Standardized Roadtype Scheme

From GRFSpecs
Revision as of 01:38, 28 December 2023 by Lurkmore (talk | contribs)
Jump to navigationJump to search

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 - ROAD for roadtypes, ELRL for tramtypes - and not to this standard; for example "FNCY", "HAUL" and "NSTD" would be fancy labels) 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 Recomended vehicle set fallbacks
R Regular Road RI(S)
P Passenger-only RPI(S) R
G Guided busway RPG P then R
I Industrial Site (ISR) I R
B Bicycle Lane RB(Z) R
W Waterway W
A Amphibious on road (hidden) RPI(S)W R
S Snowy or Iced Track S
a Amphibious on snow (hidden) SW S
Z Pedestrian Zone Z
E Eyecandy E
p Pump/Pipeline p

Tramtype:

Letter Meaning (Tram) Powered Tramtypes Recomended vehicle set fallbacks
R Regular Rail RI(M)
P Passenger-only RPI(M) R
I Industrial Site (ISR) I R
B Bicycle Lane (R)B
S Suspended Monorail S
M Metro M(RP)
O Trackless trams O
E Eyecandy/Electrical infrastructure E

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

Vehicles should use "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 aA
A Slow / rough / light aAB
B Regular 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.

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:

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
[***X] Energy source type class
Default labels [ROAD, ELRL] and non-standard labels

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.
[**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
X or x Multiple guidance systems or guages (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)

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 E then G
i Eyecandy/Pipeline Infrastructure Eyecandy/Electric & Telecom Infrastructure I then Z then G then E
L Reclaimed Elevated Rail Eco-Park Elevated Rail I then Z then E then G then N
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
X N/A Multiple systems of electricity Use with surface X or x (e.g. XABX and xABX) or surface R (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 trackless tram overlap
x N/A Multiple systems of guidance, incompatible 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, tram and pneumatic metro)
0-2 & 5-9 N/A Multiple systems of guidance, mix of compatible/incompatible For use when tramtypes are a mix of compatible and fundamentally incompatible (i.e. electrified, ground electrified, trackless tram, suspended monorail, tram and pneumatic metro); 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. XAB0/XAB1/XAB2/XAB5/.../XAB9 for XABE/XABX and RAB0/RAB1/RAB2/RAB5/.../RAB9 for RABN/RABE/RABX).