Something about ancillaries and traits

[Andreas]

As a side not, IIRC from ealier this day, the trait file is indeed read first...

Sounds good anyway, I also noticed this today, have to check it some day. Even if I cannot come up with any good use, it's moddable and that's worth cheering:)

[Malrubius]

Simetrical had an idea about using Electability for the purpose of tracking who has what ancillary. It looks like any culture can get the Electability attribute, and it can take very high values. SenateStanding and PopularStanding are the same way.

[alpaca]

They'd only take up to 65536 (as a signed short, used for most values in R:TW) or 4,294,967,296 (as a signed integer), not likely though, as most small values are shorts. This means, either 16 or 32 ancillaries.
It wouldn't be very useful without the modulo-operator anyways because you get lots (and I mean lots) of conditions.
I don't think this should be used really.

[Simetrical]

See my post after that one in the thread. I checked it out―Electability appears to work up to at least a billion, and you only need two triggers per desired ancillary. So 30+ ancillaries should certainly be possible. If you're right about the four-byte allocation, which would make sense, then that would still be good for 32 ancillaries. More, if you factor in other possibilities like SenateStanding (although that obviously won't be useful for mods that use that attribute).

In any case, this doesn't have a lot to do with your discovery. That can't be used to track ancillaries, because of transfer problems. Possibly it has some other use, but I can't think of one.

[alpaca]

Hmm do you know that signed numerical types are cyclic?
That means, if you go above 32768, e.g. 32769, you land at -32768.
So if you only tested to add 100000 and tested Electability = 100000 then you'd usually get true, except that it isn't 100k but -31072, which is, e.g., identical to 34464.

Anyways, it isn't too useful because of the heavy condition requirements ;)

[Simetrical]

Hmm do you know that signed numerical types are cyclic?

They don't have to be. Sometimes they just "max out" at a certain value. But yes, I'm aware that that can occur and should have taken it into account in my testing.

That means, if you go above 32768, e.g. 32769, you land at -32768.
So if you only tested to add 100000 and tested Electability = 100000 then you'd usually get true, except that it isn't 100k but -31072, which is, e.g., identical to 34464.

Well, the number I used was a billion. In binary that's 111011100110101100101000000000. The last sixteen bits are 1100101000000000, or 51,712, presumably actually +18,944. Now, the test for >= a billion of course worked fine. Now, a million is 11110100001001000000 in binary, the last 16 bits are 0100001001000000 or 16,960 in decimal. This would work out to –15,808 with the sign taken into account, which would indeed be less than the billion value. My final testing value, a thousand, would of course be less than the billion value.

Conclusion: more testing is necessary. We should test, specifically, whether 1,000,000 = 1,065,536; whether 32,767 is less than or greater than 32,769; and whether 65,535 is less than or greater than 65,537. You're quite right, this might not work perfectly, but we'll certainly be able to make it work for at least sixteen ancillaries.

Anyways, it isn't too useful because of the heavy condition requirements ;)

Hmm? There are only two triggers required per ancillary.

[alpaca]

Yes but if you want to check whether a character has the ancillary who has byte 1 you'll have to check every odd number (presumably 32768 conditions) with an or.