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