Extended Action 1

Implemented in r22926.


Common problems

Reusing sprites

Action 2 can always only reference sprites from one spriteset. So, if multiple action2 want to use some common sprites (e.g. groundsprites),

All three solutions are bad in some way. For stations there is another way around the issue: Sprties can be resolved using multiple Action 1-2-3 chains. But for features using Action 2 spritelayouts (houses, industry tiles, airport tiles, objects) that is not possible.

Spritesets with different amount of sprites

Every spriteset in an Action 1 has the same amount of sprites. If a spriteset needs more sprites than other sets, all other sets need to be extended with dummy sprites.

Suggestion for new Action 1 format

The idea is to allow referencing spritesets from different Action 1 in all Action 2. To achieve that a index for the


to define is appended to Action 1. That way one Action1 defines the spritesets



first-spriteset + num-sets - 1

. If an earlier Action 1 loaded different spritesets they remain valid.

So it is possible to define spritesets 23..25 in one Action 1, define spritesets 0..5 in another Action 1. An Action 2 can then access sets 0..5 and 23..25. Later another Action 1 can redefine spritesets 2..3, and following Action 2 could access spritesets 0..1, 2..3, 4, 23..25 from various Action 1.

While all spritesets defined with a single Action 1 have the same amount of sprites for each spriteset, different Action 1 may define different spritesets with different amounts of sprites.

This format uses bit 7 of <feature> to indicate the new format.

<sprite-number> * <length> 01 <0x80 + feature> <num-sets> <num-ent> <first-spriteset>

Using the feature to indicate the format, is something which is done nowhere else. While there is general processing of the feature byte in e.g. TTDPatch, this is not the case for Action1.

Use "regular num-sets"==0 to indicate he new format, then append a separate new num-sets.

<sprite-number> * <length> 01 <feature> 00 <first-spriteset> <num-sets> <num-ent>
  • While num-ent==0 is valid and needed in various cases, num-sets==0 defines no valid sets which could be referenced in Action2 and thus was not useful up to now.
  • Turns out there is indeed one GRF which has an Action1 with 0 sets of 0 sprites: The "TTO Conversion" set inserts such an Action1 before defining house spritelayouts which only reference ActionA sprites.

In both cases num-sets is an extended byte in the format.

Element Size Description
<sprite-number> dec A sequential sprite number
<length> dec The total number of bytes used in this action
01 B Defines action 01
<feature> B The feature that following sprites should be used for.
<num-sets> B* The number of sprite sets you have (one sprite set is one vehicle/station/ship etc)
<num-ent> B* The number of views the sprite has
<first-spriteset> B* The first spriteset to define.

The Action 1 must be followed by a consist of

num-sets * num-ent



OpenTTD implementation details