Standardized Railtype Scheme
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 type and gauge, 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 type and gauge 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 type and gauge class [X***]
The first position in the railtype label defines track type and/or track gauge 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 types or gauges 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 type/gauge.
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 type/gauge 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 1D (NFO) or 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 SAAN + SABN to SACN and SADN to SAEN if the cost difference between the two railtypes is high, or SAAN to SABN and SACN + SADN to SAEN 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 NAAN for the track label, and provide NABN, NACN, NADN, NAEN in property 1D (NFO) or 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 | three phase AC electrification | E |
| D | DC catenary electrification | E |
| d | low voltage DC catenary electrification (only when D also used in set) | First D, 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 1D (NFO) or 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 type and gauge class
- Define at least one track type for every track type/gauge class you want in your set.
- If you only provide tracks for one type/gauge, 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 1D (NFO) or 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 1D (NFO) or 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 type and gauge classes should be neither powered nor compatible with each other.
Or, put differently, for each type/gauge, 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 type and gauge 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 the forum topic.
