Proposal for a Roadtype standard.

[Brickblock1]

Should we consider this finished? It would seam that there are no other additions or changes neccesary.

I have moved this over to the main wiki now and I added Z based on conversation in quast65's
tram track topic.

https://newgrf-specs.tt-wiki.net/wiki/S ... ype_Scheme

[Auge]

Hello

I have moved this over to the main wiki now and I added Z based on conversation in quast65's
tram track topic.

https://newgrf-specs.tt-wiki.net/wiki/S ... ype_Scheme

Thank you.

Tschö, Auge

[Quast65]

I have a question/suggestion regarding the second letter in the label

Code: Select all

Speed / Feature [*X**]

Is there a special reason why vehicles can only use "A" and roads can use any character?

If not,
I feel that this property is underused and I would like to suggest to change it to:

Code: Select all

Position / Feature [*X**]

So position of the vehicle on the surface
With:
A
Normal Position (so if you select drive-left in the game-settings, those vehicles drive on the left and if you select drive-right in the game-settings, those vehicles drive on the right).
Nothing special here
B
Flipped Position (so if you select drive-left in the game-settings, those vehicles drive on the right and if you select drive-right in the game-settings, those vehicles drive on the left).
This may sound weird at the moment, but I have some eyecandy tramtracks in mind, where this feature would be very usefull for.
C
Centered/middle Position
These vehicles will drive in the exact middle of a surface (like for example GarryG's marching soldiers).

I think this way it may be possible to keep those kinds of "special" vehicles constricted to only certain roads/tramtracks and not wonder off everywhere

Could this be considered?

[Eddi]

I have a question/suggestion regarding the second letter in the label

Code: Select all

Speed / Feature [*X**]

Is there a special reason why vehicles can only use "A" and roads can use any character?

it's not that they can't use other letters, but they shouldn't.

1. it makes no sense that a vehicle should be prevented from going on a 30km/h speed limit road, just because it's allowed to go 100km/h
2. if the road set doesn't contain more letters, your vehicle wouldn't be available at all

[Revenge_of_KioTheDev]

hi i want apologize for not discuss my edits to wiki page... https://newgrf-specs.tt-wiki.net/wiki/S ... ype_Scheme ...before i made them

my changes were just suggestion and if ok i would like to know if you think they are good idea
please excuse my english i have issues so is hard to type and good grammar. i get help from friend who help me edit wiki to explain some my ideas

First letter (surface/railtype) ideas
Road surface

• lowercase "p" for pipeline like utility truck roads
• undo my edit for uppercase "X" pipe crossing idea did not realize is not feasible without two roadtype

Tram rails

• lowercase "p" for power like wasteland
• uppercase "X" for crossings like suspended monorail and tram, or tram and bike lane, or bike below monorail

Second letter (speed/feature) ideas
Road speed or feature

• uppercase letters for speed variants
  • Hey, um... kio's friend here. I will explain because he can't get it out on the screen easily. The uppercase letters as speed variants means there can be 26 different speeds which is more than anyone would need, but because features are secondary afaik the idea is that you define the number of "non-unique" speeds your roadtype set has (e.g. if the roadtypes with R*BN like RABN, RBBN, etc. are in six different speeds, A to E, and that's the most that any X*XX combination of system, terrain and energy source has, then you reserve speeds RABN to REBN) and then use lowercase letters to define things like cosmetic variants of roads or eyecandy from tramtypes. If you somehow manage to use all 26 lowercase letters on a single system, terrain and energy source (kio says that's not possible because there's a 64 roadtype-tramtype limit to conserve?) then and only then is when you would resort to uppercase letters for more road features because no other grfs could be loaded without breaking the limit at that point(?)
• undo my edit for uppercase "X" pipe crossing idea did not realize is not feasible without two roadtype

Tram speed or feature

• lowercase "p" for pipeline like wasteland or utility truck roads
• uppercase "X" for crossings like suspended monorail and tram, or tram and bike lane, or bike below monorail

Third letter (terrain/stability) ideas

• lowercase "b" has no support by the standard for terrain so it seems like if grf mod dev want to make roadtype inherently incompatible with most vehicles for reason then maybe use it? not sure may be bad idea
  
  Fourth letter (energy source) ideas
  Road energy sources
  • lowercase "i" for invisible underground pipeline; driving on grass; road with invisible overhead power so bus and truck stop not clip graphics
  • uppercase "P" for pipelines; pipes need bridge or tunnel to cross roads
  • uppercase "S" for science-fiction roads/"smartroad"/self-driving car road that need internet connection or special tech to work
  • uppercase "X" for two or more energy source crossing like trolleybus and sci-fi road
  Tram energy sources
  • uppercase "M" for suspended monorail power source?
  • uppercase "P" for power lines; utility poles and those big towers like in one of GarryG's grfs
  • uppercase "S" for sci-fi trams and optic-guided bus
  • lowercase "i" for eyecandy catenary with power line (uppercase "P") support but no tram; lights, trees, fences or a tunnel
    • Me again. It came to mind that the note should instead read more like For eyecandy tramtypes with underground infrastructure, you should use EABX, EABS, EABG and EABE in the alternative_roadtype_list or alternative_tramtype_list for a road/tramtype using this energy source?
  • uppercase "X" for multiple power types like suspended monorail with tram tracks below

because i lose all my grf mod work to hard drive failure recently i not want to make roadtype mod grfs with these anymore but i think if these are judged and corrected by expert and added to standard then mod devs got better way to make or relabel niche roadtype like ice or racetrack and multiple tramtype like metro with suspended monorail by themselves with out troubles

also i see no track gauges listed for tramtype first letter? is oversight or on purpose? should gauge be part of third letter (terrain/stability) and use xXYZz or similar?

[Brickblock1]

I haven't had time to look at all of what you have written but I think that lowercase b isn't really neccesary since it could just as well us an out of standard id

As for track guage it simply wouldn't be of use since the limit for the amount of road/tramtypes is so small I also doubt it would really add any form of interesting gameplay.

[JohnFranklin523]

Just a reminder that I have made my JF Ratt Roads compatible with standardised roadtype scheme:

And it is players' decision whether "Town Road" is "RBBN" or "JF11".

jfrrtable-debug.png (68.21 KiB) Viewed 14522 times

** Edit: the former table was wrong; this should be the bug-free table. I misunderstood the scheme, and I have already uploaded the new version of JF Ratt Roads after realising that.

[Brickblock1]

It seems you have implemented it correctly with the exception of the default label of ROAD which you treat as universal instead of as equivalent to RABN which is the intended implementation so that vanilla and non standard vehicles don't go on the farm tracks.

I also really need to pick this up again to finnish it.

[Brickblock1]

I found another thing that you missed there isn't currently any remap for IAAN and IACN which is necessary since the vehicles would otherwise end up on the regular road or not be shown at all depending on what the vehicle sets prefers. This would be an easy fix since all you have to do is add this line to IABN:

Code: Select all

if (param[0]) {
	item (FEAT_ROADTYPES, item_industrial1_road, 19) {
		property {
			label:					"IABN";
			alternative_roadtype_list:   "IAAN", "IACN";
		}
	}

[Brickblock1]

I have now updated the wiki page to hopefully clarify the standard. I would now consider it fully functional but there may of course something that I have missed.

[+] Spoiler

Now all I have to do is to make a roadset of my own...

[Revenge_of_KioTheDev]

i look at my last post and rethink it because possibly too complex

Instead narrow down to few possible additions...

• X and x for multiple gauge of tramtype on same tile
• I for induction charge (can be used for reduced running cost when charging battery)
• i for energy source and eyecandy use with utilities
• X and x energy sources
  • X for when all tramtype can hypothetical run on all other tramtype (e.g. trams and trackless trams and utility crossing)
  • x for when all tramtype are mutual incompatible but can cross (e.g. trams and suspend monorail and weird tinted shapes "metro" tramtype and eyecandy)
    • can also use number label and alternative_tramtype_list if want more specific combos

is good?

[Auge]

Hello

• X and x for multiple gauge of tramtype on same tile
• ...
• X and x energy sources

is good?

Öhmmm, X and x for different gauges or for different energy sources?

Tschö, Auge

[Revenge_of_KioTheDev]

Hello

• X and x for multiple gauge of tramtype on same tile
• ...
• X and x energy sources

is good?

Öhmmm, X and x for different gauges or for different energy sources?

Tschö, Auge

both i put explain at bottom of wiki page in suggestions

[Lurkmore]

Oh, is this a thing yet? If so, can I get a link to a list or explanation of how this works?

[Brickblock1]

Oh, is this a thing yet? If so, can I get a link to a list or explanation of how this works?

It isn't used by much yet but It is complete-ish for now and imo ready to be used the wiki page explaining it is in this url https://newgrf-specs.tt-wiki.net/wiki/S ... ype_Scheme

Feel free to ask any questions if you so please

[Lurkmore]

Oh, is this a thing yet? If so, can I get a link to a list or explanation of how this works?

It isn't used by much yet but It is complete-ish for now and imo ready to be used the wiki page explaining it is in this url https://newgrf-specs.tt-wiki.net/wiki/S ... ype_Scheme

Feel free to ask any questions if you so please

Code: Select all

=== Terrain / Stability [**X*] ===
Describes the roughness of the road surface / trackbed stability, and thus the vehicle tier.
{| class="wikitable" 
|- style="font-style:italic;"
! Letter
! Meaning
! Powered Roadtypes
|-
| a
| Very slow / rough / light
| aA
|-
| A
| Slow / rough / light
| aAB
|-
| B
| Regular
| ABC
|-
| C
| Fast / stable
| BCc
|-
| c
| Very fast / stable
| Cc
|}

If all classes aren't defined by the road set, the other ones should be in the [[NML:Roadtypes#Roadtype_properties|alternative_roadtype_list (NML)]]. The same goes for tramtypes: [[NML:Tramtypes#Tramtype_properties|alternative_tramtype_list (NML)]].

Road vehicle sets should not implement fallbacks for terrain / stability.

Classes "a" and "c" are entirely optional for road/tramtype sets and should under no circumstances be used by vehicles.

I had a quick thought as I started tinkering with someone else's source code. Instead of lurking I just won't post any files; I only play alone and can't sprite due to color-blindness (as well as error-blindness, it seems), so I change the stats of stuff more to my liking. This is the first time I've looked into roadtypes or railtypes, and I don't know if the idea is any good, but...

Would a lowercase "b" as the third character (**b*) be a good solution for player-enforced "low clearance"? It would look the same but have something like "Road (Low Clearance)" in the name and stuff. The idea is you could set normal busses and anything shorter to PAbN, double deckers to PABN, and trucks to RABN. That would mean an RAbN tile could look the same as an RABN tile but busses and trucks that are too tall for a waypoint, tunnel or bridge will automatically take the fastest high clearance route. I don't know what kind of problems that would introduce, tho.

[Brickblock1]

Code: Select all

=== Terrain / Stability [**X*] ===
Describes the roughness of the road surface / trackbed stability, and thus the vehicle tier.
{| class="wikitable" 
|- style="font-style:italic;"
! Letter
! Meaning
! Powered Roadtypes
|-
| a
| Very slow / rough / light
| aA
|-
| A
| Slow / rough / light
| aAB
|-
| B
| Regular
| ABC
|-
| C
| Fast / stable
| BCc
|-
| c
| Very fast / stable
| Cc
|}

If all classes aren't defined by the road set, the other ones should be in the [[NML:Roadtypes#Roadtype_properties|alternative_roadtype_list (NML)]]. The same goes for tramtypes: [[NML:Tramtypes#Tramtype_properties|alternative_tramtype_list (NML)]].

Road vehicle sets should not implement fallbacks for terrain / stability.

Classes "a" and "c" are entirely optional for road/tramtype sets and should under no circumstances be used by vehicles.

I had a quick thought as I started tinkering with someone else's source code. Instead of lurking I just won't post any files; I only play alone and can't sprite due to color-blindness (as well as error-blindness, it seems), so I change the stats of stuff more to my liking. This is the first time I've looked into roadtypes or railtypes, and I don't know if the idea is any good, but...

Would a lowercase "b" as the third character (**b*) be a good solution for player-enforced "low clearance"? It would look the same but have something like "Road (Low Clearance)" in the name and stuff. The idea is you could set normal busses and anything shorter to PAbN, double deckers to PABN, and trucks to RABN. That would mean an RAbN tile could look the same as an RABN tile but busses and trucks that are too tall for a waypoint, tunnel or bridge will automatically take the fastest high clearance route. I don't know what kind of problems that would introduce, tho.

Thank you for adding that bit to the introduction (and fixing my spelling mistakes), even if I might not fully have understood this line:

it is recommended to think of standardized roadtypes vs. "fancy" roadtypes as a microcosm of the difference between a base set (OpenGFX) and a NewGRF that provides new graphics

Mostly due to the not quite understanting what the "fancy" roadtypes would be.

I think the idea of high and low clearance is quite interesting and it could certainly be a fun gameplay element but I don't really know how it would be supported by the standard. Using lowercase "b" in the third position is a bit problematic since it would really convolute the standard, It is on the other hand in some ways the best place to put it since putting it in the "power class" would be limiting those vehicles to conventional power systems. Using the "surface class" could work quite well but there are already a lot of paved types in there.

Treating I*** as high clerance could almost work since those are very similar in gameplay but this does of course not have the same flexibility of the other implementation. I do also doubt the need for standardising this since it is a very niche and would likely be used by three sets at most. This can to some extent be observed with how there aren't a lot of sets which use the axle classes from the railtype scheme I belive it is one unfinished track set and a few vehicle sets. That would of course not prevent it being implemented by the use of non standard labels which might work well in this case. There is also the slight issue in that there is sadly no way of preventing waypoints and stops for different roadtypes (tunnels is possible with jgrpp).

[Lurkmore]

...

Thank you for adding that bit to the introduction (and fixing my spelling mistakes), even if I might not fully have understood this line:

it is recommended to think of standardized roadtypes vs. "fancy" roadtypes as a microcosm of the difference between a base set (OpenGFX) and a NewGRF that provides new graphics

Mostly due to the not quite understanting what the "fancy" roadtypes would be.

I saw it here. A "fancy" roadtype or tracktype is (if I'm reading into this right) any label that doesn't use the standard and not a default label (ROAD or ELRL).

I think the idea of high and low clearance is quite interesting and it could certainly be a fun gameplay element but I don't really know how it would be supported by the standard. Using lowercase "b" in the third position is a bit problematic since it would really convolute the standard, It is on the other hand in some ways the best place to put it since putting it in the "power class" would be limiting those vehicles to conventional power systems. Using the "surface class" could work quite well but there are already a lot of paved types in there.

Treating I*** as high clerance could almost work since those are very similar in gameplay but this does of course not have the same flexibility of the other implementation. I do also doubt the need for standardising this since it is a very niche and would likely be used by three sets at most. This can to some extent be observed with how there aren't a lot of sets which use the axle classes from the railtype scheme I belive it is one unfinished track set and a few vehicle sets. That would of course not prevent it being implemented by the use of non standard labels which might work well in this case. There is also the slight issue in that there is sadly no way of preventing waypoints and stops for different roadtypes (tunnels is possible with jgrpp).

Leaving it explicitly optional but a minor part of the standard is probably the best option then?