Is the bard kit targeting in SPLPROT bugged?

[temnix]

I have used effects 318 and 326 before with wizard kits, but now it is not working with bard kits. I have a spell that checks in turn for the skald, blade and jester kits and applies subspells accordingly, but the character always draws the last card, no matter what his own kit is. Below there is a subspell for bards without kits - separated by 318 blocks for the jester, the skald and the blade, and that one works, so the engine does recognize the having of bard kits, it only applies everything to a character with any of them. I can still get the different options through by having an invisible minion do the checks, but this sucks.

For that matter, even with wizard kits I haven't tried a combination where several kits would be checked for in one spell. Maybe this fails with them too.

[subtledoctor]

The default SPLPROT entry for kits checks for bit equality. You need to add a new line to the .2da file for exact equality. 

Edited May 4, 2022 by subtledoctor

[temnix]

The checks are the same for wizard and bard kits, but wizard kits' work individually and bard kits' just don't. I checked. I got around this by using 177 and then separate EFFs for the kit values.

[DavidW]

10 hours ago, subtledoctor said:

The default splprot entry for kits checks for bit equality. Or something. You need to add a new line for exact equality. 

 

1 hour ago, temnix said:

The checks are the same for wizard and bard kits, but wizard kits' work individually and bard kits' just don't. I checked.

That's because wizard kits all have IDS that are exact powers of 2, but bard kits do not.

[subtledoctor]

2 hours ago, temnix said:

The checks are the same for wizard and bard kits, but wizard kits' work individually and bard kits' just don't.

I mean, I told you how to make it work. Are you arguing against that?

It's like some people don't actually want to solve their problems.

[Graion Dilach]

Nah, it's just that some people can't think in bitwise and can't accept that bitwise thinking makes sense. I mean, we also had that smartass, who - after numerous other people tried to explain the difference between a BOR and an OR -, still kept saying the difference is just semantics... ohwait...

[subtledoctor]

2 hours ago, Graion Dilach said:

after numerous other people tried to explain the difference between a BOR and an OR -, still kept saying the difference is just semantics

I suppose technically the difference is semantics... but in this context semantics is, like, the whole ballgame.

[temnix]

I think DavidW just said that it's a problem with the number references of the kits.

[subtledoctor]

55 minutes ago, temnix said:

I think DavidW just said that it's a problem with the number references of the kits.

No, he said "that's how the kits are numbered." It is not a problem, it's just how the game is. The "problem" is that you are trying to use sheer force of will to make the game work differently than it does, rather than just accounting for how the game works in your code. You would prefer to write code that doesn't work and bitch about the game itself being wrong (for some nonsensical value of "wrong") instead of just writing code that works.

You know what, I can't even be bothered to restate what I've already said. Good luck.

[DavidW]

5 hours ago, temnix said:

I think DavidW just said that it's a problem with the number references of the kits.

It's not a problem - both sets of kits are numbered perfectly legally. It's just that as it happens (I think as a legacy of oBG1) the wizard kits are numbered so that doing a bitwise-equality check (which, as SD says, is logically speaking wrong) happens to get the right number. Specifically, if x and y are both powers of 2 then they are bitwise equal if and only if they are equal, so you get away with it.

[temnix]

It's not me who gets away with it, in that case. It was the developers who put the checks for kits as they are. And Beamdog didn't change those in any way. So you say a line needs to be added with, what, 0 as the relation instead of 8? All right, but I worked around it. Let the next people who wonder why yet another thing isn't working in the toolset come and learn that they need to rewrite the existing checks to make a simple condition trigger.

[subtledoctor]

1 hour ago, temnix said:

It's not me who gets away with it, in that case. It was the developers who put the checks for kits as they are. And Beamdog didn't change those in any way.

I don't know where or how Beamdog uses that line, but a good guess is that they use it somewhere for an actual bit-equality check.

[DavidW]

1 hour ago, temnix said:

It's not me who gets away with it, in that case. It was the developers who put the checks for kits as they are. And Beamdog didn't change those in any way.

3 minutes ago, subtledoctor said:

I don't know where or how Beamdog uses that line, but a good guess is that they use it somewhere for an actual bit-equality check.

Good, but wrong. I've just had a look and that spellstate isn't used in any ITM, SPL or EFF file in IWDEE, BG2EE or SoD. And to be honest it's hard to think what the actual point would be - with a few very esoteric exceptions (which you probably know better than I do), kitids doesn't store information bitwise.

To be honest, my guess is that it's just a mistake - it appears in the middle of a long list of splstate entries that have been put in in bulk to cover general checks, and it's directly below a row (alignment) where bitwise checking does make sense. I suspect someone in IWDEE development just coded up a bunch of general checks, got that one wrong, and it's never been an issue because it doesn't actually get used. (Note that the human-readable descriptors in splprot.2da were added later.)

I'll report it at the EE fixpack forum, there's at least a case for fixing it. (And if I'm missing some subtle use case, someone there might know what it is.)

[temnix]

Why not overwrite the relation = 8 checks with relation = 0 checks for those entries? If that's how it works. Yes, this was probably just good enough for the developers when they needed simple checks. But if I didn't put in extra obsessive testing to see if the bard kit checks worked, I would have assumed they were fine, like the wizard checks, and the mod would ship with quite a big error. Anyway, @DavidW, since you're here, can you tell me where to put the macro for adding item headers that Ardanis wrote a few years ago? I don't know where to put this macros or how to use it. I get an error if I put this code in a GLOB patch. Does it need to be added outside somewhere?

DEFINE_PATCH_FUNCTION ~ADD_ITEM_HEADER~
  INT_VAR
    type=3
    required_id=0
    location=3
    alt_dicesize=0
    target=1
    target_count=0
    range=0
    projectile_type=0
    alt_dicenumber=0
    speed=0
    alt_damage=0
    thaco=0
    dicesize=0
    school=0
    dicenumber=0
    sectype=0
    damage=0
    damage_type=0
    charges=0
    depletion=0
    flags=0
    projectile=1
    overhand=0
    backhand=0
    thrust=0
    is_bow=0
    is_xbow=0
    is_sling=0

    copy_header=0
    insert_point=~-1~
  STR_VAR
    icon=~~
  RET
    insert_point
BEGIN
  LPF ~FJ_SPL_ITM_REINDEX~ END
  hs=0x38

  READ_LONG 0x64 ho
  READ_SHORT 0x68 hc
  READ_LONG 0x6a eo
  insert_point = (insert_point>hc || insert_point<0) ? hc : insert_point
  copy_header = (copy_header<0) ? 0 : copy_header

  PATCH_IF copy_header>hc BEGIN
    PATCH_WARN ~Unable to copy %copy_header%th header, %SOURCE_FILE% contains only %hc% headers!~
  END ELSE BEGIN
    INSERT_BYTES ho+insert_point*hs hs
    hc+=1
    eo+=hs
    PATCH_IF copy_header BEGIN
      READ_SHORT ho+(copy_header - 1)*hs+0x1e ec
      READ_SHORT ho+(copy_header - 1)*hs+0x20 ei
      READ_ASCII eo+ei*0x30 effs (ec*0x30)
      READ_ASCII ho+(copy_header - 1)*hs copy (hs)
      WRITE_ASCIIE ho+insert_point*hs ~%copy%~ (hs)
    END
    WRITE_SHORT 0x68 hc
    WRITE_LONG 0x6a eo

    READ_SHORT 0x70 ei // technically, it is a counter
    FOR (i=ho;i<ho+hc*hs;i+=hs) BEGIN
      READ_SHORT i+0x1e ec
      WRITE_SHORT i+0x20 ei
      ei+=ec
    END

    PATCH_IF copy_header BEGIN
      READ_SHORT ho+insert_point*hs+0x1e ec
      READ_SHORT ho+insert_point*hs+0x20 ei
      INSERT_BYTES eo+ei*0x30 ec*0x30
      WRITE_ASCIIE eo+ei*0x30 ~%effs%~ (ec*0x30)
    END ELSE BEGIN
      off=ho+insert_point*hs
      WRITE_BYTE off type
      WRITE_BYTE off+0x1 required_id
      WRITE_BYTE off+0x2 location
      WRITE_BYTE off+0x3 alt_dicesize
      WRITE_ASCIIE off+0x4 ~%icon%~ (8)
      WRITE_BYTE off+0xc target
      WRITE_BYTE off+0xd target_count
      WRITE_SHORT off+0xe range
      WRITE_BYTE off+0x10 projectile_type
      WRITE_BYTE off+0x11 alt_dicenumber
      WRITE_BYTE off+0x12 speed
      WRITE_BYTE off+0x13 alt_damage
      WRITE_SHORT off+0x14 thaco
      WRITE_BYTE off+0x16 dicesize
      WRITE_BYTE off+0x17 school
      WRITE_BYTE off+0x18 dicenumber
      WRITE_BYTE off+0x19 sectype
      WRITE_SHORT off+0x1a damage
      WRITE_SHORT off+0x1c damage_type
      WRITE_SHORT off+0x22 charges
      WRITE_SHORT off+0x24 depletion
      WRITE_LONG off+0x26 flags
      WRITE_SHORT off+0x2a projectile
      WRITE_SHORT off+0x2c overhand
      WRITE_SHORT off+0x2e backhand
      WRITE_SHORT off+0x30 thrust
      WRITE_SHORT off+0x32 is_bow
      WRITE_SHORT off+0x34 is_xbow
      WRITE_SHORT off+0x36 is_sling
    END
  END
END

 

[DavidW]

2 minutes ago, temnix said:

Why not overwrite the relation = 8 checks with relation = 0 checks for those entries? If that's how it works.

There's a case for that; see here

 

3 minutes ago, temnix said:

But if I didn't put in extra obsessive testing to see if the bard kit checks worked, I would have assumed they were fine, like the wizard checks, and the mod would ship with quite a big error.

The descriptors in splprot.2da are useful here: note that 109 is described as 'STAT(KIT)BITS=n', not 'STAT(KIT)=n'.

 

4 minutes ago, temnix said:

can you tell me where to put the macro for adding item headers that Ardanis wrote a few years ago?

No idea. If it doesn't just go in an ITM patch, I don't know why. A