Transport Tycoon Forums

michael blunck wrote: Well, seems that this scheme should include all imaginable rail types now.

there was a time when the british patent office closed, because they believed all imaginable inventions have been made by now...

the purpose of including "all" railtypes is that we have some definite reference for which "alternate" labels have to be provided when railtypes are left out.

- "TC" is redundant,

well, yes, but we need something to separate these track types following this scheme from the ones outside this scheme, e.g. the NUTracks-types which only model speed limit, or maglev/transrapid/monorail/shinkansen/whatever types

- use "E/e" for (normal, overhead) electrification, and "3" for "third rail" (electrification),

i had this before, but Snail wanted it differently

- for axle weight a letter should be used consistently, i.e., no "0" (zero),

can you expand on this, please? i don't see how you want to do this, without losing the correlation between the letter and the "real" track class.

we could scratch the usage of letters altogether, and use nibbles instead:

i.e. "TC" 01 23 (or "TC\01\23")
then 0/1/2/3 could be used to characterize speedlimit/gauge/axle weight/power

Maybe use a single "T" instead of "TC". There are currently no railtype labels in use that start with a T (TRPD is listed but not used). That frees up an additional position for use.

Eddi wrote:

- use "E/e" for (normal, overhead) electrification, and "3" for "third rail" (electrification),

The problem would be the "3". Michael himself said it would be an exception. If we keep the E/3 scheme, instead of the C/T, how can we differentiate NG between SG for 3rd-rail powered tracks?

Snail wrote:

mb wrote:

- use "E/e" for (normal, overhead) electrification, and "3" for "third rail" (electrification),

The problem would be the "3". Michael himself said it would be an exception. If we keep the E/3 scheme, instead of the C/T, how can we differentiate NG between SG for 3rd-rail powered tracks?

Simply from the other letters, being capitalized or not.

In any way, "E/e" and "3" are way more intuitive than "C/c" and "T/t".


W/r to the redundant "TC":

Eddi wrote: we need something to separate these track types following this scheme from the ones outside this scheme, e.g. the NUTracks-types which only model speed limit, or maglev/transrapid/monorail/shinkansen/whatever types

All labels must be unique, so there´s no need for wasting letters/numbers to only separate this scheme from others.

Eddi wrote:

mb wrote: - for axle weight a letter should be used consistently, i.e., no "0" (zero),

can you expand on this, please? i don't see how you want to do this, without losing the correlation between the letter and the "real" track class.

Well, there´s no need to stick to a German or RIV axle load scheme here, or is it?

Eddi wrote: we could scratch the usage of letters altogether, and use nibbles instead

I´d propose letters to keep it more intuitive.

regards
Michael

michael blunck wrote: Well, there´s no need to stick to a German or RIV axle load scheme here, or is it?

[...] to keep it more intuitive.

IMHO that's exactly the reason.

Eddi wrote:

michael blunck wrote: Well, there´s no need to stick to a German or RIV axle load scheme here, or is it?

[...] to keep it more intuitive.

IMHO that's exactly the reason.

Well, there are other (non-European) axle load schemes. But anyway, this leaves us with three possibilities:

- introducing fictitious identifiers for the axle load classes,
- shift the RIV scheme one up, i.e. lowest class "A/a" getting 13 tons,
- introducing a fictitous identifer for that 13 ton class, e.g., another letter, unused in the RIV scheme, or, in case you´re into that "zero", use this one. In any way, this would be only another number then.

Other than that, for the speed class there could be also letters or numbers.

regards
Michael

So why not using all the four letters then?
First letter: gauge (S = standard, B = broad, N = narrow, possibly M = metric)
Second letter: speed class
Third letter: axle weight class
Fourth letter: electrification system

Snail wrote: So why not using all the four letters then?
First letter: gauge (S = standard, B = broad, N = narrow, possibly M = metric)
Second letter: speed class
Third letter: axle weight class
Fourth letter: electrification system

Proposal:

First letter: gauge
S = standard, B = broad, N = narrow, possibly M = metric

Second letter: speed class
30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 180, 200, 220, 240, 250, 260, 280, 300, 330, 350, 360, >400 km/h -> [A .. Z]

Third letter: axle weight class
13, 16, 18, 20, 22.5, 25 tons -> [a, A, B, C, D, E]

Fourth letter: electrification system / special rail
0 - no electrification, no special rail
1 - rack
2 - overhead
3 - third rail
4 - overhead & rack
5 - third rail & rack
6 - overhead & third rail
7 - ...

E.g.:
SPD2 -> SG, 200 km/h, 22.5t, overhead
NBa1 -> NG, 40 km/h, 13t, rack rail not electrified

regards
Michael

Wouldn't this mean a huge number of possible railtypes labels? I imagine the compatibility lists we'd have to write in our codes would be extremely long...

michael blunck wrote:Proposal:

First letter: gauge
S = standard, B = broad, N = narrow, possibly M = metric

ok. that makes some sense

Second letter: speed class
30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 180, 200, 220, 240, 250, 260, 280, 300, 330, 350, 360, >400 km/h -> [A .. Z]

flat out: no. that's insane. you get insane compatibility troubles...

instead all vehicles should be defined for the A railtype, and the set provides B, C, ... types if it wants to have several different speed limits. the actual speed limits are responsibility of the track set, the vehicle set doesn't need to know them.

Third letter: axle weight class
13, 16, 18, 20, 22.5, 25 tons -> [a, A, B, C, D, E]

alright, i can live with that.

Fourth letter: electrification system / special rail
0 - no electrification, no special rail
1 - rack
2 - overhead
3 - third rail
4 - overhead & rack
5 - third rail & rack
6 - overhead & third rail
7 - ...

what happened to letters being more intuitive?

it looks like you're heading into a bitmask here, so it could make sense to do:
bit 0: catenary
bit 1: third rail
bit 7: rack
bit 2-6: reserved for future use (some insane people want 50Hz vs. 16.7Hz and AC vs DC or something)

Well, right before Michael wrote, I was thinking about another possible scheme, so I'll put in here now:

These might be possible railtypes, together with a description that could be a guideline for trainset creators' to define their track's limits. The numbers at the right are those I have in mind for my French Set.

My thought is that, to ensure the maximum compatibility without pigeonholing vehicle sets' creators, it would be best if this scheme only had loose definitions of max axle weight and speed, rather than defining specific values for weight and speed all the sets will have to comply with. Depending on the variety of rolling stock historically available across the countries, single trainsets might need their own limits in terms of axle weights, speeds, etc. as well as multiple railtypes of the same axle weight supporting different max speeds. "Common sense" should be what makes the sets ultimately compatible.
For instance, what should the max axle weight of a "light" engine be? IMO it should be around 15 or 16t. Perhaps the CETS will define it to 16t, whike the French set will define it to 15t; as long as all the trainsets have these thresholds at comparable levels, there should be no major compatiblity problems.
Same goes with max speed. For instance, some sets might need two types of "light" tracks, a slow and a fast one, while other sets could do with just one with the max speed set in between.

As for compatibility in case someone plays with a trainset and a trackset that support different tracktype labels, we could code the engines so that they're always compatible "upwards", i.e. to heavier tracks of the same gauge and electrification type. So, a "medium" catenary-powered engine should be compatible with SACE, SBCE, SADE, SBDE, SAEE, SBEE. Ideally, if a trainset defines an engine as "SADE" railtype, and it's used in conjunction with a trackset that doesn't support "SADE", then that engine should automatically be compatible and powered on the "SAEE" tracktype (if defined).
But perhaps this is over the top?

What do you guys think?

Snail wrote:What do you guys think?

I like it. It is specific enough to properly distinguish different engines in a set, but unspecific enough to allow cross-compatibility between sets.

Fixing speed and axle weight to exact values doesn't make sense IMHO because you'll always find a history example that won't fit. With a more loose definition set authors have discretion to select good track classes for good gameplay.

To ensure vehicle compatibility railtype GRFs should for example set all "lesser" track types as compatible/powered. If needed, the proposed alternate label patch could also be used so that a railtype GRF always exposes all defined track classes to vehicle sets while limiting the choices presented to the player. Not sure about that, maybe it would also be enough if vehicle sets install different railtype tables according to which labels are defined.

-- Michael Lutz

Michi_cc wrote:

Snail wrote:What do you guys think?

I like it. It is specific enough to properly distinguish different engines in a set, but unspecific enough to allow cross-compatibility between sets.

Fixing speed and axle weight to exact values doesn't make sense IMHO because you'll always find a history example that won't fit. With a more loose definition set authors have discretion to select good track classes for good gameplay.

right, if you see the axle limits as something "freely chosable", you could "compress" the scheme like this: this means if ever the french set and CETS are used alongside, you may experience some slightly suboptimal misalignments, but each one in itself will be consistent.

To ensure vehicle compatibility railtype GRFs should for example set all "lesser" track types as compatible/powered. If needed, the proposed alternate label patch could also be used so that a railtype GRF always exposes all defined track classes to vehicle sets while limiting the choices presented to the player. Not sure about that, maybe it would also be enough if vehicle sets install different railtype tables according to which labels are defined.

well the problem is that there is potentially an exponential explosion in the selections of available railtypes for the vehicle set to consider, which must be covered complex action 6/7/9/D, while with an alternative label list this is completely shielded from the vehicle set, and the railtype set has only linear size.

Eddi wrote:this means if ever the french set and CETS are used alongside, you may experience some slightly suboptimal misalignments, but each one in itself will be consistent.

Yeah, but I think this is acceptable. The precise track specs aren't really relevant for gameplay anyway (only for historical correctness). If you take the BR 01 and the BR 03 for example, it doesn't matter that one has an axle weight of 20t and the other of 18t. The only relevant thing is that the BR 01 was too heavy for a lot of the older tracks which lead to the development of the BR 03 for the lighter tracks, i.e. it is only important that the BR 01 runs on heavier track than the BR 03, but not on which precise track class.

Eddi wrote:well the problem is that there is potentially an exponential explosion in the selections of available railtypes for the vehicle set to consider, which must be covered complex action 6/7/9/D, while with an alternative label list this is completely shielded from the vehicle set, and the railtype set has only linear size.

We have a patch for that, so we could use if it makes sense.

-- Michael Lutz

Michi_cc wrote:

Eddi wrote:this means if ever the french set and CETS are used alongside, you may experience some slightly suboptimal misalignments, but each one in itself will be consistent.

Yeah, but I think this is acceptable. The precise track specs aren't really relevant for gameplay anyway (only for historical correctness). If you take the BR 01 and the BR 03 for example, it doesn't matter that one has an axle weight of 20t and the other of 18t. The only relevant thing is that the BR 01 was too heavy for a lot of the older tracks which lead to the development of the BR 03 for the lighter tracks, i.e. it is only important that the BR 01 runs on heavier track than the BR 03, but not on which precise track class.

That's exactly the point. The BR 01 could even be marked as a "heavy"-weight engine, and the BR 03 as a "medium" weight engine. So, if you want to use the BR 01, you'll have to upgrade the tracks to "heavy" ones; otherwise, you'll have to use the BR 03.

The trainsets that want to use this scheme just need to classify the engines by gauge, electrification type and weight (even approximately, if they don't want to go through the research of the exact max axle weight), and the tracksets would do the remaining part, deciding which engines can run where.

Eddi wrote:

mb wrote: Second letter: speed class
30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 180, 200, 220, 240, 250, 260, 280, 300, 330, 350, 360, >400 km/h -> [A .. Z]

flat out: no. that's insane. you get insane compatibility troubles...

Well, only to please all future railtype set developers. You know, I´m content with only a very small set of railtypes for my own train set (branch line, branch line electrified, main line, main line electrified, high-speed line electrified, everything more is moot).

Honestly, there are only two options for this "standardisation attempt":

- make a complete unified scheme, taking into account every possible real rail type,
- make small subsets which fit together in a best possible way.

Everything else is just labour in vain.

Eddi wrote: what happened to letters being more intuitive?
it looks like you're heading into a bitmask here

Yeah, that was the idea, because there could be a lot of combinations.

Eddi wrote: track_classes3.png [

You missed rack rail and its electrification possibilities.

regards
Michael

Why are we making this more complicated then it has to be when Nutracks was fine before. If you want certain speeds just set them your selves in the parameters. For my newgrf presets I have different speeds for Australia, North America, Europe, etc.

I do how ever think we could have a few more rail ypes or something like that but we dont need like a million rail types just to cover every unique network on earth. I think just being about to have different speed rails is good enough.

NekoMaster wrote:Why are we making this more complicated then it has to be

because one man's "complicated" is another man's "interesting".

when Nutracks was fine before.

that's where you're wrong. NuTracks isn't "fine", it's actually rather "boring". especially if you're building a freight network, you get away with using the cheapest and slowest railtype most of the times. that's where axle weight may give another interesting incentive to upgrade rails.

If you want certain speeds just set them your selves in the parameters. For my newgrf presets I have different speeds for Australia, North America, Europe, etc.

really, the whole discussion isn't about speedlimits at all (i said that in the very beginning, but some people don't listen)

the discussion is about three people doing something very similar, and getting them to do it in an interchangeable way.

Eddi wrote: really, the whole discussion isn't about speedlimits at all (i said that in the very beginning, but some people don't listen) [...]

Just for the record, I only mentioned "speed" because I see it in your tables. Personally, I´d be fine w/o any speed limits.

regards
Michael

michael blunck wrote:

Eddi wrote: really, the whole discussion isn't about speedlimits at all (i said that in the very beginning, but some people don't listen) [...]

Just for the record, I only mentioned "speed" because I see it in your tables. Personally, I´d be fine w/o any speed limits.

regards
Michael

Indeed, a much more interesting way of controlling speed would be through a combination of advanced signalling, and lineside markers, or the equivalent. That would obviously require a new feature though and is out of scope of the discussion here.

NekoMaster, it is indeed a very interesting discussion, if you are happy with how it was, you know what's to be said, use that version and be happy, no further need to comment on further developments