Something about ancillaries and traits

Well I'm not 100% sure if this has been posted before, I didn't know it yet anyways and if it hasn't, this could be interesting news for some of you.

export_descr_ancillaries.txt trigger definitions accept and successfully use "Affects" phrases.
That means, you can add traits with the same trigger simultaneously as an ancillary.

This doesn't work vice-versa, export_descr_character_traits does accept and parse the "AcquireAncillary" statement but it doesn't recognize the ancillary (which makes me think that the traits file is read first by the game).

Now I currently can't think of a direct application as we still can't track properly an ancillary's being moved between characters, but it might be interesting to know.

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:)

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.

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.

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.

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 ;)

Quote:

---

Originally Posted by alpaca

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.

Quote:

---

Originally Posted by alpaca

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.

Quote:

---

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

---

Hmm? There are only two triggers required per ancillary.

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.

No, you just have to check if they have Trait Ancillary1 = 1.