<h2>Additions to NewGRF Specifications in JGR's Patchpack</h2>
<p>This document describes non-standard additions to the <ahref="https://newgrf-specs.tt-wiki.net/wiki/Main_Page">Official OpenTTD NewGRF Specifications</a> which are present in this patchpack.
<p>A subset of the features listed below are also supported in a fork of NML, see the associated <ahref="newgrf-additions-nml.html">NML document</a> for more details.</p>
<p>NewGRFs which use any of these features SHOULD use the <ahref="#feature-test">feature testing</a> mechanism described below to check whether individual added features are supported.</p>
<p>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.</p>
<p>Within an FTST chunk, the SETP binary (type B) field contains the bit number to set/clear in
<ahref="https://newgrf-specs.tt-wiki.net/wiki/GlobalVariables">global variable</a> 0x9D (TTD Platform) to store the result of the test. This is 1 byte.<br/>
If the test is successful, the bit is set (to 1), otherwise the bit is cleared (to 0).<br/>
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.<br/>
Global variable 0x9D can then be tested by using a standard <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action7">Action 7 or 9</a>, or a standard <ahref="https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2">Variational Action 2</a>.<br/>
If this field is omitted, no bit is set or cleared, and the test is not observable.
<p>Each A0PM chunk (type C) describes an individual property mapping.<br/>
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.</p>
<p>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:
<ul>
<li>The global variable 0x8D is checked to determine whether the property mapping operation was successful.</li>
<li>The feature name <fontface="monospace">property_mapping</font> is checked for.</li>
</ul>
Unknown Action 14 blocks are ignored, and do not need to be skipped.</p>
<p>Within an A0PM chunk, the FEAT binary (type B) field contains the <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action0#Feature">Action 0 feature ID</a>. This is 1 byte.</p>
<p>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.<br/>
It is possible to override existing properties, however this use is not recommended.</p>
<p>Within an A0PM chunk, the SETT binary (type B) field contains the bit number to set/clear in
<ahref="https://newgrf-specs.tt-wiki.net/wiki/GlobalVariables">global variable</a> 0x8D (TTD version) to store whether the mapping operation was successful. This is 1 byte.<br/>
If the operation is successful, the bit is set (to 1), otherwise the bit is cleared (to 0).<br/>
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.<br/>
Global variable 0x8D can then be tested by using a standard <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action7">Action 7 or 9</a>, or a standard <ahref="https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2">Variational Action 2</a>.<br/>
If this field is omitted, no bit is set or cleared.
<p>Within an A0PM chunk, the FLBK binary (type B) field contains the fallback mode. This is 1 byte.<br/>
The fallback mode may take the following values:
<table>
<tr><th>Value</th><th>Behaviour</th></tr>
<tr><td>0</td><td>Attempts to map an unknown property name are ignored. Use of the mapped property in an Action 0 is ignored. This is the default.</td></tr>
<tr><td>1</td><td>Attempts to map an unknown property name are ignored. Use of the mapped property in an Action 0 is an error.</td></tr>
<tr><td>2</td><td>Attempting to map an unknown property name is an error.</td></tr>
</table>
Attempts to set a fallback mode other than those listed above are silently ignored. More fallback modes MAY be added in future versions of this mechanism.<br/>
This chunk MAY be specified more than once, in which case the last specified valid value is used.<br/>
Note that even when using fallback mode 0, above, if the property mapping feature is not present, then use of the mapped property ID in an Action 0 is an error.
Note that each use of the mapped property ID is followed by Num-info iterations of the size and data pair above. See: <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action0">Action 0 Specification</a>.
<p>This property allows building bridges over stations.<br/>
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).<br/>
Each height value is 1 byte, the total property length is 8 bytes.
<h4id="railtype_enable_programmable_signals">Enable custom signal sprites for programmable pre-signals (mappable property: railtype_enable_programmable_signals)</h4>
<h4id="railtype_enable_restricted_signals">Enable restricted signal flag for custom signal sprites (mappable property: railtype_enable_restricted_signals)</h4>
<p>This applies to <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action3/Railtypes#Signal_sprites_.280B.29">Action 2/3 - Railtype custom signal sprites</a>.<br/>
When enabled, bit 24 of variable 18 (extra callback info) is set if the signal is restricted (has a routing restriction program attached).<br/>
<h4id="railtype_enable_signal_recolour">Enable recolouring for custom signal sprites (mappable property: railtype_enable_signal_recolour)</h4>
<p>This applies to <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action3/Railtypes#Signal_sprites_.280B.29">Action 2/3 - Railtype custom signal sprites</a>.<br/>
When enabled, in addition to returning a sprite, register 0x100 may be set to the following:
<table>
<tr><th>Bits</th><th>Meaning</th></tr>
<tr><td>0 - 23</td><td>Recolour sprite to use. Set to 0 for no recolouring.</td></tr>
<tr><td>24 - 31</td><td>Reserved, set to zero. </td></tr>
</table></p>
<p>The property length is 1 byte. 0 is disabled (default). 1 is enabled.</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_railtype_recolour</font>, version 1</p>
<h4id="railtype_extra_aspects">Set number of additional signal aspects (mappable property: railtype_extra_aspects)</h4>
<p>This applies to <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action3/Railtypes#Signal_sprites_.280B.29">Action 2/3 - Railtype custom signal sprites</a>.<br/>
The value is the number of additional signal aspects to use (e.g. 4-aspect signalling should use a value of 2).<br/>
When set, the lowest byte of variable 0x18 (SS: signal state) may have the given number of additional values starting from 02:
<table>
<tr><th>Value</th><th>Meaning</th></tr>
<tr><td>00</td><td>Red signal</td></tr>
<tr><td>01</td><td>Green signal</td></tr>
<tr><td>02</td><td>1st extra aspect (e.g. yellow)</td></tr>
<tr><td>03</td><td>2nd extra aspect (e.g. double yellow)</td></tr>
<tr><td>...</td><td>Further extra aspects...</td></tr>
</table></p>
<p>The property length is 1 byte.<br/>
The provided value is currently clamped to be within the range 0 - 6 (inclusive).</p>
<p>N.B. Realistic braking must be enabled for additional signal aspects to be used.</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_railtype_extra_aspects</font>, version 1</p>
<h4id="railtype_disable_realistic_braking">Disable use of realistic braking with this rail type (mappable property: railtype_disable_realistic_braking)</h4>
The string should have the same format and use the same ID range as
<ahref="https://newgrf-specs.tt-wiki.net/wiki/Action0/Industries#Default_name_for_nearby_station_.2824.29">industry - default name for nearby station</a>.<br/>
The Action 0 ID field is ignored. This property always adds a new station name string instead of overwriting an existing one.<br/>
<p>Note that Action 0 feature 0E is not supported (does nothing) in standard OpenTTD.</p>
<p>This implementation of feature 0E is not the same as that in TTDPatch.</p>
<h4id="signals_enable_programmable_signals">Enable custom signal sprites for programmable pre-signals (mappable property: signals_enable_programmable_signals)</h4>
<p>This enables <ahref="#a3signals_custom_signal_sprites">Action 2/3 Signals (Feature 0E) custom signal sprites</a> for programmable pre-signals for this GRF.<br/>
Programmable pre-signals have the signal type value: 06.<br/>
The property length is 1 byte. 0 is disabled (default). 1 is enabled.<br/>
The Action 0 Id field is not used, the value is ignored.
</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_signals_programmable_signals</font>, version 1</p>
<h4id="signals_enable_no_entry_signals">Enable custom signal sprites for no-entry signals (mappable property: signals_enable_no_entry_signals)</h4>
<p>This enables <ahref="#a3signals_custom_signal_sprites">Action 2/3 Signals (Feature 0E) custom signal sprites</a> for no-entry signals for this GRF.<br/>
No-entry signals have the signal type value: 07.<br/>
The property length is 1 byte. 0 is disabled (default). 1 is enabled.
</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_signals_no_entry_signals</font>, version 1</p>
<h4id="signals_enable_restricted_signals">Enable restricted signal flag for custom signal sprites (mappable property: signals_enable_restricted_signals)</h4>
<p>This applies to <ahref="#a3signals_custom_signal_sprites">Action 2/3 Signals (Feature 0E) custom signal sprites</a> for this GRF.<br/>
When enabled, bit 24 of variable 18 (extra callback info) is set if the signal is restricted (has a routing restriction program attached).<br/>
When enabled, the "Show restricted electric signals using default graphics" client setting and signal post recolouring is not applied.<br/>
This flag should only be set if the Action 2/3 actually returns a different sprite when bit 24 of variable 18 is set.<br/>
The property length is 1 byte. 0 is disabled (default). 1 is enabled.<br/>
The Action 0 Id field is not used, the value is ignored.
</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_signals_restricted_signals</font>, version 1</p>
<h4id="object_use_land_ground">Object uses land ground sprite (mappable property: object_use_land_ground)</h4>
<p>This property sets whether to use the underlying ground as the object ground sprite, ignoring the ground sprite provided in the sprite layout.<br/>
When enabled, the ground sprite will be bare ground, grass, snow, desert, etc. as if it were a clear ground tile.<br/>
In edge foundation mode, the ground may be coast/shore when flooded.<br/>
The property length is 1 byte. 0 is disabled (default). 1 is enabled.</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_object_use_land_ground</font>, version 1</p>
<h4id="object_edge_foundation_mode">Enable object edge foundation mode (mappable property: object_edge_foundation_mode)</h4>
<p>This property enables edge foundation mode for the object.<br/>
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.<br/>
Foundations will only be added as required to get a suitable level edge.<br/>
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.<br/>
The format of each byte is:
<table>
<tr><th>Bit</th><th>Value</th><th>Meaning (for this view)</th></tr>
<tr><td>0 - 1</td><td></td><td>
Which tile edge to use:<br/>
<table>
<tr><th>Value</th><th>Meaning</th></tr>
<tr><td>0</td><td>North-east edge</td></tr>
<tr><td>1</td><td>South-east edge</td></tr>
<tr><td>2</td><td>South-west edge</td></tr>
<tr><td>3</td><td>North-west edge</td></tr>
</table>
</td></tr>
<tr><td>2</td><td>4</td><td>Change z-position for the building sprite to the height of the edge</td></tr>
<tr><td>3</td><td>8</td><td>If the height of the edge is lower than the maximum height of the tile, build a foundation</td></tr>
<tr><td>4</td><td>10</td><td>Use inclined instead of a flat foundations where possible. (Slopes with one corner raised where the height of the edge is at the maximum height of the tile).<br/>
<h4id="object_viewport_map_tile_type">Set tile type used for display in viewport map mode and the small-map window (mappable property: object_viewport_map_tile_type)</h4>
<p>This property sets how object tiles are displayed in viewport map mode and the small-map window.<br/>
<tr><td>05</td><td>Farm fields</td><td>The specific type of field can be set using object_viewport_map_tile_subtype</td></tr>
<tr><td>06</td><td>Snow</td><td></td></tr>
<tr><td>07</td><td>Desert</td><td></td></tr>
<tr><td>08</td><td>Trees</td><td>The specific tree count and ground type/density can be set using object_viewport_map_tile_subtype</td></tr>
<tr><td>09</td><td>House</td><td></td></tr>
<tr><td>0A</td><td>Water</td><td></td></tr>
</table></p>
<p>This is indicated by the feature name: <fontface="monospace">action0_object_viewport_map_tile_type</font>, version 1</p>
<h4id="object_viewport_map_tile_subtype">Set tile sub-type used for display in viewport map mode and the small-map window (mappable property: object_viewport_map_tile_subtype)</h4>
<p>This property can be used to further refine the type set in object_viewport_map_tile_type.<br/>
<p>The variable mapping mechanism has the feature name: <fontface="monospace">variable_mapping</font>, this document describes version 1 (and where indicated, version 2).</p>
<p>Unlike property mappings, it is not necessary to perform a feature test or check a mapping success variable before using a mapped variable.</p>
<p>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.<br/>
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.</p>
<p>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.</p>
<p>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.<br/>
Each variable mapping SHOULD use a unique combination of feature ID, shift-num and and-mask.</p>
<p>From version 2 of the <fontface="monospace">variable_mapping</font> feature name, variable remapping can also be used with variable 0x7B.<br/>
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.<br/>
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.</p>
<p>Each A2VM chunk (type C) describes an individual variable mapping.<br/>
Sub-chunks within each A2VM chunk may appear in any order, however each sub-chunk SHOULD only appear ONCE within an individual A2VM chunk.</p>
<p>Unknown Action 14 blocks are ignored, and do not need to be skipped.</p>
</p>
<h4id="A2VM-NAME">Property Name: C "A2VM" -> T "NAME"</h4>
<p>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.</p>
<h4id="A2VM-FEAT">Action 0 Feature ID: C "A2VM" -> B "FEAT"</h4>
<p>Within an A2VM chunk, the FEAT binary (type B) field contains the <ahref="https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2#Feature">Variational Action 2 feature ID</a>. This is 1 byte.</p>
<p>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.<br/>
The shift-num value must be < 32 (0x20).<br/>
If this is not specified, a value of 0 is assumed.</p>
<p>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.<br/>
If this is not specified, a value of 0 is assumed.</p>
<h4id="A2VM-SETT">Success Indicator Global Variable 0x8D Bit: C "A2VM" -> B "SETT"</h4>
<p>This behaves identically to the <ahref="#A0PM-SETT">C "A0PM" -> B "SETT"</a> case, above</p>
<h4id="A2VM-VPRM">Replacement parameter: C "A2VM" -> B "VPRM"</h4>
<p>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.<br/>
If this is not specified, a value of 0 is assumed.<br/>
Support for this field is indicated by the feature name <fontface="monospace">variable_mapping</font>, version 2.</p>
// 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
<h4id="object_foundation_tile_slope">Tile slope after foundation applied (mappable variable: object_foundation_tile_slope)</h4>
<p>This has the same format as bits 8-12 of object variable 41.</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_object_edge_foundation_mode</font>, version 2</p>
<h4id="object_foundation_change_tile_slope">Tile slope after foundation applied xor underlying tile slope (mappable variable: object_foundation_change_tile_slope)</h4>
<p>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.<br/>
If this variable is non-zero a foundation is present.<br/>
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.</p>
<p>This is indicated by the feature name: <fontface="monospace">action0_object_edge_foundation_mode</font>, version 2</p>
<p>Note that Action 3 feature 0E is not supported (does nothing) in standard OpenTTD.</p>
<p>This implementation of feature 0E is not the same as that in TTDPatch.</p>
<h4id="a3signals_custom_signal_sprites">Custom signal sprites using Action 2/3 (action 3 ID: 0)</h4>
<p>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 <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action3/Railtypes#Signal_sprites_.280B.29">Action 2/3 - Railtype custom signal sprites</a>,<br/>
however, this applies to all signals, not only those of a particular rail type.</p>
<p>Variational Action 2 variables 10, 18 and 40 are available and have the same format as in <ahref="https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Railtypes">VariationalAction2/Railtypes</a>.</p>
<p>Rail type custom signal sprites have a higher priority than custom signal sprites for all signals as set here.</p>
<p>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).</p>
<p>This is indicated by the feature name: <fontface="monospace">action3_signals_custom_signal_sprites</font>, version 1</p>
<p>See <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action14">Action 14 Specification</a> and <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action5">Action 5 Specification</a> for background information.</p>
<p>The action 5 type ID mapping mechanism has the feature name: <fontface="monospace">action5_type_id_mapping</font>, this document describes version 1.</p>
<p>Users of this mechanism SHOULD at minimum test for the presence of the feature above or test variable 8D, below.</p>
<p>Each A5TM chunk (type C) describes an individual action 5 type ID mapping.<br/>
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.</p>
<p>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:
<ul>
<li>The global variable 0x8D is checked to determine whether the type ID mapping operation was successful.</li>
<li>The feature name <fontface="monospace">action5_type_id_mapping</font> is checked for.</li>
</ul>
Unknown Action 14 blocks are ignored, and do not need to be skipped.</p>
<p>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).<br/>
It is possible to override existing type IDs, however this use is not recommended.</p>
<p>Signal graphics come in groups of 16. These groups contain sprites in the same order as sprites 1275-1290 in trg1[r].grf and <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action5#04_Signal_graphics.">Action 5 type 4 (signals)</a>;
red, then green, for each of: SW-facing, NE-facing, NW-facing, SE-facing, E-facing, W-facing, S-facing, N-facing.
<h4id="no_entry_signals">No-entry signal graphics (mappable type: no_entry_signals)</h4>
<p>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 <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action5#04_Signal_graphics.">Action 5 type 4 (signals)</a>;
red only, for each of: SW-facing, NE-facing, NW-facing, SE-facing, E-facing, W-facing, S-facing, N-facing.
<h3id="feature-id-mapping">Action 14 - Feature ID Mapping</h3>
<p>See <ahref="https://newgrf-specs.tt-wiki.net/wiki/Action14">Action 14 Specification</a> and <ahref="https://newgrf-specs.tt-wiki.net/wiki/Features">Feature Specifications</a> for background information.</p>
<p>The feature ID mapping mechanism has the feature name: <fontface="monospace">feature_id_mapping</font>, this document describes version 1.</p>
<p>Users of this mechanism SHOULD at minimum test for the presence of the feature above or test variable 8D, below.</p>
<h4id="FIDM">Feature ID Mapping: C "FIDM"</h4>
<p>Each FIDM chunk (type C) describes an individual feature ID mapping.<br/>
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.</p>
<p>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:
<ul>
<li>The global variable 0x8D is checked to determine whether the feature ID mapping operation was successful.</li>
<li>The feature name <fontface="monospace">feature_id_mapping</font> is checked for.</li>
</ul>
Unknown Action 14 blocks are ignored, and do not need to be skipped.</p>
<p>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).</p>
<p><b>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.<br/>
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.<br/>
This means that the GRF has the potential to inexplicably fail in the distant future if the sprites are not correctly skipped.<br/>
Do not rely on the behaviour where unknown feature IDs are skipped.</b></p>
<h4id="FIDM-NAME">Property Name: C "FIDM" -> T "NAME"</h4>
<p>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.</p>
<h4id="FIDM-FTID">Property ID: C "FIDM" -> B "FTID"</h4>
<p>Within an FTID chunk, the FTID binary (type B) field contains the feature ID to allocate to the named feature. This is 1 byte.<br/>
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.<br/>
It is possible to override existing feature IDs, however this use is STRONGLY NOT RECOMMENDED due to a high potential for confusion when your code is inspected by someone else.<br/>
At the time of writing known existing feature IDs include the values: 0x00 - 0x13 (inclusive) and 0x48.</p>
<h4id="FIDM-SETT">Success Indicator Global Variable 0x8D Bit: C "FIDM" -> B "SETT"</h4>
<p>This behaves identically to the <ahref="#A0PM-SETT">C "A0PM" -> B "SETT"</a> case, above</p>
<h4id="FIDM-FLBK">Fallback Mode: C "FIDM" -> B "FLBK"</h4>
<p>This behaves identically to the <ahref="#A0PM-FLBK">C "A0PM" -> B "FLBK"</a> case, above</p>
<h4id="FIDM-example">Example NFO:</h4>
<pre>
// 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
