SPLPROT.2da and relation #9 "binary not match"

[subtledoctor]

The IESDP/Camdawg's original post about this says:

Quote

9 - binary not match (none of the bits are common)

That sounds like it would work for me, but in some testing it is not working.  Maybe people smarter about this bit-equality stuff can help me figure out why.

What I am doing: I take a proficiency stat with 4 bytes, and split it into 8 sections of half a byte each.  The first section checks for bit values of 1/2/4/8, thus recording values of 1 through 15 that I can use via opcode 318 or 324 or 326.  The second section checks bit values 16/32/64/128, thus recording values of (1 << 4) through (15 << 4).  The third section checks values 256/512/1024/2048, thus recording values of (1 << 8 ) through (15 << 8 ). Et cetera.

The problem is, what happens if the value goes negative?  I have a circumstance in which your value in the second section can start at, say, (5 << 4), and then progressively drop to no bits set in section 2 (so, the equivalent of (0 << 4))... and then have an effect that applies a negative adjustment of 16, i.e. (1 << 4).  Since the value of the stat is something other than a combination of 16/32/64/128 - 9, say, or 521 - then applying a reduction of 16 could wrap around to a negative value, or just the wrong value over 256. 

So what I would like to do is add a 318 effect to any spell that reduces the stat values.  To basically say, "if the stat's value is not bit equal to one of the 15 combinations of 16/32/64/128, then do not apply this reduction."  I therefore used relation #9 (no bits in common), filtering for (15 << 4). It did not work.

I guess the question is: should that have worked?  Is it likely that I made a mistake in implementation, which can be fixed?  Or am I barking up the wrong tree with relation #9?  And if the latter, is there a way i can do this?

Thx all.

Edited August 7, 2020 by subtledoctor

[DavidW]

I'm not super familiar with the "binary not match" description, but from the description, "no bits in common" is more demanding than you want. 

Restricting to the first byte for simplicity, you want (if I understand correctly) to block the effect on 0b0000xxxx, because you want to keep within the effect range of that second half-byte. And you're doing it by a binary-not-match with 15<<4 = 0b11110000. 

But (for instance) if the stat's value is 0b00000000, there are bits in common: the bits in the first half-byte. So the effect will return false and the block won't happen.

 

 

[subtledoctor]

Ah - right.  Damn.  But yes,

33 minutes ago, DavidW said:

want to block the effect on 0b0000xxxx

Is precisely correct.  More precisely, since the stat is four bytes, I want to set up:

• one spell that blocks the effect on 0bxxxx0000xxxxxxxxxxxxxxxxxxxxxxxx
• one spell that blocks the effect on 0b0000xxxxxxxxxxxxxxxxxxxxxxxxxxxx
• one spell that blocks the effect on 0bxxxxxxxxxxxx0000xxxxxxxxxxxxxxxx
• one spell that blocks the effect on 0bxxxxxxxx0000xxxxxxxxxxxxxxxxxxxx
• ...etc.

I'm having flashbacks to around two years ago, trying something like this with relation #11 ("stat doesn't contain all the bits of value") and that didn't work either.  Though, I may have been doing something different.  Really hard to remember exactly.

[DavidW]

If you can cope with two half-bytes, you could do it with 16 splprots. But that’s already cumbersome, and the combinatorics will be unmanageable beyond two.

[kjeron]

 

5 hours ago, subtledoctor said:

I guess the question is: should that have worked?  Is it likely that I made a mistake in implementation, which can be fixed?

Yes it should.  Error should be elsewhere.

 

"Bit Not Match" is just the negated result of "Bit Match", it only looks for matching set bits, not matching unset bits.

(Value) Bit Match (0b00000000) = false

(Value) Bit Not Match (0b00000000) = true

(15 << 4) Bit Not Match (0b1xxx0000) = false

(15 << 4) Bit Not Match (0b0000xxxx) = true

 

[DavidW]

That's interesting: apologies, then, @subtledoctor, I misinterpreted the IESDP. (It would be clearer as 'none of the set bits are common'.)

[subtledoctor]

It's not working in my tests - maybe something about the way the 233 effect kicks in, or how it is canceled by 321 (this is a repeating spell), or something.  But anyway I think instead of applying a spell and using a 318 effect at the beginning of that spell filtering by relation #9 "bit not match (0b11110000)" to block itself, I can instead simply cast the spell via 326, filtering by relation #8, "binary match (0b11110000)."