Trains/signals Force green very high intersection throughput

[hansjoachim]

TL;DR

Increasing train intersection throughput by forcing signals to be green.

What ?

Allow signals to be set to green by circuit conditions.

Why ?

Would give the players better control over trains and allow complex traffic control systems.
If we could set signals to green we could drasticly increase throughput in intersections.
With this a player can make trains behave as the trains on the upper track, while the lower track is how maximum acceleration of multiple trains is currently.

You could also make more compact intersections, as you don't need chain signals if you control it properly with circuit conditions.

[Ripshaft]

I don't really see sufficient justification for this one.... I'm not sure there's any realistic scenario in which it'd be beneficial, and the potential frustration such a feature could cause is reason enough not to give it to the player.

If you could provide a specific scenario in which you're having problems with throughput and think it would be best solved by such a feature, it'd go a long way if you could provide it.

Unless you're arguing on a purely aesthetic or artistic basis, which I can kind of understand, though that's probably not worth the likely considerable work that would have to be done to implement such a feature, since it basically undermines the current pathfinding.

[Tekky]

I am against this suggestion.

In my opinion, in order to increase throughput of intersections, it would be more important to implement OpenTTD path signals, as has been suggested in the following threads:

viewtopic.php?f=6&t=26592 Trains reserve paths by segments instead of blocks
viewtopic.php?f=6&t=32020 All signals work as path signals ([0.13.20] Rails driving me crazy)
viewtopic.php?f=6&t=3497 Path signals for railroads / railway / train

Also, implementing some kind of grade separation (such as underground rails or bridges) would significantly increase throughput of current train intersections. This has been suggested in the following threads:

viewtopic.php?f=5&t=10054 trains, bridges and improvements to the rail system
viewtopic.php?f=6&t=46978 Underground Rail
viewtopic.php?f=6&t=44338 Underground rails
viewtopic.php?f=6&t=22395 Rail tunnels
viewtopic.php?f=6&t=33294 Suggestion for Rail Bridges

This thread also contains some interesting suggestions about controlling signals and the train pathfinder with the circuit network:

viewtopic.php?f=80&t=21899 Control Train Pathfinder (Passthru stations, Add Penalty)

[Engimage]

I am strongly against the suggestion.
Current system is crash proof no matter what you are trying to do with your circuit network experiments.

Your change will lead to multiple train crashes and it will hit the forums and devs. Silly questions about why my misconfigured signals make trains crash.

[mrvn]

You intent to set signals to green so that the next train crosses the track when the previous train has passed. I believe that the trains will crash when they repath because they might suddenly break while you assumed they would leave a crossing at a certain time.

[Koub]

It's like being able to override traffic lights so that both sides can be green at the same time. It might help you with throughput ... for the 2 first cars, and then, throughput will become worse, due to the fact you have to clean the accident and rebuild everything.

[hansjoachim]

Ripshaft, Koub
There are two scenarios where this would drastically increase potential throughput.

Merger
I have a merger between two lines, where I switch priority every 900 ticks. Because that packs the train tighter together than if you just join two tracks together.

When the lights turn green, the first train will start accelerate then the second, third, forth etc.
If I could force all the lights, on that track, to be green, the first and the last train would start to accelerate at the same time.
Then I would have a way better merger.

Intersection
I have a 4 way intersection that is similar to a 4 way road intersection with signals.
Imagine a road intersection for cars. The signal turns green. Then if all cars in the same line would start accelerate at the same time you could get way more cars through the intersection before the signal turns red.

If we implement this in factorio, we don't need undergrounds or bridges as much. As the throughput of such a intersection would be much higher than what is currently possible.

[hansjoachim]

Tekky
I fully agree with those other suggestions, I would have loved path signals and bridges/tunnels.

I don't think we will get bridges or tunnels as implementing that is alot of work, one can always hope though.
If we could force green signals, we could have way higher throughput as I wrote in another reply.

If you do it wrong you will crash some trains, if you do it right they won't crash. When I played OpenTTD, crashing trains by accident was part of the fun=)

[hansjoachim]

PacifyerGrey
Would be fun to crash a bunch of trains though! You could even sett up traps in multiplayer=)

[Tekky]

I have a 4 way intersection that is similar to a 4 way road intersection with signals.
Imagine a road intersection for cars. The signal turns green. Then if all cars in the same line would start accelerate at the same time you could get way more cars through the intersection before the signal turns red.

The reason why all cars do not accelerate at the same time in reality is that, as their speed increased, they need additional safety distance to the car in front of them.

The same is the case for trains. In reality, even when using continous train control systems such as ETCS or LZB, the train that is behind another train will always be required to keep a safety distance to the train in front, so that, even if the train in front suddenly comes to an abrupt stop (e.g. due to an accident), there is no danger of the train behind to drive into the train in front.

Although there is only very little danger in Factorio that the train in front of another train will come to an abrupt stop (due to a crash with another train), I still consider it appropriate that the signalling system would not allow the train behind to crash into the train in front.

Therefore, I continue to believe that the best (and most realistic way) to increase train intersection throughput would be grade separation (such as tunnels and bridges) and OpenTTD path signals.

[hansjoachim]

Tekky
That is a good reason to not allow to force green light.
You changed my opinion, i don't think it is the right solution anymore

[Tekky]

Actually, your idea to abolish fixed block signalling is not that bad. Continous train control systems such as ETCS and LZB work that way by having variable block positions that change their position and size depending on the train's position and speed. This allows for trains to have less safety distance between each other, without compromising the safety of the trains. In that case, the signals on the track are redundant, except when there is a failure in the train control system.

However, I don't think that this realistic highly optimized continuous train control system would fit well into Factorio or OpenTTD, because players want to see real signals in fixed positions as visual feedback.

Therefore, as I stated before, the only thing missing in Factorio is, in my opinion, path signals and tunnels/bridges, which works very well in OpenTTD to increase train intersection throughput.

[Engimage]

By artificially increasing throughput of some small intersection you want to make trains exit the intersection within a very small distance of one another. However right after that trains will be forced to maintain at least block size (and actually a bit more) distance from one another due to logic of other signals in their path. And you don't want to place signals every 2 tiles right?

As to path signals, while they are very effective in OpenTTD (where train brakes in 1 tile) it was already stated that they just can't be implemented in Factorio due to heavy impact of train acceleration/braking distance. Also path signals are not visually readable adding more confusion to train system. Trains are a big part of Factorio and there is a ton of things that can be implemented making gameplay better but this one smells trouble due to added complexity and confusion.

[steinio]

Once upon a time there were this mods:
http://factoriomods.net/rail-crossing-mod/
http://factoriomods.net/moving-block-signals-mod/

Cu, steinio.

[Tekky]

As to path signals, while they are very effective in OpenTTD (where train brakes in 1 tile) it was already stated that they just can't be implemented in Factorio due to heavy impact of train acceleration/braking distance.

The main advantage of path signals is that they allow several trains into the same intersection block at the same time, provided that their paths do not cross. This is accomplished by trains being forced to reserve a route to the next signal before they are allowed past a signal.

I see no reason why the unrealistic braking distance of OpenTTD would prevent this feature from being implemented in Factorio. Trains will just have to reserve a route past a signal a bit earlier than in OpenTTD. Instead of reserving a route past a signal at that signal, they will already have to do so when approaching the signal, at braking distance.

The issue of braking distance only seems to be relevant to me in the context of the original poster's suggestion.

Also path signals are not visually readable adding more confusion to train system..

In OpenTTD, there is an option to highlight the reserved paths of trains on the track. If this were implemented in Factorio, one could argue that the signalling system would be even more visually readable than it is now.

[mrvn]

I have a 4 way intersection that is similar to a 4 way road intersection with signals.
Imagine a road intersection for cars. The signal turns green. Then if all cars in the same line would start accelerate at the same time you could get way more cars through the intersection before the signal turns red.

The reason why all cars do not accelerate at the same time in reality is that, as their speed increased, they need additional safety distance to the car in front of them.

The same is the case for trains. In reality, even when using continous train control systems such as ETCS or LZB, the train that is behind another train will always be required to keep a safety distance to the train in front, so that, even if the train in front suddenly comes to an abrupt stop (e.g. due to an accident), there is no danger of the train behind to drive into the train in front.

Although there is only very little danger in Factorio that the train in front of another train will come to an abrupt stop (due to a crash with another train), I still consider it appropriate that the signalling system would not allow the train behind to crash into the train in front.

Therefore, I continue to believe that the best (and most realistic way) to increase train intersection throughput would be grade separation (such as tunnels and bridges) and OpenTTD path signals.

The only way this wouldn't instantly cause a crash is when trains would also break all at the same time. The overly tight packed trains would also cause a problem at the first unmanaged signal the come across. The second train suddenly needs to break because it can't reserve the next block and you get far more separation than if you had merged the trains properly.

Trains do aso come to a sudden stop sometimes. Simples case: remove a rail in front of a train. Enabling/disabling stations and repathing supposedly cause instant stops too.

[mrvn]

As to path signals, while they are very effective in OpenTTD (where train brakes in 1 tile) it was already stated that they just can't be implemented in Factorio due to heavy impact of train acceleration/braking distance.

The main advantage of path signals is that they allow several trains into the same intersection block at the same time, provided that their paths do not cross. This is accomplished by trains being forced to reserve a route to the next signal before they are allowed past a signal.

I see no reason why the unrealistic braking distance of OpenTTD would prevent this feature from being implemented in Factorio. Trains will just have to reserve a route past a signal a bit earlier than in OpenTTD. Instead of reserving a route past a signal at that signal, they will already have to do so when approaching the signal, at braking distance.

The issue of braking distance only seems to be relevant to me in the context of the original poster's suggestion.

Also path signals are not visually readable adding more confusion to train system..

In OpenTTD, there is an option to highlight the reserved paths of trains on the track. If this were implemented in Factorio, one could argue that the signalling system would be even more visually readable than it is now.

What you describe as path signals sounds like the chain signal. The trains need to reserve the blocks (paths) they will use before they are allowed to pass the chain signal. So what is the difference? Do path signals automatically check for crossing paths instead of the user having to mark blocks with enough chain signals?

[Tekky]

What you describe as path signals sounds like the chain signal. The trains need to reserve the blocks (paths) they will use before they are allowed to pass the chain signal. So what is the difference? Do path signals automatically check for crossing paths instead of the user having to mark blocks with enough chain signals?

Path signals are very different from chain signals.

First of all, when using path signals in OpenTTD, signals are normally placed only in safe waiting points, i.e. in places where it is safe for a train to wait without causing a deadlock. Due to this, signals will only be placed before intersections, but never after or inside intersections, because you don't want trains to block intersections. This is also how signals are normally placed in reality.

In contrast to this realistic signalling setup, Factorio - and also OpenTTD when using block signals instead of path signals - requires you to place signals both before and after intersections. In order to make trains only wait at signals in front of intersections and not after intersections (which would cause the train to block the entire intersection), Factorio allows you place two signal types, normal signals and chain signals. When using block signals in OpenTTD, you can do something similar by placing block entry and exit pre-signals.

However, both in Factorio and with OpenTTD block signals, trains don't actually reserve the route to the next safe waiting position. They just make sure that all blocks to the next safe waiting location are free at the time of entering the next block (or entering braking distance of the next block). Therefore, if there are other trains crossing the path of the intended path of the train, the previously free blocks in the route of the train could suddenly become in use, which could, in certain situations, cause a deadlock, but should be preventable in most situations.

OpenTTD path signals, in contrast, actually reserve the entire route from one signal (which, as previously stated, is always a safe waiting location) to the next signal. That way, deadlocks are virtually impossible, unless you completely overload a certain route with trains or do something stupid, like placing signals in positions where it is not safe for a train to wait, i.e. after an intersection so that the train waits inside the intersection.

But the main advantage of OpenTTD path signals is that trains don't reserve entire blocks. Instead, they only reserve the actual track that they are using. That way, it is not necessary to place signals everywhere inside a train intersection in order to divide it into several blocks so that several trains several trains can use it at the same time. Trains can always use the same intersection at the same time, provided that their paths do not cross.

Due to this, OpenTTD path signals are are lot simpler to use when creating train intersections, because the number of signals necessary is much less and the positions of the signals is also more intuitive (and realistic).