## News:

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

## Solution to underbuilding timed interval signals.

Started by DrSuperGood, April 12, 2018, 08:26:08 AM

0 Members and 1 Guest are viewing this topic.

#### DrSuperGood

In another thread James pointed out that how I was using timed interval signals was not exactly how they were meant to be used. Specifically on the server I have timed interval signals only at stations with potentially 50-80km of signal-less track between them.

In theory for safe operation one needs a lot of timed interval signals to prevent the bus clump problem from causing the fast running train from having to perform an emergency stop with the slow running train. However due to the mechanics of these signals it is not possible for trains to pass them at maximum speed, specifically because the warning signal cannot be placed the 2-4km breaking distance required to stop at full speed. This means trains will slow down a lot for every timed interval signal they pass, greatly decreasing their average speed and hence profitability. This drives people to build my configuration of lines to minimize the number of intermediate signals in order to maximize speed. However the result is unnaturally high average speeds for the time period as well as saving on maintenance costs of signals, not all realistic.

So I propose a solution in the form of a game mechanic which enforces realism in a sensible way by preventing my style of line construction. The timed interval driving method will only work for up to Xkm where X is a realistic signal spacing distance for timed interval signals and possibly could vary with signal type. This means that a train driving in timed interval mode will revert to drive by sight mode after Xkm have passed since the last timed interval signal unless it passes another timed interval signal before then. As drive by sight is extremely slow it makes sense to try and keep the train operating in timed interval mode as much as possible, even if that means several timed interval signals between stops that the train has to slow down for. Chances are even when the train slows down for the signals it will still be much faster than drive by sight. It also means that signalling would be a major limiting factor to train speed around the 1850s, much more so than the trains themselves like it was in reality.

#### ACarlotti

Another feature that might be helpful is to have some random variation in the speeds that trains actually run at (with the level of variation depending on things like the type of train and the type of signalling). This would mean that if timed interval signals were too far apart, then collisions would become increasingly likely. It would also provide an incentive for implementing ATO (Automatic Train Operation) on busy lines once the technology is available.

#### DrSuperGood

QuoteAnother feature that might be helpful is to have some random variation in the speeds that trains actually run at (with the level of variation depending on things like the type of train and the type of signalling). This would mean that if timed interval signals were too far apart, then collisions would become increasingly likely. It would also provide an incentive for implementing ATO (Automatic Train Operation) on busy lines once the technology is available.
All trains can hit their designed speed in real life... It is only absolute limits, beyond the designed running limits, that would vary slightly. These limits were seldom, if ever, used because they are not safe or cause too much wear/fatigue to be economical.

For this reason I could argue that many of the trains available have maximum speed values that are far too high.

#### ACarlotti

Quote from: DrSuperGood on April 12, 2018, 10:06:02 PM
All trains can hit their designed speed in real life...

In theory perhaps, but are you really trying to tell me that an old steam locomotive would always reach and maintain 80mph if the speed limit was 80mph (over a long stretch of track). I rather think that sometimes they'd go at 79.5mph, or 79.9mph, or 80.1mph, or 77.8mph,  or stuff like that. It is this variation in actual speed (partly due to imprecisions in speedometers, and partly due to variation in driver behaviour) that drives the requirement for timed interval signals to exist and to be not too far apart. (Although, to be fair, having mixed traffic on a line is probably a bigger reason.)

Admittedly, this might not give enough disincentive by itself against building lines with widely spaced time interval signals, but it would be a realistic simulation of the need for such signals.

#### jamespetts

These are interesting ideas, although they both have drawbacks and need careful consideration. Dr. Supergood's proposal for time interval signals and a limited distance is interesting (and this method of exploit prevention is already used for moving block signalling), but I worry that calibrating the distance would be difficult, that this would not be transparent or easy to communicate to players, and that it would further complicate the (already extremely difficult to work with) signalling code and thus be prone to introducing many bugs that take many months and huge amounts of development time to solve between them.

A. Carlotti's suggestion is one closer to something that models the way in which things worked in reality, and could in principle be tied to how recently that a vehicle was maintained (having, perhaps, a diminishing amount of power the longer that it has been since maintenance), but I am not sure quite how well that this would actually work with things such as schedules, or how easy that this would be to communicate to the players. This would certainly be the more realistic solution, and perhaps a little easier to implement than the distance limit.

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

#### Ves

Another thing I have been thinking of with time interval signals, both with and without telegraph, is that it could utilize the sighting distance as it does with crossings, but also on plain track.
That means that when a train cannot pass a time interval signal, if there is another train within sighting distance, ie 7 tiles after the signal. This would make it possible to have small visual blocks, and would be usefull for places where trains risk lining up after each other.

#### jamespetts

Given the complexity of the signalling code, adding new features to signalling such as this is likely to take tens of hours of intensive work, and many months of bugfixes.

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

#### DrSuperGood

Problem with A. Carlotti's suggestion is it does not solve the underlying problem. One can use schedules to work around it. It also makes even less sense to users than a single line stating that all timed interval signals have a maximum range of Xkm.

#### jamespetts

Quote from: DrSuperGood on April 13, 2018, 03:46:42 AM
Problem with A. Carlotti's suggestion is it does not solve the underlying problem. One can use schedules to work around it. It also makes even less sense to users than a single line stating that all timed interval signals have a maximum range of Xkm.

I am not sure that it does make less sense, as it (or at least the version of it that I suggest) would actually be simulating something that exists in reality, whereas a limit on distance between time interval signals (after which trains revert to the drive by sight working method) would not, at least not so far as I can discern or would be likely to be apparent to anyone playing.

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

#### Ves

The max distance could be showed in the UI, just like for moving block signals?

#### jamespetts

Quote from: Ves on April 13, 2018, 11:00:06 PM
The max distance could be showed in the UI, just like for moving block signals?

The maximum distance is not shown in the tooltip for moving block signals - where in the UI do you think that this is displayed?

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

#### Ves

Moving block signals have that displayed in their info window, where it says "Max dist. between beacons: X km"

#### DrSuperGood

QuoteI am not sure that it does make less sense, as it (or at least the version of it that I suggest) would actually be simulating something that exists in reality, whereas a limit on distance between time interval signals (after which trains revert to the drive by sight working method) would not, at least not so far as I can discern or would be likely to be apparent to anyone playing.
Except did limits really not exist? One can do the maths and come up with a sensible limit needed so trains are properly spaced out and run safely (ish, as train accidents did used to happen).

Also trains already run at different speeds due to the bus clump problem. Variances in passengers at stops cause trains to take varying loading times and have varying performance. Hence they arrive at stops at varying times. On the server game this was apparent in the one 70km track stretch I ran where trains used to have to emergency stop in the middle at times. The solution I used, until pre-signals were available, was to schedule the trains at the stop before so they were always spaced out >10 minutes.

Hence to prevent people using schedules to work around random speeds and still avoiding signals, the only practical option one has is to place a maximum distance limit on the drive mode of the signals themselves.

One does not even need to do the maths. One can measure signal spacing from real life examples, if one knows where the signals were placed back in 1840-1850.

#### jamespetts

The point is that, in reality, there was no hard limit a kilometre beyond which a train would suddenly have to revert to driving by sight. There would certainly have been no general rules about signal spacing at that time: each railway company would have had its own practices, which would have varied considerably. The practical limit is a function of the distance and the difference in speed potential between different trains in the section (and thus the propensity for collisions). In the game, players might well have different degrees of differences in speed on the same line (depending, for example, on whether freight trains share lines with passenger trains, etc.), and so the actual practical limit will differ.

It makes much more sense for the practical limit being enforced by a gradually increasing chance of emergency stops in realistic circumstances than being an exact distance beyond which trains revert to the drive by sight working method.

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

I early years of railways, there was a practical limit on distance between signalboxes, because they used (at least in austro-hungarian empire) optical telegraph. So you had to build them in sighting distance from each other. As the signals to drivers were given by hand or signals that were just next to the signalbox, the distance between signalboxes defined block length. At that time it was time interval signalling, and it was used as 3-aspect signals. (danger, caution, clear)

The introduction of electric telegraph (not necessarily Morse type) allowed for longer blocks and significant cost savings.

#### jamespetts

Quote from: Vladki on April 14, 2018, 01:58:50 PM
I early years of railways, there was a practical limit on distance between signalboxes, because they used (at least in austro-hungarian empire) optical telegraph. So you had to build them in sighting distance from each other. As the signals to drivers were given by hand or signals that were just next to the signalbox, the distance between signalboxes defined block length. At that time it was time interval signalling, and it was used as 3-aspect signals. (danger, caution, clear)

The introduction of electric telegraph (not necessarily Morse type) allowed for longer blocks and significant cost savings.

That is very interesting - but that restriction is inapplicable to any system not using the optical telegraph.

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

#### ACarlotti

In particular, time interval signalling is specifically designed and used for situations where there is no (routine) communication between one signal and the next.

That is true only for double tracked lines. In central Europe all early railways were only single tracked, so they needed some communication to switch direction of travel. It was also used to call for help in case of broken engine or an accident.

#### DrSuperGood

QuoteIt makes much more sense for the practical limit being enforced by a gradually increasing chance of emergency stops in realistic circumstances than being an exact distance beyond which trains revert to the drive by sight working method.
It does not really make sense... Since one can exploit the time tabling feature to get around all of that. In fact why even have drive by sight if one can schedule a drive by site system in the first place?

This is why hard limits are needed to force players to use a mechanic. They will always find a work around otherwise and make the existing mechanics look silly.

If we need to enforce some behavior to match real life, then it means that the simulation is lacking some aspect that i real life lead to that behavior.

If you have a line with time-interval signals too far from each other, that the following scenarios should happen that will force you to build them more often:
- fast train collides with slow train, causing emergency stop, and thus having higher chance that another train will catch them up and collide too.
- train leaves station too soon after another, thus is forced to run at half speed over the whole line. Just waste of time and capacity. If the line is long enough another train may be released later at full speed and catch up and collide
- if the line is too busy, all trains will eventually go at half-speed or collide with each other.

However if the traffic is so low, that you can avoid building signals, and use timetabling to keep trains nicely spaced and running at full speed, I would not consider that as cheating. Even in real life the railway companies carefully considered what is the cost efficient distance between signals. Of course there is one important aspect that we do not simulate - breakdowns. But that was a problem in real life too, unless the signalman could oversee the whole track up to the next signal, which would effectively change the system to some sort of absolute block signaling.

In real life there were different rules for time interval in different countries - i.e. how much time must have passed after dispatching one train to change the signal to caution, and how much for "clear". This time interval must have been chosen according to the expected travel time to the next signal, with some safety margins. So the distance between signals and speed of trains ruled the length of the intervals. Could that be somehow used in the game? Not having the time interval fixed at 5-10 minutes, but based on distance to the next signal? I don't know however what speed to use as a factor in such calculation.

#### jamespetts

Quote from: DrSuperGood on April 14, 2018, 10:45:15 PM
It does not really make sense... Since one can exploit the time tabling feature to get around all of that. In fact why even have drive by sight if one can schedule a drive by site system in the first place?

This is why hard limits are needed to force players to use a mechanic. They will always find a work around otherwise and make the existing mechanics look silly.

A slight realistic variation in speed as A. Carlotti suggested would remove the ability to use scheduling to prevent the need for multiple time interval signals and thus the need for the unrealistic hard limit.

The first sentence of Vladki's reply is precisely the Simutrans-Extended design philosophy.