Topic: Early single track railways - how?!

[Vladki]

This turned out to a lengthy discussion. Just to elaborate my point earlier in the thread:
The distinction between time interval with telegraph and my proposal is that my proposal is making directional reservations with drive by sight. There would be no timer in the signal to enforce spacing between the trains. The datfile would be:
Working method=drive by sight
Longblocksignal=1

I think this actually was suggested once a while ago too.

Yes. Actually something like that is used even now, here in Brno, when they do some reconstructions on tram networks. Normally the whole network is double tracked, trams drive by sight, so no signals are needed (except for signals at crossroads, where trams go on the road with cars). But for reconstruction, they create a short (few 100 m) single tracked part (and repair the other track). There are signals on both entries that allow multiple trams to enter in the same direction. Trams have to drive by sight all time (even on double track). When the single track part is clear, trams from opposite direction can enter. So it is a combination of drive by sight and track circuit. For early years it would have to be something similar, just the negotiation of direction would not be track circuit but a token. All the problem is that the early forms of telecommunication (before electrical telegraph), were either expensive (optical telegraph), slow (courier on horseback), or unreliable (timetable, giving the staff to the last train), and at last not easy to properly implement in simutrans...

[jamespetts]

Yes, the real difficulty with this is accurately simulating the economic consequences of the inherent shortcomings in these systems.

[Ves]

Now I came to think about it, my solution would simulate a timetable backwards, meaning that wherever the train happen to be at a certain time is according to the schedule.
But it could be made a little bit more challenging and also add to the immersion that there is a time schedule:
The “state” if the post (clear, danger) can be set to automatically shift with a timer, very much like how the street crossing light is working in simutrans.
Three settings needed:
• Frequency
• Offset
• “Clear” duration

Then it’s the responsibility of the player to make realistic timing so the track is ever only traversable in one direction at all times.
Still it could create the directional reservation, and the player should be able to set the duration of the “clear” so multiple trains can go in one direction. The directional reservation would still be a good idea, since we assume all other train drivers on the map knows about the schedule and in which direction current travel is.
If two posts conflicts with their timings, either the directional reservation would take care of that, or it’s simply poor design by the player.

[jamespetts]

The trouble is that that would not actually simulate any specific real life signalling system, and it would conflict with the other systems which do simulate a specific real life signalling system in some detail. This is not how timetabled working of single lines actually worked - it would be better to add a mechanic that allows (if and to the extent this is not already possible) this sort of working.

One thing that I had wondered is whether it would be a good idea to implement a mechanic for automatically resolving head-on collisions: if two trains meet head-on, one (the one with the lowest load, or, if they both have the same load, the one with the lowest convoy number) reverts to its previous destination on the schedule. I should note that this may not work, however, when there is another train behind the one that collided head-on and reverses.

[AP]

I suspect that that would actually be much easier than the complexities involved in section staff signalling. What do you think that the minimum viable addition to the current timing system would be to allow for this?

The first difficulty is that Simutrans doesn't use 24 h time,  it goes to 6:24:00 each month.  This is really counterintuitive. It should be 24h.

Secondly,  wait for time operates only on whole fractions of that, not in minutes. This makes finely tuning a timetable really tricky. It should be in actual minutes.

There is no way to have the duration between departures longer than 6:24:00 which for long routes is sometimes necessary.

We now have routes recording the distance between stops, and the time taken for a complete circuit,  but not the time between stops. This complicates setting up stop departure times. There is no way to account for hills and corners, which make trains take longer than expected en route. There is also no way to simulate this data in advance,  which ought to be possible, since we have a simulation at our disposal ; instead one must waste time with a test train to get the data.

The current system uses "multiple departure slots per month" which sounds good,  but in single track operation is a minefield,  because usually there is only one slot that a particular train must use, if it misses it, it can't take the next one,  because that's required for a following train.  The timetable must simply be right. 

There is no easy way to build a timetable,  and check it is right,  apart from lots of trial and error,  fast-forwarding offline games to see if it works smoothly. And of course,  whenever vehicles are upgraded,  get faster,  the whole timetable needs redoing.  It almost needs an in game train graph on a per line basis. If such were added to the graph function,  showing time vs distance and all the vehicle movements that would really really help with setting up the waits so the paths crossed at the right loops etc. Because visual editors are so intuitive,  it might even allow the difficulties with the time system to become tolerable, as it would provide instant feedback of whether waits were too many /long etc.

The multiple slots per month is a bit misleading because in fact the intention is usually that each slot corresponds to a specific train. Sometimes you want trains to skip a slot, either because the passing loops are asymmetric or there is another line e.g. freight train which has to be allowed to weave amongst the passenger trains. There is no way to make trains skip slots e.g ever 10 mins except 20 and 30 past the hour.

[jamespetts]

The first difficulty is that Simutrans doesn't use 24 h time,  it goes to 6:24:00 each month.  This is really counterintuitive. It should be 24h.

Because everything is balanced to work with this timescale, and because this is derived from some fundamental aspects of the game, changing this would be an unimaginably huge undertaking. Doing this alone would probably take more than a year of intensive work. Accordingly, this is not feasible in the foreseeable future.

Secondly,  wait for time operates only on whole fractions of that, not in minutes. This makes finely tuning a timetable really tricky. It should be in actual minutes.

This might be a little easier, but I am not sure quite how difficult that this would be. However, this would then make it harder to use the system as it was intended, viz. as a simple frequency regulator.

There is no way to have the duration between departures longer than 6:24:00 which for long routes is sometimes necessary.

This might be relatively straightforward - I will have to look into this to check. This might be possible by allowing fractions of a month to be expressed in quantities greater than 1 (e.g. 12/10ths of a month) without changing the system of having this in fractions of a month.

We now have routes recording the distance between stops, and the time taken for a complete circuit,  but not the time between stops. This complicates setting up stop departure times.

A third party developer has actually produced code for this, which I will hopefully be testing and integrating when I get back home, so this is in preparation.

There is no way to account for hills and corners, which make trains take longer than expected en route. There is also no way to simulate this data in advance,  which ought to be possible, since we have a simulation at our disposal ; instead one must waste time with a test train to get the data.

Simulating this in advance would be difficult in the extreme, as one would need to run a full simulation of all the physics, all the signalling and the whole traffic on the route, so this is not likely to be feasible in the foreseeable future.

The current system uses "multiple departure slots per month" which sounds good,  but in single track operation is a minefield,  because usually there is only one slot that a particular train must use, if it misses it, it can't take the next one,  because that's required for a following train.  The timetable must simply be right.

I do not understand what you mean by "must simply be right". Can you elaborate?

There is no easy way to build a timetable,  and check it is right,  apart from lots of trial and error,  fast-forwarding offline games to see if it works smoothly. And of course,  whenever vehicles are upgraded,  get faster,  the whole timetable needs redoing.  It almost needs an in game train graph on a per line basis. If such were added to the graph function,  showing time vs distance and all the vehicle movements that would really really help with setting up the waits so the paths crossed at the right loops etc. Because visual editors are so intuitive,  it might even allow the difficulties with the time system to become tolerable, as it would provide instant feedback of whether waits were too many /long etc.

That would be a very large amount of work indeed. I should note that, in reality, timetables are exceedingly difficult to set up, which is why I have not allowed for more detailed timetabling before (the departures/month idea is really just about having a regular service, rather than a specific timetable, which is why it is in fractions of a month).

If actual timetabling cannot sensibly be achieved without this sort of extreme complexity of additional work, it is probably not worth doing at all, especially if players need (or are lead to believe that they need) to master this sort of complexity just to play.

The multiple slots per month is a bit misleading because in fact the intention is usually that each slot corresponds to a specific train. Sometimes you want trains to skip a slot, either because the passing loops are asymmetric or there is another line e.g. freight train which has to be allowed to weave amongst the passenger trains. There is no way to make trains skip slots e.g ever 10 mins except 20 and 30 past the hour.

Given these descriptions, full timetabling is simply not feasible, either for players to deal with sensibly in the game, or for me to code. The amount of work required for coding all of these features would be measured in multiple years, and it would make it extraordinarily difficult for new players to interact with the game.

I suspect that what would be preferable to detailed timetabling mechanics, which are not feasible, are some relatively straightforward conditional provisions in schedules (e.g. "depart when convoy X reaches point Y in its schedule"). Such conditional provisions may well be necessary for some planned features in any event.

[AP]

By "must simply be right"  I meant that a timetable for a single track route,  if commenced with errors in it, will quickly unravel and gridlock. On a double tracked route,  scheduled departure slots work rather well because there is no need to account for returning trains. On a single track route,  if one mistakenly allows insufficient time somewhere,  it will just gridlock. Then you have to send everything to depot and start again.  The player has to know with confidence they have everything right before commencing the timetabled service.

Your points about complexity and coding time are understood and appreciated,  it's why I was presuming setting up a simple staff working model would be the easier course of action.

Personally I don't think timetables are the way to go.

[Vladki]

The trouble is that that would not actually simulate any specific real life signalling system, and it would conflict with the other systems which do simulate a specific real life signalling system in some detail. This is not how timetabled working of single lines actually worked - it would be better to add a mechanic that allows (if and to the extent this is not already possible) this sort of working.

I think I have read somewhere about such system, but now I cannot find the reference. It was something like odd hours one way, even hours the other way, with some time (half-hour) left to clear the line.

[jamespetts]

The trouble is that both timetabling and section staff working would be a huge undertaking; the sort of section staff working that you envisage above would be by far the most complex of all the signalling systems so far to be implemented, and there is still, as far as I can see, no sensible way of dealing with terminus stations with multiple platforms where trains may start their journey into the single track section from either platform.

That is why I suspect that conditional schedules are probably the better solution.

[Ves]

If you implement conditional scheduling, that would be awesome, and perhaps if it in general would open of for more advanced schedules. Remember, there are other areas that could benefit from that, like “only load x amount of cargo” “only load cargo y” etc. but that is another topic.

Still though, I think the signal I and vladki talk about could have some potential. It would indeed simulate a time table in its own way, and yes, the player would have to think ahead before setting it up, just like with most of the other working methods.

[AP]

There is still, as far as I can see, no sensible way of dealing with terminus stations with multiple platforms where trains may start their journey into the single track section from either platform.

Yes there is; you just include a "loop" immediately outside the station platforms, with the single track block section commencing at the end of it. The loop and terminus are "drive by sight".

So long as each block section ends on a loop, it doesn't matter what is beyond the loop, for the purposes of operating the single track section. You can put a junction, terminus, or anything, beyond the loop and solve them on their own terms. So long as the train entering and exiting the single track section can pass, all is well.

[Dutchman on Rails]

Chiming in on this with a possible alternative.

As we know from the signalling system, Simutrans Extended is capable of 'seeing' up to 875 meters ahead. This because of 'seeing' the signal. We also know that trans can 'push' a reservation ahead. In the drive by sight method this reservation is turned off, probably to avoid trains running up behind each other.

The issue with drive by sight in single track railways is that the drivers can see each other, but just keep running into each other.

Perhaps the combination could work out with the following rules:

1. A train in the drive by sight method 'pushes' a reservation ahead as far as the line of sight of the driver, or as far as it encounters the edge of another reservation block, or another train.

2. A driver will stop if the front encounters a reservation block normally.

In that way it's up to the players. One must ensure that the line of sight extends into the next passing loop, so no more than 875m or 7 tiles ahead on the straight and level. So it does have its limitations.

[jamespetts]

Is a requirement to have a passing loop every 7 tiles likely to be worth bothering to have single track at all? Did very early single track railways actually use this system?

[Dutchman on Rails]

About the systems you'd have to send a mail to the National Railway Museum or the Science Museum. Normally such museums have a few volunteers to explain such things. I do seem to remember that early railways often simply pushed the entire train off the track to let the other one pass (which in Simutrans would amount to a long stop, one of the trains remaining still and the other starting to move, then the first one starts moving again too), but that will probably be difficult to program (especially as later trains will progressively become too heavy to pull that off).

About the passing loops, it kind of makes sense. Currently the drivers behave a bit like irate motorists on a narrow bridge. They see each other coming, they know it's just one track, but they refuse to stop and give way, shouting instead: "Get the **** out of my way!".

A small addition might help with the distance though. If the train runs into a reservation block on a single track section (in other words, it 'sees' an oncoming train), it knows where it is (that's also shown in the signalling videos). It can calculate if it's more than halfway the next passing section. If it's before that point, it has to turn around, head back to the passing section it just came from, and wait there. It's not very efficient, but that's just another reason to start using signals.

[jamespetts]

A small addition might help with the distance though. If the train runs into a reservation block on a single track section (in other words, it 'sees' an oncoming train), it knows where it is (that's also shown in the signalling videos). It can calculate if it's more than halfway the next passing section. If it's before that point, it has to turn around, head back to the passing section it just came from, and wait there. It's not very efficient, but that's just another reason to start using signals.

This is an interesting idea. There is no reasonably easy algorithm to determine where a passing loop is (as it would be fantastically difficult to tell a passing loop from a siding or branch), but a similar logic, albeit using stops instead of passing loops, might work well; if two trains meet head-on, the one that is closest to its previous stop reverts to the previous stop in its schedule and turns around. This will not be certain to avoid deadlocks where multiple trains area heading towards a head-on meeting, but might well alleviate things in more lightly trafficked areas.

[Dutchman on Rails]

The solution for the point to 'know' where the passing loops are, is a sign. We already have the one-way sign, which can only be effectively used on two-track lines anyway.

[AP]

Also a passing loop allows a P shape path to be found, where the circumference of the loop is unlikely to exceed a quantifiable value.

[jamespetts]

The solution for the point to 'know' where the passing loops are, is a sign. We already have the one-way sign, which can only be effectively used on two-track lines anyway.

Measuring distance to the last/next one way sign on the route is much harder than to the last stop, and would require much more work to code (as well as considerably increasing the computational load), as this might involve actually calculating extra parts of the route. It is also not certain that the next/last one way sign on the route is in fact a passing place (imagine that the train merged onto a single track line from a double track line, and the last one way sign was on the double track line, for example), or that there is a one way sign anywhere on the route.

Edit: Also, there is no way of sending a train back only to the previous passing loop: without a major rewrite at least, a convoy can only be sent to a specific place in its schedule, such as the immediately previous stop.

[Dutchman on Rails]

I can live with the last stop (or waypoint I suppose). It does mean taking good care of where to schedule stops and waypoints, but that's part of the charm.

[AP]

It could be set out in the tutorial that,  for example, it is mandatory for single track operation,  that a waypoint be set on each passing loop.  Granted not ideal if add more later,  but nonetheless.

[jamespetts]

I have now added a feature, implemented in the current nightly build, whereby two trains coming into conflict in the drive by sight method (with both trains not heading in the same direction) will cause one of the trains to go back to its previous stop.

I should be grateful if people could let me know how this assists with the issue.

[nochiu]

The one train staff system was intended to simulate one engine in steam working, rather than staff and ticket working: the idea is that the train reserves the whole route until it gets back to the (same or an immediately neighbouring) one train staff cabinet again.

I should note that the one train staff system already does use its aspect data to encode data about whether it is in use, albeit I cannot now recall the details.

One Train Staff can also simulate what I call "Instant Section Staff". This save provides the first implementation of this.
Save

[jamespetts]

One Train Staff can also simulate what I call "Instant Section Staff". This save provides the first implementation of this.
Save

Interesting. This is not quite what was intended with this system, but it is interesting what you have managed to do with it.

[AP]

I was able to mock up a rudimentary single line operation as well with it on the Canterbury server,  but it was fragile in use if convoys clustered for any reason.

[jamespetts]

I was able to mock up a rudimentary single line operation as well with it on the Canterbury server,  but it was fragile in use if convoys clustered for any reason.

I do wonder whether any of the features discussed here might assist with some of the issues described here?