Loading

Revision differences

Old revision #pbccy01piNew revision #pf4sixzxy
1Spec  1NotRoadType Spec
2  2  
3Essential  3Essential  
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 subtypes in towns  35        ▪ too restrictive = can’t overbuild current subtype in towns
36        ▪ too permissive = deliberate or accidental breaking of existing routes by overbuilding incompatible subtype  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  
42Optional (proposed by frosch)  37Optional (proposed by frosch)  
43• split global toolbar to ‘road’ and ‘light rail’  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