Combined two-way signals

[adf88]

See also OpenTTD Development::[patch]Combined two-way signals
--------------------------------------------------------------------------------------------------------------
Idea: allow combining different signal types on a single track.

2.png (22.42 KiB) Viewed 7136 times

I'm willing to implement this but first I would like to discuss few things.

• What do you think about the idea?
• How should it be implemented? I'm struggling about few things.

What signal type combinations should be allowed? Normal and block signals - probably all combinations. One-way PBS - disallow to combine. Normal PBS? I'm not sure here. I was digging in the code a little and discovered that disallowing to combine normal PBS'es would make implementation simpler.

The second thing I'm struggling with is (G)UI. My idea is simple. Leave the signal window as is. If a user tries to build a signal of type A on a track that has a single signal of type B and these types are allowed to be combined then add that second signal making a combination (current behaviour is to cycle signal side). If a user tries to build a signal on a track that has combined signals then cycle signal side, but only by swapping their types (don't change two-way to one-way).

Another thing is whether to allow combining different signal variants (signal/semaphore). This should be easy to implement, but is it wanted anyway?

Any other thoughts? Any advices?

[kyosuke1989]

My idea would be single-track line-blocking on both directions between passing loops. That would allow efficent track use on single track.

See translated figure, single track line with blocking signals. More info: http://en.wikipedia.org/wiki/Finnish_railway_signalling

First case is currently plausibly possible on OpenTTD, with limitations that current two-way PBS signals reserve routes just few moments before passing the signal, and no presignal/repeater is possible to have. The repeater could behave like a trigger (pre-reserving PBS signal), reserving the next block ahead of next main signal. Repeater remains green (Proceed) or flashing green (Proceed to diverging route/Proceed 35 km/h), until the main signal ahead shows red. Also the main signal has presignal/repeater for next signal, and it shows flashing green, when the route is clear from departing signal. In OpenTTD, there could be main signal with pre-reserving PBS signal, for that use.

Second case is not currently possible, because there is no direction (PBS reservation) locking availability in one direction of the traffic. The first block signal to the line is red, unless it there is a route reserved to it. Next block signals show green, if they have line unoccupied for next two blocks ahead. If just one block ahead is unoccupied, block signal shows yellow. If block ahead is occupied, OR line direction is "against the signal", block signal shows red.

Third case is currently possible, without repeaters (before main signals and on main signals) and multi-aspect block and main signals.

[Gwiyomi]

The signalling in OpenTTD is so flawed that I only use PBS signal on stations (facing the platforms) and one-way PBS as entry and block signal as exit signal and then blocks all the way to the next one-way PBS.
To prevent stupid trains, all my tracks are one-way if block signals are used.

If we can have PBS signals that reserve paths then I don't understand why we can't have proper bidirectional block signalling.

To make things easy, all signals should be possible to pass from the back. The back of a signal can always be passed from the back unless we've given the signal is specific flag that says one-way.
All signals should pre-signal the next one, unless the signal itself shows STOP, which turns off pre-signaling.
What we need is Entry, Close-up and Exit as well as block signals.
Entry marks the beginning of a station, platforms or not, that's not needed.
For a entry signal to be able to show Proceed, it has to have a Close-up signal which will mark the safe stopping position. This Close-up signal can be put just at the end of a platform or anywhere before a Railways switch.
A substitute for a Close-up signal should be an exit signal or a depot. These should be valid destinations beyond Entry signal. However! If the next signal that the train wants to pass is an Exit signal, the exit must show Proceed Before the entry can show Proceed. This is to allow other trains to cross and not causing deadlock.
The Close-up signal can only show Proceed if the next signal is a Close-up signal or an Exit signal with the aspect Proceed.
An exit signal can only show Proceed if the next signal is an entry signal and the line is free/safe or the block signals have the block direction set in the same direction as the exit signal.
An exit signal is just like a block-signal but marks the end of a station.

To make it clear: The back of a signal should always be ignored unless it has a constant stop aspect sign like one-way PBS currently has.

I registered this account just now because I'm so frustrated by the flawed signals in OpenTTD. I've played OpenTTD for quite some time and the signals Always get on my nerves. My current use of signals is the only way to get smooth flow and no dead-locks.
I drive trains in real life (Sweden & Denmark) and the signals in OpenTTD drives me crazy!!!

The signals, signalling and pathfinding in OpenTTD is making my lose my hair.
Blocks have a direction, they can't show proceed in both directions! They aren't block signals if they do.
The signals in OpenTTD don't have to match real signalling where there aren't blocks due to costs and stations that aren't manned or remote controlled and therefore show proceed in all directions.

To make the aspects on the signals easy for anyone to understand, simple colors can be used.

Two green: Proceed, expect Proceed.
Green over amber: Proceed, expect stop.
Red or two red: Stop

To make it easier to tell signals apart, entry and Close-up signals can show two red instead of one red.
I've read a lot about the OpenTTD signals on the wiki and here on the forum and none of the solutions are satisfying. They all just show how flawed the concept is. It seems like the signals have been rewritten a few times, going from one highly flawed solution to Another one.

I'm sorry if I seem very mad and displeased. I'm just frustrated over the signals in OpenTTD and how Internet Explorer marks all my text with red wavy lines because it's not in Swedish. I've tried to turn off spell correction but it still insists that I should only type in Swedish. Windows Phone doesn't have this problem at all.

I'm just hoping that a proper implementation of signals will some day become reality in OpenTTD.

[Eddi]

The signalling in OpenTTD is so flawed

the signals make perfect sense from a programming point of view. they might not make as much sense from a train driver's point of view. in particular this means that the terminology might not mean the same as in the "real" railway.

In OpenTTD, a "block" is every piece of rail that can be reached (including impossible curves and turning around) without crossing a signal. thus "block" signals cannot be passed from the back as this would make it difficult to define where a block ends, which means all signals in this "block" would go red at the same time, and thus the signals become always red. that wouldn't be very useful. if you want signals that can be passed from the back, use path signals everywhere.

also "exit signal" is kind of a misnomer that was introduced by TTDPatch. it doesn't mark the "exit" of the station, but of the junction before the station.

[michael blunck]

[...] "exit signal" is kind of a misnomer that was introduced by TTDPatch. it doesn't mark the "exit" of the station, but of the junction before the station.

It always explicitly meant "exit from a pre-signals block". Every other interpretation is pure fiction.

regards
Michael

[Eddi]

"It was always meant that way" doesn't change the fact that it completely differs from what any "real-world railway" would call an "exit signal"

[michael blunck]

"It was always meant that way" doesn't change the fact that it completely differs from what any "real-world railway" would call an "exit signal"

Since when has a "real-world railway" anything to do with what happens in TTD/TTDPatch/OTTD?

Just read the post above.

And it wasn´t only "always meant that way", but it has been documented as such from the very beginning:

[...] a pre-signal shows a green light if, and only if, one of the exit signals from the block behind it shows a green light. This means that trains will only enter the pre-signal block if there is a green exit. As a result, the block will only be entered for short times and trains will leave it immediately, allowing for a very efficient layout. This is particularly useful for station entrances, but can also be applied in other cases.

Nobody is talking about "exit signals for stations".

regards
Michael

[Gwiyomi]

I've tried to use only PBS signals but that method creates deadlocks.
Keep in mind that signals in real life are controlled by computers and they run software that has barely changed since the 80s and 90s.
So the "from a programing point of view" doesn't make sense. Rethink the concept of how to write the code.
Signal control computers what ever they are called in the US and UK, run processors that are really slow compared to the PCs that can run OpenTTD.
They run 68k family CPUs or 486SX class CPUs. They don't need much computing power.

[Eddi]

Keep in mind that signals in real life are controlled by computers and they run software that has barely changed since the 80s and 90s.

err... by far the majority of signals are still operated by a guy pulling levers and cables, which were built 100 years ago. the process of introducing electronic controls is sloooow.

Deadlock prevention is nothing that a signal controlling computer in this world currently does. it's always a person sending in and letting out trains.

we can possibly help you make your network deadlock-free, but you'd have to show us your savegame for that.

[Gwiyomi]

Keep in mind that signals in real life are controlled by computers and they run software that has barely changed since the 80s and 90s.

err... by far the majority of signals are still operated by a guy pulling levers and cables, which were built 100 years ago. the process of introducing electronic controls is sloooow.

Deadlock prevention is nothing that a signal controlling computer in this world currently does. it's always a person sending in and letting out trains.

we can possibly help you make your network deadlock-free, but you'd have to show us your savegame for that.

None of the government owned railway in Sweden is operated mechanically.
It has all gone over to electronics or computers.
Deadlock prevention can be achieved if you write code as a problem solving program rather than giving each train its own will.
Due to the nature of OpenTTD being a game and that the code doesn't have to be of SIL 4-standard, I think that this can be done in OpenTTD. I haven't been convinced that it requires too much computing power.

[Hyronymus]

Perhaps have a look at the code of SimSig to solve the signal issues?

[Sylf]

The topic of discussion strayed away from the OP so fast, it's not even funny.
TTO or OpenTTD are not train driving or railroad simulator. One of the fundamental difference I see between the real trains and the trains in the OTTD? The fact that OTTD trains can stop from their top speed to a halt within single signal block, no matter how small that block is. That includes all high speed trains traveling at 300+km/h. In the real world, you can only slow the trains so fast before you get wheel slips. That's why you rely on "slow down" signals etc. There's no such need in OTTD. Signals from real railroads have no place in OTTD.

The only point I saw in the OP was the way to build pre-signal based priorities without having to build extra tracks. Any other discussion feels like hijacking of the thread. (Yarr, I'm re-hijacking the thread!)

Having said that, I have no desire to have such feature. For one thing, it's only useful for building the prios. I don't know how many people even build any prios in their games. I play on coop's server, where prios are used every day, so I've built countless of them. There were times when such feature could have been useful, but I've managed without them. Coop players always have found ways to work around without such feature. In fact, lack of such feature have resulted in most insane awesome constructs I've seen.

[michael blunck]

["prios"]

Yeah, that´s indeed hilarious. IIRC, I did already comment on those funny perpendicular track pieces which seem to be needed in some cases.

To derail the thread even more (?) this would be done in TTDPatch in a more clean way by using restricted and/or programming signals, depending on the situation.

A feature which seems to be clearly missing in OTTD.

regards
Michael

[Alberth]

Overloading signalling with all kinds of additional functionality and magic behavior doesn't look like a solution to me.
The openttdcoop solution may look ugly, but at least nothing is hidden. If you know the standard signals, you can decipher how it works. You can also see what it touches.

Instead of making a signal do everything and totally wrecking the meaning of "signal", my preference for these features would be in adding new elements to the tracks so you can see what is happening where.
However, I won't add such features to the game, people have trouble enough handling all the current features.

[adf88]

How about a feature where you can see what's happening without some extra visual indication, feature which doesn't increase signal system complexity by adding extra signal types or rules, feature that makes your rail network look not-so-ugly? Combined signals is such a feature. Would you like to see it in OpenTTD?

I know that combined signals doesn't solve many problems. But they do solve some of them. They also don't introduce new problems and don't collide with programmable signals idea. So maybe it's worth to have them.

[michael blunck]

Overloading signalling with all kinds of additional functionality and magic behavior doesn't look like a solution to me.
The openttdcoop solution may look ugly, but at least nothing is hidden. If you know the standard signals, you can decipher how it works. You can also see what it touches.

Let´s presume you´re talking to me.

For certain, "signalling" could be a quite non-intuitive part of the game for the novice user, but OTOH that type of user won´t have any need for the more sophisticated use cases, hence no desire to use "restricted" or "programming" signals w/o any knowledge how to handle them in the first place.

In TTDPatch, both these features are clearly discernible:

- restricted signalling builds on setting penalties for the path finder. They are set on base of train data like speed, weight, cargo, schedule, etc.

- the status of programmable signals OTOH is depending on status of other signals and linked by logical operators.

These are easy understandable concepts (even for the beginner), the only "problem" would be a user-friendly interface. This is not really a problem for restricted signalling, but making a GUI for setting up chains of logical operators for programmable signals might be the more challenging task.

But IMO, this is even more understandable than that well-known "PBS/pre-signal" mess.

Instead of making a signal do everything and totally wrecking the meaning of "signal", my preference for these features would be in adding new elements to the tracks so you can see what is happening where.

Without any good solution available, people clutter their maps with loads of waypoints. An approach with the additional drawback of having to define them in the train schedules.

regards
Michael

[Alberth]

They are set on base of train data like speed, weight, cargo, schedule, etc.

My point is I cannot see that in the world display. I see a world of tracks and signals and by 'magic' some trains never take a signal. If you post a screenshot, I cannot see what your signals do, and why train X doesn't do what is wanted.
Lack of visual feedback of what is created makes discussion difficult.

It also makes the feature unnecessarily complicated for users that start using it, since there are no screenshot or so they can study, like you can browse through signal setups or junctionaries. (note: Surely someone will have posted a wiki page with examples, that's not what I mean.)

- the status of programmable signals OTOH is depending on status of other signals and linked by logical operators.

Similarly, some signal never turns green but why? No way to tell unless you open lots of windows, study them all. No way to ever figure that out from a screenshot of the world.

This is imho the problem, If the world shows a red sign with 80 on it, I can see trains driving more than 80 are not allowed. A track with a signal doesn't tell me that.

These are easy understandable concepts (even for the beginner)

'Simple' is in the eye of the beholder. (I know logic, so I can see what you're saying, but looking around me, I can also see this is not universally true, even for people that I consider far beyond beginner.)

By sticking everything onto the logic concept, you make the feature available for a select few, instead of many who might enjoy it too.

While you definitely need logic in the implementation, I believe you do not need to show that to the user, nor expect of him that he has a true understanding of how it works at a larger scale. The logic is implied in the placement. A simple example, a sign with coal followed by a sign with 80 at the same track means "both signs must hold". No need to express that in a line in some gui with "and", imho.

, the only "problem" would be a user-friendly interface. This is not really a problem for restricted signalling, but making a GUI for setting up chains of logical operators for programmable signals might be the more challenging task.

I would say the challenge is in letting the user see what he has built in the world is the challenge.

A single graphic element in the world should have a single meaning. That way everybody can see what is built. You can make screenshot, talk about that element at the forum etc.
It may be more work, but it makes use of these features much more accessible than only to those that truly understand logic.

But IMO, this is even more understandable than that well-known "PBS/pre-signal" mess.

pre-signals are obsolete in my view, I don't think we will ever get rid of them however

Without any good solution available, people clutter their maps with loads of waypoints. An approach with the additional drawback of having to define them in the train schedules.

I said "new track elements", which does not necessarily mean way-points. (They are however an option, of course)
For the record, your assumption is wrong, trains can perfectly drive through stations and way-points that are not in their schedule (goto non-stop orders), just like they can drive through (programmed) signals.

[michael blunck]

My point is I cannot see that in the world display. [...]

I understand what you mean.

But this is a too simplistic approach, IMO. And it´s not even true in terms of today´s state of the game. There *are* already a lot of windows needing to be opened to get sufficient information about a train´s (current or future) behaviour. And there *are* already different types of signals (implying different train behaviour) which don´t fulfill your assumption of "a single graphic element in the world should have a single meaning".

Second point is that I don´t propose to make those "sophisticated" signals a "standard". These are clearly "special", yet important, signals. they won´t be used en masse. But only by introduction of these type of signals, some complex but everyday situations can be solved in a very easy and understandable way, e.g. allocating station tracks to certain trains, or dividing lines for slow freight and fast passenger trains. Without cluttering the map with "way points", or the need to set up customized schedules.

O/c, there´s a need to make these type of signals graphically different from block or PBS signals.

Without any good solution available, people clutter their maps with loads of waypoints. An approach with the additional drawback of having to define them in the train schedules.

For the record, your assumption is wrong, trains can perfectly drive through stations and way-points that are not in their schedule (goto non-stop orders), just like they can drive through (programmed) signals.

That´s not what I wrote. But using waypoints to define certain tracks for trains would require to put them into the train´s schedule explicitly. OTOH, this isn´t needed when using "restricted signalling". Approaches are reversed: the first one defines the route explicitly for every train, the second one sets "rules" which might be relevant for some trains but not for others without any need for intervention into their schedules.

regards
Michael

[YNM]

How about two-way, two sided PBS that doesn't eat up two blocks ? Sounds like a better (and straighter) idea...

[Alberth]

How about two-way, two sided PBS that doesn't eat up two blocks ? Sounds like a better (and straighter) idea...

No idea, what kind of use do you have in mind?
I find the 2-way PBS signal that extends the path in one direction very useful, as it prevents deadlock situations (two trains at both sides of the signal, both wanting to go through the signal), like you can have with the regular two-way block signal.