Random bits in Var 2

[PikkaBird]

Cookie up for grabs.

[How] Can I access the random bits (of an industry tile) in a var action 2?

'Create a random action 2 that picks between n var2s, set constants in the var2s then point all the var2s to a 1C test' would work, but is a little inelegant...

[mart3p]

For station tiles, I tried using variable 5F. This works fine in TTDPatch but is unsupported by OpenTTD.

I ended up using a random action 2 that chooses between a number of values, then using a procedure call (variable 7E) to call the random action 2.

[DaleStan]

If 5F is giving you random bits, I'm pretty sure it's broken. The documentation says "random triggers", and I remember discussion to the effect of "this is triggers, not bits, as bits are accessible via a random 2".

I'm not aware of any more elegant way to read an industry tile's (or house's) random bits.

[PikkaBird]

Indeed, that's what I thought when I read the spec for 5F.

I ended up using my inelegant solution, and it works well enough.

[mart3p]

If 5F is giving you random bits, I'm pretty sure it's broken. The documentation says "random triggers", and I remember discussion to the effect of "this is triggers, not bits, as bits are accessible via a random 2".

So "random triggers" means the trigger bits themselves (i.e. bit 0 - new cargo waiting, bit 1 - no more cargo, etc.)?

I tried it anyway, to see what would happen and as I say, it seemed to give random bits. The value returned was certainly different for each station tile of any one platform. But I was only using bits 16 and 17, so maybe these just contain junk. This shouldn’t be the case though, as the spec says var 5F is a doubleword...


Edit: Here’s a test GRF and the NFO code that demonstrates this behaviour. It simply selects a sprite layout with numbers 0 to 3, using var 5F bits 16 and 17.

var5F.png (10.29 KiB) Viewed 2211 times

I also tested with bits 0 and 1, this also gives random selection of the sprites but for the whole station. This is what would be expected if var 5F was accessing the random bits but not the random triggers.

[frosch]

Hmm, indeed, this var is missing in ottd. However mart3p is right here:

.getrandomtriggers:
jmp [getrandombits+ecx*4]

It does return random bits.

So what should it return? IMO randombits are more useful than random triggers. Though 32bits have enough room for both.

[michael blunck]

Yes, this is faulty. Var 5F should´ve returned all trigger bits which have been triggered so far.

AFAIR, this feature had been introduced by Josef a long time ago on my request (to be working together with CB32), but even back then this bug seemed to have been in existence. Obviously it had never been fixed, and after a while it went out of focus.

regards
Michael

[DaleStan]

So, since obviously no one has ever used 5F for its documented purpose, should I/we/someone/whoever:
1) Fix it to agree with the documentation?
2) Fix the documentation to agree with the behaviour?
3) Add the triggers in the third byte and update the documentation appropriately?
4) Move the bits to the high word, put the triggers in the low byte, and update the documentation appropriately?
5) Something else?

[frosch]

Wrt 3): Fourth byte. Stations need 3 bytes for the bits.

[peter1138]

This has been changed to triggers bits in the low byte and random bits in the top three bytes, and is also now supported in OpenTTD.