Factorio Forums

As the bugfix introduced in 0.15.27 regarding chain signals is pretty relevant to a project of mine I decided to take a closer look at the consequences of it. There are some quirks and I'm pretty sure that not all of them are intended.

Setup (attached savefile): Turning on the constant combinator by A launches a train from the west that is heading to station F. It also launches the train by station F that will occupy it. Once the rail signal by A is no longer green the signal by D opens allowing the train to reach E. I'm examining what happens when you place chain signals at A,B and/or C. In all scenarios what I'd expect is that the train changes path and reaches the station by E. The train sees the red signal on the path to F way before it passes the first chain signals and by that time the path to E is also open.

Different scenarios:

1. No chain signals
What happens: the train changes path and reaches the station at E

2. Chain signal at A
What happens: the train changes path and reaches the station at E

3. Chain signal at B
What happens: the train changes path and reaches the station at E

4. Chain signal at C
What happens: the train does not change path and stops at rail signals by C

5. Chain signal at A and B
What happens: The train changes path and stops at D

6. Chain signal at A and C
What happens: the train does not change path and stops at rail signals by C

7. Chain signal at B and C
What happens: the train does not change path and stops at rail signals by C

8. Chain signal at A, B and C
What happens: the train does not change path and stops at rail signals by C

These results lead me to believe that the train locks its path once it has a chain signal reserved and not when it is in a block controlled by a chain signal. As shown this yields some pretty weird results, it also means it is still possible to deadlock roundabouts by path changing as shown below: Guess I don't need to retire my deadlockomatic just yet

@aaargha Did you do anything to cause the train to change its path for that roundabout deadlock example? Or did the train decide to path a 270 degree right turn rather a 90 degree left turn without something happening to cause it to repath? (If the later would you mind uploading the save for the roundabout? The devs are much more likely to look at it if there is a savefile).

The train changes its path from its initial W->E path to heading north after it has passed the northern chain signal. The path change is caused by a red signal on the eastern path. It is the same mechanic as scenario number 5 in the OP.

I'll attach a primed version of the test save (needs creative mode for that setup to run). Just turn on the copper plate constant combinator to the top left to get things going.

Lets start by the first "wrong" behaviour.

aaargha wrote: 4. Chain signal at C
What happens: the train does not change path and stops at rail signals by C

The problem is, that both ways have red signals. If I remove the signaling from the top signal, it just works as expected. The top signal starts to be green way too late.

kovarex wrote:Lets start by the first "wrong" behaviour.

aaargha wrote: 4. Chain signal at C
What happens: the train does not change path and stops at rail signals by C

The problem is, that both ways have red signals. If I remove the signaling from the top signal, it just works as expected. The top signal starts to be green way too late.

If that was the case then none of scenario 1, 2, or 3 would work, which they clearly do. When the train reaches the split the top signal is actually green. I've attached an updated version of the demo that more clearly shows the behaviour.

EDIT: It works when removing the circuitry from the top signal because the train chooses that destination by default.

It seems that I was a bit too quick when making the v2 demo, the additional sensors break behaviour 5. I've attached a new version that should be able to show all the behaviours mentioned on the OP.

I'll also attach a vanilla demo for the roundabout deadlock, just turn off the constant combinator on the hazard concrete to start things.

I just noticed that this was still in pending but I'm a bit unsure what additional information is being asked for at the moment. If there is anything I can supply that would help the investigation please let me know and I'll do my best to help. If not, then don't mind me and carry on

Disclaimer: The following is mostly speculation/guessing/suggestions from my part:
It seems to me that the path lock is currently applied when "Do I currently have a chain signal reserved?" is true instead of "Was the last signal I passed a chain signal?". If the second option was used instead, it would fix the problems with 4 and 5, which should make all intersections deadlock safe for "soft" path changes as that'd lock the path in the critical area. With that change the behaviours should change like so:

2. Chain signal at A
What happens: the train does not change path and stops at rail signals by C

3. Chain signal at B
What happens: the train does not change path and stops at rail signals by C

4. Chain signal at C
What happens: the train changes path and reaches the station at E

5. Chain signal at A and B
What happens: the train does not change path and stops at rail signals by C

Which would IMO be much more preferred, while there might be some situations where trains would take longer paths than absolutely needed (a better path became available while between the last chain signal and the rail signal), it would make the worst cases much more reasonable.

I think it may be possible to further improve the trains behaviour if the lock for soft path changes was changed from "Do not change path" to "Only accept a new path if it can reach a rail signal". This is likely much more complicated to implement than the first suggestion, so it's mostly wishful thinking on my part It should, however, when combined with the first suggestion, change the behaviour for all cases to "the train changes path and reaches the station at E".

In the roundabout case the train stays on its path as desired if signal A is moved 2 tiles to the right and a chain signal is added in its old position.


This shows an inconsistency in how reserved paths are handeled:
- For a reservation to be possible the path into the block that begins with signal A needs to be clear
- The path that is actually reserved already ends if the train has passed signal B, thus the train is allowed to change its path. But it still has not reached the signal including which the path needed to be clear for the reservation to be possible in the first place.

I hope this explaination is somewhat understandable.

The bugfix introduced in 0.16.0

Train can't block its own path anymore. (19619)

helps in some cases but makes others worse. I think it is the wrong fix for this issue.

The 0.16.0 fix:

• - Short trains
  • -Are working
  - Long trains:
  • - In setups with unavoidable self intersections caused by the rail layout the train crashes
    - In setups with self intersections caused by repathing the train crashes, except if adding additional chain signals before the exiting rail signals which prevents repathing

The fix proposed in the previous post:

• -Short trains
  • - In setups with unavoidable self intersections caused by the rail layout still deadlock the train. But this can be solved by removing inappropriate chain signals
    - In other setups simply do not repath and thus do not intersect themselfes
  - Long trains
  • - In setups with unavoidable self intersections caused by the rail layout deadlock the train. It does not crash and cannot be solved by signals, just by another rail layout
    - In other setups simply do not repath and thus do not intersect themselfes

Before any fix:

• - No train crashes
  - Chain signals before the exit rail signals are a workaround

- Long trains:
- In setups with unavoidable self intersections caused by the rail layout the train crashes

Isn't building such rail layouts and then using long trains a case of shooting yourself in the foot?

Zavian wrote:

- Long trains:
- In setups with unavoidable self intersections caused by the rail layout the train crashes

Isn't building such rail layouts and then using long trains a case of shooting yourself in the foot?

Yes, it is. But in a bigger layout you (or at least I) sometimes forget what I (or maybe someone else in a multiplayer build) built previously in some obscure spot of the rail network. And when this happens I prefer having a deadlock over having a crash.

Edit: And yes, in fact this never happened to me. But I don't want it to happen to other players, either.

For those following this: Some changes made to chain signal block detection in 0.16.17 (didn't make the changelog) actually resolves this bug as it is posed in the OP.

The detection was changed from "is a chain signal reserved" to "was the last signal passed a chain signal". In my testing this makes basically all reasonably signalled intersections deadlock/crash safe (even roundabouts), as long as the path of the train is not broken (disable station/broken rails). Hard path changes can still cause issues but that's pretty tricky to get around.

Nice. Does that mean you'll endup retesting a ton of intersections?

I'll have to change the deadlock ratings of a few of them and probably rerun the throughput testing on at least one. Most designs tested haven't changed that much, except that those rated B-E should need hard path changes to deadlock. As I'll be changing how I rate intersections anyway this should actually save me some work in that I can get away with fewer ratings.

aaargha wrote: The detection was changed from "is a chain signal reserved" to "was the last signal passed a chain signal".

Are you talking about the detection if a train is disallowed to repath? So if the described condition is true, repathing is not allowed? This would be awesome , finally evereything should be working without an additional signal. Thanks for the info.

Yep, as long as the train is not forced to do a hard re-path it should be fine.