#openttdcoop

Spec

Essential
•	‘road' and ‘tram' are independent, like ‘road’ and ‘rail’
•	they can coexist on the same tile in some cases, but do not influence each other
•	the term ‘roadtypes’ is confusing for historical reasons and due to pre-existing use in code, and is not used here: this is NotRoadTypes
•	‘tram’ and ‘road’ are built as subtypes
•	per tile, one subtype of ‘road’ and one subtype of ’tram’ may be present
•	construction tools for ‘road’ and ’tram' are independent
•	adding/removing/converting ‘road’ on a tile does not affect ‘tram’ for tile and vice-versa
•	vehicles are either ‘road’ or ‘tram’, they cannot be both
•	vehicle routing and movement per ‘road’ and ‘tram’ are independent
•	any ‘road’ subtype may be freely combined with any ’tram’ subtype, there are no ways to make ‘road’ and ’tram’ incompatible with each other by subtype or any other means 
•	subtypes
    ◦	proposed up to 15 ‘road' subtypes and 15 ‘tram’ subtypes (implementation detail: uses 4 bits each, uses 8 bits free in m8)
    ◦	15 is more than enough for any game
    ◦	spec shouldn’t have an opinion on how many type a game needs, but 3 or 4 of each is plenty imho
    ◦	each subtype has a label
    ◦	vehicle compatibility with a subtype is determined by label
    ◦	vehicle may determine some properties by subtype (power, possibly others)
•	drawing
    ◦	‘tram’ is always drawn above ‘road’; authors need to be aware of this when drawing sprites, no mechanism will be provided to vary this
    ◦	drawing of city roads, bridges, tunnels, and similar will follow existing behaviour
    ◦	drawing of rail crossings may or may not be fixed (road tile is enforced for tram crossings currently, this looked non-trivial to fix when I tried)
    ◦	methods _may_ be provided to enable more control over appearance, e.g. snow above snowline etc
•	catenary
    ◦	subtypes can provide catenary, or not (implementation detail: flag or cb returning sprites)
    ◦	both ‘road’ and ‘tram’ can provide catenary on a tile
    ◦	authors will need to draw catenary carefully to avoid it looking bad when ‘road’ and ‘tram’ catenary are combined on a tile
    ◦	vehicle power on a tile is determined by vehicle against subtype label, unrelated to drawing of catenary sprites
    ◦	there is sophisticated handling of rail catenary to preserve continuity where railtypes cross, something similar needs to be provided for NotRoadTypes
•	converting between subtypes
    ◦	a convert tool is needed, similar to rail conversion
    ◦	this will need to consider ownership carefully
        ▪	too restrictive = can’t overbuild subtypes in towns
        ▪	too permissive = deliberate or accidental breaking of existing routes by overbuilding incompatible subtype
•	drive-in stops:
    ◦	behaviour of articulated vehicles and trams unchanged, can’t use drive-in stops
    ◦	catenary needs to be provided for ‘road' drive-in stops
•	overtaking: out of scope

Optional (proposed by frosch)
•	split global toolbar to ‘road’ and ‘light rail’
•	this makes the distinction between the transport types obvious
•	in this way it’s clear that a tile can have
    ◦	1 type of rail
    ◦	1 type of road
    ◦	1 type of light rail
•	unknown: would the various vehicle menus, station menus etc also be split for ‘road’ and ‘light rail’?

Mark as private