Additions to NewGRF Specifications in JGR's Patchpack

This document describes non-standard additions to the Official OpenTTD NewGRF Specifications which are present in this patchpack.

These additions MAY also be present in other patchpacks. They MAY be removed or moved in future, if necessary.

A subset of the features listed below are also supported in a fork of NML, see the associated NML document for more details.

NewGRFs which use any of these features SHOULD use the feature testing mechanism described below to check whether individual added features are supported.

Features with separate pages

• Road stops
• New landscape (custom graphics)
• Towns (the parent scope for stations, objects, etc.)

Sections

• Action 14 - Feature Tests
• Action 14 - Property Mapping for Action 0
• Action 0 - Stations
• Action 0 - Bridges
• Action 0 - Railtypes
• Action 0 - Roadtypes
• Action 0 - Global Settings
• Action 0 - Signals (Feature 0E)
• Action 0 - Objects
• Action 14 - Variable Mapping for Variational Action 2
• Variational Action 2 - Additional Types
• Variational Action 2 - Vehicles
• Variational Action 2 - Stations
• Variational Action 2 - Railtypes
• Variational Action 2 - Objects
• Variational Action 2 - Airport tiles
• Variational Action 2 - Signals (Feature 0E)
• Callbacks - Ships
• Action 3 - Objects
• Action 3 - Signals (Feature 0E)
• Action 14 - Type ID Mapping for Action 5
• Action 14 - Feature ID Mapping

Action 14 - Feature Tests

See Action 14 Specification for background information.

Feature Test: C "FTST"

Each FTST chunk (type C) describes an individual feature test.
Sub-chunks within each FTST chunk may appear in any order, however each sub-chunk SHOULD only appear ONCE within an individual FTST chunk.

Feature tests can be safely used on implementations which do not implement the described feature test mechanism because unknown Action 14 blocks are ignored, and the observable result (in global variable 0x9D) is equivalent to the case where all feature tests have failed, indicating that the feature is not present.

Feature Name: C "FTST" -> T "NAME"

Within an FTST chunk, the NAME text (type T) field contains the name of the feature to test for. The value of the language ID byte is ignored.
If the named feature is not present, or if this field is omitted, the version is 0.
If the named feature is present, the version number will be at least 1.

The feature testing mechanism itself has the feature name: feature_test, this document describes version 1.

Feature Minimum Version: C "FTST" -> B "MINV"

Within an FTST chunk, the MINV binary (type B) field contains the minimum (inclusive) (≥) version to accept. This is a Word (2 bytes).
The default value is 1.

Feature Maximum Version: C "FTST" -> B "MAXV"

Within an FTST chunk, the MAXV binary (type B) field contains the maximum (inclusive) (≤) version to accept. This is a Word (2 bytes).
The default value is 0xFFFF (no maximum).

Feature Set Global Variable 0x9D Bit: C "FTST" -> B "SETP"

Within an FTST chunk, the SETP binary (type B) field contains the bit number to set/clear in global variable 0x9D (TTD Platform) to store the result of the test. This is 1 byte.
If the test is successful, the bit is set (to 1), otherwise the bit is cleared (to 0).
The bit number MUST be in the range: 4 ≤ bit number ≤ 31. These bits can be assumed to be 0 on implementations which do not support this feature test mechanism.
Global variable 0x9D can then be tested by using a standard Action 7 or 9, or a standard Variational Action 2.
If this field is omitted, no bit is set or cleared, and the test is not observable (unless the SVAL chunk is used).

Feature Set Global Variable 0x91 Success Test Value: C "FTST" -> B "SVAL"

Within an FTST chunk, the SVAL binary (type B) field contains a 32 bit value which can be tested using the mechanism below. This is 4 bytes.
If the test is successful, the value is added to a list of successful result values which can be checked using the mechanism below.
If the test is unsuccessful, no action is taken.
The value must be > 0, a value of 0 has no effect.

To check if the test succeeded (the value has been added to the list of successful result values), use Action 7 or 9.
The parameter to test is global variable 0x91 (this always has a value of 0, equivalent to the case where the test has failed, if this feature test mechanism is not present).
The condition-type to use is: 02 (\7=, equality) to jump if the value is in the list (the test succeeded), or 03 (\7!, inequality) to jump if the value is not in the list (the test did not succeed).
The value in the Action 7 or 9 must match the value specified in this SVAL chunk.

If this field is omitted, the test is not observable (unless the SETP chunk is used).

This chunk and the associated test mechanism requires the feature name: feature_test, version 2.
Using this chunk instead or as well as SETP allows observing the result of more than 28 feature tests.

Example NFO:

// Set bit 4 of global variable 0x9D if sample_feature_1 is present with a version of at least 4
// Set bit 5 of global variable 0x9D if sample_feature_2 is present with a version of at least 5 and at most 6
-1 * -1 14
	"C" "FTST"
		"T" "NAME" 00 "sample_feature_1" 00
		"B" "MINV" \w2 \w4
		"B" "SETP" \w1 04
		00
	"C" "FTST"
		"T" "NAME" 00 "sample_feature_2" 00
		"B" "MINV" \w2 \w5
		"B" "MAXV" \w2 \w6
		"B" "SETP" \w1 05
		00
	00
....
// Skip 1 sprite if bit 4 of global variable 0x9D is not set (indicating that sample_feature_1 with a version of at least 4 is NOT present)
-1 * -1  07 9D 01 \70 04 01
	

Action 14 - Property Mapping for Action 0

See Action 14 Specification and Action 0 Specification for background information.

The property mapping mechanism has the feature name: property_mapping, this document describes version 1.

Users of this mechanism SHOULD at minimum test for the presence of the feature above or test variable 8D, below.

Property Mapping: C "A0PM"

Each A0PM chunk (type C) describes an individual property mapping.
Sub-chunks within each A0PM chunk may appear in any order, however except where otherwise noted each sub-chunk SHOULD only appear ONCE within an individual A0PM chunk.

Property mapping can be safely used on implementations which do not implement the property mapping mechanism if Action 0 sprites which use mapped property IDs are skipped if one or more of:

• The global variable 0x8D is checked to determine whether the property mapping operation was successful.
• The feature name property_mapping is checked for.

Property Name: C "A0PM" -> T "NAME"

Within an A0PM chunk, the NAME text (type T) field contains the name of the property to map. The value of the language ID byte is ignored.

Action 0 Feature ID: C "A0PM" -> B "FEAT"

Within an A0PM chunk, the FEAT binary (type B) field contains the Action 0 feature ID. This is 1 byte.

Property ID: C "A0PM" -> B "PROP"

Within an A0PM chunk, the PROP binary (type B) field contains the property ID to allocate to the named property, this value can used in Action 0 sprites. This is 1 byte.
It is possible to override existing properties, however this use is not recommended.

Success Indicator Global Variable 0x8D Bit: C "A0PM" -> B "SETT"

Within an A0PM chunk, the SETT binary (type B) field contains the bit number to set/clear in global variable 0x8D (TTD version) to store whether the mapping operation was successful. This is 1 byte.
If the operation is successful, the bit is set (to 1), otherwise the bit is cleared (to 0).
The bit number MUST be in the range: 4 ≤ bit number ≤ 31. These bits can be assumed to be 0 on implementations which do not support this property mapping mechanism.
Global variable 0x8D can then be tested by using a standard Action 7 or 9, or a standard Variational Action 2.
If this field is omitted, no bit is set or cleared.

Success Indicator Global Variable 0x91 Test Value: C "A0PM" -> B "SVAL"

This behaves identically to the C "FTST" -> B "SVAL" case, above

This chunk and the associated test mechanism requires the feature name: property_mapping, version 2.

Fallback Mode: C "A0PM" -> B "FLBK"

Within an A0PM chunk, the FLBK binary (type B) field contains the fallback mode. This is 1 byte.
The fallback mode may take the following values:

Format of remapped properties

Example NFO:

// Map station property "sample_station_property" to property id 0xF8, and set bit 4 of global variable 0x8D if successful
-1 * -1 14
	"C" "A0PM"
		"T" "NAME" 00 "sample_station_property" 00
		"B" "FEAT" \w1 04
		"B" "PROP" \w1 F8
		"B" "SETT" \w1 4
		00
	00
....
// Skip 1 sprite if bit 4 of global variable 0x8D is not set (indicating that station property sample_station_property is NOT present)
-1 * -1  07 8D 01 \70 04 01
// Set sample_station_property for station ID 10 to 2 byte value: AB CD
-1 * -1  00 04 01 01 10 F8 02 AB CD
	

Action 0 - Stations

Minimum bridge height (1B, or mappable property: station_min_bridge_height)

This property allows building bridges over stations.
The bridge height property defines minimum clearances required for a bridge for each of the 8 station layouts (or 0 to not allow any bridge). Values are given in height level units (1 level == 8px).
Each height value is 1 byte, the total property length is 8 bytes.

This is indicated by the feature name: action0_station_prop1B, version 1

Disallowed bridge pillars (mappable property: station_disallowed_bridge_pillars)

This property describes which bridge pillars are not allowed on the station tile.
It consists of 8 pillar flags, for each of the 8 station layouts.
Each set of flags is 1 byte, the total property length is 8 bytes.
Each set of flags has the format described in the bridge_pillar_flags property section, below.

This is indicated by the feature name: action0_station_disallowed_bridge_pillars, version 1

Action 0 - Bridges

Menu icons (14, or mappable property: bridge_menu_icon)

This property sets the GUI menu icon for bridge type, this is displayed when constructing a bridge
This has the format:

This is indicated by the feature name: action0_bridge_prop14, version 1

Bridge pillars (mappable property: bridge_pillar_flags)

This property describes the pillars present for each bridge sprite table.
It consists of 6 pairs of pillar flags, for bridge sprite tables 0 - 5.
Each pair consists of: X direction flags, Y direction flags
Each set of flags is 1 byte, the total property length is 12 bytes.
Each set of flags has the format:

This is indicated by the feature name: action0_bridge_pillar_flags, version 1

Bridge availability flags (mappable property: bridge_availability_flags)

This property sets the availability flags for this bridge type.
The property length is 1 byte. The format is:

This is indicated by the feature name: action0_bridge_availability_flags, version 1

More bridges (16 instead of 13)

This is indicated by the feature name: more_bridge_types, version 1

Action 0 - Railtypes

Enable custom signal sprites for programmable pre-signals (mappable property: railtype_enable_programmable_signals)

This enables Action 2/3 - Railtype custom signal sprites for programmable pre-signals.
Programmable pre-signals have the signal type value: 06.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_railtype_programmable_signals, version 1

Enable custom signal sprites for no-entry signals (mappable property: railtype_enable_no_entry_signals)

This enables Action 2/3 - Railtype custom signal sprites for no-entry signals.
No-entry signals have the signal type value: 07.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_railtype_no_entry_signals, version 1

Enable restricted signal flag for custom signal sprites (mappable property: railtype_enable_restricted_signals)

This applies to Action 2/3 - Railtype custom signal sprites.
When enabled, bit 24 of variable 18 (extra callback info) is set if the signal is restricted (has a routing restriction program attached).
When enabled, the "Show restricted electric signals using default graphics" client setting and signal post recolouring is not applied.
This flag should only be set if the Action 2/3 actually returns a different sprite when bit 24 of variable 18 is set.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.

See also: railtype_signal_restriction_info variable

This is indicated by the feature name: action0_railtype_restricted_signals, version 1

Enable recolouring for custom signal sprites (mappable property: railtype_enable_signal_recolour)

This applies to Action 2/3 - Railtype custom signal sprites.
When enabled, in addition to returning a sprite, register 0x100 may be set to the following:

The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_railtype_recolour, version 1

Set number of additional signal aspects (mappable property: railtype_extra_aspects)

This applies to Action 2/3 - Railtype custom signal sprites.
The value is the number of additional signal aspects to use (e.g. 4-aspect signalling should use a value of 2).
When set, the lowest byte of variable 0x18 (SS: signal state) may have the given number of additional values starting from 02:

The property length is 1 byte.
The provided value is currently clamped to be within the range 0 - 6 (inclusive).

N.B. Realistic braking must be enabled for additional signal aspects to be used.

This is indicated by the feature name: action0_railtype_extra_aspects, version 1

Disable use of realistic braking with this rail type (mappable property: railtype_disable_realistic_braking)

When this property is set realistic braking is disabled for trains of this railtype even when realistic braking is otherwise in effect.
The property length is 1 byte. 0 is realistic braking is not disabled for this railtype. 1 is disable realistic braking for this railtype.

This is indicated by the feature name: action0_railtype_disable_realistic_braking, version 1

Action 0 - Roadtypes and Action 0 - Tramtypes

Extra road/tram type flags (mappable property: roadtype_extra_flags)

This property sets the extra flags for this road/tram type.
The property length is 1 byte. The format is:

This is indicated by the feature name: action0_roadtype_extra_flags, version 1

Road vehicle collision mode (mappable property: roadtype_collision_mode)

This property sets the road vehicle collision mode for road vehicles of this road/tram type.
The property length is 1 byte. The format is:

This is indicated by the feature name: action0_roadtype_collision_mode, version 1

Action 0 - Global Settings

Extra station names (mappable property: global_extra_station_names)

This adds extra station names for use when all the available station names for a given town have been used.
The string should have the same format and use the same ID range as industry - default name for nearby station.
The Action 0 ID field is ignored. This property always adds a new station name string instead of overwriting an existing one.
The property length is 4 bytes. The format is:

This is indicated by the feature name: action0_global_extra_station_names, version 1

Extra station names probability (mappable property: global_extra_station_names_probability)

This sets the probability of using an extra station name even when the available default names have not been exhausted.
The range is 0 - 255, where 0 is never (the default) and 255 is always.
Some station names are always used first even when this is non-zero.
The Action 0 ID field is ignored.
The property length is 1 bytes.

This is indicated by the feature name: action0_global_extra_station_names, version 2

Lighthouse object map generation amount (mappable property: global_lighthouse_generate_amount)

This sets the map generation amount value for the lighthouse default object (0 is no generation, 255 is maximum).
The Action 0 ID field is ignored. The property length is 1 byte.

This is indicated by the feature name: action0_global_default_object_generate_amount, version 1

Transmitter object map generation amount (mappable property: global_transmitter_generate_amount)

This sets the map generation amount value for the transmitter default object (0 is no generation, 255 is maximum).
The Action 0 ID field is ignored. The property length is 1 byte.

This is indicated by the feature name: action0_global_default_object_generate_amount, version 1

Allow rocky tiles in desert zones (tropical climate) (mappable property: global_allow_rocks_in_desert)

This sets whether rocky tiles are allowed to generate in and remain in desert zones (tropical climate).
The Action 0 ID field is ignored. The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_global_allow_rocks_in_desert, version 1

Action 0 - Signals (Feature 0E)

Note that Action 0 feature 0E is not supported (does nothing) in standard OpenTTD.

This implementation of feature 0E is not the same as that in TTDPatch.

Enable custom signal sprites for programmable pre-signals (mappable property: signals_enable_programmable_signals)

This enables Action 2/3 Signals (Feature 0E) custom signal sprites for programmable pre-signals for this GRF.
Programmable pre-signals have the signal type value: 06.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_programmable_signals, version 1

Enable custom signal sprites for no-entry signals (mappable property: signals_enable_no_entry_signals)

This enables Action 2/3 Signals (Feature 0E) custom signal sprites for no-entry signals for this GRF.
No-entry signals have the signal type value: 07.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_signals_no_entry_signals, version 1

Enable restricted signal flag for custom signal sprites (mappable property: signals_enable_restricted_signals)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites for this GRF.
When enabled, bit 24 of variable 18 (extra callback info) is set if the signal is restricted (has a routing restriction program attached).
When enabled, the "Show restricted electric signals using default graphics" client setting and signal post recolouring is not applied.
This flag should only be set if the Action 2/3 actually returns a different sprite when bit 24 of variable 18 is set.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

See also: signals_signal_restriction_info variable

This is indicated by the feature name: action0_signals_restricted_signals, version 1

Enable recolouring for custom signal sprites (mappable property: signals_enable_signal_recolour)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites for this GRF.
When enabled, in addition to returning a sprite, register 0x100 may be set to the following:

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_recolour, version 1

Set number of additional signal aspects (mappable property: signals_extra_aspects)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites for this GRF.
The value is the number of additional signal aspects to use (e.g. 4-aspect signalling should use a value of 2).
When set, the lowest byte of variable 0x18 (SS: signal state) may have the given number of additional values starting from 02:

The property length is 1 byte.
The provided value is currently clamped to be within the range 0 - 6 (inclusive).

N.B. Realistic braking must be enabled for additional signal aspects to be used.

This is indicated by the feature name: action0_signals_extra_aspects, version 1

Define a custom signal style (mappable property: signals_define_style)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites for this GRF.
This defines a new signal style. Signals using this style will only use this GRF, or the default graphics if no graphics are returned.

The total number of custom signal styles in a game is currently limited to 15.

The property length is 1 byte. This is the local ID of the style which is returned in the signals_signal_style variable.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style name (mappable property: signals_style_name)

This applies to the most recent custom signal style defined using the signals_define_style property.
This property should be set, as otherwise the style will not have a name.

The property length is 2 byte. This is a string ID.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style train electric signal types enabled (mappable property: signals_style_electric_enabled)

This applies to the most recent custom signal style defined using the signals_define_style property.
This sets which electric signal types may be built using this signal style.

At least one of this property and signals_style_semaphore_enabled should be set to a non-zero value, as otherwise no signal types will be enabled for this custom signal style.

The property length is 4 bytes:

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style train semaphore signal types enabled (mappable property: signals_style_semaphore_enabled)

This applies to the most recent custom signal style defined using the signals_define_style property.
This sets which semaphore signal types may be built using this signal style.

The property length is 4 bytes and has an identical format to signals_style_electric_enabled, above.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style no aspect increase mode (mappable property: signals_style_no_aspect_increase)

This applies to the most recent custom signal style defined using the signals_define_style property.
When enabled, signals using this style do not increase the signal aspect with respect to the signals either side (i.e. the behaviour is like a banner repeater).

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style always reserve through mode (mappable property: signals_style_always_reserve_through)

This applies to the most recent custom signal style defined using the signals_define_style property.
When enabled, signals using this style have reserve through unconditionally enabled.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style train look-ahead extra aspects (mappable property: signals_style_lookahead_extra_aspects)

This applies to the most recent custom signal style defined using the signals_define_style property.
This property only makes a difference when the "realistic train braking is aspect limited" game setting is enabled.
This limits the signal aspect which the hypothetical train driver can "read" from the signal without affecting signal aspect propagation to other signals, or variable 0x18.
Example values could include: 1 for traditional banner repeater signals.
Shunt signals should use signals_style_lookahead_single_signal_only instead.

The property length is 1 byte. The value is clamped to be less than or equal to the value set in the signals_extra_aspects property.
The Action 0 Id field is not used, the value is ignored.

As a special case, a value of 255 (0xFF) disables the "realistic train braking is aspect limited" setting entirely for signals using this style.
This should only be used for signal types which are intended to emulate in-cab signalling, instead of the "driver" visually reading a signal.
This special case is indicated by the feature name action0_signals_style, version 2.

This property is indicated by the feature name: action0_signals_style, version 1

Set custom signal style train look-ahead to single signal only mode (mappable property: signals_style_lookahead_single_signal_only)

This applies to the most recent custom signal style defined using the signals_define_style property.
This property only makes a difference when the "realistic train braking is aspect limited" game setting is enabled, or when using a different signal type which uses signals_style_combined_normal_shunt.
This is similar to signals_style_lookahead_extra_aspects with a value of 0, except the lookahead always ends at the next signal, even if that signal type sets signals_style_no_aspect_increase.
If enabled, this property overrides signals_style_lookahead_extra_aspects.
This can be used for shunt signals.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style combined normal aspect and shunt signal mode (mappable property: signals_style_combined_normal_shunt)

This applies to the most recent custom signal style defined using the signals_define_style property.
When enabled and displaying a shunt aspect, the signal state in the lowest byte of variable 0x18 (SS: signal state) will have the value: 0xFF.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style signal drawn on opposite side (mappable property: signals_style_opposite_side)

This applies to the most recent custom signal style defined using the signals_define_style property.
When enabled, signals using this style are drawn on the opposite side of the track.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set custom signal style signal drawn on both sides (mappable property: signals_style_both_sides)

This applies to the most recent custom signal style defined using the signals_define_style property.
When enabled, signals using this style are drawn on both sides of the track.
Bit 9 of signals_signal_context is set when drawing the second signal on the opposite side.

If this and signals_style_opposite_side are both set, the first signal is drawn on the opposite side and the second signal is drawn on the usual side.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 3

Set custom signal style signal requires realistic braking (mappable property: signals_style_realistic_braking_only)

This applies to the most recent custom signal style defined using the signals_define_style property.
When enabled, signals using this style may only be built when realistic braking is enabled.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Set whether custom signal sprites should not be used for the default signal style (mappable property: signals_no_default_style)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites for this GRF.
When enabled, this GRF is not used for the default signal style, it is only used for custom signal styles defined with signals_define_style.

The property length is 1 byte. 0 is disabled (default). 1 is enabled.
The Action 0 Id field is not used, the value is ignored.

This is indicated by the feature name: action0_signals_style, version 1

Action 0 - Objects

Object uses land ground sprite (mappable property: object_use_land_ground)

This property sets whether to use the underlying ground as the object ground sprite, ignoring the ground sprite provided in the sprite layout.
When enabled, the ground sprite will be bare ground, grass, snow, desert, etc. as if it were a clear ground tile.
In edge foundation mode, or when foundations are disabled, the ground may be coast/shore when flooded.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_object_use_land_ground, version 1

Enable object edge foundation mode (mappable property: object_edge_foundation_mode)

This property enables edge foundation mode for the object.
This property is intended for objects which are positioned at the edge of a tile, and only require a level edge, not a completely level tile.
Foundations will only be added as required to get a suitable level edge.
The property length is 4 bytes, 1 byte per view. If the object has fewer than 4 views then some of the values provided in the property will not be used, and may be 0.
The format of each byte is:

This is indicated by the feature name: action0_object_edge_foundation_mode, version 1

Object is flood resistant (mappable property: object_flood_resistant)

This property sets whether the object is flood resistant.
Flood resistance is always enabled for objects which can be built on water.
This property can be used to enable flood resistance without enabling the object to be built on water.
The property length is 1 byte. 0 is disabled (default). 1 is enabled.

This is indicated by the feature name: action0_object_flood_resistant, version 1

Set tile type used for display in viewport map mode and the small-map window (mappable property: object_viewport_map_tile_type)

This property sets how object tiles are displayed in viewport map mode and the small-map window.
The property length is 1 byte.

This is indicated by the feature name: action0_object_viewport_map_tile_type, version 1

Set tile sub-type used for display in viewport map mode and the small-map window (mappable property: object_viewport_map_tile_subtype)

This property can be used to further refine the type set in object_viewport_map_tile_type.
The property length is 2 bytes.

Farm fields:

Trees:

This is indicated by the feature name: action0_object_viewport_map_tile_type, version 1

Action 14 - Variable Mapping for Variational Action 2

See Action 14 Specification and Variational Action 2 Specification for background information.

The variable mapping mechanism has the feature name: variable_mapping, this document describes version 1 (and where indicated, version 2).

Unlike property mappings, it is not necessary to perform a feature test or check a mapping success variable before using a mapped variable.

Remapped variables are accessed by reading from variable 0x11 using a varadjust shift-num and and-mask which exactly matches that specified in the variable mapping.
In the absence of any successful variable mapping, variable 0x11 has all bits set to 0 and attempting to read from it with any shift-num and and-mask value results in a value of 0 without producing an error.

Reading a mapped variable on a version of OpenTTD which does not support this variable mapping mechanism or which does not support the requested variable, returns a value of 0.

If more than one variable mapping is made for the same combination of feature ID, shift-num and and-mask, it is implementation-defined which mapping is used.
Each variable mapping SHOULD use a unique combination of feature ID, shift-num and and-mask.

From version 2 of the variable_mapping feature name, variable remapping can also be used with variable 0x7B.
In this case the parameter of variable 0x7B should be set to 0x11, and the shift and mask fields set the same way in the direct 0x11 variable case.
The "VPRM" parameter field is ignored, and the parameter used is the accumulator of the previous adjust part in the usual way for variable 0x7B.

Variable Mapping: C "A2VM"

Each A2VM chunk (type C) describes an individual variable mapping.
Sub-chunks within each A2VM chunk may appear in any order, however each sub-chunk SHOULD only appear ONCE within an individual A2VM chunk.

Unknown Action 14 blocks are ignored, and do not need to be skipped.

Property Name: C "A2VM" -> T "NAME"

Within an A2VM chunk, the NAME text (type T) field contains the name of the variable to map. The value of the language ID byte is ignored.

Action 0 Feature ID: C "A2VM" -> B "FEAT"

Within an A2VM chunk, the FEAT binary (type B) field contains the Variational Action 2 feature ID. This is 1 byte.

In the case where a parent/related scope is used to access a different feature (e.g. the town feature as the parent scope for objects), the feature ID used here is that associated with the scope where the variable is used.
To map a town variable, the feature ID should be the result of mapping the "town" feature name using the feature mapping mechanism, this is not necessarily the feature ID used directly in the variational action 2.

Shift to replace: C "A2VM" -> B "RSFT"

Within an A2VM chunk, the RSFT binary (type B) field contains the Variational Action 2 varadjust shift-num value to look for. This is 1 byte.
The shift-num value must be < 32 (0x20).
If this is not specified, a value of 0 is assumed.

Mask to replace: C "A2VM" -> B "RMSK"

Within an A2VM chunk, the RMSK binary (type B) field contains the Variational Action 2 varadjust and-mask value to look for. This is 4 bytes.
When using byte or word sized variational action 2s, the and-mask is zero-extended to 32 bits before comparing with this value.
If this is not specified, a value of 0 is assumed.

Replacement shift: C "A2VM" -> B "VSFT"

Within an A2VM chunk, the VSFT binary (type B) field contains the replacement Variational Action 2 varadjust shift-num value to use on the mapped variable. This is 1 byte.
The shift-num value must be < 32 (0x20).
If this is not specified, a value of 0 is assumed.

Replacement mask: C "A2VM" -> B "VMSK"

Within an A2VM chunk, the RMSK binary (type B) field contains the replacement Variational Action 2 varadjust and-mask value to use on the mapped variable. This is 4 bytes.
If this is not specified, a value of 0 is assumed.

Success Indicator Global Variable 0x8D Bit: C "A2VM" -> B "SETT"

This behaves identically to the C "A0PM" -> B "SETT" case, above

Success Indicator Global Variable 0x91 Test Value: C "A2VM" -> B "SVAL"

This behaves identically to the C "FTST" -> B "SVAL" case, above

This chunk and the associated test mechanism requires the feature name: variable_mapping, version 3.

Replacement parameter: C "A2VM" -> B "VPRM"

Within an A2VM chunk, the VPRM binary (type B) field contains the Variational Action 2 parameter value (as in 60+X variables) to use on the mapped variable. This is 4 bytes.
If this is not specified, a value of 0 is assumed.
Support for this field is indicated by the feature name variable_mapping, version 2.

Example NFO:

// Map station variable "sample_station_variable" with a shift-num of 4 and an and-mask of 0xFF, to reads of variable 0x11 with a shift-num of 1 and an and-mask of 0x2, and set bit 4 of global variable 0x8D if successful
-1 * -1 14
	"C" "A2VM"
		"T" "NAME" 00 "sample_station_variable" 00
		"B" "FEAT" \w1 04
		"B" "RSFT" \w1 1
		"B" "RMSK" \w4 \dx00000002
		"B" "VSFT" \w1 4
		"B" "VMSK" \w4 \dx000000FF
		"B" "SETT" \w1 4
		00
	00
....
 -1 * 15       02 04 03 81        // Action2, Feature 04 (stations), action2ID 03, 1-byte variable
                   11 01 02       // variable 11 (remapping variable or 0), shift 01, mask 0x02 (these exactly match the remapping above)
                                  // This is remapped to ‐‐> sample_station_variable with a shift of 04 and a mask of 0xFF
                   01             // check one range
                   02 00    00 04 // range 00 - 04: link to action2ID 02
                   01 00          // default:       link to action2ID 01
	

Variational Action 2 - Additional Types

Additional variational action 2 types are indicated by the feature name: more_varaction2_types, this document describes version 1.
This feature name must be tested for to enable this feature.

See the Variational Action 2 Specification (types) for background information.

This feature adds the type value 87, for additional variation action 2 modes/scopes. (This is used instead of the standard values: 81, 82, 85, 86, 89 or 8A).
An additional byte follows to specify which sub-type.

<Sprite-number> * <Length> 02 <feature> <set-id> 87 <sub-type> ...

If an unknown sub-type is used, or if subsequent sub-type bytes are invalid, a callback failure group is created, the same as sub-type 00.

Sub-type 00: Callback failure

<Sprite-number> * <Length> 02 <feature> <set-id> 87 00

Sub-type 01: Relative scope for vehicles (random action 2 type 84 syntax)

<Sprite-number> * <Length> 02 <feature> <set-id> 87 01 <count> <variable> <varadjust> [<operator> <variable> <varadjust>]... <nvar> (<set-id> <low-range> <high-range>){n} <default>

This sub-type is only valid for vehicles.

The vehicle which is accessed can be any in the vehicle consist. The count byte selects which, this has the same syntax and functionality as the count byte in random action 2 type 84.

Note: The count byte mode where temporary variable 0x100 is used should be used with caution.

Sub-type 02: Relative scope for vehicles (longer syntax)

<Sprite-number> * <Length> 02 <feature> <set-id> 87 02 <mode> <offset> <variable> <varadjust> [<operator> <variable> <varadjust>]... <nvar> (<set-id> <low-range> <high-range>){n} <default>

This sub-type is only valid for vehicles.

The vehicle which is accessed can be any in the vehicle consist. The mode and offset bytes select which.

The mode byte has the following syntax:

The offset byte specifies how far to count from the starting vehicle. A value of 0 is not special.
Bit 7 of the mode byte must be set to use temporary variable 0x100 instead.

Note: Using temporary variable 0x100 as the offset should be used with caution.

Variational Action 2 - Vehicles

Query variable of n-th vehicle in chain (61)

This variable is also enabled for ships if indicated by the feature name: multi_part_ships, version 2.

Variational Action 2 - Stations

Track type in purchase list (42)

This is indicated by the feature name: varaction2_station_var42, version 1

Station info of nearby tiles v2 (mappable variable: station_station_info_nearby_tiles_v2)

This has a similar value to 68/Station info of nearby tiles.

Variational Action 2 - Railtypes

Signal routing restriction information (mappable variable: railtype_signal_restriction_info)

This applies to Action 2/3 - Railtype custom signal sprites.

See also: railtype_enable_restricted_signals property

This is indicated by the feature name: action0_railtype_restricted_signals, version 2

Signal context (mappable variable: railtype_signal_context)

This applies to Action 2/3 - Railtype custom signal sprites.

This is indicated by the feature name: varaction2_railtype_signal_context, version 1

Signal side (mappable variable: railtype_signal_side)

This applies to Action 2/3 - Railtype custom signal sprites.

This is indicated by the feature name: varaction2_railtype_signal_side, version 1

Vertical clearance (mappable variable: railtype_signal_vertical_clearance)

This applies to Action 2/3 - Railtype custom signal sprites.

This is indicated by the feature name: varaction2_railtype_signal_vertical_clearance, version 1

Adjacent level crossing information (mappable variable: railtype_adjacent_crossing)

This is indicated by the feature name: varaction2_railtype_adjacent_crossing, version 1

Variational Action 2 - Objects

Tile slope after foundation applied (mappable variable: object_foundation_tile_slope)

This has the same format as bits 8-12 of object variable 41.

This is indicated by the feature name: action0_object_edge_foundation_mode, version 2

Tile slope after foundation applied xor underlying tile slope (mappable variable: object_foundation_change_tile_slope)

This has the same format as bits 8-12 of object variable 41, but has bits set only where the foundation slope differs from the underlying tile slope.
If this variable is non-zero a foundation is present.
This is useful for xoring with bits 8-12 of variable 41, because if this variable is unavailable then the result is still the underlying tile slope.

This is indicated by the feature name: action0_object_edge_foundation_mode, version 2

Variational Action 2 - Airport Tiles

Airport ID (mappable variable: airporttiles_airport_id)

This is the local GRF ID of the airport type.

This is indicated by the feature name: varaction2_airporttiles_airport_info, version 1

Airport layout number (mappable variable: airporttiles_airport_layout)

This is the airport layout number (as defined in airport property 0A).

This is indicated by the feature name: varaction2_airporttiles_airport_info, version 1

Variational Action 2 - Signals (Feature 0E)

Signal routing restriction information (mappable variable: signals_signal_restriction_info)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites.

See also: signals_enable_restricted_signals property

This is indicated by the feature name: action0_signals_restricted_signals, version 2

Signal context (mappable variable: signals_signal_context)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites.

This is indicated by the feature name: varaction2_signals_signal_context, version 1

Signal side (mappable variable: signals_signal_side)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites.

This is indicated by the feature name: varaction2_signals_signal_side, version 1

Signal style (mappable variable: signals_signal_style)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites.
If the signal being drawn uses a custom signal style, the value is the signal style ID as set in the signals_define_style property.
Otherwise for signals using the default style, the value is 0.

This is indicated by the feature name: action0_signals_style, version 1.

Vertical clearance (mappable variable: signals_signal_vertical_clearance)

This applies to Action 2/3 Signals (Feature 0E) custom signal sprites.

This is indicated by the feature name: varaction2_signals_signal_vertical_clearance, version 1

Callbacks - Ships

Multi-part ships

Callback 16 - Articulated engine may also be used for ships.
The feature name: multi_part_ships must be tested for to enable this callback for ships.
This functions the same as for trains and road vehicles, and is enabled for individual engines in the same way (bit 4 of ship property 12).
Additional ship parts are not used for graphics, they are only used for additional cargo capacity.
The graphics chain for the primary vehicle may check the cargo states of the other ship parts if required.
Additional ship parts may be refitted individually.

This is indicated by the feature name: multi_part_ships, version 1

From version 3 of the multi_part_ships feature, Action 2 loadtypes/loadingtypes cargo thresholds refer to the entire ship, not just the first vehicle.

Callback EC008002 - Ship part name for refit window
This callback is called on the primary vehicle to get the name of each part of the ship (e.g. the name of each cargo hold) in the refit window.
This is not called for ships of only one part.
If this callback is not handled, a default name is used.
Bits 0 - 7 of variable 10 contains the index of the part of the ship. The first/primary part is 0, each subsequent part increases the value by 1.

The return value should be the number of a D0xx text to be displayed. The contents of registers 100h..105h are copied onto the text reference stack and can be used with string codes 80/81 to show texts from the D8xx range as well, extending the available unique strings.
You can return 400 to use the default name (instead of failing the callback).
(This is the same return format as callbacks: 23, 38, 3A, 14D, 15C, 161).

This is indicated by the feature name: multi_part_ships, version 1

Action 3 - Objects

Before JGRPP 0.54 and vanilla OpenTTD 14.0, if feature name more_objects_per_grf is present and the feature is successfully tested for, the Action 3 ID field is an extended byte, and GRFs may define more than 255 object types.
Otherwise, only 255 object types may be defined per GRF, and the extended byte format may not be used.

From JGRPP 0.54 and vanilla OpenTTD 14.0, the extended byte format may always be used.

NewGRFs may check whether either the more_objects_per_grf feature is present, or if the NewGRF version indicates OpenTTD 14.0 or later.

Action 3 - Signals (Feature 0E)

Note that Action 3 feature 0E is not supported (does nothing) in standard OpenTTD.

This implementation of feature 0E is not the same as that in TTDPatch.

Custom signal sprites using Action 2/3 (action 3 ID: 0)

This feature allows using Action 3 to assign an Action 2 chain which dynamically resolves signal sprites, in a very similar way to that of Action 2/3 - Railtype custom signal sprites,
however, this applies to all signals, not only those of a particular rail type.

Variational Action 2 variables 10, 18 and 40 are available and have the same format as in VariationalAction2/Railtypes.

Rail type custom signal sprites have a higher priority than custom signal sprites for all signals as set here.

Note that this is not a generic callback, the sprite group must be assigned to ID 0 (further IDs may be allocated for other purposes in future).
Cargo type definitions are not used. Only the default set ID is used.

This is indicated by the feature name: action3_signals_custom_signal_sprites, version 1

Action 14 - Type ID Mapping for Action 5

See Action 14 Specification and Action 5 Specification for background information.

The action 5 type ID mapping mechanism has the feature name: action5_type_id_mapping, this document describes version 1.

Users of this mechanism SHOULD at minimum test for the presence of the feature above or test variable 8D, below.

Action 5 type ID Mapping: C "A5TM"

Each A5TM chunk (type C) describes an individual action 5 type ID mapping.
Sub-chunks within each A5TM chunk may appear in any order, however except where otherwise noted each sub-chunk SHOULD only appear ONCE within an individual A5TM chunk.

Action 5 type ID mapping can be safely used on implementations which do not implement the type ID mapping mechanism if Action 5 sprites which use mapped type IDs are skipped if one or more of:

• The global variable 0x8D is checked to determine whether the type ID mapping operation was successful.
• The feature name action5_type_id_mapping is checked for.

Property Name: C "A5TM" -> T "NAME"

Within an A5TM chunk, the NAME text (type T) field contains the name of the type to map. The value of the language ID byte is ignored.

Property ID: C "A5TM" -> B "TYPE"

Within an A5TM chunk, the TYPE binary (type B) field contains the type ID to allocate to the named type, this value can used in Action 5 sprites. This is 1 byte. The value MUST be < 128 (i.e bit 7 must be clear).
It is possible to override existing type IDs, however this use is not recommended.

Success Indicator Global Variable 0x8D Bit: C "A5TM" -> B "SETT"

This behaves identically to the C "A0PM" -> B "SETT" case, above

Success Indicator Global Variable 0x91 Test Value: C "A5TM" -> B "SVAL"

This behaves identically to the C "FTST" -> B "SVAL" case, above

This chunk and the associated test mechanism requires the feature name: action5_type_id_mapping, version 2.

Fallback Mode: C "A5TM" -> B "FLBK"

This behaves identically to the C "A0PM" -> B "FLBK" case, above

Example NFO:

// Map action5 type "sample_action5_type" to type id 0x70, and set bit 5 of global variable 0x8D if successful
-1 * -1 14
	"C" "A5TM"
		"T" "NAME" 00 "sample_action5_type" 00
		"B" "TYPE" \w1 70
		"B" "SETT" \w1 5
		00
	00
....
// Skip 3 sprites if bit 5 of global variable 0x8D is not set (indicating that station property sample_action5_type is NOT present)
-1 * -1  07 8D 01 \70 05 03
// Set 2 sprites at offset 7 into sample_action5_type
-1 * -1  05 F0 02 07
-1  sprites/sample.png 546 8 09 23 33 -26 0
-1  sprites/sample.png 594 8 09 23 33 -5 0
	

Programmable pre-signal graphics (mappable type: programmable_signals)

Signal graphics come in groups of 16. These groups contain sprites in the same order as sprites 1275-1290 in trg1[r].grf and Action 5 type 4 (signals); red, then green, for each of: SW-facing, NE-facing, NW-facing, SE-facing, E-facing, W-facing, S-facing, N-facing.

This is indicated by the feature name: action5_programmable_signals, version 1

No-entry signal graphics (mappable type: no_entry_signals)

No-entry signal graphics come in groups of 8. These groups contain sprites in the same order as the red sprites of 1275-1290 in trg1[r].grf and Action 5 type 4 (signals); red only, for each of: SW-facing, NE-facing, NW-facing, SE-facing, E-facing, W-facing, S-facing, N-facing.

This is indicated by the feature name: action5_no_entry_signals, version 1

Miscellaneous GUI graphics (mappable type: misc_gui)

There is currently one misc GUI sprite.

This is indicated by the feature name: action5_misc_gui, version 1

Road waypoint graphics (mappable type: road_waypoints)

This is 4 sprites, in the same order and format as the drive-through bus or truck road stop graphics.

This is indicated by the feature name: action5_road_waypoints, version 1

Action 14 - Feature ID Mapping

See Action 14 Specification and Feature Specifications for background information.

The feature ID mapping mechanism has the feature name: feature_id_mapping, this document describes version 1.

Users of this mechanism SHOULD at minimum test for the presence of the feature above or test variable 8D, below.

Feature ID Mapping: C "FIDM"

Each FIDM chunk (type C) describes an individual feature ID mapping.
Sub-chunks within each FIDM chunk may appear in any order, however except where otherwise noted each sub-chunk SHOULD only appear ONCE within an individual FIDM chunk.

Feature ID mapping can be safely used on implementations which do not implement the feature ID mapping mechanism if all sprites which use mapped feature IDs are skipped if one or more of:

• The global variable 0x8D is checked to determine whether the feature ID mapping operation was successful.
• The feature name feature_id_mapping is checked for.

After this mapping, the mapped feature ID value can used in all sprites which expect a feature ID (including Action 0, Action 1, Action 2, Action 3, Action 4, Action D, Action 14).

Note that implementations which are not aware of a particular feature ID and which do not implement the feature ID mapping mechanism will automatically skip sprites with unknown feature IDs.
However: if/when the specification and/or the implementation assigns the chosen feature ID to an unrelated feature in future, sprites using that feature will not be skipped.
This means that the GRF has the potential to inexplicably fail in the distant future if the sprites are not correctly skipped.
Do not rely on the behaviour where unknown feature IDs are skipped.

Property Name: C "FIDM" -> T "NAME"

Within an FIDM chunk, the NAME text (type T) field contains the name of the feature to map. The value of the language ID byte is ignored.

Property ID: C "FIDM" -> B "FTID"

Within an FTID chunk, the FTID binary (type B) field contains the feature ID to allocate to the named feature. This is 1 byte.
Note that the remapped feature ID can only be used after this FIDM chunk in the GRF. It is not applied retrospectively to sprites earlier in the GRF file, or earlier parts of the current Action 14 sprite.
It is possible to override existing feature IDs, however this use is STRONGLY NOT RECOMMENDED (except in the specific case below) due to a high potential for confusion when your code is inspected by someone else.
At the time of writing known existing feature IDs include the values: 0x00 - 0x14 (inclusive) and 0x48.

The interface for feature 0x14 (road stops) is mostly equivalent to that of the "roadstops" feature name, therefore it is reasonable to map the "roadstops" feature name to ID 0x14, such that both interfaces can be supported simultaneously.

Success Indicator Global Variable 0x8D Bit: C "FIDM" -> B "SETT"

This behaves identically to the C "A0PM" -> B "SETT" case, above

Success Indicator Global Variable 0x91 Test Value: C "FIDM" -> B "SVAL"

This behaves identically to the C "FTST" -> B "SVAL" case, above

This chunk and the associated test mechanism requires the feature name: feature_id_mapping, version 2.

Fallback Mode: C "FIDM" -> B "FLBK"

This behaves identically to the C "A0PM" -> B "FLBK" case, above

Example NFO:

// Map feature "sample_feature" to feature id 0xB0, and set bit 6 of global variable 0x8D if successful
-1 * -1 14
	"C" "FIDM"
		"T" "NAME" 00 "sample_feature" 00
		"B" "FTID" \w1 B0
		"B" "SETT" \w1 6
		00
	00
....
// Skip 3 sprites if bit 6 of global variable 0x8D is not set (indicating that the sample_feature feature is NOT present)
-1 * -1  07 8D 01 \70 06 03
// Use action 1 to define 1 sample_feature spriteset of 2 views
-1 * -1 01 B0 01 02
-1  sprites/sample.png 546 8 09 23 33 -26 0
-1  sprites/sample.png 594 8 09 23 33 -5 0
	

Available features: