Not All AA Displayed

[Uleat]

I haven't been ignoring this one..my online time is limited and I've attempted twice to respond to it - without luck...


You can set bitmasks up to represent just about anything..but, looking specifically at the expansion value chart posted (re-posted) above:

Kunark has a bit value of 1 and a bitmask of 1.


A standard ordinal bitmask will usually exclude 0 from its rankings due to the fact that the lowest provable ranking value is 1 - there is no 0's column
in bit representation.

To convert an ordinal bit ranking to bit position, yes, a simple (1 << (ord_val - 1)) should be used. For cases of 0, you would simple prove it by
checking (bool)ord_val == false or ord_val == 0.

SIDENOTE: You can create a positive mask for validating greater than the ordinal ranking by using (~0 << ord_val). C++ doesn't implement bit rotations,
so there is no chance of a wrap-around with a standard bit shift.


In the case of Kunark, converting the 'value' to a bit position in the coded example does indeed produce 0x02 where the mask is 0x01.

However, look at what is being considered: CanUseAlternateAdvancementRank

Since the transformation reflects a greater than positional value, and there is a 'false' return methodology, you really don't want that condition
to be true for an exclusionary check.


There's a lot of systems that I'm not up-to-speed with - this being one of them.

But, looking at what is defined and what is being checked, I think that particular code snippet is correct. That's not to say that there may not be
issues elsewhere (these guys are pretty sharp and usually catch logic errors pretty quick.)

[Cilraaz]

Originally Posted by Uleat

Kunark has a bit value of 1 and a bitmask of 1.

Kunark would be the oddity. I hadn't considered it, since Kunark didn't have any AA availability.

Originally Posted by Uleat

However, look at what is being considered: CanUseAlternateAdvancementRank

Since the transformation reflects a greater than positional value, and there is a 'false' return methodology, you really don't want that condition
to be true for an exclusionary check.

Perhaps I'm misunderstanding your intended message, but since it returns false on a not true, the result from the bitwise & should be true if the AA is to be visible to the player. Using SoL as an example, since I can break the comparison down to just a nibble, we currently have the bitwise & of the expansion bitmask (0100) and the shifted rank->expansion value (1000):

0100
1000
----
0000

Throwing a not on that then evaluates true and in turn returns false, even though we obviously want SoL AA to be used if SoL is the enabled expansion

Originally Posted by Uleat

There's a lot of systems that I'm not up-to-speed with - this being one of them.

But, looking at what is defined and what is being checked, I think that particular code snippet is correct. That's not to say that there may not be
issues elsewhere (these guys are pretty sharp and usually catch logic errors pretty quick.)

Which snippet do you believe is correct? The one I posted or the one in source. Perhaps the above bit in this reply is wholly unnecessary.