From GRFSpecs
Jump to: navigation, search


Action 3 assigns graphics sets (referenced to by (chains of) action 2(s) to feature IDs (vehicles, stations, houses, industries, ...).


The format of the data is feature-dependent.

The data is:

 <Sprite-number> * <Length> 03 <feature> <n-id> <ids...> <num-cid> (<cargo-type> <set-ID>)... <default set-ID>
Element Size Description
<Sprite-number> dec A sequential sprite number
<length> dec The total number of bytes used in this action
03 B Defines action 03
<feature> B What type of feature the IDs refer to
<n-id> B Number of IDs this action 3 associates graphics with
<ids...> B/B* IDs of the current feature this action 3 associates graphics with. There must be as many IDs as <n-id> specifies
<num-cid> B Number of different cargo types to support
<cargo-type> B Cargo type for which to use the following set-ID
<set-ID> W Set-ID (from action 2 or from a varaction2 chain) to use for this cargo type
<default set-ID> W Default set-ID to use if none of the above matches



This is just the number you are at.


Count the number of bytes in this action.


This sets the type of feature that you wish to change. Set it to:

Value Feature
00 Trains
01 Road Vehicles
02 Ships
03 Aircraft
04 Stations
05 Canals/Rivers
07 Houses
09 Industry Tiles
0A Industries
0B Cargos
0C Sound Effects (generic callback only)
0D Airports
0E Signals (generic callback only)
0F Objects
10 Railtypes
11 Airport Tiles


How many items of the current feature this action 3 defines new graphics for. If this is more than one, all items listed will get the same graphics. If this value has bit 7 set (i.e. 80 added), it is a wagon override. See Action 3 - Livery Override for more info on this feature.

You can make a definition with n-id equal to zero (and thus no ids that follow).  This creates a generic feature-specific definition not associated with any particular item.  At the moment, this is used for generic callbacks, but might be extended to other functions eventually.


Feature IDs to use this action 3 for. All IDs are counted from the first of their class, i.e. the first road vehicle has 00, as does the first plane, the first ship, and the first train vehicle.

In OpenTTD since r13482, each ID is an extended byte for vehicles, otherwise the ID is a regular byte.

For canals and rivers the id has a special meaning, see its own Action 3 page

For town buildings, the IDs are the house IDs, and specifying a house ID that haven't been defined before (by setting its property 08) doesn't do anything, but doesn't cause an error, either. Note that you don't necessarily have to assign a set-ID to a house ID, the old TTD sprite of the substitute type will be used if you don't do so.  Industry tile IDs work in the same manner.


Number of cargo type definitions that follow. Can be zero if only the default follows.

For features 05 (canals/rivers), 07 (houses), 09 (industry tiles), 0A (industries), and 0B (cargoes) this must always be zero.


For vehicles (features 00 .. 03) and stations (feature 04)

The cargo-type for which the set-ID applies.  If the item is built to use this type of cargo, or if it is refitted for it, the given set-ID is used as its graphics.  See column "type A" in the table at CargoTypes for a list of cargo-type values.

If the grf file has installed a cargo translation table, the cargo type here refers to the cargo with the label in the given slot of the translation table, e.g. if you use cargo-type=08, it refers to the cargo that has the label in the ninth slot (numbered 08) in the translation table.

If defined, cargo-type FF is used for graphics shown in the purchase or construction window.

Note that for dual-headed trains (prop 13) special rules for the purchase menu sprite apply: two sprites are drawn (for front and back) as if the vehicle is normally constructed. If you supply one purchase menu sprite, it will be used for both vehicle parts in the purchase menu. Provide a set of 8 sprites, and the 7th resp. 3rd sprite will be drawn; provide a set of 8 blank sprites except the 7th if you want to fully control a single purchase menu sprite for a dual-headed engine.

For stations, you can additionally define a special cargo-type of FE which prevents the default from being used (which would show the sum of all cargo).  Instead, the given set-ID is displayed with no cargo at all.

Railtypes are available only in OpenTTD > r19056 and its action 3 re-uses the 'cargo'-type definition.

For details see its own Action 3 page

For canals/rivers, houses, industry tiles, industries and cargoes (features 05, 07, 09, 0A and 0B)

As <num-cid> is zero for features 05 (canals/rivers), 07 (houses), 09 (industry tiles), 0A (industries), and 0B (cargoes), <cargo-type> and <set-ID> need to be skipped and you only have to set <default set-ID>.

For objects (feature 0F)

Objects support a buy menu sprite similar to vehicles (cargo-type FF).

default set-ID

Default set-ID if no entry from the cargo-type list above matches, or if there are no special cargo-types listed at all.


Below is an example of what a real action 3 pseudo-sprite could look like for a train engine.

 13 * 7   03 00 01 02 00 00 00
Byte Meaning
13 <sprite-number>
7 <length> of the action in bytes; start counting at 03 (<action>)
03 <action>: sets this pseudo-sprite to function as action 3
00 <feature>: 00 for trains
01 <n-id>: One ID to change in this case
02 <ids...>: vehicle ID (02 - Ploddyphut Choo-Choo)
00 <num-cid>: this engine doesn't have cargo-specific graphics
00 00 <default set-ID>: Use action 2 ID 00, because it is a word value you add 00