GRFSpecs - User contributions [en-gb]

Action0/Vehicles/Trains

2025-09-14T15:17:45Z

Michi cc: Prop 34

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

=Introduction=
Defining properties of train vehicles.

= Properties =

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|0.6|2.0}}||Track type (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||AI special flag: set to 1 if engine is 'optimized' for passenger service (AI won't use it for other cargo), 0 otherwise||no
|-
|09||W||{{ottdp|0.6|2.0}}||Speed in mph*1.6 (see below)||no
|-
|0B||W||{{ottdp|0.6|2.0}}||Power (0 for wagons)||should be zero
|-
|0D||B||{{ottdp|0.6|2.0}}||Running cost factor (0 for wagons)||should be zero
|-
|0E||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sprite ID (FD for new graphics)||yes
|-
|13||B||{{ottdp|0.6|2.0}}||Dual-headed flag; 1 if dual-headed engine, 0 otherwise||should be zero also for front
|-
|14||B||{{ottdp|0.6|2.0}}||Cargo capacity||yes
|-
|15||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'<br/>
{{ottd|15.0}} Since 15.0, a default cargo translation table corresponding to the climate is used if one is not provided.
||yes
|-
|16||B||{{ottdp|0.6|2.0}}||Weight in tons||should be zero
|-
|17||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|18||B||{{ottdp|<0.7|2.0}}<ref>This property is not used by OpenTTDs NoAI API.</ref>||Engine rank for the AI (AI selects the highest-rank engine of those it can buy)||no
|-
|19||B||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Engine traction type (see below)||no
|-
|1A||B/B*<ref>{{ottdp|0.7|no|ottdrev=r13831}} Since OpenTTD r13831 this is an extended byte.</ref>||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Not a property, but an action: sort the purchase list.||no
|-
|1B||W||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Power added by each wagon connected to this engine, see below||should be zero
|-
|1C||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1D||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (bit value) in [[CargoTypes]]. <b>Obsoleted by properties 2C/2D</b>||yes
|-
|1E||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|1F||B||{{ottdp|0.6|2.5|ttdprev=alpha 19}}||Coefficient of tractive effort||should be zero
|-
|20||B||{{ottdp|1.1|2.5|ttdprev=alpha 27}}||Coefficient of air drag||should be zero
|-
|21||B||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Make vehicle shorter by this amount, see below||yes
|-
|22||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set visual effect type (steam/smoke/sparks) as well as position, see below||yes
|-
|23||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set how much weight is added by making wagons powered (i.e. weight of engine), see below||should be zero
|-
|24||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||High byte of vehicle weight, weight will be prop.24*256+prop.16||should be zero
|-
|25||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||User-defined bit mask to set when checking veh. var. 42||yes
|-
|26||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|27||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous flags||partly
|-
|28||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes||yes
|-
|29||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes||yes
|-
|2A||D||{{ottdp|0.6|2.5|ottdrev=r7191|ttdprev=r1210}}||Long format introduction date||no
|-
|2B||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|2C||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types||yes
|-
|2D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types||yes
|-
|2E||W||{{ottdp|12|no|ottdrev=g2183fd4dab}}||Maximum curve speed modifier||yes
|-
|2F||W||{{ottdp|13|no}}||Vehicle variant group||no
|-
|30||D||{{ottdp|13|no}}||Extra flags||??
|-
|31||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below||yes
|-
|32||W||{{ottdp|15|no|ottdrev=gd2496b6ec4}}||Cargo classes required for refittability||yes
|-
|33||W n*W||{{ottdp|15}}||List of badges||??
|-
|34||B n*B||{{ottdp|15|no|ottdrev=g52e97c981c}}||List of track types||should be same as front
|}
<references/>

= Description =

== Track type (05) ==
Set track type of vehicle: 0 = rail, 1 = monorail, 2 = maglev. For setting the appropriate traction type, see [[Action0Trains#Engine traction type 19|prop19]].

{{ottdp|1.0|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, this property is an index into the table instead.

{{ottdp|15|no|ottdrev=g52e97c981c}} Overwritten by prop 34.

== Speed (09) ==

Train speed is in units of mph*1.6, i.e. approximately km/h.

For wagons, this value is only used if the "wagonspeedlimit" switch is on, and it limits the speed of the train to that of the lowest wagon speed.  This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed.

For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit.

== Power (0B) ==

The power of the engine, in HP.

A value of 0 means that the vehicle will be a wagon, otherwise it will be an engine.

== Running cost base (0E) and factor (0D) ==

TTD calculates all costs by multiplying a 32-bit [[BaseCosts|base amount]] with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of train vehicles, the following base amounts are available depending on the vehicle type (the value here is a pointer into TTD's memory where the actual amount is stored):

{| |-
!Type!!Value!!in little-endian notation
|-
|Steam engines||4C30||30 4C 00 00
|-
|Diesel engines||4C36||36 4C 00 00
|-
|Electric engines||4C3C||3C 4C 00 00
|-
|Wagons||0||00 00 00 00
|}

Theoretically, you could use pointers to other base amounts available in TTD, but these are the numbers TTD uses for train vehicles.

The following are some real values for maintenance costs depending on the setting of the above two factors.  This value is correct for medium difficulty, but increases and decreases for hard and easy difficulties respectively.  These are the costs of a new game starting in 1921, because they obviously increase with inflation over time (unless noinflation is turned on).

'''Running cost base 4C30 (steam)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 42
|-
|10||$ 700
|-
|20||$ 1.400
|-
|80||$ 5.600
|-
|A0||$ 7.000
|-
|FF||$ 11.112
|}

'''Running cost base 4C36 (diesel)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 40
|-
|10||$ 650
|-
|20||$ 1.300
|-
|80||$ 5.200
|-
|A0||$ 6.500
|-
|FF||$ 10.318
|}

'''Running cost base 4C3C (electric)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 36
|-
|10||$ 600
|-
|20||$ 1.200
|-
|80||$ 4.800
|-
|A0||$ 6.000
|-
|FF||$ 9.524
|}

== Cost factor (17) ==

The cost factor is a bit-coded value which determines how expensive an engine is. There is no distinction between steam, diesel or electric engines, they all use the same cost factor. The table below gives you some values to use for finding the right price for your engines.

{| |-
!Cost factor!!Price
|-
|01||$ 3.124
|-
|10||$ 50.000
|-
|20||$ 100.000
|-
|80||$ 400.000
|-
|A0||$ 500.000
|-
|FF||$ 796.874
|}

== Engine traction type (19) ==

This sets the traction type of a train engine, i.e. whether it is powered by steam, diesel, electric, monorail or maglev technology.  It also sets the corresponding sound effect of the engine, and if property 22 is not set, the visual effect as well.

The following ranges are available (and it does not matter which value you pick):

{| |-
!Values!!Traction type
|-
|00..07||Steam
|-
|08..27||Diesel
|-
|28..31||Electric
|-
|32..37||Monorail
|-
|38..41||Maglev
|}
Default value is 00, i.e. steam. For setting the appropriate track type, see [[Action0Trains#Track type 05|prop05]].

{{ottdp|1.1|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, setting this property does NOT alter the track type.

== Sort vehicle list (1A) ==

This is not a property as such, but an action.  It forces TTDPatch to shuffle the vehicle this "property" is being set for in front of the vehicle with the given value of the property.  The order of this list is only used in the train purchase window.

For example, setting prop. 1A for vehicle 09 to a value of 07 would lead to the following internal list: ... 05 06 09 07 08 0A 0B ...

This property can not simply be overwritten, because the list is already shuffled when trying to do so.

{{ottdp|no|2.0}} It is possible to reset the list to its original order with a special action 0 that has num-info set to 0, and only sets property 1A for trains:
<pre>00 00 01 00 00 1A</pre>

Resetting the list should however only be done by sets that contain replacements for all train vehicles.

{{ottdp|0.7|no|ottdrev=r13831}} This property is an extended byte in OpenTTD since r13831!

== Powered train wagons (1B and 23, see also 22) ==

Normally, train wagons are unpowered in TTD, and if you set property 0B to a non-zero value, they become engines instead.  Therefore, to model real-life trains where wagons have power, a different mechanism is needed.
To make train wagons powered, you set property 1B of the '''engine''' instead of the wagon. This determines how much power each wagon adds to the train when attached to this engine. This only applies to wagons with a [[Action3|graphics override]] for this engine as well.  This means that for example passenger wagons (with an override) will add power, but coal wagons (with no override) will not.

In addition to adding power, these wagons are also heavier by the amount set in property 23.

== Refit cost (1C) ==

Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (27) is set, auto-refitting is allowed.

== Callbacks (1E, 31) ==
For trains, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 1E and 31 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|0||1||10||Powered wagons and visual effect
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated engines
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|-
|9||200||163||{{ottdp|15|no|ottdrev=gd2496b6ec4}}Custom refit
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

These callbacks do not need a bit to activate them, they are always active and will be used if defined in the action 3/action 2 chain.
{| |-
!Variable 0C value!!Callback
|-
|1D||Can wagon be attached
|-
|23||Additional text in purchase screen
|-
|31||Start/stop check
|-
|32||32-day callback
|-
|36||Change Vehicle Properties
|-
|15E||Refit cost
|}

== Coefficient of tractive effort (1F) ==

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

Theoretically, this value should be calculated by taking the ratio of adhesive weight W<sub>adh</sub> (i.e. the vehicle weight that rests on powered axles) times the coefficient of friction µ between the wheels and the rails to the total vehicle weight W, times 255, and convert to hex:

prop. 1F = HEX ((W<sub>adh</sub> * µ / W) * 255)

With prop. 1F having a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

Sometimes you know the real-life tractive effort instead of adhesive weight and coefficient of friction. To help calculating prop. 1F in that case, here's a small example using the NS 1600 (Electric) with a mass of 84 tons and real-life tractive effort (TE<sub>real</sub>) of 259 kN. To quickly find the value for property 1F you fill in the following formula:

prop. 1F = HEX ((TE<sub>real</sub> / (Mass * g) * 255)

That may look confusing but you already know all variables:

prop. 1F = HEX ((259 / (84 * 9.8) * 255)

prop. 1F = HEX (0.3146 *255) = HEX(80.229)

HEX calculations only work with figures in the natural domain: each figure has to be a positive and round figure. Therefore the value you convert to HEX isn't 80.229 but 80:

HEX 80 = 50

Property 1F for the NS 1600 (Electric) would then be: 1F 50.

== Coefficient of air drag (20) ==

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. 00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!! <16!! 16!! 24!! 32!! 48!! 64!! 96!! 128!! 192!! 256!! ...
|-
|c2|| 192|| 128|| 96|| 64|| 48|| 32|| 24|| 16|| 12|| 8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTD's consistent scaling. If a train doesn't reach its historical top speed, you might try setting the value of prop. 20 one or two steps lower than the default above, otherwise it's probably a good idea to leave it at the default.

== Shorter train vehicles (21) ==

This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly
<ref>{{ottdp|1.0|no|ottdrev=r15793}} This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.</ref>,
except at the end of the train
<ref>{{ottdp|<1.0|}} This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.</ref>. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).

<references/>

== Visual effects and wagon power (22) ==

By default, the visual effect of train engines is determined by the traction type (property 19). With this option you can change the type of effect as well as the position of it relative to the vehicle. (Note: for TTDPatch and OpenTTD up to r21229 only the positioning of steam actually works. For {{ottdp|1.1|no|ottdrev=r21230}} positioning diesel smoke and electric sparks works as well) The position of the effect provides a range from 0 to F that is added to the type of the effect.

Position 0 corresponds to a point half a vehicle length ahead of the vehicle, 4 is the front of the vehicle, 8 the middle, C the end and F is a half length behind the vehicle. Intermediate values are in-between.

Additionally, this property can be used to disable powered wagons of this type, although that is usually done with [[Callbacks#Visual_effect_and_wagon_power_.2810.29| callback 10]] instead (which has the same meaning as prop. 22, but is more flexible).

{| |-
!Range !!Effect type
|-
|00..0F||Use the default effect type, but reposition it. For engines this is defined via property 19, wagons have no default effect.
|-
|10..1F||Steam puffs
|-
|20..2F||Diesel fumes
|-
|30..3F||Electric sparks
|-
|40||Disable visual effect
|-
|41..7F||{{ottdp|1.5|no|ottdrev=r26747}} Create effects with [[Callbacks#Advanced_effect_creation_.28160.29|Callback 160]] using one of these spawning models:
* 41 Steam: Gradually less effects when approaching max speed
* 42 Diesel: Effect proportional to acceleration, no effect when idling at top speed
* 43 Electric: Random effect, gradually less likely when approaching max spped
* 44-7F Reserved
|-
|80+00..80+7F||Same as 00..7F above, but disable wagon power
|}

For example, 28 would make the wagon powered and emit diesel fumes, but 80+28 = A8 would only emit the diesel fumes without adding power.

== Miscellaneous flags (27) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|0.6|2.5}}|| Vehicle tilts in curves, and thus gets speed bonus <ref>The tilting speed bonus only applies if all vehicles in the train have this bit set. In TTDPatch it requires the "curves" switch to be on. For realistic curves, it gives the train two free curving pieces with no speed decrease, and for other settings, it increases the curves setting by one (0->1, 1->2, 2->2). In OpenTTD, the curve speed limit increases by 20% if 'realistic' acceleration is enabled, else there is no effect.
</ref>
|-
|1|| 2||{{ottdp|0.6|2.5}}|| Uses two company colors
|-
|2|| 4||{{ottdp|0.6|2.5}}|| Vehicle is a multiple unit (DMU/EMU), for colour selection
|-
|3|| 8||Varies|| {{ottdp|1.1|no|ottdrev=r21966}}Vehicle can be flipped around in the depot. <br>{{ottdp|13|no|no}}This flag is no longer required, vehicles can always be flipped.
<ref>From {{ottd|13|no}} onwards, OpenTTD will again allow all vehicles to flip, and will automatically adjust offsets accordingly. From {{ottd|13|no}}, if this flag is set, OpenTTD will not automatically apply the correct offsets for vehicles < 8/8 long, and will defer to offsets set by the grf. Do not set this flag unless you need it for a specific reason.
<br>
For {{ottd|1.1|r21966}} up to {{ottdp|12|no|no}} when you enable flipping of a vehicle in a depot you must make sure that the graphics are correctly aligned when flipped as well. Especially in the case of shortened vehicles.
<br>
Prior to {{ottd|1.1|r21966}} all non-multiheaded/non-articulated vehicles would be able to flip around in the depot. As such {{ottd|1.1|r21966}} disables a "feature" in OpenTTD, but often it makes no sense to flip vehicles around (symetric vehicles) or the graphics are wrong (most shortened vehicles), and thus only enabling this when the NewGRF developer says it is possible is better.
<br>
For all relevant OpenTTD versions, the flipping bit has no effect for multiheaded or articulated vehicles as they cannot be flipped in depot.
</ref>
|-
|4|| 10||{{ottdp|1.2|no|ottdrev=r23087}}|| Auto-refitting is enabled for refits where callback 15E allows it or prop 1C specifies zero cost
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}}|| Use cargo multiplier for default cargo (and load amount). See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}}|| Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}}|| [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

<references />

== Cargo classes (28, 29, 32) ==

To make vehicle sets more compatible with future new cargo definitions, these three properties allow vehicles to define what type of cargo they should be refittable to. A wagon will be refittable to all cargo types that match any of the classes set in prop. 28 ''and'' have all of the classes set in prop. 32, except for the ones that match any of the classes set in prop. 29. In addition, afterwards those cargo types listed in prop. 1D will be toggled. In terms of logic, it is

Refit list = (cargos from prop. 28 filtered by prop. 32 AND NOT cargos from prop. 29) XOR cargos from prop. 1D

This means, if a cargo type is in the list because it matches props 28/31 but not prop 29, having the respective bit set in prop. 1D will disable it again. Conversely, if the cargo type is not in the list, the bit in prop. 1D will add it. This way, if props. 28/29 are unset, prop. 1D will retain the original meaning, but it is still able to selectively add or remove certain cargo types even if props. 28/29 are used.

As a consequence, you have both full control over the cargo types that you know of (using prop. 1D), and those you don't know of yet (using props. 28/29). Leave the bits for cargos that you don't know of unset in prop. 1D, and set/clear the bits for known cargos to add/remove them from the list as appropriate.

{{ottd|1.2|r23291}} It is recommended to use properties 2C and 2D instead of property 1D, as property 1D behaves badly if the cargo classes of a cargo are ever changed.

The class list is a bit mask. See the action0 cargos page for bits and classes defined so far.

Take a look at [[Action0Cargos#Cargo classes 16|Action0 for cargos]] for the classes defined so far.

Note that cargo types may belong to several classes. This is the reason for making three properties, an additive, a filter, and a subtractive one, because this way a vehicle can be specified to be refittable to, for example, all express cargo that does not require refrigeration (i.e., from the default cargos, no food).
For the cargo types added in this way, the vehicle will probably have no specific graphics (in [[Action3|action 3]]) to show the cargo load.  In this case, the default will be used, which should therefore be sufficiently generic-looking if possible. However, using [[VariationalAction2/Vehicles#Vehicle cargo info 47|vehicle variable 47]] you can at least select the graphics most appropriate for the cargo type's class.
About the interaction with other properties take a look at the summary page about [[VehicleRefitting|vehicle refitting]].

Disclaimer: there is no guarantee that classes won't vary over time or between sets. The classes of a cargo may change between different versions of a specific industry/cargo newgrf, or different classes may be set for the same cargo label by different industry/cargo newgrfs. Feel free to use classes in your set for conveniently refitting to cargos, but if you - the vehicle author - care about specific cargos being transported in specific vehicles, use label based refits (changing labels without a very good reason is considered to be bad practice).

== Long format introduction date (2A) ==

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

== Custom cargo ageing period (2B) ==

This property allows to modify the period in ticks after which cargo carried by the vehicle is aged. By default, cargo is aged every 185 ticks. A value of 0 disables ageing of cargo. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

Changing this value from the default does not automatically make the vehicle earn more or less. Predicting the effect is complicated, as it depends on many things, including: vehicle speed, route length, route delays, transfer credits, the payment curve set by the cargo, and whether the cargo is already aged from a previous transfer when the vehicle loads it.

Authors are advised that tests show this property can lead to disappointment. Avoid, or use with caution.

== List of always refittable cargo types (2C, 2D) ==

These two properties allows to unconditionally include or exclude cargo types for refittability independent of any of the other refit properties or the cargo classes. If you specify a cargo type that is not available, the cargo type will be silently ignored.

The format for both properties is:

<pre>2C/2D <nvar> (<Index into cargo type table>){n}</pre>

That is you give the number of cargos in a single byte followed by a list of that length of indexes into the cargo translation table ([[CargoTypes|Type A]]).

== Maximum curve speed modifier (2E) ==

This property allows to give vehicles a maximum curve speed modifier. The given value is treated as a signed word with 8 fractional bits. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

The modifier is applied after the normal curve speed calculation is done using the formula max_curve_speed * (1 + prop 2E). This means that the default property value of 0 is equivalent to no change. While values less than -1.0 are technically possible, the resulting vehicle curve speed is clamped at 2 mph-ish to make sure vehicles don't become permanently stuck.

If different vehicles in a train have different curve speed modifiers, the lowest value wins.

== Vehicle variant group (2F) ==

This property supports grouping vehicles in the purchase menu (also the autoreplace menu). The property value is the ID of another vehicle in the same GRF which will act as the parent for vehicles in the group.

Groups can also be nested (this is experimental as of December 2022 and may change with testing).

See also [[Action0Trains#Extra flags (30)|vehicle extra flags]] which can influence the behaviour of vehicles in variant groups.

See also https://github.com/OpenTTD/OpenTTD/pull/10220

== Extra flags (30) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|13|no}}|| Disable "New Vehicle" news message for this engine
|-
|1|| 2||{{ottdp|13|no}}|| Disable "Exclusive Preview" for this engine
|-
|2|| 4||{{ottdp|13|no}}|| Variants - Include this variant when primary engine has "Exclusive Preview"
|-
|3|| 8||{{ottdp|13|no}}|| Variants - (Attempt to) Synchronize reliability the primary engine
|-
|}

== Extra callback flags (31) ==

See [[#Callbacks_.281E.2C_31.29]]

== Track type list (34) ==

List of track types for the vehicle. Data values are indices into the [[Action0Railtypes|rail type]] translation table.

The vehicle will be available/run on all listed track types.

Overwritten by prop 05.

= Example =

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

(A basic version)

<pre>10 * 14  00 00 03 01 02 09 C0 00 0B D8 0E 12 FD</pre>

{| |-
!'''Bytes'''!!'''Meaning'''
|-
|10||<Sprite-number>
|-
|14||<Length>: of the action in bytes; start counting at 0 (<action>)
|-
|00||<action>: sets this pseudo-sprite to function as action 0
|-
|00||<Feature>: In this case Train
|-
|03||<Num-props>: 3 Properties to change
|-
|01||<Num-info>: 1 vehicle ID to make changes to
|-
|02||<ids...>: vehcile ID (02 - Ploddyphut Choo-Choo)
|-
|||'''Properties'''
|-
|09||<Speed>
|-
|C0 00||<Value>: Value for Speed (192 Km/h)
|-
|0B||<Power>
|-
|D8 0E||<value>: value for Power (3800 HP)
|-
|12||<Sprite ID>
|-
|FD||<value>: FD for new graphics
|}
Since nfo version 7, so-called [[GRFActionsDetailed#Byte order|"escape sequences"]] have been introduced in an attempt to offer a more human-readable form.

Below is the same example as above, with escape sequences being used:

<pre>-1 * 0 00 00 \b3 01 \b*2 // \b<number of props to change> \b*<vehicle ID>

       09 \w192 // value for speed (192 Km/h)

       0B \w3800 // value for power (3800 hp)

       12 FD // use new graphics</pre>

Standardized Railtype Scheme

2025-06-12T16:12:43Z

Michi cc: /* Summary and notes for train sets */ Not yet a reality

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

All track gauges or types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''N''' is any gauge that is smaller than standard gauge, but not corresponding to any specific gauge that exists in real life, just like '''n''' is smaller than '''N''', but does not corresponds to a specific real-life gauge.

A train set may define vehicles for gauge '''n''' while not defining vehicles for gauge '''N''', but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

All energy source types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''D''' and '''d''' are treated as two different DC voltage levels, but do not correspond to any specific real-life voltage level used.

A train set may define vehicles for energy source '''d''' while not defining vehicles for energy source '''D''' (as an example, applies to other energy sources, too), but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary and notes for track sets ==
This section summarizes and comments the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
* Don't use specialized sub-types (e.g. d, a) unless you also use the main specialized class (e.g. D, A).
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always re-define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent label(s) from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
; Powered/compatible rail types
* For the speed limit/appearance class, every type should be powered and compatible with each other.
* Axle load classes implemented as real railtypes should be powered and compatible in ascending order, i.e. a lower axle load is compatible with a higher axle load, but not vice versa.
* Different energy sources should be compatible with each other but not powered on each other, expect for multi-system energy source classes.
* Different track gauge and type classes should be neither powered nor compatible with each other.

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary and notes for train sets ==
This section summarizes and comments the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
** Think about your set design and how for example standard gauge and narrow gauge vehicles differ to decide if a fallback from narrow gauge to standard gauge has gameplay meaning.
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded. This is a decision you need to make depending on the design of your train set.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations. This can mean that some vehicles may not appear with some set combinations, but if a player does not want to have e.g. narrow gauge tracks, they might not want narrow gauge vehicles either.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T15:42:16Z

Michi cc: /* Summary for train sets */ More commentary

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

All track gauges or types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''N''' is any gauge that is smaller than standard gauge, but not corresponding to any specific gauge that exists in real life, just like '''n''' is smaller than '''N''', but does not corresponds to a specific real-life gauge.

A train set may define vehicles for gauge '''n''' while not defining vehicles for gauge '''N''', but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

All energy source types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''D''' and '''d''' are treated as two different DC voltage levels, but do not correspond to any specific real-life voltage level used.

A train set may define vehicles for energy source '''d''' while not defining vehicles for energy source '''D''' (as an example, applies to other energy sources, too), but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary and notes for track sets ==
This section summarizes and comments the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
* Don't use specialized sub-types (e.g. d, a) unless you also use the main specialized class (e.g. D, A).
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always re-define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent label(s) from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
; Powered/compatible rail types
* For the speed limit/appearance class, every type should be powered and compatible with each other.
* Axle load classes implemented as real railtypes should be powered and compatible in ascending order, i.e. a lower axle load is compatible with a higher axle load, but not vice versa.
* Different energy sources should be compatible with each other but not powered on each other, expect for multi-system energy source classes.
* Different track gauge and type classes should be neither powered nor compatible with each other.

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary and notes for train sets ==
This section summarizes and comments the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
** Think about your set design and how for example standard gauge and narrow gauge vehicles differ to decide if a fallback from narrow gauge to standard gauge has gameplay meaning.
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
* The multi-system energy source classes (like e.g. Z or Y) are rarely appropriate for vehicles, as it would mean a vehicle needs both energy sources to be powered.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded. This is a decision you need to make depending on the design of your train set.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations. This can mean that some vehicles may not appear with some set combinations, but if a player does not want to have e.g. narrow gauge tracks, they might not want narrow gauge vehicles either.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T15:29:44Z

Michi cc: /* Summary for track sets */ Notes on compatible/powered.

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

All track gauges or types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''N''' is any gauge that is smaller than standard gauge, but not corresponding to any specific gauge that exists in real life, just like '''n''' is smaller than '''N''', but does not corresponds to a specific real-life gauge.

A train set may define vehicles for gauge '''n''' while not defining vehicles for gauge '''N''', but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

All energy source types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''D''' and '''d''' are treated as two different DC voltage levels, but do not correspond to any specific real-life voltage level used.

A train set may define vehicles for energy source '''d''' while not defining vehicles for energy source '''D''' (as an example, applies to other energy sources, too), but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary and notes for track sets ==
This section summarizes and comments the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
* Don't use specialized sub-types (e.g. d, a) unless you also use the main specialized class (e.g. D, A).
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always re-define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent label(s) from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
; Powered/compatible rail types
* For the speed limit/appearance class, every type should be powered and compatible with each other.
* Axle load classes implemented as real railtypes should be powered and compatible in ascending order, i.e. a lower axle load is compatible with a higher axle load, but not vice versa.
* Different energy sources should be compatible with each other but not powered on each other, expect for multi-system energy source classes.
* Different track gauge and type classes should be neither powered nor compatible with each other.

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T15:15:19Z

Michi cc: /* Energy source type class [***X] */ Extra comment about mixing D/s.

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

All track gauges or types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''N''' is any gauge that is smaller than standard gauge, but not corresponding to any specific gauge that exists in real life, just like '''n''' is smaller than '''N''', but does not corresponds to a specific real-life gauge.

A train set may define vehicles for gauge '''n''' while not defining vehicles for gauge '''N''', but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

All energy source types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''D''' and '''d''' are treated as two different DC voltage levels, but do not correspond to any specific real-life voltage level used.

A train set may define vehicles for energy source '''d''' while not defining vehicles for energy source '''D''' (as an example, applies to other energy sources, too), but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T15:09:25Z

Michi cc: /* Speed limit/appearance class [*X**] */ Moved example classes to Standardized Railtype Scheme extensions page

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

All track gauges or types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''N''' is any gauge that is smaller than standard gauge, but not corresponding to any specific gauge that exists in real life, just like '''n''' is smaller than '''N''', but does not corresponds to a specific real-life gauge.

A train set may define vehicles for gauge '''n''' while not defining vehicles for gauge '''N''', but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme extensions

2025-06-12T15:08:47Z

Michi cc: /* Speed limit class [*X**] */

==Multi-voltage Trains==
One might be interested in implementing a train which speed and/or power depends on the voltage in the overhead line electrification. In order for this to work properly the newgrf needs to test the track with [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] or [https://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Variables_that_require_an_argument NML tile_powers_railtype].

Below is an example from RUKTS code, where a train with a diesel generator has higher speed on high voltage ac tracks. We need to test for only SAAA if it is avaliable, as otherwise we would have the train gain the benefits on all electrified tracks. If it however isn't avaliable we still want to know if the track is electrified which is why we have the second part.

<code>railtype_available("SAAA") ? tile_powers_railtype("SAAA") : (tile_powers_railtype("SAAE") || tile_powers_railtype("ELRL"))</code>

==Rack rail==
There are two different types of rack rail engines, pure rack and rack and adhesion. Pure rack engines may only move on tracks fitted with racks (xRxx) whilst rack and adhesion engines may also move on regular tracks but at a lower tractive effort.

Rack rail is currently implemented in the speed class as a "special type", this is unfurtunate as the speed class would otherwise be trackset private.

===Alternative 1===

====Pure rack engines====
These engines should use *R** as label. A trackset could then prevent these trains from traversing *A** tracks.

====Rack and adhesion engines====
These engines should use *A** as label and test for *R** using [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] or [https://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Variables_that_require_an_argument NML tile_powers_railtype]. This assumes the trackset will allow *A** on *R**.

====Issues====
*Currently French Set Rails (the most popular rack-rail set) implements compatibility both ways which makes pure rack systems impossible.
*French Narrow Gauge Trains Set uses NRAN for rack and adhesion engines so tracksets can not support it as intended and pure rack systems at the same time.

===Alternative 2===

====Pure rack engines====
These engines should use *r** (not in scheme) as label. A trackset would then prevent these trains from traversing *A** tracks but allow them on *R**.

====Rack and adhesion engines====
These engines should use *R** as label and test for *r** using [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] or [https://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Variables_that_require_an_argument NML tile_powers_railtype]. Tracksets will allow *R** on *A** and *r**.

====Issues====
*Requires more track types than alternative 1.

=="Innsbruck 2022 Convention" for partial compliance==

This is really esoteric, but eh. It was the product of long discussion / debate / argument / reasoning between grf authors.

1. The Standardized Railtype Scheme '''is a useful tool''' for providing reliable compatibility between train grfs and railtype grfs.

2. The '''axle load class''' in the scheme presents a number of issues for compliance.

2.1. Over 10 years since the scheme was standardised, not many train grfs implement multiple axle load classes '''as required by the scheme'''. Known examples that '''do''' comply include Dutch Train Set, French Narrow Gauge Trains, and Finnish Trains.

2.2. Elements of the axle load rules have proven hard to interpret. For example:

* is it compliant to use ''fewer'' than 5 classes in a train grf? There is a lack of consensus on this.
* axle load is only one of many factors that govern whether a vehicle is compatible with a route, for example loading gauge, minimum curve, signalling types etc

2.3. Meanwhile ''multiple existing train grfs use class ''A'' for the axle load for all trains'' (except where relying on default railtypes such as RAIL and ELRL).

'''3. The Innsbruck 2022 Convention uses class ''A'' for axle load for '''all''' trains in a train grf (except where relying on default railtypes such as RAIL and ELRL).'''

This is '''not''' fully compliant with the Standardized Railtype Scheme and does not claim to be.

However train grfs using the Innsbruck 2022 Convention are ''broadly compatible'' with railtype grfs using the Standardized Railtype Scheme.

Obligatory XKCD link about 'standards': https://xkcd.com/927/

===Known issues===

Known problems are that trains using only class 'A' may limit the ability of railtype grf authors to achieve their design goals for separating railtypes by axle load.
But on reflection, it can be seen that a train grf might not be able to provide a broad enough range of vehicles to cover at least 5 axle load classes.

3.1. The Innsbruck 2022 Convention is '''not''' appropriate for train grf authors who wish to provide more than one axle load class.

3.2. The Innsbruck 2022 Convention treats the meaning of class ''A'' as ''undefined'', ''ignored'' or ''compatible with most restricted railtype'' for axle load.

Axle load class ''A'' '''cannot''' be safely interpreted as ''universal'' because from the perspective of a railtype grf ''A'' is ''most restricted railtype'', where ''universal'' is better represented as ''least restricted railtype''. Depending how many axle load classes are in use by the railtype grf, this could be class ''B'', ''C'', ''D'', ''E'' etc. To illustrate this issue, take the following scenario

* railtype grf defines axle loads ''A'' to ''E''. In this case the railtype grf author intends that ''A'' is compatible with the smallest range of vehicles, ''E'' is compatible with the largest range of vehicles, and ''B'', ''C'' and ''D'' are compatible with some intermediate ranges of vehicles
* but the vehicle grf author has defined all vehicles to be axle load ''A'' in an attempt to express this vehicle is ''universal''. The result in the game is that an identical range of vehicles will be compatible with railtypes ''A'' to ''E''.

This is clearly '''not''' the intended outcome of the railtype author. But nor is it clear within the spec that the vehicle author has particularly done anything wrong.

It ''would'' be possible to use railtype availability testing to adjust the vehicle property 05 (track_type) to fit the highest defined axle load (''E'' in this example case), but this is not insignificant work, and it's unlikely to be widely adopted by vehicle grf authors. Nor would this solution achieve ''universal'' as all vehicles in vehicle grf then would be incompatible with types ''A'' through ''D''.

3.3. When the Innsbruck 2022 Convention is used, this '''does not prevent''' a train grf being extended in some future release to achieve full compliance with Standardized Railtype Scheme. ''That choice remains with train grf authors''.

3.4. If 2012 could be revisited, providing an optional ''_'' axle load class in the Standardized Railtype Scheme for ''undefined'' would have been preferable, but as of 2022, ''A'' is already widely used for this purpose, and time travel is not known to be possible.

==Multi-voltage extensions==
These are extensions to the energy source type class currently supported by SETS and xUSSR Rails which allow trainsets to code trains which are limited to a certain selection of voltages. As stated in the energy source type class section this might not be of use for all sets, as such it is optional but still recommended for trainsets for ideal functionality with tracksets which support the extended labels.
{|
! colspan="2" | Specialized energy type classes !!Vehicle set fallback
|-
|* ||Equivilent to A, a, D and d || E
|-
| colspan="3" |  
|-
|' ||Equivilent to A, a and D || E
|-
|^ ||Equivilent to A, a and d || E
|-
|_ ||Equivilent to A, D and d || E
|-
|, ||Equivilent to a, D and d || E
|-
| colspan="3" |  
|-
|$ ||Equivilent to A and a || First A then E or just E
|-
|= ||Equivilent to D and d || First D then E or just E
|-
|) ||Equivilent to A and D || E
|-
|( ||Equivilent to A and d || E
|-
|] ||Equivilent to a and D || E
|-
|[ ||Equivilent to a and d || E
|}

==Maglev extensions==
These are extensions to the rail system and energy source type classes currently supported by RIMS, FRIMS and the Maglev Track Set which allow trainsets to code trains which use different, incompatible maglev variations. As stated in the energy source type class section this might not be of use for all sets, as such it is optional but still recommended for all maglevs in trainsets for ideal functionality with tracksets which support the extended labels.

===Rail System/Gauge [X***]===
{|
! !!Track type/gauge
|-
|L ||Maglevs that have a u-shaped track (SCMaglev)
|-
|T ||Maglevs that have a monorail track (Transrapid/China)
|}

=== Energy source type class [***X] ===
{|
! !!Electrification !!Vehicle set fallback
|-
|S ||Maglevs that use a synchronous linear motor ||N/A
|-
|I ||Maglevs that use a linear induction motor || N/A
|}

==JP+ extensions==
These are extensions to the gauge and energy source type classes currently supported by JP+ tracks and used by JP+ train sets.
===Rail System/Gauge [X***]===
{|
! !!Track type/gauge !!Vehicle set fallback
|-
|s ||Scotch gauge || S
|-
|_ ||Universal || N/A
|}

=== Energy source type class [***X] ===
{|
! !!Electrification !!Vehicle set fallback
|-
|I ||Linear induction motor || D
|}

==Possible additions==

There are a number of proposed labels for standardization of non-standardized labels...

'''CURRENTLY NOT IMPLEMENTED AND MOSTLY NOT OF VALUE'''

===Rail System/Gauge [X***]===
{| class="mw-collapsible mw-collapsed wikitable"
! !!Track type/gauge
|-
|_ ||Universal "cheat" rail; ALWAYS add "_H_c" and "_S_t" to EVERY [[NML:Railtypes#Railtype_properties|compatible_railtype_list (NML)]], and ALWAYS add "_S_t" to EVERY [[NML:Railtypes#Railtype_properties|powered_railtype_list (NML)]] if you intend to support this
|-
|0 ||(A number zero, not a letter "Oh") No track, eyecandy-use only
|-
|U ||[https://perma.cc/93VE-8JQZ "Ukrainian monorail" or Şaropoí̈zd (Шаропоїзд)], a u-shaped concrete "monorail trench" from 1920's Soviet Union; see [https://www.tt-forums.net/viewtopic.php?f=26&t=47432 the Yarmanchuk Express] for graphics
|-
|1 ||Early Monorail; See [https://perma.cc/6BVS-2P2X here] and [https://perma.cc/VCG2-ATUA here]
|-
|G ||Gyrail; [https://en.wikipedia.org/wiki/Gyro_monorail Gyro monorail/Gyroscopic monorail/Gyro-stabilized monorail] for description and IRL example, and [https://wikimon.net/Trailmon here] ([https://web.archive.org/web/20240227205547/https://wikimon.net/Trailmon archived]) for good fictional examples
|-
|A ||Alweg-based Monorail
|-
|m ||Minimum gauge rail; [https://en.wikipedia.org/wiki/Minimum-gauge_railway 15 in (381 mm), 400 mm (15+3⁄4 in), or 16 in (406 mm)]
|-
|2 ||Minimum gauge rail; [https://en.wikipedia.org/wiki/Minimum-gauge_railway 18 in (457 mm), 19 in (483 mm), 500 mm (19+3⁄4 in) or 20 in (508 mm)]
|-
|n ||600mm "Decauville" or "Feldsbahn", formerly labelled "NG60" before standardization; the most common narrow gauge track type in OpenTTD other than metre gauge, 600mm gauge is thus ideal for taking up the "n" gauge, though this is an ultimately optional distinction
|-
|7 ||750mm, Bosnian gauge (760 mm), and 762mm; all start with 7 and are close in size
|-
|3 ||Swedish 3 foot (891 mm), 900mm, 3 foot (914 mm) and Italian Metre (950mm) gauges
|-
|R ||Metre gauge; potentially compatible with base tramtype "RABN", most early tramways were metre gauge
|-
|4 ||4 foot gauge (1219 mm), and possibly 4'6" in. (1372 mm) if standardization is needed for 1372mm
|-
|s ||Scotch gauge (1372 mm)
|-
|S ||Standard gauge; already implemented in original standardized railtype scheme, but could include near-standard (1422+ mm) as well as existing true standard (1435 mm) and is also potentially compatible with the SAbN tramtype
|-
|X ||Omni-gauge rail (for at-grade multi-gauge crossings and stations); ultrabroad/secondary broad/primary broad/standard/primary narrow/secondary narrow gauge. Use this if you don't mind gameplay abstractions but don't want physically impossible combinations (e.g. rail, monorail and maglev cannot have any level crossings with each other). Specifically, this accommodates B (ultrabroad), g (2140 mm), V (1600mm), S (1435 mm), R (1000 mm), and n (600 mm).
|-
|x ||Multi-gauge rail (for at-grade multi-gauge crossings and stations); secondary broad/primary broad/standard/primary narrow/secondary narrow. Specifically, this accommodates g (2140 mm), V (1600mm), S (1435 mm), R (1000 mm), and n (600 mm). Use if you want to provide a cheaper alternative to X that doesn't support fictional "supertrain" gauges.
|-
|<nowiki>+</nowiki> ||Quad-gauge (Four-gauge) rail (for at-grade multi-gauge crossings and stations); secondary broad/primary broad/standard/primary narrow. Specifically, this accommodates g (2140 mm), V (1600mm), S (1435 mm), and R (1000 mm). Use with minus (<nowiki>-</nowiki>) if you want to give a bit of a puzzle to players over how to design a network limited by a "one or the other" pair of railtypes.
|-
|<nowiki>-</nowiki> ||Four-gauge rail (for at-grade multi-gauge crossings and stations); primary broad/standard/primary narrow/secondary narrow. Specifically, this accommodates V (1600mm), S (1435 mm), R (1000 mm), and n (600 mm). Use with plus (<nowiki>+</nowiki>) if you want to give a bit of a puzzle to players over how to design a network limited by a "one or the other" pair of railtypes.
|-
|b ||Broad gauge rail - As broad gauge is a rare tracktype, it may still be feasible to cement B and b as broad gauges of two differing sizes, but the rarity among gauges in the real world would need to match; Italian (1445 mm), Dresden (1450 mm) and Leipzig (1458 mm) gauges are all based on streetcar/tram systems and may be better grouped here
|-
|t ||Greater Toronto Area streetcars (1495 mm)
|-
|5 ||1520mm and 5 foot (1524 mm) gauges
|-
|V ||Pennsylvanian (1581 mm and 1588 mm) and Australian "Victorian" (1600 mm) gauges
|-
|6 ||6 foot (1829 mm) broad gauge
|-
|g ||Brunel's Great Western Railway gauge (2140 mm)
|-
|B ||Biggest Broad gauge rail - As broad gauge is a rare tracktype, and the variation in common real life track types too wide, it may be desirable to cement B and b as broad gauges of two differing sizes; With no real life examples that match the usage frequency of "B", the gauge might best draw inspiration from the infamous [https://en.wikipedia.org/wiki/Breitspurbahn Breitspurbahn] (3000 mm) and [https://perma.cc/KQ2Z-5RCR the never-built vehicles designed for it], or from the [https://en.wikipedia.org/wiki/Brighton_and_Rottingdean_Seashore_Electric_Railway Brighton & Rottingdean Seashore Electric Railway] (18 ft/5,486 mm)
|-
|F ||Flightrail; A [https://web.archive.org/web/20231213122530/http://www.flightrail.com/ system capable of high speeds and steep hill grades] that uses a pneumatic pipe for propulsion (see "P" under energy sources), and ''wheels pointed inwards at a 45-degree angle''
|}

It might be preferred to instead use/keep "B" for "all (current) broad gauges" (mostly Victorian gauge) instead using lowercase "b" for Brunel/GWR broad gauge. This wouldn't be to different from narrow gauge since the lesser used ones are lowercase and fallback to the uppercase ones.

=== Speed limit/appearance class [*X**] ===

The speed limit class may also be used for some advanced features of the label scheme, like specialized track types and eyecandy purposes. Be careful not to break the compatibility with other sets when using the speed limit class for these purposes.

An example of a special use is rack rail. In the French set it is used to give rack rail engines a higher speed and TE than normal rail engines when used on rack rail. When defining trains with a special speed limit class, always allow a fallback to speed limit class A via the railtype table.

An example of eyecandy use are urban tracks. These are a variation of regular tracks, but with concrete ground tiles to better match the urban environment. Train sets must not define vehicles for eyecandy classes. If you think you have special vehicles that should only run on the eyecandy class, it is ''not'' eyecandy but a separate track gauge/type.

The appearance class can be tested for by trains using [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] (which the French Set uses to change vehicle properties on rack rail), but this is generally not standardized, limits interoperability and is only useful for co-developed train and track sets.

The following special and eyecandy classes have been defined so far:

{|
! !!Description !!Type !!Used by
|-
|A-H ||speed limits ||colspan="2"| reserved
|-
|K-R ||rack rail with speed limits, that allows rack-equipped vehicle to not slow down going uphill ||special ||French Set Rails
|-
|k-r ||rack rail with speed limits, that powers a rack-only vehicle ||special ||
|-
|S ||subterranean ||eyecandy ||Metro Track Set
|-
|s ||subterranean (low-clearance) ||eyecandy, should not be supported by double-deck passenger carriages or double-stack container wagons ||
|-
|U ||urban ||eyecandy ||Metro Track Set
|}
Rack rail needs a bit greater of a explanation, ideally it would be coded in a way where both pure rack and rack-and-adhesion systems are supported.
This can be achieved by making regular tracks powered on rackrail without the opposite being true. This means vehicles defined for NRAN can't go on NAAN (like a pure rack system) but NAAN vehicles can go on NRAN (like a rack-and-adhesion system). Currently French Set Rails (the most popular rack set) implements compatibility both ways which makes pure rack systems impossible.

Should another rack rail set be implemented, it might be prudent to make K-R equivalent to A-H for rack-and-adhesion, and k-r equivalent to A-H for rack rail only.

=== Axle load class [**X*] ===
{| class="mw-collapsible mw-collapsed"
! !!Indefinite !!Generic !! First usage
|-
|c ||Horse-drawn Wagonway ||1 metric tonne (1000kg) per axle || style="text-align:right;"|1594
|-
|b ||Iron Plateway ||1 metric tonne (1000kg) per axle || style="text-align:right;"|1799
|-
|a ||Prototype Rails ||5 metric tonnes (5000kg) per axle; Because reserved by examples || style="text-align:right;"|1820
|-
|A ||Very Low (2012 OG Default)||10 metric tonnes (10000kg) per axle || style="text-align:right;"|1828
|-
|B ||Low (2024 "New" Default) ||20 metric tonnes (20000kg) per axle || style="text-align:right;"|1968
|-
|C ||Medium ||30 metric tonnes (30000kg) per axle || style="text-align:right;"|~1978
|-
|D ||High ||40 metric tonnes (40000kg) per axle || style="text-align:right;"|1988
|-
|4 (Formerly d) ||High, extra-lean freight bogies ||50 metric tonnes (50000kg) per axle || style="text-align:right;"|2008
|-
|E ||Very High ||50 metric tonnes (50000kg) per axle (update in 2030 or so?)|| style="text-align:right;"|~2028
|-
|F ||Future-proofing ||No limit per axle (update in 2050 or so?) || style="text-align:right;"|~2048
|}

If the above scheme is used, "d" should NEVER be used as the axle weight of a railtype. Instead, if your train set supports axle weights, use SAdN/SAdE/etc. as a vehicle's axle weight if they are a freight car available between 2008 and 2028 but are more than 40 metric tonnes (40000kg) per axle, and add the railtype to the [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]] of SADN or equivalent.

====Axle Loads by Real World Implementation====
The table below is compatible with those above but functions differently than the ones above. It assumes that, in lieu of a train set that has ever implemented "d" as an axle weight, that instead "4" be used and a "3" placed between C and D for similar reasons. All the same classes are listed, however axle weight guidelines have been run by a research LLM which suggested different ranges of weight and different dates of availability. 4 is identical to d in practice. If "d" is not defined as a lighter axle weight than "c", then **4* should be used alongside it in an alternative_tracktype_list for any **D** track type with axle weight "D". If "d" is defined as a lighter axle weight than "c", only tracktypes with axle weight "4" (**4*) should be listed in the alternative_tracktype list for any **D* tracktype.

Use **4* on all applicable rolling stock going forward, and rely on track sets to define "d" for vehicle sets.

{| class="mw-collapsible mw-collapsed"
! !!Indefinite !!Generic !! First usage
|-
|c ||Horse-drawn Wagonway ||1 metric tonne (1000kg) per axle || style="text-align:right;"|1594
|-
|b ||Iron Plateway ||5 metric tonnes (5000kg) per axle || style="text-align:right;"|1799
|-
|a ||Prototype Rails ||10 metric tonnes (10000kg) per axle; Because reserved by examples || style="text-align:right;"|~1820 (Focused on carrying capacity over speed)
|-
|A ||Very Low (2012 OG Default)||15 metric tonnes (15000kg) per axle || style="text-align:right;"|~1870
|-
|B ||Low (2024 "New" Default) ||20 metric tonnes (20000kg) per axle || style="text-align:right;"|~1890
|-
|C ||Medium ||26 metric tonnes (26000kg) per axle || style="text-align:right;"|~1910
|-
|3 ||Medium, lightweight "FLEXX Eco" and "FLEXX Eco Commuter" bogies ||26 metric tonnes (26000kg) per axle || style="text-align:right;"|2001 (FLEXX Eco)
|-
|D ||High ||31 metric tonnes (31000kg) per axle || style="text-align:right;"|~1930
|-
|4 (Formerly d) ||High, extra-lean "DYNAFREIGHT" and "FLEXX Eco Regional" bogies ||30 metric tonnes (30000kg) per axle || style="text-align:right;"|2016 (FLEXX Eco, Regional var.)
|-
|E ||Very High ||40 metric tonnes (40000kg) per axle (update in 2030 or so?)|| style="text-align:right;"|1988
|-
|F ||Fortescue/Future-proofed ||No limit per axle (update in 2050 or so?) || style="text-align:right;"|2008
|}

=== Energy source type class [***X] ===
{| class="mw-collapsible mw-collapsed wikitable"
! !!Electrification !!Fallback !!Notes
|-
|1 ||Unspecified monorail electrification |||MONO (the whole label) ||
|-
|t ||"Universal custom tunnel" (for diagonal sub-surface "rail tunnels" that use decorative track types to complete the illusion) ||c, then p, then 7, then U (mandatory) ||
|-
|<nowiki>-</nowiki> ||Universal energy type (''not'' meant to replace "***N"; use for vehicles such as driving cabs which cannot move under their own power regardless, if desired) ||N/A (Be sure to put "***E" in the [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]] of a "***-" label) ||(''Do not give a fallback or use for railtypes, this is for unpowered "locomotives" only!'')
|-
|5 ||750v DC Outer 3rd Rail ("MTRO" or "SA_3") and 630v DC Inner 3rd/4th Rail; a total of 5 rails (2 for wheels, 3 for electricity), plausible in the London Underground network ||3 or 4 ||
|-
|U ||750v DC Outer 3rd Rail ("MTRO" or "SA_3"), 630v DC Inner 3rd/4th Rail and universal catenary (SAEE); a total of 5 rails (2 for wheels, 3 for electricity) if only one gauge, plausible in the London Underground network and an "ultimate" dual rail electrification without being a cheat (make it expensive or toggle-able?) as SAEU or as XAEU (universal dual rail electrified tracks) ||E ||
|-
|7 ||750v DC Outer 3rd Rail ("MTRO" or "SA_3"), 630v DC Inner 3rd/4th Rail, Three-phase AC (SA_T) 3rd/4th rail & catenary, and universal catenary (SA_E); a total of 7 rails (2 for wheels, 5 for electricity) if only one gauge, a truly universal dual rail electrification without being impossible (make it VERY expensive or toggle-able so it isn't cheat-y?) as SAE7, XAE7 or even as XRE7 (combination of ALL two-rail track gauges with universally-compatible electrification including an outer 3rd rail and a paired set of inner 3rd/4th rails, and a rack rail in the exact center; improbable, but not physically impossible) ||U ||
|-
|<nowiki>+</nowiki> ||750v DC catenary ||U, then E ||
|-
|6 ||600v DC catenary ||U, then E||
|-
|z ||Atypical catenary voltage ||U, then E
|-
|P ||Pneumatic tube with physical piston slit, or closed pneumatic tube with magnetic piston (i.e. that used by [https://web.archive.org/web/20231213122530/http://www.flightrail.com/ Flightrail]) ||N/A ||
|-
|p ||Pneumatic and universal electrical power ||P or 7 (Be sure to put "***_" and ***P" in the [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]] of a "***p" label) || XREp is a combination of ALL two-rail track gauges with improbably high axle load with universally-compatible electrification including an outer 3rd rail and a paired set of inner 3rd/4th rails, and a rack rail in the exact center; improbable, but not physically impossible)
|-
|c ||Cheat electrification type; use solely for the "_R_c" and "_R_t" railtype labels specifically (runs everything if coded properly), the latter ("_R_t") is for tunnels, while the former ("_R_c") is for "cheat rail upgrade" newgrfs ||p, then 7, then U, then E, then N, then "SA_-" (the whole label) ||
|}

Standardized Railtype Scheme

2025-06-12T14:57:10Z

Michi cc: /* Track gauge and type class [X***] */

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

All track gauges or types are abstractions of real-life types and do not correspond to specific examples used in real-life. For example '''N''' is any gauge that is smaller than standard gauge, but not corresponding to any specific gauge that exists in real life, just like '''n''' is smaller than '''N''', but does not corresponds to a specific real-life gauge.

A train set may define vehicles for gauge '''n''' while not defining vehicles for gauge '''N''', but this is likely only useful for sets that are specifically designed to be used along-side other sets, and the used railtype fallbacks should be carefully considered.

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

The appearance class can be tested for by trains using [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] (which the French Set uses to change vehicle properties on rack rail), but this is generally not standardized, limits interoperability and is only useful for co-developed train and track sets.

The following speed limit/appearance classes have been defined so far:

{|
! !!Description !!Type !!Used by
|-
|A-H ||speed limits ||colspan="2"| reserved
|-
|R ||rack rail, that allows rack-equipped vehicle to not slow down going uphill ||special ||French Set Rails
|-
|S ||subterranean ||appearance ||Metro Track Set
|-
|U ||urban ||appearance ||Metro Track Set
|}

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T14:45:38Z

Michi cc: /* When to use the scheme and when not to use the scheme */ Added

This railtype label scheme aims to provide a way to allow players to easily mix and match different train and track sets. It does this by grouping the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type. To limit combinatorial explosions of rail types, the track properties are abstracted away from strict real-life representations.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set. Additionally, due to the decoupling, depending on the specific train and track sets used, not all defined vehicles and/or track types might be available in a specific set combination. This is fully intended behaviour.

== When to use the scheme and when ''not'' to use the scheme ==

When to use:
* If you only want to develop a track or a train set.
* If you want players to be able to mix-and-match sets.
* If you are okay with abstractions from real life.

When ''not'' to use:
* If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
* If you want your tracks or vehicles to exactly mirror real-life counterparts down to the last mm of gauge width.
* If your train set is specifically designed to work with your track set only.
* If you feel the compulsory need to fill all 64 railtype slots.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

The appearance class can be tested for by trains using [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] (which the French Set uses to change vehicle properties on rack rail), but this is generally not standardized, limits interoperability and is only useful for co-developed train and track sets.

The following speed limit/appearance classes have been defined so far:

{|
! !!Description !!Type !!Used by
|-
|A-H ||speed limits ||colspan="2"| reserved
|-
|R ||rack rail, that allows rack-equipped vehicle to not slow down going uphill ||special ||French Set Rails
|-
|S ||subterranean ||appearance ||Metro Track Set
|-
|U ||urban ||appearance ||Metro Track Set
|}

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T14:02:26Z

Michi cc: /* Speed limit class [*X**] */ Speed limit class is also for appearance

This railtype label scheme aims to bring order to the uncontrolled growth of railtype labels. It groups the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

=== Speed limit/appearance class [*X**] ===
The second position in the railtype label defines the speed limit/appearance class. This can be used to provide tracks with different speed limits or appearance variations. The speed limit/appearance class is ''not'' used for trains and a train set should always use the class letter '''A''' in this position.

There is no fixed numeric mapping for this class, but speed limits should start at '''A''' for the lowest speed limit and progress with '''B/C/...''' for higher limits. If you do not want to employ speed limits in your track set, always use the class '''A'''.

Additionally this class can also be used to distinguish different track appearances like normal or full width ballast, grass or concrete ground, etc. Train sets must not define vehicles for appearance classes. If you think you have special vehicles that should only run on the appearance class, it is ''not'' appearance but a separate track gauge/type.

The appearance class can be tested for by trains using [https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2/Vehicles#Track-type_test_against_another_track-type_.2863.29 var 63] (which the French Set uses to change vehicle properties on rack rail), but this is generally not standardized, limits interoperability and is only useful for co-developed train and track sets.

The following speed limit/appearance classes have been defined so far:

{|
! !!Description !!Type !!Used by
|-
|A-H ||speed limits ||colspan="2"| reserved
|-
|R ||rack rail, that allows rack-equipped vehicle to not slow down going uphill ||special ||French Set Rails
|-
|S ||subterranean ||appearance ||Metro Track Set
|-
|U ||urban ||appearance ||Metro Track Set
|}

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Standardized Railtype Scheme

2025-06-12T13:44:44Z

Michi cc: /* Axle load class [**X*] */ Improve guidance and remove useless table.

This railtype label scheme aims to bring order to the uncontrolled growth of railtype labels. It groups the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard/broad gauge
|-
|d ||Dual gauge rail, standard/narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

=== Speed limit class [*X**] ===
The second position in the railtype label defines the speed limit class. These classes do not map to a fixed numeric value, but are used to define an internal speed limit order for the track set. This means that if your track set has two different speed limits for track types that are otherwise identical, you'll use letters A and B here. In case of three different speed limits, use A, B and C. In case your track set does not employ speed limits, always use A. Train sets do not care about the speed limit, and will always set the lowest speed class, i.e. A.

This gives for instance the following options:

<div style="float:left;">
<div style="float:left;">
{|
! !!Speed limit class
|-
|A ||no speed limits
|}
</div>
<div style="float:left;">
 OR 
</div>
</div>
<div style="float:left;">
<div style="float:left;">
{|
! !!Speed limit class
|-
|A ||low speed
|-
|B ||high speed
|}
</div>
<div style="float:left;">
 OR 
</div>
</div>
<div style="float:left;">
<div style="float:left;">
{|
! !!Speed limit class
|-
|A ||low speed
|-
|B ||medium speed
|-
|C ||high speed
|}
</div>
<div style="float:left;">
 etc. 
</div>
</div>
<div style="clear:left;"></div>

The speed limit class may also be used for some advanced features of the label scheme, like specialized track types and eyecandy purposes. Be careful not to break the compatibility with other sets when using the speed limit class for these purposes.

An example of a special use is rack rail. In the French set it is used to give rack rail engines a higher speed and TE than normal rail engines when used on rack rail. When defining trains with a special speed limit class, always allow a fallback to speed limit class A via the railtype table.

An example of eyecandy use are urban tracks. These are a variation of regular tracks, but with concrete ground tiles to better match the urban environment. Train sets must not define vehicles for eyecandy classes. If you think you have special vehicles that should only run on the eyecandy class, it is ''not'' eyecandy but a separate track gauge/type.

The following special and eyecandy classes have been defined so far:

{|
! !!Description !!Type !!Used by
|-
|A-H ||speed limits ||colspan="2"| reserved
|-
|R ||rack rail, that allows rack-equipped vehicle to not slow down going uphill ||special ||French Set Rails
|-
|S ||subterranean ||eyecandy ||Metro Track Set
|-
|U ||urban ||eyecandy ||Metro Track Set
|}

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a higher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Ideally, all five standard axle load classes should be used, but a train set may use only some weight classes, as the vehicle rooster might not make it feasible to use all five. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. If you do not use all classes, try to spread the classes out (don't use '''A''' and '''B''' for two classes, but e.g. '''B''' and '''D''').

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existence of any other class than '''A''' through '''E''', so think about providing appropriate fallbacks in your railtype table. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|Y ||4th rail and catenary electrification || 4 or E
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || First A then E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || First A then E
|}

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 64 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

==Extensions and best practice==
See [https://newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions Standardized Railtype Scheme extensions]

Version numbers

2025-01-11T14:52:19Z

Michi cc: /* NFO version */ Fix NFO doc linkl.

There are various version numbers involved in these NewGRF specs. This page clarifies the terms for version numbers.

== Version of a specific NewGRF ==
{{ottdp|1.1|no}}

The version number of a specific NewGRF distinguishes releases of the same NewGRF and defines which release is "newer" or "older".
This has no effect on the NewGRF specs or general behaviour of the NewGRF.
A NewGRF defines its version using [[Action14#GRF_version_.28.22INFO.22_-.3E_.22VRSN.22.29|Action 14]],
it can also define a [[Action14#Minimal_compatible_GRF_version_.28.22INFO.22_-.3E_.22MINV.22.29|minimum version]] to which it is savegame compatible.

Before the introduction of Action14 - and version numbers in it - NewGRFs used to change the GRFID in case of savegame-incompatibility.
However, this was not done consistently by NewGRF authors, esp. since it caused problems in other places (e.g. NewGRFs testing for other NewGRFs).

== GRF version ==

The GRF version defines the version of the NewGRF specs to which a NewGRF adheres.
Changing the GRF version of a GRF is likely to affect the operativity of a NewGRF as it might change the behaviour of various NewGRF features.

Throughout the specs the dependencies and changes between GRF versions are indicated using the {{grf|}} icon.

A NewGRF defines the version of the specs it adheres to within its [[Action8]].

=== GRF version 0 and 1 ===
{{ottdp|no|no}}

These GRF versions are from the alpha and beta days of NewGRFs in general.
Especially version 1 introduced [[Action8]] which allows a NewGRF to specify the GRF version it adheres to.
GRF version 2 concurs with TTDPatch 2.0, the first stable version of TTDPatch supporting NewGRFs. It comes along with a hard compatibility cut in NewGRFs:
TTDPatch 2.0 is the first version to support GRF version 2, while it removes support for version 0 and 1 at the same time (which implies making Action 8 mandatory).

During the development of the GRF specs various features were designed, implemented and redesigned again. As such GRF version 2 is the first stable version of the specs.

=== GRF version 2 to 6 ===
{{ottdp|0.6|2.0}}

These GRF versions were introduced at somewhat arbitrary spots of TTDPatch development to allow NewGRFs to specify requirements for newer GRF features.
Later this approach of versioning the specs was dropped. Instead NewGRFs can now read and test the TTDPatch / OpenTTD version in [[Action9]] and disable themself using [[ActionB]] with an appropiate error message.

=== GRF version 7 ===
{{ottdp|0.6|2.5}}

GRF version 7 makes various semantic changes to various NewGRF features. The same code can be valid for both version 6 and 7, but will have a different meaning.
Most notable changes are:
* Language codes in [[Action4]] were completely redesigned.
* Various callbacks, properties and variables use cargobits instead of cargoslots.
The changes are described in detail on the pages for the features they affect.

=== GRF version 8 ===
{{ottdp|1.2|no}}

GRF version 8 again makes various semantic changes to various NewGRF features.
Most notable changes are:
* Various compatibility layers within the specs were removed to simplify writing NewGRFs resp. to remove arbitrary restrictions.
: E.g. the special meaning of 0xFF?? callback results was removed. Also all callbacks are 15bit callbacks now.
* All remnants of cargoslots were removed. (Except for the cargo definition itself of course.)
* Various parts of the specs were clarified, various callbacks which allowed various results with the same meaning before now only allow definite values for every possible result, while the other values stay reserved.
: E.g. callbacks results which were previously only tested for zero or non-zero must now return a specific value 0 or 1.
* All "height" variables were revised to better distinguish height in heightlevels or in pixels. This is a preparation for the introduction of more than 16 heightlevels.

== GRF container version ==

The GRF container format is the binary format of the GRF file. While the GRF version controls the meaning of the content of a NewGRF, the
GRF container version specifies the storage format for it. As such this version affects the software which reads/writes NewGRFs like grfcodec, nml, and of course also
OpenTTD and TTDPatch.

The GRF container format is specified in the [https://raw.githubusercontent.com/OpenTTD/grfcodec/refs/heads/master/docs/grf.txt grfcodec documentation].

=== GRF container version 1 ===
{{ottdp|0.6|2.0}}

This is the traditional file format from TTD.

=== GRF container version 2 ===
{{ottdp|1.2|no}}

This is a new file format introduced in GRFCodec 6.0. Implementations which only know GRF container version 1 will consider GRFs with this version empty / invalid.

New features in this version are:
* Pseudosprites (and binary include sprites) can be bigger than 64KB.
* Realsprites can be higher than 255 pixels.
* Realsprites can contain various versions of the same sprite in different zoom levels and colour depths (8bpp/32bpp).

There are no implications between GRF container version, GRF version and NFO version. Though of course some things are only possible with GRF container version 2.

== NFO version ==

This is the file format of NFO files, the input/output of GRFCodec and NFORenum.
There are no implications between GRF container version, GRF version and NFO version. Though of course some things may only be represented using newer NFO versions.

The differences between the formats are ''documented'' in the [https://github.com/OpenTTD/grfcodec/blob/master/src/readinfo.cpp GRFCodec source code],
which can still read all formats (though not write).

=== NFO version 1 to 7 ===

Along these versions numerous advanced syntax forms were added to GRFCodec. However, every version can be converted into every other of these versions without losing
information when encoding/decoding NewGRFs (except source code comments, which are lost when encoding GRFs). Though older NFO versions might not be that comfortable
for representing certain GRF features (e.g. binary include sprites).

=== NFO versions 8 to 31 ===
Historically the numeric values of GRF versions and NFO versions were often the same (esp. for the long lasting versions 6 and 7), causing quite some confusion among NewGRF authors, which then used the version numbers
incorrectly. When GRF version 8 coincided again (time-wise) with the requirement for a new NFO version, it was decided to skip NFO versions 8 to 31 to make the numeric values
vastly different and thus making confusion less likely.

The value "32" for the new version was picked for unspecified reasons. Rumours say the value 32 stands for:
* Support for 32bpp graphics.
* Support for GRF container version 2.0. (Versions are usually encoded hexadecimal, and 20h = 32)

=== NFO version 32 ===

NFO version 32 adds support for GRF container version 2 specific features like 32bpp graphics or zoom-level specific graphics.
However, NFO version 32 and earlier versions can also be encoded into GRF container version 1 resp. 2.
Encoding into GRF container version 1 or decoding into NFO version < 32 might drop additional sprites though, which cannot be represented in those formats.

== TTDPatch version ==

Certain NewGRF features are only supported starting from certain TTDPatch versions on. These version requirements are mentioned throughout the specs using the {{ttdp|}} icon.
NewGRFs can check the TTDPatch version using [[Action9]] for variables [[GlobalVariables|0B and 1D]] and disable themself using [[ActionB]].

TTDPatch is versioned in alpha, beta and stable versions.
However, before 2.6 alphas the alpha versions were named with different version numbers than the beta/stable versions they would lead to; instead they used the previous stable version incremented by 0.0.1.

{| |-
! Series !! Alpha versions !! Beta versions !! Stable !! Maintenance releases of stables
|-
| 1.9 <ref>These versions had no NewGRF support at all and are only listed to explain the following lines.</ref> || 1.8.1 alpha XX || 1.9 beta X || 1.9 ||
|-
| 2.0 || 1.9.1 alpha XX || 2.0 beta X || 2.0 || 2.0r1
|-
| 2.5 || 2.0.1 alpha XX || 2.5 beta X || 2.5 <ref>Not released yet.</ref> ||
|-
| 2.6 || 2.6 nightly rXXXX || || ||
|}

<references/>

== OpenTTD version ==

Certain NewGRF features are only supported starting from certain OpenTTD versions on. These version requirements are mentioned throughout the specs using the {{ottd|}} icon.
NewGRFs can check the OpenTTD version using [[Action9]] for variables [[GlobalVariables#OpenTTD_Version_.2821_.2F_A1.29|21 and 1D]] and disable themself using [[ActionB]].

OpenTTD is versioned in alpha, beta and stable versions. The major and minor version number stays the same for alphas, betas and stables leading to each other,
except when the major version number is increased.

{| |-
! Series !! Alpha versions !! Beta versions !! Stable !! Maintenance releases of stables
|-
| 0.6 || 0.6 nightly rXXXX || 0.6.0-beta X || 0.6.0 || 0.6.x
|-
| 0.7 || 0.7 nightly rXXXX || 0.7.0-beta X || 0.7.0 || 0.7.x
|-
| 1.0 || 0.8 nightly rXXXX, 1.0 nightly rXXXX <ref>The nightlies changed the version after the decision that 1.0 would follow 0.7 instead of 0.8.</ref> || 1.0.0-beta X || 1.0.0 || 1.0.x
|-
| 1.1 || 1.1 nightly rXXXX || 1.1.0-beta X || 1.1.0 || 1.1.x
|-
| 1.9 || 1.9 nightly YYYYMMDD <ref>Since 1.9 nightlies no longer use a revision number, but a date.</ref> || 1.9.0-beta X || 1.9.0 || 1.9.x
|-
| 12 <ref>Version 1.11 was followed by version 12.</ref> || 12 nightly YYYYMMDD || 12.0-beta X || 12.0 || 12.x
|}

<references/>

Version numbers

2025-01-11T14:51:10Z

Michi cc: /* GRF container version */ Fix GRF container doc link.

There are various version numbers involved in these NewGRF specs. This page clarifies the terms for version numbers.

== Version of a specific NewGRF ==
{{ottdp|1.1|no}}

The version number of a specific NewGRF distinguishes releases of the same NewGRF and defines which release is "newer" or "older".
This has no effect on the NewGRF specs or general behaviour of the NewGRF.
A NewGRF defines its version using [[Action14#GRF_version_.28.22INFO.22_-.3E_.22VRSN.22.29|Action 14]],
it can also define a [[Action14#Minimal_compatible_GRF_version_.28.22INFO.22_-.3E_.22MINV.22.29|minimum version]] to which it is savegame compatible.

Before the introduction of Action14 - and version numbers in it - NewGRFs used to change the GRFID in case of savegame-incompatibility.
However, this was not done consistently by NewGRF authors, esp. since it caused problems in other places (e.g. NewGRFs testing for other NewGRFs).

== GRF version ==

The GRF version defines the version of the NewGRF specs to which a NewGRF adheres.
Changing the GRF version of a GRF is likely to affect the operativity of a NewGRF as it might change the behaviour of various NewGRF features.

Throughout the specs the dependencies and changes between GRF versions are indicated using the {{grf|}} icon.

A NewGRF defines the version of the specs it adheres to within its [[Action8]].

=== GRF version 0 and 1 ===
{{ottdp|no|no}}

These GRF versions are from the alpha and beta days of NewGRFs in general.
Especially version 1 introduced [[Action8]] which allows a NewGRF to specify the GRF version it adheres to.
GRF version 2 concurs with TTDPatch 2.0, the first stable version of TTDPatch supporting NewGRFs. It comes along with a hard compatibility cut in NewGRFs:
TTDPatch 2.0 is the first version to support GRF version 2, while it removes support for version 0 and 1 at the same time (which implies making Action 8 mandatory).

During the development of the GRF specs various features were designed, implemented and redesigned again. As such GRF version 2 is the first stable version of the specs.

=== GRF version 2 to 6 ===
{{ottdp|0.6|2.0}}

These GRF versions were introduced at somewhat arbitrary spots of TTDPatch development to allow NewGRFs to specify requirements for newer GRF features.
Later this approach of versioning the specs was dropped. Instead NewGRFs can now read and test the TTDPatch / OpenTTD version in [[Action9]] and disable themself using [[ActionB]] with an appropiate error message.

=== GRF version 7 ===
{{ottdp|0.6|2.5}}

GRF version 7 makes various semantic changes to various NewGRF features. The same code can be valid for both version 6 and 7, but will have a different meaning.
Most notable changes are:
* Language codes in [[Action4]] were completely redesigned.
* Various callbacks, properties and variables use cargobits instead of cargoslots.
The changes are described in detail on the pages for the features they affect.

=== GRF version 8 ===
{{ottdp|1.2|no}}

GRF version 8 again makes various semantic changes to various NewGRF features.
Most notable changes are:
* Various compatibility layers within the specs were removed to simplify writing NewGRFs resp. to remove arbitrary restrictions.
: E.g. the special meaning of 0xFF?? callback results was removed. Also all callbacks are 15bit callbacks now.
* All remnants of cargoslots were removed. (Except for the cargo definition itself of course.)
* Various parts of the specs were clarified, various callbacks which allowed various results with the same meaning before now only allow definite values for every possible result, while the other values stay reserved.
: E.g. callbacks results which were previously only tested for zero or non-zero must now return a specific value 0 or 1.
* All "height" variables were revised to better distinguish height in heightlevels or in pixels. This is a preparation for the introduction of more than 16 heightlevels.

== GRF container version ==

The GRF container format is the binary format of the GRF file. While the GRF version controls the meaning of the content of a NewGRF, the
GRF container version specifies the storage format for it. As such this version affects the software which reads/writes NewGRFs like grfcodec, nml, and of course also
OpenTTD and TTDPatch.

The GRF container format is specified in the [https://raw.githubusercontent.com/OpenTTD/grfcodec/refs/heads/master/docs/grf.txt grfcodec documentation].

=== GRF container version 1 ===
{{ottdp|0.6|2.0}}

This is the traditional file format from TTD.

=== GRF container version 2 ===
{{ottdp|1.2|no}}

This is a new file format introduced in GRFCodec 6.0. Implementations which only know GRF container version 1 will consider GRFs with this version empty / invalid.

New features in this version are:
* Pseudosprites (and binary include sprites) can be bigger than 64KB.
* Realsprites can be higher than 255 pixels.
* Realsprites can contain various versions of the same sprite in different zoom levels and colour depths (8bpp/32bpp).

There are no implications between GRF container version, GRF version and NFO version. Though of course some things are only possible with GRF container version 2.

== NFO version ==

This is the file format of NFO files, the input/output of GRFCodec and NFORenum.
There are no implications between GRF container version, GRF version and NFO version. Though of course some things may only be represented using newer NFO versions.

The differences between the formats are ''documented'' in the [http://dev.openttdcoop.org/projects/grfcodec/repository/entry/src/readinfo.cpp GRFCodec source code],
which can still read all formats (though not write).

=== NFO version 1 to 7 ===

Along these versions numerous advanced syntax forms were added to GRFCodec. However, every version can be converted into every other of these versions without losing
information when encoding/decoding NewGRFs (except source code comments, which are lost when encoding GRFs). Though older NFO versions might not be that comfortable
for representing certain GRF features (e.g. binary include sprites).

=== NFO versions 8 to 31 ===
Historically the numeric values of GRF versions and NFO versions were often the same (esp. for the long lasting versions 6 and 7), causing quite some confusion among NewGRF authors, which then used the version numbers
incorrectly. When GRF version 8 coincided again (time-wise) with the requirement for a new NFO version, it was decided to skip NFO versions 8 to 31 to make the numeric values
vastly different and thus making confusion less likely.

The value "32" for the new version was picked for unspecified reasons. Rumours say the value 32 stands for:
* Support for 32bpp graphics.
* Support for GRF container version 2.0. (Versions are usually encoded hexadecimal, and 20h = 32)

=== NFO version 32 ===

NFO version 32 adds support for GRF container version 2 specific features like 32bpp graphics or zoom-level specific graphics.
However, NFO version 32 and earlier versions can also be encoded into GRF container version 1 resp. 2.
Encoding into GRF container version 1 or decoding into NFO version < 32 might drop additional sprites though, which cannot be represented in those formats.

== TTDPatch version ==

Certain NewGRF features are only supported starting from certain TTDPatch versions on. These version requirements are mentioned throughout the specs using the {{ttdp|}} icon.
NewGRFs can check the TTDPatch version using [[Action9]] for variables [[GlobalVariables|0B and 1D]] and disable themself using [[ActionB]].

TTDPatch is versioned in alpha, beta and stable versions.
However, before 2.6 alphas the alpha versions were named with different version numbers than the beta/stable versions they would lead to; instead they used the previous stable version incremented by 0.0.1.

{| |-
! Series !! Alpha versions !! Beta versions !! Stable !! Maintenance releases of stables
|-
| 1.9 <ref>These versions had no NewGRF support at all and are only listed to explain the following lines.</ref> || 1.8.1 alpha XX || 1.9 beta X || 1.9 ||
|-
| 2.0 || 1.9.1 alpha XX || 2.0 beta X || 2.0 || 2.0r1
|-
| 2.5 || 2.0.1 alpha XX || 2.5 beta X || 2.5 <ref>Not released yet.</ref> ||
|-
| 2.6 || 2.6 nightly rXXXX || || ||
|}

<references/>

== OpenTTD version ==

Certain NewGRF features are only supported starting from certain OpenTTD versions on. These version requirements are mentioned throughout the specs using the {{ottd|}} icon.
NewGRFs can check the OpenTTD version using [[Action9]] for variables [[GlobalVariables#OpenTTD_Version_.2821_.2F_A1.29|21 and 1D]] and disable themself using [[ActionB]].

OpenTTD is versioned in alpha, beta and stable versions. The major and minor version number stays the same for alphas, betas and stables leading to each other,
except when the major version number is increased.

{| |-
! Series !! Alpha versions !! Beta versions !! Stable !! Maintenance releases of stables
|-
| 0.6 || 0.6 nightly rXXXX || 0.6.0-beta X || 0.6.0 || 0.6.x
|-
| 0.7 || 0.7 nightly rXXXX || 0.7.0-beta X || 0.7.0 || 0.7.x
|-
| 1.0 || 0.8 nightly rXXXX, 1.0 nightly rXXXX <ref>The nightlies changed the version after the decision that 1.0 would follow 0.7 instead of 0.8.</ref> || 1.0.0-beta X || 1.0.0 || 1.0.x
|-
| 1.1 || 1.1 nightly rXXXX || 1.1.0-beta X || 1.1.0 || 1.1.x
|-
| 1.9 || 1.9 nightly YYYYMMDD <ref>Since 1.9 nightlies no longer use a revision number, but a date.</ref> || 1.9.0-beta X || 1.9.0 || 1.9.x
|-
| 12 <ref>Version 1.11 was followed by version 12.</ref> || 12 nightly YYYYMMDD || 12.0-beta X || 12.0 || 12.x
|}

<references/>

Callback: Custom refit

2024-11-18T21:55:52Z

Michi cc: Var 18 undefined value

== Custom refit (163) ==

The custom refit callback allows overriding the refittablity of each cargo as defined by the standard vehicle properties. It will be called for each defined cargo type once after the game has loaded all NewGRF files. It needs to be enabled by a callback flag.

The callback is run in purchase list scope, i.e. for cargotype FF. No variables of an actual vehicle are available. Information about the cargo type the callback is called for is available in variables 10 and 18:

* variable 10:
{| |-
!bit numbers!!Meaning
|-
|0..15||[[Action0Cargos#CargoClasses_.2816.29 | Cargo classes]] of the cargo type
|-
|other bits||reserved for future use
|}
* variable 18:
{| |-
!bit numbers!!Meaning
|-
|0..7||Index of the cargo type in the cargo translation table, or FF if the cargo is not present in the translation table
|-
|other bits||reserved for future use
|}

The callback has to return one of the following values:
{| |-
!Value!!Meaning
|-
|0|| Don't change refittability (i.e. use whatever the evaluation of the various refittability vehicle props has determined).
|-
|1|| Allow cargo type as a refit.
|-
|2|| Disallow cargo type as a refit.
|}

A failed callback is treated like a 0 return value.

'''Note:''' As this callback is not re-evaluated after game initialization, using any dynamic variables like e.g. game date will lead to undefined and faulty behaviour.

This callback is available starting with {{ottdp|15|no|ottdrev=gd2496b6ec4}} OpenTTD 15.

[[Category:Callbacks]]

Action0/Vehicles/Planes

2024-11-18T21:49:23Z

Michi cc: PR #13090

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of planes.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Is helicopter? 2=no, 0=yes
|-
|0A||B||{{ottdp|0.6|2.0}}||Is large? 0=no, 1=yes (i.e. can't safely land on small airports)
|-
|0B||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0C||B||{{ottdp|0.6|2.0}}||Speed in units of 8 mph, that is: property = (speed in mph) / 8
|-
|0D||B||{{ottdp|0.6|2.0}}||Acceleration in units of 3/8 mph/tick, that is: property = (acceleration in mph/tick) * 8/3 <ref>{{ottd|<1.3.1}} In OpenTTD before r25115 the units for acceleration were messed up. The unit used was about 1 mph/tick, so aircraft accelerated more than twice as fast. Also values bigger than 19 failed.</ref>
|-
|0E||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|0F||W||{{ottdp|0.6|2.0}}||Primary cargo capacity (passenger or refitted cargo)
|-
|11||B||{{ottdp|0.6|2.0}}||Secondary cargo capacity (mail)
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect
|-
|13||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (Bit Value) in [[CargoTypes]]. <b>Obsoleted by properties 1D/1E</b>
|-
|14||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|15||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|1F||W||{{ottdp|1.2|no|ottdrev=r23504}}||Aircraft range in tiles. Distance is euclidean, a value of 0 means range is unlimited
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below
|-
|23||W||{{ottdp|15|no|ottdrev=gd2496b6ec4}}||Cargo classes required for refittability, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 32]]
|}
<references/>

== Descriptions ==

=== Primary (0F) and secondary (11) cargo capacity ===
Aircraft can transport up to two cargo types.
The first (primary) cargo type can be changed when refitting the aircraft.

The secondary cargo type is always mail, and is only present when the primary cargo type is part of the [[Action0/Cargos#CargoClasses_.2816.29|passenger cargo class]].

See also the page about [[VehicleRefitting|vehicle refitting]].

=== Sound effect (12) ===

The following sound effects are used by planes (note, the setting is ignored for helicopters):

{| |-
!Number!!Sound
|-
|06||Propeller sound 1
|-
|07||Jet sound 1
|-
|3B||Supersonic
|-
|3D||Jet sound 2
|-
|45||Propeller sound 2
|-
|46||Jet sound 3
|}

{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.

{{ottdp|1.11|no|ottdrev=6198a47}} Since OpenTTD g6198a47 this prop can be used to to set custom Action11 sound effects for helicopers. Default sound effects are ignored as before.

=== Callbacks (14, 22) ===
For planes, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 14 (certain other, not as frequently used callbacks are available without setting a bit here)::

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|-
|9||200||163||{{ottdp|15|no|ottdrev=gd2496b6ec4}}Custom refit
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (15) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 15 specifies zero cost.
|-
|5||20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6||40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
Note: This also applies to the rotor sprite, if custom rotor sprites are used.
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Custom cargo ageing period (1C) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Ships

2024-11-18T21:48:56Z

Michi cc: PR #13090

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of ships.
== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Refittable (0 no, 1 yes)
|-
|0A||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0B||B||{{ottdp|0.6|2.0}}||Speed in mph*3.2, use property 23 for speeds > 255
|-
|0C||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'<br/>
{{ottd|15.0}} Since 15.0, a default cargo translation table corresponding to the climate is used if one is not provided.
|-
|0D||W||{{ottdp|0.6|2.0}}||Capacity
|-
|0F||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|10||B||{{ottdp|0.6|2.0}}||Sound effect type (4=cargo ship, 5=passenger ship)<br/>{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.
|-
|11||D||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Bit mask of cargo types available for refitting, see column 2 (bit values) in [[CargoTypes]]. <b>Obsoleted by properties 1E/1F</b>
|-
|12||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|13||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|14||B||{{ottdp|1.2|2.5|ttdprev=alpha 44|ottdrev=r22639}}||Ocean speed fraction, sets fraction of top speed available in the ocean; e.g. 00=100%, 80=50%, FF=0.4%
|-
|15||B||{{ottdp|1.2|2.5|ttdprev=alpha 44|ottdrev=r22639}}||Canal speed fraction, same as above but for canals and rivers
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Refittable cargo classes, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Non-refittable cargo classes, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.6|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||B||{{ottdp|1.1|no|ottdrev=r21240}}||Visual effect
|-
|1D||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1F||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below
|-
|23||W||{{ottdp|14|no|ottdrev=g5a55c4a934}}||Speed in mph*3.2
|-
|24||B||{{ottdp|14|no|ottdrev=g5a55c4a934}}||Acceleration in mph*3.2/h (0.5 km-ish/h). Minimum 1, defaults to 1 when omitted
|-
|25||W||{{ottdp|15|no|ottdrev=gd2496b6ec4}}||Cargo classes required for refittability, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 32]]
|}

== Descriptions ==

=== Callbacks (12, 22) ===
For ships, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 12 and 22 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|-
|9||200||163||{{ottdp|15|no|ottdrev=gd2496b6ec4}}Custom refit
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (13) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 13 specifies zero cost.
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort_vehicle_list_.281A.29|trains]] for details.

=== Visual effect (1C) ===
See the equivalent [[Action0Trains#Visual_effects_and_wagon_power_.2822.29|train property]] for information about the meaning of all bits. There is no default effect for ships, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.

=== Custom cargo ageing period (1D) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/RoadVehicles

2024-11-18T21:48:02Z

Michi cc: PR #13090

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of road vehicles.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|1.10|no}}||Roadtype / tramtype (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||Speed in mph*3.2||no
|-
|09||B||{{ottdp|0.6|2.0}}||Running cost factor||should be zero
|-
|0A||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|0E||B||{{ottdp|0.6|2.0}}||Sprite ID (FF for new graphics)||yes
|-
|0F||B||{{ottdp|0.6|2.0}}||Capacity||yes
|-
|10||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'<br/>
{{ottd|15.0}} Since 15.0, a default cargo translation table corresponding to the climate is used if one is not provided.
||yes
|-
|11||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect: 17/19/1A for regular, 3C/3E for toyland<br/>{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.||no
|-
|13||B||{{ottdp|1.1|2.0}} {{grfFrom|2}}||Power in 10 hp, see below||should be zero
|-
|14||B||{{ottdp|1.1|2.0}} {{grfFrom|2}}||Weight in 1/4 tons, see below||should be zero
|-
|15||B||{{ottdp|0.7|2.0}} {{grfFrom|2}}||Speed in mph*0.8, see below||no
|-
|16||D||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Bit mask of cargo types available for refitting (not refittable if 0 or unset), see column 2 (bit values) in [[CargoTypes]]. <b>Obsoleted by properties 24/25</b>||yes
|-
|17||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|18||B||{{ottdp|1.1|2.5|ttdprev=alpha 30}}||Coefficient of tractive effort||should be zero
|-
|19||B||{{ottdp|1.1|2.5|ttdprev=alpha 30}}||Coefficient of air drag||should be zero
|-
|1A||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1B||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|1C||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags||partly ("tram" should be same as front)
|-
|1D||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 28]]||yes
|-
|1E||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 29]]||yes
|-
|1F||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date||no
|-
|20||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list||no
|-
|21||B||{{ottdp|1.1|no|ottdrev=r21240}}||Visual effect||yes
|-
|22||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|23||B||{{ottdp|1.2|no|ottdrev=r23164}}||Make vehicle shorter, see [[Action0/Vehicles/Trains#Shorter_train_vehicles_.2821.29|train property 21]]||yes
|-
|24||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]||yes
|-
|25||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]||yes
|-
|26||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|27||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|28||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below||yes
|-
|29||W||{{ottdp|15|no|ottdrev=gd2496b6ec4}}||Cargo classes required for refittability, see [[Action0Trains#Cargo_classes (28, 29, 32)|train prop. 32]]||yes
|}

== Description ==

=== Roadtype or tramtype (05) ===
{{ottdp|1.10|no}} Roadtype or tramtype for the vehicle. This is an index into the [[Action0/Global_Settings#Roadtype_translation_table_.2816.29|roadtype]] or [[Action0/Global_Settings#Tramtype_translation_table_.2817.29|tramtype]] translation table.

This property:
* will use property 1C bit 0 (flag 'vehicle is tram') to determine whether to use a roadtype or tramtype table
* requires an appropriate roadtype or tramtype table to be loaded

=== Running cost base (0A) and factor (09) ===

TTD calculates all costs by multiplying a 48-bit base amount with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of road vehicles, the following base amounts are available:

{| |-
!Type!!Value!!in little-endian notation
|-
|Road vehicle running cost base||4C48||48 4C 00 00
|}

Theoretically, you could use pointers to other [[BaseCosts|base amounts]] available in TTD, but these are the numbers TTD uses for road vehicles.

=== Cost factor (11) ===

The cost factor is a bit-coded value which determines how expensive a vehicle is. The table below gives you some values to use for finding the right price for your vehicles.

{| |-
!Cost factor!!Price
|-
|00||$ 0
|-
|01||$ 108
|-
|10||$ 1,750
|-
|20||$ 3,500
|-
|80||$ 14,000
|-
|FF||$ 27,890
|}

=== Realistic acceleration properties (13, 14, 15) ===

Using property 15 to set the speed, it is possible to achieve speeds larger than 80 mph (127 km/h), to which property 08 is limited. When setting property 15, always set property 08 as well, so that the vehicle works reasonably well whether realistic acceleration is turned on or off. If property 15 is not set, the value from property 08 is used instead.

{{ttdp|}} TTDPatch uses these properties only if road vehicles are set to realistic acceleration in the NewCurveAndMountainHandling switch. They are ignored otherwise.

{{ottd|}} OpenTTD uses these properties always, if they are defined and gives the speed defined here precedence over the one defined in property 08.

=== Callbacks (17, 28) ===

For road vehicles, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 17 and 28 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated vehicle
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|-
|9||200||163||{{ottdp|15|no|ottdrev=gd2496b6ec4}}Custom refit
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Coefficient of tractive effort (18) ===

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

For a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on.  If not set, a default of 4C is used, for a fraction of 0.30, corresponding to W<sub>adh</sub>=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

=== Coefficient of air drag (19) ===

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units.  00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!!<16!!16!!24!!32!!48!!64!!96!!128!!192!!256!!...
|-
|c2||192||128||96||64||48||32||24||16||12||8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTd's consistent scaling.  If a vehicle doesn't reach its historical top speed, you might try setting prop. 19 one or two higher than the default above, otherwise it's probably a good idea to leave it at the default.

=== Refit cost (1A) ===

Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (1C) is set, auto-refitting is allowed.

=== Miscellaneous flags (1C) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||Vehicle is a tram/light rail vehicle and requires tram tracks to operate
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 1A specifies zero cost.
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

=== Long format introduction date (1F) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (20) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Visual effect (21) ===
See the equivalent [[Action0Trains#Visual effects and wagon power 22|train property]] for information about the meaning of all bits. There is no default effect for road vehicles, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.

=== Custom cargo ageing period (22) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Trains

2024-11-18T21:45:38Z

Michi cc: /* Cargo classes (28, 29, 32) */

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

=Introduction=
Defining properties of train vehicles.

= Properties =

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|0.6|2.0}}||Track type (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||AI special flag: set to 1 if engine is 'optimized' for passenger service (AI won't use it for other cargo), 0 otherwise||no
|-
|09||W||{{ottdp|0.6|2.0}}||Speed in mph*1.6 (see below)||no
|-
|0B||W||{{ottdp|0.6|2.0}}||Power (0 for wagons)||should be zero
|-
|0D||B||{{ottdp|0.6|2.0}}||Running cost factor (0 for wagons)||should be zero
|-
|0E||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sprite ID (FD for new graphics)||yes
|-
|13||B||{{ottdp|0.6|2.0}}||Dual-headed flag; 1 if dual-headed engine, 0 otherwise||should be zero also for front
|-
|14||B||{{ottdp|0.6|2.0}}||Cargo capacity||yes
|-
|15||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'<br/>
{{ottd|15.0}} Since 15.0, a default cargo translation table corresponding to the climate is used if one is not provided.
||yes
|-
|16||B||{{ottdp|0.6|2.0}}||Weight in tons||should be zero
|-
|17||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|18||B||{{ottdp|<0.7|2.0}}<ref>This property is not used by OpenTTDs NoAI API.</ref>||Engine rank for the AI (AI selects the highest-rank engine of those it can buy)||no
|-
|19||B||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Engine traction type (see below)||no
|-
|1A||B/B*<ref>{{ottdp|0.7|no|ottdrev=r13831}} Since OpenTTD r13831 this is an extended byte.</ref>||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Not a property, but an action: sort the purchase list.||no
|-
|1B||W||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Power added by each wagon connected to this engine, see below||should be zero
|-
|1C||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1D||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (bit value) in [[CargoTypes]]. <b>Obsoleted by properties 2C/2D</b>||yes
|-
|1E||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|1F||B||{{ottdp|0.6|2.5|ttdprev=alpha 19}}||Coefficient of tractive effort||should be zero
|-
|20||B||{{ottdp|1.1|2.5|ttdprev=alpha 27}}||Coefficient of air drag||should be zero
|-
|21||B||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Make vehicle shorter by this amount, see below||yes
|-
|22||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set visual effect type (steam/smoke/sparks) as well as position, see below||yes
|-
|23||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set how much weight is added by making wagons powered (i.e. weight of engine), see below||should be zero
|-
|24||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||High byte of vehicle weight, weight will be prop.24*256+prop.16||should be zero
|-
|25||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||User-defined bit mask to set when checking veh. var. 42||yes
|-
|26||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|27||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous flags||partly
|-
|28||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes||yes
|-
|29||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes||yes
|-
|2A||D||{{ottdp|0.6|2.5|ottdrev=r7191|ttdprev=r1210}}||Long format introduction date||no
|-
|2B||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|2C||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types||yes
|-
|2D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types||yes
|-
|2E||W||{{ottdp|12|no|ottdrev=g2183fd4dab}}||Maximum curve speed modifier||yes
|-
|2F||W||{{ottdp|13|no}}||Vehicle variant group||no
|-
|30||D||{{ottdp|13|no}}||Extra flags||??
|-
|31||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below||yes
|-
|32||W||{{ottdp|15|no|ottdrev=gd2496b6ec4}}||Cargo classes required for refittability||yes
|}
<references/>

= Description =

== Track type (05) ==
Set track type of vehicle: 0 = rail, 1 = monorail, 2 = maglev. For setting the appropriate traction type, see [[Action0Trains#Engine traction type 19|prop19]].

{{ottdp|1.0|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, this property is an index into the table instead.

== Speed (09) ==

Train speed is in units of mph*1.6, i.e. approximately km/h.

For wagons, this value is only used if the "wagonspeedlimit" switch is on, and it limits the speed of the train to that of the lowest wagon speed.  This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed.

For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit.

== Power (0B) ==

The power of the engine, in HP.

A value of 0 means that the vehicle will be a wagon, otherwise it will be an engine.

== Running cost base (0E) and factor (0D) ==

TTD calculates all costs by multiplying a 32-bit [[BaseCosts|base amount]] with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of train vehicles, the following base amounts are available depending on the vehicle type (the value here is a pointer into TTD's memory where the actual amount is stored):

{| |-
!Type!!Value!!in little-endian notation
|-
|Steam engines||4C30||30 4C 00 00
|-
|Diesel engines||4C36||36 4C 00 00
|-
|Electric engines||4C3C||3C 4C 00 00
|-
|Wagons||0||00 00 00 00
|}

Theoretically, you could use pointers to other base amounts available in TTD, but these are the numbers TTD uses for train vehicles.

The following are some real values for maintenance costs depending on the setting of the above two factors.  This value is correct for medium difficulty, but increases and decreases for hard and easy difficulties respectively.  These are the costs of a new game starting in 1921, because they obviously increase with inflation over time (unless noinflation is turned on).

'''Running cost base 4C30 (steam)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 42
|-
|10||$ 700
|-
|20||$ 1.400
|-
|80||$ 5.600
|-
|A0||$ 7.000
|-
|FF||$ 11.112
|}

'''Running cost base 4C36 (diesel)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 40
|-
|10||$ 650
|-
|20||$ 1.300
|-
|80||$ 5.200
|-
|A0||$ 6.500
|-
|FF||$ 10.318
|}

'''Running cost base 4C3C (electric)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 36
|-
|10||$ 600
|-
|20||$ 1.200
|-
|80||$ 4.800
|-
|A0||$ 6.000
|-
|FF||$ 9.524
|}

== Cost factor (17) ==

The cost factor is a bit-coded value which determines how expensive an engine is. There is no distinction between steam, diesel or electric engines, they all use the same cost factor. The table below gives you some values to use for finding the right price for your engines.

{| |-
!Cost factor!!Price
|-
|01||$ 3.124
|-
|10||$ 50.000
|-
|20||$ 100.000
|-
|80||$ 400.000
|-
|A0||$ 500.000
|-
|FF||$ 796.874
|}

== Engine traction type (19) ==

This sets the traction type of a train engine, i.e. whether it is powered by steam, diesel, electric, monorail or maglev technology.  It also sets the corresponding sound effect of the engine, and if property 22 is not set, the visual effect as well.

The following ranges are available (and it does not matter which value you pick):

{| |-
!Values!!Traction type
|-
|00..07||Steam
|-
|08..27||Diesel
|-
|28..31||Electric
|-
|32..37||Monorail
|-
|38..41||Maglev
|}
Default value is 00, i.e. steam. For setting the appropriate track type, see [[Action0Trains#Track type 05|prop05]].

{{ottdp|1.1|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, setting this property does NOT alter the track type.

== Sort vehicle list (1A) ==

This is not a property as such, but an action.  It forces TTDPatch to shuffle the vehicle this "property" is being set for in front of the vehicle with the given value of the property.  The order of this list is only used in the train purchase window.

For example, setting prop. 1A for vehicle 09 to a value of 07 would lead to the following internal list: ... 05 06 09 07 08 0A 0B ...

This property can not simply be overwritten, because the list is already shuffled when trying to do so.

{{ottdp|no|2.0}} It is possible to reset the list to its original order with a special action 0 that has num-info set to 0, and only sets property 1A for trains:
<pre>00 00 01 00 00 1A</pre>

Resetting the list should however only be done by sets that contain replacements for all train vehicles.

{{ottdp|0.7|no|ottdrev=r13831}} This property is an extended byte in OpenTTD since r13831!

== Powered train wagons (1B and 23, see also 22) ==

Normally, train wagons are unpowered in TTD, and if you set property 0B to a non-zero value, they become engines instead.  Therefore, to model real-life trains where wagons have power, a different mechanism is needed.
To make train wagons powered, you set property 1B of the '''engine''' instead of the wagon. This determines how much power each wagon adds to the train when attached to this engine. This only applies to wagons with a [[Action3|graphics override]] for this engine as well.  This means that for example passenger wagons (with an override) will add power, but coal wagons (with no override) will not.

In addition to adding power, these wagons are also heavier by the amount set in property 23.

== Refit cost (1C) ==

Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (27) is set, auto-refitting is allowed.

== Callbacks (1E, 31) ==
For trains, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 1E and 31 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|0||1||10||Powered wagons and visual effect
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated engines
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|-
|9||200||163||{{ottdp|15|no|ottdrev=gd2496b6ec4}}Custom refit
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

These callbacks do not need a bit to activate them, they are always active and will be used if defined in the action 3/action 2 chain.
{| |-
!Variable 0C value!!Callback
|-
|1D||Can wagon be attached
|-
|23||Additional text in purchase screen
|-
|31||Start/stop check
|-
|32||32-day callback
|-
|36||Change Vehicle Properties
|-
|15E||Refit cost
|}

== Coefficient of tractive effort (1F) ==

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

Theoretically, this value should be calculated by taking the ratio of adhesive weight W<sub>adh</sub> (i.e. the vehicle weight that rests on powered axles) times the coefficient of friction µ between the wheels and the rails to the total vehicle weight W, times 255, and convert to hex:

prop. 1F = HEX ((W<sub>adh</sub> * µ / W) * 255)

With prop. 1F having a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

Sometimes you know the real-life tractive effort instead of adhesive weight and coefficient of friction. To help calculating prop. 1F in that case, here's a small example using the NS 1600 (Electric) with a mass of 84 tons and real-life tractive effort (TE<sub>real</sub>) of 259 kN. To quickly find the value for property 1F you fill in the following formula:

prop. 1F = HEX ((TE<sub>real</sub> / (Mass * g) * 255)

That may look confusing but you already know all variables:

prop. 1F = HEX ((259 / (84 * 9.8) * 255)

prop. 1F = HEX (0.3146 *255) = HEX(80.229)

HEX calculations only work with figures in the natural domain: each figure has to be a positive and round figure. Therefore the value you convert to HEX isn't 80.229 but 80:

HEX 80 = 50

Property 1F for the NS 1600 (Electric) would then be: 1F 50.

== Coefficient of air drag (20) ==

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. 00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!! <16!! 16!! 24!! 32!! 48!! 64!! 96!! 128!! 192!! 256!! ...
|-
|c2|| 192|| 128|| 96|| 64|| 48|| 32|| 24|| 16|| 12|| 8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTD's consistent scaling. If a train doesn't reach its historical top speed, you might try setting the value of prop. 20 one or two steps lower than the default above, otherwise it's probably a good idea to leave it at the default.

== Shorter train vehicles (21) ==

This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly
<ref>{{ottdp|1.0|no|ottdrev=r15793}} This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.</ref>,
except at the end of the train
<ref>{{ottdp|<1.0|}} This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.</ref>. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).

<references/>

== Visual effects and wagon power (22) ==

By default, the visual effect of train engines is determined by the traction type (property 19). With this option you can change the type of effect as well as the position of it relative to the vehicle. (Note: for TTDPatch and OpenTTD up to r21229 only the positioning of steam actually works. For {{ottdp|1.1|no|ottdrev=r21230}} positioning diesel smoke and electric sparks works as well) The position of the effect provides a range from 0 to F that is added to the type of the effect.

Position 0 corresponds to a point half a vehicle length ahead of the vehicle, 4 is the front of the vehicle, 8 the middle, C the end and F is a half length behind the vehicle. Intermediate values are in-between.

Additionally, this property can be used to disable powered wagons of this type, although that is usually done with [[Callbacks#Visual_effect_and_wagon_power_.2810.29| callback 10]] instead (which has the same meaning as prop. 22, but is more flexible).

{| |-
!Range !!Effect type
|-
|00..0F||Use the default effect type, but reposition it. For engines this is defined via property 19, wagons have no default effect.
|-
|10..1F||Steam puffs
|-
|20..2F||Diesel fumes
|-
|30..3F||Electric sparks
|-
|40||Disable visual effect
|-
|41..7F||{{ottdp|1.5|no|ottdrev=r26747}} Create effects with [[Callbacks#Advanced_effect_creation_.28160.29|Callback 160]] using one of these spawning models:
* 41 Steam: Gradually less effects when approaching max speed
* 42 Diesel: Effect proportional to acceleration, no effect when idling at top speed
* 43 Electric: Random effect, gradually less likely when approaching max spped
* 44-7F Reserved
|-
|80+00..80+7F||Same as 00..7F above, but disable wagon power
|}

For example, 28 would make the wagon powered and emit diesel fumes, but 80+28 = A8 would only emit the diesel fumes without adding power.

== Miscellaneous flags (27) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|0.6|2.5}}|| Vehicle tilts in curves, and thus gets speed bonus <ref>The tilting speed bonus only applies if all vehicles in the train have this bit set. In TTDPatch it requires the "curves" switch to be on. For realistic curves, it gives the train two free curving pieces with no speed decrease, and for other settings, it increases the curves setting by one (0->1, 1->2, 2->2). In OpenTTD, the curve speed limit increases by 20% if 'realistic' acceleration is enabled, else there is no effect.
</ref>
|-
|1|| 2||{{ottdp|0.6|2.5}}|| Uses two company colors
|-
|2|| 4||{{ottdp|0.6|2.5}}|| Vehicle is a multiple unit (DMU/EMU), for colour selection
|-
|3|| 8||Varies|| {{ottdp|1.1|no|ottdrev=r21966}}Vehicle can be flipped around in the depot. <br>{{ottdp|13|no|no}}This flag is no longer required, vehicles can always be flipped.
<ref>From {{ottd|13|no}} onwards, OpenTTD will again allow all vehicles to flip, and will automatically adjust offsets accordingly. From {{ottd|13|no}}, if this flag is set, OpenTTD will not automatically apply the correct offsets for vehicles < 8/8 long, and will defer to offsets set by the grf. Do not set this flag unless you need it for a specific reason.
<br>
For {{ottd|1.1|r21966}} up to {{ottdp|12|no|no}} when you enable flipping of a vehicle in a depot you must make sure that the graphics are correctly aligned when flipped as well. Especially in the case of shortened vehicles.
<br>
Prior to {{ottd|1.1|r21966}} all non-multiheaded/non-articulated vehicles would be able to flip around in the depot. As such {{ottd|1.1|r21966}} disables a "feature" in OpenTTD, but often it makes no sense to flip vehicles around (symetric vehicles) or the graphics are wrong (most shortened vehicles), and thus only enabling this when the NewGRF developer says it is possible is better.
<br>
For all relevant OpenTTD versions, the flipping bit has no effect for multiheaded or articulated vehicles as they cannot be flipped in depot.
</ref>
|-
|4|| 10||{{ottdp|1.2|no|ottdrev=r23087}}|| Auto-refitting is enabled for refits where callback 15E allows it or prop 1C specifies zero cost
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}}|| Use cargo multiplier for default cargo (and load amount). See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}}|| Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}}|| [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

<references />

== Cargo classes (28, 29, 32) ==

To make vehicle sets more compatible with future new cargo definitions, these three properties allow vehicles to define what type of cargo they should be refittable to. A wagon will be refittable to all cargo types that match any of the classes set in prop. 28 ''and'' have all of the classes set in prop. 32, except for the ones that match any of the classes set in prop. 29. In addition, afterwards those cargo types listed in prop. 1D will be toggled. In terms of logic, it is

Refit list = (cargos from prop. 28 filtered by prop. 32 AND NOT cargos from prop. 29) XOR cargos from prop. 1D

This means, if a cargo type is in the list because it matches props 28/31 but not prop 29, having the respective bit set in prop. 1D will disable it again. Conversely, if the cargo type is not in the list, the bit in prop. 1D will add it. This way, if props. 28/29 are unset, prop. 1D will retain the original meaning, but it is still able to selectively add or remove certain cargo types even if props. 28/29 are used.

As a consequence, you have both full control over the cargo types that you know of (using prop. 1D), and those you don't know of yet (using props. 28/29). Leave the bits for cargos that you don't know of unset in prop. 1D, and set/clear the bits for known cargos to add/remove them from the list as appropriate.

{{ottd|1.2|r23291}} It is recommended to use properties 2C and 2D instead of property 1D, as property 1D behaves badly if the cargo classes of a cargo are ever changed.

The class list is a bit mask. See the action0 cargos page for bits and classes defined so far.

Take a look at [[Action0Cargos#Cargo classes 16|Action0 for cargos]] for the classes defined so far.

Note that cargo types may belong to several classes. This is the reason for making three properties, an additive, a filter, and a subtractive one, because this way a vehicle can be specified to be refittable to, for example, all express cargo that does not require refrigeration (i.e., from the default cargos, no food).
For the cargo types added in this way, the vehicle will probably have no specific graphics (in [[Action3|action 3]]) to show the cargo load.  In this case, the default will be used, which should therefore be sufficiently generic-looking if possible. However, using [[VariationalAction2/Vehicles#Vehicle cargo info 47|vehicle variable 47]] you can at least select the graphics most appropriate for the cargo type's class.
About the interaction with other properties take a look at the summary page about [[VehicleRefitting|vehicle refitting]].

Disclaimer: there is no guarantee that classes won't vary over time or between sets. The classes of a cargo may change between different versions of a specific industry/cargo newgrf, or different classes may be set for the same cargo label by different industry/cargo newgrfs. Feel free to use classes in your set for conveniently refitting to cargos, but if you - the vehicle author - care about specific cargos being transported in specific vehicles, use label based refits (changing labels without a very good reason is considered to be bad practice).

== Long format introduction date (2A) ==

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

== Custom cargo ageing period (2B) ==

This property allows to modify the period in ticks after which cargo carried by the vehicle is aged. By default, cargo is aged every 185 ticks. A value of 0 disables ageing of cargo. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

Changing this value from the default does not automatically make the vehicle earn more or less. Predicting the effect is complicated, as it depends on many things, including: vehicle speed, route length, route delays, transfer credits, the payment curve set by the cargo, and whether the cargo is already aged from a previous transfer when the vehicle loads it.

Authors are advised that tests show this property can lead to disappointment. Avoid, or use with caution.

== List of always refittable cargo types (2C, 2D) ==

These two properties allows to unconditionally include or exclude cargo types for refittability independent of any of the other refit properties or the cargo classes. If you specify a cargo type that is not available, the cargo type will be silently ignored.

The format for both properties is:

<pre>2C/2D <nvar> (<Index into cargo type table>){n}</pre>

That is you give the number of cargos in a single byte followed by a list of that length of indexes into the cargo translation table ([[CargoTypes|Type A]]).

== Maximum curve speed modifier (2E) ==

This property allows to give vehicles a maximum curve speed modifier. The given value is treated as a signed word with 8 fractional bits. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

The modifier is applied after the normal curve speed calculation is done using the formula max_curve_speed * (1 + prop 2E). This means that the default property value of 0 is equivalent to no change. While values less than -1.0 are technically possible, the resulting vehicle curve speed is clamped at 2 mph-ish to make sure vehicles don't become permanently stuck.

If different vehicles in a train have different curve speed modifiers, the lowest value wins.

== Vehicle variant group (2F) ==

This property supports grouping vehicles in the purchase menu (also the autoreplace menu). The property value is the ID of another vehicle in the same GRF which will act as the parent for vehicles in the group.

Groups can also be nested (this is experimental as of December 2022 and may change with testing).

See also [[Action0Trains#Extra flags (30)|vehicle extra flags]] which can influence the behaviour of vehicles in variant groups.

See also https://github.com/OpenTTD/OpenTTD/pull/10220

== Extra flags (30) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|13|no}}|| Disable "New Vehicle" news message for this engine
|-
|1|| 2||{{ottdp|13|no}}|| Disable "Exclusive Preview" for this engine
|-
|2|| 4||{{ottdp|13|no}}|| Variants - Include this variant when primary engine has "Exclusive Preview"
|-
|3|| 8||{{ottdp|13|no}}|| Variants - (Attempt to) Synchronize reliability the primary engine
|-
|}

== Extra callback flags (31) ==

See [[#Callbacks_.281E.2C_31.29]]

= Example =

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

(A basic version)

<pre>10 * 14  00 00 03 01 02 09 C0 00 0B D8 0E 12 FD</pre>

{| |-
!'''Bytes'''!!'''Meaning'''
|-
|10||<Sprite-number>
|-
|14||<Length>: of the action in bytes; start counting at 0 (<action>)
|-
|00||<action>: sets this pseudo-sprite to function as action 0
|-
|00||<Feature>: In this case Train
|-
|03||<Num-props>: 3 Properties to change
|-
|01||<Num-info>: 1 vehicle ID to make changes to
|-
|02||<ids...>: vehcile ID (02 - Ploddyphut Choo-Choo)
|-
|||'''Properties'''
|-
|09||<Speed>
|-
|C0 00||<Value>: Value for Speed (192 Km/h)
|-
|0B||<Power>
|-
|D8 0E||<value>: value for Power (3800 HP)
|-
|12||<Sprite ID>
|-
|FD||<value>: FD for new graphics
|}
Since nfo version 7, so-called [[GRFActionsDetailed#Byte order|"escape sequences"]] have been introduced in an attempt to offer a more human-readable form.

Below is the same example as above, with escape sequences being used:

<pre>-1 * 0 00 00 \b3 01 \b*2 // \b<number of props to change> \b*<vehicle ID>

       09 \w192 // value for speed (192 Km/h)

       0B \w3800 // value for power (3800 hp)

       12 FD // use new graphics</pre>

Action0/Vehicles/Trains

2024-11-18T21:44:43Z

Michi cc: PR #13090

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

=Introduction=
Defining properties of train vehicles.

= Properties =

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|0.6|2.0}}||Track type (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||AI special flag: set to 1 if engine is 'optimized' for passenger service (AI won't use it for other cargo), 0 otherwise||no
|-
|09||W||{{ottdp|0.6|2.0}}||Speed in mph*1.6 (see below)||no
|-
|0B||W||{{ottdp|0.6|2.0}}||Power (0 for wagons)||should be zero
|-
|0D||B||{{ottdp|0.6|2.0}}||Running cost factor (0 for wagons)||should be zero
|-
|0E||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sprite ID (FD for new graphics)||yes
|-
|13||B||{{ottdp|0.6|2.0}}||Dual-headed flag; 1 if dual-headed engine, 0 otherwise||should be zero also for front
|-
|14||B||{{ottdp|0.6|2.0}}||Cargo capacity||yes
|-
|15||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'<br/>
{{ottd|15.0}} Since 15.0, a default cargo translation table corresponding to the climate is used if one is not provided.
||yes
|-
|16||B||{{ottdp|0.6|2.0}}||Weight in tons||should be zero
|-
|17||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|18||B||{{ottdp|<0.7|2.0}}<ref>This property is not used by OpenTTDs NoAI API.</ref>||Engine rank for the AI (AI selects the highest-rank engine of those it can buy)||no
|-
|19||B||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Engine traction type (see below)||no
|-
|1A||B/B*<ref>{{ottdp|0.7|no|ottdrev=r13831}} Since OpenTTD r13831 this is an extended byte.</ref>||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Not a property, but an action: sort the purchase list.||no
|-
|1B||W||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Power added by each wagon connected to this engine, see below||should be zero
|-
|1C||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1D||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (bit value) in [[CargoTypes]]. <b>Obsoleted by properties 2C/2D</b>||yes
|-
|1E||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|1F||B||{{ottdp|0.6|2.5|ttdprev=alpha 19}}||Coefficient of tractive effort||should be zero
|-
|20||B||{{ottdp|1.1|2.5|ttdprev=alpha 27}}||Coefficient of air drag||should be zero
|-
|21||B||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Make vehicle shorter by this amount, see below||yes
|-
|22||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set visual effect type (steam/smoke/sparks) as well as position, see below||yes
|-
|23||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set how much weight is added by making wagons powered (i.e. weight of engine), see below||should be zero
|-
|24||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||High byte of vehicle weight, weight will be prop.24*256+prop.16||should be zero
|-
|25||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||User-defined bit mask to set when checking veh. var. 42||yes
|-
|26||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|27||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous flags||partly
|-
|28||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes||yes
|-
|29||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes||yes
|-
|2A||D||{{ottdp|0.6|2.5|ottdrev=r7191|ttdprev=r1210}}||Long format introduction date||no
|-
|2B||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|2C||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types||yes
|-
|2D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types||yes
|-
|2E||W||{{ottdp|12|no|ottdrev=g2183fd4dab}}||Maximum curve speed modifier||yes
|-
|2F||W||{{ottdp|13|no}}||Vehicle variant group||no
|-
|30||D||{{ottdp|13|no}}||Extra flags||??
|-
|31||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below||yes
|-
|32||W||{{ottdp|15|no|ottdrev=gd2496b6ec4}}||Cargo classes required for refittability||yes
|}
<references/>

= Description =

== Track type (05) ==
Set track type of vehicle: 0 = rail, 1 = monorail, 2 = maglev. For setting the appropriate traction type, see [[Action0Trains#Engine traction type 19|prop19]].

{{ottdp|1.0|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, this property is an index into the table instead.

== Speed (09) ==

Train speed is in units of mph*1.6, i.e. approximately km/h.

For wagons, this value is only used if the "wagonspeedlimit" switch is on, and it limits the speed of the train to that of the lowest wagon speed.  This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed.

For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit.

== Power (0B) ==

The power of the engine, in HP.

A value of 0 means that the vehicle will be a wagon, otherwise it will be an engine.

== Running cost base (0E) and factor (0D) ==

TTD calculates all costs by multiplying a 32-bit [[BaseCosts|base amount]] with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of train vehicles, the following base amounts are available depending on the vehicle type (the value here is a pointer into TTD's memory where the actual amount is stored):

{| |-
!Type!!Value!!in little-endian notation
|-
|Steam engines||4C30||30 4C 00 00
|-
|Diesel engines||4C36||36 4C 00 00
|-
|Electric engines||4C3C||3C 4C 00 00
|-
|Wagons||0||00 00 00 00
|}

Theoretically, you could use pointers to other base amounts available in TTD, but these are the numbers TTD uses for train vehicles.

The following are some real values for maintenance costs depending on the setting of the above two factors.  This value is correct for medium difficulty, but increases and decreases for hard and easy difficulties respectively.  These are the costs of a new game starting in 1921, because they obviously increase with inflation over time (unless noinflation is turned on).

'''Running cost base 4C30 (steam)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 42
|-
|10||$ 700
|-
|20||$ 1.400
|-
|80||$ 5.600
|-
|A0||$ 7.000
|-
|FF||$ 11.112
|}

'''Running cost base 4C36 (diesel)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 40
|-
|10||$ 650
|-
|20||$ 1.300
|-
|80||$ 5.200
|-
|A0||$ 6.500
|-
|FF||$ 10.318
|}

'''Running cost base 4C3C (electric)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 36
|-
|10||$ 600
|-
|20||$ 1.200
|-
|80||$ 4.800
|-
|A0||$ 6.000
|-
|FF||$ 9.524
|}

== Cost factor (17) ==

The cost factor is a bit-coded value which determines how expensive an engine is. There is no distinction between steam, diesel or electric engines, they all use the same cost factor. The table below gives you some values to use for finding the right price for your engines.

{| |-
!Cost factor!!Price
|-
|01||$ 3.124
|-
|10||$ 50.000
|-
|20||$ 100.000
|-
|80||$ 400.000
|-
|A0||$ 500.000
|-
|FF||$ 796.874
|}

== Engine traction type (19) ==

This sets the traction type of a train engine, i.e. whether it is powered by steam, diesel, electric, monorail or maglev technology.  It also sets the corresponding sound effect of the engine, and if property 22 is not set, the visual effect as well.

The following ranges are available (and it does not matter which value you pick):

{| |-
!Values!!Traction type
|-
|00..07||Steam
|-
|08..27||Diesel
|-
|28..31||Electric
|-
|32..37||Monorail
|-
|38..41||Maglev
|}
Default value is 00, i.e. steam. For setting the appropriate track type, see [[Action0Trains#Track type 05|prop05]].

{{ottdp|1.1|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, setting this property does NOT alter the track type.

== Sort vehicle list (1A) ==

This is not a property as such, but an action.  It forces TTDPatch to shuffle the vehicle this "property" is being set for in front of the vehicle with the given value of the property.  The order of this list is only used in the train purchase window.

For example, setting prop. 1A for vehicle 09 to a value of 07 would lead to the following internal list: ... 05 06 09 07 08 0A 0B ...

This property can not simply be overwritten, because the list is already shuffled when trying to do so.

{{ottdp|no|2.0}} It is possible to reset the list to its original order with a special action 0 that has num-info set to 0, and only sets property 1A for trains:
<pre>00 00 01 00 00 1A</pre>

Resetting the list should however only be done by sets that contain replacements for all train vehicles.

{{ottdp|0.7|no|ottdrev=r13831}} This property is an extended byte in OpenTTD since r13831!

== Powered train wagons (1B and 23, see also 22) ==

Normally, train wagons are unpowered in TTD, and if you set property 0B to a non-zero value, they become engines instead.  Therefore, to model real-life trains where wagons have power, a different mechanism is needed.
To make train wagons powered, you set property 1B of the '''engine''' instead of the wagon. This determines how much power each wagon adds to the train when attached to this engine. This only applies to wagons with a [[Action3|graphics override]] for this engine as well.  This means that for example passenger wagons (with an override) will add power, but coal wagons (with no override) will not.

In addition to adding power, these wagons are also heavier by the amount set in property 23.

== Refit cost (1C) ==

Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (27) is set, auto-refitting is allowed.

== Callbacks (1E, 31) ==
For trains, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 1E and 31 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|0||1||10||Powered wagons and visual effect
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated engines
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|-
|9||200||163||{{ottdp|15|no|ottdrev=gd2496b6ec4}}Custom refit
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

These callbacks do not need a bit to activate them, they are always active and will be used if defined in the action 3/action 2 chain.
{| |-
!Variable 0C value!!Callback
|-
|1D||Can wagon be attached
|-
|23||Additional text in purchase screen
|-
|31||Start/stop check
|-
|32||32-day callback
|-
|36||Change Vehicle Properties
|-
|15E||Refit cost
|}

== Coefficient of tractive effort (1F) ==

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

Theoretically, this value should be calculated by taking the ratio of adhesive weight W<sub>adh</sub> (i.e. the vehicle weight that rests on powered axles) times the coefficient of friction µ between the wheels and the rails to the total vehicle weight W, times 255, and convert to hex:

prop. 1F = HEX ((W<sub>adh</sub> * µ / W) * 255)

With prop. 1F having a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

Sometimes you know the real-life tractive effort instead of adhesive weight and coefficient of friction. To help calculating prop. 1F in that case, here's a small example using the NS 1600 (Electric) with a mass of 84 tons and real-life tractive effort (TE<sub>real</sub>) of 259 kN. To quickly find the value for property 1F you fill in the following formula:

prop. 1F = HEX ((TE<sub>real</sub> / (Mass * g) * 255)

That may look confusing but you already know all variables:

prop. 1F = HEX ((259 / (84 * 9.8) * 255)

prop. 1F = HEX (0.3146 *255) = HEX(80.229)

HEX calculations only work with figures in the natural domain: each figure has to be a positive and round figure. Therefore the value you convert to HEX isn't 80.229 but 80:

HEX 80 = 50

Property 1F for the NS 1600 (Electric) would then be: 1F 50.

== Coefficient of air drag (20) ==

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. 00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!! <16!! 16!! 24!! 32!! 48!! 64!! 96!! 128!! 192!! 256!! ...
|-
|c2|| 192|| 128|| 96|| 64|| 48|| 32|| 24|| 16|| 12|| 8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTD's consistent scaling. If a train doesn't reach its historical top speed, you might try setting the value of prop. 20 one or two steps lower than the default above, otherwise it's probably a good idea to leave it at the default.

== Shorter train vehicles (21) ==

This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly
<ref>{{ottdp|1.0|no|ottdrev=r15793}} This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.</ref>,
except at the end of the train
<ref>{{ottdp|<1.0|}} This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.</ref>. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).

<references/>

== Visual effects and wagon power (22) ==

By default, the visual effect of train engines is determined by the traction type (property 19). With this option you can change the type of effect as well as the position of it relative to the vehicle. (Note: for TTDPatch and OpenTTD up to r21229 only the positioning of steam actually works. For {{ottdp|1.1|no|ottdrev=r21230}} positioning diesel smoke and electric sparks works as well) The position of the effect provides a range from 0 to F that is added to the type of the effect.

Position 0 corresponds to a point half a vehicle length ahead of the vehicle, 4 is the front of the vehicle, 8 the middle, C the end and F is a half length behind the vehicle. Intermediate values are in-between.

Additionally, this property can be used to disable powered wagons of this type, although that is usually done with [[Callbacks#Visual_effect_and_wagon_power_.2810.29| callback 10]] instead (which has the same meaning as prop. 22, but is more flexible).

{| |-
!Range !!Effect type
|-
|00..0F||Use the default effect type, but reposition it. For engines this is defined via property 19, wagons have no default effect.
|-
|10..1F||Steam puffs
|-
|20..2F||Diesel fumes
|-
|30..3F||Electric sparks
|-
|40||Disable visual effect
|-
|41..7F||{{ottdp|1.5|no|ottdrev=r26747}} Create effects with [[Callbacks#Advanced_effect_creation_.28160.29|Callback 160]] using one of these spawning models:
* 41 Steam: Gradually less effects when approaching max speed
* 42 Diesel: Effect proportional to acceleration, no effect when idling at top speed
* 43 Electric: Random effect, gradually less likely when approaching max spped
* 44-7F Reserved
|-
|80+00..80+7F||Same as 00..7F above, but disable wagon power
|}

For example, 28 would make the wagon powered and emit diesel fumes, but 80+28 = A8 would only emit the diesel fumes without adding power.

== Miscellaneous flags (27) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|0.6|2.5}}|| Vehicle tilts in curves, and thus gets speed bonus <ref>The tilting speed bonus only applies if all vehicles in the train have this bit set. In TTDPatch it requires the "curves" switch to be on. For realistic curves, it gives the train two free curving pieces with no speed decrease, and for other settings, it increases the curves setting by one (0->1, 1->2, 2->2). In OpenTTD, the curve speed limit increases by 20% if 'realistic' acceleration is enabled, else there is no effect.
</ref>
|-
|1|| 2||{{ottdp|0.6|2.5}}|| Uses two company colors
|-
|2|| 4||{{ottdp|0.6|2.5}}|| Vehicle is a multiple unit (DMU/EMU), for colour selection
|-
|3|| 8||Varies|| {{ottdp|1.1|no|ottdrev=r21966}}Vehicle can be flipped around in the depot. <br>{{ottdp|13|no|no}}This flag is no longer required, vehicles can always be flipped.
<ref>From {{ottd|13|no}} onwards, OpenTTD will again allow all vehicles to flip, and will automatically adjust offsets accordingly. From {{ottd|13|no}}, if this flag is set, OpenTTD will not automatically apply the correct offsets for vehicles < 8/8 long, and will defer to offsets set by the grf. Do not set this flag unless you need it for a specific reason.
<br>
For {{ottd|1.1|r21966}} up to {{ottdp|12|no|no}} when you enable flipping of a vehicle in a depot you must make sure that the graphics are correctly aligned when flipped as well. Especially in the case of shortened vehicles.
<br>
Prior to {{ottd|1.1|r21966}} all non-multiheaded/non-articulated vehicles would be able to flip around in the depot. As such {{ottd|1.1|r21966}} disables a "feature" in OpenTTD, but often it makes no sense to flip vehicles around (symetric vehicles) or the graphics are wrong (most shortened vehicles), and thus only enabling this when the NewGRF developer says it is possible is better.
<br>
For all relevant OpenTTD versions, the flipping bit has no effect for multiheaded or articulated vehicles as they cannot be flipped in depot.
</ref>
|-
|4|| 10||{{ottdp|1.2|no|ottdrev=r23087}}|| Auto-refitting is enabled for refits where callback 15E allows it or prop 1C specifies zero cost
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}}|| Use cargo multiplier for default cargo (and load amount). See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}}|| Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}}|| [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

<references />

== Cargo classes (28, 29, 31) ==

To make vehicle sets more compatible with future new cargo definitions, these three properties allow vehicles to define what type of cargo they should be refittable to. A wagon will be refittable to all cargo types that match any of the classes set in prop. 28 ''and'' have all of the classes set in prop. 31, except for the ones that match any of the classes set in prop. 29. In addition, afterwards those cargo types listed in prop. 1D will be toggled. In terms of logic, it is

Refit list = (cargos from prop. 28 filtered by prop. 31 AND NOT cargos from prop. 29) XOR cargos from prop. 1D

This means, if a cargo type is in the list because it matches props 28/31 but not prop 29, having the respective bit set in prop. 1D will disable it again. Conversely, if the cargo type is not in the list, the bit in prop. 1D will add it. This way, if props. 28/29 are unset, prop. 1D will retain the original meaning, but it is still able to selectively add or remove certain cargo types even if props. 28/29 are used.

As a consequence, you have both full control over the cargo types that you know of (using prop. 1D), and those you don't know of yet (using props. 28/29). Leave the bits for cargos that you don't know of unset in prop. 1D, and set/clear the bits for known cargos to add/remove them from the list as appropriate.

{{ottd|1.2|r23291}} It is recommended to use properties 2C and 2D instead of property 1D, as property 1D behaves badly if the cargo classes of a cargo are ever changed.

The class list is a bit mask. See the action0 cargos page for bits and classes defined so far.

Take a look at [[Action0Cargos#Cargo classes 16|Action0 for cargos]] for the classes defined so far.

Note that cargo types may belong to several classes. This is the reason for making three properties, an additive, a filter, and a subtractive one, because this way a vehicle can be specified to be refittable to, for example, all express cargo that does not require refrigeration (i.e., from the default cargos, no food).
For the cargo types added in this way, the vehicle will probably have no specific graphics (in [[Action3|action 3]]) to show the cargo load.  In this case, the default will be used, which should therefore be sufficiently generic-looking if possible. However, using [[VariationalAction2/Vehicles#Vehicle cargo info 47|vehicle variable 47]] you can at least select the graphics most appropriate for the cargo type's class.
About the interaction with other properties take a look at the summary page about [[VehicleRefitting|vehicle refitting]].

Disclaimer: there is no guarantee that classes won't vary over time or between sets. The classes of a cargo may change between different versions of a specific industry/cargo newgrf, or different classes may be set for the same cargo label by different industry/cargo newgrfs. Feel free to use classes in your set for conveniently refitting to cargos, but if you - the vehicle author - care about specific cargos being transported in specific vehicles, use label based refits (changing labels without a very good reason is considered to be bad practice).

== Long format introduction date (2A) ==

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

== Custom cargo ageing period (2B) ==

This property allows to modify the period in ticks after which cargo carried by the vehicle is aged. By default, cargo is aged every 185 ticks. A value of 0 disables ageing of cargo. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

Changing this value from the default does not automatically make the vehicle earn more or less. Predicting the effect is complicated, as it depends on many things, including: vehicle speed, route length, route delays, transfer credits, the payment curve set by the cargo, and whether the cargo is already aged from a previous transfer when the vehicle loads it.

Authors are advised that tests show this property can lead to disappointment. Avoid, or use with caution.

== List of always refittable cargo types (2C, 2D) ==

These two properties allows to unconditionally include or exclude cargo types for refittability independent of any of the other refit properties or the cargo classes. If you specify a cargo type that is not available, the cargo type will be silently ignored.

The format for both properties is:

<pre>2C/2D <nvar> (<Index into cargo type table>){n}</pre>

That is you give the number of cargos in a single byte followed by a list of that length of indexes into the cargo translation table ([[CargoTypes|Type A]]).

== Maximum curve speed modifier (2E) ==

This property allows to give vehicles a maximum curve speed modifier. The given value is treated as a signed word with 8 fractional bits. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

The modifier is applied after the normal curve speed calculation is done using the formula max_curve_speed * (1 + prop 2E). This means that the default property value of 0 is equivalent to no change. While values less than -1.0 are technically possible, the resulting vehicle curve speed is clamped at 2 mph-ish to make sure vehicles don't become permanently stuck.

If different vehicles in a train have different curve speed modifiers, the lowest value wins.

== Vehicle variant group (2F) ==

This property supports grouping vehicles in the purchase menu (also the autoreplace menu). The property value is the ID of another vehicle in the same GRF which will act as the parent for vehicles in the group.

Groups can also be nested (this is experimental as of December 2022 and may change with testing).

See also [[Action0Trains#Extra flags (30)|vehicle extra flags]] which can influence the behaviour of vehicles in variant groups.

See also https://github.com/OpenTTD/OpenTTD/pull/10220

== Extra flags (30) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|13|no}}|| Disable "New Vehicle" news message for this engine
|-
|1|| 2||{{ottdp|13|no}}|| Disable "Exclusive Preview" for this engine
|-
|2|| 4||{{ottdp|13|no}}|| Variants - Include this variant when primary engine has "Exclusive Preview"
|-
|3|| 8||{{ottdp|13|no}}|| Variants - (Attempt to) Synchronize reliability the primary engine
|-
|}

== Extra callback flags (31) ==

See [[#Callbacks_.281E.2C_31.29]]

= Example =

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

(A basic version)

<pre>10 * 14  00 00 03 01 02 09 C0 00 0B D8 0E 12 FD</pre>

{| |-
!'''Bytes'''!!'''Meaning'''
|-
|10||<Sprite-number>
|-
|14||<Length>: of the action in bytes; start counting at 0 (<action>)
|-
|00||<action>: sets this pseudo-sprite to function as action 0
|-
|00||<Feature>: In this case Train
|-
|03||<Num-props>: 3 Properties to change
|-
|01||<Num-info>: 1 vehicle ID to make changes to
|-
|02||<ids...>: vehcile ID (02 - Ploddyphut Choo-Choo)
|-
|||'''Properties'''
|-
|09||<Speed>
|-
|C0 00||<Value>: Value for Speed (192 Km/h)
|-
|0B||<Power>
|-
|D8 0E||<value>: value for Power (3800 HP)
|-
|12||<Sprite ID>
|-
|FD||<value>: FD for new graphics
|}
Since nfo version 7, so-called [[GRFActionsDetailed#Byte order|"escape sequences"]] have been introduced in an attempt to offer a more human-readable form.

Below is the same example as above, with escape sequences being used:

<pre>-1 * 0 00 00 \b3 01 \b*2 // \b<number of props to change> \b*<vehicle ID>

       09 \w192 // value for speed (192 Km/h)

       0B \w3800 // value for power (3800 hp)

       12 FD // use new graphics</pre>

Callbacks

2024-11-18T21:34:14Z

Michi cc:

==Introduction==

A callback is a special action 2 that the patch "calls" in order to modify various features, an example being the visual effect of train vehicles.  See the [[ttwiki:CallbacksTut|callback tutorial]] on how to use them.

In the final action 2 of a chain of VarAction2s, the second byte of the matching entry has to have bit 7 set to identify it as a callback result.

For example, 04 00 is not a callback result (but it may be the ID of another chained action 2), whereas 04 80 is a callback result with a value of 4. In total a callback has 15 bit result values, where the upper 7 bits are stored in the second byte. For example, 54 C2 is a callback result with a value of 4254=16980, where again the second byte has bit 7 set, changing the 42 into C2.

{{grfTill|7}} For GRF version 7 and below not all 15 bit values are available as return values, only values between 00 and 7EFF.
For compatibility with earlier patch versions, FF in the high byte is taken to mean the same thing as 80, so 04 FF also has a callback result of 4. Note that if your grf file needs to be compatible with versions before TTDPatch 2.0.1 alpha 40, you must set the high byte to FF, and so can use only 8 bit results.

{{grfFrom|8}} For GRF version 8 and above this compatibility layer has been removed. Callbacks can return all 15 bit values between 00 and 7FFF.

To check for a specific callback, use an [[VariationalAction2]] or [[VarAction2Advanced]] to check for variable 0C.
* Variable 0C contains the callback number.
* Variable 0C is a word, thus the VarAction2 must use type 85.
* Results can be specified directly using 8xxx values (see above), or with 8xxx value in subsequent (Basic/Variational/Random)Action2 which are referenced as usual with their set-id.
* The default case of the VarAction2 must point to the regular graphics chain, so that unknown/future callbacks results in a "callback failure" result.

Example:
<Sprite-number> * <Length> 02 <feature> <set-id> 85 0C 00 \wxFFFF
<nvar> (<set-id/result> \wx <callback> \wx <callback>){n}
<set-id of graphics chain>

The format for VarAction2 is explained in detail on the [[VariationalAction2]] page.

== List of callbacks ==

The following callbacks are defined by the patch.  The number of the callback is what will be stored in variable 0C so that you can return the right results if you have several callbacks.  All callbacks are explained in more detail below.

'''PLEASE NOTE:''' Since TTDPatch 2.5 beta 5, the size of variable 0C has changed, and now there are word-sized callback numbers as well. To maintain backwards compatibility, only callbacks 10..3F can be checked using a byte-sized check. Callbacks 140 and above, on the other hand, must be checked using a word or dword sized check, to make sure they are identified uniquely.

{| |-
!Number!!Feature(s)!!Meaning
|-
|10||Vehicles||[[Callback: Visual effect and wagon power|Visual effect and wagon power]]
|-
|11||Vehicles||[[Callback: Wagon length|Wagon length]]
|-
|12||Vehicles||[[Callback: Load amount|Load amount]]
|-
|13||Stations||[[Callback: Station availability|Station availability]]
|-
|14||Stations||[[Callback: Station sprite layout|Select sprite layout]]
|-
|15||Vehicles||[[Callback: Refitted capacity callback|Refitted capacity callback]]
|-
|16||Trains||[[Callback: Articulated engine|Build articulated engines]]
|-
|17||Houses||[[Callback: House construction check|House construction check]]
|-
|18||Several <ref name="generic">Generic callbacks are called for the feature, not any specific vehicle ID. Read the [[Action3#n-id|Action 3]] entry on how to define these.</ref>||[[Callback: AI construction/purchase selection|AI construction/purchase selection]]
|-
|19||Vehicles||[[Callback: Cargo Subtype Display|Cargo sub-type display]]
|-
|1A||Houses||Next animation frame
|-
|1B||Houses||Animation control
|-
|1C||Houses||Construction stage changes
|-
|1D||Trains||Can wagon be attached
|-
|1E||Houses||Decide colour of building
|-
|1F||Houses||Cargo acceptance
|-
|20||Houses||Length of animation frame
|-
|21||Houses||Trigger building destruction
|-
|22||Industries||Availability
|-
|23||Vehicles||Additional text in purchase screen
|-
|24||Stations||Custom station layout
|-
|25||Industry tiles||Animation control
|-
|26||Industry tiles||Next animation frame
|-
|27||Industry tiles||Length of animation frame
|-
|28||Industries||Industry location permissibility
|-
|29||Industries||Random production change
|-
|2A||Houses||Get accepted cargo types
|-
|2B||Industry tiles||Decide cargo acceptance
|-
|2C||Industry tiles||Get accepted cargo types
|-
|2D||Vehicles||Select colour mapping for vehicle
|-
|2E||Houses||Custom cargo production
|-
|2F||Industry tiles||Custom shape check
|-
|30||Industry tiles||Decide drawing default foundations
|-
|31||Vehicles||Start/stop check
|-
|32||Vehicles||32-day callback
|-
|33||Several||Sound effect callback
|-
|34||Vehicles <ref name="generic"/>||Autoreplace vehicle selection
|-
|35||Industries||Monthly random production change
|-
|36||Vehicles||Change vehicle Properties
|-
|37||Industries||Cargo sub-type display
|-
|38||Industries||Show additional text in fund window
|-
|39||Cargoes||Custom profit calculation
|-
|3A||Industries||Show additional text in industry window
|-
|3B||Industries||Control special effects
|-
|3C||Industry tiles||Disable autosloping
|-
|3D||Industries||Opt out of accepting cargo
|-
|40..13F|| ||--Reserved--
|-
|140||Stations||Animation control
|-
|141||Stations||Next animation frame
|-
|142||Stations||Length of animation frame
|-
|143||Houses||Protect building conditionally
|-
|144||Sounds <ref name="generic"/>||{{ottdp|1.2|2.6|ottdrev=r23144|ttdprev=r821}} Ambient sound effects
|-
|145||Cargoes||Custom station rating calculation
|-
|146||New Signals <ref name="generic"/>||New signals sprite drawing
|-
|147||Canals||Add sprite offset
|-
|148||Houses||Watched cargo accepted
|-
|149||Stations||Land slope check
|-
|14A||Industries||Decide industry color
|-
|14B||Industries||Decide input cargo types
|-
|14C||Industries||Decide output cargo types
|-
|14D||Houses||Customized building name
|-
|14E||Houses||Decide drawing default foundations
|-
|14F||Houses||Disable autosloping
|-
|150||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Decide drawing default foundations
|-
|152||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Animation control
|-
|153||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Next Animation frame
|-
|154||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Length of animation frame
|-
|155||Airports||{{ottdp|1.1|no|ottdrev=r20373}} Extra information about airport layout in the build gui
|-
|156||Airports||{{ottdp|1.1|no|ottdrev=r20373}} Airport layout name
|-
|157||Objects||Land slope check
|-
|158||Objects||Next animation frame
|-
|159||Objects||Animation control
|-
|15A||Objects||Length of animation frame
|-
|15B||Objects||Decide colour of building
|-
|15C||Objects||Show additional text in building window
|-
|15D||Objects||Disable autosloping
|-
|15E||Vehicles||{{ottdp|1.2|no|ottdrev=r23124}} Refit cost factor
|-
|15F||Industries||{{ottdp|1.3|no|ottdrev=r24186}} Set initial production level on construction
|-
|160||Vehicles||{{ottdp|1.5|no|ottdrev=r26747}} Advanced effect creation
|-
|161||Vehicles||{{ottdp|14|no|ottdrev=g05ed9f56fd}} Engine name
|-
|162||Vehicles||{{ottdp|14|no|ottdrev=gddd609ce9b}} Probability of reversing rail vehicle on build
|-
|163||Vehicles||{{ottdp|15|no|ottdrev=gd2496b6ec4}} Custom refit
|}
<references/>

{{:Callback: Visual effect and wagon power}}
{{:Callback: Wagon length}}
{{:Callback: Load amount}}
{{:Callback: Station availability}}
{{:Callback: Station sprite layout}}
{{:Callback: Refitted capacity callback}}
{{:Callback: Articulated engine}}
{{:Callback: House construction check}}
{{:Callback: AI construction/purchase selection}}
{{:Callback: Cargo Subtype Display}}
{{:Callback: Next animation frame}}
{{:Callback: Animation control}}
{{:Callback: Construction stage changes}}
{{:Callback: Can wagon be attached}}
{{:Callback: Building colour}}
{{:Callback: Cargo acceptance}}
{{:Callback: Length of animation frame}}
{{:Callback: Trigger building destruction}}
{{:Callback: Industry availability}}
{{:Callback: Additional text in purchase screen}}
{{:Callback: Custom station layout}}
{{:Callback: Industry location permissibility}}
{{:Callback: Random production change}}
{{:Callback: Get accepted cargo types}}
{{:Callback: Decide cargo acceptance}}
{{:Callback: Select colour mapping for vehicle}}
{{:Callback: Custom cargo production}}
{{:Callback: Custom shape check}}
{{:Callback: Decide drawing default foundations}}
{{:Callback: Vehicle Start/stop check}}
{{:Callback: 32-day callback}}
{{:Callback: Sound effect}}
{{:Callback: Autoreplace vehicle selection}}
{{:Callback: Monthly random production change}}
{{:Callback: Change vehicle properties}}
{{:Callback: Cargo sub-type display for industries}}
{{:Callback: Show additional text in fund/building window}}
{{:Callback: Custom profit calculation for cargoes}}
{{:Callback: Show additional text in industry window}}
{{:Callback: Control special industry effects}}
{{:Callback: Disable autosloping}}
{{:Callback: Opt out of accepting cargo}}
{{:Callback: Protect building conditionally}}
{{:Callback: Ambient sound effects}}
{{:Callback: Custom station rating calculation}}
{{:Callback: New signals sprite drawing callback}}
{{:Callback: Add sprite offset callback}}
{{:Callback: Watched cargo accepted}}
{{:Callback: Station slope check}}
{{:Callback: Decide industry colour}}
{{:Callback: Decide input and output cargo types}}
{{:Callback: Customized building name}}
{{:Callback: Extra information about layout in the build gui}}
{{:Callback: Layout name}}
{{:Callback: Object slope check}}
{{:Callback: Decide object colour}}
{{:Callback: Refit cost factor}}
{{:Callback: Set initial production level on construction}}
{{:Callback: Advanced effect creation}}
{{:Callback: Engine name}}
{{:Callback: Build probability}}
{{:Callback: Custom refit}}

Callback: Custom refit

2024-11-18T21:33:32Z

Michi cc: PR#13090

== Custom refit (163) ==

The custom refit callback allows overriding the refittablity of each cargo as defined by the standard vehicle properties. It will be called for each defined cargo type once after the game has loaded all NewGRF files. It needs to be enabled by a callback flag.

The callback is run in purchase list scope, i.e. for cargotype FF. No variables of an actual vehicle are available. Information about the cargo type the callback is called for is available in variables 10 and 18:

* variable 10:
{| |-
!bit numbers!!Meaning
|-
|0..15||[[Action0Cargos#CargoClasses_.2816.29 | Cargo classes]] of the cargo type
|-
|other bits||reserved for future use
|}
* variable 18:
{| |-
!bit numbers!!Meaning
|-
|0..7||Index of the cargo type in the cargo translation table
|-
|other bits||reserved for future use
|}

The callback has to return one of the following values:
{| |-
!Value!!Meaning
|-
|0|| Don't change refittability (i.e. use whatever the evaluation of the various refittability vehicle props has determined).
|-
|1|| Allow cargo type as a refit.
|-
|2|| Disallow cargo type as a refit.
|}

A failed callback is treated like a 0 return value.

'''Note:''' As this callback is not re-evaluated after game initialization, using any dynamic variables like e.g. game date will lead to undefined and faulty behaviour.

This callback is available starting with {{ottdp|15|no|ottdrev=gd2496b6ec4}} OpenTTD 15.

[[Category:Callbacks]]

VariationalAction2

2023-09-10T17:57:37Z

Michi cc: /* Type */ Related objects for airport (tiles)

==Introduction==

To support changes in graphics based on other factors than just the load states, you use a VarAction2. This provides a sophisticated way of deciding what graphics to use.

A VarAction2 can be used like any other action 2, but it provides an additional step in-between: instead of defining the action 1 sets right away, it instead specifies a list of additional action 2 entry, one of which is used depending on the kind of variation that is defined. These action 2 entries that are referred can in turn be variational or random (to provide chains of decisions), or they can be the final element, that is a regular action 2 which contains definitions of action 1 sets, or a callback result.

== Format ==

The data looks as follows:

<Sprite-number> * <Length> 02 <feature> <set-id> <type> <variable> <varadjust> <nvar> (<set-id> <low-range> <high-range>){n} <default>

{| |-
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''
|-
|<Sprite-number>||dec||A sequential sprite number
|-
|<length>||dec||The total number of bytes used in this action.
|-
|02||B||Defines action 02
|-
|<feature>||B||For what type of vehicle/station should this definition be used?
|-
|<set-id>||B||The ID of this action 2 (used like a cargo ID)
|-
|<type>||B||Type of VarAction2, see below
|-
|<variable>||B||Which variable we base the decision on
|-
|<varadjust>||V||How to manipulate the value before deciding.
|-
|<nvar>||B||Number of different ranges of the value (not counting the default)
|-
|<set-id>||W||Action 2 set-id to use for the following range.
|-
|<low-range>||B/W/D||Minimum (inclusive) of the range for which to use the above set-id
|-
|<high-range>||B/W/D||Maximum (inclusive) of the range
|-
|<default>||W||Action 2 set-id to use if no range matches
|}

The size of <varadjust> depends on <type> as well as the adjustments to be performed and must always provide an AND mask. For <type> 81, a "do nothing" <varadjust> would be 00 FF.

You repeat the sequence of <set-id> <low-range> <high-range> as often as <nvar> specifies.

<low-range> and <high-range> have a size of B, W, or D, depending on <type>. See that entry for more information.

== Description ==

=== Sprite-number ===

This is just the number you are at.

=== Length ===

Count the number of bytes in this action.

=== Feature ===

This sets the type of [[Features|feature]] that you wish to change. Set it to:

{|- |
!Value!![[Features|Feature]]
|-
|00||[[VariationalAction2/Vehicles | Trains]]
|-
|01||[[VariationalAction2/Vehicles | Road Vehicles]]
|-
|02||[[VariationalAction2/Vehicles | Ships]]
|-
|03||[[VariationalAction2/Vehicles | Aircraft]]
|-
|04||[[VariationalAction2/Stations | Stations]]
|-
|05||[[VariationalAction2/Canals | Canals/Rivers]]
|-
|06||[[VariationalAction2/Bridges | Bridges]]
|-
|07||[[VariationalAction2/Houses | Houses]]
|-
|09||[[VariationalAction2/Industry Tiles | Industry Tiles]]
|-
|0A||[[VariationalAction2/Industries | Industries]]
|-
|0B||Cargos (no feature specific variables)
|-
|0C||Sound Effects (no feature specific variables)
|-
|0D||[[VariationalAction2/Airports | Airports]]
|-
|0E||[[VariationalAction2/Signals | Signals]]
|-
|0F||[[VariationalAction2/Objects | Objects]]
|-
|10||[[VariationalAction2/Railtypes | Railtypes]]
|-
|11||[[VariationalAction2/Airport Tiles | Airport Tiles]]
|-
|12||[[VariationalAction2/Roadtypes | Roadtypes]]
|-
|13||[[VariationalAction2/Tramtypes | Tramtypes]]
|-
|14||[[VariationalAction2/Road Stops | Road Stops]]
|}

=== Set-ID ===

This defines the number of this action 2.  The ID can then be used as target in an action 3 or another variational/random action 2.

=== Type ===

{| |-
! !! B<br/>Access lowest byte !! {{ottdp|0.6|2.5}} W<br/>Access lowest word !! {{ottdp|0.6|2.5}} D<br/>Access lowest doubleword
|-
!align="left"| Access general variable or<br/>variable of the primary object
|align="center"| 81
|align="center"| 85
|align="center"| 89
|-
!align="left"| Access variable of "related" object
|align="center"| 82
|align="center"| 86
|align="center"| 8A
|}

The access type specifies both the size of the variable access, and selects between general variables and the object's innate variables, or variables of a specific "related" object.

{|- |
!colspan="2"|[[Features|Feature]]!!Related object
|-
|00-03||[[VariationalAction2/Vehicles | Vehicles]]||First [[VariationalAction2/Vehicles | vehicle]] of consist
|-
|04||[[VariationalAction2/Stations | Stations]]||[[VariationalAction2/Towns | Town]] to which station belongs
|-
|05||[[VariationalAction2/Canals | Canals/Rivers]]||N/A
|-
|06||[[VariationalAction2/Bridges | Bridges]]||[[VariationalAction2/Towns | Town]] of bridge
|-
|07||[[VariationalAction2/Houses | Houses]]||[[VariationalAction2/Towns | Town]] of house
|-
|09||[[VariationalAction2/Industry Tiles | Industry Tiles]]||[[VariationalAction2/Industries | Industry]] containing tile
|-
|0A||[[VariationalAction2/Industries | Industries]]||[[VariationalAction2/Towns | Town]] of industry
|-
|0B||Cargos||N/A
|-
|0C||Sound Effects||N/A
|-
|0D||[[VariationalAction2/Airports | Airports]]||[[VariationalAction2/Towns | Town]] to which airport belongs
|-
|0E||[[VariationalAction2/Signals | Signals]]||N/A
|-
|0F||[[VariationalAction2/Objects | Objects]]||[[VariationalAction2/Towns | Town]] of object
|-
|10||[[VariationalAction2/Railtypes | Railtypes]]||N/A
|-
|11||[[VariationalAction2/Airport Tiles | Airport Tiles]]||[[VariationalAction2/Airports | Airport]] containing tile
|-
|12||[[VariationalAction2/Roadtypes | Roadtypes]]||N/A
|-
|13||[[VariationalAction2/Tramtypes | Tramtypes]]||N/A
|}

Every variable specifies a size for it. Not every variable is a doubleword.
If the accessed variable is smaller than the size given here, the extra bits may contain junk, and should be <and-masked> out.

=== Variable ===

Variational Action 2 allows accessing these variables:

{| |-
!'''Number'''!![[GRFActionsDetailed|'''Size''']]!!Version!!'''Meaning'''
|-
|00-3F|| || ||See [[GlobalVariables| global variables page]].
|-
|40+x||D|| ||specially calculated feature-specific variable, see following feature-specific pages
|-
|5F||D||{{ottdp|0.7|2.6|ttdprev=r1928}}||Feature-specific random data: triggers in low byte, bits in other three bytes. Bits of the variable not associated with random or trigger bits are reserved.
|-
|60+x||D|| ||similar to 40+x variables, but the variable number must be followed by a byte, which will be given to the variable handler as parameter.
|-
|7B||-||{{ottdp|1.1|2.6|ottdrev=r21604|ttdprev=r2359}}||A special 60+x variable to be used in Advanced Variational Action 2. It allows to evaluate any other 60+x variable using a non-constant parameter from a register. The parameter of variable 7B specifies another 60+x variable which is evaluated. The parameter for that variable is read from the accumulator ('val1'), i.e. the result from the preceding operations of the same Advanced Variational Action 2. Hence variable 7B may not be the first variable used in the calculation. Variable 7B itself and 7E (procedure call) are not allowed to be used as parameter for variable 7B.

{{ottdp|1.2|no|ottdrev=r23138}} Since OpenTTD r23138 you can use this to pass 32 bit parameters to 60+x variables. Currently this is only useful for a few variables, e.g. vehicle variable 60. For most variables the higher bits of the parameter are considered reserved. So, make sure to mask the higher bits in the preceding calculations.
|-
|7C||D||{{ottdp|0.6|2.6|ttdprev=r1315}}||A special 60+x variable used to access values stored in the registers of [[Storages#Persistent storage|persistent storage]].
|-
|7D||D||{{ottdp|0.6|2.6|ttdprev=r1246}}||A special 60+x variable used to access values stored in the registers of [[Storages#Temporary storage|temporary storage]]. Available in the purchase list.
|-
|7E||D||{{ottdp|0.6|2.5}}||A special 60+x variable indicating a [[VarAction2Advanced#Using procedures|procedure call]]. Available in the purchase list.
|-
|7F||D||{{ottdp|0.6|2.5}}||A special 60+x variable that reads GRF parameter whose number is given by the 60+x parameter. Available in the purchase list.
|-
|80+x|| || ||Feature-specific variable, see following feature-specific pages. While most of these variables actually refer to raw memory locations of original TTD structures, you cannot rely on that. Some variables were added later, some were moved or replaced. Only the variables listed in the specs are somewhat set to not be changed in the future.
|}

For all features, the 80+x variables are offsets into the corresponding structure in TTD's game data.  The 40+x and 60+x variables are special variables that are computed on-the-fly, and aren't actually stored anywhere in memory, unless stated otherwise. Therefore they should be used as little as necessary so as not to slow down the game too much with the calculation of these variables (which can be called thousands of times per second, whenever any vehicle moves).

When displaying a vehicle (etc.) in the purchase list, the game will show those variations based on external variables (dates etc.) correctly, but variations based on vehicle variables (variables 40+x, 60+x and 80+x) will always show the first (not the default) cargo-ID unless otherwise specified for the given variable. If you do a calculation, the first cargo-ID will be selected if any of the needed variables is inaccessible.

The lists of 80+x variables on the following pages are not exhaustive; only the useful variables are listed there. For a full list check the definition of corresponding structures in TTD. Marcin Grzegorczyk has a pretty good list of the structure definitions on his [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html savegame internals page].

=== varadjust ===

Adjust variable to a more useful range. It has the following format:

<pre> <shift-num> <and-mask> <nowiki>[<add-val> <divide-val>/<modulo-val>]</nowiki></pre>

{| |-
!'''Element'''!![[GRFActionsDetailed|'''Size''']]!!'''Description'''
|-
|shift-num||B||value to right-shift the variable, and some special bits. See below.
|-
|and-mask||B/W/D||value with which to AND the variable after shifting. Return this value if neither bit 6 nor bit 7 of shift-num are set.
|-
|add-val||B/W/D||value to add to the variable after ANDing. Only present if bits 6 or 7 are set in shift-num.
|-
|divide-val||B/W/D||return the sum divided by this value. Only present if bit 6 is set in shift-num.
|-
|modulo-val||B/W/D||return the sum modulo (remainder of division by) this value. Only present if bit 7 is set in shift-num.
|}

<shift-num> is a partial bit-mask; its bits have the following meanings:

{| |-
!Bit(s)!!Value!!Version!!Meaning
|-
|0..4||0..1F||{{ottdp|0.6|2.0}}||number of bits to right shift <variable>
|-
|5||20||{{ottdp|0.6|2.5}}||This is an [[VarAction2Advanced|advanced VarAction2]]
|-
|6||40||{{ottdp|0.6|2.5}}||This is a shift-and-add-divide adjustment.
|-
|7||80||{{ottdp|0.6|2.5}}||This is a shift-and-add-modulo adjustment.
|}

Bits 6 and 7 may not both be set. If neither are set, this varadjust is a shift-and adjustment.

Note that for the add and divide operations, both the variable and the divisor are taken to be signed numbers. This means that if the high bit is set, the number is taken to be negative, so you may need to mask out the most significant bit to do an unsigned division.

=== nvar ===

Here you set how many different ranges to check for. If the value of the variable, after the above manipulations, is not within one of these ranges, the default will be used.  When displayed in the purchase window, the game will always show the first range if the variable is of the 40+x or 80+x type (because the variable is undefined since the vehicle doesn't exist yet).

{{ottdp|0.6|2.5|ttdprev=2.0.1 alpha 57}} Since TTDPatch 2.0.1 alpha 57, nvar=0 is a special case. Instead of using ranges, nvar=0 means that the result of an [[VarAction2Advanced|advanced]] calculation (or, if no calculation is performed, the adjusted variable value itself) is returned as callback result, with bit 15 set.  This is useful for those callbacks where many different return values are possible and it is easier to calculate them than list them in ranges.  The default value must still be specified, and will be used in case the variable(s) used are not available.

=== sets and ranges ===

For each of the ranges to check, you give the set-id as a '''WORD''' value (i.e. with a 00 following, e.g. set-id 5 becomes 05 00, or - in case of a callback result - by setting the high bit, e.g. 05 80), followed by the low and high limits of this range.  The first range that matches will be used.

The various \b, \w, and \d escape sequences can be useful for <min-range> and <max-range>. See [[GRFActionsDetailed#Byte order|the discussion of escape sequences]] for further information.

=== default ===

The set-id to use if none of the ranges matches.

=Example=
<pre>
-1 * 15 02 05 03 81 // Action2, Feature 05 (canals), action2ID 03, 1-byte variable
81 00 04 // variable 81 (terrain type), shift 00, mask 0x04 (=bit for "on or above snowline")
01 // check one range
02 00 04 04 // snowy tile: link to action2ID 02
01 00 // default: link to action2ID 01

</pre>

Callbacks

2023-01-30T22:22:15Z

Michi cc: Engine name CB

==Introduction==

A callback is a special action 2 that the patch "calls" in order to modify various features, an example being the visual effect of train vehicles.  See the [[ttwiki:CallbacksTut|callback tutorial]] on how to use them.

In the final action 2 of a chain of VarAction2s, the second byte of the matching entry has to have bit 7 set to identify it as a callback result.

For example, 04 00 is not a callback result (but it may be the ID of another chained action 2), whereas 04 80 is a callback result with a value of 4. In total a callback has 15 bit result values, where the upper 7 bits are stored in the second byte. For example, 54 C2 is a callback result with a value of 4254=16980, where again the second byte has bit 7 set, changing the 42 into C2.

{{grfTill|7}} For GRF version 7 and below not all 15 bit values are available as return values, only values between 00 and 7EFF.
For compatibility with earlier patch versions, FF in the high byte is taken to mean the same thing as 80, so 04 FF also has a callback result of 4. Note that if your grf file needs to be compatible with versions before TTDPatch 2.0.1 alpha 40, you must set the high byte to FF, and so can use only 8 bit results.

{{grfFrom|8}} For GRF version 8 and above this compatibility layer has been removed. Callbacks can return all 15 bit values between 00 and 7FFF.

To check for a specific callback, use an [[VariationalAction2]] or [[VarAction2Advanced]] to check for variable 0C.
* Variable 0C contains the callback number.
* Variable 0C is a word, thus the VarAction2 must use type 85.
* Results can be specified directly using 8xxx values (see above), or with 8xxx value in subsequent (Basic/Variational/Random)Action2 which are referenced as usual with their set-id.
* The default case of the VarAction2 must point to the regular graphics chain, so that unknown/future callbacks results in a "callback failure" result.

Example:
<Sprite-number> * <Length> 02 <feature> <set-id> 85 0C 00 \wxFFFF
<nvar> (<set-id/result> \wx <callback> \wx <callback>){n}
<set-id of graphics chain>

The format for VarAction2 is explained in detail on the [[VariationalAction2]] page.

== List of callbacks ==

The following callbacks are defined by the patch.  The number of the callback is what will be stored in variable 0C so that you can return the right results if you have several callbacks.  All callbacks are explained in more detail below.

'''PLEASE NOTE:''' Since TTDPatch 2.5 beta 5, the size of variable 0C has changed, and now there are word-sized callback numbers as well. To maintain backwards compatibility, only callbacks 10..3F can be checked using a byte-sized check. Callbacks 140 and above, on the other hand, must be checked using a word or dword sized check, to make sure they are identified uniquely.

{| |-
!Number!!Feature(s)!!Meaning
|-
|10||Vehicles||[[Callback: Visual effect and wagon power|Visual effect and wagon power]]
|-
|11||Vehicles||[[Callback: Wagon length|Wagon length]]
|-
|12||Vehicles||[[Callback: Load amount|Load amount]]
|-
|13||Stations||[[Callback: Station availability|Station availability]]
|-
|14||Stations||[[Callback: Station sprite layout|Select sprite layout]]
|-
|15||Vehicles||[[Callback: Refitted capacity callback|Refitted capacity callback]]
|-
|16||Trains||[[Callback: Articulated engine|Build articulated engines]]
|-
|17||Houses||[[Callback: House construction check|House construction check]]
|-
|18||Several <ref name="generic">Generic callbacks are called for the feature, not any specific vehicle ID. Read the [[Action3#n-id|Action 3]] entry on how to define these.</ref>||[[Callback: AI construction/purchase selection|AI construction/purchase selection]]
|-
|19||Vehicles||[[Callback: Cargo Subtype Display|Cargo sub-type display]]
|-
|1A||Houses||Next animation frame
|-
|1B||Houses||Animation control
|-
|1C||Houses||Construction stage changes
|-
|1D||Trains||Can wagon be attached
|-
|1E||Houses||Decide colour of building
|-
|1F||Houses||Cargo acceptance
|-
|20||Houses||Length of animation frame
|-
|21||Houses||Trigger building destruction
|-
|22||Industries||Availability
|-
|23||Vehicles||Additional text in purchase screen
|-
|24||Stations||Custom station layout
|-
|25||Industry tiles||Animation control
|-
|26||Industry tiles||Next animation frame
|-
|27||Industry tiles||Length of animation frame
|-
|28||Industries||Industry location permissibility
|-
|29||Industries||Random production change
|-
|2A||Houses||Get accepted cargo types
|-
|2B||Industry tiles||Decide cargo acceptance
|-
|2C||Industry tiles||Get accepted cargo types
|-
|2D||Vehicles||Select colour mapping for vehicle
|-
|2E||Houses||Custom cargo production
|-
|2F||Industry tiles||Custom shape check
|-
|30||Industry tiles||Decide drawing default foundations
|-
|31||Vehicles||Start/stop check
|-
|32||Vehicles||32-day callback
|-
|33||Several||Sound effect callback
|-
|34||Vehicles <ref name="generic"/>||Autoreplace vehicle selection
|-
|35||Industries||Monthly random production change
|-
|36||Vehicles||Change vehicle Properties
|-
|37||Industries||Cargo sub-type display
|-
|38||Industries||Show additional text in fund window
|-
|39||Cargoes||Custom profit calculation
|-
|3A||Industries||Show additional text in industry window
|-
|3B||Industries||Control special effects
|-
|3C||Industry tiles||Disable autosloping
|-
|3D||Industries||Opt out of accepting cargo
|-
|40..13F|| ||--Reserved--
|-
|140||Stations||Animation control
|-
|141||Stations||Next animation frame
|-
|142||Stations||Length of animation frame
|-
|143||Houses||Protect building conditionally
|-
|144||Sounds <ref name="generic"/>||{{ottdp|1.2|2.6|ottdrev=r23144|ttdprev=r821}} Ambient sound effects
|-
|145||Cargoes||Custom station rating calculation
|-
|146||New Signals <ref name="generic"/>||New signals sprite drawing
|-
|147||Canals||Add sprite offset
|-
|148||Houses||Watched cargo accepted
|-
|149||Stations||Land slope check
|-
|14A||Industries||Decide industry color
|-
|14B||Industries||Decide input cargo types
|-
|14C||Industries||Decide output cargo types
|-
|14D||Houses||Customized building name
|-
|14E||Houses||Decide drawing default foundations
|-
|14F||Houses||Disable autosloping
|-
|150||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Decide drawing default foundations
|-
|152||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Animation control
|-
|153||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Next Animation frame
|-
|154||Airport tiles||{{ottdp|1.1|no|ottdrev=r19197}} Length of animation frame
|-
|155||Airports||{{ottdp|1.1|no|ottdrev=r20373}} Extra information about airport layout in the build gui
|-
|156||Airports||{{ottdp|1.1|no|ottdrev=r20373}} Airport layout name
|-
|157||Objects||Land slope check
|-
|158||Objects||Next animation frame
|-
|159||Objects||Animation control
|-
|15A||Objects||Length of animation frame
|-
|15B||Objects||Decide colour of building
|-
|15C||Objects||Show additional text in building window
|-
|15D||Objects||Disable autosloping
|-
|15E||Vehicles||{{ottdp|1.2|no|ottdrev=r23124}} Refit cost factor
|-
|15F||Industries||{{ottdp|1.3|no|ottdrev=r24186}} Set initial production level on construction
|-
|160||Vehicles||{{ottdp|1.5|no|ottdrev=r26747}} Advanced effect creation
|-
|161||Vehicles||{{ottdp|14|no|ottdrev=g05ed9f56fd}} Engine name
|}
<references/>

{{:Callback: Visual effect and wagon power}}
{{:Callback: Wagon length}}
{{:Callback: Load amount}}
{{:Callback: Station availability}}
{{:Callback: Station sprite layout}}
{{:Callback: Refitted capacity callback}}
{{:Callback: Articulated engine}}
{{:Callback: House construction check}}
{{:Callback: AI construction/purchase selection}}
{{:Callback: Cargo Subtype Display}}
{{:Callback: Next animation frame}}
{{:Callback: Animation control}}
{{:Callback: Construction stage changes}}
{{:Callback: Can wagon be attached}}
{{:Callback: Building colour}}
{{:Callback: Cargo acceptance}}
{{:Callback: Length of animation frame}}
{{:Callback: Trigger building destruction}}
{{:Callback: Industry availability}}
{{:Callback: Additional text in purchase screen}}
{{:Callback: Custom station layout}}
{{:Callback: Industry location permissibility}}
{{:Callback: Random production change}}
{{:Callback: Get accepted cargo types}}
{{:Callback: Decide cargo acceptance}}
{{:Callback: Select colour mapping for vehicle}}
{{:Callback: Custom cargo production}}
{{:Callback: Custom shape check}}
{{:Callback: Decide drawing default foundations}}
{{:Callback: Vehicle Start/stop check}}
{{:Callback: 32-day callback}}
{{:Callback: Sound effect}}
{{:Callback: Autoreplace vehicle selection}}
{{:Callback: Monthly random production change}}
{{:Callback: Change vehicle properties}}
{{:Callback: Cargo sub-type display for industries}}
{{:Callback: Show additional text in fund/building window}}
{{:Callback: Custom profit calculation for cargoes}}
{{:Callback: Show additional text in industry window}}
{{:Callback: Control special industry effects}}
{{:Callback: Disable autosloping}}
{{:Callback: Opt out of accepting cargo}}
{{:Callback: Protect building conditionally}}
{{:Callback: Ambient sound effects}}
{{:Callback: Custom station rating calculation}}
{{:Callback: New signals sprite drawing callback}}
{{:Callback: Add sprite offset callback}}
{{:Callback: Watched cargo accepted}}
{{:Callback: Station slope check}}
{{:Callback: Decide industry colour}}
{{:Callback: Decide input and output cargo types}}
{{:Callback: Customized building name}}
{{:Callback: Extra information about layout in the build gui}}
{{:Callback: Layout name}}
{{:Callback: Object slope check}}
{{:Callback: Decide object colour}}
{{:Callback: Refit cost factor}}
{{:Callback: Set initial production level on construction}}
{{:Callback: Advanced effect creation}}
{{:Callback: Engine name}}

Callback: Engine name

2023-01-30T22:20:50Z

Michi cc: Engine name callback

== Engine name (161) ==

This callback allows you to dynamically determine the name shown for an engine type. 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.

{{grfFrom|8}} For GRF version 8 and above you can return 400 to display the engine name from the property (instead of failing the callback).

The callback is run in purchase list scope, i.e. for cargotype FF. No variables of an actual vehicle are available.

During this callback, variable 10 (extra callback info 1) contains information about the context where the name is shown.

{| |-
! Bits 0 - 7 of [[GlobalVariables#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|variable 10]]<ref>Values correspond to the values used for [[Action2/Vehicles#Drawing_different_sprites_on_map_in_various_GUIs|sprite drawing]].</ref>!! Meaning
|-
| 00 || No specific context is avaible.
|-
| 01..10 || reserved
|-
| 11 || Name is shown in the vehicle details GUI. (This includes the refit GUI.)
|-
| 12..1F || reserved for other future GUIs.
|-
| 20 || Vehicle is drawn in the purchase list. (This includes the autoreplace GUI.)<br>Bits '''8 - 15''' contain the indentation level in the list, e.g. when using vehicle variants.
|-
| 21 || Vehicle is drawn in the exclusive preview GUI or in the advertisement news.
|-
| 22..2F || reserved for other future GUIs with non-purchased vehicles.
|-
| 30..FF || reserved
|}

This callback is available from {{ottdp|14|no|ottdrev=g05ed9f56fd}} OpenTTD 14 and above.
[[Category:Callbacks]]

Action0/Vehicles/Planes

2023-01-30T22:06:45Z

Michi cc: /* Properties */

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of planes.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Is helicopter? 2=no, 0=yes
|-
|0A||B||{{ottdp|0.6|2.0}}||Is large? 0=no, 1=yes (i.e. can't safely land on small airports)
|-
|0B||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0C||B||{{ottdp|0.6|2.0}}||Speed in units of 8 mph, that is: property = (speed in mph) / 8
|-
|0D||B||{{ottdp|0.6|2.0}}||Acceleration in units of 3/8 mph/tick, that is: property = (acceleration in mph/tick) * 8/3 <ref>{{ottd|<1.3.1}} In OpenTTD before r25115 the units for acceleration were messed up. The unit used was about 1 mph/tick, so aircraft accelerated more than twice as fast. Also values bigger than 19 failed.</ref>
|-
|0E||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|0F||W||{{ottdp|0.6|2.0}}||Primary cargo capacity (passenger or refitted cargo)
|-
|11||B||{{ottdp|0.6|2.0}}||Secondary cargo capacity (mail)
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect
|-
|13||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (Bit Value) in [[CargoTypes]]
|-
|14||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|15||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|1F||W||{{ottdp|1.2|no|ottdrev=r23504}}||Aircraft range in tiles. Distance is euclidean, a value of 0 means range is unlimited
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below
|}
<references/>

== Descriptions ==

=== Primary (0F) and secondary (11) cargo capacity ===
Aircraft can transport up to two cargo types.
The first (primary) cargo type can be changed when refitting the aircraft.

The secondary cargo type is always mail, and is only present when the primary cargo type is part of the [[Action0/Cargos#CargoClasses_.2816.29|passenger cargo class]].

See also the page about [[VehicleRefitting|vehicle refitting]].

=== Sound effect (12) ===

The following sound effects are used by planes (note, the setting is ignored for helicopters):

{| |-
!Number!!Sound
|-
|06||Propeller sound 1
|-
|07||Jet sound 1
|-
|3B||Supersonic
|-
|3D||Jet sound 2
|-
|45||Propeller sound 2
|-
|46||Jet sound 3
|}

{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.

{{ottdp|1.11|no|ottdrev=6198a47}} Since OpenTTD g6198a47 this prop can be used to to set custom Action11 sound effects for helicopers. Default sound effects are ignored as before.

=== Callbacks (14, 22) ===
For planes, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 14 (certain other, not as frequently used callbacks are available without setting a bit here)::

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (15) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 15 specifies zero cost.
|-
|5||20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6||40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
Note: This also applies to the rotor sprite, if custom rotor sprites are used.
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Custom cargo ageing period (1C) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Ships

2023-01-30T22:06:33Z

Michi cc: /* Properties */

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of ships.
== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Refittable (0 no, 1 yes)
|-
|0A||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0B||B||{{ottdp|0.6|2.0}}||Speed in mph*3.2
|-
|0C||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'
|-
|0D||W||{{ottdp|0.6|2.0}}||Capacity
|-
|0F||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|10||B||{{ottdp|0.6|2.0}}||Sound effect type (4=cargo ship, 5=passenger ship)<br/>{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.
|-
|11||D||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Bit mask of cargo types available for refitting, see column 2 (bit values) in [[CargoTypes]]
|-
|12||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|13||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|14||B||{{ottdp|1.2|2.5|ttdprev=alpha 44|ottdrev=r22639}}||Ocean speed fraction, sets fraction of top speed available in the ocean; e.g. 00=100%, 80=50%, FF=0.4%
|-
|15||B||{{ottdp|1.2|2.5|ttdprev=alpha 44|ottdrev=r22639}}||Canal speed fraction, same as above but for canals and rivers
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Refittable cargo classes, see [[Action0Trains#Cargo_classes_.2828.2C_29.29|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Non-refittable cargo classes, see [[Action0Trains#Cargo_classes_.2828.2C_29.29|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.6|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||B||{{ottdp|1.1|no|ottdrev=r21240}}||Visual effect
|-
|1D||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1F||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below
|}

== Descriptions ==

=== Callbacks (12, 22) ===
For ships, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 12 and 22 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (13) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 13 specifies zero cost.
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort_vehicle_list_.281A.29|trains]] for details.

=== Visual effect (1C) ===
See the equivalent [[Action0Trains#Visual_effects_and_wagon_power_.2822.29|train property]] for information about the meaning of all bits. There is no default effect for ships, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.

=== Custom cargo ageing period (1D) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/RoadVehicles

2023-01-30T22:06:19Z

Michi cc: /* Properties */

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of road vehicles.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|1.10|no}}||Roadtype / tramtype (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||Speed in mph*3.2||no
|-
|09||B||{{ottdp|0.6|2.0}}||Running cost factor||should be zero
|-
|0A||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|0E||B||{{ottdp|0.6|2.0}}||Sprite ID (FF for new graphics)||yes
|-
|0F||B||{{ottdp|0.6|2.0}}||Capacity||yes
|-
|10||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'
||yes
|-
|11||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect: 17/19/1A for regular, 3C/3E for toyland<br/>{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.||no
|-
|13||B||{{ottdp|1.1|2.0}} {{grfFrom|2}}||Power in 10 hp, see below||should be zero
|-
|14||B||{{ottdp|1.1|2.0}} {{grfFrom|2}}||Weight in 1/4 tons, see below||should be zero
|-
|15||B||{{ottdp|0.7|2.0}} {{grfFrom|2}}||Speed in mph*0.8, see below||no
|-
|16||D||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Bit mask of cargo types available for refitting (not refittable if 0 or unset), see column 2 (bit values) in [[CargoTypes]]||yes
|-
|17||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|18||B||{{ottdp|1.1|2.5|ttdprev=alpha 30}}||Coefficient of tractive effort||should be zero
|-
|19||B||{{ottdp|1.1|2.5|ttdprev=alpha 30}}||Coefficient of air drag||should be zero
|-
|1A||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1B||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|1C||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags||partly ("tram" should be same as front)
|-
|1D||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]||yes
|-
|1E||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]||yes
|-
|1F||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date||no
|-
|20||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list||no
|-
|21||B||{{ottdp|1.1|no|ottdrev=r21240}}||Visual effect||yes
|-
|22||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|23||B||{{ottdp|1.2|no|ottdrev=r23164}}||Make vehicle shorter, see [[Action0/Vehicles/Trains#Shorter_train_vehicles_.2821.29|train property 21]]||yes
|-
|24||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]||yes
|-
|25||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]||yes
|-
|26||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|27||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|28||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below||yes
|}

== Description ==

=== Roadtype or tramtype (05) ===
{{ottdp|1.10|no}} Roadtype or tramtype for the vehicle. This is an index into the [[Action0/Global_Settings#Roadtype_translation_table_.2816.29|roadtype]] or [[Action0/Global_Settings#Tramtype_translation_table_.2817.29|tramtype]] translation table.

This property:
* will use property 1C bit 0 (flag 'vehicle is tram') to determine whether to use a roadtype or tramtype table
* requires an appropriate roadtype or tramtype table to be loaded

=== Running cost base (0A) and factor (09) ===

TTD calculates all costs by multiplying a 48-bit base amount with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of road vehicles, the following base amounts are available:

{| |-
!Type!!Value!!in little-endian notation
|-
|Road vehicle running cost base||4C48||48 4C 00 00
|}

Theoretically, you could use pointers to other [[BaseCosts|base amounts]] available in TTD, but these are the numbers TTD uses for road vehicles.

=== Cost factor (11) ===

The cost factor is a bit-coded value which determines how expensive a vehicle is. The table below gives you some values to use for finding the right price for your vehicles.

{| |-
!Cost factor!!Price
|-
|00||$ 0
|-
|01||$ 108
|-
|10||$ 1,750
|-
|20||$ 3,500
|-
|80||$ 14,000
|-
|FF||$ 27,890
|}

=== Realistic acceleration properties (13, 14, 15) ===

Using property 15 to set the speed, it is possible to achieve speeds larger than 80 mph (127 km/h), to which property 08 is limited. When setting property 15, always set property 08 as well, so that the vehicle works reasonably well whether realistic acceleration is turned on or off. If property 15 is not set, the value from property 08 is used instead.

{{ttdp|}} TTDPatch uses these properties only if road vehicles are set to realistic acceleration in the NewCurveAndMountainHandling switch. They are ignored otherwise.

{{ottd|}} OpenTTD uses these properties always, if they are defined and gives the speed defined here precedence over the one defined in property 08.

=== Callbacks (17, 28) ===

For road vehicles, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 17 and 28 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated vehicle
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Coefficient of tractive effort (18) ===

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

For a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on.  If not set, a default of 4C is used, for a fraction of 0.30, corresponding to W<sub>adh</sub>=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

=== Coefficient of air drag (19) ===

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units.  00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!!<16!!16!!24!!32!!48!!64!!96!!128!!192!!256!!...
|-
|c2||192||128||96||64||48||32||24||16||12||8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTd's consistent scaling.  If a vehicle doesn't reach its historical top speed, you might try setting prop. 19 one or two higher than the default above, otherwise it's probably a good idea to leave it at the default.

=== Refit cost (1A) ===

Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (1C) is set, auto-refitting is allowed.

=== Miscellaneous flags (1C) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||Vehicle is a tram/light rail vehicle and requires tram tracks to operate
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 1A specifies zero cost.
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

=== Long format introduction date (1F) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (20) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Visual effect (21) ===
See the equivalent [[Action0Trains#Visual effects and wagon power 22|train property]] for information about the meaning of all bits. There is no default effect for road vehicles, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.

=== Custom cargo ageing period (22) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Trains

2023-01-30T22:06:08Z

Michi cc: Engine name CB

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

=Introduction=
Defining properties of train vehicles.

= Properties =

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|0.6|2.0}}||Track type (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||AI special flag: set to 1 if engine is 'optimized' for passenger service (AI won't use it for other cargo), 0 otherwise||no
|-
|09||W||{{ottdp|0.6|2.0}}||Speed in mph*1.6 (see below)||no
|-
|0B||W||{{ottdp|0.6|2.0}}||Power (0 for wagons)||should be zero
|-
|0D||B||{{ottdp|0.6|2.0}}||Running cost factor (0 for wagons)||should be zero
|-
|0E||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sprite ID (FD for new graphics)||yes
|-
|13||B||{{ottdp|0.6|2.0}}||Dual-headed flag; 1 if dual-headed engine, 0 otherwise||should be zero also for front
|-
|14||B||{{ottdp|0.6|2.0}}||Cargo capacity||yes
|-
|15||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'
||yes
|-
|16||B||{{ottdp|0.6|2.0}}||Weight in tons||should be zero
|-
|17||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|18||B||{{ottdp|<0.7|2.0}}<ref>This property is not used by OpenTTDs NoAI API.</ref>||Engine rank for the AI (AI selects the highest-rank engine of those it can buy)||no
|-
|19||B||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Engine traction type (see below)||no
|-
|1A||B/B*<ref>{{ottdp|0.7|no|ottdrev=r13831}} Since OpenTTD r13831 this is an extended byte.</ref>||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Not a property, but an action: sort the purchase list.||no
|-
|1B||W||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Power added by each wagon connected to this engine, see below||should be zero
|-
|1C||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1D||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (bit value) in [[CargoTypes]]||yes
|-
|1E||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|1F||B||{{ottdp|0.6|2.5|ttdprev=alpha 19}}||Coefficient of tractive effort||should be zero
|-
|20||B||{{ottdp|1.1|2.5|ttdprev=alpha 27}}||Coefficient of air drag||should be zero
|-
|21||B||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Make vehicle shorter by this amount, see below||yes
|-
|22||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set visual effect type (steam/smoke/sparks) as well as position, see below||yes
|-
|23||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set how much weight is added by making wagons powered (i.e. weight of engine), see below||should be zero
|-
|24||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||High byte of vehicle weight, weight will be prop.24*256+prop.16||should be zero
|-
|25||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||User-defined bit mask to set when checking veh. var. 42||yes
|-
|26||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|27||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous flags||partly
|-
|28||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes||yes
|-
|29||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes||yes
|-
|2A||D||{{ottdp|0.6|2.5|ottdrev=r7191|ttdprev=r1210}}||Long format introduction date||no
|-
|2B||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|2C||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types||yes
|-
|2D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types||yes
|-
|2E||W||{{ottdp|12|no|ottdrev=g2183fd4dab}}||Maximum curve speed modifier||yes
|-
|2F||W||{{ottdp|13|no}}||Vehicle variant group||no
|-
|30||D||{{ottdp|13|no}}||Extra flags||??
|-
|31||B||{{ottdp|14|no|ottdrev=g2d73076056}}||Additional callback flags bit mask, see below||yes
|}
<references/>

= Description =

== Track type (05) ==
Set track type of vehicle: 0 = rail, 1 = monorail, 2 = maglev. For setting the appropriate traction type, see [[Action0Trains#Engine traction type 19|prop19]].

{{ottdp|1.0|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, this property is an index into the table instead.

== Speed (09) ==

Train speed is in units of mph*1.6, i.e. approximately km/h.

For wagons, this value is only used if the "wagonspeedlimit" switch is on, and it limits the speed of the train to that of the lowest wagon speed.  This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed.

For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit.

== Power (0B) ==

The power of the engine, in HP.

A value of 0 means that the vehicle will be a wagon, otherwise it will be an engine.

== Running cost base (0E) and factor (0D) ==

TTD calculates all costs by multiplying a 32-bit [[BaseCosts|base amount]] with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of train vehicles, the following base amounts are available depending on the vehicle type (the value here is a pointer into TTD's memory where the actual amount is stored):

{| |-
!Type!!Value!!in little-endian notation
|-
|Steam engines||4C30||30 4C 00 00
|-
|Diesel engines||4C36||36 4C 00 00
|-
|Electric engines||4C3C||3C 4C 00 00
|-
|Wagons||0||00 00 00 00
|}

Theoretically, you could use pointers to other base amounts available in TTD, but these are the numbers TTD uses for train vehicles.

The following are some real values for maintenance costs depending on the setting of the above two factors.  This value is correct for medium difficulty, but increases and decreases for hard and easy difficulties respectively.  These are the costs of a new game starting in 1921, because they obviously increase with inflation over time (unless noinflation is turned on).

'''Running cost base 4C30 (steam)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 42
|-
|10||$ 700
|-
|20||$ 1.400
|-
|80||$ 5.600
|-
|A0||$ 7.000
|-
|FF||$ 11.112
|}

'''Running cost base 4C36 (diesel)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 40
|-
|10||$ 650
|-
|20||$ 1.300
|-
|80||$ 5.200
|-
|A0||$ 6.500
|-
|FF||$ 10.318
|}

'''Running cost base 4C3C (electric)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 36
|-
|10||$ 600
|-
|20||$ 1.200
|-
|80||$ 4.800
|-
|A0||$ 6.000
|-
|FF||$ 9.524
|}

== Cost factor (17) ==

The cost factor is a bit-coded value which determines how expensive an engine is. There is no distinction between steam, diesel or electric engines, they all use the same cost factor. The table below gives you some values to use for finding the right price for your engines.

{| |-
!Cost factor!!Price
|-
|01||$ 3.124
|-
|10||$ 50.000
|-
|20||$ 100.000
|-
|80||$ 400.000
|-
|A0||$ 500.000
|-
|FF||$ 796.874
|}

== Engine traction type (19) ==

This sets the traction type of a train engine, i.e. whether it is powered by steam, diesel, electric, monorail or maglev technology.  It also sets the corresponding sound effect of the engine, and if property 22 is not set, the visual effect as well.

The following ranges are available (and it does not matter which value you pick):

{| |-
!Values!!Traction type
|-
|00..07||Steam
|-
|08..27||Diesel
|-
|28..31||Electric
|-
|32..37||Monorail
|-
|38..41||Maglev
|}
Default value is 00, i.e. steam. For setting the appropriate track type, see [[Action0Trains#Track type 05|prop05]].

{{ottdp|1.1|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, setting this property does NOT alter the track type.

== Sort vehicle list (1A) ==

This is not a property as such, but an action.  It forces TTDPatch to shuffle the vehicle this "property" is being set for in front of the vehicle with the given value of the property.  The order of this list is only used in the train purchase window.

For example, setting prop. 1A for vehicle 09 to a value of 07 would lead to the following internal list: ... 05 06 09 07 08 0A 0B ...

This property can not simply be overwritten, because the list is already shuffled when trying to do so.

{{ottdp|no|2.0}} It is possible to reset the list to its original order with a special action 0 that has num-info set to 0, and only sets property 1A for trains:
<pre>00 00 01 00 00 1A</pre>

Resetting the list should however only be done by sets that contain replacements for all train vehicles.

{{ottdp|0.7|no|ottdrev=r13831}} This property is an extended byte in OpenTTD since r13831!

== Powered train wagons (1B and 23, see also 22) ==

Normally, train wagons are unpowered in TTD, and if you set property 0B to a non-zero value, they become engines instead.  Therefore, to model real-life trains where wagons have power, a different mechanism is needed.
To make train wagons powered, you set property 1B of the '''engine''' instead of the wagon. This determines how much power each wagon adds to the train when attached to this engine. This only applies to wagons with a [[Action3|graphics override]] for this engine as well.  This means that for example passenger wagons (with an override) will add power, but coal wagons (with no override) will not.

In addition to adding power, these wagons are also heavier by the amount set in property 23.

== Refit cost (1C) ==

Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (27) is set, auto-refitting is allowed.

== Callbacks (1E, 31) ==
For trains, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 1E and 31 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|0||1||10||Powered wagons and visual effect
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated engines
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

These callbacks do not need a bit to activate them, they are always active and will be used if defined in the action 3/action 2 chain.
{| |-
!Variable 0C value!!Callback
|-
|1D||Can wagon be attached
|-
|23||Additional text in purchase screen
|-
|31||Start/stop check
|-
|32||32-day callback
|-
|36||Change Vehicle Properties
|-
|15E||Refit cost
|}

== Coefficient of tractive effort (1F) ==

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

Theoretically, this value should be calculated by taking the ratio of adhesive weight W<sub>adh</sub> (i.e. the vehicle weight that rests on powered axles) times the coefficient of friction µ between the wheels and the rails to the total vehicle weight W, times 255, and convert to hex:

prop. 1F = HEX ((W<sub>adh</sub> * µ / W) * 255)

With prop. 1F having a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

Sometimes you know the real-life tractive effort instead of adhesive weight and coefficient of friction. To help calculating prop. 1F in that case, here's a small example using the NS 1600 (Electric) with a mass of 84 tons and real-life tractive effort (TE<sub>real</sub>) of 259 kN. To quickly find the value for property 1F you fill in the following formula:

prop. 1F = HEX ((TE<sub>real</sub> / (Mass * g) * 255)

That may look confusing but you already know all variables:

prop. 1F = HEX ((259 / (84 * 9.8) * 255)

prop. 1F = HEX (0.3146 *255) = HEX(80.229)

HEX calculations only work with figures in the natural domain: each figure has to be a positive and round figure. Therefore the value you convert to HEX isn't 80.229 but 80:

HEX 80 = 50

Property 1F for the NS 1600 (Electric) would then be: 1F 50.

== Coefficient of air drag (20) ==

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. 00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!! <16!! 16!! 24!! 32!! 48!! 64!! 96!! 128!! 192!! 256!! ...
|-
|c2|| 192|| 128|| 96|| 64|| 48|| 32|| 24|| 16|| 12|| 8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTD's consistent scaling. If a train doesn't reach its historical top speed, you might try setting the value of prop. 20 one or two steps lower than the default above, otherwise it's probably a good idea to leave it at the default.

== Shorter train vehicles (21) ==

This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly
<ref>{{ottdp|1.0|no|ottdrev=r15793}} This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.</ref>,
except at the end of the train
<ref>{{ottdp|<1.0|}} This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.</ref>. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).

<references/>

== Visual effects and wagon power (22) ==

By default, the visual effect of train engines is determined by the traction type (property 19). With this option you can change the type of effect as well as the position of it relative to the vehicle. (Note: for TTDPatch and OpenTTD up to r21229 only the positioning of steam actually works. For {{ottdp|1.1|no|ottdrev=r21230}} positioning diesel smoke and electric sparks works as well) The position of the effect provides a range from 0 to F that is added to the type of the effect.

Position 0 corresponds to a point half a vehicle length ahead of the vehicle, 4 is the front of the vehicle, 8 the middle, C the end and F is a half length behind the vehicle. Intermediate values are in-between.

Additionally, this property can be used to disable powered wagons of this type, although that is usually done with [[Callbacks#Visual_effect_and_wagon_power_.2810.29| callback 10]] instead (which has the same meaning as prop. 22, but is more flexible).

{| |-
!Range !!Effect type
|-
|00..0F||Use the default effect type, but reposition it. For engines this is defined via property 19, wagons have no default effect.
|-
|10..1F||Steam puffs
|-
|20..2F||Diesel fumes
|-
|30..3F||Electric sparks
|-
|40||Disable visual effect
|-
|41..7F||{{ottdp|1.5|no|ottdrev=r26747}} Create effects with [[Callbacks#Advanced_effect_creation_.28160.29|Callback 160]] using one of these spawning models:
* 41 Steam: Gradually less effects when approaching max speed
* 42 Diesel: Effect proportional to acceleration, no effect when idling at top speed
* 43 Electric: Random effect, gradually less likely when approaching max spped
* 44-7F Reserved
|-
|80+00..80+7F||Same as 00..7F above, but disable wagon power
|}

For example, 28 would make the wagon powered and emit diesel fumes, but 80+28 = A8 would only emit the diesel fumes without adding power.

== Miscellaneous flags (27) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|0.6|2.5}}|| Vehicle tilts in curves, and thus gets speed bonus <ref>The tilting speed bonus only applies if all vehicles in the train have this bit set. In TTDPatch it requires the "curves" switch to be on. For realistic curves, it gives the train two free curving pieces with no speed decrease, and for other settings, it increases the curves setting by one (0->1, 1->2, 2->2). In OpenTTD, the curve speed limit increases by 20% if 'realistic' acceleration is enabled, else there is no effect.
</ref>
|-
|1|| 2||{{ottdp|0.6|2.5}}|| Uses two company colors
|-
|2|| 4||{{ottdp|0.6|2.5}}|| Vehicle is a multiple unit (DMU/EMU), for colour selection
|-
|3|| 8||Varies|| {{ottdp|1.1|no|ottdrev=r21966}}Vehicle can be flipped around in the depot. <br>{{ottdp|13|no|no}}This flag is no longer required, vehicles can always be flipped.
<ref>From {{ottd|13|no}} onwards, OpenTTD will again allow all vehicles to flip, and will automatically adjust offsets accordingly. From {{ottd|13|no}}, if this flag is set, OpenTTD will not automatically apply the correct offsets for vehicles < 8/8 long, and will defer to offsets set by the grf. Do not set this flag unless you need it for a specific reason.
<br>
For {{ottd|1.1|r21966}} up to {{ottdp|12|no|no}} when you enable flipping of a vehicle in a depot you must make sure that the graphics are correctly aligned when flipped as well. Especially in the case of shortened vehicles.
<br>
Prior to {{ottd|1.1|r21966}} all non-multiheaded/non-articulated vehicles would be able to flip around in the depot. As such {{ottd|1.1|r21966}} disables a "feature" in OpenTTD, but often it makes no sense to flip vehicles around (symetric vehicles) or the graphics are wrong (most shortened vehicles), and thus only enabling this when the NewGRF developer says it is possible is better.
<br>
For all relevant OpenTTD versions, the flipping bit has no effect for multiheaded or articulated vehicles as they cannot be flipped in depot.
</ref>
|-
|4|| 10||{{ottdp|1.2|no|ottdrev=r23087}}|| Auto-refitting is enabled for refits where callback 15E allows it or prop 1C specifies zero cost
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}}|| Use cargo multiplier for default cargo (and load amount). See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}}|| Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}}|| [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

<references />

== Cargo classes (28, 29) ==

To make vehicle sets more compatible with future new cargo definitions, these two properties allow vehicles to define what type of cargo they should be refittable to. A wagon will be refittable to all cargo types that match any of the classes set in prop. 28 except for the ones that match any of the classes set in prop. 29. In addition, afterwards those cargo types listed in prop. 1D will be toggled. In terms of logic, it is

Refit list = (cargos from prop. 28 AND NOT cargos from prop. 29) XOR cargos from prop. 1D

This means, if a cargo type is in the list because it matches prop. 28 but not prop 29, having the respective bit set in prop. 1D will disable it again. Conversely, if the cargo type is not in the list, the bit in prop. 1D will add it. This way, if props. 28/29 are unset, prop. 1D will retain the original meaning, but it is still able to selectively add or remove certain cargo types even if props. 28/29 are used.

As a consequence, you have both full control over the cargo types that you know of (using prop. 1D), and those you don't know of yet (using props. 28/29). Leave the bits for cargos that you don't know of unset in prop. 1D, and set/clear the bits for known cargos to add/remove them from the list as appropriate.

{{ottd|1.2|r23291}} It is recommended to use properties 2C and 2D instead of property 1D, as property 1D behaves badly if the cargo classes of a cargo are ever changed.

The class list is a bit mask. See the action0 cargos page for bits and classes defined so far.

Take a look at [[Action0Cargos#Cargo classes 16|Action0 for cargos]] for the classes defined so far.

Note that cargo types may belong to several classes. This is the reason for making two properties, an additive and a subtractive one, because this way a vehicle can be specified to be refittable to, for example, all express cargo that does not require refrigeration (i.e., from the default cargos, no food).
For the cargo types added in this way, the vehicle will probably have no specific graphics (in [[Action3|action 3]]) to show the cargo load.  In this case, the default will be used, which should therefore be sufficiently generic-looking if possible. However, using [[VariationalAction2/Vehicles#Vehicle cargo info 47|vehicle variable 47]] you can at least select the graphics most appropriate for the cargo type's class.
About the interaction with other properties take a look at the summary page about [[VehicleRefitting|vehicle refitting]].

Disclaimer: there is no guarantee that classes won't vary over time or between sets. The classes of a cargo may change between different versions of a specific industry/cargo newgrf, or different classes may be set for the same cargo label by different industry/cargo newgrfs. Feel free to use classes in your set for conveniently refitting to cargos, but if you - the vehicle author - care about specific cargos being transported in specific vehicles, use label based refits (changing labels without a very good reason is considered to be bad practice).

== Long format introduction date (2A) ==

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

== Custom cargo ageing period (2B) ==

This property allows to modify the period in ticks after which cargo carried by the vehicle is aged. By default, cargo is aged every 185 ticks. A value of 0 disables ageing of cargo. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

Changing this value from the default does not automatically make the vehicle earn more or less. Predicting the effect is complicated, as it depends on many things, including: vehicle speed, route length, route delays, transfer credits, the payment curve set by the cargo, and whether the cargo is already aged from a previous transfer when the vehicle loads it.

Authors are advised that tests show this property can lead to disappointment. Avoid, or use with caution.

== List of always refittable cargo types (2C, 2D) ==

These two properties allows to unconditionally include or exclude cargo types for refittability independent of any of the other refit properties or the cargo classes. If you specify a cargo type that is not available, the cargo type will be silently ignored.

The format for both properties is:

<pre>2C/2D <nvar> (<Index into cargo type table>){n}</pre>

That is you give the number of cargos in a single byte followed by a list of that length of indexes into the cargo translation table ([[CargoTypes|Type A]]).

== Maximum curve speed modifier (2E) ==

This property allows to give vehicles a maximum curve speed modifier. The given value is treated as a signed word with 8 fractional bits. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

The modifier is applied after the normal curve speed calculation is done using the formula max_curve_speed * (1 + prop 2E). This means that the default property value of 0 is equivalent to no change. While values less than -1.0 are technically possible, the resulting vehicle curve speed is clamped at 2 mph-ish to make sure vehicles don't become permanently stuck.

If different vehicles in a train have different curve speed modifiers, the lowest value wins.

== Vehicle variant group (2F) ==

This property supports grouping vehicles in the purchase menu (also the autoreplace menu). The property value is the ID of another vehicle in the same GRF which will act as the parent for vehicles in the group.

Groups can also be nested (this is experimental as of December 2022 and may change with testing).

See also [[Action0Trains#Extra flags (30)|vehicle extra flags]] which can influence the behaviour of vehicles in variant groups.

See also https://github.com/OpenTTD/OpenTTD/pull/10220

== Extra flags (30) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|13|no}}|| Disable "New Vehicle" news message for this engine
|-
|1|| 2||{{ottdp|13|no}}|| Disable "Exclusive Preview" for this engine
|-
|2|| 4||{{ottdp|13|no}}|| Variants - Include this variant when primary engine has "Exclusive Preview"
|-
|3|| 8||{{ottdp|13|no}}|| Variants - (Attempt to) Synchronize reliability the primary engine
|-
|}

= Example =

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

(A basic version)

<pre>10 * 14  00 00 03 01 02 09 C0 00 0B D8 0E 12 FD</pre>

{| |-
!'''Bytes'''!!'''Meaning'''
|-
|10||<Sprite-number>
|-
|14||<Length>: of the action in bytes; start counting at 0 (<action>)
|-
|00||<action>: sets this pseudo-sprite to function as action 0
|-
|00||<Feature>: In this case Train
|-
|03||<Num-props>: 3 Properties to change
|-
|01||<Num-info>: 1 vehicle ID to make changes to
|-
|02||<ids...>: vehcile ID (02 - Ploddyphut Choo-Choo)
|-
|||'''Properties'''
|-
|09||<Speed>
|-
|C0 00||<Value>: Value for Speed (192 Km/h)
|-
|0B||<Power>
|-
|D8 0E||<value>: value for Power (3800 HP)
|-
|12||<Sprite ID>
|-
|FD||<value>: FD for new graphics
|}
Since nfo version 7, so-called [[GRFActionsDetailed#Byte order|"escape sequences"]] have been introduced in an attempt to offer a more human-readable form.

Below is the same example as above, with escape sequences being used:

<pre>-1 * 0 00 00 \b3 01 \b*2 // \b<number of props to change> \b*<vehicle ID>

       09 \w192 // value for speed (192 Km/h)

       0B \w3800 // value for power (3800 hp)

       12 FD // use new graphics</pre>

Action0/Vehicles/RoadVehicles

2023-01-30T22:04:23Z

Michi cc: Engine name CB.

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of road vehicles.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|1.10|no}}||Roadtype / tramtype (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||Speed in mph*3.2||no
|-
|09||B||{{ottdp|0.6|2.0}}||Running cost factor||should be zero
|-
|0A||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|0E||B||{{ottdp|0.6|2.0}}||Sprite ID (FF for new graphics)||yes
|-
|0F||B||{{ottdp|0.6|2.0}}||Capacity||yes
|-
|10||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'
||yes
|-
|11||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect: 17/19/1A for regular, 3C/3E for toyland<br/>{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.||no
|-
|13||B||{{ottdp|1.1|2.0}} {{grfFrom|2}}||Power in 10 hp, see below||should be zero
|-
|14||B||{{ottdp|1.1|2.0}} {{grfFrom|2}}||Weight in 1/4 tons, see below||should be zero
|-
|15||B||{{ottdp|0.7|2.0}} {{grfFrom|2}}||Speed in mph*0.8, see below||no
|-
|16||D||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Bit mask of cargo types available for refitting (not refittable if 0 or unset), see column 2 (bit values) in [[CargoTypes]]||yes
|-
|17||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|18||B||{{ottdp|1.1|2.5|ttdprev=alpha 30}}||Coefficient of tractive effort||should be zero
|-
|19||B||{{ottdp|1.1|2.5|ttdprev=alpha 30}}||Coefficient of air drag||should be zero
|-
|1A||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1B||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|1C||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags||partly ("tram" should be same as front)
|-
|1D||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]||yes
|-
|1E||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]||yes
|-
|1F||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date||no
|-
|20||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list||no
|-
|21||B||{{ottdp|1.1|no|ottdrev=r21240}}||Visual effect||yes
|-
|22||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|23||B||{{ottdp|1.2|no|ottdrev=r23164}}||Make vehicle shorter, see [[Action0/Vehicles/Trains#Shorter_train_vehicles_.2821.29|train property 21]]||yes
|-
|24||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]||yes
|-
|25||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]||yes
|-
|26||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|27||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|28||B||{{ottd|14|ottdrev=gf5394ed2ef}}||Additional callback flags bit mask, see below||yes
|}

== Description ==

=== Roadtype or tramtype (05) ===
{{ottdp|1.10|no}} Roadtype or tramtype for the vehicle. This is an index into the [[Action0/Global_Settings#Roadtype_translation_table_.2816.29|roadtype]] or [[Action0/Global_Settings#Tramtype_translation_table_.2817.29|tramtype]] translation table.

This property:
* will use property 1C bit 0 (flag 'vehicle is tram') to determine whether to use a roadtype or tramtype table
* requires an appropriate roadtype or tramtype table to be loaded

=== Running cost base (0A) and factor (09) ===

TTD calculates all costs by multiplying a 48-bit base amount with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of road vehicles, the following base amounts are available:

{| |-
!Type!!Value!!in little-endian notation
|-
|Road vehicle running cost base||4C48||48 4C 00 00
|}

Theoretically, you could use pointers to other [[BaseCosts|base amounts]] available in TTD, but these are the numbers TTD uses for road vehicles.

=== Cost factor (11) ===

The cost factor is a bit-coded value which determines how expensive a vehicle is. The table below gives you some values to use for finding the right price for your vehicles.

{| |-
!Cost factor!!Price
|-
|00||$ 0
|-
|01||$ 108
|-
|10||$ 1,750
|-
|20||$ 3,500
|-
|80||$ 14,000
|-
|FF||$ 27,890
|}

=== Realistic acceleration properties (13, 14, 15) ===

Using property 15 to set the speed, it is possible to achieve speeds larger than 80 mph (127 km/h), to which property 08 is limited. When setting property 15, always set property 08 as well, so that the vehicle works reasonably well whether realistic acceleration is turned on or off. If property 15 is not set, the value from property 08 is used instead.

{{ttdp|}} TTDPatch uses these properties only if road vehicles are set to realistic acceleration in the NewCurveAndMountainHandling switch. They are ignored otherwise.

{{ottd|}} OpenTTD uses these properties always, if they are defined and gives the speed defined here precedence over the one defined in property 08.

=== Callbacks (17, 28) ===

For road vehicles, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 17 and 28 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated vehicle
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Coefficient of tractive effort (18) ===

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

For a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on.  If not set, a default of 4C is used, for a fraction of 0.30, corresponding to W<sub>adh</sub>=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

=== Coefficient of air drag (19) ===

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units.  00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!!<16!!16!!24!!32!!48!!64!!96!!128!!192!!256!!...
|-
|c2||192||128||96||64||48||32||24||16||12||8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTd's consistent scaling.  If a vehicle doesn't reach its historical top speed, you might try setting prop. 19 one or two higher than the default above, otherwise it's probably a good idea to leave it at the default.

=== Refit cost (1A) ===

Refit cost, using 25% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (1C) is set, auto-refitting is allowed.

=== Miscellaneous flags (1C) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||Vehicle is a tram/light rail vehicle and requires tram tracks to operate
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 1A specifies zero cost.
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

=== Long format introduction date (1F) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (20) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Visual effect (21) ===
See the equivalent [[Action0Trains#Visual effects and wagon power 22|train property]] for information about the meaning of all bits. There is no default effect for road vehicles, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.

=== Custom cargo ageing period (22) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Ships

2023-01-30T22:03:35Z

Michi cc: Engine name CB

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of ships.
== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Refittable (0 no, 1 yes)
|-
|0A||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0B||B||{{ottdp|0.6|2.0}}||Speed in mph*3.2
|-
|0C||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'
|-
|0D||W||{{ottdp|0.6|2.0}}||Capacity
|-
|0F||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|10||B||{{ottdp|0.6|2.0}}||Sound effect type (4=cargo ship, 5=passenger ship)<br/>{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.
|-
|11||D||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Bit mask of cargo types available for refitting, see column 2 (bit values) in [[CargoTypes]]
|-
|12||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|13||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|14||B||{{ottdp|1.2|2.5|ttdprev=alpha 44|ottdrev=r22639}}||Ocean speed fraction, sets fraction of top speed available in the ocean; e.g. 00=100%, 80=50%, FF=0.4%
|-
|15||B||{{ottdp|1.2|2.5|ttdprev=alpha 44|ottdrev=r22639}}||Canal speed fraction, same as above but for canals and rivers
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Refittable cargo classes, see [[Action0Trains#Cargo_classes_.2828.2C_29.29|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 55}}||Non-refittable cargo classes, see [[Action0Trains#Cargo_classes_.2828.2C_29.29|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.6|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||B||{{ottdp|1.1|no|ottdrev=r21240}}||Visual effect
|-
|1D||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1F||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottd|14|ottdrev=gf5394ed2ef}}||Additional callback flags bit mask, see below
|}

== Descriptions ==

=== Callbacks (12, 22) ===
For ships, the following [[callbacks]] have to be enabled by setting the corresponding bit in properties 12 and 22 (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (13) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 13 specifies zero cost.
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort_vehicle_list_.281A.29|trains]] for details.

=== Visual effect (1C) ===
See the equivalent [[Action0Trains#Visual_effects_and_wagon_power_.2822.29|train property]] for information about the meaning of all bits. There is no default effect for ships, therefore values of 00..0F will show no visual effect. Bit 7 (disable wagon power) currently has no meaning and should be left at 0.

=== Custom cargo ageing period (1D) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Planes

2023-01-30T22:02:30Z

Michi cc: /* Properties */

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of planes.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Is helicopter? 2=no, 0=yes
|-
|0A||B||{{ottdp|0.6|2.0}}||Is large? 0=no, 1=yes (i.e. can't safely land on small airports)
|-
|0B||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0C||B||{{ottdp|0.6|2.0}}||Speed in units of 8 mph, that is: property = (speed in mph) / 8
|-
|0D||B||{{ottdp|0.6|2.0}}||Acceleration in units of 3/8 mph/tick, that is: property = (acceleration in mph/tick) * 8/3 <ref>{{ottd|<1.3.1}} In OpenTTD before r25115 the units for acceleration were messed up. The unit used was about 1 mph/tick, so aircraft accelerated more than twice as fast. Also values bigger than 19 failed.</ref>
|-
|0E||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|0F||W||{{ottdp|0.6|2.0}}||Primary cargo capacity (passenger or refitted cargo)
|-
|11||B||{{ottdp|0.6|2.0}}||Secondary cargo capacity (mail)
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect
|-
|13||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (Bit Value) in [[CargoTypes]]
|-
|14||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|15||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|1F||W||{{ottdp|1.2|no|ottdrev=r23504}}||Aircraft range in tiles. Distance is euclidean, a value of 0 means range is unlimited
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottd|14|ottdrev=gf5394ed2ef}}||Additional callback flags bit mask, see below
|}
<references/>

== Descriptions ==

=== Primary (0F) and secondary (11) cargo capacity ===
Aircraft can transport up to two cargo types.
The first (primary) cargo type can be changed when refitting the aircraft.

The secondary cargo type is always mail, and is only present when the primary cargo type is part of the [[Action0/Cargos#CargoClasses_.2816.29|passenger cargo class]].

See also the page about [[VehicleRefitting|vehicle refitting]].

=== Sound effect (12) ===

The following sound effects are used by planes (note, the setting is ignored for helicopters):

{| |-
!Number!!Sound
|-
|06||Propeller sound 1
|-
|07||Jet sound 1
|-
|3B||Supersonic
|-
|3D||Jet sound 2
|-
|45||Propeller sound 2
|-
|46||Jet sound 3
|}

{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.

{{ottdp|1.11|no|ottdrev=6198a47}} Since OpenTTD g6198a47 this prop can be used to to set custom Action11 sound effects for helicopers. Default sound effects are ignored as before.

=== Callbacks (14, 22) ===
For planes, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 14 (certain other, not as frequently used callbacks are available without setting a bit here)::

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (15) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 15 specifies zero cost.
|-
|5||20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6||40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
Note: This also applies to the rotor sprite, if custom rotor sprites are used.
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Custom cargo ageing period (1C) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Vehicles/Planes

2023-01-30T22:01:58Z

Michi cc:

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of planes.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Is helicopter? 2=no, 0=yes
|-
|0A||B||{{ottdp|0.6|2.0}}||Is large? 0=no, 1=yes (i.e. can't safely land on small airports)
|-
|0B||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0C||B||{{ottdp|0.6|2.0}}||Speed in units of 8 mph, that is: property = (speed in mph) / 8
|-
|0D||B||{{ottdp|0.6|2.0}}||Acceleration in units of 3/8 mph/tick, that is: property = (acceleration in mph/tick) * 8/3 <ref>{{ottd|<1.3.1}} In OpenTTD before r25115 the units for acceleration were messed up. The unit used was about 1 mph/tick, so aircraft accelerated more than twice as fast. Also values bigger than 19 failed.</ref>
|-
|0E||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|0F||W||{{ottdp|0.6|2.0}}||Primary cargo capacity (passenger or refitted cargo)
|-
|11||B||{{ottdp|0.6|2.0}}||Secondary cargo capacity (mail)
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect
|-
|13||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (Bit Value) in [[CargoTypes]]
|-
|14||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|15||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|1F||W||{{ottdp|1.2|no|ottdrev=r23504}}||Aircraft range in tiles. Distance is euclidean, a value of 0 means range is unlimited
|-
|20||W||{{ottdp|13|no}}||Vehicle variant group, see [[Action0/Vehicles/Trains#Vehicle_variant_group_.282F.29|train property 2F]]
|-
|21||D||{{ottdp|13|no}}||Extra flags, see [[Action0/Vehicles/Trains#Extra_flags_.2830.29|train property 30]]
|-
|22||B||{{ottd|14|ottdrev=gf5394ed2ef}}||Additional callback flags bit mask, see below||yes
|}
<references/>

== Descriptions ==

=== Primary (0F) and secondary (11) cargo capacity ===
Aircraft can transport up to two cargo types.
The first (primary) cargo type can be changed when refitting the aircraft.

The secondary cargo type is always mail, and is only present when the primary cargo type is part of the [[Action0/Cargos#CargoClasses_.2816.29|passenger cargo class]].

See also the page about [[VehicleRefitting|vehicle refitting]].

=== Sound effect (12) ===

The following sound effects are used by planes (note, the setting is ignored for helicopters):

{| |-
!Number!!Sound
|-
|06||Propeller sound 1
|-
|07||Jet sound 1
|-
|3B||Supersonic
|-
|3D||Jet sound 2
|-
|45||Propeller sound 2
|-
|46||Jet sound 3
|}

{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.

{{ottdp|1.11|no|ottdrev=6198a47}} Since OpenTTD g6198a47 this prop can be used to to set custom Action11 sound effects for helicopers. Default sound effects are ignored as before.

=== Callbacks (14, 22) ===
For planes, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 14 (certain other, not as frequently used callbacks are available without setting a bit here)::

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|-
|8||100||161||{{ottd|14|ottdrev=gf5394ed2ef}}Engine name
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (15) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 15 specifies zero cost.
|-
|5||20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6||40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
Note: This also applies to the rotor sprite, if custom rotor sprites are used.
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Custom cargo ageing period (1C) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

TextIDs

2023-01-30T21:58:33Z

Michi cc: Extended DCxx text area.

{{ottdp|no|2.0}} This is a list of the text IDs in TTD (for action 4), originally compiled by A. Skrobov.

You can use these Text IDs
* to change/translate TTD strings using action4 feature 48. (This is not supported by OpenTTD, nor will it ever.)
* to reference them in various action 0 properties, e.g. for house/industry/cargo names. (This is partly supported by OpenTTD.)

Note: OpenTTD's string system is very different to the system of TTD and TTDPatch. It supports/requires plural forms, genders, cases and different number formattings, so complex strings which are combined from multiple parts are not interchangeable. Various strings also have changed their parameter order over time or got additional arguments.

As such action 4 is not allowed to change any original strings in OpenTTD; translations are not done via NewGRF, but only via the [http://translator.openttd.org/ WebTranslator].

In action 0 only a subset of the original strings can be accessed. These are more or less the string which have no additional parameters, e.g. plain cargo/house/industry names.

=0000 General strings=
[[TextIDs/General_strings | General strings 0000-07FF]]

=0800 Basic land strings=
[[TextIDs/Basic_land_strings | Basic land strings 0800 - 0FFF]]

=1000 Railroad strings=
[[TextIDs/Railroad strings | Railroad strings 1000 - 17FF]]

=1800 Road strings=
[[TextIDs/Road strings | Road strings 1800 - 1FFF]]

=2000 Town strings=
[[TextIDs/Town strings | Town strings 2000 - 27FF]]

=2800 Tree strings=
[[TextIDs/Tree strings | Tree strings 2800 - 2FFF]]

=3000 Station strings=
[[TextIDs/Station strings | Station strings 3000 - 37FF]]

=3800 Water strings=
[[TextIDs/Water strings | Water strings 3800 - 3FFF]]

=4000 Load/save strings=
[[TextIDs/Load, save strings | Load, save strings 4000 - 47FF]]

=4800 Industry strings=
[[TextIDs/Industry strings | Industry strings 4800 - 4FFF]]

=5000 Tunnel and bridge strings=
[[TextIDs/Tunnel and bridge strings | Tunnel and bridge strings 5000-57FF]]

=5800 Object strings=
[[TextIDs/Object strings | Object strings 5800 - 5FFF]]

=6000 Debugger strings=
[[TextIDs/Debugger strings | Debugger strings 6000 - 67FF]]

=6800 Difficulty strings=
[[TextIDs/Difficulty strings | Difficulty strings 6800 - 6FFF]]

=7000 Company strings=
[[TextIDs/Company strings | Company strings 7000 - 77FF]]

=7800 Custom strings=
These cannot be set directly; an entry is generated every time the player enters a custom name for example for signs, stations or vehicles.

=8000 Vehicle type names=
[[TextIDs/Vehicle type names | Vehicle type names 8000 - 87FF]]

Note, IDs 8000..80FF will be changed by using a regular action 4 to name new vehicles, but not by using "custom vehicle names" from vehicle.dat which use custom strings instead.

=8800 Train strings=
[[TextIDs/Train strings | Train strings 8800 - 8FFF]]

=9000 Road vehicle strings=
[[TextIDs/Road vehicle strings | Road vehicle strings 9000 - 97FF]]

=9800 Ship strings=
[[TextIDs/Ship strings | Ship strings 9800 - 9FFF]]

=A000 Aircraft strings=
[[TextIDs/Aircraft strings | Aircraft strings A000 - A7FF]]

=A800 Pseudo-vehicle strings=
(None defined)

=B000 Disaster strings=
[[TextIDs/Disaster strings | Disaster strings B800 - BFFF]]

=B800 unused=

=C000 New station names=
This is used for TTDPatch newgrf station and class names. See action 4 for more details.

=C800 New house names=
This is used for TTDPatch newgrf town building names. See action 4 for more details.

=D000 Miscellaneous GRF texts=
This is used for TTDPatch newgrf miscellaneous texts, mostly for callbacks. See action 4 for more details.

The table has up to 1024 entries. To use entry X in an include text (codes 80/81), use ID D400+X. Note that if you want to include ID D000/D400, the 00 byte will be considered the end of string in action 4, this will therefore break if additional texts are supposed to follow in the action 4.

=D800 Persistent GRF texts=
This is used for TTDPatch newgrf persistent texts (the ID mappings are preserved through saving and loading even if the GRF file is unavailable). See action 4 for more details.

D800 class IDs (DCxx IDs) must not be used except in action 0 and where the spec explicitly says that they work.

{{ottd|14|ottdrev=gf5394ed2ef}} This textid area extends up to ID FFFF.

=E000 Hard-coded game texts=
[[TextIDs/Hard-coded game texts | Hard-coded game texts E000 - E7FF]]

This text class exists only in TTDPatch 2.0.1 alpha 59 and later. It contains language-dependent texts that didn't have textIDs originally. This class allows translating TTD entirely by using action 4s, since now every language-dependent text can be accessed.

{{ottd|14|ottdrev=gf5394ed2ef}} Continuation of D800 texts.

=E800 News texts=
This is used internally by TTDPatch for its additional news messages.

{{ottd|14|ottdrev=gf5394ed2ef}} Continuation of D800 texts.

=F000 unused=
(Unused, but TTD's critical error messages internally have a number in this region, even though they aren't text IDs as such.)

{{ottd|14|ottdrev=gf5394ed2ef}} Continuation of D800 texts.

=F800 Internal TTDPatch texts=
[[TextIDs/Internal TTDPatch strings | Internal TTDPatch texts F800 - FFFF]]

This is used internally by TTDPatch for its additional regular strings, i.e. those from ttdpttxt.txt. Since TTDPatch 2.0.1 alpha 59 you may use the following text IDs to change the respective patch strings (before alpha 59, the text IDs changed regularly). For default values, please see ttdpttxt.txt produced by mkpttxt.exe.

{{ottd|14|ottdrev=gf5394ed2ef}} Continuation of D800 texts.

TTDPatchFlags

2023-01-30T21:56:31Z

Michi cc: DCxx test area

In the table below you find all the TTDPatch flags that belong to <param-num> = 85 in Action 7 and Action 9.

{| |-
!'''Bit'''!!'''Switch (bit set = switch on)'''!!'''Correspondence in OpenTTD'''
|-
|0C||keepsmallairport||station.never_expire_airports
|-
|0D||newairports||1
|-
|0E||largestations||1
|-
|0F||longbridges||construction.longbridges
|-
|10||loadtime||0
|-
|12||presignals||1
|-
|13||extpresignals||1
|-
|16||enginespersist||vehicles.never_expire_vehicles
|-
|1B||multihead||1
|-
|1D||lowmemory||1
|-
|1E||generalfixes||1
|-
|27||moreairports||economy.station_noise_level
|-
|28||mammothtrains||1
|-
|29||trainrefit||1
|-
|2B||subsidiaries||0
|-
|2C||gradualloading||order.gradual_loading
|-
|32||(Set to bit 0 of unifiedmaglev mode)||1 (n/a)
|-
|33||(Set to bit 1 of unifiedmaglev mode)||1 (n/a)
|-
|34||bridgespeedlimits||1
|-
|36||eternalgame||1
|-
|37||newtrains||1
|-
|38||newrvs||1
|-
|39||newships||1
|-
|3A||newplanes||1
|-
|3B||signalsontrafficside||construction.signal_side
|-
|3C||electrifiedrailway||vehicle.disable_elrails
|-
|41 <ref>loadallgraphics is obsolete (and its bit unused) since revision 401. The next official versions were the 5/Jun/2006 nightly (402) and TTDPatch 2.5 beta 6 (472)</ref>||loadallgraphics||1
|-
|43||semaphores||1
|-
|4A||newobjects (since r2364)||1
|-
|4B||enhancegui||0
|-
|4C||newagerating||0
|-
|4D||buildonslopes||construction.build_on_slopes
|-
|4E||fullloadany||1
|-
|4F||planespeed||1
|-
|50 <ref>moreindustriesperclimate is obsolete (and its bit unused) since TTDPatch 2.5 beta 2.</ref>||moreindustriesperclimate||0
|-
|51||moretoylandfeatures||0
|-
|52||newstations||1
|-
|53||tracktypecostdiff||1
|-
|54||manualconvert||1
|-
|55||buildoncoasts||construction.build_on_slopes
|-
|56||canals||1
|-
|57||newstartyear||1
|-
|58||freighttrains||vehicle.freight_trains > 1
|-
|59||newhouses||1
|-
|5A||newbridges||1
|-
|5B||newtownnames||1
|-
|5C||moreanimation||1
|-
|5D||wagonspeedlimits||vehicle.wagon_speed_limits
|-
|5E||newshistory||1
|-
|5F||custombridgeheads||0
|-
|60||newcargodistribution||0
|-
|61||windowsnap||1
|-
|62||townbuildnoroads||not (economy.allow_town_roads or _generating_world)
|-
|63||pathbasedsignalling||1
|-
|64||aichoosechances||0
|-
|65||resolutionwidth||1
|-
|66||resolutionheight||1
|-
|67||newindustries||1
|-
|68||fifoloading||order.improved_load
|-
|69||townroadbranchprob||0
|-
|6A||tempsnowline||0
|-
|6B||newcargos||1
|-
|6C||enhancemultiplayer||1
|-
|6D||onewayroads||1
|-
|6E||irregularstations||1
|-
|6F||morestatistics||1
|-
|70||newsounds||1
|-
|71||autoreplace||1
|-
|72||autoslope||1
|-
|73||followvehicle||0
|-
|74||trams||1
|-
|75||enhancetunnels||0
|-
|76||shortrvs||1
|-
|77||articulatedrvs||1
|-
|78||dynamicengines||{{ottd|0.7|r12924}} vehicle.dynamic_engines
|-
|7E||variablerunningcosts (since r1421)||1
|-
|7F||set if any switches are on||1
|-
|80||-||{{ottd|1.9|g4b0b4e064}} 1 (larger persistent storage)
|-
|81||-||{{ottd|1.11|g1478fa93b}} economy.inflation
|-
|82||-||{{ottd|14|ottdrev=gf5394ed2ef}} 1 (Extended DCxx text area)
|}

<references />

Action4

2023-01-30T21:54:19Z

Michi cc: /* offset */

==Introduction==
Define strings, e.g vehicle, house or industry names

When making new vehicle graphics, you also need to name the new vehicles, or they'll show up with their original name from TTD.
However, custom vehicle names assigned by the player in-game (or for TTDPatch also via TTD's vehicle.dat) will always take precendence.

In TTDPatch you can also use this action to change most of TTD's text strings.

== Syntax ==

The data looks as follows:

<Sprite-number> * <Length> '''04''' <feature> <language-id> <num-ent> <offset> <text>

{| |-
!Element!![[GRFActionsDetailed|Size]]!!Description
|-
|<Sprite-number>||dec||A sequential sprite number
|-
|<length>||dec||The total number of bytes used in this action.
|-
|04||B||Defines action 04
|-
|<feature>||B||For what type of vehicle/station should this definition be used?
|-
|<language-id>||B||Which of TTD's languages this name is for
|-
|<num-ent>||B||Number of consecutive strings to change
|-
|<offset>||B/W||First ID to change
|-
|<text>||S||New text strings
|}

Whether <offset> is a '''BYTE''' (extended byte in openttd for vehicles) or a '''WORD''' is decided by bit 7 of <language-id>, see below.

== Descriptions ==

=== Sprite-number ===

This is just the number you are at.

=== Length ===

Count the number of bytes in this action.

=== Feature ===

This sets the type of [[Features|feature]] that you wish to change. Set it to:

{|- |
!Value!![[Features|Feature]]
|-
|00||Trains
|-
|01||Road Vehicles
|-
|02||Ships
|-
|03||Aircraft
|-
|04||Stations
|-
|07||Houses
|-
|0A||Industries
|-
|0B||Cargos
|-
|0D||Airports
|-
|0F||Objects
|-
|10||Railtypes
|-
|12||Roadtypes
|-
|13||Tramtypes
|-
|48||Original strings; see [[TextIDs]] for a list of TTD's text IDs.
|}

=== language IDs ===
The meaning of this byte depends on the GRF version of the .grf file as set in [[Action8#version|action 8]].

{{grfTill|6}} Up to version 6, this is a bit mask of the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||01||American or "other"
|-
|1||02||English
|-
|2||04||German
|-
|3||08||French
|-
|4||10||Spanish
|-
|7||80||Flag for 16 bit string IDs
|}

Add the bits of all languages for which the following strings apply. Bit 7 controls, whether the following string ID consists of 16 or 8 bit. Unknown languages will use the American strings as fallback. Otherwise the string would remain undefined for these languages. To actually define strings for any new language, you must use grf version 7.

{{grfFrom|7}} For version 7 and higher, it is a simple language ID from the list below. (This has changed with TTDPatch 2.5 beta 4). Bit 7 has the same meaning as in the earlier versions above.

In either scheme, you can use the value 7F or FF, respectively, to define strings shown for languages that you do not provide translation for. First set all strings to a default value using this, and later override the language specific ones if they exist.

Set bit7 (add 0x80 to the languageID as in the table below) in order to use 16 bit string IDs.

For a list of plural forms see [[StringCodes]]. As the assignment of plural forms to languages is in fact not as fixed as one might expect, the used plural form is defined by each GRF separately for its strings using [[Action0/Global Settings]] property 15.

{{:language_IDs}}

When translating for a new language, please simply edit the [[language_IDs|language list]] and add the new definition here.

=== num-ent ===

How many consecutive entries to change.

=== offset ===

The ID of the first string to change.

When language-id bit 7 is clear, this is a byte value; For OpenTTD since r13482, where it is an extended byte value for vehicles.

When language-id bit 7 is set, this is a word value in little endian notation, e.g. 8134 becomes 34 81.

The 8 bit version is only allowed for vehicles to set their name, in which case the text ID is just the vehicle ID.
To replace original texts, or to define texts for usage in callbacks or properties of vehicles, stations, houses or industries you have to use the 16 bit version. However, town names are changed with [[ActionF|Action F]].

For the usable 16 bit text IDs see the table below, resp. for feature 48 see [[TextIDs]].

Though these ranges are shared across all features, you should still set the proper feature you are using them for.

{| |-
!ID!!Content
|-
|C4xx||Set name of station class associated with station ID xx; this is the text above the preview (where otherwise TTD shows "Orientation")
|-
|C5xx||New station names, this changes the text "number of platforms" into the given text when the station with this ID from the current set is selected (i.e. xx=station-id from action 3 and 0)
|-
|C9xx||Name of the house type of this ID. If both property 12 and this is set, the latest definition is used always. You should prefer setting [[Action0/Houses#Building name ID (12)|property 12]] instead of this, so executables translated with TTD Translator will show the name in the current language. However, if you can't find any suitable old TTD texts, this can be used to specify your custom name. Don't forget to set the same text for all parts of a multi-tile building.
|-
|D0xx||Miscellaneous graphics texts, unique to each .grf file. Used for several callbacks. Some callbacks support IDs up to D3FF.
|-
|D4xx||'''Never use in Action4''', only for displaying textids in range D000-D3FF (grf specific), see [[TextIDs]]
|-
|D8xx
|{{ottd|1.7|rev=r27769}} Useable like DCxx in Action 0 and for inclusion via string codes 0x80 and 0x81.
{{ttdp|}}'''Never use in Action4''', only usable in Action0 features, see [[TextIDs]]
|-
|DCxx||Set miscellaneous persistent GRF texts. Useable in Action 0 and for inclusion via string codes 0x80 and 0x81.
{{ottd|14|ottdrev=gf5394ed2ef}} This area extends up to textid FFFF.

{{ttdp|}} Unlike the D0xx GRF texts, these IDs can be used to set properties. The text ID must be set before any [[Action0/Houses|action 0]] references it.
|}

{{ttdp|}} The DCxx IDs are allocated internally when defined, and are persistent in the savegame data. Each .grf file gets its own separate map of these internal IDs and thus may set all 256 of them.  However, only 1024 IDs are available in total, to be shared by all .grf files ever activated in the savegame. This means these IDs should be used as sparingly as possible. But use them when they are useful!

=== text ===

This is a list of zero-terminated strings, there must be as many strings as num-ent specifies.

Grfcodec version 0.9.6 or later accepts literal strings in the .nfo. These are encoded exactly as written, in whatever encoding your text editor uses; if you need a 00, put it immediately after the literal string.
For the supported encodings, format, and restrictions on what characters you may use, please see [[GRFActionsDetailed#Strings|GRFActionsDetailed]] and StringCodes.

A large number of original TTD strings require a colour code in front of the actual string. You can also use these colour codes in most of your custom strings. Use them wisely! In case a string requires a colour code, the string will have the code displayed in front of the default text as listed in [[TextIDs]].Typically, a colour coded string starts with the escape character (backslash), followed by hex byte and then the actual text string itself. I.e. string 0001 ("\94Off edge of map") has colour code 0x94 in front of the text string, which will colour it white. You can also put the plain hex byte outside the quoted string without having to escape it. ''94 "Off edge of map"'' would be the same as ''"\94Off edge of map"''

The following colour codes are available for use:

{| |-
!'''Code'''!!'''Colour'''!!'''Pallete Colour'''
|-
|88||Blue|| <div style="background:#3890E8;width:2em;"> </div>
|-
|89||Silver|| <div style="background:#C8C8C8;width:2em;"> </div>
|-
|8A||Golden|| <div style="background:#FCC000;width:2em;"> </div>
|-
|8B||Red|| <div style="background:#FC0000;width:2em;"> </div>
|-
|8C||Purple|| <div style="background:#A888E0;width:2em;"> </div>
|-
|8D||Light Brown|| <div style="background:#B0B084;width:2em;"> </div>
|-
|8E||Orange|| <div style="background:#FCB030;width:2em;"> </div>
|-
|8F||Green|| <div style="background:#90E05C;width:2em;"> </div>
|-
|90||Yellow|| <div style="background:#FCF880;width:2em;"> </div>
|-
|91||Dark Green|| <div style="background:#B4CC7C;width:2em;"> </div>
|-
|92||Cream|| <div style="background:#D49480;width:2em;"> </div>
|-
|93||Brown|| <div style="background:#A46040;width:2em;"> </div>
|-
|94||White|| <div style="background:#FCFCFC;width:2em;"> </div>
|-
|95||Light Blue|| <div style="background:#80C4FC;width:2em;"> </div>
|-
|96||Grey|| <div style="background:#626562;width:2em;"> </div>
|-
|97||Dark Blue|| <div style="background:#8484A4;width:2em;"> </div>
|-
|98||Black|| <div style="background:#101010;width:2em;"> </div>
|}

==Example==

Action4

2023-01-30T21:53:44Z

Michi cc: /* offset */

==Introduction==
Define strings, e.g vehicle, house or industry names

When making new vehicle graphics, you also need to name the new vehicles, or they'll show up with their original name from TTD.
However, custom vehicle names assigned by the player in-game (or for TTDPatch also via TTD's vehicle.dat) will always take precendence.

In TTDPatch you can also use this action to change most of TTD's text strings.

== Syntax ==

The data looks as follows:

<Sprite-number> * <Length> '''04''' <feature> <language-id> <num-ent> <offset> <text>

{| |-
!Element!![[GRFActionsDetailed|Size]]!!Description
|-
|<Sprite-number>||dec||A sequential sprite number
|-
|<length>||dec||The total number of bytes used in this action.
|-
|04||B||Defines action 04
|-
|<feature>||B||For what type of vehicle/station should this definition be used?
|-
|<language-id>||B||Which of TTD's languages this name is for
|-
|<num-ent>||B||Number of consecutive strings to change
|-
|<offset>||B/W||First ID to change
|-
|<text>||S||New text strings
|}

Whether <offset> is a '''BYTE''' (extended byte in openttd for vehicles) or a '''WORD''' is decided by bit 7 of <language-id>, see below.

== Descriptions ==

=== Sprite-number ===

This is just the number you are at.

=== Length ===

Count the number of bytes in this action.

=== Feature ===

This sets the type of [[Features|feature]] that you wish to change. Set it to:

{|- |
!Value!![[Features|Feature]]
|-
|00||Trains
|-
|01||Road Vehicles
|-
|02||Ships
|-
|03||Aircraft
|-
|04||Stations
|-
|07||Houses
|-
|0A||Industries
|-
|0B||Cargos
|-
|0D||Airports
|-
|0F||Objects
|-
|10||Railtypes
|-
|12||Roadtypes
|-
|13||Tramtypes
|-
|48||Original strings; see [[TextIDs]] for a list of TTD's text IDs.
|}

=== language IDs ===
The meaning of this byte depends on the GRF version of the .grf file as set in [[Action8#version|action 8]].

{{grfTill|6}} Up to version 6, this is a bit mask of the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||01||American or "other"
|-
|1||02||English
|-
|2||04||German
|-
|3||08||French
|-
|4||10||Spanish
|-
|7||80||Flag for 16 bit string IDs
|}

Add the bits of all languages for which the following strings apply. Bit 7 controls, whether the following string ID consists of 16 or 8 bit. Unknown languages will use the American strings as fallback. Otherwise the string would remain undefined for these languages. To actually define strings for any new language, you must use grf version 7.

{{grfFrom|7}} For version 7 and higher, it is a simple language ID from the list below. (This has changed with TTDPatch 2.5 beta 4). Bit 7 has the same meaning as in the earlier versions above.

In either scheme, you can use the value 7F or FF, respectively, to define strings shown for languages that you do not provide translation for. First set all strings to a default value using this, and later override the language specific ones if they exist.

Set bit7 (add 0x80 to the languageID as in the table below) in order to use 16 bit string IDs.

For a list of plural forms see [[StringCodes]]. As the assignment of plural forms to languages is in fact not as fixed as one might expect, the used plural form is defined by each GRF separately for its strings using [[Action0/Global Settings]] property 15.

{{:language_IDs}}

When translating for a new language, please simply edit the [[language_IDs|language list]] and add the new definition here.

=== num-ent ===

How many consecutive entries to change.

=== offset ===

The ID of the first string to change.

When language-id bit 7 is clear, this is a byte value; For OpenTTD since r13482, where it is an extended byte value for vehicles.

When language-id bit 7 is set, this is a word value in little endian notation, e.g. 8134 becomes 34 81.

The 8 bit version is only allowed for vehicles to set their name, in which case the text ID is just the vehicle ID.
To replace original texts, or to define texts for usage in callbacks or properties of vehicles, stations, houses or industries you have to use the 16 bit version. However, town names are changed with [[ActionF|Action F]].

For the usable 16 bit text IDs see the table below, resp. for feature 48 see [[TextIDs]].

Though these ranges are shared across all features, you should still set the proper feature you are using them for.

{| |-
!ID!!Content
|-
|C4xx||Set name of station class associated with station ID xx; this is the text above the preview (where otherwise TTD shows "Orientation")
|-
|C5xx||New station names, this changes the text "number of platforms" into the given text when the station with this ID from the current set is selected (i.e. xx=station-id from action 3 and 0)
|-
|C9xx||Name of the house type of this ID. If both property 12 and this is set, the latest definition is used always. You should prefer setting [[Action0/Houses#Building name ID (12)|property 12]] instead of this, so executables translated with TTD Translator will show the name in the current language. However, if you can't find any suitable old TTD texts, this can be used to specify your custom name. Don't forget to set the same text for all parts of a multi-tile building.
|-
|D0xx||Miscellaneous graphics texts, unique to each .grf file. Used for several callbacks. Some callbacks support IDs up to D3FF.
|-
|D4xx||'''Never use in Action4''', only for displaying textids in range D000-D3FF (grf specific), see [[TextIDs]]
|-
|D8xx
|{{ottd|1.7|rev=r27769}} Useable like DCxx in Action 0 and for inclusion via string codes 0x80 and 0x81.
{{ttdp|}}'''Never use in Action4''', only usable in Action0 features, see [[TextIDs]]
|-
|DCxx||Set miscellaneous persistent GRF texts. Useable in Action 0 and for inclusion via string codes 0x80 and 0x81.
{{ottd|14|ottdrev=gf5394ed2ef}} This area extends up to textid FFFF.
{{ttdp|}} Unlike the D0xx GRF texts, these IDs can be used to set properties. The text ID must be set before any [[Action0/Houses|action 0]] references it.
|}

{{ttdp|}} The DCxx IDs are allocated internally when defined, and are persistent in the savegame data. Each .grf file gets its own separate map of these internal IDs and thus may set all 256 of them.  However, only 1024 IDs are available in total, to be shared by all .grf files ever activated in the savegame. This means these IDs should be used as sparingly as possible. But use them when they are useful!

=== text ===

This is a list of zero-terminated strings, there must be as many strings as num-ent specifies.

Grfcodec version 0.9.6 or later accepts literal strings in the .nfo. These are encoded exactly as written, in whatever encoding your text editor uses; if you need a 00, put it immediately after the literal string.
For the supported encodings, format, and restrictions on what characters you may use, please see [[GRFActionsDetailed#Strings|GRFActionsDetailed]] and StringCodes.

A large number of original TTD strings require a colour code in front of the actual string. You can also use these colour codes in most of your custom strings. Use them wisely! In case a string requires a colour code, the string will have the code displayed in front of the default text as listed in [[TextIDs]].Typically, a colour coded string starts with the escape character (backslash), followed by hex byte and then the actual text string itself. I.e. string 0001 ("\94Off edge of map") has colour code 0x94 in front of the text string, which will colour it white. You can also put the plain hex byte outside the quoted string without having to escape it. ''94 "Off edge of map"'' would be the same as ''"\94Off edge of map"''

The following colour codes are available for use:

{| |-
!'''Code'''!!'''Colour'''!!'''Pallete Colour'''
|-
|88||Blue|| <div style="background:#3890E8;width:2em;"> </div>
|-
|89||Silver|| <div style="background:#C8C8C8;width:2em;"> </div>
|-
|8A||Golden|| <div style="background:#FCC000;width:2em;"> </div>
|-
|8B||Red|| <div style="background:#FC0000;width:2em;"> </div>
|-
|8C||Purple|| <div style="background:#A888E0;width:2em;"> </div>
|-
|8D||Light Brown|| <div style="background:#B0B084;width:2em;"> </div>
|-
|8E||Orange|| <div style="background:#FCB030;width:2em;"> </div>
|-
|8F||Green|| <div style="background:#90E05C;width:2em;"> </div>
|-
|90||Yellow|| <div style="background:#FCF880;width:2em;"> </div>
|-
|91||Dark Green|| <div style="background:#B4CC7C;width:2em;"> </div>
|-
|92||Cream|| <div style="background:#D49480;width:2em;"> </div>
|-
|93||Brown|| <div style="background:#A46040;width:2em;"> </div>
|-
|94||White|| <div style="background:#FCFCFC;width:2em;"> </div>
|-
|95||Light Blue|| <div style="background:#80C4FC;width:2em;"> </div>
|-
|96||Grey|| <div style="background:#626562;width:2em;"> </div>
|-
|97||Dark Blue|| <div style="background:#8484A4;width:2em;"> </div>
|-
|98||Black|| <div style="background:#101010;width:2em;"> </div>
|}

==Example==

Action3/Tramtypes

2022-12-26T23:02:42Z

Michi cc: /* cargo-type */ type 03 tunnel

== Introduction ==

Action 3 assigns graphics sets (referenced to by (chains of) [[Action2|action 2(s]]) to feature IDs.

{{ottdp|1.10}} Tramtypes are available only in OpenTTD > 1.10

== Format ==

The format of the data is feature-dependent. For tramtypes it looks like

<pre> <Sprite-number> * <Length> 03 13 <n-id> <ids...> <num-cid> <cargo-type> <set-ID>... <default set-ID></pre>

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

== Description ==

=== Sprite-number ===

This is just the number you are at.

=== Length ===

Count the number of bytes in this action.

=== n-id ===

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

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

=== ids ===

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

=== num-cid ===

Number of "cargo" type definitions that follow.

=== cargo-type ===

Tramtypes re-uses in its Action3 the 'cargo'-type definition in order to assign the type of graphics defined by the associated set-ID:

{| class="wikitable"
|-
!'Cargo' Type
!Sprite Type
!#Sprites
!Useage
|-
|00
|Icons and cursors
|12
|4 rail directions, autorail, depot, tunnel and convert rail. First all icons, then all cursors.
|-
|01
|Track overlays<ref name=leftout>Either all or none of these sprites should be provided.</ref>
|19
|11 trackbit combinations, 4 slopes, and 4 dead ends. These sprites are '''required''' for tramtypes.
|-
|02
|Underlay<ref name=leftout />
|19
|11 trackbit combinations, 4 slopes, and 4 dead ends. These sprites are required.
|-
|03
|Tunnel<ref name=leftout />
|4
|{{ottd|13|}} 1 sprite for each direction. Sprite is overlay for tram in existing tunnel graphics, but only if no road type has an overlay, too. The original ground sprite is drawn, then the overlay, then possibly a RV and the original tunnel head is drawn over the top. This keeps compatibility with different landscape types. Sprite order: SW, NW, NE, SE.
|-
|04
|Catenary front
|29
|11 trackbit combinations, 4 slopes, 4 dead ends, 4 tunnels, 2 bridge middle, 4 bridge ramps
|-
|05
|Catenary back
|29
|11 trackbit combinations, 4 slopes, 4 dead ends, 4 tunnels (unused), 2 bridge middle, 4 bridge ramps
|-
|06
|Bridge surfaces<ref name=leftout />
|6
|2 bridge middle, 4 bridge ramps
|-
|08
|Depots
|6
|Follows the original layout for depot sprites. If not present, the default depot sprites (depending on catenary flag) plus track overlay are drawn. If present, the depot sprites are expected to include track overlay graphics.

|}

<references />

==== GUI sprites (00) ====

[[File:Nrt_gui.png]]

==== Track overlay (01) ====

[[File:Nrt_overlay.png]]

==== Track underlay (02) ====

[[File:Nrt_underlay.png]]

==== Catenary front (04)====

[[File:Nrt_catenary_front.png]]

==== Catenary back (05) ====

[[File:Nrt_catenary_back.png]]

==== Depot sprites (08) ====

[[File:Nrt_depot.png]]

{| class="wikitable
|-
!Sprite Number
!Usage
|-
|0
|    NE wall for SE-entry depot.
|-
|1
|    Depot building for SE-entry depot.
|-
|2
|    NW wall for SW-entry depot.
|-
|3
|    Depot building for SW-entry depot.
|-
|4
|    Depot building for NE-entry depot.
|-
|5
|    Depot building for NW-entry depot.
|}

==== Bridge surfaces (06) ====

[[File:Nrt_bridge.png]]


=== default set-ID ===

The default set-ID would be used for tramtype callbacks. However, since there are currently no callbacks for tramtypes it should always result in a [[Action2/Only_Callback_Failure|callback-failure]].

== Example ==

Action3/Roadtypes

2022-12-26T23:00:27Z

Michi cc: /* cargo-type */ 03 tunnel

== Introduction ==

Action 3 assigns graphics sets (referenced to by (chains of) [[Action2|action 2(s]]) to feature IDs.

{{ottdp|1.10}} Roadtypes are available only in OpenTTD > 1.10

== Format ==

The format of the data is feature-dependent. For roadtypes it looks like

<pre> <Sprite-number> * <Length> 03 12 <n-id> <ids...> <num-cid> <cargo-type> <set-ID>... <default set-ID></pre>

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

== Description ==

=== Sprite-number ===

This is just the number you are at.

=== Length ===

Count the number of bytes in this action.

=== n-id ===

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

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

=== ids ===

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

=== num-cid ===

Number of "cargo" type definitions that follow.

=== cargo-type ===

Roadtypes re-uses in its Action3 the 'cargo'-type definition in order to assign the type of graphics defined by the associated set-ID:

{| class="wikitable"
|-
!'Cargo' Type
!Sprite Type
!#Sprites
!Useage
|-
|00
|Icons and cursors
|12
|4 road directions, autoroad, depot, tunnel and convert road. First all icons, then all cursors.
|-
|01
|Track overlays<ref name=leftout>Either all or none of these sprites should be provided.</ref>
|19
|11 roadbit combinations, 4 slopes, and 4 dead ends. These sprites are optional for roadtypes.
|-
|02
|Underlay<ref name=leftout />
|19
|11 roadbit combinations, 4 slopes, and 4 dead ends. These sprites are required.
|-
|03
|Tunnel<ref name=leftout />
|4
|{{ottd|13|}} 1 sprite for each direction. Sprite is overlay for road in existing tunnel graphics. The original ground sprite is drawn, then the overlay, then possibly a RV and the original tunnel head is drawn over the top. This keeps compatibility with different landscape types. Sprite order: SW, NW, NE, SE.
|-
|04
|Catenary front
|29
|11 roadbit combinations, 4 slopes, 4 dead ends, 4 tunnels, 2 bridge middle, 4 bridge ramps
|-
|05
|Catenary back
|29
|11 roadbit combinations, 4 slopes, 4 dead ends, 4 tunnels (unused), 2 bridge middle, 4 bridge ramps
|-
|06
|Bridge surfaces<ref name=leftout />
|6
|2 bridge middle, 4 bridge ramps
|-
|08
|Depots
|6
|Follows the original layout for depot sprites. If not present, the default depot sprites (depending on catenary flag) plus track overlay are drawn. If present, the depot sprites are expected to include track overlay graphics.

|-
|0A
|Road stops
|4
|Overlays for drive-in road stops
|-
|0B
|One-way road arrows
|18
|{{ottd|13|}} Overlays for one-way roads: repeat (arrow facing SW, arrow NE, impassable NE-SW, arrow NW, arrow SE, impassable NW-SE) for flat, N corner raised, S corner raised.
|}

<references />

==== GUI sprites (00) ====

[[File:Nrt_gui.png]]

==== Road underlay (02) ====

[[File:Nrt_underlay.png]]

==== Catenary front (04)====

[[File:Nrt_catenary_front.png]]

==== Catenary back (05) ====

[[File:Nrt_catenary_back.png]]

==== Depot sprites (08) ====

[[File:Nrt_depot.png]]

{| class="wikitable
|-
!Sprite Number
!Usage
|-
|0
|    NE wall for SE-entry depot.
|-
|1
|    Depot building for SE-entry depot.
|-
|2
|    NW wall for SW-entry depot.
|-
|3
|    Depot building for SW-entry depot.
|-
|4
|    Depot building for NE-entry depot.
|-
|5
|    Depot building for NW-entry depot.
|}

==== Bridge surfaces (06) ====

[[File:Nrt_bridge.png]]

==== Road stops (0A) ====

[[File:Nrt_drivein.png]]

==== One-way road arrows (0B) ====

Since {{ottd|13|}}.
[[File:Nrt_oneway.png]]



=== default set-ID ===

The default set-ID would be used for roadtype callbacks. However, since there are currently no callbacks for roadtypes it should always result in a [[Action2/Only_Callback_Failure|callback-failure]].

== Example ==

ReadingPatchVariables

2022-03-13T13:20:59Z

Michi cc: /* variable */ 0x17: Map seed

== Introduction ==

Since TTDPatch 2.0.1 alpha 48, it has been possible to use action D to read various special Patch variables. These are usually switch values, but there are also a few other useful values.

== Syntax ==

<Sprite-number> * <Length> 0D <target> <operation> <variable> FE FF FF 00 00

{|
!Element!![[GRFActionsDetailed|Size]]!!Description

|-
|0D||B||Defines action 0D

|-
|<target>||B||Target parameter

|-
|<operation>||B||As for ActionD, but only assignment is valid.

|-
|<variable>||B||Patch variable number to read. See below.

|-
|FE||B||Defines a special variable access

|-
|FF FF 00 00||D||Indicates that a patch variable is being read
|}

== variable ==

The following patch variables are defined:

{|
!variable!!Switch!!Version!!Value
|-
|00||miscmods/-Yo||{{ottdp|no|2.5}}||Bit switch
|-
|01||experimentalfeatures/-XF||{{ottdp|no|2.5}}||Bit switch
|-
|02||morevehicles/-x||{{ottdp|no|2.5}}||Vehicle array multiplier
|-
|03||mountains and curves/-mc||{{ottdp|no|2.5}}||Two bytes with four sets of two bits
|-
|04||planecrashcontrol/-Xc||{{ottdp|no|2.5}}||Bit switch
|-
|05||autorenew/-Xa||{{ottdp|no|2.5}}||Signed value
|-
|06||multihead/-M||{{ottdp|no|2.5}}||Speed increase, in percent
|-
|07||disasters/-XD||{{ottdp|no|2.5}}||Bit switch
|-
|08||unifiedmaglev/-XM||{{ottdp|no|2.5}}||Unified maglev mode
|-
|09||bridgespeedlimits/-XX||{{ottdp|no|2.5}}||Speed fraction, in percent
|-
|0A||---||{{ottdp|no|2.5}}||TTD Language, see the "new scheme" for [[Action4#language id|action 4]]
|-
|0B||startyear/-XY||{{ottdp|0.6|2.5}}||Year-1920
|-
|0C||morebuildoptions/-YB||{{ottdp|no|2.5}}||Bit switch
|-
|0D||moresteam/-YM||{{ottdp|no|2.5}}||value=LF (two hex digits), L=length, F=frequency
|-
|0E||freighttrains/-Yf||{{ottdp|0.6|2.5}}||weight factor
|-
|0F||wagonspeedlimits/-YL||{{ottdp|0.6|2.5}}||Speed increase for empty wagons
|-
|10||planespeed/-YP||{{ottdp|0.6|2.5}}||speed factor
|-
|11||dual company colors||{{ottdp|0.6|2.5|ttdprev=r1404}}||2CC colormap base sprite
|-
|12||miscmods2/-Zm||{{ottdp|no|2.6|ttdprev=r1738}}||Bit switch
|-
|13||map size information||{{ottdp|0.6|2.6|ottdrev=r11961|ttdprev=r1817}}||Format = -MABXYSS
{| |-
| M || the type of map
* bit 0 set: squared map. Clear : rectangular map
* bit 1 set: Y is the bigger edge(bit 0 is clear).Clear : X is the bigger edge.
|-
|A || minimum edge(log2) of the map
|-
|B || maximum edge(log2) of the map
|-
|XY || edges(log2) of each side of the map.
|-
|SS || combination of both X and Y, thus giving the size(log2) of the map
|-
|}
All map sizes will be substracted by 6, as to keep the size 64 the smallest one, thus zero based
|-
|14||maximum height level||{{ottdp|1.2|no|ottdrev=r23158}}||Maximal possible height level of a tile. {{ottdp|1.5|no|ottdrev=r27010}}Any value between 1 and 255. In earlier versions fixed at 15.
|-
|15||extra foundations||{{ottdp|1.4|no|ottdrev=r25230}}||Extra foundation sprites as set via [[Action5|Action 5 type 06]]. This sprite block does only contain the extra foundations from Action 5, it does not contain the default foundations of Action A sprites 990 to 1003.
|-
|16||coast sprites||{{ottdp|1.4|no|ottdrev=r25230}}||All coast sprites in the order of the 16 sprites version of [[Action5#In_NewGRFs|Action 5 type 0D]]. Note that, it does not matter in which way the sprites were originally defined (whether via Action 5 with 10 or 16 sprites, or via Action A), the sprite block returned by this variable has always all sprites in the same order.
|-
|17||map seed||{{ottdp|13.0|no|ottdrev=g08a5478a9}}||Map generation seed.
|}

If experimentalfeatures, miscmods, or miscmods2 are off, the corresponding value will be zero. For all other switches, the value is unspecified if the switch is off, so [[TTDPatchFlags|action 7 variable 85]] should be checked first.

Action0/Vehicles/Trains

2021-08-15T09:39:25Z

Michi cc: Prop 2E

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

=Introduction=
Defining properties of train vehicles.

= Properties =

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available for articulated parts
|-
|05||B||{{ottdp|0.6|2.0}}||Track type (see below)||should be same as front
|-
|08||B||{{ottdp|0.6|2.0}}||AI special flag: set to 1 if engine is 'optimized' for passenger service (AI won't use it for other cargo), 0 otherwise||no
|-
|09||W||{{ottdp|0.6|2.0}}||Speed in mph*1.6 (see below)||no
|-
|0B||W||{{ottdp|0.6|2.0}}||Power (0 for wagons)||should be zero
|-
|0D||B||{{ottdp|0.6|2.0}}||Running cost factor (0 for wagons)||should be zero
|-
|0E||D||{{ottdp|0.6|2.0}}||Running cost base, see below||should be zero
|-
|12||B||{{ottdp|0.6|2.0}}||Sprite ID (FD for new graphics)||yes
|-
|13||B||{{ottdp|0.6|2.0}}||Dual-headed flag; 1 if dual-headed engine, 0 otherwise||should be zero also for front
|-
|14||B||{{ottdp|0.6|2.0}}||Cargo capacity||yes
|-
|15||B||{{ottdp|0.6|2.0}}||Cargo type, see [[CargoTypes]]<br/>
{{grfTill|7}} For GRF version 7 and below: Type B 'cargo slot'<br/>
{{grfFrom|8}} For GRF version 8 and above: Type A '(translated) cargo bit'
||yes
|-
|16||B||{{ottdp|0.6|2.0}}||Weight in tons||should be zero
|-
|17||B||{{ottdp|0.6|2.0}}||Cost factor||should be zero
|-
|18||B||{{ottdp|<0.7|2.0}}<ref>This property is not used by OpenTTDs NoAI API.</ref>||Engine rank for the AI (AI selects the highest-rank engine of those it can buy)||no
|-
|19||B||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Engine traction type (see below)||no
|-
|1A||B/B*<ref>{{ottdp|0.7|no|ottdrev=r13831}} Since OpenTTD r13831 this is an extended byte.</ref>||{{ottdp|0.6|2.0}} {{grfFrom|1}}||Not a property, but an action: sort the purchase list.||no
|-
|1B||W||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Power added by each wagon connected to this engine, see below||should be zero
|-
|1C||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]||yes
|-
|1D||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (bit value) in [[CargoTypes]]||yes
|-
|1E||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below||yes
|-
|1F||B||{{ottdp|0.6|2.5|ttdprev=alpha 19}}||Coefficient of tractive effort||should be zero
|-
|20||B||{{ottdp|1.1|2.5|ttdprev=alpha 27}}||Coefficient of air drag||should be zero
|-
|21||B||{{ottdp|0.6|2.0}} {{grfFrom|2}}||Make vehicle shorter by this amount, see below||yes
|-
|22||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set visual effect type (steam/smoke/sparks) as well as position, see below||yes
|-
|23||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Set how much weight is added by making wagons powered (i.e. weight of engine), see below||should be zero
|-
|24||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||High byte of vehicle weight, weight will be prop.24*256+prop.16||should be zero
|-
|25||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||User-defined bit mask to set when checking veh. var. 42||yes
|-
|26||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])||no
|-
|27||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous flags||partly
|-
|28||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes||yes
|-
|29||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes||yes
|-
|2A||D||{{ottdp|0.6|2.5|ottdrev=r7191|ttdprev=r1210}}||Long format introduction date||no
|-
|2B||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period||yes
|-
|2C||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types||yes
|-
|2D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types||yes
|-
|2E||W||{{ottdp|12|no|ottdrev=g2183fd4dab}}||Maximum curve speed modifier||yes
|}
<references/>

= Description =

== Track type (05) ==
Set track type of vehicle: 0 = rail, 1 = monorail, 2 = maglev. For setting the appropriate traction type, see [[Action0Trains#Engine traction type 19|prop19]].

{{ottdp|1.0|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, this property is an index into the table instead.

== Speed (09) ==

Train speed is in units of mph*1.6, i.e. approximately km/h.

For wagons, this value is only used if the "wagonspeedlimit" switch is on, and it limits the speed of the train to that of the lowest wagon speed.  This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed.

For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit.

== Power (0B) ==

The power of the engine, in HP.

A value of 0 means that the vehicle will be a wagon, otherwise it will be an engine.

== Running cost base (0E) and factor (0D) ==

TTD calculates all costs by multiplying a 32-bit [[BaseCosts|base amount]] with an 8-bit factor.  The base amount is changed according to inflation, whereas the factor remains constant.

For the running costs of train vehicles, the following base amounts are available depending on the vehicle type (the value here is a pointer into TTD's memory where the actual amount is stored):

{| |-
!Type!!Value!!in little-endian notation
|-
|Steam engines||4C30||30 4C 00 00
|-
|Diesel engines||4C36||36 4C 00 00
|-
|Electric engines||4C3C||3C 4C 00 00
|-
|Wagons||0||00 00 00 00
|}

Theoretically, you could use pointers to other base amounts available in TTD, but these are the numbers TTD uses for train vehicles.

The following are some real values for maintenance costs depending on the setting of the above two factors.  This value is correct for medium difficulty, but increases and decreases for hard and easy difficulties respectively.  These are the costs of a new game starting in 1921, because they obviously increase with inflation over time (unless noinflation is turned on).

'''Running cost base 4C30 (steam)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 42
|-
|10||$ 700
|-
|20||$ 1.400
|-
|80||$ 5.600
|-
|A0||$ 7.000
|-
|FF||$ 11.112
|}

'''Running cost base 4C36 (diesel)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 40
|-
|10||$ 650
|-
|20||$ 1.300
|-
|80||$ 5.200
|-
|A0||$ 6.500
|-
|FF||$ 10.318
|}

'''Running cost base 4C3C (electric)'''

{| |-
!Running cost factor!!Maintenance cost
|-
|01||$ 36
|-
|10||$ 600
|-
|20||$ 1.200
|-
|80||$ 4.800
|-
|A0||$ 6.000
|-
|FF||$ 9.524
|}

== Cost factor (17) ==

The cost factor is a bit-coded value which determines how expensive an engine is. There is no distinction between steam, diesel or electric engines, they all use the same cost factor. The table below gives you some values to use for finding the right price for your engines.

{| |-
!Cost factor!!Price
|-
|01||$ 3.124
|-
|10||$ 50.000
|-
|20||$ 100.000
|-
|80||$ 400.000
|-
|A0||$ 500.000
|-
|FF||$ 796.874
|}

== Engine traction type (19) ==

This sets the traction type of a train engine, i.e. whether it is powered by steam, diesel, electric, monorail or maglev technology.  It also sets the corresponding sound effect of the engine, and if property 22 is not set, the visual effect as well.

The following ranges are available (and it does not matter which value you pick):

{| |-
!Values!!Traction type
|-
|00..07||Steam
|-
|08..27||Diesel
|-
|28..31||Electric
|-
|32..37||Monorail
|-
|38..41||Maglev
|}
Default value is 00, i.e. steam. For setting the appropriate track type, see [[Action0Trains#Track type 05|prop05]].

{{ottdp|1.1|no}} In OpenTTD, if a [[Action0Railtypes|rail type]] translation table is loaded, setting this property does NOT alter the track type.

== Sort vehicle list (1A) ==

This is not a property as such, but an action.  It forces TTDPatch to shuffle the vehicle this "property" is being set for in front of the vehicle with the given value of the property.  The order of this list is only used in the train purchase window.

For example, setting prop. 1A for vehicle 09 to a value of 07 would lead to the following internal list: ... 05 06 09 07 08 0A 0B ...

This property can not simply be overwritten, because the list is already shuffled when trying to do so.

{{ottdp|no|2.0}} It is possible to reset the list to its original order with a special action 0 that has num-info set to 0, and only sets property 1A for trains:
<pre>00 00 01 00 00 1A</pre>

Resetting the list should however only be done by sets that contain replacements for all train vehicles.

{{ottdp|0.7|no|ottdrev=r13831}} This property is an extended byte in OpenTTD since r13831!

== Powered train wagons (1B and 23, see also 22) ==

Normally, train wagons are unpowered in TTD, and if you set property 0B to a non-zero value, they become engines instead.  Therefore, to model real-life trains where wagons have power, a different mechanism is needed.
To make train wagons powered, you set property 1B of the '''engine''' instead of the wagon. This determines how much power each wagon adds to the train when attached to this engine. This only applies to wagons with a [[Action3|graphics override]] for this engine as well.  This means that for example passenger wagons (with an override) will add power, but coal wagons (with no override) will not.

In addition to adding power, these wagons are also heavier by the amount set in property 23.

== Refit cost (1C) ==

Refit cost, using 50% of the [[BaseCosts|purchase price cost base]]. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (27) is set, auto-refitting is allowed.

== Callbacks (1E) ==
For trains, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 1E (certain other, not as frequently used callbacks are available without setting a bit here):

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|0||1||10||Powered wagons and visual effect
|-
|1||2||11||Wagon length
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|4||10||16||Build articulated engines
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

These callbacks do not need a bit to activate them, they are always active and will be used if defined in the action 3/action 2 chain.
{| |-
!Variable 0C value!!Callback
|-
|1D||Can wagon be attached
|-
|23||Additional text in purchase screen
|-
|31||Start/stop check
|-
|32||32-day callback
|-
|36||Change Vehicle Properties
|-
|15E||Refit cost
|}

== Coefficient of tractive effort (1F) ==

This cofficient sets what fraction of the vehicle weight is equal to the maximum tractive effort.  This includes the effect of having some unpowered axles, as well as the coefficient of friction that is available.

Theoretically, this value should be calculated by taking the ratio of adhesive weight W<sub>adh</sub> (i.e. the vehicle weight that rests on powered axles) times the coefficient of friction µ between the wheels and the rails to the total vehicle weight W, times 255, and convert to hex:

prop. 1F = HEX ((W<sub>adh</sub> * µ / W) * 255)

With prop. 1F having a value of FF, the tractive effort is equal to the vehicle weight, for 80, it is half, and so on. If not set, a default of 4C is used, for a fraction of 0.30, corresponding to Wadh=W and a coefficient of friction of 0.30, which is the value used by the patch before TTDPatch 2.0.1 alpha 19.

Sometimes you know the real-life tractive effort instead of adhesive weight and coefficient of friction. To help calculating prop. 1F in that case, here's a small example using the NS 1600 (Electric) with a mass of 84 tons and real-life tractive effort (TE<sub>real</sub>) of 259 kN. To quickly find the value for property 1F you fill in the following formula:

prop. 1F = HEX ((TE<sub>real</sub> / (Mass * g) * 255)

That may look confusing but you already know all variables:

prop. 1F = HEX ((259 / (84 * 9.8) * 255)

prop. 1F = HEX (0.3146 *255) = HEX(80.229)

HEX calculations only work with figures in the natural domain: each figure has to be a positive and round figure. Therefore the value you convert to HEX isn't 80.229 but 80:

HEX 80 = 50

Property 1F for the NS 1600 (Electric) would then be: 1F 50.

== Coefficient of air drag (20) ==

This property sets the air drag coefficient c2 used for the realistic acceleration model, from 01 (no airdrag) to FF (most air drag) in arbitrary units. 00 means to use the default value that depends on the top speed (to simulate the fact that high-speed engines are more streamlined).

The default values are the following:

{| |-
!top speed (mph/1.6)!! <16!! 16!! 24!! 32!! 48!! 64!! 96!! 128!! 192!! 256!! ...
|-
|c2|| 192|| 128|| 96|| 64|| 48|| 32|| 24|| 16|| 12|| 8
|}

For higher speeds, the series is continued in the same manner.

Air drag in Newtons will then be c2*v*v with v in m/s, although it is probably futile to attempt to make c2 a realistic number due to the lack of TTD's consistent scaling. If a train doesn't reach its historical top speed, you might try setting the value of prop. 20 one or two steps lower than the default above, otherwise it's probably a good idea to leave it at the default.

== Shorter train vehicles (21) ==

This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly
<ref>{{ottdp|1.0|no|ottdrev=r15793}} This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.</ref>,
except at the end of the train
<ref>{{ottdp|<1.0|}} This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.</ref>. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).

<references/>

== Visual effects and wagon power (22) ==

By default, the visual effect of train engines is determined by the traction type (property 19). With this option you can change the type of effect as well as the position of it relative to the vehicle. (Note: for TTDPatch and OpenTTD up to r21229 only the positioning of steam actually works. For {{ottdp|1.1|no|ottdrev=r21230}} positioning diesel smoke and electric sparks works as well) The position of the effect provides a range from 0 to F that is added to the type of the effect.

Position 0 corresponds to a point half a vehicle length ahead of the vehicle, 4 is the front of the vehicle, 8 the middle, C the end and F is a half length behind the vehicle. Intermediate values are in-between.

Additionally, this property can be used to disable powered wagons of this type, although that is usually done with [[Callbacks#Visual_effect_and_wagon_power_.2810.29| callback 10]] instead (which has the same meaning as prop. 22, but is more flexible).

{| |-
!Range !!Effect type
|-
|00..0F||Use the default effect type, but reposition it. For engines this is defined via property 19, wagons have no default effect.
|-
|10..1F||Steam puffs
|-
|20..2F||Diesel fumes
|-
|30..3F||Electric sparks
|-
|40||Disable visual effect
|-
|41..7F||{{ottdp|1.5|no|ottdrev=r26747}} Create effects with [[Callbacks#Advanced_effect_creation_.28160.29|Callback 160]] using one of these spawning models:
* 41 Steam: Gradually less effects when approaching max speed
* 42 Diesel: Effect proportional to acceleration, no effect when idling at top speed
* 43 Electric: Random effect, gradually less likely when approaching max spped
* 44-7F Reserved
|-
|80+00..80+7F||Same as 00..7F above, but disable wagon power
|}

For example, 28 would make the wagon powered and emit diesel fumes, but 80+28 = A8 would only emit the diesel fumes without adding power.

== Miscellaneous flags (27) ==

This is a bit mask, with the following bits:

{| |-
!Bit!! Value!! Version !!Meaning
|-
|0|| 1||{{ottdp|0.6|2.5}}|| Vehicle tilts in curves, and thus gets speed bonus <ref>The tilting speed bonus only applies if all vehicles in the train have this bit set. In TTDPatch it requires the "curves" switch to be on. For realistic curves, it gives the train two free curving pieces with no speed decrease, and for other settings, it increases the curves setting by one (0->1, 1->2, 2->2). In OpenTTD, the curve speed limit increases by 20% if 'realistic' acceleration is enabled, else there is no effect.
</ref>
|-
|1|| 2||{{ottdp|0.6|2.5}}|| Uses two company colors
|-
|2|| 4||{{ottdp|0.6|2.5}}|| Vehicle is a multiple unit (DMU/EMU), for colour selection
|-
|3|| 8||{{ottdp|1.1|no|ottdrev=r21966}}|| Vehicle can be flipped around in the depot <ref>When you enable flipping of a vehicle in a depot you must make sure that the graphics are correctly aligned when flipped as well. Especially in the case of shortened vehicles. For multiheaded or articulated vehicles the flipping bit has no effect; these vehicles are never to be flipped around in the depot.
<br>
Prior to {{ottd|1.1|r21966}} all non-multiheaded/non-articulated vehicles would be able to flip around in the depot. As such this disables a "feature" in OpenTTD, but often it makes no sense to flip vehicles around (symetric vehicles) or the graphics are wrong (most shortened vehicles), and thus only enabling this when the NewGRF developer says it is possible is better.
</ref>
|-
|4|| 10||{{ottdp|1.2|no|ottdrev=r23087}}|| Auto-refitting is enabled for refits where callback 15E allows it or prop 1C specifies zero cost
|-
|5|| 20||{{ottdp|1.2|no|ottdrev=r23861}}|| Use cargo multiplier for default cargo (and load amount). See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6|| 40||{{ottdp|1.3|no|ottdrev=r24124}}|| Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}}|| [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
|}

<references />

== Cargo classes (28, 29) ==

To make vehicle sets more compatible with future new cargo definitions, these two properties allow vehicles to define what type of cargo they should be refittable to. A wagon will be refittable to all cargo types that match any of the classes set in prop. 28 except for the ones that match any of the classes set in prop. 29. In addition, afterwards those cargo types listed in prop. 1D will be toggled. In terms of logic, it is

Refit list = (cargos from prop. 28 AND NOT cargos from prop. 29) XOR cargos from prop. 1D

This means, if a cargo type is in the list because it matches prop. 28 but not prop 29, having the respective bit set in prop. 1D will disable it again. Conversely, if the cargo type is not in the list, the bit in prop. 1D will add it. This way, if props. 28/29 are unset, prop. 1D will retain the original meaning, but it is still able to selectively add or remove certain cargo types even if props. 28/29 are used.

As a consequence, you have both full control over the cargo types that you know of (using prop. 1D), and those you don't know of yet (using props. 28/29). Leave the bits for cargos that you don't know of unset in prop. 1D, and set/clear the bits for known cargos to add/remove them from the list as appropriate.

{{ottd|1.2|r23291}} It is recommended to use properties 2C and 2D instead of property 1D, as property 1D behaves badly if the cargo classes of a cargo are ever changed.

The class list is a bit mask. See the action0 cargos page for bits and classes defined so far.

Take a look at [[Action0Cargos#Cargo classes 16|Action0 for cargos]] for the classes defined so far.

Note that cargo types may belong to several classes. This is the reason for making two properties, an additive and a subtractive one, because this way a vehicle can be specified to be refittable to, for example, all express cargo that does not require refrigeration (i.e., from the default cargos, no food).
For the cargo types added in this way, the vehicle will probably have no specific graphics (in [[Action3|action 3]]) to show the cargo load.  In this case, the default will be used, which should therefore be sufficiently generic-looking if possible. However, using [[VariationalAction2/Vehicles#Vehicle cargo info 47|vehicle variable 47]] you can at least select the graphics most appropriate for the cargo type's class.
About the interaction with other properties take a look at the summary page about [[VehicleRefitting|vehicle refitting]].

Disclaimer: there is no guarantee that classes won't vary over time or between sets. The classes of a cargo may change between different versions of a specific industry/cargo newgrf, or different classes may be set for the same cargo label by different industry/cargo newgrfs. Feel free to use classes in your set for conveniently refitting to cargos, but if you - the vehicle author - care about specific cargos being transported in specific vehicles, use label based refits (changing labels without a very good reason is considered to be bad practice).

== Long format introduction date (2A) ==

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

== Custom cargo ageing period (2B) ==

This property allows to modify the period in ticks after which cargo carried by the vehicle is aged. By default, cargo is aged every 185 ticks. A value of 0 disables ageing of cargo. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

Changing this value from the default does not automatically make the vehicle earn more or less. Predicting the effect is complicated, as it depends on many things, including: vehicle speed, route length, route delays, transfer credits, the payment curve set by the cargo, and whether the cargo is already aged from a previous transfer when the vehicle loads it.

== List of always refittable cargo types (2C, 2D) ==

These two properties allows to unconditionally include or exclude cargo types for refittability independent of any of the other refit properties or the cargo classes. If you specify a cargo type that is not available, the cargo type will be silently ignored.

The format for both properties is:

<pre>2C/2D <nvar> (<Index into cargo type table>){n}</pre>

That is you give the number of cargos in a single byte followed by a list of that length of indexes into the cargo translation table ([[CargoTypes|Type A]]).

== Maximum curve speed modifier (2E) ==

This property allows to give vehicles a maximum curve speed modifier. The given value is treated as a signed word with 8 fractional bits. This property can be modified via [[Callbacks#Change_vehicle_properties_.2836.29|callback 36]].

The modifier is applied after the normal curve speed calculation is done using the formula max_curve_speed * (1 + prop 2E). This means that the default property value of 0 is equivalent to no change. While values less than -1.0 are technically possible, the resulting vehicle curve speed is clamped at 2 mph-ish to make sure vehicles don't become permanently stuck.

If different vehicles in a train have different curve speed modifiers, the lowest value wins.

= Example =

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

(A basic version)

<pre>10 * 14  00 00 03 01 02 09 C0 00 0B D8 0E 12 FD</pre>

{| |-
!'''Bytes'''!!'''Meaning'''
|-
|10||<Sprite-number>
|-
|14||<Length>: of the action in bytes; start counting at 0 (<action>)
|-
|00||<action>: sets this pseudo-sprite to function as action 0
|-
|00||<Feature>: In this case Train
|-
|03||<Num-props>: 3 Properties to change
|-
|01||<Num-info>: 1 vehicle ID to make changes to
|-
|02||<ids...>: vehcile ID (02 - Ploddyphut Choo-Choo)
|-
|||'''Properties'''
|-
|09||<Speed>
|-
|C0 00||<Value>: Value for Speed (192 Km/h)
|-
|0B||<Power>
|-
|D8 0E||<value>: value for Power (3800 HP)
|-
|12||<Sprite ID>
|-
|FD||<value>: FD for new graphics
|}
Since nfo version 7, so-called [[GRFActionsDetailed#Byte order|"escape sequences"]] have been introduced in an attempt to offer a more human-readable form.

Below is the same example as above, with escape sequences being used:

<pre>-1 * 0 00 00 \b3 01 \b*2 // \b<number of props to change> \b*<vehicle ID>

       09 \w192 // value for speed (192 Km/h)

       0B \w3800 // value for power (3800 hp)

       12 FD // use new graphics</pre>

TTDPatchFlags

2020-12-27T11:08:07Z

Michi cc: OTTD: economy.inflation

Action0/Vehicles/Planes

2020-12-06T19:35:58Z

Michi cc: /* Sound effect (12) */ PR #8347

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

== Introduction ==

Defining properties of planes.

== Properties ==

{| |-
!Number!![[GRFActionsDetailed|Size]]!!Version!!Description
|-
|08||B||{{ottdp|0.6|2.0}}||Sprite (FF for new graphics)
|-
|09||B||{{ottdp|0.6|2.0}}||Is helicopter? 2=no, 0=yes
|-
|0A||B||{{ottdp|0.6|2.0}}||Is large? 0=no, 1=yes (i.e. can't safely land on small airports)
|-
|0B||B||{{ottdp|0.6|2.0}}||Cost factor
|-
|0C||B||{{ottdp|0.6|2.0}}||Speed in units of 8 mph, that is: property = (speed in mph) / 8
|-
|0D||B||{{ottdp|0.6|2.0}}||Acceleration in units of 3/8 mph/tick, that is: property = (acceleration in mph/tick) * 8/3 <ref>{{ottd|<1.3.1}} In OpenTTD before r25115 the units for acceleration were messed up. The unit used was about 1 mph/tick, so aircraft accelerated more than twice as fast. Also values bigger than 19 failed.</ref>
|-
|0E||B||{{ottdp|0.6|2.0}}||Running cost factor
|-
|0F||W||{{ottdp|0.6|2.0}}||Primary cargo capacity (passenger or refitted cargo)
|-
|11||B||{{ottdp|0.6|2.0}}||Secondary cargo capacity (mail)
|-
|12||B||{{ottdp|0.6|2.0}}||Sound effect
|-
|13||D||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Bit mask of cargo types available for refitting, see column 2 (Bit Value) in [[CargoTypes]]
|-
|14||B||{{ottdp|0.6|2.5}} {{grfFrom|6}}||Callback flags bit mask, see below
|-
|15||B||{{ottdp|0.6|2.5|ttdprev=alpha 30}}||Refit cost, using 1/32 of the default refit cost base
|-
|16||B||{{ottdp|0.6|2.5|ttdprev=alpha 44}}||Retire vehicle early, this many years before the end of phase 2 (see [[Action0General]])
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Miscellaneous vehicle flags
|-
|18||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 28]]
|-
|19||W||{{ottdp|0.6|2.5|ttdprev=alpha 58}}||Non-refittable cargo classes, see [[Action0Trains#Cargo classes 28 29|train prop. 29]]
|-
|1A||D||{{ottdp|0.6|2.5|ttdprev=r1210|ottdrev=r7191}}||Long format introduction date
|-
|1B||B*||{{ottdp|0.7|no|ottdrev=r13831}}||Sort the purchase list
|-
|1C||W||{{ottdp|1.2|no|ottdrev=r22713}}||Custom cargo ageing period
|-
|1D||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of always refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2C]]
|-
|1E||B n*B||{{ottdp|1.2|no|ottdrev=r23291}}||List of never refittable cargo types, see [[Action0/Vehicles/Trains#List_of_always_refittable_cargo_types_.282C.2C_2D.29|train property 2D]]
|-
|1F||W||{{ottdp|1.2|no|ottdrev=r23504}}||Aircraft range in tiles. Distance is euclidean, a value of 0 means range is unlimited
|}

<references/>

== Descriptions ==

=== Primary (0F) and secondary (11) cargo capacity ===
Aircraft can transport up to two cargo types.
The first (primary) cargo type can be changed when refitting the aircraft.

The secondary cargo type is always mail, and is only present when the primary cargo type is part of the [[Action0/Cargos#CargoClasses_.2816.29|passenger cargo class]].

See also the page about [[VehicleRefitting|vehicle refitting]].

=== Sound effect (12) ===

The following sound effects are used by planes (note, the setting is ignored for helicopters):

{| |-
!Number!!Sound
|-
|06||Propeller sound 1
|-
|07||Jet sound 1
|-
|3B||Supersonic
|-
|3D||Jet sound 2
|-
|45||Propeller sound 2
|-
|46||Jet sound 3
|}

{{ottdp|1.6|no|ottdrev=r27507}} Since OpenTTD r27507 also custom sound effects from Action11 are allowed here.

{{ottdp|1.11|no|ottdrev=6198a47}} Since OpenTTD g6198a47 this prop can be used to to set custom Action11 sound effects for helicopers. Default sound effects are ignored as before.

=== Callbacks (14) ===
For planes, the following [[callbacks]] have to be enabled by setting the corresponding bit in property 14 (certain other, not as frequently used callbacks are available without setting a bit here)::

{| |-
!Bit!!Value!!Variable 0C value!!Callback
|-
|2||4||12||Load amount
|-
|3||8||15||Set refitted capacity
|-
|5||20||19||show a suffix after the cargo type name
|-
|6||40||2D||Select color mapping for vehicle
|-
|7||80||33||Sound effect callbacks
|}

Bit is the bit you have to set, you do this by adding all the values for all the bits. Variable 0C value is what variable 0C will be set to, for checking it in the VarAction2 for callbacks.

=== Refit cost (15) ===

Refit cost, using 1/32 of the default refit cost base. This property can be overridden by callback 15E.

{{ottdp|1.2|no|ottdrev=r23087}} If the refit cost factor is set to zero and bit 4 of the miscellaneous flags (17) is set, auto-refitting is allowed.

=== Miscellaneous flags (17) ===

This is a bit mask, with the following bits:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||reserved, do not use
|-
|1||2||Uses two company colors
|-
|2||4||reserved, do not use
|-
|3||8||reserved, do not use
|-
|4||10||{{ottdp|1.2|no|ottdrev=r23087}} Auto-refitting is enabled for refits where callback 15E allows it or prop 15 specifies zero cost.
|-
|5||20||{{ottdp|1.2|no|ottdrev=r23861}} Use cargo multiplier for default cargo. See page about [[VehicleRefitting#Misc._vehicle_flag_5_.27use_of_capacity_multiplier_for_default_cargo.27_set|vehicle refitting]].
|-
|6||40||{{ottdp|1.3|no|ottdrev=r24124}} Disable breakdown smoke effect.
|-
|7|| 80||{{ottdp|1.7|no|ottdrev=r27668}} [[Action2/Vehicles#Composing_vehicles_from_multiple_sprites|Compose vehicle from multiple sprites.]]
Note: This also applies to the rotor sprite, if custom rotor sprites are used.
|}

=== Long format introduction date (1A) ===

Set the vehicle introduction date, in days since the year 0. This takes account of leap years; dividable by 4, but not 100 unless 400. A start date of 1920-01-01 is obtained with a value of 701265 (51 B3 0A 00). This property must be set after property 00 to take effect.

{{ottdp|no|}} In TTDPatch, dates after 2044 will be limited to 2044.

=== Sort vehicle list (1B) ===
See sort vehicle list for [[Action0Trains#Sort vehicle list 1A|trains]] for details.

=== Custom cargo ageing period (1C) ===
See custom cargo ageing period for [[Action0Trains#Custom_cargo_ageing_period_.282B.29|trains]] for details.

== Example ==

To be written

Action0/Industries

2020-06-28T15:13:39Z

Michi cc: /* Special industry flags to define special behavior (1A) */ INDUSTRYBEH_WATER_NO_CLAMP_PROD

==Introduction==

Industries work similarly to town buildings. The limit for the number of industry types is:
* {{ttdp|2.5}} TTDPatch: 37
* {{ottd|<1.6}} OpenTTD < 1.6: 64
* {{ottd|1.6}} OpenTTD ⩾ 1.6: 128 per NewGRF, 240 in total
The non-overridden original types count towards the (total) limit. Industries don't have a climate mask; you should simply not define an industry if it would be for the wrong climate.

Defining industries follows the same schema as houses do: to start using an ID, you first need to define it by setting property 8 for it. If you try to reference an ID (either via action0 or via action3) that isn't defined, your request is ignored, but not reported as an error, either. This means that if you want to conditionally define an ID, all you need to do is skipping the action0 that sets property8, and everything else gets skipped automatically.

== Properties ==
{| |-
!Property !![[GRFActionsDetailed|Size]] !!Version !! Description
|-
|08||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Substitute industry type
|-
|09||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Industry type override
|-
|0A||V||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Set industry layout(s)
|-
|0B||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Industry production flags
|-
|0C||W||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Industry closure message
|-
|0D||W||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Production increase message
|-
|0E||W||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Production decrease message
|-
|0F||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Fund cost multiplier
|-
|10||W||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Production cargo types
|-
|11||D||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Acceptance cargo types
|-
|12,13||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Production multipliers
|-
|14||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Minimal amount of cargo distributed
|-
|15||V||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Random sound effects
|-
|16||3*B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Conflicting industry types
|-
|17||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Probability in random game
|-
|18||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Probability during gameplay
|-
|19||B||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Map color
|-
|1A||D||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Special industry flags to define special behavior
|-
|1B||W||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||New industry text ID
|-
|1C,1D,1E||D||{{ottdp|0.6|2.5|ttdprev=alpha 45}}||Input cargo multipliers for the three input cargo types
|-
|1F||W||{{ottdp|0.6|2.5|ttdprev=alpha 49}}||Industry name
|-
|20||D||{{ottdp|0.6|2.5|ttdprev=alpha 49}}||Prospecting success chance
|-
|21,22||B||{{ottdp|0.6|2.5|ttdprev=alpha 49}}||Callback flags
|-
|23||D||{{ottdp|0.6|2.5|ttdprev=alpha 73}}||Destruction cost multiplier
|-
|24||W||{{ottdp|0.6|2.6|ttdprev=r1782}}||Default text for nearby station
|-
|25||V||{{ottdp|1.9|no|ottdrev=e66cec8f}}||Production cargo type list
|-
|26||V||{{ottdp|1.9|no|ottdrev=e66cec8f}}||Acceptance cargo type list
|-
|27||V||{{ottdp|1.9|no|ottdrev=e66cec8f}}||Production multiplier list
|-
|28||V||{{ottdp|1.9|no|ottdrev=e66cec8f}}||Input cargo multiplier list
|}

== Description ==

=== Substitute industry type (08) ===

Substitute industry type. The first assignment of this property copies all properties of the old type to this new type. Unlike for houses, the substitute type won't replace this new type if the definition becomes unavailable. List of [[IndustryDefaultProps#Climate_independent_properties |valid industry types]]

There's a special use of this property beginning from alpha 70: if you set it to FFh, you can disable an original industry. In this case, the ID used must be the number of industry you want to disable. Disable requests are ignored for industries not present on the current climate and industries already overridden.

{{ottdp|1.1|ottdrev=r20108}} AIs can use the substitute type to make decisions about station graphics and vehicle choice via [[Callbacks#AI_construction.2Fpurchase_selection_.2818.29| callback 18]].

=== Industry type override (09) ===

Industry type override. The overridden industry type won't be built in new random games. If the GRF file becomes active after the game was started, industries of the overridden new type won't be replaced by the new type. List of [[IndustryDefaultProps#Climate_independent_properties |valid industry types]]

By overriding an old type, you're saying "my type is a substitute for that old type". When GRFs ask information about the old type you've overridden (via industry variable 67, for example), they will get information about your type instead. If you want to replace an old industry type with something completely different, use the "disable" function of property 08 (see above), then define the new industry type ''without'' using property 09. A rule of thumb: if your industry accepts or produces different cargoes than the original one, it should not override the original one.

For example, if you want to replace the old coal mine with something that changes its coal production more dynamically, use property 09 to override industry 00. This way, other industries that want to be far from coal mines will stay far from your industry type too. If, however, you want to replace the coal mine with a potash mine, do not use property 09. This will ensure that other industries don't consider your type as a coal mine.

Please note, however, that only one new industry can override an old type. If two new types want to override the same old type, the first one wins, and the second is added normally, ignoring its property 09.

=== Set industry layout(s) (0A) ===

Format of industry layout tables:

{| |-
!Size!!Variable!!Meaning
|-
|B||numlayouts||The total number of layouts following
|-
|D||size||The size of the whole definition, excluding numlayouts and size
|-
|V||layouts||numlayout layouts, see format below
|}

Format of an industry layout:

As a special case, if the first byte of a new industry layout is FEh, then only two bytes follow: the industry number and the layout number. The specified layout of the specified old industry type will be added to the layout list of the current industry. The following applies only if the first byte wasn't FEh

{| |-
!Size!!Variable!!Meaning
|-
|B||xoffs
|-
|B||yoffs||Offsets counted from the northernmost tile of the industry, specifying the position of the current tile. Both are taken as signed integers, but cannot go negative except the special case mentioned below.
|-
|B||oldtile||An old tile type to be put on the given tile
|-
|||--or--||
|-
|0xFE,W||newtile||The ID of an already defined industry tile, padded with 0 to create a word value. This tile type will be placed on the given tile.
|-
|||--or--||
|-
|0xFF|| ||The given tile is checked for clearance, but nothing will be placed on it. Useful to ensure some free space around your industry. This is the only case where xoffs and yoffs can be negative.

{{grfTill|7}} For GRF versions <= 7, if xoffs is negative, yoffs must be one lower than the wanted value.
|
|}

The layout consists of a list of the above tile definitions, terminated by two bytes: 0,80h

=== Industry production type (0B) ===

{| |-
!Value!!Meaning!!{{ottdp|0.6|no}} Effect on nearby stations!!Effect if [[Callbacks#Random_production_change_.2829.29|CB 29]] is disabled
|-
|00||consuming industry (e.g. power plant)||none||No production changes; no closure
|-
|01||extractive industry (e.g. coal mine)||suffix 'Mines' if some non-liquid, non-passenger, non-mail cargo is produced||Standard primary-industry production change
|-
|02||organic industry (e.g. forest)||suffix 'Forest' or 'Woods' if wood is produced||Standard primary-industry production change
|-
|04||processing industry (e.g. steel mill)||none||Standard processing-industry closing-behaviour
|}
Other values are reserved; do not set any other values.

=== Industry messages (0C..0E), new industry text ID (1B) ===

The text associated with these textID will be shown if the industry announces closedown, if the industry increases production, if the industry decreases production or when the industry is generated during the game.

For the generation message, by default, all industries have "New xxx is being constructed near yyy", except forests, that have "New Forest is being planted near yyy".

=== Production cargo types (10) ===

Two climate-dependent cargo numbers representing the cargo types the industry can produce. Unused slots can be filled with FFh. List of valid types: [[CargoTypes]]

{{ottdp|1.9|no|ottdrev=e66cec8f}} This property only supports two output cargos. Use property 25 instead to output more cargo types.

=== Acceptance cargo types (11) ===

Three climate-dependent cargo numbers representing the cargo types the industry can accept, plus a fourth filler byte which is always ignored. Unused slots can be filled with FFh. List of valid types: [[CargoTypes]]

These cargo types will only be really accepted if the according acceptance of the industry tiles adds up to 8/8 or more.

From GRF version 7 and above, the meaning of the above two properties will change: instead of climate-dependent cargo slot numbers, you have to give climate-independent cargo IDs. If your GRF has a cargo translation table, then this ID is the index in that table; otherwise, it's the cargo bit. Cargoes not currently present will be changed to FFh. Please note that TTD stops processing these lists at the first FFh value, so specifying absent cargoes isn't always safe.

{{ottdp|1.9|no|ottdrev=e66cec8f}} This property only supports three input cargos. Use property 26 instead to output more cargo types.

=== Production multipliers (12, 13) ===

If nonzero, the industry periodically (every 256 ticks, that is 8 or 9 times in a month) produces the given amount from the according cargo type. The properties specify the amount produced at default production level, they are scaled equally on [[Callbacks#Random production change 29|production changes]].

{{ottdp|1.9|no|ottdrev=e66cec8f}} This properties only supports two output cargos. Use property 27 instead to output more cargo types.

=== Minimal amount of cargo distributed (14) ===

The produced cargo will be distributed to stations only after it exceeds this amount.

=== Random sound effects (15) ===

The data starts with a byte defining the number of available effects, then one byte per effect. TTD periodically picks one of the available effects randomly, and plays it.

=== Conflicting industry types (16) ===

3 bytes define 3 types that won't appear in the vicinity of this industry. If a byte has bit 7 set, the bottom 6 bits are the ID of a new type already defined in the current GRF file. If bit 7 is clear, the bottom 6 bits specify an old industry type. FFh can be used to fill unused entries. You shouldn't modify property 9 after the type has been referenced by a property 16. List of [[IndustryDefaultProps#Climate_independent_properties |valid industry types]]

=== Probability in random game (17), Probability during gameplay (18) ===

Old types have probabilities between 0 and 10. If the random game probability value is nonzero, at least one instance of this type is guaranteed to appear on the map.

These probabilities are "relative probabilities". That is, if you set the probability of industry A to twice the probability of industry B, industry A will appear about twice as often as B. Increasing the probabilities of all industries on the other hand changes nothing. The appearance probabilities have no influence on how many industries are placed in total.

=== Map colour (19) ===

The value must be a color index from the DOS pallette. The following values are used by default industries:

{| |-
!Number!!Colour!!Example
|-
|01||Black||Coal mine
|-
|0A||Gray||Steel mill
|-
|0F||White||Bank
|-
|25||Dark beige||Water supply
|-
|27||Light beige||Rubber plantation
|-
|30||Pink||Farm
|-
|37||Brown||Food processing plant
|-
|56||Green||Forest
|-
|98||Blue||Oil wells/oil rig
|-
|AE||Purple||Factory
|-
|B8||Red||Power station
|-
|BF||Yellow||Oil refinery
|-
|C2||Orange||Saw mill
|-
|D0||Light green||Water tower
|}

=== Special industry flags to define special behavior (1A) ===

{| |-
!Bit!!Value!!Version!!Meaning
|-
|0||1||{{ottdp|0.6|2.5}}||The industry periodically plants fields around itself (temperate and arctic farms)
|-
|1||2||{{ottdp|0.6|2.5}}||The industry cuts trees around itself and produces its first output cargo from them (lumber mill)
|-
|2||4||{{ottdp|0.6|2.5}}||The industry is built on water (oil rig)
|-
|3||8||{{ottdp|0.6|2.5}}||The industry can only be built in towns (i.e. it has to replace houses) with population larger than 1200 (temperate bank)
|-
|4||10||{{ottdp|0.6|2.5}}||The industry can only be built in towns (i.e. it has to replace houses) (arctic and tropic banks, water tower)
|-
|5||20||{{ottdp|0.6|2.5}}||The industry is always built near towns (i.e. near town sign; additionally the industry is allowed to replace houses) (toy shop)
|-
|6||40||{{ottdp|0.6|2.5}}||Fields are planted around the industry when it's built (all farms)
|-
|7||80||{{ottdp|0.6|2.5}}||The industry cannot increase its production on the temperate climate (oil wells)
|-
|8||100||{{ottdp|0.6|2.5}}||The industry is built only before 1950 (oil wells)
|-
|9||200||{{ottdp|0.6|2.5}}||The industry is built only after 1960 (oil rig)
|-
|10||400||{{ottdp|0.6|2.5}}||AI players will attempt to establish air and ship routes going to this industry (oil rig)
|-
|11||800||{{ottdp|0.6|2.5}}||The industry can be exploded by a military airplane (oil refinery)
|-
|12||1000||{{ottdp|0.6|2.5}}||The industry can be exploded by a military helicopter (factory)
|-
|13||2000||{{ottdp|0.6|2.5}}||The industry can cause a subsidence (coal mine)
|-
|14||4000||{{ottdp|0.6|2.5}}||Automatic production multiplier handing (No industry has this bit set by default.)<ref>If bit 14 is set, variables 40..42 will be divided by industry.prodmultiplier (variable 93), and the resulting instructions will be multiplied by the same amount before applying them. If you set this bit, please use small amounts in your instructions, since industry.prodmultiplier is 16 for default production, and can get as high as 128.</ref>
|-
|15||8000||{{ottdp|0.6|2.5}}||The production callback needs random bits in var. 10 (No industry has this bit set by default.)
|-
|16||10000||{{ottdp|1.0|2.6|ttdprev=r1925}}||Do not force one instance of this type to appear during initial map generation (No industry has this bit set by default.)
|-
|17||20000||{{ottdp|0.6|2.6|ttdprev=r1925}}||Allow closing down the last instance of this type (No industry has this bit set by default.)
|-
|18||40000||{{ottdp|1.9|no|ottdrev=e66cec8f}}||New format for callback 37, 14B, 14C to support more input/output cargos. See the callbacks for details.
|-
|19||80000||{{ottdp|1.11|no|ottdrev=6d3c2edc}}||By default, the amount of the second produced cargo is clamped for water industries (e.g. pax for oil rigs). This flag disables the clamping.
|}

<references />

By default, TTDPatch tries to ensure that cargo chains don't get broken. To achieve this, TTDPatch always generates at least one instance from every available industry type during random map generation, and prevents the last instance from closing down even when the production change callback says it should. If your industry type isn't essential for gameplay, or you want to handle this situation yourself, you can set bits 16 and/or 17 to turn off the default TTDPatch behavior.

If you supply a lot of industry types but also want to support OpenTTD's small map sizes you should set bit 16 for the less important industry types which can be ommitted (there will likely not be enough space for an industry of every type).

=== Input cargo multipliers for the three input cargo types (1C..1E) ===

If the first (low) word of the property is M1 and the second (high) word is M2, and X units of the corresponding cargo is delivered to the industry, the output amounts are calculated this way:

<pre>output_type1 = X*M1/256

output_type2 = X*M2/256</pre>

The default value for old industry types is 0100h,0000h , so every unit of input cargo produces one unit of output cargo of the first type. Exceptions are temperate banks and oil rigs, that have the default value of 0000h,0000h ,so input cargo doesn't affect output.

{{ottdp|1.9|no|ottdrev=e66cec8f}} This property only supports three input and two output cargos. Use property 28 instead, if you have more cargo types.

=== Industry name (1F) ===

This is the text ID that will be attached to the town name when TTD texts refer to the industry.

=== Prospecting success chance (20) ===

This value is currently used only for extractive and organic industries (see property 0B for details). The higher this value is, the higher the chance that your industry can be built on a random place after prospecting. 0 means constant failure, while FFFFFFFFh means constant success.

=== Callback flags (21,22) ===

Property 21 can have the following bits set:

{| |-
!Bit!!Value!!Var. 0C!!Version!!Callback
|-
|0||1||22||{{ottdp| |2.5}}||Determine whether the industry can be built
|-
|1||2||00||{{ottdp| |2.5}}||Call the [[Action2Industries|production callback]] when cargo arrives at the industry <ref name="smootheconomy">{{ottdp|0.6|no}} If none of the production change callbacks is activated, OpenTTD will use "smooth economy" if enabled. If any of the callbacks is enabled, "smooth economy" will be disabled for the industry.</ref>
|-
|2||4||00||{{ottdp| |2.5}}||Call the [[Action2Industries|production callback]] every 256 ticks <ref name="smootheconomy"/>
|-
|3||8||28||{{ottdp| |2.5}}||Determine whether the industry can be built on given spot
|-
|4||10||29||{{ottdp| |2.5}}||Control random production changes
|-
|5||20||35||{{ottdp| |2.5}}||Monthly random production change
|-
|6||40||37||{{ottdp| |2.5}}||Cargo sub-type display
|-
|7||80||38||{{ottdp| |2.5|ttdprev=2.0.1 alpha 72}}||Additional text in industry fund window
|}
<references/>

Property 22 can have the following bits set:

{| |-
!Bit!!Value!!Var. 0C!!Version!!Callback
|-
|0||1||3A||{{ottdp| |2.5|ttdprev=2.0.1 alpha 72}}||Show additional text in industry window
|-
|1||2||3B||{{ottdp| |2.5|ttdprev=2.0.1 alpha 73}}||Control special industry effects
|-
|2||4||3D||{{ottdp| |2.5|ttdprev=2.5 beta 4 }}||Opt out of accepting cargo
|-
|3||8||14A||{{ottdp| |2.6|ttdprev=r1712}}||Decide industry color
|-
|4||10||14B||{{ottdp| |2.6|ttdprev=r1718}}||Decide input cargo types
|-
|5||20||14C||{{ottdp| |2.6|ttdprev=r1718}}||Decide output cargo types
|-
|6||40||15F||{{ottdp|1.3|no|ottdrev=r24186}}||Set initial production level on construction.
|}

=== Destruction cost multiplier (23) ===

This value specifies the cost of removing the industry when the ctrl-dynamite function of morebuildoptions.removeindustry is enabled. This value is multiplied by the house removal cost multiplier to get the final cost. The default value is 1000 in TTDPatch, and 0 (zero) in OpenTTD.

=== Default name for nearby station (24) ===

If non-zero, this text ID specifies an additional name option for stations built near this industry, which will be used before any of the standard TTD names. The text should contain a \80, which will be the name of the nearby town.

If the newly built station cannot use the specified text (because that name has been used for another station in the same town) the default TTD naming system will be used, but without the names "\80 Oilfield" or "\80 Mines".

Setting this to zero disables "\80 Oilfield" and "\80 Mines" without adding any additional station name options.

=== Production cargo type list (25) ===
{{ottdp|1.9|no|ottdrev=e66cec8f}}

Format:
<numoutput> (<cargotype>)*

{| |-
!Size!!Variable!!Meaning
|-
|B||numoutput||Number of <cargotype> to follow,
|-
|B||cargotype||Cargotype (from CTT) to produce.
|}

This property defines up to 16 cargotypes, which are produced by the industry.
Use this property instead of property 10.

=== Acceptance cargo type list (26) ===
{{ottdp|1.9|no|ottdrev=e66cec8f}}

Format:
<numinput> (<cargotype>)*

{| |-
!Size!!Variable!!Meaning
|-
|B||numinput||Number of <cargotype> to follow,
|-
|B||cargotype||Cargotype (from CTT) to accept.
|}

This property defines up to 16 cargotypes, which are accepted by the industry.
Use this property instead of property 11.

=== Production multiplier list (27) ===
{{ottdp|1.9|no|ottdrev=e66cec8f}}

Format:
<numoutput> (<amount>)*

{| |-
!Size!!Variable!!Meaning
|-
|B||numinput||Number of <amount> to follow,
|-
|B||amount||Amount of cargo to produce.
|}

If nonzero, the industry periodically (every 256 ticks, that is 8 or 9 times in a month) produces the given amount from the according cargo type.
The amounts correlate to the cargotypes set by property 25. If fewer/more amounts are set, the extra items are not produced/ignored.

The properties specify the amount produced at default production level, they are scaled equally on [[Callbacks#Random production change 29|production changes]].

Use this property instead of property 12 and 13.

=== Input cargo multiplier list (28) ===
{{ottdp|1.9|no|ottdrev=e66cec8f}}

Format:
<numinput> <numoutput> (<multiplier>)*

{| |-
!Size!!Variable!!Meaning
|-
|B||numinput||Number of input cargos to use.
|-
|B||numoutput||Number of output cargos to use.
|-
|W||multiplier||Cargo multipliers in 1/256 units. <numinput>*<numoutput> items.
|}

This property defines a matrix which described how input cargos from property 26 are processed into output cargos from property 25.

Example:
03 04 // 3 input cargos, 4 output cargos
\wx0100 \wx0000 \wx0000 \wx0100 // input cargo 0 is converted to output cargos 0 and 3
\wx0000 \wx0100 \wx0000 \wx0100 // input cargo 1 is converted to output cargos 1 and 3
\wx0000 \wx0000 \wx0100 \wx0100 // input cargo 2 is converted to output cargos 2 and 3

The matrix correlates to the cargotypes set by property 25 and 26. If fewer/more cargotypes are used, the extra items are not produced/ignored.

Use this property instead of property 1C..1E.

Features

2019-05-09T18:37:04Z

Michi cc: /* List of features and feature-specific Actions */

==List of features and feature-specific Actions==

{| |-
!colspan="2"|Feature || [[Action0]] || [[Action1]] || [[Action2]] || [[VariationalAction2 | VarAction2]] || [[RandomAction2]] || [[Callbacks]] || [[Action3]] || [[Action4]]
|-
|00 || Trains || [[Action0/Vehicles/Trains | yes]] || [[Action1 | yes]] || [[Action2/Vehicles | yes]] || [[VariationalAction2/Vehicles | yes]] || [[RandomAction2#Vehicles | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|01 || Road Vehicles || [[Action0/Vehicles/RoadVehicles | yes]] || [[Action1 | yes]] || [[Action2/Vehicles | yes]] || [[VariationalAction2/Vehicles | yes]] || [[RandomAction2#Vehicles | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|02 || Ships || [[Action0/Vehicles/Ships | yes]] || [[Action1 | yes]] || [[Action2/Vehicles | yes]] || [[VariationalAction2/Vehicles | yes]] || [[RandomAction2#Vehicles | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|03 || Aircraft || [[Action0/Vehicles/Planes | yes]] || [[Action1 | yes]] || [[Action2/Vehicles | yes]] || [[VariationalAction2/Vehicles | yes]] || [[RandomAction2#Vehicles | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|04 || Stations || [[Action0/Stations | yes]] || [[Action1 | yes]] || [[Action2/Stations | yes]] || [[VariationalAction2/Stations | yes]] || [[RandomAction2#Stations | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|05 || Canals || [[Action0/Canals | yes]] || [[Action1 | yes]] || [[Action2/Single Set | yes]] || [[VariationalAction2/Canals | yes]] || [[RandomAction2#Canals | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || ''no''
|-
|06 || Bridges || [[Action0/Bridges | yes]] || ''no'' || ''no'' || [[VariationalAction2/Bridges | no-ish]] || ''no'' || ''no'' || ''no'' || [[Action0/Bridges#Purchase_text_.2810.29 | yes-ish]]
|-
|07 || Houses || [[Action0/Houses | yes]] || [[Action1 | yes]] || [[Action2/Sprite Layout | yes]] || [[VariationalAction2/Houses | yes]] || [[RandomAction2#Town_building_triggers | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|08 || Global Settings || [[Action0/Global Settings | yes]] || ''no'' || ''no'' || ''no'' || ''no'' || ''no'' || ''no'' || ''no''
|-
|09 || Industry Tiles || [[Action0/Industry Tiles | yes]] || [[Action1 | yes]] || [[Action2/Sprite Layout | yes]] || [[VariationalAction2/Industry Tiles | yes]] || [[RandomAction2#Industry_tile_triggers | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || ''no''
|-
|0A || Industries || [[Action0/Industries | yes]] || [[Action1 | yes]] || [[Action2/Industries | yes]] || [[VariationalAction2/Industries | yes]] || [[RandomAction2#Industry_tile_triggers | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|0B || Cargos || [[Action0/Cargos | yes]] || [[Action1 | yes]] || [[Action2/Single Set | yes]] || [[VariationalAction2 | yes-ish]] <ref name="novars">No feature specific variables though</ref> || ''no'' || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|0C || Sound Effects || [[Action0/Sound Effects | yes]] || ''no'' || [[Action2/Only Callback Failure | yes-ish]] <ref name="failonly">Callback failure only</ref> || [[VariationalAction2 | yes-ish]] <ref name="novars"/> || ''no'' || [[Callbacks | yes]] || [[Action3 | yes]] || ''no''
|-
|0D || Airports || [[Action0/Airports | yes]] || [[Action1 | yes]] || [[Action2/Single Set | yes]] || [[VariationalAction2/Airports | yes]] || [[RandomAction2#Stations | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|0E || Signals || ''no'' || [[Action5#0E_New_Signals | Action5]] || [[Action2/Only Callback Failure | yes-ish]] <ref name="failonly"/> || [[VariationalAction2/Signals | yes]] || ''no'' || [[Callbacks | yes]] || [[Action3 | yes]] || ''no''
|-
|0F || Objects || [[Action0/Objects | yes]] || [[Action1 | yes]] || [[Action2/Sprite Layout | yes]] || [[VariationalAction2/Objects | yes]] || [[RandomAction2#Objects | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || [[Action4 | yes]]
|-
|10 || Railtypes || [[Action0/Railtypes | yes]] || [[Action1 | yes]] || [[Action2/Single Set | yes]] || [[VariationalAction2/Railtypes | yes]] || [[RandomAction2#Rail_types | yes]] || ''no'' || [[Action3 | yes]] || [[Action4 | yes]]
|-
|11 || Airport Tiles || [[Action0/Airport Tiles | yes]] || [[Action1 | yes]] || [[Action2/Sprite Layout | yes]] || [[VariationalAction2/Airport Tiles | yes]] || [[RandomAction2#Stations | yes]] || [[Callbacks | yes]] || [[Action3 | yes]] || ''no''
|-
|12 || Roadtypes || [[Action0/Roadtypes | yes]] || [[Action1 | yes]] || [[Action2/Single Set | yes]] || [[VariationalAction2/Roadtypes | yes]] || [[RandomAction2#Road_types | yes]] || ''no'' || [[Action3 | yes]] || [[Action4 | yes]]
|-
|13 || Tramtypes || [[Action0/Roadtypes | yes]] || [[Action1 | yes]] || [[Action2/Single Set | yes]] || [[VariationalAction2/Roadtypes | yes]] || [[RandomAction2#Road_types | yes]] || ''no'' || [[Action3 | yes]] || [[Action4 | yes]]
|-
|N/A 
| Towns || ''no'' || ''no'' || ''no'' || [[VariationalAction2/Towns | yes]] || ''no'' || ''no'' || ''no'' || [[ActionF]]
|-
|48 || Original Strings <ref>This is a pseudo-feature only used in Action4 to assign original strings. The value 0x48 originates from the way old TTDPatch versions checked for switches enabling/disabling features. NewTrains (feature 0x00) are activated by [[TTDPatchFlags | switch 0x37]]. Adding 0x48 to that results in 0x7F - a switch which is always set when TTDPatch is active. Thus feature 0x48 was not disabled by any switch. (today TTDPatch does not depend on the switches being in order of the features)</ref> || ''no'' || ''no'' || ''no'' || ''no'' || ''no'' || ''no'' || ''no'' || [[Action4 | yes]]
|}
<references/>

Action0/Railtypes

2019-03-10T10:36:13Z

Michi cc: /* Rail type flags (10) */ More details for 90 deg

'''''Action 0 properties for rail types'''''

= Action 0 - Properties for rail types =

Defining properties of rail types.

{{ottdp|1.0|no|ottdrev=r18969}} 16 railtypes can be defined.

{{ottdp|1.9|no|ottdrev=bf8d7df7}} 64 railtypes can be defined.

== Properties ==

{| class="wikitable"
|-
!'''Number'''
!'''Version'''
!'''Size'''
!'''Description'''
|-
|08
|{{ottdp|1.0}}
|4*B
|Rail type label
|-
|09
|{{ottdp|1.0}}
|W
|StringID: Build rail toolbar caption<ref>{{grfTill|7}} For GRF version 7 or earlier, setting property 09 sets property 1B as well.</ref>
|-
|0A
|{{ottdp|1.0}}
|W
|StringID: Rail construction dropdown text
|-
|0B
|{{ottdp|1.0}}
|W
|StringID: Build vehicle window caption
|-
|0C
|{{ottdp|1.0}}
|W
|StringID: Autoreplace text
|-
|0D
|{{ottdp|1.0}}
|W
|StringID: New engine text
|-
|0E
|{{ottdp|1.0}}
|B n*D
|Compatible rail type list<ref name="alt_label">Rail type labels in this list are ''not'' resolved using the alternate label list.</ref>
|-
|0F
|{{ottdp|1.0}}
|B n*D
|Powered rail type list<ref name="alt_label" />
|-
|10
|{{ottdp|1.0}}
|B
|Rail type flags
|-
|11
|{{ottdp|1.0}}
|B
|Curve speed advantage multiplier
|-
|12
|{{ottdp|1.0}}
|B
|Station (and depot) graphics
|-
|13
|{{ottdp|1.0}}
|W <ref>In r18969 to 19306 this property was byte-sized.</ref>
|Construction costs
|-
|14
|{{ottdp|1.0}}
|W
|Speed limit
|-
|15
|{{ottdp|1.0}}
|B
|Acceleration model
|-
|16
|{{ottdp|1.0|no|ottdrev=r19307}}
|B
|Minimap colour
|-
|17
|{{ottdp|1.1|no|ottdrev=r21842}}
|D
|Introduction date
|-
|18
|{{ottdp|1.1|no|ottdrev=r21842}}
|B n*D
|Introduction required rail type list<ref name="alt_label" />
|-
|19
|{{ottdp|1.1|no|ottdrev=r21841}}
|B n*D
|Introduced rail type list<ref name="alt_label" />
|-
|1A
|{{ottdp|1.1|no|ottdrev=r21866}}
|B
|Sort order
|-
|1B
|{{ottdp|1.2|no|ottdrev=r23129}}
|W
|StringID: Rail type name<ref>{{grfTill|7}} For GRF version 7 or earlier, set property 1B ''after'' setting property 09, as property 09 sets the rail type name as well for backwards compatibility.</ref>
|-
|1C
|{{ottdp|1.2|no|ottdrev=r23415}}
|W
|Infrastructure maintenance cost factor
|-
|1D
|{{ottdp|1.2|no|ottdrev=r23758}}
|B n*D
|Alternate rail type labels that shall be "redirected" to this rail type
|}

<references />

In NFO, rail type IDs will be GRF local, with an ID to label mapping. Therefore to modify an existing rail type, specify its label in property 08. To create a new rail type, again just specify its label in property 08. This way there is no need for complex GRM mechanisms to allocate IDs. If a label 'clashes' with another GRF, then one GRF will end up modifying the properties instead of creating a new rail type.

When a new rail type is created, it is populated with the information from the first rail type, except that the compatible and powered list contain only the rail type being created. However, no default values should be assumed, as the first rail type may have been modified.

== Vehicle and Railtype availability ==

Vehicle and railtype availability and compatibility is influenced by multiple properties.
Generally, the vehicle defines which railtype it is, and the railtypes define the compatibility between each other.
* A vehicle exists, if its railtype (train prop 05) is defined. Otherwise the vehicle is disabled.
* When a vehicle is introduced, it always introduces its railtype (train prop 05).
* A railtype is introduced, if at least one of the following conditions is met:
** A vehicle is introduced, that references the railtype (train prop 05).
** Another railtype is introduced, that references the railtype via the introduced railtype list (railtype prop 19).
** The introduction date (railtype prop 17) is passed and all required railtypes (railtype prop 18) are available.

Via railtype property 1D multiple railtypes can be defined, which shall be considered equivalent to a railtype.
This affects the interpretation of train property 05. If train property 05 references an undefined railtype, then
railtype property 1D is checked for all defined railtypes, whether the vehicle can be reassigned to some other railtype.
Otherwise the vehicle is disabled.

== Rail type label (08) ==

These are globally unique four-letter identifiers for specific rail types (analoguous to [[Action0Cargos#Cargo label 17|cargo labels]]), used to make various rail types accessible from train vehicle grfs. Reserved labels for default rail types are:

{| class="wikitable
|-
!'''Label'''
!'''Rail Type'''
|-
|RAIL
| Normal Rail
|-
|ELRL
| Electrified Rail
|-
|MONO
| Mono Rail
|-
|MGLV
| Maglev Rail
|}

{{ottdp|1.0|no|ottdrev=r18969}} 16 railtypes can be defined.

{{ottdp|1.9|no|ottdrev=bf8d7df7}} 64 railtypes can be defined.

Rail type sets may use up to 64 railtypes and have to specify their own [[RailtypeLabels|labels]].

See also [[Action0/Global Settings#Rail type translation table 12|Rail Type Translation Table]] for further info.

== Build rail toolbar caption (09) ==

String ID of the name of the rail type as shown in the toolbar caption.

{{grfTill|7}} {{ottd|1.2|ottdrev=r23129}} For backwards compatibility, setting this property sets the rail type name (property 1B) to this string as well for GRF versions 7 or below.

OpenTTD before r20342 and 1.0.3 require the string to start with the white control code. Later versions of OpenTTD will automatically default to white.

== Rail construction dropdown text (0A) ==

String ID for text in the dropdown of all rail types.

This string must never start with a colour control code.

== Build vehicle window caption (0B) ==

String ID for build vehicle window caption.

OpenTTD before r20342 and 1.0.3 require the string to start with the white control code. Later versions of OpenTTD will automatically default to white.

== Autoreplace text (0C) ==

String ID for rail type shown in autoreplace window.

== New engines (0D) ==

StringID to use for showing texts of the type "We have invented a new <rail type> engine".

== Compatible rail type list (0E) ==

List of rail types on which trains of this rail type can run, even though they might not be powered. E.g. wagons/engines of "eletrified rail"-type are also compatible to "normal rail" and "third rail" type, but they are not powered (there need to be an other powered engine in the consist to move the train).

The format is:

<pre>0E <nvar> (<rail type label>){n}</pre>

That is you give the number of compatible rail types in a single byte followed by a list of that length of rail type labels. A rail type is automatically compatible (and powered) with itself, so you don't need to list the current rail type.

Note that these properties apply to trains of this rail type, not the track. If you want trains of other rail types to be able to run on your rail types, you must set the compatible rail types property for each rail type. Setting these properties behaves always incremental, so you only need to the set additional bits for each other rail type, you cannot remove compatibility/poweredness once it is set (by some other grf).

== Powered rail type list (0F) ==

List of rail types on which trains of this rail type are powered. E.g. engines of "normal rail"-type are powered on "electrified rail"- and "third-rail"-type as well.

Same format as for property 0E above.

== Rail type flags (10) ==

Flags to define properties related to the rail type:

{| class="wikitable"
|-
!'''Bit'''
!'''Value'''
!'''Version'''
!'''Meaning'''
|-
|0
|1
||{{ottdp|1.0}}
|Draw catenary for this rail type
|-
|1
|2
||{{ottdp|1.1|no|ottdrev=r20049}}
|Disallow level crossings for this rail type
|-
|2
|4
||{{ottdp|1.9|no|ottdrev=e3b440c9c5}}
|Hide this rail type from construction menu
|-
|3
|8
||{{ottdp|1.10|no|ottdrev=g42046af933}}
|Enable use of precombined overlay sprites
|-
|4
|16
||{{ottdp|1.10|no|ottdrev=gcc5f175615}}
|Always allow 90 degree turns
|-
|5
|32
||{{ottdp|1.10|no|ottdrev=gcc5f175615}}
|Always prohibit 90 degree turns (takes precedence over bit 4)
|}

== Curve Speed advantage multiplier (11) ==

This property sets the multiplier to the curve speed advantage which all trains running on this track type get. The base curve speed advantage is given by the multiplication of the value of this property with the base speed advantage - which depends on the curve length in wagons:

{| class="wikitable"
|-
!'''Curve Length'''
!'''Base Speed Adv.'''
|-
|0 (90° turn)
|30
|-
|1 (2x45° turn)
|44
|-
|2
| 55
|-
|3
| 66
|-
|4
| 75
|-
|5
| 84
|-
|6
| 91
|-
|7
| 98
|-
|8
| 103
|-
|9
| 108
|-
|10
| 111
|-
|11
| 114
|-
|12+
| 115
|}

"Curve length" is the average number of wagons of the train between turns. However, very sharp turns (values 0 and 1) are not averaged out in longer trains.

The maximum speed for a train in a curve is defined by "base speed advantage" * (2 + "property 11"). Tilting trains get an additional bonus of 20% to this value.

For the default rail types this property is 0 for normal rail and electrified rail, 1 for monorail, and 2 for maglev.

== Station (and depot) graphics (12) ==

This property defines the default graphics for the stations. If no depot sprites are defined, this also defines at the same time the depot sprites to be used. There are three kind of default stations (and depots), usually associated with rail, monorail and maglev tracks. Valid values are:

{| class="wikitable"
|-
!'''Value'''
!'''Meaning'''
|-
|0
|Normal Rail
|-
|1
|Monorail
|-
|2
|Maglev
|}

== Speed limit (14) ==

Speed limit in mph*1.6 (approx. km/h). Set to "0" for no limit at all.

== Acceleration model (15) ==

This property defines the acceleration model used. Valid values range from 0 to 2:

{| class="wikitable"
|-
!'''Value'''
!'''Meaning'''
|-
|0
|Normal Rail
|-
|1
|Monorail
|-
|2
|Maglev
|}

There is currently no difference between normal rail and monorail.

== Map colour (16) ==

This property defines the colour this track type is drawn in the minimap view. The byte value specifies the colour entry in the [[PalettesAndCoordinates|DOS palette]].

== Introduction date (17) ==

This property defines the long date formatted introduction date of this rail type. With this property set the rail type will be introduced at (or after) this date when all of the introduction required rail types are available to the company of the player, or whenever a vehicle using this rail type gets introduced whichever is first.

== Introduction required rail type list (18) ==

List of rail types on that need to be available to the company of the player for this rail type to be introduced at (or after) the introduction date. This limit does not apply when the rail type is introduced by the introduction of a vehicle.

Same format as for property 0E above.

This can, for example, be used to introduce a third rail with catenary track type when both third rail and catenary rail types are available.

== Introduced rail type list (19) ==

List of rail types that get introduced when this rail type is introduced. For example, to make sure that when a fast rail type is introduced the slow variant exists.

Same format as for property 0E above.

== Sort order (1A) ==

Property for influencing the sort order of the drop down lists with rail types. Default values are as follows:

{| class="wikitable"
|-
!'''Value'''
!'''Meaning'''
|-
|07
|Normal Rail
|-
|17
|Electrified Rail
|-
|27
|Monorail
|-
|37
|Maglev
|-
|n7
|Railtype #n
|}

Thus the rail type that (internally) gets index 8 will get a default value of 87. These defaults are to keep the ordering when this property is not supported as they were.

== Rail type name (1B) ==

String ID of the name of the rail type.

{{grfTill|7}} For GRF versions 7 or earlier, set property 1B ''after'' setting property 09, as property 09 sets the rail type name as well for backwards compatibility.

== Alternate rail type labels (1D) ==

A list of alternate labels that get "redirected" to this rail type when used e.g. as track type of train or when testing if a label is defined. The redirection only happens if the alternate label isn't defined as a real rail type. Same format as for property 0E above.

Alternate labels are not considered when evaluating properties 0E, 0F, 18, and 19.

= Example =

To be written

Storages

2018-09-02T19:50:35Z

Michi cc: Larger persistent storage for OTTD.

==Introduction==

Storages are arrays of registers that can be accessed when using [[VariationalAction2]]. Registers (temporary and persistent alike) always have a size of 4 bytes. If you're writing them using smaller sizes (anything but type 89/8A), the given value will be sign-extended to 4 bytes. Therefore, be careful when you read a register using a bigger size than it was written with. This also applies to registers read by TTDPatch; if not indicated specifically, TTDPatch reads all 4 bytes of the register.

==Description==
===Temporary storage===
{{ottdp|0.6|2.6}}

'''Size:''' 00 - FF (256) (from TTDPatch r1246 to r1301) or 00 - 10F (272) (since TTDPatch r1301 and OpenTTD r9707)

'''Data storage:''' [[VarAction2Advanced#operator|Operator \2sto (0E)]] allows to store values inside the registers of this storage.

'''Data access:''' The first 256 registers 00 to FF can be read using [[VariationalAction2#Variable|variable 7D]]. The rest of the values (100 to 10F) are write only: they are used to pass extra data to some 4x and 6x variables, as well as for returning extra data from callbacks.

Temporary storage contains values local to the current [[VariationalAction2]] chain. When a new chain starts, the values inside the temporary storage are undefined. Therefore, they should not be used unless they have been properly initialized. During the execution of a chain, only that chain can modify the values in the temporary storage.

===Persistent storage===
{{ottdp|0.6|2.6}}

'''Size:''' 00 - 0F (16) or 00 - FF (256) (since {{ottd|1.9|6391d49}})

'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage.

'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7C]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]).

'''Features that support it:''' Industries (0A)

Persistent storage is associated to a single item. When the item is created, all of the values of the persistent storage are set to zero. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.

===Persistent storage accessed by GRFID===
{{ottdp|1.2|ottdrev=r22569}}

'''Size:''' 00 - 0F (16) or 00 - FF (256) (since {{ottd|1.9|6391d49}}) for each GRFID

'''Data storage:''' [[VarAction2Advanced#operator|Operator \2psto (10)]] allows to store values inside the registers of this storage. The GRFID to access must be stored in temporary register 0x100 before using Operator 10. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.

'''Data access:''' The registers can be read using [[VariationalAction2#Variable|variable 7C]]. Note that it is possible to access the persistent storage of related objects (see [[VariationalAction2#Type]]). The GRFID to access must be stored in temporary register 0x100 before checking variable 7C. 0xFFFFFFFF can be used to access the GRFID of the item using the current [[VariationalAction2]] chain.

'''Features that support it:''' Towns (since OpenTTD r22569)

Features supporting persistent storage accessed by GRFID are not restricted to a single persistent storage; there is a persistent storage associated to every GRFID. An item only has write access to the persistent storage associated to its own GRFID, but it can read the registers of any GRFID. Persistent storage values cannot be accessed or modified by items that are being created. Persistent storage should not be read if the current feature doesn't support it.

TTDPatchFlags

2018-09-02T19:43:54Z

Michi cc: Larger persistent storage for OTTD.

In the table below you find all the TTDPatch flags that belong to <param-num> = 85 in Action 7 and Action 9.

{| |-
!'''Bit'''!!'''Switch (bit set = switch on)'''!!'''Correspondence in OpenTTD'''
|-
|0C||keepsmallairport||station.never_expire_airports
|-
|0D||newairports||1
|-
|0E||largestations||1
|-
|0F||longbridges||construction.longbridges
|-
|10||loadtime||0
|-
|12||presignals||1
|-
|13||extpresignals||1
|-
|16||enginespersist||vehicles.never_expire_vehicles
|-
|1B||multihead||1
|-
|1D||lowmemory||1
|-
|1E||generalfixes||1
|-
|27||moreairports||economy.station_noise_level
|-
|28||mammothtrains||1
|-
|29||trainrefit||1
|-
|2B||subsidiaries||0
|-
|2C||gradualloading||order.gradual_loading
|-
|32||(Set to bit 0 of unifiedmaglev mode)||1 (n/a)
|-
|33||(Set to bit 1 of unifiedmaglev mode)||1 (n/a)
|-
|34||bridgespeedlimits||1
|-
|36||eternalgame||1
|-
|37||newtrains||1
|-
|38||newrvs||1
|-
|39||newships||1
|-
|3A||newplanes||1
|-
|3B||signalsontrafficside||construction.signal_side
|-
|3C||electrifiedrailway||vehicle.disable_elrails
|-
|41 <ref>loadallgraphics is obsolete (and its bit unused) since revision 401. The next official versions were the 5/Jun/2006 nightly (402) and TTDPatch 2.5 beta 6 (472)</ref>||loadallgraphics||1
|-
|43||semaphores||1
|-
|4A||newobjects (since r2364)||1
|-
|4B||enhancegui||0
|-
|4C||newagerating||0
|-
|4D||buildonslopes||construction.build_on_slopes
|-
|4E||fullloadany||1
|-
|4F||planespeed||1
|-
|50 <ref>moreindustriesperclimate is obsolete (and its bit unused) since TTDPatch 2.5 beta 2.</ref>||moreindustriesperclimate||0
|-
|51||moretoylandfeatures||0
|-
|52||newstations||1
|-
|53||tracktypecostdiff||1
|-
|54||manualconvert||1
|-
|55||buildoncoasts||construction.build_on_slopes
|-
|56||canals||1
|-
|57||newstartyear||1
|-
|58||freighttrains||vehicle.freight_trains > 1
|-
|59||newhouses||1
|-
|5A||newbridges||1
|-
|5B||newtownnames||1
|-
|5C||moreanimation||1
|-
|5D||wagonspeedlimits||vehicle.wagon_speed_limits
|-
|5E||newshistory||1
|-
|5F||custombridgeheads||0
|-
|60||newcargodistribution||0
|-
|61||windowsnap||1
|-
|62||townbuildnoroads||not (economy.allow_town_roads or _generating_world)
|-
|63||pathbasedsignalling||1
|-
|64||aichoosechances||0
|-
|65||resolutionwidth||1
|-
|66||resolutionheight||1
|-
|67||newindustries||1
|-
|68||fifoloading||order.improved_load
|-
|69||townroadbranchprob||0
|-
|6A||tempsnowline||0
|-
|6B||newcargos||1
|-
|6C||enhancemultiplayer||1
|-
|6D||onewayroads||1
|-
|6E||irregularstations||1
|-
|6F||morestatistics||1
|-
|70||newsounds||1
|-
|71||autoreplace||1
|-
|72||autoslope||1
|-
|73||followvehicle||0
|-
|74||trams||1
|-
|75||enhancetunnels||0
|-
|76||shortrvs||1
|-
|77||articulatedrvs||1
|-
|78||dynamicengines||vehicle.dynamic_engines, since r12924
|-
|7E||variablerunningcosts (since r1421)||1
|-
|7F||set if any switches are on||1
|-
|80||-||1 (larger persistent storage, since 6391d49)
|}

<references />

Standardized Railtype Scheme

2012-12-20T16:01:35Z

Michi cc: /* Speed limit class [*X**] */ Clarify use of eyecandy track classes

This railtype label scheme aims to bring order to the uncontrolled growth of railtype labels. It groups the rail types into what matters from a technical perspective. The scheme provides a standardized way of defining railtype labels, based on track gauge and type, speed class, allowable axle weight and electrification type.

It is the explicit intent of this scheme to decouple track sets from vehicle sets to facilitate easy mixing. This way the player can select a track set of choice to go with a train set of choice. It allows the player to play with or without axle load classes, or with or without speed limit classes, simply by loading a track set that does or does not provide these features. In some cases it will also be possible to combine niche track sets, for instance a standard gauge track set with a narrow gauge and a metro track set.

== The Label Scheme ==
A railtype label consists of four characters. In this scheme, each position has a different purpose:
# Track gauge and type class (e.g. standard gauge rail, narrow gauge rail, monorail)
# Speed limit class
# Axle load class (maximum allowed axle weight for this track)
# Energy source type class

In the next sections, each of the four positions will be explained.

=== Track gauge and type class [X***] ===
The first position in the railtype label defines track gauge and/or track type class. The following classes are currently defined:

{|
! !!Track type/gauge
|-
|S ||Standard gauge rail
|-
|B ||Broad gauge rail
|-
|N ||Narrow gauge rail
|-
|n ||Secondary narrow gauge rail (e.g. when providing both metre and cape gauge, always use N in case of just one type of narrow gauge)
|-
|D ||Dual gauge rail, standard+broad gauge
|-
|d ||Dual gauge rail, standard+narrow gauge
|-
|M ||Monorail
|-
|L ||Magnetic Levitation
|}

=== Speed limit class [*X**] ===
The second position in the railtype label defines the speed limit class. These classes do not map to a fixed numeric value, but are used to define an internal speed limit order for the track set. This means that if your track set has two different speed limits for track types that are otherwise identical, you'll use letters A and B here. In case of three different speed limits, use A, B and C. In case your track set does not employ speed limits, always use A. Train sets do not care about the speed limit, and will always set the lowest speed class, i.e. A.

This gives for instance the following options:

<div style="float:left;">
<div style="float:left;">
{|
! !!Speed limit class
|-
|A ||no speed limits
|}
</div>
<div style="float:left;">
 OR 
</div>
</div>
<div style="float:left;">
<div style="float:left;">
{|
! !!Speed limit class
|-
|A ||low speed
|-
|B ||high speed
|}
</div>
<div style="float:left;">
 OR 
</div>
</div>
<div style="float:left;">
<div style="float:left;">
{|
! !!Speed limit class
|-
|A ||low speed
|-
|B ||medium speed
|-
|C ||high speed
|}
</div>
<div style="float:left;">
 etc. 
</div>
</div>
<div style="clear:left;"></div>

The speed limit class may also be used for some advanced features of the label scheme, like specialized track types and eyecandy purposes. Be careful not to break the compatibility with other sets when using the speed limit class for these purposes.

An example of a special use is rack rail. In the French set it is used to give rack rail engines a higher speed and TE than normal rail engines when used on rack rail. When defining trains with a special speed limit class, always allow a fallback to speed limit class A via the railtype table.

An example of eyecandy use are urban tracks. These are a variation of regular tracks, but with concrete ground tiles to better match the urban environment. Train sets must not define vehicles for eyecandy classes. If you think you have special vehicles that should only run on the eyecandy class, it is ''not'' eyecandy but a separate track gauge/type.

The following special and eyecandy classes have been defined so far:

{|
! !!Description !!Type !!Used by
|-
|A-H ||speed limits ||colspan="2"|reserved
|-
|R ||rack rail ||special ||French Set Rails
|-
|S ||subterranean ||eyecandy ||Metro Track Set
|-
|U ||urban ||eyecandy ||Metro Track Set
|}

=== Axle load class [**X*] ===
The third position defines the axle weight limit. Heavy trains cannot run on tracks with a low axle weight limit; these trains need more expensive tracks with a heigher weight limit. There are five axle load classes '''A''' through '''E'''. '''A''' is for the lowest axle load limit, '''E''' for the highest. The exact axle load attached to each class is relative to the track gauge/type and trains in the set.

A train set should set the appropriate axle weight for each train via the railtype label, as to make the set work with track sets that do provide tracks with different weight limits, even if you don't care about it for your trainset. Split all vehicles of a certain track gauge/type into five groups of similar axle weight. The group with the lowest axle weights will get class '''A''', the second lowest class '''B''', etc. up to the group with the highest axle weights which will get class '''E'''. Do the same for the other track gauge/types if your train set has those.

A track set does not have to provide a dedicated track type for each axle weight limit. A track set that does not provide a dedicated track for each axle load class, must make sure to map all undefined axle load classes to a real railtype using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]]. This way a train set can rely on all labels for all axle load classes being available. Example: if you only want to provide 2 axle load classes for standard gauge unelectrified with no speed limits, you can map SA'''A'''N + SA'''B'''N to SA'''C'''N and SA'''D'''N to SA'''E'''N if the cost difference between the two railtypes is high, or SA'''A'''N to SA'''B'''N and SA'''C'''N + SA'''D'''N to SA'''E'''N if the cost difference is low.

If you don't want to provide any axle load classes in your track set, it doesn't really matter what axle load class you choose for the track, as you'll be mapping all other classes to this track anyways. But the lowest or highest class are the obvious choice. Example: if your track set only provides narrow gauge unelectrified track with no speed limits and no axle load limits, you may use NA'''A'''N for the track label, and provide NA'''B'''N, NA'''C'''N, NA'''D'''N, NA'''E'''N in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

If you need more than five axle load class, you may use lowercase letters for very low axle loads and continue the uppercase letters for very high axle loads. Be advised that your train set may not assume the existance of any other class than '''A''' through '''E''', so when the range make sure to program your railtype table such that trains with such a class will fall back to class '''A''' or '''E'''. If you make a track set with an extended range, be aware that not all train sets will define trains for these tracks. In general: only do this in case of a train set with a matching track set.

For the lowercase letters, '''b''' is lower than '''a''', so for increasing axle load limits: b < a < A < B < C etc.

Note that the axle load classes never map to a specific weight in tonnes. For that reason it does not make sense to add a numeric value for the axle load to the name of a track type or in the extended purchase info of a train. Instead use the relative expressions 'very low', 'low', 'medium', 'high' and 'very high' or use the class letters directly.

=== Energy source type class [***X] ===
The last position defines the energy source type class. This is split in generic energy source types like overhead wires and third rail and specialized types like alternating and direct current.

A track set that only uses specialized types, should map the generic types to the most suitable specialized type in the set.

A vehicle set that uses specialized types should define a generic type as fallback, via the railtype table. If such a fallback is omitted, please note that certain vehicles may be unavailable depending on track set loaded.

{|
! !!Generic energy type classes
|-
|N ||no electrification
|-
|E ||overhead wires/catenary electrification
|-
|3 ||3rd rail electrification
|}

{|
! !!Specialized energy type classes !!Vehicle set fallback
|-
|Z ||3rd rail and catenary electrification || 3 or E
|-
|4 ||4th rail electrification || 3
|-
|T ||[http://en.wikipedia.org/wiki/Three-phase_AC_railway_electrification three phase AC electrification] || E
|-
| colspan="3" |  
|-
|D ||DC catenary electrification || E
|-
|d ||low voltage DC catenary electrification (only when D also used in set) || E
|-
|A ||AC catenary electrification || E
|-
|a ||low voltage AC catenary electrification (only when A also used in set) || E
|}

If you want multi-voltage/current vehicles in your set (i.e. a train that can run on both AC and DC current), you have to define a dedicated railtype for those vehicles. Without the railtype, it's not possible to define vehicles with this property. If you only have vehicles that can run on either one type of voltage/current or on all types of voltage/current (e.g. a 2-system if you only have '''A''' and '''D''' tracks, or a 4-system in case of all '''A''', '''a''', '''D''' and '''d'''), then use the generic class '''E''' for vehicles that should be able to run on all different voltage/currents. Also the track set needs to have one at least one railtype with class '''E''' defined.

Note that if you want more than one type of multi-voltage/current, you'll quickly get a combinatory explosion of railtype labels, so plan carefully or do not attempt it. For every different multi-voltage/current vehicle type a dedicated railtype is needed. If you want all possible combinations, then you need to define an additional 8 classes. It is not recommended to make your train/track set this complicated.

Example approach for a 4-system set, with trains that can run on either one or all systems:
* '''E''': generic catenary-powered electric engines. "universal" [4-system] if any of '''D'''/'''d'''/'''A'''/'''a''' are defined.
* '''A''': generic AC catenary electric engines. 25kV only if '''a''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''A''';
* '''a''': 15kV AC catenary electric engines. Only defined if '''A''' also defined. Vehicle sets should use '''A''' and '''E''' as fallback, if defining an engine for '''a''';
* '''D''': generic DC catenary electric engines. 3kV if '''d''' also defined. Vehicle sets should use '''E''' as fallback, if defining an engine for '''D''';
* '''d''': 1.5kV DC catenary electric engines. Only defined if '''D''' also defined. Vehicle sets should use '''D''' and '''E''' as fallback, if defining an engine for '''d'''.
For a 2-system set, you can simply drop '''a''' and '''d'''.

=== Standard labels: RAIL, ELRL, MONO, MGLV ===
It's not possible to undefine the standard railtypes RAIL, ELRL, MONO and MGLV. The game will always add those if there are vehicles defined for these track types. As a result, for a track set it's best not to ignore those standard labels, but rather work with them and define them in the set. If your track set does not have monorail or maglev tracks, there of course is no need to define those. But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels. Matching labels from the above scheme will then be defined in property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

As vehicles from NewGRFs that do not use explicit railtypes will end up on these standard railtypes, you should use RAIL instead of whatever type could be regarded as the most commonly used unelectrified type, ELRL instead of the most commonly used electrified type and so on. The label according to this scheme is then set as an alternate.

== Summary for track sets ==
This section summarizes the above for track sets.

; [X***] Track gauge and type class
* Define at least one track type for every track gauge/type class you want in your set.
* If you only provide tracks for one gauge/type, consider leaving some free railtypes so a player can load an additional set for some other type.
; [*X**] Speed limit class
* Make sure class A is always available, either directly or via an alternate label.
* Use only class A if you don't want speed limits;
* With speed limits, A is the lowest speed limit. Continue with B, C, etc. for increasing speed limits;
* The speed class can also be used to implement additional eye-candy track types, use letters higher in the alphabet for this.
; [**X*] Axle load class
* Always define all classes A through E for every track type class / electrification combination, either:
** Directly via a real railtype definition;
** Indirectly via the alternate rail type label list, property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].
* Extend the predefined classes only if you also provide a train set that makes use of these.
; [***X] Energy source type class
* If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via property 1D.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Always define the standard labels when possible, instead of what would be the equivalent of the standard label in this scheme.
* Map the equivalent labels from this scheme to the standard labels using property [[Action0/Railtypes#Alternate_rail_type_labels_.281D.29|1D (NFO)]] or [[NML:Railtypes#Railtype_properties|alternative_railtype_list (NML)]].

Or, put differently, for each gauge/type, select one or more energy source types. For each type/energy combination provide all axle load classes for the speed class "A", either as a real type or as an alternate of another type. Provide more types with a different speed letter if you want to provide several different speeds or other eye-candy tracks.

== Summary for train sets ==
This section summarizes the above for train sets.

; [X***] Track gauge and type class
* Use the track type class that matches the vehicle;
* Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded.
** Specialized subtypes like "n" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "N").
; [*X**] Speed limit class
* Always use class A for every vehicle.
; [**X*] Axle load class
* Use all classes A through E according to the maximum axle weight of the vehicle.
* Extend the predefined classes only if you also provide a track set that makes use of these;
** When extending the predefined classes A through E, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; [***X] Energy source type class
* Use the energy source type class that matches the vehicle;
* When using specialized classes, define a fallback type via the railtype table in case you want the vehicle to be available if no matching track set is loaded.
; Standard labels [RAIL, ELRL, MONO, MGLV]
* Define a fallback type to the standard labels via the railtype table in case you want the vehicle to be available on the standard tracks if no matching track set is loaded.

Be as specific as you want when selecting the railtype, it is the job of the track set to select a playable, reduced subset out of all possible type combinations.

== In case you're not convinced by this scheme ==
Adopting this scheme gives the player freedom to use any track set in combination with any train set that follow the scheme.

This means that you can make your train set compatible with track sets that provide axle load classes, and track sets that provide speed limits, and at the same time with track sets that provide none of this. This way, the player can decide to play with or without axle load classes, or with or without speed limits, simply by loading a track set that does or does not provide these features.

And for your track set, it means that you can make it as simple or as complicated as you want (within the 16 track type limit), while not having to worry about compatibility with train sets.

Still not convinced? Feel free to use railtype labels of your own, but know that you will likely come to regret that at some point in the future.

==Forum topic==
If you want to discuss the standardized railtype scheme or have any questions about it, you can visit [http://www.tt-forums.net/viewtopic.php?t=59379 the forum topic].

GlobalVariables

2012-07-08T18:49:58Z

Michi cc: /* Misc. GRF Features (1E / 9E) */ Ambient sound effects are support by OTTD for some time now.

== Overview ==
{|
!colspan=3|'''Variable'''
!rowspan=2|[[GRFActionsDetailed|'''Size''']]
!rowspan=2|'''Versions'''
!rowspan=2|'''Description'''
|-
|[[VariationalAction2 | VA2]]||A[[Action6|6]]/[[Action7|7]]/[[Action9|9]]/[[ActionD|D]]<br>(read)||[[ActionD|ActD]]<br>(write)
|-
|00||80|| ||W||{{ottdp|0.6|2.0}}||current date (counted as days from 1920)<ref name="startdate">{{ottdp|0.7}} In multiplayer games OpenTTD doesn't report the current date and year to actions 6,7,9 and D, but the date and year the game was loaded. The reason lies in the fact that it was seen that use of this variable leads to desyncs in network games.</ref>
|-
|01||81|| ||B||{{ottdp|0.6|2.0}}|| Current year (count from 1920, max. 2175 even with eternalgame)<ref name="startdate"/>
|-
|02||82|| ||B/D||{{ottdp|0.6|2.0}}|| current month (0-11) in bits 0-7; the higher bytes contain unusable junk.<ref name="startdate"/><br/>{{ottdp|0.7|ottdrev=r13594}} Since OpenTTD r13594 'day of month' (0-30) is stored in bits 8-12, bit 15 is set in leapyears and 'day of year'(0-364 resp. 365) is stored in bits 16-24. All other bits are reserved and should be masked.
|-
|03||83|| ||B||{{ottdp|0.6|2.0}}|| Current climate: 00 = temp, 01 = arctic, 02 = trop, 03 = toyland
|-
| ||84|| ||D||{{ottdp|0.6|2.0}}|| [[GrfLoadingStages|GRF loading stage]], see [[#GRF_Loading_stage_.28-_.2F_84.29|below]]
|-
| ||85|| ||B||{{ottdp|0.6|2.0}}|| [[TTDPatchFlags|TTDPatch flags]]: only for bit tests
|-
|06||86|| ||B||{{ottdp|0.6|2.0}}|| Road traffic side: bit 4 clear=left, set=right; other bits are reserved and must be masked.
|-
| ||(87)||(87)||B||{{ottdp|no|no}}|| No longer used since TTDPatch 2.0. (was width of "€" character)
|-
| ||88|| ||4*B||{{ottdp|0.6|2.0}}|| Checks specified GRFID (see [[Action7#condition-type|condition-types]])<ref>The value of variable 88 can only be tested with the GRFID tests.</ref>
|-
|09||89|| ||W||{{ottdp|0.6|2.0}}|| date fraction, incremented by 0x375 every engine tick
|-
|0A||8A|| ||W||{{ottdp|0.6|2.0}}|| animation counter, incremented every tick
|-
|0B||8B|| ||D||{{ottdp|no|2.0}}|| [[Version_numbers#TTDPatch_version|TTDPatch version]], see [[#TTDPatch_Version_.280B_.2F_8B.29|below]] <ref>OpenTTD reports some arbitrary TTDPatch 2.6 version number to make old GRFs work, which do not know about OpenTTD. Do not rely on this for new NewGRFs.</ref><ref name="versionchecks">It is generally not useful to check version variables using Action 7. If you want to skip certain actions which are incompatible to some versions, you want to skip them during all loading stages. So, use Action 9.</ref>
|-
|0C|| || ||W||{{ottdp|0.6|2.5}}|| current [[Callbacks|callback]] ID (feature-specific), set to 00 when not in a callback
|-
|0D||8D|| ||B||{{ottdp|0.6|2.5}}|| TTD version, 0=DOS, 1=Windows
|-
|0E||8E||8E||B||{{ottdp|0.6|2.5}}|| Y-Offset for train sprites
|-
|0F||8F||8F||3*B||{{ottdp|0.6|2.5}}|| Rail track type cost factors
|-
|10|| || ||D||{{ottdp|0.6|2.5}}|| Extra callback info 1, see [[#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|below]].
|-
|11|| || ||B||{{ottdp|no|2.5}}|| current rail tool type (for station callbacks)
|-
|12||92|| ||B||{{ottdp|0.6|2.5}}|| Game mode, 0 in title screen, 1 in game and 2 in editor
|-
|13||93||93||W||{{ottdp|no|2.5|ttdprev=2.0.1 alpha 39}}|| Tile refresh offset to left <ref name="tilefresh">See [[ActionD#Tile+refresh+offsets|Action D]] for more details on tile refresh offsets and their use.</ref>
|-
|14||94||94||W||{{ottdp|no|2.5|ttdprev=2.0.1 alpha 39}}|| Tile refresh offset to right <ref name="tilefresh"/>
|-
|15||95||95||W||{{ottdp|no|2.5|ttdprev=2.0.1 alpha 39}}|| Tile refresh offset upwards <ref name="tilefresh"/>
|-
|16||96||96||W||{{ottdp|no|2.5|ttdprev=2.0.1 alpha 39}}|| Tile refresh offset downwards <ref name="tilefresh"/>
|-
| ||97||97||B||{{ottdp|no|2.5}}|| Fixed snow line height <ref>This variable is a deprecated way to set the snow line height via NewGRFs using [[ActionD]]. It is superseded by the [[Action0/Global Settings#Snow_line_height_table_.2810.29 | Action 0 snow line height table]]. To read the current snow line with [[VariationalAction2 | VarAct2]] in a running game, use variable 20 instead.</ref><ref name="heightlevel">{{grfTill|7}} For GRF version 7 and below these variable are multiples of 8; {{grfFrom|8}} for GRF version 8 and above they directly state the heightlevel as multiple of 1.</ref>
|-
|18|| || ||D||{{ottdp|0.6|2.5}}|| Extra callback info 2, see [[#Extra_callback_info_.2810_.2F_-.29_and_.2818_.2F_-.29|below]].
|-
| ||99||99||D||{{ottdp|no|2.5}}|| Global ID offset
|-
|1A||9A|| ||D||{{ottdp|0.6|2.5}}|| Has always all bits set; you can use this to make unconditional jumps
|-
|1B|| || ||B||{{ottdp|no|2.5}}|| display options; bit 0=town names, 1=station names, 2=signs, 3=animation, 4=transparency, 5=full detail
|-
|1C|| || ||D||{{ottdp|0.6|2.5}}|| result from most recent VarAction2
|-
|1D||9D|| ||D||{{ottdp|0.6|2.5}}|| TTD Platform, 0=TTDPatch, 1=OpenTTD <ref name="versionchecks"/>
|-
|1E||9E||9E||D||{{ottdp|0.6|2.5}}|| Misc. GRF Features
|-
| || ||9F||D||{{ottdp|no|2.5}}|| writable only: Locale-dependent settings
|-
|20|| || ||B||{{ottdp|0.6|2.5}}|| Current snow line height, FFh if snow isn't present at all <ref name="heightlevel"/>
|-
|21||A1|| ||D||{{ottdp|0.6|no}}|| [[Version_numbers#OpenTTD_version|OpenTTD version]], see [[#OpenTTD_Version_.2821_.2F_A1.29|below]]. <ref name="versionchecks"/>
|-
|22||A2|| ||D||{{ottdp|0.7|2.6|ottdrev=r12499|ttdprev=r1857}}|| Difficulty level: 00= easy, 01=medium, 02=hard, 03=custom
|-
|23||A3|| ||D||{{ottdp|0.7|2.6|ottdrev=r13376|ttdpref=r2048}}|| Current date long format
|-
|24||A4|| ||D|||{{ottdp|0.7|2.6|ottdrev=r13376|ttdprev=r2048}}|| Current year zero based
|-
|25|| || ||D||{{ottdp|0.7|ottdrev=r15739}}|| GRFID of the grf that contains the corresponding Action3. Useful when accessing the "related" object. Currently only supported for vehicles.
|}

All other variable numbers are reserved and must not be used.

<references/>

== Special variables ==

=== GRF Loading stage (- / 84) ===

Variable 84 is a BYTE variable up to TTDPatch 2.5r1220. Its lower byte (bits 0..7) are 0 for the post-load and GRF initialization stages and 01 for all other stages. The remaining bits are a bitmask, and including the lower byte have the following meaning:
{|
!Bit!!Version!!Meaning
|-
|0||{{ottdp|0.6|2.0}}||Set after the "Initialization" stage completes
|-
|1..7||{{ottdp|0.6|2.0}}||Always clear
|-
|8||{{ottdp|0.6|2.5|ttdprev=r1220}}||Set during the "Reserve" stage only
|-
|9||{{ottdp|0.6|2.5|ttdprev=r1220}}||Set during the "Activate" stage only
|-
|10||{{ottdp|0.6|2.5|ttdprev=r1220}}||Set during the "Test" stage only
|-
|11..15|| || Reserved. Do not test for them.
|}

=== TTDPatch Version (0B / 8B) ===
Variable 8B has the following format: MMmrbbbb (though encoded in little endian as bb bb mr MM)
{|
!Element!!Meaning!!Value
|-
|MM||major||First number of the [[Version_numbers#TTDPatch_version|TTDPatch version]]
|-
|m||minor||Second number of the TTDPatch version
|-
|r||revision||Third number of the TTDPatch version<ref name="rev">For TTDPatch 2.0, r=7 and for TTDPatch 2.0.1 series, r=10 due to an oversight which used r=1..4 for TTDPatch 2.0 beta 1..4.</ref>
|-
|bbbb||build||Alpha/beta version number times ten (up to an including TTDPatch 2.5 beta 5), SVN revision (from TTDPatch 2.5 beta 5 r418 on)
|}

Examples
{|
!Version!!Variable 8B!!Elements
|-
|1.9.1 alpha 50||019101F4|| MM=01, m=9, r=1, bbbb=50*10=01F4
|-
|2.0 beta 4||02040028||MM=02, m=0, r=4<ref name="rev"/>, bbbb=4*10=0028
|-
|2.0 final||02070046||MM=02, m=0, r=7<ref name="rev"/>, bbbb=70=0046
|-
|2.0 rev 1||02070050||MM=02, m=0, r=7<ref name="rev"/>, bbbb=80=0050
|-
|2.0.1 alpha 3||020A001E||MM=02, m=0, r=10<ref name="rev"/>, bbbb=3*10=001E
|-
|2.5 beta 2||02500014||MM=02, m=5, r=0, bbbb=2*10=0014
|-
|2.5 rev631||02500631||MM=02, m=5, r=0, bbbb=631=0631
|}

<references/>

To detect versions from TTDPatch 2.5 rev419 and up correctly, check that var. 8B is 02500419 or higher, or replace 0419 with the actual required revision (using the revision number as hex digits). Because SVN revisions are shared with other patch branches, it is important to check the actual patch version as well as the SVN revision.

=== Y-Offset for train sprites (0E / 8E) ===

Since train sprites must normally have the same offsets on the map and in the depot view, they will appear either too low on the map or too high in the depot view. This variable moves all vehicles in the depot view down by this many pixels.

{{ottdp|1.0|no|ottdrev=r16867}} Since OpenTTD r16867 this variable works per grf file, that is: It only affects trains defined in the same grf.

=== Rail track type cost factors (0F / 8F) ===

This variable is a collection of three bytes that are used as multipliers for track costs when the "trackcostdiff" switch is on. The value of 08 is the baseline value that is used by standard TTD.

The defaults are the following:

{|
!Values!!Track types!!Electrified railways setting

|-
|08, 10, 18||Regular, Monorail, Maglev||off

|-
|08, 0D, 10||Regular, Electric, Monorail/Maglev||on
|}

=== Extra callback info (10 / -) and (18 / -) ===
These variables have callback specific meanings. They are described along the individual [[callbacks]].

Additionally they are used outside of callbacks for these special purposes:
{| |-
! [[Features|Feature]] !! Usage
|-
| Vehicles || Used to distinguish drawing of vehicles in the GUI or on the map. See [[Action2/Vehicles#Introduction|Action2]].
|-
| Stations || Used to compose station tiles with sprites from different Action-1-2-3 chains, or to draw custom foundations. See [[Action0/Stations#General_Flags_.2813.29|General station flags]] and [[AdvancedSpriteLayout]].
|-
| Railtypes || Used to distinguish between the type of tunnel portal or signal requested. See [[Action3/Railtypes#Tunnel_portal_overlay_.280A.29|Railtype tunnel portal overlay]] or [[Action3/Railtypes#Signal_sprites_.280B.29|Railtype signal sprites]] for details, respectively.
|}

=== Tile refresh offsets (13,14,15,16 / 93,94,95,96) ===

These four offsets define the size and position of the rectangle refreshed when TTD decides to refresh a tile. The basis of the calculations is the pixel coordinate of the north corner of the tile.

After calculating it, TTD subtracts offset_left from it to get the x coordinate of the left edge, adds offset_right to get the x coordinate of the right edge, subtracts offset_up to get the y coordinate of the top edge and adds offset_down to get the y coordinate of the bottom edge. This results in refreshing (offset_left+offset_right)*(offset_up+offset_down) pixels. The default values of these variables are 31, 36, 122 and 32, respectively.

Reading these values is not too useful, but you can modify them using action D as well, so your sprites that would exceed the original limits can still be redrawn and animated properly. Please note that TTD uses these values for every tile, so specifying too high values may slow the game down. Please also note that these variables are specified as dwords for technical reasons, but only the bottom word will be used.

Since these values are global to the entire game, you shouldn't just overwrite them with an action D. Instead, you should first check if they're big enough for you by using action 7, and skip your action D if they are. This way, the variables will be set to the maximal value needed, not just the value needed for the last grf in the list.

=== Snow line height (- / 97) ===

This is only active if the tempsnowline switch is on. It defaults to FF (no snow) and 38 (GRF version < 8) resp. 07 (GRF version >= 8) in the temperate and arctic climates, respectively.

{{grfTill|7}} For GRF version 7 and below it must be set to a multiple of 8, which is one level of height difference.

{{grfFrom|8}} For GRF version 8 and above the heightlevel is set directly as multiple of 1.

=== Global ID offset (- / 99) ===

Setting this variable will add the given value to all the relevant IDs in subsequent action 0, action 3 (''except'' livery overrides), action 4 (''except'' generic texts) and action A entries. This is a more convenient way of applying the result of a GRF resource request. Setting this variable applies only to the current .grf file only.

In detail, it affects the following elements:

{|
!Action!!Element modified

|-
|0||<tt><Id></tt> (i.e., not property numbers)

|-
|3||<tt><Ids...></tt> (i.e., not cargo types or cargo IDs, also not for livery overrides)

|-
|4||<tt><Offset></tt> (not for generic texts, though)

|-
|A||<tt><First-sprite></tt>
|}

=== Display options (1B / -) ===
The definition of variable 1B is slightly feature-dependent. For features that can be drawn transparently (stations, bridges, houses, industry tiles and objects) bit 4 is set if the current feature will be drawn normally, and clear if the current feature will be drawn transparently. For these purposes, airports are stations. For all other features, bit 4 is undefined.

=== Misc. GRF Features (1E / 9E) ===

This variable is a global bit mask of various patch features a grf file can enable. Please only set the bits using operation 08 (bitwise OR), or, if absolutely necessary, remove certain bits with operation 07 (bitwise AND). This ensures that you don't mess up the settings of other grf files.

{|
!Bit!!Value!!Version!!Feature

|-
|0||1||{{ottdp|no|2.5}}||Allow trees and fields in the desert
|-
|1||2||{{ottdp|0.6|2.5}}||Show pavement and lights in desert towns
|-
|2||4||{{ottdp|no|2.5}}||Fields have a height, using a 3D bounding box
|-
|3||8||{{ottdp|0.6|2.5}}||Display train vehicles with full width of 32 pixels in depot window (instead of 29 pixels)<ref>Since {{ottdp|1.0|no|ottdrev=r16867}} this flag works per grf file, that is: It only affects trains defined in the same GRF.</ref>
|-
|4||10||{{ottdp|1.2|2.6|ottdrev=r23114|ttdprev=r821}}||Enable ambient sound effect callback 144
|-
|5||20||{{ottdp|no|2.5/2.6|ttdprev=r1439, will be in yet unreleased 2.5 beta 10}}||Enable catenaries over the third track type (only with electrifiedrailway on)
|-
|31||80000000||{{ottdp|no|2.5}}||Only to be set by ttdpbase(w).grf for identification
|}

Remarks:
<references />

Example code for setting bit 3:

24 * 9 0D 9E 08 9E FF 08 00 00 00

(Here, the first 08 indicates the bitwise OR operation, and 08 00 00 00 is the value to OR var.9E with.)

=== Locale-dependent settings (1F / 9F) ===

This variable is a doubleword in the format rrccmmll, where the meaning of the bytes is:

{|
!Byte!!Meaning

|-
|rr||Reserved for future use, just put zero here for now

|-
|cc||Default currency to be used when the game is first started. It can be larger than 5 to select one of the currencies added via morecurrencies. If this value is larger than 5 while morecurrencies is disabled, US dollars will be used instead.

|-
|mm||Default measurement system to be used when the game is first started. 00h means the imperial system (miles), 01h means the metric system (kilometers), other values are forbidden.

|-
|ll||Language ID. By setting this byte, you can override the default language ID and allow other GRFs to supply correctly localized texts. (The other GRF can check for this value in action 4s)
|}

Reading this variable isn't reliable, so you must only write to it. Please also note that the cc and mm parts are considered only while loading the title screen for the first time, changing them later is ignored.

'''NOTE''': This variable is reset after the initialization stage. Only changes during the activation stage are considered. This way, GRFs disabled in newgrf.cfg won't change the language and/or default settings. If you want to modify the cc or mm part, make sure the corresponding action D isn't skipped by an earlier action 7 or 9. In particular, if your GRF isn't available for the tropic climate, make sure you set variable 9F before the climate check, since the default title screen is tropic, and your climate check will fail on it.

=== OpenTTD Version (21 / A1) ===
Variable A1 has the following format: Mmrbbbbb (though encoded in little endian as bb bb rb Mm). This variable has only a usefull meaning when variable 9D is 1 (OpenTTD). This variable can be used since OpenTTD r11330.
{|
!Element!!Meaning!!Value
|-
|M||major||First number of the [[Version_numbers#OpenTTD_version|OpenTTD version]]
|-
|m||minor||Second number of the OpenTTD version
|-
|r||revision||Third number of the OpenTTD version
|-
|bbbbb||build||Subversion revision of a build leading towards a release. When a final release is done 80000h is set.
|}

The presence of 80000h (bit 19 set) means that a release always has a higher version number than any builds leading to that release.

Examples
{|
!Version!!Variable A1!!Elements
|-
|0.6.0 r11330||06002C42||M=0, m=6, r=0, bbbbb=11330=2C42
|-
|0.6.0 (release)||06080000||M=0, m=6, r=0, bbbbb=0=80000 (due to release)
|}

VariationalAction2/Vehicles

2012-07-02T19:33:31Z

Michi cc: /* Query variable of n-th vehicle in chain (61) */ CB 2D doesn't modify properties either.

<div style="float:right; padding-left:12px; background:none;">{{NFONavVehicles}}</div>

==Introduction==

== Variables ==

{|
!Variable!![[GRFActionsDetailed|Size]]!!Version!!Description!!Available in purchase list
|+
|10||D||{{ottdp|1.2|no|ottdrev=r23080}}||Pick sprites for different GUI windows - See [[Action2/Vehicles]].||{{ottdp|1.2|no|ottdrev=r23080}}
|+
|40||D||{{ottdp|0.6|2.5}}||Position in consist and length of consist||no
|+
|41||D||{{ottdp|0.6|2.5}}||Position in and length of chain of consecutive vehicles with same ID||no
|+
|42||D||{{ottdp|0.6|2.5}}||Cargo types transported by consist||no
|+
|43||D||{{ottdp|0.6|2.5}}||Player info||{{ottdp|0.6|2.5|ottdrev=r4611|ttdprev=beta 2}}
|+
|44||D||{{ottdp|0.6|2.5|ttdprev=2.0.1 alpha 48}}||Aircraft info||no
|+
|45||D||{{ottdp|0.6|2.5|ttdprev=2.0.1 alpha 58}}||Curvature info||no
|+
|46||D||{{ottdp|0.6|2.5|ttdprev=2.0.1 alpha 59}}||Motion counter||no
|+
|47||D||{{ottdp|0.6|2.5}}||Vehicle cargo info||{{ottdp|0.7|no|ottdrev=r15542}} <ref name="var47">Variable 47 refers to the default cargo of the vehicle, when in purchase list. This differs from the cargo used in Action 3, which is 0xFF in purchase list. The "refit cycle" (F2) is currently always zero in the purchase list.</ref>
|+
|48||D||{{ottdp|0.6|2.5}}||Vehicle type information||{{ottdp|0.6|2.5|ottdrev=r5338|ttdprev=beta 2}}
|+
|49||D||{{ottdp|0.7|2.6|ottdrev=r13376|ttdprev=r2216}}||Year of construction (long format, 0 based)||{{ottdp|0.7|no|ottdrev=r13376}} <ref name="date">This is the current date</ref>
|+
|4A||D||{{ottdp|1.1|no|ottdrev=r20165}}||Info about current rail type for trains||no
|+
|4B||D||{{ottdp|1.2|no|ottdrev=r23068}}||Long date of last servicing||{{ottdp|1.2|no|ottdrev=r23068}} <ref name="date" />
|+
|4C||D||{{ottdp|1.3|no|ottdrev=r24246}}||Current max speed including e.g track or timetable speed limits. Only valid for front vehicle. Note, units differ for each vehicle type<ref name="speed">See [[Action0Trains#Speed 09|train property 09]], [[Action0RoadVehicles|road vehicle property 08]] (not 15, even when using realistic acceleration), [[Action0Ships|ship property 0B]] and [[Action0Planes|aircraft property 0C]].</ref>||no
|+
|60||D||{{ottdp|0.6|2.5|ttdprev=2.0.1 alpha 57}}||Count Veh.ID occurence||no
|+
|61||-<ref>The size of the result matches the size of the queried variable.</ref>||{{ottdp|1.2|no|ottdrev=r22997}}||Query variable of n-th vehicle in chain||no
|+
|62||D||{{ottdp|1.2|no|ottdrev=r22998}}||Curvature/position difference for n-th vehicle in chain||no
|+
|97||B||{{ottdp|0.6|2.0}}||Tick counter, increased every engine tick||no
|+
|B2||W||||Vehicle status: bit0 = vehicle invisible (in tunnel/depot), bit1 = stopped, bit7 = crashed||no
|+
|B4||W||{{ottdp|0.6|2.0}}||Current speed. Note, units differ for each vehicle type<ref name="speed" />||no
|+
|B9||B||{{ottdp|0.6|2.0}}||Cargo type (type B from the list at [[CargoTypes]]; climate dependent)||no
|+
|C0||W||{{ottdp|0.6|2.0}}||Engine age in days<br/>{{ottdp|1.2|2.5|ottdrev=r22816|ttdprev=alpha 61}} Valid for wagons and articulated parts as well.||no
|+
|C4||B||{{ottdp|0.6|2.0}}||Year built (counted from 1920), note this is modified when Cht: Year is used||{{ottdp|0.6|no|ottdrev=r4611}} <ref name="date" />
|+
|C6||W||{{ottdp|0.6|2.0}}||Vehicle type ID <ref>{{ottdp|0.7|no}} In OpenTTD 0.7 and newer this is the GRF-local ID of the vehicle. Earlier versions of OpenTTD and TTDPatch report the [[VehicleIDs|TTD ID]]. For trains this is the same; for other vehicle types they differ.</ref> (useful for [[Callbacks#Can wagon be attached (1D)|Callback 1D]])||no
|+
|C8||B||{{ottdp|0.6|2.0}}||Sprite type; FD for trains forward, FE or FF when reversed||no
|+
|C9||B||{{ottdp|0.6|2.0}}||Day counter; increased daily||no
|+
|DA||W||{{ottdp|0.6|2.0}}||Next wagon index, FFFF if last wagon (use shift-num=08 and check for FF)||no
|+
|F2||B||{{ottdp|0.6|2.5}}||Refit cycle, how many times refitted to the same cargo type||{{ottdp|0.7|no|ottdrev=r15542}} <ref name="var47" />
|+
|FE||W||{{ottdp|0.6|2.5}}||Modflags||no
|+
|FF||B||{{ottdp|0.6|2.5}}||Modflags||no
|}

<references />

For other 80+x variables confer the [http://marcin.ttdpatch.net/sv1codec/TTD-locations.html#_VehicleArray TTD vehicle structure].

Variables 40, 41, 42 and 43 are cached. This means that while they are in principle computationally expensive, they can be used without impacting performance. Variables 45 and 60 are also computationally expensive but cannot be cached, and should therefore be used sparingly. If possible 80+x variables are to be preferred.

Cached variables are updated when the game is loaded, when the consist enters or is rearranged in a depot, and when the train reverses.

In the purchase list only a few variables are available. Especially the front vehicle (related object) cannot be accessed, nor other articulated parts.

== Description ==
=== Position and length (40, 41) ===

'''Format:''' 00nnbbff

{| |-
!Variable!!Value
|-
|ff||position of vehicle within the consist counted from the engine (front), e.g. the engine would have ff=0, the 1st wagon or mail compartment of planes would have ff=1, the 2nd wagon or the rotor of helicopters would have ff=2, the 3rd wagon would have ff=3 etc
|-
|bb||same as ff, but counted from the end, i.e. the last wagon has bb=0, the next-to-last wagon has bb=1 etc.
|-
|nn||total number of vehicles in the consist minus one (i.e. a train with engine and three wagons has nn=3), including shadow and rotor for aircraft.
|}

For variable 40, these numbers refer to the whole consist, but for variable 41, they only refer to the chain of consecutive vehicles with the same ID as the current wagon (including itself, but possibly excluding the engine):

[[File:vehicle_var40_41.png]]

Note however, that accessing the "related" object (i.e. the locomotive) doesn´t make much sense for vars 40/41, except for var40 when in a [[Callbacks#Can wagon be attached 1D|callback 1D]] chain.

=== Consist cargo (42) ===

'''Format:''' uuiicctt

{| |-
!Variable!!Value
|-
|tt||a bit mask of all [[Action0Cargos#Cargo classes 16|cargo classes]] transported by the consist
|-
|cc||the most common [[CargoTypes|cargo type]] (from the column for type A)
|-
|ii||the most common refit cycle (var. F2) of cargo type cc
|-
|uu||the result of ORing the bits of prop. 25 from all vehicles in the train
|}

If used with VarAction2 type 81 (vehicle) it returns only cargo from this vehicle on, with type 82 (engine) that of the whole consist.
See also variable 47 for more details on the cargo carried by a vehicle.

{{grfTill|7}} For GRF versions 7 and before "cc" is the untranslated bit number from [[Action0/Cargos#Bit_number_for_bitmasks_.2808.29|cargo property 8]].

{{grfFrom|8}} With GRF version 8 the meaning of "cc" changes. If the grf file has installed a [[Action0/Global_Settings#Cargo_translation_table_.2809.29|cargo translation table]], the value in "cc" is the index of the cargo in that table; or FF if the cargo is not present in the table.

=== Player info (43) ===

'''Format:''' Ccttmmnn

{| |-
!Variable!!Value
|-
|nn||the number of the current player from 0 to 7 (up to E (14) in OpenTTD since r14735)
|-
|mm||the multiplayer player number with the host player (or the single player) being 0 and the client player being 1
|-
|tt||the player type, see below for possible values
|-
|c||the primary player colour
|-
|C||{{ottdp|0.6|2.5|ttdprev=r1405}} the secondary player colour, equal to c if none (since r1405)
|}

{| |-
!tt value!!Meaning
|-
|0||Player is human player (permanent company)
|-
|1||Player is AI player (not managed)
|-
|2||{{ottdp|no|2.5}} Player is a human managing an AI company
|-
|3||{{ottdp|no|2.5}} Player is human player's original company, now temporarily AI controlled
|}

{{ottdp|0.6|2.5|ttdprev=r1497}} Since r1497, when the vehicle sprite is being displayed in an exclusive offer window or new vehicle news message, or in other circumstances when no player is associated with the vehicle, nn will be FF.

=== Aircraft info (44) ===

'''Format:''' xxxxhhtt

hh is the height of the aircraft above ground, or more properly above the height of its shadow. Buildings, including the heliport, don't count as "ground", i.e. to get the height above a heliport, you have to subtract the heliport height from hh.

tt is the type of the current airport: 0=small, 1=large, 2=heliport, 3=oil rig. The current airport is the target airport for aircraft that have finished the ascent and are in flight.

=== Curvature info (45) ===

'''Format:''' xxxTxBxF

This returns the amount of curvature between the adjacent wagon pairs. It is useful for train vehicles that normally tilt in curves. The curvature is the difference in direction between the surrounding vehicles:

F = for the front pair (previous wagon to current wagon, 0 if vehicle is first)

B = for the back pair (current wagon to next wagon, 0 if wagon is last)

T = for the triplet (previous wagon to next wagon; is zero in an S-bend)

Possible values:

{| |-
!Decimal!!Hex!!Meaning
|-
| -4||C||180° curve left (T only)
|-
| -3||D||135° curve left (T only)
|-
| -2||E||90° curve left
|-
| -1||F||45° curve left
|-
|0||0||no curve
|-
|1||1||45° curve right
|-
|2||2||90° curve right
|-
|3||3||135° curve right (T only)
|-
|4||4||180° curve right (T only)
|}

=== Motion counter (46) ===

'''Format:''' 32-bit value

This variable counts the amount of motion that a vehicle has done.  It is only valid for the first vehicle in a consist (i.e. use VarAction2 type 82!).  Its value is in units of 1/4096 of a tile.  A vehicle actually moves visibly every time the motion counter increases by 256, and since a tile consists of 16 such subunits, 16*256=4096 motion units mean motion across one tile.

The most useful way to access it is probably with <shiftnum>=08 and an appropriate <andmask>.  For example, to achieve an animation with one frame per vehicle motion and 16 frames in total for motion across an entire tile, you would use <shiftnum>=08 and <andmask>=0F.  For an animation with one frame every two vehicle motions and 4 frames total, use <shiftnum>=09 and <andmask>=03.

If the vehicle is going very fast (>160 mph for trains), it may move by several 1/16ths of a tile at once, and thus some frames may be skipped, but the animation will still remain in sync with the motion.

Note that vehicle graphics are only updated every time the vehicle actually moves, so checking the lower byte is probably pointless, and only needed internally to achieve sufficient precision.

=== Vehicle cargo info (47) ===

'''Format:''' ccccwwtt

{| |-
!Variable!!Value
|-
|tt||the [[CargoTypes|cargo type]] transported by the vehicle (from the column for type A); translated if a translation table has been installed
|-
|ww||cargo unit weight in 1/16 tons, same as [[Action0Cargos#Weight of one unit of the cargo 0F|cargo prop. 0F]]
|-
|cccc||the [[Action0Cargos#Cargo classes 16|cargo class]] value of the cargo transported by the vehicle
|}

Note that if the grf has installed a [[Action0/Global_Settings#Cargo_translation_table_.2809.29|cargo translation table]], the value in "tt" is the slot number in that table, irrespective of which actual slot or bit the cargo is using in the game. If a table has been installed, but the current cargo is not listed there, "tt" will be set to FF.

Unlike variable 42, this variable returns the info of the current vehicle only, not the consist.

=== Vehicle type information (48) ===

'''Format:''' xxxxxxff

The bits of ff are:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||Vehicle type is available on the market
|-
|1||2||Vehicle type is in the testing phase
|-
|2||4||Exclusive testing offer for a human player active
|}

All other bits in ff are undefined and must be masked out.

=== Information about current rail type for trains (4A) ===

'''Format:''' xxxxFFrr

The lower byte (rr) contains the (translated) rail type the train vehicle is currently driving on. If the rail type has no entry in the rail type translation table of the GRF, this value will be 0xFF. If no translation table is present, the raw value will be returned.

The next byte (FF) contains the following flags:

{| |-
!Bit!!Value!!Meaning
|-
|0||1||The vehicle is/would be powered on the current rail type (this is independent from powered/non-powered wagon or anything)
|}

All other bits are undefined.

All other bytes and the result for non-rail vehicles are undefined.

=== Count Veh.ID occurence (60) ===

'''Format:''' xxxxxxnn

The 60+x parameter is the vehicle ID to look for, and the returned nn is the number of vehicles in the consist that have this ID. If used with VarAction2 type 81, only the current vehicle and onwards will be check, with VarAction2 type 82, all vehicles in the consist will be counted.

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

This is a special variable to get the contents of another variable of a different vehicle in the vehicle chain. It is only supported for trains and road vehicles. It is not supported during a callback that is used to modify vehicle properties to avoid circular dependencies, which currently limits this variable to callbacks 1D, 2D, 31 and 32 plus outside callback scope.

Temporary register 10F is interpreted as a signed integer and specifies the offset in the chain from the current vehicle. Positive values are interpreted as towards the end, negative values as towards the front. If the offset is outside the vehicle chain, the result value will be 0.

The 60+x parameter specifies the variable to access and temporary register 10E is passed as the new 60+x parameter. Passing 61 as the variable is not allowed. Currently only vehicle specific variables listed on this page plus global variable 25 are accessible through var 61. Esp. variable 5F is currently not supported.

The resulting value will have the size of whatever variable is queried.

=== Curvature/position difference for n-th vehicle in chain (62) ===

'''Format:''' zzyyxxFD

This variable is only supported for trains and road vehicles.

The 60+x parameter is interpreted as a signed integer and specifies the offset in the chain from the current vehicle. Positive values are interpreted as towards the end, negative values as towards the front. If the offset is outside the vehicle chain, the result value will be 0.

The lowest nibble (D) contains the direction difference between the selected vehicle and this vehicle, the possible values are identical to those of [[#Curvature_info_.2845.29|variable 45]].

The next nibble (F) has the following meaning:
{| |-
!Bit!!Value!!Meaning
|-
|3||8||The vehicle is currently hidden
|}

The upper three bytes contain the signed difference of the X/Y/Z position between the selected vehicle and this vehicle.

=== Modflags (FE and FF) ===

The bits in FE mostly relate to gradualloading.  A few useful bits for grf authors are;

{| |-
!Bit!!Version!!Value of the bit
|-
|5||{{ottdp|0.6|2.5}}||Vehicle is powered (engine or powered wagon, mainly useful for the latter)
|-
|6||{{ottdp|0.6|2.5}}||Vehicle would be powered (engine or powered wagon) if there were suitable track. (E.g. electric train in mixed train on normal track)
|-
|8 <ref>This bit is only accurate for the first vehicle in the consist.</ref>||{{ottdp|0.6|2.5}}||This bit is flipped every time the train reverses direction
|-
|10||{{ottdp|0.6|2.5|ttdprev=r1334}}||Vehicle was built during the exclusive preview
|}
<references/>

variable FF is actually the high byte of variable FE, so FE bit 8 is the same as FF bit 0.

Other bits are reserved; most are actually used for TTDPatch internal states.

==Examples==