[2.0.15] Stack inserters do not prioritize full stacks from a chest first and get stuck

[Discobotly]

While running my recyclers into a chest and trying to use a stack inserter for more throughput, i found it frustrating that the stack inserter prioritizes the last item added to the chest and would get "stuck" waiting for more of that item to arrive, rather than emptying the many full stacks of items in the chest.

11-11-2024, 21-04-31.png (1.51 MiB) Viewed 754 times

Each of these chests is nearly full.

I fixed this with wiring, but i feel this behavior would make more sense by default or as a checkbox option on the inserter "Only take full stacks" ect.

11-11-2024, 21-09-46.png (121.06 KiB) Viewed 754 times

My solution which was to check Each > 16 = Output as Filter

[Rseding91]

This is not a bug. The stack inserter waits for full stacks of things.

[Discobotly]

This is not a bug. The stack inserter waits for full stacks of things.

I understand it's an intentional feature that a stack inserter waits for a full stack of the item it's holding before placing. However this thread is about a behavioral issue when the inserter is empty and looking to select the next item from a chest or machine.

For all other inserter types, the order in which they select items from a chest is either a non issue, or they have some internal logic that prevents the factory from jamming. In the case of the stack inserter, the automatic selection order from a chest or machine will frequently prioritize non-full stacks of items when full stacks exist.

I believe this behavior needs developer consideration.

[Rseding91]

I believe this behavior needs developer consideration.

I understand you dislike the current behavior however when the stack inserter concept was designed this was the behavior that was decided on. It was considered, and decided that it will always wait for full stacks of items. It's a specific design challenge to using the inserter over other ones in that you *must* handle that it will wait for a full stack if you decide to use it. If you don't want to deal with that challenge, you can simply not use the stack inserter. Alternatively, you can set a filter on the inserter so it will always and only grab the item(s) you decide.

[robot256]

I believe this behavior needs developer consideration.

I understand you dislike the current behavior however when the stack inserter concept was designed this was the behavior that was decided on. It was considered, and decided that it will always wait for full stacks of items. It's a specific design challenge to using the inserter over other ones in that you *must* handle that it will wait for a full stack if you decide to use it. If you don't want to deal with that challenge, you can simply not use the stack inserter. Alternatively, you can set a filter on the inserter so it will always and only grab the item(s) you decide.

With that in mind, I believe these two topics are important to address:

recommend having the empty upgrade planner not upgrade from Bulk to Stack Inserters -- since as you say, they solve fundamentally different problems. They could still be in the same fast-replace group but not specified as a next_upgrade.

Stack inserters do not respond to stack size change (while asleep waiting for items) -- which could lead to some interesting circuits for adjusting stack size based on available items.

[Discobotly]

when the stack inserter concept was designed this was the behavior that was decided on. It was considered, and decided that it will always wait for full stacks of items. It's a specific design challenge to using the inserter over other ones in that you *must* handle that it will wait for a full stack if you decide to use it.

I appreciate the response but i feel misunderstood because you're addressing the "Wait for full stack" mechanism as being intended, which i never questioned. Here's a visual example of where i find fault with the system in the hope it'll make this clear.

Take the following chest when emptied by a stack inserter.

11-13-2024, 01-57-40.png (52.15 KiB) Viewed 598 times

It places 16 green circuits onto the belt

11-13-2024, 02-00-21.png (19.95 KiB) Viewed 598 times

It picks up the rest of the circuits, holding 9 in its hand

11-13-2024, 02-00-53.png (20.99 KiB) Viewed 598 times

And it leaves the following stacks of items in the chest. Waiting for more green circuits to arrive

11-13-2024, 02-02-09.png (41.18 KiB) Viewed 598 times

To me this isn't a logical default behavior. The stack inserter has plenty of resources in that chest it can move successfully in stacks of 16x, but it opts instead for the last slot, the stack of 9 circuits that will leave it waiting for more to arrive.

The inserter should iterate over the contents of the chest, empty each resource that can be successfully moved in a 16x stack, and then pick up that stack of 9 green circuits and wait.

[Rseding91]

Everything you just showed is fully working as designed and intended to work. You can suggest other behavior but that's almost guaranteed to not happen.

It's like suggesting that the recipe cost for mech armor be changed to 1 iron plate. The answer is simply going to be "no" - it is what it is because we wanted it to work that way and programmed it to work that way.

What you want is the bulk inserter that does not work this way.

[rapos13]

I also wanted a stacked recycler output and run into the same problem OP had.
After a few hour of cicuit development i created the setup in the attacked blueprint.
Please see the blueprint and circuit element descriptions for details.

It is a stackable design:

0eNrVVsGO2zYQ/RWCpwSljZUteW1fgxyDFNjeNguDosYWEYlUSGo37sIf0A/pj/VLOkPJlr2Vm2xyyskyNXzzOPP4Rs88r1ponDaBr595AV453QRtDV/zj21o2uCZD1J99sxumQO1V5U2O9Y4W7Qq+Cn7ZD5YH+htKIEFXQPTgT3pqmI2ArCUlXpX9jCC5bjkbQ0U6k+xyoEMwBIxY9ax+YstoGTrEb3Unj3JPe1S0iALeAQTYmZVAtLYOlszVdndjli2DYKHEsOh9uzNl1ZWOuzPjtGB0FGA1dZBjGRh3yCzUOLLATlyYcq2Jgj2VGr8g2TS5dtP5vcKJLLDExRxw1kZ/bEwSqsWWUMFNTL2Uy64Vvier++fudc7IyvqgJE1YOk7huD4AcNMAV/5OjmIkcDIaqKNBxcuwmeHB8Exkw4auiTxz35j2jrHyHUijhihdbmdBCeNb6wLkxyqgPQa63WnhGeOgJNkMZ9mgu/5OstW0wxTFRp5diFLYvciw+xnMiy/J8P8lCFvq7MyjEHPrpNPZiPYqfhPM8Zgb46gl5DpCGImhq4BVJOoqzHQ7PaiDCNQC3FFAGNoi+tFTbBHqMLgbLXJoZSP2jraqLQjuW7AyLyCgq+Da0GclnFLcUqy1c6HzaBMuj1I7FG7gPeND0xjBJ1afSahkvqDJONJl/SvbqSTgfLzf/76O0b06TyEzVZXeD7/kgm9iiVAAn9C9xZ3ollc7hip4e2JmXRoEmRIaoI0cm0ijdHGXJNQOl7HAXmomf+BooFUJVXEA8FshtKh/GwDWLfOsn/DnZ3rvrohKDPeVHIPbnM5Bt6R5TGJHk0+1lmpPndGaYre6n1c7XDZFn087ui1yYKNFkkj433U1eVrayo09n6M2IAI0Yyj45LV7vCUFOYYkJETXLqcsjfp8jQfdAyMHDq3lo1U5PhHEya+b/mIGJav9qose50brn4mw3e5YXIztBbnjEIRf0vP6XCGw7iCz9XVoXLRP2xq+fV4H+PUOdflNTXdxa0nKXUDe9BSHNf0l+Y/LcT2T9kfNPnjBvzFVhdM+kv5dNd9OtbcJPmBqz7/Zml+hct99z8X+w7Cixr2X3pkpXS9zvtwfhfPLj/WG78znlCY9JFxn4mZuBWzB3G/EIlAQc7jIy2m/RM2gx5v6fEmhlIYLScPCEV5aJ6fPksFryTeEOJL7LDzx3ncmw5GPKLPxzNli9kqXa2yNL1J59nicPgXU7a5Ow==

Copy blueprint

[Loewchen]

118839