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.

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.

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.

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.

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

Action 0 - Global Settings

Extra station names (mappable property: global_extra_station_names)

This adds extra station names for use when all the avilable 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

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.

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

Variational Action 2 - Stations

Track type in purchase list (42)

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

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).

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

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