Factorio Forums

As the topic title says, stack inserters do not respond to their stack size changing while waiting for items. If a stack inserter is waiting for an item while already having a few in-hand, it does not respond to the stack size being changed. This will result in situations where the stack inserter is holding more items than its stack size allows, but the inserter refuses to drop them despite its destination being empty.

My expectation would be that if the stack size is set equal or less than the number of items the inserter is holding, the stack inserter should drop the items (if the destination is free, of course) and then continue operating using the new stack size. The stack size can be changed either by manually configuring the inserter or by circuit network control, the behavior is the same (as in, nothing happens either way).

I have attached a video showing the issue and hopefully explaining clearly what is happening. It seems the problem originates from the fact that the stack inserters are inactive while waiting for a change in the inventory they are picking up from (makes sense, generally speaking). Changing the inserter configuration does not wake the inserter up and it does not re-evaluate its state, so it remains stuck in a now-invalid waiting state until something else wakes it up for some other reason. This can effectively lead to deadlocks if the pickup inventory isn't modified externally, as the stack inserters themselves do not obey changes to their configuration which should result in them operating rather than waiting. Note that in the video I show this happening with circuit network stack size control, but the same thing happens if the stack size is changed manually from the inserter's UI.

I have attached my save file and the log as well.

This is still present in 2.0.18. Disabling the stack inserter, changing the stack size, and then re-enabling the inserter will cause it to re-evaluate if it's currently holding a full hand. It's also possible to convince it to re-evaluate by changing the filters.

I can confirm that this also happens if the configured stack size is equal to the number of held items, not just greater.

EDIT: Also, when an item passes on a belt below the inserter, that also causes it to evaluate its hand limit and drop the held item(s).

I was trying to solve the excessive wait times of legendary inserters on mixed (sushi) belts by limiting the hand size with combinators. So I set the hand limit to 0 (or rather 1) when the held item count does not change for two ticks. But they repeatedly get stuck with one item in hand and a hand size of 1, which is supposed to make them drop the item.

Thanks for the hint @breggen, maybe I can get it to work by setting a filter instead.

Yeah, definitely a case of the stack inserter not being prompted to wake up when its stack size control signals value changes.

Reducing the inventory count in a chest its inserting into will cause it to wake. Increasing inventory in that chest won't. Any changes to the tile/machine its pulling from's output buffer/contents also seems to trigger a wake up check.

By the way, changing the filters using signals also does not trigger the inserter to wake up. Probably not worth an own issue thread, because it seems related to this one.

Hi, I think this issue is related to another one I have already seen a couple of days ago due to belt stacking sizes.

I need to find it again but the basic gist is that a Stack Inserter will always wait for a full belt stack size to be put on belts (for example if you have researched belt stack size 4 it will wait for 4 / 8 / 12 / 16 items etc...)
This behavior is there even if the stack size gets changed during this process to prevent non-full stacks being placed on the belt.

ref 123286
ref 121423

This should be fixed for 2.0.24 due to 121360 as one of the changes i did during the inserter stack size override refactoring was to make that when live stack size changes to a value smaller or equal to amount of held items, the inserter will immediately enter drop mode.

Should this get included separately in the patch notes? I've been checking them for this fix, and almost missed it.