Merge both railway signals into one

[ShadowTheAge]

I have an idea and some proofs that having two types of railway signals is redundant and there is a clear algorithm to decide which signal to use in each situation.
Having only one signal will help new players make less errors.
Signals divide tracks into blocks.

The algorithm:
you need block signals before blocks that
- either have only one entrance that is not also an exit
- or have only one exit that is not also an entrance
otherwise you need chain signals

These types of blocks are always safe to enter, because:
1) you can never needlessly block another train by staying in this block (both trains shares either entrance or exit so they are moving in the same general direction)
2) you can never have a "face to face" deadlock (the most common one for unexperienced players)

Theoretical examples:
- A piece of one-way track: block signal
- A piece of two-way track: chain signal (two entrances and exits, and also entrance == exit)
- Y split or merge (one-way track) - has one exit or entrance - block signal
- complex junction on a one-way track: chain signals before the junction, block signals after
- deadend or signalless loop on a two-way track (station area) - block signal to enter, chain signal to exit
- railroad siding on a two-way track (https://i.imgur.com/2o19lXy.jpg) - chain signals at exit, block signals at entrance

[sillyfly]

Hmm... The algorithm may need some more refining to be well defined in all cases, but it sounds reasonable, and at least at a glance I can't see any real disadvantages to this.
So yeah, sounds good!

[Khaylain]

I'm getting a bit of a headache trying to understand this. I feel like it's pretty ok with the two signals as they are for now. I bet the devs could make signals better, and maybe they'll get more use out of your post, Shadow.

I'd probably understand what you meant a little easier if you were to take the time to take some pictures of what you meant. Anyways, it's probably good to have a discussion on this.

[ssilk]

Doesn't take in account train length. So I doubt it works in all cases.

[sillyfly]

Could you give an example of a case where you'd consider one type of signal, but your trains being one length or another would make you change your mind?
I can't think of a case where this will happen. For me, train length affects the location of the signals, but not really their kind...

[ShadowTheAge]

More in-depth explanation:

I've found a situation where train lengths matter (solution below)
If you have two complex junctions very close together that are functioning okay with small trains. But then if you add a large train to the system, it could block first junction while waiting the second to resolve. And two such trains moving in opposite directions could deadlock.
That’s when you can decide to remove signals between junctions or replace them with chain ones, effectively merging two junctions into one.

This is a problem with both signalling systems and it is solvable in both. But there is an opportunity if we have “one type of signals” to behave better: If we have only one signal type, it can choose behavior on a per-train basis accounting train lenghts. This is optional but if it is implemented, it will improve junctions a little bit in a way that is inachievable now.

There is an easy logic behind “one signal type” idea.
Train should reserve his path up to the next station or up to a safe place where it could stay without needlessly blocking other paths. This is better explanation then “signal that behaves either as block signal or as chain signal”. Train uses signals to reserve its path to a safe place. If a safe place is just behind the next signal - that’s okay, using only one signal (“works like block signal”). If the same train needs several signals to get there - okay, reserve all of them (“works like chain signal”)

I’m using this algorithm all the time as my personal guide “which signal to use” and it works perfectly. I mostly use two-way tracks with sidings because I like to play with extremely low resources so I have to build very long tracks and building one-ways is too expensive. When building two-ways you need chain signals about 70% of the time


Also I made some images to demonstrate algorithm (using junctions from google images) - https://imgur.com/a/WHFM5
I’ve marked blocks and entrances:
red blocks have more then one enter and exit, using chain signals before them
blue blocks have one exit, using block signals before them
green blocks have one entrance, using block signals before them

[tobsimon]

First of all: Nice and yesssssss

But I'm going to play the mean guy now with stupid border casses to destroy you algorithm.

Case 1: Dead-end rail with combined entrance and exit.

• The entrance signal to a dead end rail should be a block signal. (I think a chain signal wouldn't even work right.) It is a chain signal, by your algorithm.

A fix to your algorithm:

Code: Select all

You need block signals on entrances of blocks, that have only one entrance or one exit (which may coincide),
otherwise you need chain signals.

Case 2: Dead-end rail station with two entries and and two exit, all separate.

• Who would ever build something like that? But it is virtually indifferentiable from a rail crossing, if you only count number and configuration of entrances and exits. It needs, however, block signals instead of chain signals. I think this is a show stopper for the first approach.

The second approach is more promising. Here is an alternative formulation:

Code: Select all

Reserve path until a safe halt is possible or the end of the rail is reached.

• A safe halt spot is free of crossings and bi-direcional rail segments. Splits do not matter. Mergers matter (simple alternative), only if there is a split afterwards in the same block (medium complex), which may be used by another train with higher priority (crazy complex).
• Path currently means all blocks on the way, but should mean only the affected rail segments to get rid of the need for signals in the middle of junctions, while still allowing trains to pass simultaniously.
• Actually no signals are necessary for the definition of a safe halt spot.
• Problem: Much farer lookahead may be neccessary for long trains.
• Will not prevent capacity issues in an area. This would need a more complex approach involving the lines in an area, their priorities and throughput optimization.
• Potential to closely follow a train, which is riding in the same direction, through a long stretch of crossing or bi-directional rails. This would involve the ability to push another train out of it's reserved halting area further down it's path and queueing reservations on rail segments without reintroducing deadlock situations. Optimizations on the reservation queue with the expected time of arrival then leads to full blown throughput optimization.

This issue can get arbitrarily complex, if you dive deep into it. The safe halt logic a pretty elegant way to solve most deadlock situations and I'm glad I'm not the only one thinking about stuff like that. However I know of no game, which employs it, which makes me wonder if there is a fundemental flaw I'm not seeing, or if actually no developper thought of that solution before.

[bobingabout]

I'd need to know what the new type of signal does, but from what I recall, the new signal type is either something like a pre-signal from OpenTTD/TTDPatch (In that it only goes green if at least one signal after it is green) or like a PBS signal (In that it will allow multiple trains in a single block, as long as there is no collissions in the pre-booked route detected)

The former is good for stations, so further trains won't enter the block before a station if all platforms are full. The latter can be used for that, or also for junctions.

[Zeblote]

I'd need to know what the new type of signal does, but from what I recall, the new signal type is either something like a pre-signal from OpenTTD/TTDPatch (In that it only goes green if at least one signal after it is green) or like a PBS signal (In that it will allow multiple trains in a single block, as long as there is no collissions in the pre-booked route detected)

The former is good for stations, so further trains won't enter the block before a station if all platforms are full. The latter can be used for that, or also for junctions.

The chain signal is green if the next block that the train needs to go to is also free

So the state of the signal depends on the path of the train approaching it

[bobingabout]

The chain signal is green if the next block that the train needs to go to is also free

So the state of the signal depends on the path of the train approaching it

So... I guess that's like TTD's pre-signals, only smarter, because it only considers the platform, or platforms the specific train wants to go to, rather than everything behind the signal.

[ShadowTheAge]

@ tobsimon

The signal blocks the train if the next block they have to go is red (and the place is "not safe to stay")
But if there is no next signal (we are approaching the station), it works just as regular signal

Since we have only one signal, it is indistinguishable for player which "mode" it is in (especially if it decides its behavior on a per-train basis)
So both dead-end variant with stations would work perfectly (no train and no next block = green light)

Why did I choose to include exceptions like "that is not also an exit" / "that is not also an entrance" ? This is to prevent "face to face" deadlocking in a specific cases
Example:
A loop (enter == exit, "track A") plus one additional entrance "track B"
Two entrances and an exit (that is also an entrance). If we are using block lights:
1) train A approaches from the side of "track A". The loop is clear so this train enters the previous segment
2) train B approaches from the side of "track B".
3) train B enters the loop because there is no train there
4) train B and A meet at track A, face-to-face
If we have a chain signal, train A would wait far before the loop (on a siding or station) OR train B would wait on a signal just before the loop

The situation is strange but it could happen.

[ratchetfreak]

Frankly it's simpler to have the player set which mode the signal should operate in.

Coalescing the signals into one item and then being able to set how it operates opens up the possibility for more signal types/more settings without polluting the items/crafting window.

[bobingabout]

I suppose with the current system, if you make a chain of the chain signals all the way along the line, then if a station on the end of the line that a train wants to go to was occupied, then the entire length of track would turn red.

A possible solution (Without changing much logic) would be to make them only look at the one signal block in front of them.

Now that I know how they work though, I've made good use of them already.

[ShadowTheAge]

The entire track wouldn't turn red, but the signal ahead the train would (if there are other exits)
The track would be usable by other trains that don't intend to go to that station
By doing this you tell all the trains that you don't want any train to stop at this segment. That is correct if it is a straight two-way segment.

[bobingabout]

By doing this you tell all the trains that you don't want any train to stop at this segment.

which could effectively be achieved with just 1 signal at the start of the huge length of track

[ratchetfreak]

By doing this you tell all the trains that you don't want any train to stop at this segment.

which could effectively be achieved with just 1 signal at the start of the huge length of track

But that would not let other tracks cross without massive deadlocks