[Fixed] bad LTN output from inserters stuck with items

[ShinoHarvest]

if arms have full load previous train with other items type in arms have little part of this items stuck in it. Have 2 logic solution for clean this
(green circuit stak on sreen)

1 - Reduce number of arms & moved item by arms near the complet load but this make slow loading effect.
2 - Use return arms this is activated if unwanted item (not in logistic train stop output) detected in wagon
but this make problem
if unwanted item loaded, logistic train stop output change and add this item (on old game version this is not do, 0.16...)
(visible on right sreen side 10 green circuit stak added)

but not in delivery

[steinio]

Try to set locked slots per wagon signal so the delivery is reduced to let space in the wagon for clearing inserter hands.

[ShinoHarvest]

>_< not the problem is bug, and you solution reduce cargo capacity, 2 combinator in buttom left make ignore small output valus and not reduce cargo capacity but normaly this not needed. on more complex system train load by buffer storage managed by bots is big prob

[Optera]

Not a bug.
Unless it loads count perfect, a multi item provider setup requires locked slots being set so one additional inserter cycle will not overflow wagons.

[ShinoHarvest]

bug is incorrect output result to that provided by the documentation
in your documentation viewtopic.php?f=214&t=51072

In this exemple green circuit is not expected by train condition in this scheduler. (on old vertion of mod this bug not here)
need change you code or documentation with (Expected train inventory after un-/loading is complete + non expected item added in train. (only Requester & Provider)

Ps: with high arms capacity technologie and item with low stack size (exemple uranium cell ) you can lock all the slots you want problem not resolved

PPS:if the unexpected items should be added to ltn output it will seem more coherent to do negative cout

[Optera]

I'll need a full debug log or a simple save with only ltn of this happening.

[ShinoHarvest]

save demo bug (only ltn & dep mod)

bug ltn demo.zip

(3.1 MiB) Downloaded 186 times

[Optera]

Thanks, this clearly shows what I expected after thinking about it for a day.

Code: Select all

123674 (OnTrainStateChanged) Train name: Jack Edwards, train.id:6 stop: nil, state: on_the_path > arrive_station
123749 (OnTrainStateChanged) Train name: Jack Edwards, train.id:6 stop: nil, state: arrive_station > wait_station
123750 (OnTrainStateChanged) Train name: Jack Edwards, train.id:6 stop: nil, state: wait_station > arrive_station
123751 (OnTrainStateChanged) Train name: Jack Edwards, train.id:6 stop: Load-Multi, state: arrive_station > wait_station

Inserters are able to drop off their items as soon as the trains stops at the temporary stop for 1 tick before it starts for 1 more tick to arrive at the real stop on the 3rd tick.

There's no quick fix.
I'd have to rewrite on_train_changed_state to output inventory when arriving at the temp stop.
It could potentially fix outputs being 1-2 ticks slower than stops outputting train inventory, so it's something I will try when I find time for it.

In the meantime don't overload trains in multi item providers.

[ShinoHarvest]

i have seen another optimization problem a latency after train try leave station but neither step of scheduler is tagged by next objective this lasts a variable time of a few seconds but configuration of this bug is complex and i not know exact trigger

[bcwhite]

LTN v1.16.7

I'm playing Space Exploration. I have a requester station ("Typhoonator") requesting "core fragments" and a provider ("Vulcanite Core Processing") providing cryonite, stone, and core fragments. (Both stations have incorrect names due to blueprint copying.)

Provider Station

Factorio 1.1.49 2022.01.16 102526.jpg (77.44 KiB) Viewed 9312 times

LTN created a delivery between the two of 8000 core fragments. Core fragments stack 100 deep and the train called has two cargo cars with front and back engines (length=4).

LTN Messages

Factorio 1.1.49 2022.01.16 101856-001.jpg (118.21 KiB) Viewed 9312 times

When the train arrives, it has a corresponding schedule.

Train Schedule

Factorio 1.1.49 2022.01.16 090755-001.jpg (142.96 KiB) Viewed 9312 times

But the output combinator has an additional output of "7 stone".

Output Combinator

Factorio 1.1.49 2022.01.16 103017.jpg (181.51 KiB) Viewed 9312 times

That extra stone gets dutifully loaded into the train which means (a) there isn't space for all the cryonite and (b) it stays in the train because the filter insterters at the requester refuse to unload it (thankfully).

This stations have been running for a while, maybe 30 minutes. I have no idea what deliveries were made previously to this one but I came looking because I had a train go to my depot with leftover core fragments. My guess is that it was a stone delivery that had both items placed in the train but only the stone was unloaded.

Attached is the factorio-current.log (gzipped).

[ssilk]

I would check if the extra stone really, really, really comes from the output combinator.

[bcwhite]

It definitely does. I even removed (actual remove, not just disconnect) everything except the LTN stop and the output is the same.

I've kept the state in a separate save if you want me to check anything else. For now, I'm going to destroy and recreate the LTN stop and see if the problem goes away.

[bcwhite]

The trigger is a few inserters left holding stone, 7 of them to be exact. These get dropped in the train the moment it arrives and causes 7 stone to be added to the LTN "output" combinator even though they're not part of the original request. And it's definitely the output combinator I'm looking at, not the train stop itself.

If I add something to the train contents any time after, it doesn't appear on the output combinator, but if it's dropped by waiting inserters at the moment of arrival, it does.

[Optera]

Merged into existing thread.

I'm still not going to reinvent train handling just to fix output not matching schedule when inserters holding items in their hands insert items before trains properly enter a stop.
The simple solution is to use locked slot signal so inserters are not left stuck with items.
See: What is "Locked Slots per Wagon" and "Train composition"?

[bcwhite]

I don't expect you to fix train loading; that's my problem.

The question is: Why did LTN's "output combinator" change because some wayward assemblers mistakenly dropped something into an arriving train?

[slaneyrw]

Is it possible to SET the wagon filters at the point an LTN schedule is created, this will stop hanging inserters loading. The existing clear filter setting resets the train at the depot ?

[Blackclaws]

I think what is really confusing is the fact that from what was requested you should be able to populate the output correctly right? Why is it that the contents of the wagons even matter at all to what the output is displaying, shouldn't that draw its information from the scheduled request?

This makes it impossible/very hard to build setups that don't use locked slots but instead unload wrongly loaded cargo.

By the way the issue isn't really solvable purely by locked slots either. In mods such as Space Exploration + Krastorio there are items with very low stack sizes, such as 1 or 5, if you combine that with a lot of inserters inserting at once you end up with significant overhead.

[Blackclaws]

So I've looked into the code. I think the culprit is this line:

https://github.com/Yousei9/Logistic-Tra ... e.lua#L378

The problem is that the existing train inventory always gets to be a part of the signals and is only cleared when stopping at a requester station:

https://github.com/Yousei9/Logistic-Tra ... e.lua#L437

or when its already part of the request at a provider station:

https://github.com/Yousei9/Logistic-Tra ... e.lua#L440

I don't really see the background for adding the inventory?

[Optera]

I've added a map setting "Providers output existing cargo" with 1.16.8.
Should solve most issues with output showing items inserted by stuck inserters by simply ignoring train inventory when entering a provider.

[Blackclaws]

Thanks for the fix!