Trains: Chain signals should factor in the length of the train

[mrvn]

TL;DR

Chain signals should let a train pass when it can clear the next full signal instead of when it can cross the next full signal.

What ?

When a train path hits a chain signal the path is checked ahead up until the next full signal. The train should then try to reserve an amount equal to the length of the train instead of just the next segment. If the reserved amount includes another chain signal the process repeats recursively.

What this means in practice is that a chain signal should only be green/blue when the train is not just able to enter the next segment protected by a full signal but able to fully cross said signal and release the chain signal(s) before it. The train would never get stuck on a junction because it doesn't fully fit behind the full signal at the exit.

Why ?

For junctions the rule is to put a chain signal before the junction and a full signal after the junction. The idea is that trains will only enter the junction when they are able to also leave it and will never get stuck on top of the junction. For that to work the segment after the junction protected by the full signal needs to be at least as large as the train. Otherwise the train can get stopped the next signal and it's tail can still be stuck on the unction. Similar for train stations and stackers.

When you start out and all your trains are LC or LF this is easy to do. But as you grow so do he trains. Suddenly there are LLCCCC trains and now all the junctions need to be revisited and the signals changed. Now the segment after a junction needs to have space for 6 train cars instead of just 2. It's is annoying to have to redo all the signaling everywhere and it's easy to miss some spot or make a mistake because one is in a hurry to get back to a functioning rail system. Also blueprints will be invalidated and need to be done again.

But there is more. If one has LCCCLCCCLCCCLCCC trains to carry ores then after a junction the next segment has to be 16 train cars long. But for many of the more advanced goods shorter trains will suffice, down to LC trains. Now those LC trains will also have to cross those 16 train car segments after each junction before the next train can even enter it. In a well functioning but busy train system that means ALL trains will keep to a 16 train car + breaking distance separation no matter how short they are. For an LC train that means a waste of 14 train cars distance and a much reduced throughput of the train system.

The whole train system is slowed down significantly because of a few long ore trains that occasionally have to drive through on their way to the smelter. On the other hand with my proposal the segment size after a junction doesn't matter. The train will only enter a chain signal segment if it can fully clear it. So LCCCLCCCLCCCLCCC will wait till there is 16 train car free space after the junction while LC trains only wait till there is 2 train car free space. Adding longer trains no longer breaks existing signaling and throughput doesn't go down for smaller trains just because longer ones are added.

[Mylon]

I'd chalk this up to user error. It may be a wise idea to put the first non-chain signal leaving your intersection further away from the intersection.

[mrvn]

I'd chalk this up to user error. It may be a wise idea to put the first non-chain signal leaving your intersection further away from the intersection.

It's not user error. You can't place the next signal 2 cars away if the next approaching train is 2 cars long and 16 cars away when the next approaching train is 16 cars long.

[eradicator]

I'd chalk this up to user error. It may be a wise idea to put the first non-chain signal leaving your intersection further away from the intersection.

It's not user error. You can't place the next signal 2 cars away if the next approaching train is 2 cars long and 16 cars away when the next approaching train is 16 cars long.

It is user error because you're trying to use an L-16C on a junction designed for L-2C trains. Every rail guide tells you that *all* segments must at least fit the *largest* train in the network. This wouldn't even work in OTTD, and adding intransparent "smart" logic to the mix will just shift the problems to somewhere else and make debugging rail networks frustrating.

Imho the best solution is to keep the "outer" ore transportation network seperate from the "inner" production network.

[mrvn]

I'd chalk this up to user error. It may be a wise idea to put the first non-chain signal leaving your intersection further away from the intersection.

It's not user error. You can't place the next signal 2 cars away if the next approaching train is 2 cars long and 16 cars away when the next approaching train is 16 cars long.

It is user error because you're trying to use an L-16C on a junction designed for L-2C trains. Every rail guide tells you that *all* segments must at least fit the *largest* train in the network. This wouldn't even work in OTTD, and adding intransparent "smart" logic to the mix will just shift the problems to somewhere else and make debugging rail networks frustrating.

Imho the best solution is to keep the "outer" ore transportation network seperate from the "inner" production network.

And this issue is about just that limitation. It doesn't have to be that way. Rail networks should be upgradable to larger trains without requiring a complete signal replacement.

[ratchetfreak]

And this issue is about just that limitation. It doesn't have to be that way. Rail networks should be upgradable to larger trains without requiring a complete signal replacement.

There are plenty of places where moving to longer trains creates issues in a network designed for a certain size of train.

And it's not a full signal replacement it's only moving the first signal after the exit signal on the junctions that will service that long train. The other signals can remain in place no problem.

[planetmaker]

Chain signals should let a train pass when it can clear the next full signal instead of when it can cross the next full signal.

I disagree.

Reasoning:
Current behaviour is simple to comprehend and also implement: a chain signal allows passage to the next green normal signal. Everyone can understand that; you can see that directly on the map. The state of chain signals does not depend on what train is passing, just that *a* train wants to pass.

Your suggestion would mix the train status into the signal status. Thus a signal would not have any longer a well-defined state and would need to know what train queries passage - it would depend (much more closely) on the train than its simple presence and request for path to a destination.
In conjunction with this increase in pathfinder difficulty, the player would have a much harder time to detect bottlenecks as you would need to check all section lengths.

Currently the player-side solution is easy: just build track sections >= length of your longest train and you're fine.

EDIT: Upgrading to longer trains never is easy nor is there need for that. And currently it's relatively simple: just remove some normal signals after junctions. The junctions themselves don't need any change.
Upgrading from 1 SPM to 100 SPM or 100 SPM to 1000 SPM or "normal production" to "beaconed production" is not a simple copy&paste either.

[mrvn]

Chain signals should let a train pass when it can clear the next full signal instead of when it can cross the next full signal.

I disagree.

Reasoning:
Current behaviour is simple to comprehend and also implement: a chain signal allows passage to the next green normal signal. Everyone can understand that; you can see that directly on the map. The state of chain signals does not depend on what train is passing, just that *a* train wants to pass.

Your suggestion would mix the train status into the signal status. Thus a signal would not have any longer a well-defined state and would need to know what train queries passage - it would depend (much more closely) on the train than its simple presence and request for path to a destination.
In conjunction with this increase in pathfinder difficulty, the player would have a much harder time to detect bottlenecks as you would need to check all section lengths.

Currently the player-side solution is easy: just build track sections >= length of your longest train and you're fine.

EDIT: Upgrading to longer trains never is easy nor is there need for that. And currently it's relatively simple: just remove some normal signals after junctions. The junctions themselves don't need any change.
Upgrading from 1 SPM to 100 SPM or 100 SPM to 1000 SPM or "normal production" to "beaconed production" is not a simple copy&paste either.

My solution is also simple to comprehend: A chain signal prevents a train from being stuck before passing the next full signal. That's probably even easier for people to use since it's more foolproof.

Which is the whole point. The proposed solution does not fail if a block is smaller than the train length. You are fine whatever you do.

The benefit is that one can accomodate trains of different sizes on the same network without reducing the blocks to the longest train length.
Any correctly signaled network will continue to work as now. But tons of currently dangerous signal configuration would start behaving safely.

And yes, the train status gets mixed into the signal. But that is already the case for chain signals in the blue state. The signal can only decide to let a train pass or block it by knowing which path it wants to take. I only add the length to the state as well.

[planetmaker]

And yes, the train status gets mixed into the signal. But that is already the case for chain signals in the blue state. The signal can only decide to let a train pass or block it by knowing which path it wants to take. I only add the length to the state as well.

Not quite, it is different things. Look at how signals behave and you will start to see the complications:
Signals show a state.
Currently normal signals: green if block guarded by it is free of any train, otherwise red. No knowledge is required whatsoever about any vehicles
Currently chain signal: blue, if undecided (several exits, no path requested). green, if signal following requested direction is green, red otherwise.

Your suggestion:
chain signal remain mostly unchanged by your suggestion: blue, if undecided (no path requested). green, if following signal in requested reservation is green. red if following signal is red. But the block signal terminating the block now might never become green...

normal signal are changed drastically:
green, if following block is empty and train shorter than block.
But this is crucial: What does it show when train is too long to fit into the block it guards? blue? red? Does it become a chain signal asking the following signal to be free, if train doesn't fit? What does it show when no train asks for a reservation for the block it guards? Also blue like chain signals?



Thus you see that you basically ask to remove easy-to-understand behaviour of the most basic signal to become something like half a chain signal where its state depends on the train which wants to pass. And you will block trains driving on the network at all, if your signal spacing is smaller than your train length

[Mylon]

Devil's advocate time:

Code-wise this probably wouldn't be too hard to do. Trains already reserve track sections ahead of their position using their braking distance. This marker that trains use can be seen using the show train breaking distance debug option. It shouldn't be too hard to attempt to reserve additional distance equal to train length so long as train is accelerating.

[ratchetfreak]

And yes, the train status gets mixed into the signal. But that is already the case for chain signals in the blue state. The signal can only decide to let a train pass or block it by knowing which path it wants to take. I only add the length to the state as well.

Not quite, it is different things. Look at how signals behave and you will start to see the complications:
Signals show a state.
Currently normal signals: green if block guarded by it is free of any train, otherwise red. No knowledge is required whatsoever about any vehicles
Currently chain signal: blue, if undecided (several exits, no path requested). green, if signal following requested direction is green, red otherwise.

Your suggestion:
chain signal remain mostly unchanged by your suggestion: blue, if undecided (no path requested). green, if following signal in requested reservation is green. red if following signal is red. But the block signal terminating the block now might never become green...

normal signal are changed drastically:
green, if following block is empty and train shorter than block.
But this is crucial: What does it show when train is too long to fit into the block it guards? blue? red? Does it become a chain signal asking the following signal to be free, if train doesn't fit? What does it show when no train asks for a reservation for the block it guards? Also blue like chain signals?



Thus you see that you basically ask to remove easy-to-understand behaviour of the most basic signal to become something like half a chain signal where its state depends on the train which wants to pass. And you will block trains driving on the network at all, if your signal spacing is smaller than your train length

normal signal behavior can be unchanged and be the dumb green when block is free, red if block is reserved/occupied. If at any point you don't want that behavior you change it to a chain signal. There are times where it is useful for a train to straddle blocks as it's waiting, mostly in places where rails merge of a single-header station where you can let the next train start to roll up to the station while the previous train is still rolling out.

However another danger is that really long trains will end up recursing on chain signals further than just the next normal signal. In extremis this means that when a big bertha train goes through your base, it cannot start to move until it has fully reserved its path (shutting down most of the train traffic in the process if it can make that reservation in the first place) or you happen to have a long section without any chain signals.

[eradicator]

Code-wise this probably wouldn't be too hard to do.

This isn't a "famous last sentences" thread though :p.
Devils rebuttal: There are other considerations: maintainability, performance, stability, user friendlyness, etc. An "if it can be done it must be done" approach does not make good software.

However another danger is that really long trains will end up recursing on chain signals further than just the next normal signal. In extremis this means that when a big bertha train goes through your base, it cannot start to move until it has fully reserved its path (shutting down most of the train traffic in the process if it can make that reservation in the first place) or you happen to have a long section without any chain signals.

Exactly what i meant when i said "it'll cause other problems". Thanks for the great example.

[mrvn]

And yes, the train status gets mixed into the signal. But that is already the case for chain signals in the blue state. The signal can only decide to let a train pass or block it by knowing which path it wants to take. I only add the length to the state as well.

Not quite, it is different things. Look at how signals behave and you will start to see the complications:
Signals show a state.
Currently normal signals: green if block guarded by it is free of any train, otherwise red. No knowledge is required whatsoever about any vehicles
Currently chain signal: blue, if undecided (several exits, no path requested). green, if signal following requested direction is green, red otherwise.

Your suggestion:
chain signal remain mostly unchanged by your suggestion: blue, if undecided (no path requested). green, if following signal in requested reservation is green. red if following signal is red. But the block signal terminating the block now might never become green...

normal signal are changed drastically:
green, if following block is empty and train shorter than block.
But this is crucial: What does it show when train is too long to fit into the block it guards? blue? red? Does it become a chain signal asking the following signal to be free, if train doesn't fit? What does it show when no train asks for a reservation for the block it guards? Also blue like chain signals?



Thus you see that you basically ask to remove easy-to-understand behaviour of the most basic signal to become something like half a chain signal where its state depends on the train which wants to pass. And you will block trains driving on the network at all, if your signal spacing is smaller than your train length

I think you misunderstood something. Normal signals don't change at all. Only chain signals change. If you put 4 normal signals close together with the last being red and a long train approaches it would still reserve and use the first three signals and come to stop before the 4th signal even though it doesn't manage to clear the first three signals. The basic signal remains unchanged.

Only the chain signal would change. And the change would be that it would have to be blue more often. Even if the next full signal is green a train might not pass because of it's length. So that would make the signal blue. Only when the train approaches and the signal sees it's short enough to clear the next full signal can the chain signal truly turn green. But it would probably look better for chain signals to remain green per default. They can turn blue/red when a train approaches that is too long to pass.

However another danger is that really long trains will end up recursing on chain signals further than just the next normal signal. In extremis this means that when a big bertha train goes through your base, it cannot start to move until it has fully reserved its path (shutting down most of the train traffic in the process if it can make that reservation in the first place) or you happen to have a long section without any chain signals.

Yes, that is a danger. A likely one actually. If you build junction too close then longer trains will reserve them all in one go. But the alternative is for the big bertha to enter the base and get stuck. Then all traffic around it piles up and you have grid lock. Nothing moves ever again until you move a bunch of trains by hand. With my suggestion the big bertha just takes a long time to reserve a path and stops traffic for a short while. Or worst case never manages to reserve the path. It's a more localized break down.

On the other hand shouldn't every junction big bertha can't reserve because some shorter train is in the way add to the cost of the path? Driving through the base should increase the score enough for big bertha do take the longer track going around the base. Note that big bertha will be stuck before the first chain signal outside the base with my proposal. So I think it would sit there a while and then re-path around the base. While currently it's likely to enter the base and only then hit a blocked chain signal. Too late to take the track around the base.

[JimBarracus]

Chain signals should let a train pass when it can clear the next full signal instead of when it can cross the next full signal.

simple rule: the largest train has to fit in every block

everything else is just bad track design
there should always be enough space for a train to leave a junction.
if there is not enough space the train should not enter the junction.

The game should not fix any design mistake.
sure its about automation, but you are the one to set the rules with very basic tools.

[mrvn]

Chain signals should let a train pass when it can clear the next full signal instead of when it can cross the next full signal.

simple rule: the largest train has to fit in every block

everything else is just bad track design
there should always be enough space for a train to leave a junction.
if there is not enough space the train should not enter the junction.

The game should not fix any design mistake.
sure its about automation, but you are the one to set the rules with very basic tools.

It's not about fixing design mistakes. Even with my suggestion having junctions nearer than the train size is still a bad design. But as said at the beginning the train size is not a constant. What was once a good design becomes a bad design, fatally so.

The suggestion is about having the train network just become inefficient for trains larger than it was build for rather than grid lock. You don't want to have to rebuild your whole factory because later in the game you need longer trains for only some goods like ores or plates. It's about keeping the train network expandable.

[Mylon]

The easiest way to adapt an old train network for longer trains is to use chain signals on the exit for your intersection. If the first non-chain signal is 16 car lengths away from the intersection your 16 car train won't enter the intersection unless it can clear it. It's a very simple adjustment to make.

[ssilk]

What factorio needs here are more signal types.

- In this case a signal, that prevents trains larger than X to enter.

Other types that makes sense:
- Signal to prevent driving faster than X km/h
- Signal to tell the path-algorithm to avoid this part

[steinio]

What factorio needs here are more signal types.

- In this case a signal, that prevents trains larger than X to enter.

Other types that makes sense:
- Signal to prevent driving faster than X km/h
- Signal to tell the path-algorithm to avoid this part

Yeah because a lot of players aren't even struggling with 2 signal types.

[bobucles]

- Signal to tell the path-algorithm to avoid this part

Doesn't the normal rail stop do a soft version of this, something like +1000 to pathing length? That may have been patched.

[ssilk]

Yeah it should. But it adds new train stops.


Yeah, of course: Edit stop, edit name, rename to " " will fix this.