Is "electrified_track" really a waytype? - should it be changed?

[Leartin]

In order to get electrification, you are required to write "own_waytype=electrified_track" - does an "electrified_track" exist as a waytype internally? Or is that only for historical reasons?

This format suggests several things:
* that you could have a way with that waytype, making it electrified from the get-go
* that there are similar waytypes like "electrified_road"
* that you could use wayobj to create double-gauges by having "own_waytype=narrowgauge_track"
* that you could create trams by having a road-wayobj with "own_waytype=tram_track"


To my knowledge, none of these are true. So of course my request is to implement all those It might be clearer if a boolean parameter called something like "electrification" or "is_electrified" was introduced for future use, deprecating the whole "own_waytype" thing.

[Ters]

Waytypes internally are basically just named numbers, and these names are somewhat different from the text values used in dat-files. I'm not sure why there is a named number overheadlines_wt. It is used two places. One is to mark a wayobj type as electrification or not. I don't know why it isn't just a boolean flag, because it is not accessible by anything but the pak format reader (which sets it) and the function which turns it into a boolean flag indicating that the wayobj is overhead electrification.

The other place it is used is for vehicle processing in makeobj, which suggests that it exists for historical reasons. If waytype is overheadlines_wt (which is what "electrified_track" is turned into), then waytype gets set to track_wt and engine type gets set to electric.

The third point is ruled out by the fact that path finding only pays attention to the way's waytype. Dual-gauge is perhaps better implemented with two ways per tile, like tram tracks on roads, but I am not sure how that works with reservation. It doesn't appear you would save anything on the infrastructure itself that way, just the cost in clearing the path for construction by only needing a path one tile wide.

I don't understand what you mean by the fourth point, as trams are not wayobjs. However, the waytype for trams is a bit peculiar if I remember correctly. Trams and their depots use the tram_wt waytype, but the ways are actually track_wt. And they can stop at stops with road_wt.

[Leartin]

Oh, no, these points are just what one would naturally conclude from the existence of "electrified_track" as a waytype in it's own right. If it actually was a waytype like "track" or "narrowgauge_track", it would mean that it could be used like the other waytypes, and the other waytypes could be used like it, leading to those assumptions.

My entire point is that even though the parameter is named "own_waytype", it has barely anything to do with a waytype. Say you wanted to introduce a rack railway in programming, being a functional opposite of electrification (only rack railway trains can use rack railway, but they can use everything else as well, as opposed to electrification trains that can only use electrified track, same as everyone else).
Would you then use "own_waytype=rack_track", or would you rather use something like "is_racktrack=1"?
And if "is_electrified" and "is_racktrack" wouldn't be dependant on a waytype, wouldn't that also mean they could potentially be integrated in a way itself?

...but those are all extra wishes, potential future development. For now, I just ask for an alternative to the own_waytype parameter, since it seems off and confusing.

[Ters]

Hmm, with half-heights, a rack wayobj could actually make some sense. But I don't like the own_waytype either. It pollutes the waytype enumeration with things that are not waytypes. The tram waytype at least as some justification for being a bit confusing. It would be better to have electrification and rack as its own wayobjtype. It would make makeobj slightly more complex in handling old format dat files that use waytype to require electrification for vehicles.

One could potentially allow way descriptor to also have an implicit wayobjtype. It would complicate the checks for electrification somewhat, but I don't think there are a lot of places where presence of electrification is checked. And one would probably want to forbid construction of wayobjs with the same wayobjtype as the way it is attempted built on.

[prissi]

A tram track is a normal track with sytem type (styp) 7, and an elevated way (or runway) is system type 1. (A normal track with styp=5 will be converted to monorail, and any way system type 255 will not show in the standard menu). Electrified_track has its own track number (it think 4), but only for historical reasons (i.e. simutrans loads old paks).

Narrowgauge tram track may work with waytype set to normal narrowgauge and sytp=7. But the trams were added more like a hack, so it may still have areas of the code that assume the waytype for tram is 1 (track). You have to try this out.

(Similar would be for monorails on roads, again system type 7 needs to be set additionally.)