Factorio Forums

The picture should hopefully explain it.
Can anyone shed some light on the train-brain logic of why it is doing what it is doing so I can design a workaround?

Train was on its way, then the station becomes inaccessible (track destroyed).
Note: There are still accessible stops, but they are all closed. There is one open inaccessible stop after the broken track segment.
But it does not move on to the next scheduled stop. Instead train sits and blocks the railway line for everybody else.
(No Path) floating text over the train, though the screenshot caught it between popups.

SuicideJunkie wrote: Mon Jan 03, 2022 5:47 am [...] why it is doing what it is doing so I can design a workaround?

Train was on its way, then the station becomes inaccessible (track destroyed).
[...]
Instead train sits and blocks the railway line for everybody else.

mmm, yes.

problem: train gets stuck

reason: track is destroyed

solution: don't destroy track

you either need to disable the inaccessible station or set the train limit to 0. Otherwise it will interpret it as a stop it needs to get to. Also from its currently location does it have a path to get back to the next station in its schedule? If not it will stop moving.

SuicideJunkie wrote: Mon Jan 03, 2022 5:47 am Can anyone shed some light on the train-brain logic of why it is doing what it is doing so I can design a workaround?

I'm not sure it's the only reason/best way to explain, but there's this thing i remember from the discussion that happened before train limits were added to the game :

If a train stop is deactivated by circuit network, the train "skip" the stop. This is assumed to be intentionnal otherwise it means you mess up the wiring.
If a train stop is set with a limit of 0 instead, the train will not "skip" the stop it will say in place with "destination full" message. This is assumed to be intentionnal too.

Now when a rail is destroyed and a train stop that was the target of a moving train becomes inaccessible it doesn't "skip" the stop and instead freezes with the "no-path" message. (supposedly here it is no longer intentionnal).

It ressemble the behavior of a train not moving when the limit of the next stop prevents it. This was made (somewhat) to have a state where all your trains are static because all the limits are set to 0. It's quite a sidestep to explain but if it wasn't the case there would be more problematic situations occuring in regular routine.

Say you have a train that picks up iron ore, then unload it, then picks up copper ore, then unload it. If you were to disable one of the unload, the train would "skip" it and then a train full or iron ore would arrive in a copper loading station, or even worse, you could have a train full iron ore unloaded in the copper unload station, if 2 station were "skipped".

The behavior of "no skip" for limit interaction was designed this way from what i remember because it was intended for a situation where you could frequently change the limit to prevent train from moving all at once at the same area. Making train freeze on spot was thought "dangerous" so instead when you set the limit to 0 while trains are already routing to that stop, those trains continue their travel to the stop that just got "soft-disabled". OR don't even start to move and instead display the message "destination full" (that was introduced).

The "no-skip" behavior here is on purpose, for the reason of avoiding risk of mixing material. In a situation where you intentionnaly select the train stop concerned.

When you do not intentionnaly select the train stop concerned then the game freeze the train on spot.

=> If you disabled a train stop with circuit, train skips them, since it's considered intentionnal. (no freeze)
=> if you set limit to 0, train finish their path, it's intentionnal (no freeze)
=> If instead the train stop is made not accessible because biters eat a rail, train do not skip it, it freeze on spot which prevent material contamination. Not intentionnal (freeze).


Supposedly only looking at trains, it doesn't matter because when the rail is replaced by robots, the train that was stuck like in your example should resume its previous travel. ( in practice it's different since it can create a traffic jam or you may not have robots coverage ).

Risks are if you have another station named the same, the train could go there instead of its original destination made unavailable due to rail removal. This is only a problem in (rare) certain conditions, if your station are named the same AND do not handle the same material for example.

There are no way around the fact that a train WILL get stuck if the destination is unavailable in some train network. Like when it's not grid like and there is only 1 way to reach an outpost and leave this outpost that has a unique name.

To have a fool-proof solution to your problem seem impossible with single-way-tracks since biters could always eat the rail just in front of a train. ( amongst any rail that is part of the unique path that reach to a train stop). Even though it seem like the train could have a smarter behavior when it happens sometimes ( for other rails located further in the path). Those would break in that extreme case.

mmmPI wrote: Mon Jan 03, 2022 8:49 am Now when a rail is destroyed and a train stop that was the target of a moving train becomes inaccessible it doesn't "skip" the stop and instead freezes with the "no-path" message. (supposedly here it is no longer intentionnal).

First: The trains behave the same if the train stop was never reachable -- that means destroying / adding tracks adds nothing of value to the discussion.

Second: Using such an isolated train-stop (just one track and one train stop) to prevent trains from skipping to the next entry in their schedule if all other stops with the same name are closed is - IMHO - the traditional way to solve the do-not-skip problem for schedules with more than two entries. Example: Mining output -> Waiting position (full) -> Consumer -> Waiting Position (empty).

So I consider that behaviour very well intentional because otherwise it would break existing saves/blueprints.

asheiduk wrote: Mon Jan 03, 2022 11:16 am First: The trains behave the same if the train stop was never reachable -- that means destroying / adding tracks adds nothing of value to the discussion.

I disagree, the title of the thread is "when a train stop become inaccessible" it is specific to destroying or adding a rail. Since otherwise the train doesn't even depart from a train stop and doesn't get stuck in the way.

the condition where train goes from A to B and cannot go to C from B but it could have from A is not the issue => only the situation where a rail is removed such as by accident or biters makes a train stop "inaccessible while a train is moving toward it" which then cause that train to get stuck/freeze in a location that you do not control.

[ or disabling all train stop with circuit while a train is moving will cause it to get stuck, this case i refer with messing up your circuit logic it's different than OP screenshot where the station is red on the schedule ]

asheiduk wrote: Mon Jan 03, 2022 11:16 am Second: Using such an isolated train-stop (just one track and one train stop) to prevent trains from skipping to the next entry in their schedule if all other stops with the same name are closed is - IMHO - the traditional way to solve the do-not-skip problem for schedules with more than two entries. Example: Mining output -> Waiting position (full) -> Consumer -> Waiting Position (empty).

So I consider that behaviour very well intentional because otherwise it would break existing saves/blueprints.

Yes this was a popular work-around used before the limit were added to the game.

The limit do not exactly replace the system and make it obsolete, rather it adds another way to deal with the matter. Instead of having that isolated station to prevent train from skipping a station, you can modify the network so that trains don't skip a station because the limit has been set to 0, they could now wait with "destination full" instead of "no path" toward that isolated station.

However the behavior OP requires would be the opposite ! a way to force a train to skip a station that has became inaccessible automatically, or at least make it so that when it happens the train doesn't stuck on random location that could be the main rail lane.

Even setting the limit to 0 here wouldn't work in the case presented in OP since the train would still get stuck with "no-path" instead of finishing the travel since the destination is inacessible.

One would require to disable with circuit the inacessible station. And even in this case it's possible that the train will not be able to reach the next station on the schedule from the location where it was when doing the repath. ( network shapes and single way rail makes it difficult close to impossible to make sure you can remove any rail and not get a situation where a train is on a dead end.

Good to know that fiddling with train limits won't help and why.

I may be able to swing a track isolation detection circuit and close the stop to prevent lockups on the main network. Can't do anything if the train has committed to the final offramp, but that is to be expected.

SuicideJunkie wrote: Mon Jan 03, 2022 4:51 pm Good to know that fiddling with train limits won't help and why.

I may be able to swing a track isolation detection circuit and close the stop to prevent lockups on the main network. Can't do anything if the train has committed to the final offramp, but that is to be expected.

noooope. you won't be able to close a station that has No Path. it'll just sit there complaining that all 7 stops or however many aren't reachable.

what im curious about is why only you seem to be having a problem with this

one more thing, if you delete all the stops with that name, it won't stop anymore. it'll skip it forever, because "No station with that name exists".

ptx0 wrote: Mon Jan 03, 2022 5:11 pm

SuicideJunkie wrote: Mon Jan 03, 2022 4:51 pm Good to know that fiddling with train limits won't help and why.

I may be able to swing a track isolation detection circuit and close the stop to prevent lockups on the main network. Can't do anything if the train has committed to the final offramp, but that is to be expected.

noooope. you won't be able to close a station that has No Path. it'll just sit there complaining that all 7 stops or however many aren't reachable.

what im curious about is why only you seem to be having a problem with this

Indeed, you would need to close all stops with the same name that are inaccessible at the same time. A train wouldn't get stuck if there was a train stop named the same as the one that is isolated, it would just switch destination to find a reachable station. It only skip one train station on the schedule when ALL train stop that have this name are disabled at the same time.

It may be possible to make something to tell you the player when such things happens but i'm not sure. At the same time as the limit was introduced was also the possibility to read the number of incoming train. Now depending on how you did your trains, it may be possible to detect when the number of incoming train decreased as read on the train stop, but no train arrived as detected with train signals. Maybe this is enough to tell when a train went from trying to reach a train stop to => "no path" due to a rail missing. Maybe too many false positive.

If there's an open stop elsewhere, the train would simply path to it and carry on.
So closing the isolated stop should kick the train back to the load stop. Even just blinking it closed for one tick would be sufficient I'd expect.
The real trick will be not closing it if there is a train actually on the way.

SuicideJunkie wrote: Mon Jan 03, 2022 9:47 pm If there's an open stop elsewhere, the train would simply path to it and carry on.
So closing the isolated stop should kick the train back to the load stop. Even just blinking it closed for one tick would be sufficient I'd expect.

yes and no, what you describe is the ideal case. Maybe the train has done 75% of the way toward a train stop that become inacessible due to a biter eating a rail. At this point there may be other open stop elsewhere, say 5, and it could happen that all of them are now inacessible for that particular train due the the rail that was eaten and the location where the train was when it happened.

worst example of network layout to illustrate :


here the train would "no path" unless you close all "a", and then it would also "no path" since it cannot complete the loop and go back to "b".

It's difficult to describe what to do to avoid that with word, in some case it's a problem, in some other cases it's not depending on the shape of the rail/junctions and so on.

SuicideJunkie wrote: Mon Jan 03, 2022 9:47 pm The real trick will be not closing it if there is a train actually on the way.

I think this you can read from a train stop connected with wire, ticking the box "read incoming train". But i'm not exactly sure how it behaves with rail removal.

Though if you try closing all station that do not have an incoming train. Those train that happen to have gotten stuck once with "no path" in the middle of the road may never be able to re-acquire a target.

It would seem easier to try and avoid the situation happening rather than trying to automate a resolution when it happens

if they're stuck in no path it's because your rail system is broken

ptx0 wrote: Tue Jan 04, 2022 1:59 am if they're stuck in no path it's because your rail system is broken

Yes i think that's the whole point , when biters eat one of your rail the system is broken, Can you make it so the consequences are predictible/negligible/self-correcting ?

I don't think it's worth it to try as a general case, most people don't either from my experience, it's easier to fix the rail system than to have it built with a embedded safety against missing rail. (or automate the fixing of the network).

but that's still a fun challenge/puzzle to consider (imo) what it would take or if it is possible at all to design a system that minize as much as reasonnable the consequences or biters eating a rail in your system.

I think for this goal the rail network layout is a more effective tool than the train schedule but that's from a blank sheet point of view, not having a game already advanced and thinking how to add that safety system to it. It could be tempting to add a mechanism to disable train stop that have no incoming trains in an attempt to force trains to skip the innacessible outpost instead of freezing in a random location "in case a biter eat a rail" .

But in this case i think what can happen if one such train goes into "no-path" state and the now-inaccessible destination disable itself just a sec to force that train to skip, is that this train may not be able to aquire a new destination. You could or not consider that one end of the schedule is always accepting train, and the other has a risk of being disconnected by ennemy. In this case the self-disabling stop could be implemented in risky-outposts, as long as trains ALWAYS have the possibility to make a U-turn. This way you mitigate consequences of biters eating a rail. If you think about a decentralised network in which both-end are at risk, you may face trouble implementing the system at both end of the schedule. Running into the case where those occasionnal "no-path" trains occuring because of rail destruction could end up unable to aquire a destination either due to the very absence of rail leading to them, OR because all other destination would be in a state of limit =0 or disabled since no incoming trains.

but there's nothing you can do in single way track if biters eat a rail in front of your train, or if ennemy player destroy a few rail to sabotage your thing

mmmPI wrote: Tue Jan 04, 2022 8:38 am

ptx0 wrote: Tue Jan 04, 2022 1:59 am if they're stuck in no path it's because your rail system is broken

Yes i think that's the whole point , when biters eat one of your rail the system is broken, Can you make it so the consequences are predictible/negligible/self-correcting ?

yes, have multiple paths to the destination.

if biters eat a rail, they don't usually stop there. you've got larger problems than trains not making it to their destination.

Yeah, as a reminder, in vanilla this can only happen by spitters firing at something else and hitting the rails (not sure if splash only or direct damage too ?). And from players of course. (And spidertrons too now ?)

I guess it happens on "busy spitter/train crossroads", where trains regularly squish biters/spitters ? (Spitters won't just fire on an unoccupied train not squishing anyone.)

Or maybe on a "busy spitter => bot / rails crossroad" ?