News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Narrowgauge tram track

Started by Phystam, March 14, 2019, 01:57:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Phystam

Hello everyone,
I am developing a patch for simutrans-extended. Narrowgauge tram track—narrowgauge track on road.
Is this needed also for standard?
https://forum.simutrans.com/index.php/topic,18759.0.html

Leartin

If only you had suggested it earlier, P192C would not have needed to switch track and narrowgauge internally to achieve it...

Personally, I don't think a complete narrowgauge-tram (with it's own waytype, depot, vehicles,...) is strictly required. Paksets probably won't have two tram systems of different gauge, and it's technically possible to choose which gauge it is already (although a bit of work to retrofit).

However, there is not only the actual "tram_track", there is also the subtype 7 for tracks which works the same, and could be reused in narrowgauge (or other track types, for that matter). Not quite a narrowgauge tram, more to be used as less frequented tracks in industrial districts, when they get a delivery once a month.


I would be more interested in your "decoration"-waytype to be used for walls, and for those larger stations. I experimented with them before, but it seemed not feasable for a basic Pakset - perhaps that can change with proper waytypes.

To make sure it's used as such I'd extend your feature list:

  • not connected with other waytype such as track, road and so on
  • the stop for new waytype acts like an extension of station
  • can be constructed above existing station
  • does not allow for depot or vehicles


And while we are at potential waytypes: Perhaps another waytype that works like roads (bi-directional) to be used for suspension railways? Perhaps you could find use for it in Extended too.

Vladki

Yeah, ng tram should be a subtype for ng, (type 7) just like it is for normal track.

A bidirectional waytype for cable cars is also my long time wishlist item.

jamespetts

There is probably much to be said for the implementation of narrow gauge trams (even if not every pakset would use them); but there is also probably also much to be said for implementing them in the same way as standard gauge trams. I cannot immediately remember how the code differentiates tram and rail at a low level in Simutrans (it is unchanged between Standard and Extended), but it would certainly make sense for this to be the same for the different types of trams.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

#4
Quote from: Vladki on March 14, 2019, 10:22:24 AM
Yeah, ng tram should be a subtype for ng, (type 7) just like it is for normal track.

Because I think that it's a bit confusing, I'd like to reiterate:
Trams exist as both, subtype 7 and as it's own tram_track waytype. The tram_track waytype is what allows us to have tram-bridges, tram-tunnels, tram-signals, tram-elevated-ways, tram-way-objects, tram-depots and tram-vehicles. The subtype 7 only allows us to place tracks on roads.
Not sure how it works internally, but I don't think we need a tram_narrowgauge_track waytype and all it encompasses, just subtype 7 - just tracks on road.

Vladki

Yeah nice summary. I'd just like to say that tram signals do not work...

prissi

Many narrowgauge mainline trains run on roads too, like in Montreux or the Furka-Oberalp.

The Tram track was a one off hack introduce a month before Hajo quit and left me with everything. At that time we did not even had narrowgauge, only a rudimentary monorail track.

Using system_type would allow to run run all kinds of mainline narrowgauge trains on tram tracks. However, if the speed limit is low enough, those mainline trains could never make any money on such slow track. (Experimental may use some weight constraits to avoid this problem.)

Extending the number of waytypes is certainly possible (there is no reason to use them as bitmasks like now). This would be needed to have a separate depot, jsut lke now (bridges and tunnels could either use normal narrowgauge track, like in reality, or is built on roads if sharing.)

jamespetts

Quote from: Vladki on March 14, 2019, 02:26:38 PM
Yeah nice summary. I'd just like to say that tram signals do not work...

If this is a bug in Extended, I should be grateful if you could open a new bug report thread in the Extended development subforum.

Quote from: prissi on March 14, 2019, 02:59:24 PMMany narrowgauge mainline trains run on roads too, like in Montreux or the Furka-Oberalp.

Indeed - and there is a small section of tramway in Porthmadoc used by the Welsh Highland Railway, which is 2ft narrow gauge.

Quote from: prissi on March 14, 2019, 02:59:24 PM
Using system_type would allow to run run all kinds of mainline narrowgauge trains on tram tracks. However, if the speed limit is low enough, those mainline trains could never make any money on such slow track. (Experimental may use some weight constraits to avoid this problem.)

Extending the number of waytypes is certainly possible (there is no reason to use them as bitmasks like now). This would be needed to have a separate depot, jsut lke now (bridges and tunnels could either use normal narrowgauge track, like in reality, or is built on roads if sharing.)

What probably needs consideration in this thread is the extent to which is is worthwhile for Phystam to implement this patch for Standard and then backport it to Extended, or whether it would be better for him to produce a patch just for Extended.

Extended does indeed have systems (a different revenue model not based on speed at all) to allow profits to be made by slow vehicles; but even in Standard, small sections of narrow gauge road running for main-line narrow gauge trains, or dedicated narrow gauge electric trams (or  some combination of the two, as in the Isle of Man, where a narrow gauge electric tram runs on dedicated tracks between towns and on the roads in the main towns) might be of use notwithstanding the different method used for calculating revenue there.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I think this is worth implementing for standard as well. There are many examples of ng trains running part of their way on road worldwide (Switzerland, slovakia) or ng tram running between cities on dedicated track (Liberec, cz)

The problem with tram signals is in standard. Signals with waytype =tram are simply ignored, you have to use train signals. I have not tried that in extended.

jamespetts

There are no tram signals encoded for Pak128.Britain-Ex, but there is no problem using train signals, so I do not think that this is a bug.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Phystam

Sorry for late reply. As conclusion of your opinions,
- narrowgauge tram track should be implemented
- decoration waytype should also be implemented
And further, if it is possible, user-defined waytype (this is extension of waytype_t number) is needed. waytype_t is defined using enum, so maybe we have to change the descriptions...

jamespetts

This seems sensible - although whether such a thing is implemented in Standard will depend on the views of the Standard developers. It would be useful to know the appetite for integrating such a patch before Phystam takes the effort to write one for Standard.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

My guess is that at some places the implicit assumption of system_type=7 means track must be removed; maybe just adding 16 in this case to the waytype and change waytype 7 (the olf tram_track) to 18. That way also maglev etc. could get road tracks. I think the changes might be not so big as that they could not easily ported to experimental. Probaly also with makeobj support (system_type=7 means adding 16 too base waytype.)

I rather expect experimental to have more troubles, since there are much more options to be considered. Or the other way round, if the changes were simple, one could do a similar thing in standard manually.

prissi

Since experimental got their narrowgauge tram track, any chance to apply this to standard easily? Is there a more or less complete patch file?

Vladki

Quote from: prissi on February 24, 2020, 12:35:41 PM
Since experimental got their narrowgauge tram track, any chance to apply this to standard easily? Is there a more or less complete patch file?

oh, really? I have missed that

Mariculous

It was discused but, I don't think it was implemented yet.

jamespetts

I do not believe that this has been added to Extended yet.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Phystam

#17
Now I am considering to restart this project again; Further my consideration, I found some solutions.

1. use system_type instead of separation of waytype.
Most of system_type are not used -- only 0,1,7,64, 255 are used. we can assign other system_types for decoration way or normal way.
For instance, when system_type is set from 128 to 191, these are assumed as decoration way. in default, these can be connected to a normal way, but if decoration_way=1, it is treated as a decoration way, that is separated from a normal way (system_type=0,1,7). And when the system_type number is odd, it is treated as an elevated decoration way.

2. use system_type for stops
If system_type=x is set in stops, it can be built on the specified way only. Menuconf is also separated using 2 arguments. if there is only 1 argument, you can build it on a normal way.
Since this is not a ""real"" stop, it doesn't show harbor/airport/monorail mark on the minimap, and it is treated as other financial information.

Using this, you can separate some ways, for example normal railway and Shinkansen/normal road and motorway. In extended there is the way_constraint feature, so I think it is very useful.

Leartin

System type for stops would be great! Even without a decoration waytype it would be useful for elevated ways which need elevated stations, or tram stops which shouldn't block the road.

Phystam

Yes, it is useful, too :)
Is it useful to use multiple selection? e.g. system_type=0,1,127,128

Flemmbrav

If you're already at it and add stops, you might want to add signs/signals too.

Leartin

Quote from: Phystam on March 02, 2020, 11:35:16 AMIs it useful to use multiple selection? e.g. system_type=0,1,127,128
Yes. This would allow you to have a stop that works for both normal and elevated track, but still disables it for a hedge or wall.


Quote from: Flemmbrav on March 02, 2020, 10:14:49 PM
If you're already at it and add stops, you might want to add signs/signals too.
...and wayobjects, crossings, bridges, depots and vehicles... oh, wait, now we basically got additional waytypes (No change in routing, or anything, just by having restricted which vehicles can go into which depot by "system type" and which depots can go on which ways based on "system type" - and using 'decoration_waytype=1' so the way of that system type it wouldn't connect...

I'm exaggerating a bit, but one should think about it - not necessarily in a positive sense, since it would be very hackish if actually done like that.
(I assume Flemm only really wants to have tram signals, but still - tram electrification is just as useful, crossings need a solution so a hedge won't turn into track if it's planted on a road, bridges should not allow regular stops on them, but stops for elevated ways, you wouldn't want players to build depots on hedges and let trains run on them so depots would need it too. All that's left would be vehicles, but at that point, would it be a large step?)

Vladki

Really, wouldn't it be better to have decorations (noise walls) as completely separate waytype, and not a system_type of some existing way?   Thus they would not connect to existing ways, and you could make crossings (i.e gates).

And then focus on getting trams (system_type=7) work better - i.e have narrowgauge trams, tram signals, tram stops,...

Phystam

Basically it is not necessary to use "tram_wt" or "narrowgauge_tram_wt" internally. It should be "track_wt" or "narrowgauge_wt" with syatem_type=7. Probably there is no harm even if it is obsolete. It is very confusing.
How to deal the financial information of tram-like waytype is an issue. It is also hard-coded.

Phystam

In my further brainstorming, I got a completely new idea — we can use newly developed waytype_desc_t and finance_desc_t, and obsolete existing hard-coded waytypes and financial information.
Track, narrowgauge, monorail and maglev have the almost same behavior, so we must not have duplicated codes. Using waytype_desc_t, we can integrate duplicated codes for waytypes.

And my comment: Such existing coding style may cause some bugs. There are so many switch-case statements currently. In my thoughts, we can delete them using my system.

Mariculous

Quote from: Phystam on March 04, 2020, 06:21:20 AMTrack, narrowgauge, monorail and maglev have the almost same behavior, so we must not have duplicated codes.
I am absolutely with you, that would be great! From a maintainance viewpoint the current implementation using repeated code is awful. In the past I had found some bugs with narrow gauge that didn't exist for normal rail.

Imho, waytype of all these is rail, whilst system type differs, but you are much more in the details to decide this.
Further, it would be nice if system types could be specified in dats rather than being hardcoded and further compatibility* to other way or system types could be specified there.

*compatibility means
1. on which way+system type can it be placed without creating a level crossing. e.g. tram tracks on roads or narrow gauge on normal gauge rails.
2. to which system type of the same waytype can it connect. There might be vehicles capable of multiple system types like trams, or some multi gauge trains.

Leartin

Quote from: Phystam on March 04, 2020, 06:21:20 AM
Track, narrowgauge, monorail and maglev have the almost same behavior, so we must not have duplicated codes.

It probably would be even better if behaviours could be applied to ways, rather than just allowing multiple ways with one predefined set of behaviours. What if you could define a bidirectional track - or in other words a road where each vehicle reserves up to the next signal? That would be perfect for something like the Wuppertaler Schwebebahn. On the open ocean, the ship-stacking may make sense, but on rivers, a road-like approach could be better, especially since changing the waytypes opens up the abilitiy to limit access of ocean steamers to rivers and vice versa. (Eg. small rivers work like roads and only allow small boats, larger rivers work like rivers do now and allow small boats and large boats, but only large boats can navigate the ocean).


But you should really look through the code where hardcoded waytypes are expected. Probably everywhere - this would be a huge task.

Vladki

Quote from: Leartin on March 04, 2020, 05:13:54 PMWhat if you could define a bidirectional track - or in other words a road where each vehicle reserves up to the next signal? That would be perfect for something like the Wuppertaler Schwebebahn.

Yeah that is on my persona wish-list for long time...

Quote from: Leartin on March 04, 2020, 05:13:54 PM(Eg. small rivers work like roads and only allow small boats, larger rivers work like rivers do now and allow small boats and large boats, but only large boats can navigate the ocean).

That is already done in extended - using the way constraints. They are used also for different electrification types (AC, DC, 3rd rail, ...)

So the question is is it worth to do a huge rework and join all rail like transports (rail, ng, monorail, maglev) into one waytype, and use system type to distinguish them? That would be really nice, and could allow for more types - e.g. broad gauge trains, or decorations; or - based on roads - cable cars or pipelines.

Mariculous

Quote from: Leartin on March 04, 2020, 05:13:54 PMEg. small rivers work like roads and only allow small boats, larger rivers work like rivers do now
What exactly do you mean by "work like roads"?
You mean there should be two lanes per river/canal and ther should not be multiple boats at the same tile?
In principle I support this.
That would make harbours/docks much more realistic as players are forced to build proper harbors that have enough capacity to store the boats.
However, I don't understand why this should not apply to large rivers or canals.
Another point is that we should first allow both "lanes" to be used for waiting at terminal stations.

Phystam

Powerline has weird image assignment; it doesn't have actual diagonal image, but uses diagonal image as skip image.
It should be consistent with other waytypes. Introducing proper new images for "skip powerline tower" is one option, and it enables to make motorway/runway with wider white dashed line distance.

Leartin

Quote from: Freahk on March 04, 2020, 08:33:24 PM
However, I don't understand why this should not apply to large rivers or canals.
It doesn't matter where the break is, all rivers could work just like roads - but the point is that it would be possible to have these things. Since we are explicitly talking about a modular approach without hardcoding, it would be up to paksets which behaviour to use.