Factorio Forums

I've been having a pretty difficult to narrow down issue lately where trains are being dispatched to provider stations without GPS coordinates, causing a lot of issues, as they're going to the wrong providers. I've narrowed down one instance of a specific issue, though I suspect there is more, and this is currently happening every time.

Context:
Heavy-oil provider main: network 255
Heavy-oil provider secondary: network 8192
Heavy-oil requester secondary: network 8192

Order of events:
Heavy-oil requester on 8192 requests 50,000 units
Heavy-oil provider on 8192 is marked as yellow, has >50,000 units available
Train is dispatched from depot to heavy-oil provider without GPS
Docks at nearest heavy-oil provider on 255 that is currently empty
Heads to heavy-oil requester after timeout, begins infinite looping as provider on 255 is empty.

I've then also had the reverse issue:
Train is dispatched from depot to supercooled-fluid provider
Is dispatched with a GPS of the correct provider station
Is dispatched without a GPS to nearest same-named requester which is full, times out, and returns to depot with fluid in tank

I've gone and destroyed my rail depots, rail providers, and rail requesters and re-placed them incase it was an issue with the circuits when they were created from copy+paste. I'm at a loss and really unsure what to look at next for troubleshooting. I can view the green cable connected to the LTN stop and they're reporting correct numbers in terms of what they're providing/currently have. I've attached a log that contains the heavy-oil fault above, the train in this instance was Jonathan Stewart. What would be my next steps to diagnose this issue? What part of the LTN framework controls the GPS dispatch so I can possibly investigate further why a requester, provider, or depot isn't assigning it?



Log:
https://www.mediafire.com/file/krjtvshm ... t.zip/file

Only way for LTN to generate schedules without temp stops is when a stop has no rail connected. In which case pathfinding would also not find the stop and the train goes into "no path".

More likely you have a mod messing with temp stops removing LTNs temp stops.

I'm scratching my head thinking what mod could be causing that issue. At this stage I'm only using Space Exploration (and pre-req/optional mods), LTN, and Miniloaders. I'm only having this issue specifically in Nauvis Orbit and not on Nauvis actual from what I've noticed. Could this possibly be a Space Exploration-specific bug related to different surfaces? I'm using the same heavy-oil provider/requester name between the planet and orbit.

This might address the issue I'm having with oil, but I'm still unsure why thermofluid has a similar issue while being Orbit-specific...

Note that plenty of other stops function without issue, so it's not as if all temp stops are broken currently, only edge cases. Is it normal behaviour for them to be deleted after docking at say, a provider station? Is there a throttle with how many coordinates can be created in a single tick and I need to change some dispatch settings?

As an update, thank you for letting me know that the GPS temp stop fails if there's no path. I believe the behaviour in this case was that one specific heavy-oil provider station was unpathable, so it would drop this temporary coordinate, and then route to the nearest same-name provider. I broke out my network into individual names to troubleshoot, and identified my heavy-oil problem as such:

There was a missing rail piece underneath 1 of 7 heavy-oil provider train station stops on the network 8192, meaning that there was a broken tile giving a "no-path", so the dispatch trains couldn't path to the correct provider outputting a "provider available" signal. They would then loop to the nearest same-named station which had a valid stop, which were in this case empty.

I'm going to work in reverse to identify why this is happening with thermofluid. Thank you for the input and setting me on the right path!

Two things to think about:

1) Why doesn't LTN detect that adding the GPS temporary stop fails? Shouldn't that output a message and flag the station a broken / red light? Sending a train there should fail and pick another station.

2) The temporary stops disappear when the train is within breaking distance of the stop while the real stops do not. So

2a) trains without GPS temporary stops in the schedule should be quite common provided the train is past the temporary stop.

2b) With trains going fast the breaking distance can be quite a distance. I wonder what the chance is of the train already being in breaking distance of the GPS coordinates, so the temp stop disappears, and rerouting to another stop. I think that can only happen when you add or remove a rail along the path the train has to take to the stop. So quite unlikely I imagine but not impossible.

mrvn wrote: Tue Sep 07, 2021 5:19 pm 1) Why doesn't LTN detect that adding the GPS temporary stop fails? Shouldn't that output a message and flag the station a broken / red light? Sending a train there should fail and pick another station.

In essence, I think an A-or-B outcome of this is already the case, as discussed above. A), the train sits motionless with the vanilla "no path" error state; or B) the train rolls, without LTN's temp_stop, to some other identical-named location elsewhere within the same rail network. (Incidentally, I personally choose to avoid any instances of identically-named LTN_trainstops anywhere -- yes, that means I have a lot of trainstop names -- which means that the B-outcome happens to be impossible for me.)

2) The temporary stops disappear when the train is within breaking distance of the stop while the real stops do not. So

As far as I can tell, any temp-stop (whether created by LTN or vanilla) only deletes upon whatever event fires upon train departure from that temp-stop, i.e. whenever the departure condition is satisfied. I just checked, and LTN's temp-stops specify a null-condition of [0seconds-total-elapsed], which while not technically the same thing as having no condition set at all, does function with the same effect as if there were no condition set. Note that for any trainstop location, temp-stop or otherwise, whether LTN or vanilla, if there is no departure condition specified, then train's pathfinder treats it as a via-point or a waypoint for itinerary and routing purposes -- which is exactly the intended behavior for LTN. This means that the departure-event fires for such a waypoint at the time that the braking-point extends for the first rail-tile past the stop location.

...Now that I think about it, I'm willing to bet that that's basically "whenever the train pathfinder extends past the stop location" but with way more words.

2a) trains without GPS temporary stops in the schedule should be quite common provided the train is past the temporary stop.

Can heartily confirm.

2b) With trains going fast the breaking [EDIT: "braking" -- sorry] distance can be quite a distance. I wonder what the chance is of the train already being in breaking distance of the GPS coordinates, so the temp stop disappears, and rerouting to another stop. I think that can only happen when you add or remove a rail along the path the train has to take to the stop. So quite unlikely I imagine but not impossible.

You're prolly correct on this. I confirm at least most of it with what I typed above.