[Rseding91] [0.14.14] Train stuck in between chain signals (due to rerouting?)

[Sephrat]

A train passed through a chain signal and suddenly stopped some chain signals later. It shouldn't have entered this section if the path wasn't free.

train stops.gif (2.76 MiB) Viewed 13779 times

Additionally, the train doesn't reroute even though it has alternative available paths. If I switch the automatic mode off/on, it changes its path and goes through an alternative (available) route.

Here is my save just a couple of seconds before the train arrives (vanilla): https://www.dropbox.com/s/mwx0udn108k09 ... g.zip?dl=0

You can find a detailed explanation of my setup and what I'm trying to achieve here. As I've explained, I have a lot of trouble with the pathing algorithm on this setup. I don't believe it is directly linked to this bug but this setup has unexplained patterns regarding train pathing.
TL;DR: one entrance with a chain signal, multiple routes (waiting bays) splitting and merging progressively, leading to a station, all of them being of equal length but with entrances closer/farther from the station. Intermediate chain signals are there to make sections smaller so that multiple trains can enter the waiting bays at a time.

What seems to happen is that the train entered the chain signals section, planning to go through an available waiting bay. For some reason when passing one of the chain signals, it rerouted twice (!!) through another waiting bay, but the second rerouting lead to a used waiting bay* (next regular signal is red). Therefore the chain signal suddenly switches from yellow to red, and stucks my train in the middle of chain signals.


*Why it did that in the first place, I really wonder: I don't understand (broke? ) the pathing algorithm on my setup... However it seems somehow correlated to the trains positions on the merging part of the waiting bays: I noticed it in the other topic, and when this bug occurs a train is moving in the merging part, probably causing the multiple reroutings. I would love you guys if you gave an explanation of what really happens here. I would really love this kind of setup to work, which doesn't seem possible so far.

[Loewchen]

viewtopic.php?f=173&t=26409

[Rseding91]

I'm pretty sure I have a fix for this. I mean.. it fixes this scenario and the one linked I just don't know fully what the ramifications of my fix might be. At this stage in 0.15 stabilization I think it's too risky. I'll put it in 0.16.

I understand now what's causing the train to do what it's doing and why it's doing it - it was simply flawed in the case of large chain signal blocks with multiple exits.

This is the scenario:

• 1. A train is driving on a path towards some point.
  2. The path crosses a set of chain signals which is perfectly valid for the train to cross
  3. While the train is driving over the chain signals it detects that at it's current speed accounting for its braking force the total rail distance in front of itself + 1 contains a rail signal that it can't reserve
  4. In this state the train tries to see if there's a better path that might be able to go around the blocked chain signal instead of just "stop at signal and wait"
  5. If a new path is found that doesn't block the train then it keeps driving as if nothing happened
  6. If there's no new path or the new path is also blocked by a signal the train slows to arrive at the blocked signal

In the above steps the logic broke at step 4: if the train is in the middle of a chain signal block and it finds a *new* path through the same signal block that doesn't currently have an exit it will have to stop at the next chain signal on the rail its sitting on thus the train sits in the middle of a set of chain signals defeating the entire purpose of the chain signal - never enter when you can't exit.

[Bilka]

Do I understand this right? The last chain signal of the 3 chain signals turns blue (because a rail signal at that end of the chained blocks becomes red?) while the train is inside of the chained blocks. Because the chain signal is blue and the route the trains wants to go to is blocked (aka the rail signal at that end of the chain signal block is red), the train has to stop at the chain signal.

If my above paragraph is right, how would you fix that? There will always be long enough chained blocks so that a rail signal in a trains path can turn red while it's inside the chained blocks.

[Rseding91]

Do I understand this right? The last chain signal of the 3 chain signals turns blue (because a rail signal at that end of the chained blocks becomes red?) while the train is inside of the chained blocks. Because the chain signal is blue and the route the trains wants to go to is blocked (aka the rail signal at that end of the chain signal block is red), the train has to stop at the chain signal.

If my above paragraph is right, how would you fix that? There will always be long enough chained blocks so that a rail signal in a trains path can turn red while it's inside the chained blocks.

No, once a train enters any chain signal block (assuming the logic is correct) it will always take the pre-determined exit route - that's where it's currently broken. If when it reaches the exit route the normal signal is red it will wait at that non-chain signal.

However, if you're signaled your rails correctly that never happens because in a proper signaled setup the "end" signal would be impossible to block except by the train coming from the chain signals: AKA: one-way rails.

[steinio]

Does this fix roundabouts?

[Rseding91]

Does this fix roundabouts?

Probably. I don't have a save that shows a reproducible problem with them so I couldn't test them.

[orzelek]

There was mention above that this will be fixed for 0.16 - and it's in latest release notes.
Is factorio bot a bit to zealous or it was moved to 0.15?

[Sephrat]

YES!!
Thanks for the fix, I'm excited to build a mega-train network in my 0.15 game and see how it goes.

[Rseding91]

There was mention above that this will be fixed for 0.16 - and it's in latest release notes.
Is factorio bot a bit to zealous or it was moved to 0.15?

I put it in 0.15. I figure if it's going to cause problems it's easy enough to revert but at most it would cause "a train isn't going where I want" kind of problems and not crashes.

[SupplyDepoo]

If when it reaches the exit route the normal signal is red it will wait at that non-chain signal.

It should be impossible for that to happen. When a train passes a chain signal, it reserves the exit.

However, if you're signaled your rails correctly that never happens because in a proper signaled setup the "end" signal would be impossible to block except by the train coming from the chain signals: AKA: one-way rails.

Even if you have two-way rail and a shared exit block, or an exit block that crosses another exit block, it shouldn't cause problems. There's no "correct way to signal the exit block" in that sense. No matter how it's signaled, trains should never stop in a chain-signaled block, because of the reservation mechanic.

[ykyjohn]

Stuff

the signs layout you did is not optimized. As i can see you missused the chains, and the stop sign too. The chains you used for the parking is no needed. The 3 which one of them the train stopped, all 3 of them are missused.
The top of the SS you took have 2 stop signs there which it should'nt be any there.
You did potencially found that bug, but trueth be told the train signs layout is not the way it should be done, it makes confusing, it is not simplified and in biger scale only gets worst.

A good tip to fallow is :
1 - to make trains always wait befor entering a tight spot usualy smaller than a train with 4 cargos.
2 - never put signs between crosses to try a very complicated stuff, just dont do that, there are soo much simpler way .
3 - use stop signs regularly to make flow constante, like 1 stop for each space equivalent to a train with 4 cargos.
4 - try to use as few signs as possible.

So with that in mind, if the train see a cross ahead it shold see a chain sign, the stop sign should be after the cross so the train can know it is ok to cross it.
chain serves to tell the train to hold its position untill its clear to proceed.

So an easy way to remember that, is to ask the questions below, only when you are using chains and for that you also must use the stop sign with it.
Stop sign = can i leave?
Chain sign = can i enter?
You see the stop sign and the chain sign defines an area which those question will make more sense to you when using them.
The scope created with these 2 signs simply asks if the train can pass through it, if not it will wait outside, evading a deadlock or any crash.

SS= stop sign
CS= Chain sign
X= cross(any condition where the raill meets another)
5 = the number of space for 1 train + its 4 cargos.

So we just need to recognize what is what.
Train begings here -> SS -> 5 -> SS -> 5 -> SS -> 5 -> CS -> X -> SS -> 5 -> SS ->
The example show that when ever you find a cross ahead you should use chain sign setups to cross it. Never allows a train to stop inside a crossing and make it possible to have as many trains in line as possible without compromizing the flow of them.

If you fallow those rules you will benefit from its simplicity and easy flow.

Im sure if you did use the sign the way it should you would never have found this bug. ^^

The purpose of this topic is not to demonstrate proper signalling but to show of a bug, unless one has additional information on this particular bug I would ask to refrain from making comments here.
-Loewchen

[Sephrat]

Stuff

the signs layout you did is not optimized. As i can see you missused the chains, and the stop sign too. The chains you used for the parking is no needed. The 3 which one of them the train stopped, all 3 of them are missused.
The top of the SS you took have 2 stop signs there which it should'nt be any there.
You did potencially found that bug, but trueth be told the train signs layout is not the way it should be done, it makes confusing, it is not simplified and in biger scale only gets worst.

A good tip to fallow is :
1 - to make trains always wait befor entering a tight spot usualy smaller than a train with 4 cargos.
2 - never put signs between crosses to try a very complicated stuff, just dont do that, there are soo much simpler way .
3 - use stop signs regularly to make flow constante, like 1 stop for each space equivalent to a train with 4 cargos.
4 - try to use as few signs as possible.

So with that in mind, if the train see a cross ahead it shold see a chain sign, the stop sign should be after the cross so the train can know it is ok to cross it.
chain serves to tell the train to hold its position untill its clear to proceed.

So an easy way to remember that, is to ask the questions below, only when you are using chains and for that you also must use the stop sign with it.
Stop sign = can i leave?
Chain sign = can i enter?
You see the stop sign and the chain sign defines an area which those question will make more sense to you when using them.
The scope created with these 2 signs simply asks if the train can pass through it, if not it will wait outside, evading a deadlock or any crash.

SS= stop sign
CS= Chain sign
X= cross(any condition where the raill meets another)
5 = the number of space for 1 train + its 4 cargos.

So we just need to recognize what is what.
Train begings here -> SS -> 5 -> SS -> 5 -> SS -> 5 -> CS -> X -> SS -> 5 -> SS ->
The example show that when ever you find a cross ahead you should use chain sign setups to cross it. Never allows a train to stop inside a crossing and make it possible to have as many trains in line as possible without compromizing the flow of them.

If you fallow those rules you will benefit from its simplicity and easy flow.

Im sure if you did use the sign the way it should you would never have found this bug. ^^

The purpose of this topic is not to demonstrate proper signalling but to show of a bug, unless one has additional information on this particular bug I would ask to refrain from making comments here.
-Loewchen

I use that many signals only for throughput reasons: it helps loosening the bottleneck. The many chain signals are only there to have shorter blocks. I know it could work with fewer signals, but the way I designed it make it so that several trains may enter the waiting bays. If one goes all the way to the end, the following one can enter the first waiting bay while the first train still is one its way to its assigned waiting bay.
Anyway, we should discuss it on the original thread instead of the bug report one. let's continue there: viewtopic.php?f=18&t=34321&p=216771

[Nexarius]

Does this fix roundabouts?

Probably. I don't have a save that shows a reproducible problem with them so I couldn't test them.

No. If a station is being disabled and the train changes route while in a roundabout it can still get stuck. (0.15.27)

[Rseding91]

Does this fix roundabouts?

Probably. I don't have a save that shows a reproducible problem with them so I couldn't test them.

No. If a station is being disabled and the train changes route while in a roundabout it can still get stuck. (0.15.27)

That's a different thing. There was an issue with trains in roundabouts.

[triffid_hunter]

Does this fix roundabouts?

Probably. I don't have a save that shows a reproducible problem with them so I couldn't test them.

No. If a station is being disabled and the train changes route while in a roundabout it can still get stuck. (0.15.27)

That's a different thing. There was an issue with trains in roundabouts.

This is fixable and we'd love it to be fixed, but as a programmer I can see that it's really not easy.

Now that random rerouting after chain signal is fixed (0.15.27 changelog, haven't tried yet), we need to do something intelligent on /forced/ rerouting after chain (eg destination station becomes disabled, track tile gets removed, normal signal forced red by circuit, etc)

So, what should we do in this case? Continue on the planned path *anway* until we pass the chain exit (first normal signal)? That could break stackers and such, but is still worth exploring.

Evaluate all reachable chain exits and ignore chain signals? That could cause crashes when multiple trains are in the same chain block - unless the train internally converts chains to normal signals until it exits the chain block.. This could still deadlock if there's two trains in a roundabout, in which case they'd want to fall back on continuing on their original planned route which should still be reserved/clear.

Hm that might work quite well, but if there's another viable destination station it could try to reroute towards that..

Plenty of thinking to be done on this one, but what we specifically *don't* want is trains *parking* in a chained roundabout/intersection when they get confused - they should exit the chain block and intelligently go *somewhere* outside the chain block without crashing into anyone else, somehow..

PS: the stacker thing might be more easily solved if we could attach circuit wires to chain signals

glossary for this post:
"chain block" is the block that a train would be in if all chain signals were removed, and only normal signals remained. Chain signals (already) make it so a train won't enter a "chain block" until it can exit that chain block past a normal signal, and multiple trains can simultaneously occupy a chain block.
"chain exit" is all reachable normal signals from within the current "chain block" - ie places that the train can exit the current chain block

[SupplyDepoo]

1. Trains should never reroute inside of chain-signaled blocks.
2. When a train reserves blocks, it should be guaranteed that it will use them.

[Ripshaft]

O, I didn't realize this was actually a bug, I'd always find a spot to place another chain signal to isolate so that a different train could travel through the same area... but I guess that once that other train has passed it prompts the stuck train to recalculate its path? Or I have not been victim to this particular problem... either way, yay fixes!

[triffid_hunter]

O, I didn't realize this was actually a bug, I'd always find a spot to place another chain signal to isolate so that a different train could travel through the same area... but I guess that once that other train has passed it prompts the stuck train to recalculate its path? Or I have not been victim to this particular problem... either way, yay fixes!

The bug happens when a train reroutes, passes a signal or three and then sees *itself* in the next block and refuses to budge until manually moved.

(it can also happen with multiple trains in large junctions, but this is the easiest one to reliably trigger and visualise)

This is really easy to trigger with 6-long or longer trains in roundabouts with 4 to 8 chain signals on the ring. It'll plan to go through the roundabout then reroute after the first signal and decide to go the other way, but its own tail is in that block and trains will never move into an occupied block - boom, deadlock.

There was a note in a recent changelog that the devs have stopped trains randomly rerouting after passing a chain signal but you can still trigger the deadlock by disabling their destination station while they're in the roundabout.

[Zavian]

Personally I consider disabling stations whilst trains are en-route to them to be a case of shooting yourself in the foot. If that is causing you problems then don't disable stations whilst trains are en-route.