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