[boskid][2.0.21] Stack inserters ignore stack size override/filter change if the input container is not updating

[Ext3h]

Actual behavior:

If have set the stack size on a stack inserter to 1, but it still refuses to discard its hand contents which are well above the configured stack size.

stacksize_ignored.png (101.07 KiB) Viewed 599 times

The input side of the stack inserter is empty (not just no matching items available, but no items at all).

It gets stuck every time in this state when there is no input.

(This is just the minimal example. In the actual setup, the stack inserter is receiving a "stack size 0" signal every 40 ticks to emulate the non-deadlocking behavior of a non-stack inserter. Same issue applies though - the changed stack size if not evaluated at all if the input side has no items.)

Expected behavior:

Setting the stack size to 0/1 forces a flush of the hand contents even if the input container is empty.

[mrvn]

Changes in the stacksize do not wake up the inserter. But if you toggle for example the "Use filters" on and off it will wake up and honor the stack size override. Annoying.

[Ext3h]

Filter changes don't properly wake it up either, as I could determine from other bug reports.

It does not even wake up if the changed filters would render the hand-contents illegal.

Looks like you have to forcefully reboot the inserters (enable/disable or a tick) to wake them up, which is a real pain because you need to have the stack size pulled down to 1 for the duration of the wakeup....


EDIT:
Actually looks like it's all the same bug. All those mechanics work whenever there is an update in the input container. None of the "should discard" rules work if the input container isn't updating.... Looks like a failed optimization attempt on inserters in general, that should have never been applied to stack inserters because they don't have a regular timer based wakeup...

[boskid]

From what i remember, inserters are extremally performance critical since they are built in huge amounts everywhere. That means they try to keep a live copy of stack size to avoid touching force data and the value updates in some specific state transitions. Possibly this could be slightly improved but it would have to be done in a way that does not increase inserter update cost

[mrvn]

From what i remember, inserters are extremally performance critical since they are built in huge amounts everywhere. That means they try to keep a live copy of stack size to avoid touching force data and the value updates in some specific state transitions. Possibly this could be slightly improved but it would have to be done in a way that does not increase inserter update cost

There is only ever one inserter which GUI is open. Changes in the GUI should really wake up and reevaluate the inserter no matter what. One extra inserter once in a blue moon is not going to change performance.

As for circuit signals here is the behavior I see:

1) Lowering stack size per signal the inserter remains stuck with more items in hand than the stacksize.
2) Changing filter per signal the inserter remains stuck with items in hand not listed in the filter.
3) Lowering stack size and changing filter at the same time the inserter drops off the items in hand.

As far as I can figure changing the stack size does not wake up the inserter. Changing the filter wakes up the inserter but it doesn't care that it holds items in hand that are no longer filtered. It no longer picks up more of that item though. When picking up items from a belt changes in the belt do not make the stack inserter drop of items unless the item is getting picked up. So really the worst you can do is remove items from the filter. The inserter is then truely stuck.

So inserters react to GUI changes or signal changes. That part is already there. What is missing is the check whether the inserter should now swing. That check seems to be only done when the inserter picks up an item. Don't sacrifice usability for premature optimization on this.

As for the intended behavior:

1) When the inserter holds more (or equal) items than the stacksize it should swing for sure.
2) When the inserter holds items not in the filter I can see use cases for both behaviors: Swing now to clear the hand or pause inserter.

"Set filter" is often used to manage how many of each item is put into a chest or on a belt. When the right number of items are present you remove the signal and the inserter stops adding more. When the stack inserter can only pick up one item type then you want it to pause. (Note: you use set filter because using enable would hardcode the condition into every inserter. Set filter you can encode the condition in one combinator and connect to many inserters. Makes it easier to change it later.)

But when the stack inserter can pick up different item types you probably want it to swing when you clear the filter so it can pick up other items in the filter.

Maybe the inserter should swing if: The hand content is not in the filter AND there is an item it can pick up instead. But I can already see a special case needed for this: If the inserter drops off in an assembler the "can pick up" check should ignore the amount stored in the assembler. Because the assembler might have all ingredients full except the one in hand. If the hand content gets dropped off the assembler would run and free up space to inserter other items.

Anyway, if we can't have both (via some configuration option) then I think swing now is the only behavior that won't deadlock. Just adding a "should I swing" check would give that behavior.

[Ext3h]

It might be possible to resolve this (and also improve usability of stack inserters by a lot), by simply giving stack inserters a switch that re-enables the "idle timeout" that they have lost compared to other inserters. Doesn't need to be as short as on a regular inserters, potentially doesn't even need to be configurable by signal.

All those issues originate from the lack of such timeout that renders them prone to deadlocking in the first place (if used outside their narrow intended use cases), and it's only when you start controlling them by circuit as a workaround to re-implement that timeout that you end up clashing with the optimizations.

E.g. when using a stack inserter on a machine that is switching recipes (or has some rare by-chance-only alternative outputs due to quality / chance based recipes), simply flicking the timeout back on would already render the stack inserter viable again out of the box.

[boskid]

This should be now fixed for 2.0.24 due to changes i did because of 121360.