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
Include sprite layout info in station var68 result
Moderator: TTDPatch Moderators
-
- Tycoon
- Posts: 5948
- Joined: 27 Apr 2005 07:09
- Contact:
Re: Include sprite layout info in station var68 result
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
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
-
- Tycoon
- Posts: 5948
- Joined: 27 Apr 2005 07:09
- Contact:
Re: Include sprite layout info in station var68 result
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.frosch wrote: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
regards
Michael
Re: Include sprite layout info in station var68 result
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.
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.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Who is online
Users browsing this forum: No registered users and 2 guests