Include sprite layout info in station var68 result

[michael blunck]

Station info of nearby tiles (68) returns a DWORD with bits 14..31 being undefined and reserved "for future use".

In bits 0..7, var68 returns the set-ID of the tile in question (if defined in the current .grf), and uses bits 8..13 for some additional information. Unfortunately, checking the set-ID isn´t sufficient for many applications, because most station set-IDs contain different sprite layouts which may need to be treated differently. At the moment, it´s not possible to distinguish between those.

My proposal is to use 8 of the unused bits (e.g. 14..21) for the actual sprite layout number of that particular set-ID.

Would this be possible?

regards
Michael

[frosch]

Hehe, so when you use this variable in callback 0x14 and the other tile does the same and queries the layout of the first tile, you will end up with a nice recursion

[michael blunck]

Hehe, so when you use this variable in callback 0x14 and the other tile does the same and queries the layout of the first tile, you will end up with a nice recursion

Well, I don´t see any problem. You may already do so by just using the set-ID here, or by having two tiles querying animation states of each other and react appropriately.

regards
Michael

[frosch]

Neither the set id nor the animation state can couse a recursion. They can only change on certain events (player action, tile loop, trigger etc, ...). But while no such event is pending, their value is fixed and stored in the map. I.e. you can read their value as often as you like in one callback, it will not change.

OTOH the tile layout callback is always called when the value is needed. There is no specific trigger when a tile layout is updated. Currently it is evaluated whenever the tile is drawn, but making it readable from a callback will cause the described deadlocks.