GRFSpecs - User contributions [en-gb]

VariationalAction2/Industry Tiles

2025-12-27T09:57:45Z

Ahyangyi: Took me some time til I realize this suggestion was outdated for modern GRF versions... Let's add a version tag.

==Introduction==

== Variables ==

{| |-
!Variable!![[GRFActionsDetailed|'''Size''']]!!Version!!Content
|-
|40||B||{{ottdp|0.6|2.5}}||Construction state of the tile: a value between 0 and 3 (only defined for industries)
|-
|41||B||{{ottdp|0.6|2.5}}||Ground type, the same as variable 81 for [[VarAction2Canals|canals]]
|-
|42||B||{{ottdp|0.6|2.5}}||Current [[TownZones|town zone]] of the tile in the nearest town
|-
|43||D||{{ottdp|0.6|2.5}}||Relative position
|-
|44||B||{{ottdp|0.6|2.5}}||Animation frame. Like [[VarAction2Houses#Current animation frame 46|house variable 46]] but can contain anything 0..FF.
|-
|60||D||{{ottdp|0.6|2.5}}||Land info of nearby tiles
|-
|61||D||{{ottdp|0.6|2.5}}||Animation stage of nearby tiles
|-
|62||D||{{ottdp|0.6|2.6|ttdprev=r1270}}||Get industry or airport tile ID at offset
|}

VarAction2 for airport tiles is only available in OpenTTD r19204 or later

No 80+x variables are available (nor will they ever be). Try to access one will crash TTD.

=== [[TownZones|Town zone]] (42) ===

[[TownZones|Town zone]] where the building is situated (which is not necessarily the founder of the town). Zero if the tile isn't in a town. This is mostly useful for banks and other urban industries.

=== Relative position (43) ===

This is the position of the tile relative to the northernmost tile of the industry or airport.

'''Format:''' 00yxYYXX

{| |-
!Variable!!Content
|-
|x||the x offset from the northernmost tile
|-
|XX||same, but stored in a byte instead of a nibble
|-
|y||the y offset from the northernmost tile
|-
|YY||same, but stored in a byte instead of a nibble
|}

Because of the fact that y and x are nibbles, they may contain incorrect values if your industry exceeds 16 tiles in either direction. This variable can be used to spare industry or airport tile IDs: the same tile type can choose different representation depending on where exactly it is inside the industry.

=== Land info of nearby tiles (60) ===

The parameter of this variable is an offset from the position of the current tile. The low nibble contains the signed X offset (that is 0h=0, 1h=+1 ... 7h=+7; 8h=-8, 9h=-7 ... Fh=-1), the high nibble contains the Y offset. Therefore the parameter 00h accesses the current tile itself.

The returned doubleword is in the format '''rc zz bb ss''', where the meaning of the letters is:
* '''r''' is reserved for future use
* '''c''' contains the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#Landscape landscape class] of the tile. {{ottdp|0.6|2.5|ttdprev=alpha 72}}
* '''zz''' is the height of the lowest corner of the tile.
: {{grfTill|7}} For GRF version 7 and below: Multiple of 8.
: {{grfFrom|8}} For GRF version 8 and above: Multiple of 1.
* '''bb''' is a bit field, the meaning of the individual bits are:
{| |-
!Bit||Value||Version||Meaning
|-
|0||1||{{ottdp|0.6|2.5}}||The tile is an industry tile, and belongs to the same industry as the current one
|-
|1||2||{{ottdp|0.6|2.5}}||The tile has water on it. This flag is set for coasts as well. If you need a full water tile, check the slope data as well. If it's zero (flat tile), the tile is fully watered.
|-
|2..4|| ||{{ottdp|0.6|2.5|ttdprev=alpha 70}}||0 - normal tile; 1 - desert; 2 - rainforest; 4 - snowy tile
|-
|5..6|| ||{{ottdp|1.2|no|ottdrev=r22679}}||Water class: 0 - undefined / land; 1 - sea; 2 - canal; 3 - river. This is not the same as bit 1, as e.g. an industry tile can have a water class but has bit 1 unset.
|-
|7|| || ||reserved for future use
|}
* '''ss''' contains the slope data of the tile. The meaning of the individual bits is:
{| |-
!Bit||Value||Meaning
|-
|0||1||West corner is above the lowest
|-
|1||2||South corner is above the lowest
|-
|2||4||East corner is above the lowest
|-
|3||8||North corner is above the lowest
|-
|4||16||The tile is a steep slope (i.e. the corner opposite to the lowest one is two units higher)
|-
|other bits|| ||always zero
|}

The resulting, possible values for this byte are illustrated in this image (from OpenTTD docs):

[[File:Industrytile_var60.png]]

{{grfTill|7}} It is sometimes more useful to know the height of the highest corner of the tile. This can be computed with "zz/8 + ((ss+15)/16)", that is: "60 XX 33 1F 00 60 XX 40 FF 0F 10", where XX is the parameter. This returns a number 0..31 instead of 0..248, though.
Why this works, and how to adjust for the different value range, are left as exercises for the reader.

Be aware that due to the way that TTD generates a random map, the class number of a neighbour tile could be different from what you expect. E.g., when placing a water-based industry adjacent to a coast in a random game, these tiles aren´t adjacent to water anymore after the industry has been generated and therefore you can't reliably check for coast tiles in the industry´s placement callback.

=== Animation stage for nearby tiles (61) ===

The parameter of this variable is interpreted the same way as for variable 60. The return value is FFFFFFFFh if the given tile doesn't belong to the industry, and the number of the current animation frame of the given tile otherwise. (That is, the value that var 44 would return for the given tile.)

=== Get industry tile ID at offset (62) ===

Works similarly to industry variable 60, except that the point of reference is the current tile instead of the north tile of the industry, and the offsets are considered to be signed.

==Example==

VariationalAction2/Stations

2025-02-02T19:23:34Z

Ahyangyi:

==Introduction==

Rail stations share a number of variables with airports. The common variables are documented on a [[VariationalAction2/BaseStation|separate page]]

== Variables ==
{| |-
!Variable!!Version!![[GRFActionsDetailed|'''Size''']]!!Description
|-
|10||{{ottdp|0.7|2.5}}||D||Additional information for sprite selection - see [[Action0/Stations#General_Flags_.2813.29|General station flags]] and [[AdvancedSpriteLayout]]
|-
|40||{{ottdp|0.6|2.5}}||D||Platform info and relative position
|-
|41||{{ottdp|0.6|2.5}}||D||Platform info and relative position for individually built sections
|-
|42||{{ottdp|0.6|2.5}}||D||Terrain and track type
|-
|43 <ref>{{ottdp|1.2|2.5|ottdrev=r22848|ttdprev=2.5 beta 2}} Available in the purchase list as well.</ref>||{{ottdp|1.2|2.5|ottdrev=r22848}}||D||Player info, see [[VarAction2Vehicles#Player info (43)|vehicle variable 43]]
|-
|44||{{ottdp|0.7|2.5}}||B||Path-based signalling info
|-
|45||{{ottdp|0.6|2.5}}||W||Rail continuation info
|-
|46,47||{{ottdp|0.6|2.5}}||D||Platform info, counted from the middle
|-
|48|| || ||See [[VariationalAction2/BaseStation|Base Stations]].
|-
|49||{{ottdp|0.6|2.5}}||D||Platform info and relative position of same-direction section
|-
|4A||{{ottdp|0.7|2.5}}||B||Current animation frame
|-
|60-65|| || ||See [[VariationalAction2/BaseStation|Base Stations]].
|-
|66||{{ottdp|0.6|2.5}}||D||Animation frame of nearby tile
|-
|67||{{ottdp|0.6|2.6}}||D||Land info of nearby tiles
|-
|68||{{ottdp|0.6|2.6}}||D||Station info of nearby tiles
|-
|69|| || ||See [[VariationalAction2/BaseStation|Base Stations]].
|-
|6A||{{ottdp|1.10|no|ottdrev=5df01bf}}||D||GRFID of nearby tiles
|-
|6B||{{ottdp|14.0|no|ottdrev=8d62a8f}}||D||16-bit station ID of nearby tiles
|-
|80||{{ottdp|no|no}} <ref>Works in TTDPatch for sufficiently small stations.</ref>||B||Number and length of train platforms
|}
<references/>

For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_StationArray TTD station structure]. Note that you have to subtract 0x10 from the offsets there, or else the facility bit mask and construction date would not be accessible; instead you lose access to variables 00..0F which are meaningless anyway.

'''WARNING''': Please do not use variables 8C..EB directly. The meaning of these variables changes if the newcargos switch is on. Use the variables 60..64 instead (see below). Those always work correctly.

== Description ==
=== Platform info (40, 41, 46, 47, 49) ===

Variables 40, 41, 46, 47 and 49 all return information about the current tile, which platform it is on and how far along the platform. The difference is in the section of the station that they consider.

{| |-
!Variables!!Regular station!!Irregular station
|-
|40, 46||Whole station||Counting entire length and all adjacent platforms
|-
|41, 47||Individually built sections||
|-
|49||Whole station||Counting length and platforms that have the same direction
|}

The term "counting" here refers to starting at the tile in question, and counting tiles in all four directions. The two directions aligned with the station direction will be the length of the station, and the other two directions give the number of platforms. For variables 40 and 46, this counting stops at the edge of the station, i.e. the first non-station tile. For variable 49, it stops either at the edge, or at a station tile that is in the wrong direction.  The resulting information is probably not really useful in the case of irregular stations, with the exception of edge detection. To correctly detect edges, you have the choice of either the station->non-station transition (vars. 40, 46), or additional an opposite-direction transition (var. 49).

Variable 41 is largely unaffected by irregular stations, because it only refers to individually built sections. However, when these individual sections are built over existing tiles, the var. 41 information of surrounding tiles changes as well, due to an internal limitation in how it is stored.

For variables 40, 41 and 49, the position is counted from the northern most edge of the station, and returned in the form TNLcCpP, where:

{| |-
!Variable!!Bits!!Meaning
|-
|T||8||Tile type: the current tile type/layout
{{ottdp|no|}} In TTDPatch this information is only available during callback 14 (and via variable 10 during callback 24).
|-
|N||4||Total number of platforms
|-
|L||4||Total platform length
|-
|c||4||Platform number current being drawn, counted from the end (starting at zero)
|-
|C||4||Platform number currently being drawn (starting from zero)
|-
|p||4||Position along this platform counted from the end, zero at the end
|-
|P||4||Position along this platform, zero at the beginning
|}

Here, the "beginning" of a station is its northern-most (up on the screen) tile, and the "end" is the southern-most (down on the screen) tile. Each variable consists of 4 bits.

For variables 46 and 47, the position is counted from the middle, i.e. the center tile has C=0 and P=0. For even lengths and numbers of platforms, the middle tile is at position L/2 resp. N/2, e.g. for length 6, it is tile 3, which is the fourth tile. The return format is xTNLxxCP, where T, N and L are as above, and C and P are the positions counted from the middle.

Since C and P can have negative numbers, here's how this is encoded:

{| |-
!Hex!!Binary!!Decimal
|-
|0||0000||0
|-
|1||0001||1
|-
|7||0111||7
|-
|8||1000||-8
|-
|9||1001||-7
|-
|E||1110||-2
|-
|F||1111||-1
|}

The counting goes like this, preferring an extra negative number for an even count (because there are 8 negative numbers available but only 7 positive ones):

{| |-
!Count!!Numbers
|-
|1||<pre> 0</pre>
|-
|2||<pre> -1 0</pre>
|-
|3||<pre> -1 0 1</pre>
|-
|4||<pre> -2 -1 0 1</pre>
|-
|5||<pre> -2 -1 0 1 2</pre>
|-
|6||<pre>-3 -2 -1 0 1 2</pre>
|}

(etc.)

=== Terrain and track type (42) ===

Variable 42 is of the format xxxxttTT, where TT is the terrain type and tt is the (translated) railway track type.

They can have the following values:

{| |-
!TT!!Meaning
|-
|0||normal (grass)
|-
|1||desert
|-
|2||rainforest
|-
|4||on or above snowline
|}

If no railtype translation table is present in the GRF, then the default translation table is used:
{| |-
!tt!!Meaning
|-
|00||railroad, regular
|-
|01||railroad, electrified
|-
|02||monorail
|-
|03||maglev
|}

If the railtype is not present in the table, then tt returns FF.

=== Path-based signalling info (44) ===

This returns the following value in bits 0-2: (bit 2 only available from alpha 47 and up)

{| |-
!State!!Value (binary)!!Value (decimal)
|-
|Reserved||111||7
|-
|Not reserved||100||4
|-
|No PBS||010||2
|}

At the moment, PBS on/off refers to the switch setting, in a future alpha version it will actually refer to whether the switch is on ''and'' the current block actually uses PBS.

The bits are defined this way to allow easy fallback to non-PBS cases. If you need graphics to show the "unreserved" state in non-PBS cases, use bit 0, but if you need the "reserved" state in non-PBS cases, use bit 1. To explicitly check whether PBS is active or not, use bit 2.

All other bits are reserved and must be masked out.

=== Rail continuation info (45) ===

This variable returns 16 bits of info whether the rail tracks continue in the eight tiles adjacent to the station tile.

{| |-
!Bit!!Value!!Set if rail continues in direction of...
|-
|0||01||+Length
|-
|1||02||-Length
|-
|2||04||+Platforms
|-
|3||08||-Platforms
|-
|4||10||+Length, +Platforms
|-
|5||20||-Length, +Platforms
|-
|6||40||+Length, -Platforms
|-
|7||80||-Length, -Platforms
|}

The following picture illustrates which bits represent which tile for the two possible station orientations:

[[File:station_var45.png]]

Bits 0 to 3 are set if there is track on the given tile, and it has a connection to the station tile. For bits 2, 3, the station of course has itself no connection to those tiles, but this doesn't matter for this variable. Bits 4 to 7 check connections to the neighbouring platform tile, i.e. bits 4 and 5 resp. 6 and 7 indicate a connection from that tile to tile 2 resp. 3. (This has changed again with 2.5 beta 4 r325.)

Bits 8..15 repeat the above, but are set if there are any train tracks on the tile and disregard whether the track is connected to the station or not entirely.

=== Animation frame of nearby tile (66) ===

(From TTDPatch 2.5 beta 5)

The parameter defines the offset relative to the current tile. Both nibbles are considered signed (that is, 8h=-8, 9h=-7, ...., Fh=-1, 0h=0, 1h=1, ..., 7h=7). The high nibble contains the amount to move sideways (between platforms), the low one is the amount to move along the platform. Negative offsets move northwards, positive ones southwards. If the selected tile is a rail station tile that belongs to the current station, its animation state is returned. Otherwise, FFFFFFFFh is returned.

=== Land info of nearby tiles (67) ===

This variable works like [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_60_|industry tile variable 60]], except for three things:
* The offsets in the parameter are interpreted relatively to the alignment of the station, the same way as for variable 66
* The '''ss''' part is "mirrored" (bit 0 and 2 swapped) for the NW-SE orientation; this will allow you to handle analogous slopes of the two orientations without checking the orientation explicitly (since TTDPatch 2.6 r1693)
* Bit 0 of the '''bb''' part is undefined

=== Station info of nearby tiles (68) ===

The parameter of this variable works the same way as the parameter of variable 66. The returned value is FFFFFFFFh if the selected tile isn't a railway station tile. Otherwise, the returned value can be separated to the following parts:

{| |-
!Bits!!Meaning
|-
|0..7||If the tile is defined in the current GRF, this is the setID used in the definition. Otherwise, the content is undefined.
|-
|8..9||0 - the tile uses original TTD graphics

1 - the tile is defined in the current GRF

2 - the tile is defined in another GRF
|-
|10||set if the selected tile belongs to the current station, clear otherwise
|-
|11||clear if the selected tile is parallel with the current one, set if perpendicular to it
|-
|12..13||0 - plain platform

1 - platform with building

2 - platform with roof, left side

3 - platform with roof, right side
|-
|14..31||Undefined, reserved for future use
|}

=== GRFID of nearby station tile (6A) ===

The parameter of this variable works the same way as the parameter of variable 66.
The returned value is one of the following:
* '''FFFFFFFFh''' if the selected tile isn't a station tile
* '''00000000h''' if the selected station is a default station (no NewGRF station)
* otherwise, the GRFID of the GRF which defined the type of the selected station

==Example==

VariationalAction2/Stations

2025-02-02T19:22:53Z

Ahyangyi:

==Introduction==

Rail stations share a number of variables with airports. The common variables are documented on a [[VariationalAction2/BaseStation|separate page]]

== Variables ==
{| |-
!Variable!!Version!![[GRFActionsDetailed|'''Size''']]!!Description
|-
|10||{{ottdp|0.7|2.5}}||D||Additional information for sprite selection - see [[Action0/Stations#General_Flags_.2813.29|General station flags]] and [[AdvancedSpriteLayout]]
|-
|40||{{ottdp|0.6|2.5}}||D||Platform info and relative position
|-
|41||{{ottdp|0.6|2.5}}||D||Platform info and relative position for individually built sections
|-
|42||{{ottdp|0.6|2.5}}||D||Terrain and track type
|-
|43 <ref>{{ottdp|1.2|2.5|ottdrev=r22848|ttdprev=2.5 beta 2}} Available in the purchase list as well.</ref>||{{ottdp|1.2|2.5|ottdrev=r22848}}||D||Player info, see [[VarAction2Vehicles#Player info (43)|vehicle variable 43]]
|-
|44||{{ottdp|0.7|2.5}}||B||Path-based signalling info
|-
|45||{{ottdp|0.6|2.5}}||W||Rail continuation info
|-
|46,47||{{ottdp|0.6|2.5}}||D||Platform info, counted from the middle
|-
|48|| || ||See [[VariationalAction2/BaseStation|Base Stations]].
|-
|49||{{ottdp|0.6|2.5}}||D||Platform info and relative position of same-direction section
|-
|4A||{{ottdp|0.7|2.5}}||B||Current animation frame
|-
|60-65|| || ||See [[VariationalAction2/BaseStation|Base Stations]].
|-
|66||{{ottdp|0.6|2.5}}||D||Animation frame of nearby tile
|-
|67||{{ottdp|0.6|2.6}}||D||Land info of nearby tiles
|-
|68||{{ottdp|0.6|2.6}}||D||Station info of nearby tiles
|-
|69|| || ||See [[VariationalAction2/BaseStation|Base Stations]].
|-
|6A||{{ottdp|1.10|no|ottdrev=5df01bf}}||D||GRFID of nearby tiles
|-
|6B||{{ottdp|14.0|no|ottdrev=8d62a8f}}||D||16-bit road stop ID of nearby tiles
|-
|80||{{ottdp|no|no}} <ref>Works in TTDPatch for sufficiently small stations.</ref>||B||Number and length of train platforms
|}
<references/>

For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_StationArray TTD station structure]. Note that you have to subtract 0x10 from the offsets there, or else the facility bit mask and construction date would not be accessible; instead you lose access to variables 00..0F which are meaningless anyway.

'''WARNING''': Please do not use variables 8C..EB directly. The meaning of these variables changes if the newcargos switch is on. Use the variables 60..64 instead (see below). Those always work correctly.

== Description ==
=== Platform info (40, 41, 46, 47, 49) ===

Variables 40, 41, 46, 47 and 49 all return information about the current tile, which platform it is on and how far along the platform. The difference is in the section of the station that they consider.

{| |-
!Variables!!Regular station!!Irregular station
|-
|40, 46||Whole station||Counting entire length and all adjacent platforms
|-
|41, 47||Individually built sections||
|-
|49||Whole station||Counting length and platforms that have the same direction
|}

The term "counting" here refers to starting at the tile in question, and counting tiles in all four directions. The two directions aligned with the station direction will be the length of the station, and the other two directions give the number of platforms. For variables 40 and 46, this counting stops at the edge of the station, i.e. the first non-station tile. For variable 49, it stops either at the edge, or at a station tile that is in the wrong direction.  The resulting information is probably not really useful in the case of irregular stations, with the exception of edge detection. To correctly detect edges, you have the choice of either the station->non-station transition (vars. 40, 46), or additional an opposite-direction transition (var. 49).

Variable 41 is largely unaffected by irregular stations, because it only refers to individually built sections. However, when these individual sections are built over existing tiles, the var. 41 information of surrounding tiles changes as well, due to an internal limitation in how it is stored.

For variables 40, 41 and 49, the position is counted from the northern most edge of the station, and returned in the form TNLcCpP, where:

{| |-
!Variable!!Bits!!Meaning
|-
|T||8||Tile type: the current tile type/layout
{{ottdp|no|}} In TTDPatch this information is only available during callback 14 (and via variable 10 during callback 24).
|-
|N||4||Total number of platforms
|-
|L||4||Total platform length
|-
|c||4||Platform number current being drawn, counted from the end (starting at zero)
|-
|C||4||Platform number currently being drawn (starting from zero)
|-
|p||4||Position along this platform counted from the end, zero at the end
|-
|P||4||Position along this platform, zero at the beginning
|}

Here, the "beginning" of a station is its northern-most (up on the screen) tile, and the "end" is the southern-most (down on the screen) tile. Each variable consists of 4 bits.

For variables 46 and 47, the position is counted from the middle, i.e. the center tile has C=0 and P=0. For even lengths and numbers of platforms, the middle tile is at position L/2 resp. N/2, e.g. for length 6, it is tile 3, which is the fourth tile. The return format is xTNLxxCP, where T, N and L are as above, and C and P are the positions counted from the middle.

Since C and P can have negative numbers, here's how this is encoded:

{| |-
!Hex!!Binary!!Decimal
|-
|0||0000||0
|-
|1||0001||1
|-
|7||0111||7
|-
|8||1000||-8
|-
|9||1001||-7
|-
|E||1110||-2
|-
|F||1111||-1
|}

The counting goes like this, preferring an extra negative number for an even count (because there are 8 negative numbers available but only 7 positive ones):

{| |-
!Count!!Numbers
|-
|1||<pre> 0</pre>
|-
|2||<pre> -1 0</pre>
|-
|3||<pre> -1 0 1</pre>
|-
|4||<pre> -2 -1 0 1</pre>
|-
|5||<pre> -2 -1 0 1 2</pre>
|-
|6||<pre>-3 -2 -1 0 1 2</pre>
|}

(etc.)

=== Terrain and track type (42) ===

Variable 42 is of the format xxxxttTT, where TT is the terrain type and tt is the (translated) railway track type.

They can have the following values:

{| |-
!TT!!Meaning
|-
|0||normal (grass)
|-
|1||desert
|-
|2||rainforest
|-
|4||on or above snowline
|}

If no railtype translation table is present in the GRF, then the default translation table is used:
{| |-
!tt!!Meaning
|-
|00||railroad, regular
|-
|01||railroad, electrified
|-
|02||monorail
|-
|03||maglev
|}

If the railtype is not present in the table, then tt returns FF.

=== Path-based signalling info (44) ===

This returns the following value in bits 0-2: (bit 2 only available from alpha 47 and up)

{| |-
!State!!Value (binary)!!Value (decimal)
|-
|Reserved||111||7
|-
|Not reserved||100||4
|-
|No PBS||010||2
|}

At the moment, PBS on/off refers to the switch setting, in a future alpha version it will actually refer to whether the switch is on ''and'' the current block actually uses PBS.

The bits are defined this way to allow easy fallback to non-PBS cases. If you need graphics to show the "unreserved" state in non-PBS cases, use bit 0, but if you need the "reserved" state in non-PBS cases, use bit 1. To explicitly check whether PBS is active or not, use bit 2.

All other bits are reserved and must be masked out.

=== Rail continuation info (45) ===

This variable returns 16 bits of info whether the rail tracks continue in the eight tiles adjacent to the station tile.

{| |-
!Bit!!Value!!Set if rail continues in direction of...
|-
|0||01||+Length
|-
|1||02||-Length
|-
|2||04||+Platforms
|-
|3||08||-Platforms
|-
|4||10||+Length, +Platforms
|-
|5||20||-Length, +Platforms
|-
|6||40||+Length, -Platforms
|-
|7||80||-Length, -Platforms
|}

The following picture illustrates which bits represent which tile for the two possible station orientations:

[[File:station_var45.png]]

Bits 0 to 3 are set if there is track on the given tile, and it has a connection to the station tile. For bits 2, 3, the station of course has itself no connection to those tiles, but this doesn't matter for this variable. Bits 4 to 7 check connections to the neighbouring platform tile, i.e. bits 4 and 5 resp. 6 and 7 indicate a connection from that tile to tile 2 resp. 3. (This has changed again with 2.5 beta 4 r325.)

Bits 8..15 repeat the above, but are set if there are any train tracks on the tile and disregard whether the track is connected to the station or not entirely.

=== Animation frame of nearby tile (66) ===

(From TTDPatch 2.5 beta 5)

The parameter defines the offset relative to the current tile. Both nibbles are considered signed (that is, 8h=-8, 9h=-7, ...., Fh=-1, 0h=0, 1h=1, ..., 7h=7). The high nibble contains the amount to move sideways (between platforms), the low one is the amount to move along the platform. Negative offsets move northwards, positive ones southwards. If the selected tile is a rail station tile that belongs to the current station, its animation state is returned. Otherwise, FFFFFFFFh is returned.

=== Land info of nearby tiles (67) ===

This variable works like [[VarAction2IndustryTiles#Land_info_of_nearby_tiles_60_|industry tile variable 60]], except for three things:
* The offsets in the parameter are interpreted relatively to the alignment of the station, the same way as for variable 66
* The '''ss''' part is "mirrored" (bit 0 and 2 swapped) for the NW-SE orientation; this will allow you to handle analogous slopes of the two orientations without checking the orientation explicitly (since TTDPatch 2.6 r1693)
* Bit 0 of the '''bb''' part is undefined

=== Station info of nearby tiles (68) ===

The parameter of this variable works the same way as the parameter of variable 66. The returned value is FFFFFFFFh if the selected tile isn't a railway station tile. Otherwise, the returned value can be separated to the following parts:

{| |-
!Bits!!Meaning
|-
|0..7||If the tile is defined in the current GRF, this is the setID used in the definition. Otherwise, the content is undefined.
|-
|8..9||0 - the tile uses original TTD graphics

1 - the tile is defined in the current GRF

2 - the tile is defined in another GRF
|-
|10||set if the selected tile belongs to the current station, clear otherwise
|-
|11||clear if the selected tile is parallel with the current one, set if perpendicular to it
|-
|12..13||0 - plain platform

1 - platform with building

2 - platform with roof, left side

3 - platform with roof, right side
|-
|14..31||Undefined, reserved for future use
|}

=== GRFID of nearby station tile (6A) ===

The parameter of this variable works the same way as the parameter of variable 66.
The returned value is one of the following:
* '''FFFFFFFFh''' if the selected tile isn't a station tile
* '''00000000h''' if the selected station is a default station (no NewGRF station)
* otherwise, the GRFID of the GRF which defined the type of the selected station

==Example==

Action0/Stations

2024-04-01T10:16:45Z

Ahyangyi:

==Introduction==

Defining properties of new stations.

Unlike vehicles, the new stations have no equivalent in TTD. The IDs are therefore free to be chosen and will in fact be allocated automatically. In action 0, you only specify IDs relative to the set, i.e. the ID of the first station type is 00, the second station type is 01 and so on.

{{ttdp|}} In TTDPatch each game can only have 255 station IDs for all active grf files.

The only property you '''must''' set for each station ID is 08 (in addition to defining an [[Action3|action 3]] for it), anything else can be left at the default. It must be the first property you set for each station ID, because the station ID is actually undefined until it has been assigned a class through property 08. Also, all station IDs must get their classes in the right order, starting from ID 00 onwards.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||D||{{ottdp|0.6|2.5|ttdprev=alpha 19}}||Class ID, see below
|-
|09||V||{{ottdp|0.6|2.5|ttdprev=alpha 20}}||Sprite layout, see below
|-
|0A||B||{{ottdp|0.6|2.5|ttdprev=alpha 20}}||Copy sprite layout
|-
|0B||B||{{ottdp|0.6|2.5|ttdprev=alpha 22}}||Callback flags
|-
|0C||B||{{ottdp|0.6|2.5|ttdprev=alpha 22}}||Bit mask of disabled numbers of platforms
|-
|0D||B||{{ottdp|0.6|2.5|ttdprev=alpha 22}}||Bit mask of disabled platform lengths
|-
|0E||V||{{ottdp|0.6|2.5|ttdprev=alpha 22}}||Define custom layout, see below
|-
|0F||B||{{ottdp|0.6|2.5|ttdprev=alpha 22}}||Copy custom layout from stationid given by argument
|-
|10||W||{{ottdp|0.6|2.5|ttdprev=alpha 25}}||Little/lots threshold
|-
|11||B||{{ottdp|0.6|2.5|ttdprev=alpha 27}}||Pylon placement
|-
|12||D||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Bit mask of cargo type triggers for random sprites
|-
|13||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||General flags
|-
|14||B||{{ottdp|0.6|2.5|ttdprev=alpha 47}}||Overhead wire placement
|-
|15||B||{{ottdp|0.6|2.5|ttdprev=alpha 51}}||Can train enter tile
|-
|16||W||{{ottdp|0.7|2.5|ttdprev=beta 9}}||Animation information
|-
|17||B||{{ottdp|0.7|2.5|ttdprev=beta 9}}||Animation speed
|-
|18||W||{{ottdp|0.7|2.5|ttdprev=beta 9}}||Animation triggers
|-
|1A||V||{{ottdp|1.2|no|ottdrev=r22518}}||Advanced sprite layout with register modifiers
|}

Unofficial additions and changes. Don't rely on them to ever work this way in OpenTTD or TTDPatch:
{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|1B||8*B||whatever-PP||Minimum bridge height for bridges over stations
|}

== Description ==

=== Station class (08) ===
TTDPatch groups sets of new station graphics into various classes.  The classes can be selected by the top dropdown list in the construction window, and the individual stations within the class from the bottom dropdown list.  In addition, each station can alter its appearance using [[VariationalAction2|variational]] and/or [[RandomAction2|random]] action 2 entries.

Only two classes are pre-defined:

{| |-
!Name!!Class ID!!Intended use for station
|-
|DFLT||44 46 4C 54||Default, no special station type
|-
|WAYP||57 41 59 50||Non-cargo stations, waypoints, signal boxes etc.
|}

You may simply use other classes than the above, as long as no more than (at the moment) 16 classes are used among all active .grf files at any time.

When a WAYP station is built, it will not accept cargo nor will any cargo appear from nearby industries or towns.  Trains will not stop at WAYP stations, regardless of the non-stop order and/or the nonstop switch.

=== Sprite layout (09) ===
This controls what sprites are displayed, where they are displayed, and in what order.  The property is variable sized, and contains the data for all 8 possible station tile types.  If this property is set, the num-ent in the corresponding [[Action1|action 1]] need not be equal to 12 (hex), it can in fact be any number, and any number of sprites can be displayed in any order.

The data is specified as data for all eight tiles in this way:

<pre><num> <data1> <data2> ... <datan></pre>

{| |-
!Size!!Name!!Meaning
|-
|B*||num||Number of different tiles supported (see below)
|-
|V||data1...||The variable size data for each of the <num> tiles, as specified below
|}

===== Number of tiles supported =====
* Normally this is 8, but you can specify fewer as well
* Using callback flags bit 1, specifying more makes sense too
* This value must be the same for all stations set by this action 0, even though it must be repeated for the prop. 09 definition of each station ID as well

(Note that num is an extended byte, see [[GRFActionsDetailed]].)

The content of each of the (usually eight) data sets is either a new sprite layout:

{| |-
!Size!!Name!!Meaning
|-
|D||groundsprite||the sprite to draw for the rails; this is by default a TTD sprite, but with bit 31 set an [[Action1|action 1]] sprite (42D+X) may be specified
|-
|V||spritedata||the data for station sprites, see below; each has a size of 10 bytes, and there may be several
|-
|B||80||a literal 80 ends the list of sprites for this tile
|}
or, alternatively, the instruction to use TTD's layout by using four zero bytes 00 00 00 00 instead of the groundsprite bytes. You can use [http://www.bytetransfer.de/projects/ttdpatch/docs/spriteidmapping.php the online sprite ID converter] to look up the sprite IDs you can use for all the climates.

One can draw two types of sprites.  One type is one that establishes a new 3D bounding box for use by the sprite sorter.  The other type shares the 3D bounding box of the previous sprite(s).  It must not be larger than the sprite which established the bounding box, nor must any part of it be outside this box.  For simplicity, it should have the exact same dimensions as the sprite it shares the bounding box with.  The latter type is supported in the station construction window display only since TTDPatch 2.6 r1684.

The spritedata of sprites with their own bounding box has this format:

{| |-
!Size!!Name!!Meaning
|-
|B||xofs||x-offset from northern tile corner
|-
|B||yofs||y-offset from northern tile corner
|-
|B||zofs||z-offset from northern tile corner
|-
|B||xextent||size of sprite in x direction
|-
|B||yextent||size of sprite in y direction
|-
|B||zextent||size of sprite in z direction
|-
|D||sprite||sprite number to draw
|}

The spritedata of sprites sharing the bounding box has this format:

{| |-
!Size!!Name!!Meaning
|-
|B||xofs||x-offset relative to previous sprite
|-
|B||yofs||y-offset relative to previous sprite
|-
|B||80||a literal 80
|-
|B||00||(ignored)
|-
|B||00||(ignored)
|-
|B||00||(ignored)
|-
|D||sprite||sprite number to draw
|}

Since OpenTTD r18959 you can draw multiple ground sprites for a tile, which is useful if you want to use the usual rail/grass/concrete groundtile, but still need to add features to it without using a new bounding box. To do so use the syntax of sprites sharing the previous bounding box, but use it before the first bounding box definition. xpixeloffset and ypixeloffset refer to the usual spot of groundtiles. The same feature is also partially supported in TTDPatch since TTDPatch 2.6 r2312: TTDPatch ignores the xofs and yofs fields and always uses (0,0) for the offset. If you are developing a GRF that needs to be compatible with both OpenTTD and TTDPatch, you should always keep xofs and yofs zero to get the same effect in both games.
Note however that both implementations do not consider the [[Action0/Stations#General_Flags_.2813.29|setting of prop13 bit 0]], hence these "multiple ground sprites" have to be always part of the building sprites set and cannot be part of the different sprite set for ground sprites.

The sprite number can have the following values (remember to use little endian, i.e. reversed byte order):

{| |-
!Number!!Sprite
|-
|0000042D+X||use sprite X from the corresponding [[Action1|action 1]] block (i.e. 0000042D for the first, 0000042E for the second, etc.)
|-
|0000842D+X||same, but draw it using company colour translation
|-
|0322442D+X||same, but draw in transparent mode (actual colours of the sprite are disregarded entirely); supported in station construction window display since TTDPatch 2.6 r1683
|-
|RRRR842D+X||draw sprite with colour translation defined in sprite RRRR; available since TTDPatch 2.6 r1683
|}

With bit 31 set, this sprite will refer to a TTD sprite, not the action 1 sprite. For the first ground sprite the reverse meaning applies.

Depending on the railtype the sprites may get additional offsets:

{| |-
! !! Normal/electrified rail !! Monorail !! Maglev
|-
|TTD sprites || 0 || 82 || 164
|-
|Action 1 sprite (first ground sprite) || 0 || 1 || 2
|-
|Action 1 sprite (other sprites in the layout) || 0 || 0 || 0
|}

So, TTD sprites and the first ground sprite are affected by the railtype, while other action 1 sprites in the layout are not. The offset "82" refers to the offset between the default TTD track sprites; if you are using non-track ground sprites which are not from an action 1, you need to supply fake spritenumbers which preemptively reverse the offsets (that is, you need different sprite layouts for every railtype your station is available for).

Setting bit 30 forces this sprite to be displayed normally even in "transparent buildings" mode (supported only in TTDPatch 2.6 r1695 and later).

See below for an example of linked sprites as well as transparent sprites (e.g. for a station roof).

Note that the coordinates here are 3D coordinates with x running from top-right to bottom-left and y running from top-left to bottom-right, with the tile dimensions being 16x16 (and 8 for one height level). This means the x and y values should always be within 0-15 (decimal).

This is different to and independent from the x/y offsets used in the actual .NFO file.  The 3D bounding box is used by TTD's sprite sorter to figure out the order in which to draw the sprites, as well as telling it which sprites to draw, because those whose bounding box falls outside the currently updated screen rectangle will not be drawn.  Make sure the 3D bounding box is large enough to contain the entire sprite, but not so large that the sprite sorter can't determine which sprites should be in front.

This means that the order in which you specify sprites is irrelevant.  Sprites will get drawn from back to front, in the order which the sprite sorter determines as correct, from their bounding boxes.  There are two exceptions, however:
* Sprites sharing the same bounding box will always be drawn in the given order.
* The station construction window display doesn't use the sprite sorter. Tiles that may be displayed in that window need to be specified in the correct drawing order, back to front.

=== Copy sprite layout (0A) ===

This is not a property as such, but an action.  It takes as argument a byte which is interpreted as station-ID to copy the custom sprite layout from.

=== Callback flags (0B) ===
For stations, the following [[callbacks]] can be defined by setting the corresponding bit in property 0B:

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|0||1||13||Whether to make station available in construction window (non-zero callback return) or not (callback returns zero)
|-
|1||2||14||Use callback to select sprite layout
|-
|2||4||141||Decide next animation frame
|-
|3||8||142||Decide animation speed
|-
|4||10||149||Custom slope check
|}
Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the [[VariationalAction2|VarAction2]] for callbacks.

=== Selection of numbers of platforms and length (0C, 0D) ===

By default all platform lengths and any number of platforms is available for the new stations.  Using these properties, you can choose which ones should be unavailable by setting the corresponding bit in the property.

The values are a byte, used as a bit mask.  Bits 0 to 6 control the availability of number or length 1 to 7, and bit 7 controls the availability of the "+7" button.  Each bit that is set disables the corresponding length or number of platforms.

For compatibility with "largestations off", at least one length between 1 and 5 (bits 0 to 4) and one number of platforms between 1 and 4 (bits 0 to 3) must be available, i.e. at least one of these bits must be unset.

=== Define custom layout (0E) ===

This allows choosing which tile type is built at which tile of a newly built

station.  There are four different types, which TTD normally defines as

{| |-
!Tile type!!Appearance
|-
|00||plain platform
|-
|02||platform with building
|-
|04||platform with roof, left side
|-
|06||platform with roof, right side
|}

These numbers are used for stations in NE-SW direction, or these numbers plus one for stations in the NW-SE direction.  To define a custom layout, use this format:

{| |-
!Size!!Name!!Meaning
|-
|B||length||length of platforms for this layout
|-
|B||number||number of platforms for this layout
|-
|V||tiles||length*number bytes of tile types, one platform after another, only 00, 02, 04 or 06 are allowed as values
|}

Repeat this as often as necessary to define the layouts for all supported combinations of length and number.  End the definitions with a 00 00 (zero length and zero number).  Any combinations that are not defined will be built using TTD's default layout.
Note that it may be easier to draw different sprite sets using a [[VariationalAction2|VarAction2]] based on [[VarAction2Stations#Platform info 40 41 46 47 49|station variable 40]], rather than redefining the layout.  In addition, [[Callbacks#Custom station layout 24|callback 24]] will be used to further customize the layout as defined by this property (or by TTD if no prop 0E layout is available). This may also be easier than defining a prop 0E layout for every combination of length and number of platforms.

=== Copy custom layout (0F) ===

Similar to property 0A, this copies the custom layout from the station-ID given by the argument.

=== Little/lots threshold (10) ===
Amount of cargo for switching from "little" to "lots" of cargo.  TTDPatch separates the full range of cargo amounts (0 to 4095) into two separate subranges, "little" and "lots" of cargo.  This allows better control of cargo amount based graphics (if needed).  Property 10 specifies at what amount of cargo the patch is to switch from one to the other subrange.  See [[Action2Stations|Action 2 for stations]] for more information.

=== Pylon placement (11) and wire placement (14) ===
Prop. 11 sets which tile types should have pylons when used with electrified tracks. By default, tiles 0-3 (default stations without roof) have pylons, and tiles 4-7 (default stations with roof) don't. This is a bit mask of tile types, with a bit set meaning that a pylon should be drawn. The tile types here do not consider [[Callbacks#Station sprite layout 14|callback 14]], but rather the type as it was built, i.e. from prop. 0E.

Prop. 14 works in a similar way, except that it sets the tile types on which there should be ''no'' wires displayed. With the default value of "00", wires are displayed everywhere, and for each bit set, the wire is omitted on that tile type.

This property should only be used when the wires cause problems with the sprite sorter, because even when the wire is obscured by a station hall or similar, it should still show up in transparent mode so that each tile can easily be verified as being electrified.

=== Cargo types for random triggers (12) ===

This sets which cargo types should trigger re-randomizing. The cargo types are given as a bitmask of the bits from column 3 (type B) in CargoTypes.  If nothing is set (the default), the no random triggers will happen, to conserve CPU time.

With GRF version 7 and above, the interpretation of bits changes. Instead of climate-dependent cargo slot numbers (type B), you have to set the bits of climate-independent cargo ID (type A).

=== General Flags (13) ===

{| |-
!Bit!!Value!!Version!!Meaning
|-
|0||1||{{ottdp|0.7|2.5}}||use different sprite set for ground sprites ([[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|var. 10]] is 1 for ground sprites, 0 otherwise)
|-
|1||2||{{ottdp|0.6|2.5}}||when calculating the cargo amount to display, divide the amount by the station size (to simulate cargo distributed over the area of the station)
|-
|2||4||{{ottdp|0.7|2.5}}||[[Callbacks#Next animation frame (1A/26/141/153/158)|callback 141]] needs random bits in var. 10
|-
|3||8||{{ottdp|1.0|2.6}}||Use custom foundations on sloped tiles (the lowest byte of [[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|var. 10]] is 2 for foundation sprites)
|-
|4||10||{{ottdp|1.0|2.6}}||When bit 3 is set, use extended foundation block instead of the simple one
|}

Bit 3 works somewhat similarly to bit 0: your sprite selection will be called again, with 2 in the lowest byte of [[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|variable 10]]. If the chain ends on a callback result, the program will assume the foundation selection has failed and will use the default foundaton sprites. The low word of [[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|variable 18]] will contain the tile type of the current tile; if you have [[Callbacks#Station sprite layout (14)|callback 14]] enabled, this will be the its return value - otherwise, the default TTD types (platform with building, platform with left roof etc.) are used. In either case, one is added for the NW-SE orientation, in case your station needs different foundations depending on its orientation. Bits 16 and 17 are set if the NW and and NE foundations are to merged with the corresponding neighbour tile, so you shouldn't draw the corresponding edge in the foundation sprite. Other bits of variable 10 and variable 18 are reserved for future use.

Your sprite selection code should select a foundation sprite block. The contents of this block depends on whether bit 4 is set or not.
* Bit 4 clear (simple foundations):
[[File:simple_foundations.png]]

The programme will combine the needed foundation from these 8 sprites depending on the current slope. You don't need to care about the merge data in bits 16..17 of [[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|variable 18]]; it will be taken care of that automatically by adding the 7th and 8th sprite only when necessary.
* Bit 4 set (extended foundations):
[[File:extended_foundations.png]]

You need to have one sprite for every slope that's possible below a rail station. The correct one will be automatically selected depending on the current slope. It can't handle the merging itself, however, so you need four foundation blocks: one with no edges removed, one with the NW edge removed, one with the NE edge removed and one with both north edges removed. Your sprite selection code is responsible for selecting the correct of those blocks according to the merge info in [[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|variable 18]].

In both cases, you can put an additional value into register 100h, which will serve as an offset into the selected block. If you don't modify register 100h during the chain, it will default to 0. It is important that the dimensions of these sprites remain the same - thus bit 6 in the real sprites must be set to prevent GRFCodec from trimming the empty blue areas. The offset of these foundations must be -31 to the X direction and -9 to the Y direction.

=== Can train enter tile (15) ===

Like props. 11 and 14, this value contains eight bits relating to the eight possible tile types. If a bit is set, trains are prevented from routing through or entering any tile of this type.

=== Animation information (16) ===

The low byte specifies the number of animation frames minus one, so 00 means 1 frame, 01 means 2 frames etc. The maximum number of frames is 256, although you can have some problems if your animation exceeds FD (253) frames. The high byte must be 0 for non-looping animations and 01 for looping animations. Every other value is reserved for future use. In addition, if the whole word contains FFFF, animation is turned off for this station (this is the default value).
Since you can't have properties for individual station tiles, this property applies for every tile of the station. If you don't want to animate some tiles, you should check the current position during [[Callbacks#Animation control (1B/25/140/152/159)|callback 140]] and return FD if the current tile doesn't need to be animated. If you also need animations of different length per tile, you'll have to use [[Callbacks#Next animation frame (1A/26/141/153/158)|callback 141]] for that.

=== Animation speed (17) ===
The meaning is the same as for [[Action0Houses#Animation Speed 1B|house property 1B]], but the lower limit is 0 instead of 2, so the fastest possible animation changes frames every game tick (27ms). The default value is 2.

=== Animation triggers (18) ===
This is a bit mask of events that should trigger [[Callbacks#Animation control (1B/25/140/152/159)|callback 140]], allowing to change the animation state

{| |-
!Bit!!Value!!Version!!Meaning!!Happens on!!Var 18
|-
|0||1||{{ottdp|0.7|2.5}}||Station part is built||the newly built tiles||
|-
|1||2||{{ottdp|0.7|2.5}}||New cargo arrives to station||whole station||<ref name="cargotype">Bits 8..15 of var 18 contain the triggering cargo type. If your GRF has a cargo translation table, the cargo type will be an index in that table, or FFh if the cargo isn't in the table. If you don't have a cargo translation table, the cargo type will simply be the climate-dependent cargo type number.</ref>
|-
|2||4||{{ottdp|0.7|2.5}}||A cargo type gets removed from station||whole station||<ref name="cargotype"/>
|-
|3||8||{{ottdp|0.7|2.5}}||Train enters station (starts loading/unloading)||platform where the train is||
|-
|4||10||{{ottdp|0.7|2.5}}||Train leaves station (done loading/unloading)||platform where the train is||
|-
|5||20||{{ottdp|1.2|2.5|ottdrev=r22746}}||Train loads/unloads cargo||platform where the train is||
|-
|6||40||{{ottdp|0.7|2.5}}||Every 250 ticks||whole station||
|}

The remaining bits are reserved for future triggers, they must be zero for now.

The "happens on" column tells which tiles will [[Callbacks#Animation control (1B/25/140/152/159) |callback 140]] be called on.

<references/>

=== Advanced sprite layout with register modifiers (1A) ===

{{ottdp|1.2|no|ottdrev=r22518}}
Format:
1A <num-layouts> <0x40 + num-sprites>
<groundsprite> <flags> [<register/value>]...
[ <buildingsprite> <flags>
( <xoffset> <yoffset> <zoffset> <xextent> <yextent> <zextent>
| <xpixeloffset> <ypixeloffset> 80)
[<register/value>]...
]...

For further details see [https://wiki.openttd.org/en/Archive/Development/Advanced%20Sprite%20Layout#stations here] for now.

=== Minimum bridge height (1B) ===

This property allows building bridges over stations.

The bridge height property defines minimum clearances required for a bridge for each of the four [[Action0/Stations#Define_custom_layout_.280E.29|tile types]] of this station (or zero to not allow any bridge). Values are given in "height level" units (1 level == 8px).

{| class="wikitable" |-
!Height (1)!!Appearance
|-
| style="text-align:center;" |x1 y1 ||plain platform
|-
| style="text-align:center;" |x2 y2 ||platform with building
|-
| style="text-align:center;" |x3 y3 ||platform with roof, left side
|-
| style="text-align:center;" |x4 y4 ||platform with roof, right side
|}
(1) where the values are one byte pairs (x-direction, y-direction) expressed in hexadecimal notation.

Syntax:

1B <1st pair> <2nd pair> <3rd pair> <4th pair><br />
1B x1 y1 x2 y2 x3 y3 x4 y4<br />
1B 01 01 02 02 03 03 03 03 // 8px 16px 24px 24px

This property is currently only available for JGR's Patch Pack (v0.26.0 and later) and the developmental "New Map Features" (NMF) fork of OpenTTD.

=== Station name (1C) ===

=== Station class name (1D) ===

== Examples ==

=== Using TTD's sprite layouts for certain tiles ===

To use TTD's layout, you use <code>00 00 00 00</code> for the ground sprite number and leave off everything else.

So instead of for example

F4 03 00 00
00 00 00 10 05 02 2E 84 00 00
00 0B 00 10 05 02 30 84 00 00
80

you just put

00 00 00 00

=== Using transparent sprites ===

You can use transparent sprites to make for example the roof translucent like in TTD's stations. The roof of TTD's stations is made like this:

00 00 10 10 10 0A 37 84 00 00
00 00 80 00 00 00 3B 44 22 03

The first sprite here is the non-transparent frame of the roof, drawn in company colours (it has bit 15 set). The second part is a special "linked" sprite without its own bounding box, it shares that of the previous sprite. That's done by setting the z offset to 80.

To make that second sprite transparent, bit 14 is set in the sprite number, and the upper word is set to 322 (*), so 0322443B means to take sprite 43B and draw it in transparent mode. The colours of that sprite are ignored entirely, every pixel in colour 0 is fully transparent, and all other pixels are semi-transparent (essentially just causing what they are drawn over to become darker).

(*) This is the [[RecolorSprites#Default_recolour_sprites | recolour sprite]] for the glass effect.