Page 1 of 1

Changing in behaviour when replacing OTTD sprites with Actio

Posted: 15 Nov 2007 08:16
by Rubidium
Since 11433 Action A sprite replacements that target OTTD sprites, i.e. sprites that are not from the original TTD sprites, will not work as they did before. This is due to the fact that there was a big reordering of all OTTD sprites.

As a result of this reordering sprites are grouped more logically and the sprites are now replaceable via an Action 5. The Action 5 for the GUI sprites furthermore supports changing only a contiguous subset of sprites. The sprites will keep the order as they are now and will keep the same Action 5 offset. However, they will not necessarily keep the same absolute sprite number.

Example code how one could support both Action A and the new Action 5 in one GRF:

Code: Select all

// First step... Action 07, Variable A1 might not exist. If that's the case it always skips.
   -1 * 0  07 A1 04 \7= FF FF FF FF 03
// Real version check.
   -1 * 0  07 A1 04 \7< \w11432 00 06 02
// We are going to overwrite the Action A sprite with the new data (05 95 01 04)
   -1 * 0  0D 00 00 FF FF 05 95 01 04
// Actually overwrite the data
   -1 * 0  06 00 04 00 FF
// Original Action A sprite
   -1 * 0  0A 01 04 3A 0C

Re: Changing in behaviour when replacing OTTD sprites with Actio

Posted: 15 Nov 2007 08:34
by DaleStan
It looks to me like you're turning the action A into an action 6. I don't think that's what you wanted.
Correcting the 06 to 05 doesn't help; that turns the A into "05 95 01 04 0C", which isn't valid.
If the endianness swaps too, which I'm pretty sure it doesn't, then I get "05 01 95 06 0C", and that's no better.

Am I missing something here?

Re: Changing in behaviour when replacing OTTD sprites with Actio

Posted: 15 Nov 2007 10:00
by Rubidium
What is invalid in "05 95 01 04 0C" ? The added 0C?

Re: Changing in behaviour when replacing OTTD sprites with Actio

Posted: 15 Nov 2007 10:35
by DaleStan
The 95. Was. I posted before you updated the documentation, or at least before I'd seen the update. (Extraneous bytes are never an error. They may warrant a diagnostic, but not an error.)