| 4 | | 4 | • ‘road' and ‘tram' are independent, like ‘road’ and ‘rail’
|
|---|
| 5 | | 5 | • they can coexist on the same tile in some cases, but do not influence each other
|
|---|
| 6 | | 6 | • the term ‘roadtypes’ is confusing for historical reasons and due to pre-existing use in code, and is not used here: this is NotRoadTypes
|
|---|
| 7 | | 7 | • ‘tram’ and ‘road’ are built as subtypes
|
|---|
| 8 | | 8 | • per tile, one subtype of ‘road’ and one subtype of ’tram’ may be present
|
|---|
| 9 | | 9 | • construction tools for ‘road’ and ’tram' are independent
|
|---|
| 10 | | 10 | • adding/removing/converting ‘road’ on a tile does not affect ‘tram’ for tile and vice-versa
|
|---|
| 11 | | 11 | • vehicles are either ‘road’ or ‘tram’, they cannot be both
|
|---|
| 12 | | 12 | • vehicle routing and movement per ‘road’ and ‘tram’ are independent
|
|---|
| 13 | 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
| 13 | • 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
|
|---|
| 14 | | 14 | • subtypes
|
|---|
| 15 | | 15 | ◦ proposed up to 15 ‘road' subtypes and 15 ‘tram’ subtypes (implementation detail: uses 4 bits each, uses 8 bits free in m8)
|
|---|
| 16 | | 16 | ◦ 15 is more than enough for any game
|
|---|
| 17 | | 17 | ◦ spec shouldn’t have an opinion on how many type a game needs, but 3 or 4 of each is plenty imho
|
|---|
| 18 | | 18 | ◦ each subtype has a label
|
|---|
| 19 | | 19 | ◦ vehicle compatibility with a subtype is determined by label
|
|---|
| 20 | | 20 | ◦ vehicle may determine some properties by subtype (power, possibly others)
|
|---|
| 21 | | 21 | • drawing
|
|---|
| 22 | | 22 | ◦ ‘tram’ is always drawn above ‘road’; authors need to be aware of this when drawing sprites, no mechanism will be provided to vary this
|
|---|
| 23 | | 23 | ◦ drawing of city roads, bridges, tunnels, and similar will follow existing behaviour
|
|---|
| 24 | | 24 | ◦ 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)
|
|---|
| 25 | | 25 | ◦ methods _may_ be provided to enable more control over appearance, e.g. snow above snowline etc
|
|---|
| 26 | | 26 | • catenary
|
|---|
| 27 | | 27 | ◦ subtypes can provide catenary, or not (implementation detail: flag or cb returning sprites)
|
|---|
| 28 | | 28 | ◦ both ‘road’ and ‘tram’ can provide catenary on a tile
|
|---|
| 29 | | 29 | ◦ authors will need to draw catenary carefully to avoid it looking bad when ‘road’ and ‘tram’ catenary are combined on a tile
|
|---|
| 30 | | 30 | ◦ vehicle power on a tile is determined by vehicle against subtype label, unrelated to drawing of catenary sprites
|
|---|
| 31 | | 31 | ◦ there is sophisticated handling of rail catenary to preserve continuity where railtypes cross, something similar needs to be provided for NotRoadTypes
|
|---|
| 32 | | 32 | • converting between subtypes
|
|---|
| 33 | | 33 | ◦ a convert tool is needed, similar to rail conversion
|
|---|
| 34 | | 34 | ◦ this will need to consider ownership carefully
|
|---|
| 35 | | 35 | ▪ too restrictive = can’t overbuild subtypes in towns
|
|---|
| 36 | | 36 | ▪ too permissive = deliberate or accidental breaking of existing routes by overbuilding incompatible subtype
|
|---|
| 37 | | 37 | • drive-in stops:
|
|---|
| 38 | | 38 | ◦ behaviour of articulated vehicles and trams unchanged, can’t use drive-in stops
|
|---|
| 39 | catenary needs to be provided for ‘road' drive-in stops
| 39 | ◦ catenary needs to be provided for ‘road' drive-in stops
|
|---|
| 40 | | 40 | • overtaking: out of scope
|
|---|