Standardized Roadtype Scheme

This scheme was originally conceived in order to decrease the amount of necessary hidden road and tramtrack types. This is done by standardizing which labels vehicles and infrastructure should use. The standard also allows for more gameplay depth by having the option to limit vehicles to certain types of roads. It does similarly to the railtype scheme allow mixing of any vehicle set with any infrastructure set. It does however not allow multiple infrastructure sets to be used at the same time. It does not prevent it but all of the sets used have to be made to be used with each other, or use different surfaces/types which don't conflict with each other. The standard sets no limit on how vehicle sets can be used.

It is ultimately up to the infrastructure set to chose what roadtypes are available and thereby what vehicles are available. Infrastructure and vehicles can both be in the same set, it is however recommended to be able to disable the infrastructure with parameters (preferably on an individual basis per roadtype) in case the player wants to use a different set for their infrastructure.

• While this is a guide rather than a hard rule, it is recommended to think of standardized roadtypes vs. "fancy" roadtypes (not a default and not to this standard; for example "FNCY", "HAUL" and "NSTD" would be fancy labels but ROAD for roadtypes, and ELRL for tramtypes, would not) as a microcosm of the difference between a base set (OpenGFX) and a NewGRF that provides new graphics; The goal is for a basic roadtype set to cover as many standardized labels as is appropriate, and leave the more niche uses of the system to another set. This reduces the number of necessary roadtypes to a bare minimum, allowing optional roadtypes more room to cover corner cases.
  • The reason to keep the above in mind is that if done in this way the effect works very differently than railtypes, where the primary concern is to allow gauge, energy source and so on to exist and bind trains from all sets to only the logically compatible railtypes. Roads and, by extension, streetcar tracks are more compatible with vehicles but also have much more variation. This is complicated by game engine limitations; only 60 - or 61 without ELRL - tracktype slots exist in recent versions of OpenTTD, but reaching that limit is usually a non-issue. Roadtypes and Tramtypes are considered the same on that front by the game engine, leaving 62 tramtypes - 64, including ROAD and ELRL - to be split in a pool between the two.

---

Surface / Type [X***]

Describes the road surface / rail type and thus the vehicle type.

Roadtype:

Letter	Meaning (Road)	Powered Roadtypes (Optional Powered)	Recommended vehicle set fallbacks	Notes
R	Regular Road	R, I, (S)	R	RABN = ROAD
P	Passenger-only (busses, cars, bikes)	R, P, (I), (S)	P, then R	HOV lane, public parking, or town road. Relevant non-standard types include TOWN, TRD_ and _TRD
g	Bus lane (no AI street traffic)	R, P	P, then R	Bus-exclusive road, or privately-owned parking lot. No guided bus sets or roadtypes exist yet but existing busses should be updated to use g and guided busses should also use it; for busses only.
G	Guided busway (Specialized busses only)	R, P, G	P, then R	Once g has been integrated into existing vehicle sets, new guided busses should use both g and G. Existing busses should NOT be updated to use G once roadtype sets provide it, guided busways are only for specially-equipped guided busses.
I	Industrial Site (ISR)	I	R	For tiles with concrete underneath, usually for use with Industrial Stations Renewal.
B	Bicycle Lane	B, b, P, R, (Z)	R and b	For bicycles that can serve as AI traffic
b	Bus Lane with Bicycle Lane	b	R and B	For bicycles that can serve as AI traffic crossing paths with a bus lane (see "g")
W	Waterway	W	W and w	For gondolas and other urban waterways.
A	Amphibious on road (hidden)	R, P, I, (S), W	R and W	Optionally, for amphibious road vehicles that are allowed on high speed roads with stability labels B (and possibly b), C or c (e.g. RABN, RACN and RAcN, and possibly RAbN) but not low speed roads.
S	Snowy or Iced Track	S	R	A road which is not plowed in winter, or an ice road.
a	Amphibious on snow (hidden)	SW	S	Optionally, for amphibious road vehicles that are allowed on rough roads with stability labels a, A or B (e.g. RAaN, RAAN and RABN, and possibly RAbN) but not highways or limited access motorways.
Z	Pedestrian Zone	Z		Dedicated pedestrian zone, for use with some AI traffic eyecandy vehicle sets.
E	Eyecandy	E		EAbi is the only label that should be defined for this. Set all eyecandy roadtypes to have custom labels and to be powered on EAbi.
p	Pump/Pipeline	p		EAbi, EBbi, ECbi, EDbi and EEbi are the only labels that should be defined for this. These are for utility pipeline "vehicles" such as "pumps" which exclusively move liquid and gaseous cargo classes.

Tramtype:

Letter	Meaning (Tram)	Powered Tramtypes (Optional Powered)	Recommended vehicle set fallbacks	Notes
R	Regular Rail (1000 mm to 1067 mm)	R, I, (M)	R, then the ELRL label.	Most mixed-use tramways are actually meter gauge, with standard gauge and similar widths of track making up the remainder.
P	Passenger-only (1000 mm to 1067 mm)	RPI(M)	R	Most streetcars are actually meter gauge, with standard gauge and similar widths of track making up the remainder.
I	(ISR) Industrial Site (1000 mm to 1067 mm)	I	R	Most mixed-use tramways are actually meter gauge, with standard gauge and similar widths of track making up the remainder.
B	Bicycle Lane	(R)B	R	For North American style bicycle lanes and cycling trails; does not allow U-Turns as it is a tramtype.
S	Suspended Monorail	S		JP+ suspended monorail tracks. SABN is the only type that needs compatibility to be implemented.
M	Metro (1000 mm to 1067 mm)	If vehicle carries passengers, P then R; if vehicle carries freight, R.		Some metro systems are actually meter gauge, with standard gauge and similar widths of track making up the majority. Sets should define both M?Bc and M?bc speed variants.
O	Trackless trams	Do not set fallbacks		These use an optical guidance system to create a "virtual" tram track as a line painted on a road or a series of LED beacons. Sets should define (depending on which electrification methods will be desired in a vehicle roster) both O?BN/O?BE/O?BG/O?BZ and O?bN/O?bE/O?bG/O?bZ speed variants with both A-H road speeds and K-R high-friction speeds.
V	Vacuum Tube Capsules	Do not set fallbacks		A futuristic tramway from the VacTram set, consisting of pneumatic tubes which propel small VacBalls at high speeds using pressure or lack of it. VEBi a as buildable type and and VACT as a hidden type are the only types that need to be implemented.
v	Deep-Bore VacMetro	Do not set fallbacks		A futuristic metro system, in a more realistic manner than VacTrains and VacTrams. Ideally, would be implemented as vSbV and vUbV (narrow tube for single-deck trains), and as vSBV and vUBV (broad tube for the double-deck futuristic subway) with similar graphics to the Fake Subways Set and not the existing metro tunnels.
E	Eyecandy/Electrical infrastructure (hidden)	Do not set fallbacks	Eyecandy, the only standardized type that should be defined is EEbc. Use as a fallback for i when a tramtype is decorative and electrical infrastructure could exist within it, to make bridges unnecessary for intersecting utility lines. These should be given graphics meant to be decorative but functional, such as
i	Electrical infrastructure	E, then the ELRL label	Infrastructure, the only standardized type that should be defined is iEbi. Use for non-decorative "eyecandy" roadtypes meant to potentially carry electricity, phone, internet, etc.

It is the vehicle set's responsibility to implement fallbacks to other appropriate surfaces. It is also up to the author to decide if they want to do it or not. This means that road/tramtrack sets shouldn't add these to their alternative_roadtype_list (NML) and alternative_tramtype_list (NML)

It is up to the track set to implement all powered roadtypes in the powered_roadtype_list (NML). The same goes for tramtypes: powered_tramtype_list (NML). It is further advised to implement support for the roadtypes/tramtypes in brackets, if applicable.

Hidden roadtypes for compatibility should be implemented by road sets. It is up to the author to decide if they want to implement it as a hidden roadtype or not.

Speed / Feature [*X**]

Any character may be used for roads, but at least one road must have "A". It has been proposed that speeds from A to H are reserved for standardized roadtype and tramtype labels. Speeds from K to R and from k-r would only be reserved for tramtypes which have comparable surface friction to a road vehicle, and would not need to be dedicated to special traction in a roadtype set that does not include tramtypes.

	Description	Type	Used by
A-H	speed limits	reserved (road & tram)
a-h	fixed-position and dedicated transport, that allows a vehicle to not slow down going uphill but requires dedicated tracks or infrastructure; use for funicular railways, ski chair lifts, industrial cable lifts, and the Wuppertal monorail.	special	none yet
I-J	general use	unreserved
K-R	high-friction with unfixed position on shared, fixed route	special	none yet
k-r	high-friction with unfixed position on dedicated route, that allows a tram vehicle to go uphill under the same mechanics as road vehicles but requires a dedicated Right-of-Way; Rubber-tired rail transport, including Paris/Quebec metro and some suspended monorails, goes here, as well as conveyor belts.	unreserved
S	suburban tunnel	eyecandy	Metro Tram Set
T	general use	unreserved
U	urban	eyecandy	Metro Tram Set
V-Z	general use	unreserved
s-z	general use	unreserved
0-9	general use	unreserved

All other characters which are valid (you'll get a warning from nmlc if they aren't) are also currently unreserved and are likely to remain so.

High-friction vs. rail, shared vs. dedicated route, and fixed vs. unfixed position, need a bit greater of a explanation. They are based on the intended system for rack rails in the Standardized_Railtype_Scheme#Speed_limit_class_.5B.2AX.2A.2A.5D Standardized Railtype Scheme. As of 2024, the French Set Rails (the most popular track set to implement rack) implements compatibility both ways which makes pure rack systems impossible.

In this case the problem is similar but worse, as it is not coded into the game engine. Ideally it would be coded in a way where all systems are only supported if such would be possible in real life. This can be partly achieved by making regular trams powered on a rackrail-equivalent such as a cablecar track (i.e. San Francisco cablecars) without the opposite being true, and by making others such as rubber-tired metros only run on rubber-tire compatible tracks. This means vehicles defined for RKBC (SFBA cablecar) can't go on RABN (like a pure rack system) but RABN vehicles (meter-gauge steam/diesel/battery trams) can go on RKBC (like a rack-and-adhesion system). However, there is no way to force a tram to adhere to the speed limits of the roadtype below the tramtype (rather than just the tramtype) it is currently on, nor any way to bar a tramtype from overlapping on roadtypes.

Should this be implemented, K-R would be equivalent to A-H for rack-and-adhesion, and k-r equivalent to A-H for rack-only. Finally, a-h would be equivalent to A-H for systems where the "vehicles" are adjoined to a cable or propelled/throttled via outside factors, such as pipelines, electrical/phone/internet lines, ski lifts and industrial bucket lifts; If the option to make roadtypes relevant to the maximum speeds of trams is added, a-h should remain untouched by the changes by requiring that existing GRFs be manually updated if they are meant to be blocked by roadways.

Vehicles should use "A", "a", "K" or "k" accordingly; if in doubt, assume "A".

Terrain / Stability [**X*]

Describes the roughness of the road surface / trackbed stability, and thus the vehicle tier.

Letter	Meaning	Powered Roadtypes
a	Very slow / rough / light	a
A	Slow / rough / light	aAB
B	Regular	ABC
C	Fast / stable	BCc
c	Very fast / stable	c

If all classes aren't defined by the road set, the other ones should be in the alternative_roadtype_list (NML). The same goes for tramtypes: alternative_tramtype_list (NML).

Road vehicle sets should not implement fallbacks for terrain / stability.

Classes "a" and "c" are entirely optional for road/tramtype sets and should under no circumstances be used by vehicles.

Energy [***X]

Describes the energy source of the track / vehicle.

Generic classes:

Letter	Meaning (Road)	Meaning (Tram)	Vehicle set fallback
N	None	None
E	Overhead electrified (Catenary)	Overhead electrified (Catenary)
G	Ground electrified	Ground electrified
Z	Ground and overhead electrified	Ground and overhead electrified	E or G

Specialized classes:

Letter	Meaning (Road)	Meaning (Tram)	Vehicle set fallback
3	n/a	Third Rail	G
4	n/a	Fourth Rail	3 then G
C	n/a	Cable	G

A tramtrack set that only uses specialized types, should map the generic types to the most suitable specialized type in the set with the help of the alternative_tramtype_list (NML).

The default labels (ROAD, ELRL) and non-standard labels

OpenTTD will allways define ROAD and ELRL incase there are vehicles for them. It is therefore recomended to have these present in the set so that you can map them to appropriete labels from the standard. There are a few ways of doing this:

• Replacing one of the standardised types with the default label and putting the standardised label in the alternative_roadtype_list (NML) or alternative_tramtype_list (NML).
• Defining ROAD and/or ELRL separately from the standardised labels and adding the standard ones to the powered_roadtype_list (NML) or powered_tramtype_list (NML). The main advantage of this is that you can use a parameter to map ROAD and/or ELRL to the standardised labels. This allows the player to chose where there non standardised vehicles will be able to go.

Vehicle set authors might want to add the default labels and non-standard labels as a fallback. If not implemented for the defualt labels, their vehicles won't show up on the default roads and/or tracks, leading to countless bug reports from players. Non standard labels that might be worth adding fallbacks too are: ELRD, RAIL, HAUL and probably some more.

Summary for Road/Tramtrack sets

This section summarizes the above for road/tramtrack sets.

[X***] Surface / Type

• Chose which Surfaces and types you want in your set and give them the correct powered_roadtype_list (NML) or powered_tramtype_list (NML).
• If you only provide roads/tramtracks for one surface/type, consider leaving some free road/tramtypes so a player can load an additional set for some other type.

[*X**] Speed / Feature

• Make sure class A is always available.
• Use B, C and so on if you have multible roads/tramtracks with the otherwise the same label.

[**X*] Terrain / Stability

• Always define classes A through C for every road/tramtrack surface/type energy combination, either:
  • Directly via a real road/tramtype definition;
  • Indirectly via the alternate road/tramtype label list, powered_roadtype_list (NML) or powered_tramtype_list (NML).

[***X] Energy source type class

• If your set only uses specialized classes, always map the generic classes to the closest matching specialized type via powered_roadtype_list (NML) or powered_tramtype_list (NML).

Default labels [ROAD, ELRL] and non-standard labels

• Always define the default labels when possible, instead of what would be the equivalent of the default label in this scheme.
• Map the equivalent labels from this scheme to the default labels using powered_roadtype_list (NML) or powered_tramtype_list (NML).
• Map common non-standard labels to the most similar label in this scheme using powered_roadtype_list (NML) or powered_tramtype_list (NML).

Summary for vehicle sets

This section summarizes the above for vehicle sets.

[X***] Surface / Type

• Use the surface / type class that matches the vehicle;
• Define a fallback type via the road/tramtype table in case you want the vehicle to be available on a different road or tramtrack if no matching road/tramtrack set is loaded.
  • Specialized subtypes like "G" might not always be available. If you want those vehicles to be still available then, fall back the the generic class (e.g. "P" or "R").

[*X**] Speed / Feature

• Always use class A for every vehicle, unless you are absolutely certain you will be introducing something cable-drawn, with tires as traction, or with a rack rail.

[**X*] Terrain / Stability

• Use A, B or C depending on where you want your vehicles to be able to drive.
  • A is used for slow offroad capable vehicles which aren't allowed on Motorways and similar Roads
  • B is used for vehicles which can drive offroad but are also allowed on Motorways.
  • C is used for vehicles which can't go offroad or similar.
  • Use B if you aren't sure what to chose.
• Never use a or c.

[***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.

Default labels [ROAD, ELRL] and non-standard labels

• Define a fallback type to the default labels via the road/tramtype table in case you want the vehicle to be available on the default roads/track if no matching set is loaded.
• Do the same for any non-standard labels that may be relevant.

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

Example of fallback order for vehicle sets

Unchanged label	Fallback order
GACE (road)	GACE -> PACE -> RACE -> (ROAD)
PAB4 (tram)	PAB4 -> PAB3 -> PABG -> RAB4 -> RAB3 -> RABG
IAAG (road)	IAAG -> RAAG
AACE (road)	AACE -> RAAE -> (ELRD)
RABE (tram)	RABE -> (ELRL)
PAAN (tram)	PAAN -> RAAN -> (RAIL)

Forum topic

Feel free to discuss and ask questions about the scheme at the forum topic Here.

Possible additions

To be discussed in the forum topic...

Surface / Type [X***]

Describes the road surface / rail type and thus the vehicle type.

Tramtype:

Letter	Meaning (Tram)	Powered Tramtypes	Recomended vehicle set fallbacks
Z	Deep-Bore Metro	(For subsurface logistics systems that are normally never visible on the surface)
z	Passenger-only (Deep-Bore Metro)	(For subsurface metro systems that are normally never visible on the surface)
X or x	Multiple guidance systems or gauges	(Depends on intent; only two tramtype rail system combinations can exist for a given set of standardized labels - i.e. XABE and xABE - making it necessary to plan accordingly)
0 (#)	Invisible	For invisible tramtypes; Fallback for INVI, BKVI, 0000 and other "null" tramtypes
s	Regular Rail (Standard Gauge)	r
p	Passenger-only (Standard Gauge)	r
r	Multi-gauge Rail (Standard Gauge, Metre Gauge, 600mm Gauge)	s, R, p, P	P or p, depending on the vehicle's gauge (City tram); R, s or 6, depending on the vehicle's gauge (Cargo tram)
6	Industrial Tramway (600mm Gauge - default tramway rails graphics)	r

Terrain / Stability [**X*]

Describes the roughness of the road surface / trackbed stability, and thus the vehicle tier. (This is edited to include the potential "Low Clearance" hidden roadtype.)

Letter	Meaning	Powered Roadtypes
a	Very slow / rough / light	aA
A	Slow / rough / light	aAB
B	Regular	ABC
b	Regular (Low clearance)	ABC
C	Fast / stable	BCc
c	Very fast / stable	Cc

If all classes aren't defined by the road set, the other ones should be in the alternative_roadtype_list (NML). The same goes for tramtypes: alternative_tramtype_list (NML).

Road vehicle sets should not implement fallbacks for terrain / stability. Class "b" should only be used for a hidden roadtype, such as "RAbN", "PAbN" and electrified variants. This is optional, but if used it should be applied to the roadtype (NML) or tram_type (NML) property of all vehicles able to travel under the relevant low-clearance obstacles.

• As a frame of reference, realistically "RAbN" should be used for all eye-candy cars small cargo vans and single-decker non-electrified cargo trams, while trucks (excluding trolleytrucks) and non-electrified double-decker trams should default to "RABN". "RAbE" and other powered vehicles should be used by trolleytrucks and electric cargo trams (excluding double-decker trams). "PAbN" should be used by double-decker busses, and most non-electric trams (excluding double-decker trams). "PAbE" should be used by most passenger trams, excluding double-decker passenger trams. For other energy sources, the instructions for"RAbE" and "PAbE" can easily be adapted for any other power source ("RAbG" and "PAbG", "RAbI" and "PAbI", etc.).

Classes "a" and "c" are entirely optional for road/tramtype sets and should under no circumstances be used by vehicles.

Class "b" is also optional for road/tramtype sets but should have ROADTYPE_FLAG_HIDDEN set in the bitmask of roadtype_flags (NML). Instead, a low-clearance variant of a standardized roadtype or tramtype should be compatible with all other standard classes ("a", "A", B", "C" and "c") using the powered_roadtype_list (NML) in a road/tramtype set that sets the standardized labels (i.e. "RAbN" should be used for small cargo vans and must fallback to "RAaN, RAAN, RABN, RACN, RAcN", and "PAbE" should be used by all busses and must fallback to "PAaN, PAAN, PABN, PACN, PAcN"). If a complex roadtype (i.e. RAaN) needs a low-clearance variant, create a non-standard label (i.e. XMPL), then define the relevant standard labels (RAaN in this case, and RAbN in turn) in the alternative_roadtype_list (NML) of the non-standard label (XMPL), and define the entire class of labels (RAaN, RAAN, RABN, RAbN, RACN, RAcN) in the powered_roadtype_list (NML) of the non-standard label (XMPL).

Energy [***X]

Describes the energy source of the track / vehicle.

Generic classes:

Letter	Meaning (Road)	Meaning (Tram)	Vehicle set fallback
I	Induction-charge electrified	Induction-charge electrified	Z then G then N
i	Eyecandy/Pipeline Infrastructure	Eyecandy/Electric & Telecom Infrastructure	Z then E then G then I
L	Reclaimed Elevated Rail Eco-Park	Elevated Rail	I then Z then G then N (Roadtype); E then Z then G then I (Tramtype)
P	No Commercial Vehicles/Parking Lot (restricted roads for RABN-compatible cars that busses and trucks cannot use; eye candy cars should use RAbP as the primary label if intended to support this)	"PneuMetro" (Pneumatic Metro/Subway)	I then N then i (Roadtype); N/A (Tramtype)
S	"SolaRoad" (Solar Roadway) or "SmartStreet" (smartgrid network-enabled roads)	Superscience/Supernatural/Special (For anything that isn't fuel and isn't based on any real energy source; psychokinetic, mana, creative energy, etc.)	I then Z then E then G then N
V	Viaduct/Voltaic Variant (For a second bridge variant of a road, or a trolleybus variant of a road with limited overhead clearance)	"VacTube" (VacTrain Metro/Subway)	P (Roadtype); N/A (Tramtype)

Specialized classes:

Letter	Meaning (Road)	Meaning (Tram)	Vehicle set fallback
-	N/A	Cheat-like "electrification" for unified tramtype tunnels, to save on roadtype/tramtype labels make a single tramtype labelled EAbt and provide catenary sprites that place a "roof" but no (visible) rails (see Quast65's tramtypes for potential graphics, GPL v2 license), and then provide a version with tram rails using a ?Abt tramtype. You should define one or two tramtypes with speed "t" ("Tunnel") and surface "0" ("Invisible") to provide road tunnels (e.g. 0tbt for single-height tunnels and 0tBt for high-clearance tunnels) as a decorative tramtype, whose catenary should override the trolleybus catenary with the eyecandy tram catenary. Use a, A, B, C, or c as stability if you plan to include a "tall tunnel" for double-decker vehicles.	N/A; Do not set powered_railtype_list for these, instead use its' alternative_railtype_list to link compatible tramtypes to it.
X	Multiple systems of electricity	Multiple systems of electricity	E; Use with surface X or x (e.g. XABX and xABX) or surface R (road, or a rail-based tramtype). For use only when at least one standardized label is an energy supply and multiple non-conflicting energy types are all at the same level, such as electrified, ground electrified and induction-charging overlap; Do not set powered_railtype_list for these, instead use alternative_railtype_list.
x	N/A	Multiple systems of guidance, height-incompatible	N/A; Use this with surface x (e.g. xABx) or the surface systems (e.g. SABx, RABx, MABx). For use when tramtypes are at different heights but all are fundamentally incompatible (i.e. suspended monorail, trackless tram and pneumatic metro all on the same tile); Do not set powered_railtype_list for these, instead use alternative_railtype_list to link other railtypes to it.
+	N/A	Multiple systems of guidance, mix of compatible/height-incompatible	For use when tramtypes are a mix of compatible and height-incompatible (i.e. electrified, ground electrified, trackless tram, suspended monorail, tram and pneumatic metro) tramtypes, provided their presence is possible in real life; Do not set powered_railtype_list for these, instead use alternative_railtype_list, or define these in another label's powered_railtype_list (i.e. XAB+ for XABN/XABE/XABX and RAB+ for RABN/RABE/RABX).
c	"Cheat electrification" for network conversion; Arguably unneeded currently as there is only one type of road electrification as of this writing.	"Cheat electrification" for network conversion; Anything where all instances of the real life systems co-existing in the real world are physically impossible, which obviously doesn't have much bearing on imaginary tramtypes but could be inferred that typical trains and monorails are not fictional and don't go well together.	Define the "RA_c" for both roadtype and tramtype, totaling 2 label IDs. Define non-standard roadtypes in Roadtypes#Roadtype_properties alternative_roadtype_list/alternative_tramtype_list of "RA_c", and define "RA_c" in powered_roadtype_list for all other standardized roadtypes.