Two-ways signals

[Nazalassa]

Makes it possible for trains to ignore some signals when they go in the opposite direction, rather than blocking them. This could be useful at junctions, or on single-tracked lines (e.g choose signal at the end). Each signal can do either this or the default behaviour through a new checkbox in the signal info window.

Examples:
 

Note: two-ways-signals-3.patch is two-ways-signals-2.patch with some bugfixes.

[poppo]

Interesting .
I'd like to ask a few questions and make some suggestions (just my personal opinion).

• How does a signal behave when placed on a railroad switch? And can we edit the signal-running direction on the railroad switch?
• Is a choose signal of the opposite direction placed after a choose signal found in route_t::find_route()? (It should not be.)
• Is it possible to place different signals on the opposite sides of the same tile?
  (I know that current signal system doesn't allow this. But I think it would be more useful if, on a single-track line, one direction could be set to "choose" while the other could be set to "longblock" or "pre-signal".)

[prissi]

You mean that a single direction signal should no block traffic in the other direction? This is dangerous territorium.

How is this useful for junctions?

As for choose signals, if a train is waiting at a choose signal, the other train can still not go through this train since it reserves the track. And end_of _choose sign would have the same effect without this patch.

As to the above questions, a second choose signal will revert the first signal to a normal signal.
Signals on switches are not allowed in the first place. They can be made, buit are anyway no supported officially.

[Nazalassa]

First, remind that this is per-signal configuration and is disabled by default: for a signal to allow traffic in the other direction this must explicitely be enabled in the signal's info window.

I noticed signals with two-ways enabled are not ignored when looking for signals in the choose signal's preliminary checks, here's a patch that fixes that.

This could be useful on single tracks that branch from a line (e.g service to industries) because this is now possible:

==================mainline====
 signal -> |-o
           \____[station]

Trains from the mainline entering the branch will ignore the signal and must reserve all of it, whereas trains leaving the branch will first go to the signal and then attempt to reserve their way on the mainline. Using a bidirectional signal instead of a unidirectional one with two-ways enabled means trains may enter the branch while it is not free and then stop at the signal, preventing the train inside from leaving and causing deadlocks.
The current workaround to this is building a short double-track section at the beginning of the branch.


Regarding junctions, I was also considering implementing a "crossing" signal that only reserves the few next tiles of track at the last moment (when the train checks whether the signal is clear) instead of when the train reserves its route. Example:  (x = reserved track)

train    ǫ | |    .---.     Only reserve when next to signal             ǫ | |    .---.
<==>xxxxxxx+-+xxxxxxxx-*--              ------>                 -----<==>xxxxxxxxxxxxx-*--
           | |                                                             | |

the bit in the middle is only reserved when the train arrives at the signal. This way it is possible to have single-track lines cross other lines without risking deadlocks.
But such a "crossing" signal would require allowing traffic in the opposite direction to be useful on single tracks.

(I probably meant "crossing" instead of "junction". But then there are often junctions near crossings.)

[poppo]

It would be helpful if end_of_choose could also specify the "end of choose" direction

[poppo]

By the way, for a single-track line, you can simply make a choose signal that allows traffic in both directions just before the station and a pre-signal on the platform.

However, since longblock signals cannot be used with choose signal in this case, the proposed feature would indeed improve practicality.

[prissi]

I do not see how a longblock signal would work together even with a one-directional choose signal. It will be impossible to determine if a route is free or not. Maybe the through route is free, because the train before chose another platform. But then the route is blocked as soon as it leaves, because the longblock signal only checks and not reserve the route.

[poppo]

-----[stop]----[stop]----|C>-<L|--[two-platform terminal with pre-signal]
like above situation, we cannot avoid deadlock in current version (without using departure time settings).

But if choose signal can only active for one-way, we can avoid this problem!

[prissi]

You cannot avoid a deadlock ever, as soon as a second train enters the section.

Longblock signals only work without deadlocks if there is never more than a single train in the single track section. So two platforms with longblock signals is a no go in any configuration, as the longblock　signal from the entering side only checks one of the platforms and might not see a train on another one.

It can work with a situation when have an exit only longblock and an entry only choose as long as there are never more than two trains ever in this branch. Three train will deadlock, even with longblock and choose signals because a longblock signal stops checking at the last stop before reversing OR at any signal. So it will allow a third train to enter even if both platforms are occupied.

[poppo]

I understand the condition of the number of platforms and convoys. thank you.

Anyway, in my opinion, it would be better to allow two-way traffic for all signal add-ons via the GUI (as two-ways-signals-2.patch).

[prissi]

Driving through a signal facing the other way is extremely rare in real life (outside of stations). I think for it should be a rare case for simutrans too and hence allowing for a single signal via GUI info is fine.

Alternatively, I could imagine a special signal that only works one way, si it is viually clear that this is single way.

I am still worried if this patch found all cases as the route search is backwards in find route.

[Nazalassa]

Turns out I accidentally broke dragging signals. This patch fixes it. Here is an updated two-way-signals-4.patch, which is two-way-signals-2.patch with bugfixes.

[Octavius]

Driving through a signal facing the other way is extremely rare in real life (outside of stations).

Actually, I think that's quite common in real life. The question is how relevant this is to Simutrans Standard.
– Most double track lines are signalled for using the opposite track (left in normally right running areas), so there are at least an exit and entry signal and possibly a sequence of block signals facing the opposite direction. Trains running on the opposite track would see the regular exit, block and entry signals from the rear. It's rare, but not unheard of, to have trains scheduled to use the opposite track. That actually contributed to a train crash in the Netherlands in 1976.¹ Most opposite-track running is however to handle disruptions and disruptions don't happen in Simutrans.
– Platform tracks where trains reverse are always equipped with signals at both ends, facing towards the platform. Trains can't enter the platform track without passing one of these signals from the rear. But this is at a station and Simutrans Standard can use implied signals there. The signal may be some distance away from the platform though, if the platform is only long enough for passenger trains but the platform track long enough for goods trains.
– At all junctions, there's a signal just before the junction. If single track, a train that has just passed the junction will see this signal from the rear, as mentioned in post #3.

So, pretty common. At least way more common than choose signals, of which we have in the Netherlands a grand total of 2.² But then, signalling in Standard isn't designed to be very realistic: real life has no presignals³ or long signals.

¹: On 4 May 1976, 7:54 a.m., there was a local train Hoek van Holland – Rotterdam Centraal, running on the right track near Schiedam Nieuwland station. The international train Hoek van Holland – München (providing a connection from London using the Harwich – Hoek van Holland ferry) overtook the local train using the left track, as scheduled, except that is was a little delayed. The local train Rotterdam Centraal – Hoek van Holland departed Schiedam – Rotterdam West station (now renamed Schiedam Centrum) despite a signal at danger and collided head-on with the international train, with the other local train hitting the debris. 24 people were killed.
²: One on the rightmost track of the southern approach to Schiphol Airport station, choosing between tracks 1 and 2, and the other on the rightmost track of the northern approach to Schiphol Airport station, choosing between tracks 5 and 6.
³: There are distant signals, but they only tell the train to slow down, not to wait at the signal.

[Andarix]

https://de.wikipedia.org/wiki/Gleiswechselbetrieb german

Technically, it consists of two single-track lines running parallel to each other.

However, I don't see any need for this in Simutrans as a game. The effort required for automatic use would likely not outweigh the benefit.

The situation is different if Simutrans were considered not as a game but as a (railway) simulator where all vehicles operate according to predefined timetables. In that case, specifying the track to be used would certainly make sense.

And so the question arises once again: What is Simutrans supposed to be?

- A game with variety and no strict rules.
- A simulator with full user control.

Both together won't work. Just as using touch and mouse/keyboard simultaneously won't work. The same applies to screen size. Small screens simply require a more streamlined UI than large ones, regardless of the screen's aspect ratio.

Unfortunately, Extended and OTRP have diverged significantly from Standard. OTRP is also in a different language environment, which makes tracking its development even more difficult.

While I don't actively follow either development, I think there are definitely aspects of both that would be helpful for Standard as well.

I'm not sure if there aren't other Simutrans forks out there somewhere, each with its own set of interesting features.

[prissi]

Double single track operation has become pretty common in the last 30 years in Europe (but apparently not UK) while only used for breakdownas the first 150 years of railway history. In Japan, it is almost non-existant even today, the tracks have been laid so that expresses overtake slower trains at stations and freight and passengers are largerly separated by schedules.

Anyway, I think the patch with a checkbox is the best way forward for now to add this to all paks; However, a new signal which has this property on default would make this much clearer. And, maybe highlighting such signals on the reservation view with a different highlight color.

[poppo]

I apologize for asking such a beginner's question, but why does the pak file need a dedicated flag for this? If we're managing the signal mode via checkboxes in the GUI for each signal, I don't think we need a flag for pakfiles.

[prissi]

The special signals would have these checkboxes set automatically and thus provide visual feedback that these will not act as signals in the other directions and allows to pass them wrongly and reserving a much larger track than probably expected.

Btw. the double single track operation requires double directional signals for each track, so that exists already within simutrans for identical signals ...

Submitted in r11945 with some more bugfixes for trams and text changed since also maglev and monorail have signals. Ptach4 contained already the dragging, yes?