Quast65's TramTrackSet (v002 released on BaNaNas 30-05-2023)

[Quast65]

MTR3 should still not have any powered or alternative types.

I took a short break, because of work, but also because my brain hurt

Ok, lets get on with this

I implimented the pow- and alt-lists as you suggested and indeed all seems to behave like it should, thank you for that!

Something handy to know:

If YYYY is in the powered_roadtype_list of XXXX (and XXXX in the powered_roadtype_list of ZZZZ), then:
- ONLY vehicles from the alternative_roadtype_list of XXXX will drive (and be bought) on YYYY.
- Vehicles added via XXXX (being in the powered_roadtype_list of ZZZZ) will NOT drive (and be bought) on YYYY



Now, before I go to tackle the possible issues with parameters to disable certain tracks, I want to get everything sorted, as if there are no parameters at all.
With that I mean adding vehicles from the R, P and I tramtypes of the scheme.
To include them, do I just need to change the lists of RAIL and ELRL to this:

Code: Select all

RAIL
Pow: RAIL, ELRL, MTR4, MTR5, MTR6
Alt: RAAN, RABN, RACN, PAAN, PABN, PACN, IAAN, IABN, IACN

ELRL
Pow: ELRL, MTR4, MTR5, MTR6
Alt: RAAE, RABE, RACE, PAAE, PABE, PACE, IAAE, IABE, IACE

And then those are done?
Because of MTR4, MTR5 and MTR6 being in the pow-lists of RAIL and ELRL?

[Brickblock1]

Now, before I go to tackle the possible issues with parameters to disable certain tracks, I want to get everything sorted, as if there are no parameters at all.
With that I mean adding vehicles from the R, P and I tramtypes of the scheme.
To include them, do I just need to change the lists of RAIL and ELRL to this:

Code: Select all

RAIL
Pow: RAIL, ELRL, MTR4, MTR5, MTR6
Alt: RAAN, RABN, RACN, PAAN, PABN, PACN, IAAN, IABN, IACN

ELRL
Pow: ELRL, MTR4, MTR5, MTR6
Alt: RAAE, RABE, RACE, PAAE, PABE, PACE, IAAE, IABE, IACE

And then those are done?
Because of MTR4, MTR5 and MTR6 being in the pow-lists of RAIL and ELRL?

I am afraid this won't help (or do anything) as if RAAE is actually defined it won't run on MTR4-6, not to meantion that this isn't acording to the scheme which states that:

It is the vehicle set's responsibility to implement fallbacks to other appropriate surfaces. It is also up to the author to decide if they want to do it or not.

[Quast65]

if RAAE is actually defined

By what, another tramtrackset? As an actual label for a track?
I dont understand.

[Brickblock1]

By what, another tramtrackset? As an actual label for a track?
I dont understand.

yes that is what I meant, those vehicles won't end up on the MTR4-6 tracks then.

[Quast65]

yes that is what I meant, those vehicles won't end up on the MTR4-6 tracks then.

But isnt the only way to solve that then by placing MTR4-6 in the pow-list of that tramtrack in the other GRF?

[Brickblock1]

yes that is what I meant, those vehicles won't end up on the MTR4-6 tracks then.

But isnt the only way to solve that then by placing MTR4-6 in the pow-list of that tramtrack in the other GRF?

It is, which is why I wanted a parameter to dissable regular trams running on MTR4-6 so that the behavior is consistent with all of them.

[Quast65]

It is, which is why I wanted a parameter to dissable regular trams running on MTR4-6 so that the behavior is consistent with all of them.

Ok, so that means that when something is in brackets in the scheme, like R & P:

Example823.png (900 Bytes) Viewed 1363 times

That means, that if you have a set with tracks that should 100% allow those kinds of vehicles (so without brackets), in my case RAIL & ELRL, you need to provide a parameter to disable the allowance of those vehicles on the tracks with brackets?
To avoid issues with other tracksets?

And then I should still have this then:

Code: Select all

RAIL
Pow: RAIL, ELRL, MTR4, MTR5, MTR6
Alt: RAAN, RABN, RACN, PAAN, PABN, PACN

ELRL
Pow: ELRL, MTR4, MTR5, MTR6
Alt: RAAE, RABE, RACE, PAAE, PABE, PACE

And if the parameter is enabled, this:

Code: Select all

RAIL
Pow: RAIL, ELRL
Alt: RAAN, RABN, RACN, PAAN, PABN, PACN

ELRL
Pow: ELRL
Alt: RAAE, RABE, RACE, PAAE, PABE, PACE

If that is correct, then what about the I-vehicles?

[Brickblock1]

Ok, so that means that when something is in brackets in the scheme, like R & P:
Example823.png
That means, that if you have a set with tracks that should 100% allow those kinds of vehicles (so without brackets), in my case RAIL & ELRL, you need to provide a parameter to disable the allowance of those vehicles on the tracks with brackets?
To avoid issues with other tracksets?

The brackets mean that it is optional to implement the behavior. I honestly think that it is incredibly hard to make multible sets work together without making the two sets specifically compatible with each other, and this becomes impossible when when labels are remaped to nonstandard labels, in the same way your set does. By adding the parameter you make it so that your set is completely isolated which helps by not confusing players.

It would be possible to make multible sets compatible but this requiers all sets which define a surface to also define all stability classes and real labels would have to be used so that they are able to be overridden in case a set wants to provide more than one road with the same features. The problem with this is that parameters like the ones you have made wouldn't work retrofitting the standard would also be harder, but other than that it is probably better to be honest. The speed / feature class would probably have to be removed in favor of grf chosing there own completly unique labels as to ensure that labels don't get overriden, standardising some labels for industrial grounds could however make sense since you would rather have them override each other then having duplicates.

The choise it kinda up to you since you have made the first standardised grf.

And then I should still have this then:

Code: Select all

RAIL
Pow: RAIL, ELRL, MTR4, MTR5, MTR6
Alt: RAAN, RABN, RACN, PAAN, PABN, PACN

ELRL
Pow: ELRL, MTR4, MTR5, MTR6
Alt: RAAE, RABE, RACE, PAAE, PABE, PACE

And if the parameter is enabled, this:

Code: Select all

RAIL
Pow: RAIL, ELRL
Alt: RAAN, RABN, RACN, PAAN, PABN, PACN

ELRL
Pow: ELRL
Alt: RAAE, RABE, RACE, PAAE, PABE, PACE

If that is correct, then what about the I-vehicles?

This is correct exept that PAXX should not be in there as vehicles should handle that by themselves it as. implementing it like this could cause issus if multible sets are loaded.

[Quast65]

This is correct exept that PAXX should not be in there as vehicles should handle that by themselves it as. implementing it like this could cause issus if multible sets are loaded.

I see, hence the R in the "Recomended vehicle set fallbacks"-column.
The vehicleset should then have something like

Code: Select all

FALLBACK_PASSONLY_VEH01: [PAXX, RAXX]

in the roadtypetable
and the vehicle in question should have

Code: Select all

road_type: FALLBACK_PASSONLY_VEH01;

in its properties.

So, nothing for me as a trackset-developer to worry about.
I do now see however, that I need to include a G-fallback in my metrovehicleset...

The other issues...

OK, then let's say I will relabel my tracks to the standard then!

Again, the disable parameters are set aside for the moment.

Should I relabel as follows then:

Code: Select all

MTR0 -> MAB3
MTR1 -> MBB3
MTR2 -> MCB3

MTR3 -> MAc3

MTR4 -> RABZ
MTR5 -> RBBZ
MTR6 -> RCBZ

Correct?

EDIT:
And

Code: Select all

INVI -> EABN

ofcourse..

[Brickblock1]

The other issues...

OK, then let's say I will relabel my tracks to the standard then!

Again, the disable parameters are set aside for the moment.

Should I relabel as follows then:

Code: Select all

MTR0 -> MAB3
MTR1 -> MBB3
MTR2 -> MCB3

MTR3 -> MAc3

MTR4 -> RABZ
MTR5 -> RBBZ
MTR6 -> RCBZ

Correct?

This isn't an incorrect implementation but it would have issues if multible sets are loaded since RABZ, RBBZ and RCBZ could get overriden which isn't ideal, as such I would recommend giving them non standard labels which would still work as vehicles would then not be expected to use them. This would however mean that there is no MAC3 which causes issues.

If we want full compatibility we would also need every set to define all terrain/stability classes (A-C) for a given surface and electrification. You set does currently not have these which means you would have to add MAA3 and MAC3 these would need new graphics or be made hidden but making them hidden has the dissadvantage of possibly hidding it even if another grf provides a nonhidden one. this could be solved with a parameter or possibly by trying to find the tramtype with tramtype_available(MAX3) this check would then need to be placed before the definition inside of the grf. It would still however be neccesary to define these types in order for them to be used to power whatever out of standard labels have been defined (such as the ones replacing MTR4-6). I might be able to provide an example later today.

It might also be worth considering giving MTR1 and MTR2 their own out of standard labels in order to avoid overrides, but I would not consider this as importand as in the case of MTR4-6 as they aren't as destinctive.

Code: Select all

RAIL -> RABN
ELRL -> ELRL (RABE in alt)

New: RAAN
New: RACN

New RAAE
New RACE

New: MAA3

MTR0 -> MAB3
MTR1 -> MBB3 or MTR1 
MTR2 -> MCB3 or MTR2

New: MAC3 

MTR3 -> MAc3

MTR4 -> MTR4
MTR5 -> MTR4
MTR6 -> MTR4

The ones marked with new would need new graphics or be hidden. The regular rail ones would only have to be provided if they are found to exist since you are only making them compatible with MTR4-6 and not really defining them since you recommend combining your set with another one. PAXX would also need this treatment. This is geting complicated and seams to be a bit too complex, especally with all of the diffrent types of electrification that would need to be checked. I am not even sure it is possible to fit all of the checks in the 64 road and tramtype limit.

[Quast65]

So possibly 5 hidden tramtypes!!?!!???
That is a huuuuuge waste of the very scarce ID's.

This is geting complicated and seams to be a bit too complex.

Well, it already was for me and now it's even getting worse.
I am getting very irritated with myself for not being able to understand it and therefor I am making a major decision.

I am giving up trying to make this set compliant to the scheme.
I have to accept the fact that I dont get it and that I am never going to get it to work the way I would want it to work and I am just wasting my time (and more importantly Brickblock1's and Kreumelchen's time) now and getting very frustrated.
I will add a disclaimer that this set is to be used at the users own risk and may not be compatible with other road/tramtrack-sets.

As this is a GPL-licensed project, others are very welcome to pick it up in future and do make it compatible to the scheme.


I will make the fallback change to the metrovehicles, so that at least those are ok.
But sadly my tramtrackset (and a roadset I am working on) will not be, because of the limitations of my intelligence.

Thank you Brickblock1 for your very kind help and patience in trying to explain it to me, but I just dont get it...
Maybe some day in the future.... (I doubt it)

[Argus]

What exactly is the problem? If the set cannot be coordinated with other tram sets, it will simply be used separately. Five hidden types would completely eliminate the possibility of use with URatt. As a standalone tram set it seems OK.

[Quast65]

What exactly is the problem?

I would have loved this set to be fully compliant with the Standard Label Scheme.
For that, it should be ready for all of the vehicle-labels that should be allowed on the tracks according to the scheme (even if those vehicles dont exist at the moment), it should also provide all of the tracks that according to the scheme it should provide, but it also should be prepared to be used with other tracksets that use the scheme (even if those tracksets dont exist at the moment).
This is proving to be too complicated for me to understand, the puzzle is just too difficult and it will be even more difficult if you take in account that I want tracks to be disabled via parameters (which would change what tracks should accept what vehicles, etc etc).
It's something that I am not able to do.

[Argus]

Oh, now I understand.You want to avoid problems with predicted future sets of vehicles, but I guess you can't predict everything anyway. There are also different issues between vehicles and road sets. Multiple road sets together don't work properly either, so it's no wonder with trams - I didn't even report that CZTR trams don't want to run under the roof, because I know that CZTR sets generally have compatibility issues.

[Quast65]

V002 released on BaNaNas.
See changelog in first post for what is changed.

Sources:

Q65TRAMS_v002.rar

(1.78 MiB) Downloaded 35 times

[Quast65]

but I guess you can't predict everything anyway.

Smarter people than I, may be able to. I'll leave it up to them if they want to make this set to fully comply with the scheme

I didn't even report that CZTR trams don't want to run under the roof, because I know that CZTR sets generally have compatibility issues.

I think that their set uses their own (so not the standard RAIL or ELRL) labels for their trams, therefor they wont run on my (and many other, like Uratt) tracks.

[kamnet]

Also consider the fact that maybe the standardization scheme itself is not right and needs to be further developed?

[Argus]

This is possible, after all, NRT itself is a relatively young thing - and children's diseases can be assumed

[Kruemelchen]

Also consider the fact that maybe the standardization scheme itself is not right and needs to be further developed?

To be honest, if the standardization scheme is too complex, it won't be very usable and thus fail its reason of existence

If we want full compatibility we would also need every set to define all terrain/stability classes (A-C) for a given surface and electrification.

I don't understand why all terrain/stability classes should be always provided as road/track?
What harm does it do to not provide them?
If another set is loaded, which provides those, the compatibility would work just as intended, as long as pow and alt lists are correctly set up, or not?

This is proving to be too complicated for me to understand, the puzzle is just too difficult and it will be even more difficult if you take in account that I want tracks to be disabled via parameters (which would change what tracks should accept what vehicles, etc etc).

To be honest, I cannot really follow this level of complexity either ...

I would probably make a dumb stupid implementation by having one or two non disable-able tracks, which would manage ALL compatibilities; and the rest would be optional tracks. And I probably would ignore any possible changes in the compatibilities
As far as standardised track labels are concerned, I would use them for standard tracks. Mind, that your compatibilities stay intact even if the track is overridden, so this shouldn't pose any problem.

[Brickblock1]

I don't understand why all terrain/stability classes should be always provided as road/track?
What harm does it do to not provide them?
If another set is loaded, which provides those, the compatibility would work just as intended, as long as pow and alt lists are correctly set up, or not?

The reason behind my statment was that I thought that it was neccesary to be able to use roadtype_available(roadtype) which it is if you want to only define certain roadtypes if they already exist, but I have noticed that this isn't a good way of doing compatibility.

It is probably better to have the sets add roadtypes that they don't define into the powered_roadtype_list asuming that the vehicles should be able to traverse those road/tracks. This does however currently not support having multible roads with the same features so that would have to be fixed by limiting the speed class to a smaller selection of letters, this would lead to roads being overriden which isn't ideal but there isn't much we can do about it. I do however think it might be worth standardising some types such as chips/irs ground and possibly covered roads/tracks, these would then use numbers in order to be not be interfering with other roads. This does have issues where we might have to update the spec in the future in order to allow more distinct types but I don't see a way around that.

Or we just don't make roadsets compatible with each other which would mean that the standard becomes easier to understand.