Duplicate Train Stations: Behavior Change?

[fandingo]

I've used the following design a ton in the past, but in my new save, it's not working at all. My trains are constantly getting deadlocked.



The idea is pretty simple. This is a "collector" station. It has two input stations in the middle (note the passive provider chests). Both stations are named "iron collector." The two outer stations are named "iron output." The idea is that several trains can use this station simultaneously, and they should have a station available without too much delay. The problem is that trains seem to predetermine their destination station when they begin, even though both destinations have the same name. For example, in the screenshot, the train is the top right is deadlocked; it's trying to get to the leftmost station, even though another "iron output" station is available. If I toggle that train to manual mode and back to automatic, it immediately goes to the available station.

What's even worse is that I have the train on the left stopped in manual mode, and trains are still routing to it, even when the other was available when they departed...

I could've sworn this used to work properly. I've been using this design since at least 0.12, and I don't remember any deadlocks. I'm not sure how you can make use of duplicate train stations anymore.

[Rockstar04]

Can you take a screenshot of the station names? This should work exactly as you expect, they are all lined up correctly. The only thing I can think, and cant see, is that they have the exact same name.

[DaveMcW]

The deadlock is because of the normal signal in the middle of the intersection block. Remove it.

Duplicate station names are known to be buggy, there is no good fix right now. The best you can do is build a waiting area to hold every train in a worst case scenario.

[fandingo]

Can you take a screenshot of the station names? This should work exactly as you expect, they are all lined up correctly. The only thing I can think, and cant see, is that they have the exact same name.

They are the same name, or toggling to manual/auto modes wouldn't direct the train to the other station.

[fandingo]

The deadlock is because of the normal signal in the middle of the intersection block. Remove it.

Which signal? The signals at the "back" (top) of each station is required, or else only one station in the entire input/output station complex could be used at a time.

Duplicate station names are known to be buggy, there is no good fix right now.

Do you have a link to the bug report?

The best you can do is build a waiting area to hold every train in a worst case scenario.

Yeah, that's what I'm considering. Just thought I'd ask here first. It's unfortunate since that strategy takes like 3x the space and has substantially less throughput. My understanding is that I'd only be able to get 1 input and 1 output station working. The only improvement is not deadlocking, but I can solve that problem by making these stations longer, so the main line has more room for the waiting trains.

[DaveMcW]

Which signal? The signals at the "back" (top) of each station is required, or else only one station in the entire input/output station complex could be used at a time.

bad-signal.jpg (233.94 KiB) Viewed 9188 times

[fandingo]

I appreciate you trying to help, but that signal is fine. The train is stopped there because the one above it is. The train in the top right is the deadlocked problem. It's waiting at a blue chain signal, which has a green signal to the right "iron output" station. The problem is that the top right train is incorrectly trying to go to the occupied "iron output" station (far left) instead of the available station with the same name.

If I remove the signal you propose, then that train wouldn't be able to leave the rightmost "iron output" station, which would cause a deadlock regardless of a bug.

[DaveMcW]

The train in the top right is the deadlocked problem. It's waiting at a blue chain signal, which has a green signal to the right "iron output" station.

It only got to the blue chain signal because the bad signal told it the track was clear. Otherwise it would have waited before the intersection.

[fandingo]

Nope. You're focusing on the wrong things. The train in the bottom right isn't contributing to the deadlock; it's merely waiting on train that's actually deadlocked. What do you think that train on the bottom right is blocking? The train on the left is loading, so it's not even trying to move. The train at the top right is the problem. It is trying to go to "iron output." There are two stations with that name. One of them is unoccupied, and the other is occupied. Factorio used to properly resolve this situation; it doesn't now.

If I toggle the top right train to manual mode then to auto, it figures out that there is an "iron output" station available and immediately goes there. No deadlock. For whatever reason, Factorio won't do this automatically anymore.

Edit: Here's what's happening. It's trying to follow the yellow line.

[DaveMcW]

Nope. You're focusing on the wrong things. The train in the bottom right isn't contributing to the deadlock; it's merely waiting on train that's actually deadlocked.

Right. The top train is the problem. Your picture illustrates the future, but consider the past. It entered the intersection because the bad signal said it was safe. If you remove the bad signal and replay the past, it stops at the bottom right chain signal.

[NorwegianBlue]

Agree with OP

I've noticed this recently too in a similar setup.

Was working 100% since I built it. Now it gets stuck with the incoming train trying to move into a bay that's full, even though there are more empty bays with the same station name.

[fandingo]

Nope. You're focusing on the wrong things. The train in the bottom right isn't contributing to the deadlock; it's merely waiting on train that's actually deadlocked.

Right. The top train is the problem. Your picture illustrates the future, but consider the past. It entered the intersection because the bad signal said it was safe. If you remove the bad signal and replay the past, it stops at the bottom right chain signal.

That chain signal is for southbound traffic only (specifically to prevent collisions with northbound traffic when the exiting train is attempting to head south), which doesn't matter since the train is northbound. There's already a normal signal on the northbound curve (where the first cargo wagon starts), so removing the "bad" signal would push the bottom right train back a little but not fix anything. I still don't get your point. The bottom right train isn't contributing to the problem at all. I think I'm done discussing that train. The issue is that Factorio doesn't seem to dynamically recalculate path at chain signals anymore.

[DaveMcW]

That chain signal is for southbound traffic only... I still don't get your point.

More bottom. More right. On the northbound lane.

[Sephrat]

This issue isn't directly related to yours, but its explanation can apply to your case.
You must consider for now that trains won't reroute to the available station if they are waiting at a signal.
It appears trains only reroute when they pass a signal. If your train is stopped, it won't reroute and sticks with the path/station it has determined earlier (when all stations were busy it arbitrarily decided to queue up for a given station).

I believe this is kind of a known issue that should be addressed in 0.15: there are quite a few bugs in this board related to trains, and I remember reading something about it in there.
If you don't want to wait, you can use the trick Deadly-Bagel explained in the first post I linked: code your own chain signal into a regular signal so that when your train passes the chain signal, it reroutes to an available station.

[Deadly-Bagel]

Thank you Sephrat, I was just about to remind everyone of that. The original topic is here which offers a better explanation.

The problem is that trains only recalculate their paths after passing a signal. Because the train at the Chain Signal is waiting at a signal rather than passing one, it isn't recalculating its path and still wants to go to the occupied bay. Normally this only happens in waiting bays when all waiting bays are occupied, and the waiting train doesn't recognise when a bay has opened up (because it's picked an occupied bay and isn't recalculating), but I have a few ideas how this happened in your case.

The solution is to wire up a Signal to behave like a Chain Signal by connecting it to all the signals in the bays and giving it the condition ([Green] = 0). Thus the moment a bay is available it will let the train through, the moment it passes the signal it recalculates and slots into an open bay.

[ChurchOrganist]

There is another solution.

Use a distant station at the entrance to your train waiting area which every train stops at momentarily (Set the wait condition to Zero Activity 0 seconds or Time Passed 0 seconds)

This resets the train's path AI before it enters the unloading system, and it can, therefore recalculate which stops are empty.

You can see the beginnings of this sytem in the station setup I'm in the process of building here.

StationSetupSm.PNG (24.83 KiB) Viewed 9121 times

The trains all stop at the Base Distant station momentarily before entering the waiting area (only 2 bays at the moment).

This gives them the chance to choose one of the two Base Ore Unload Stations, and then select a waiting bay if both are full.

[Deadly-Bagel]

That doesn't work ChurchOrganist, it does recalculate when passing signals just as it does stations. If there are already open bays the train will take it without problem.

Oooh I understand now. Yes this is the typical occurrence of this problem. There are two relevant stations, S1 and S2, and three trains, T1, T2 and T3. What happens is T1 parks in S1 as T2 parks in S2. T3 has no available station to go to so paths to S1 and queues up at the Chain Signal. T2 now leaves S2, queueing up behind T3 and blocking T1 from leaving, but because T3 is not passing a signal it's not recalculating its path so it's still waiting for S1 to become available, ignoring S2 entirely.

I didn't realise the middle two stations weren't applicable to this situation. Having a different name, the trains don't want to go to them so only the first and fourth stations count.

By making a "faux chain signal" as I like to call them, the trains pathing is irrelevant to the state of the signal, then when the signal goes green the train passes it, recalculates and enters the newly opened bay.

[fandingo]

The problem is that trains only recalculate their paths after passing a signal.

Thanks, that's some great info! I think the solution is relatively straightforward but a little unsatisfactorily large.

The solution is to wire up a Signal to behave like a Chain Signal by connecting it to all the signals in the bays and giving it the condition ([Green] = 0). Thus the moment a bay is available it will let the train through, the moment it passes the signal it recalculates and slots into an open bay.

This was my first thought. You can't wire chain signals, but the same could be done with regular signals. However, that's not going to work in my situation. There's actually 3 different classes of train stations: 2 "iron output," 2 "iron collector," and a resupply station. With just wired signals, any of those 3 types of trains could arrive at the "wait" signal, but the circuit conditions can't know which GREENs are relevant. For my situation, you'd actually need 2 "wait" train stops -- one "collectors" and another for "output" (there's only 1 resupply train in the entire network, so it can't back up). Since circuit conditions on train stops can be evaluated for specific trains, we can always use the proper GREENs.

I'm just glad that there's some user-controllable trickery that can be used to reliably work around this situation. Time to go make some new blueprints...

[ChurchOrganist]

That doesn't work ChurchOrganist.

Can you explain to me why not?

I have been using this solution to solve similar pathing problems for years in OpenTTD - before they recently improved the signalling AI.

I currently have 4 trains using this layout and have had no deadlocks apart from one early on caused by erroneously placing a normal signal instead of a chain.

You do have to signal it properly, and you have to make sure there is enough space in your waiting area to accomodate all your trains, but in my experience it does work.

[Deadly-Bagel]

you have to make sure there is enough space in your waiting area to accomodate all your trains, but in my experience it does work.

This is why it's working for you, the OP has more trains than waiting bays (in this case loading stations as there are no waiting bays).