Set priority for FILTER variant inserters to remove from partial stacks before full stacks.

[gghf]

Edit: After some discussion of this on discord, I was told that the behavior described below would likely have terrible consequences for performance once the thousands of inserters in a big save got working. I was wondering if it maybe could still be implemented if it was reserved for filter (stack) inserters only? There aren't nearly as many of those around and really those are the only inserters where it matters what stack they remove an item from.

TL;DR

Inserters currently add first to partial stack, and second to the left-most free slots. But they always remove from the right-most slot, which is an inconsistency.

What?

I would like to suggest, that much as inserters first add to partial stacks before considering which new slot to put an item in, they should also first remove from partial stacks, before considering which full-stack to remove items from.

Why?

I have built a pretty good and stable smart loading and unloading system. It uses circuitry to solve all kinds of issues related to stack size control and filter setting, as well as keeping track of what's in the wagon and what has been removed.
The last issue I face is the following:

As the loading inserters move the bot-delivered surplus into the wagon, the unloading inserters begin their work of balancing the load. This can cause previously filled slots to be freed again. As soon as one of the other items also has its surplus loaded, that surplus will end up in the newly free slot to the left of that item's old full-stack. The unloading inserters next remove that surplus from the full stack, leaving you with two partial stacks that would otherwise make up a whole. It happens only if you fill a wagon with different items.


I cannot think of a way to fix this issue with circuits without reintroducing other issues that are even more disruptive or limit flexibility by an unacceptable degree. If on the other hand inserter behavior was consistent between load and unload, this issue would be gone instantly. I'm in the process of creating a station that can handle the behavior above, and the number of hoops to jump through is quite frankly ridiculous. You end up chasing issues in circles because of the unfortunate implications the current behavior displays when combined with some of their other limitations (such as the inability to set EACH as the stack size control signal).

[gghf]

I just came back to this topic after a long time away, and thought of a way that this could be implemented with a much smaller drain on resources.

What if this check for partial stacks only happened when the filter inserter can no longer release its load? If the target inventory has a set of partial stacks that would fit in one whole stack, then merge these so that a slot becomes free again.

I imagine this kind of edge case shouldn't be unbalanced.

[ssilk]

Sorry, but I think it makes a lot of sense to behave it like so.

Think of chests which is half full.

Now you set a chest-limit (the Red cross) to one quarter of chest capacity. One quarter is now full (chest cannot be filled anymore), and another quarter is inside of the limit and can never be filled up anymore. The other half is empty, but cannot be refilled automatically.

But the “overflow” (in the crossed part) is taken out first. Which is exactly what I want, when I set the limit. I want to take out that items first. Otherwise they where like “lost”.

So removing items from right to left is the best behavior.

For filling I could think about filling as you described. But i also think what you described is a very hard edge case...

[gghf]

But the “overflow” (in the crossed part) is taken out first. Which is exactly what I want, when I set the limit. I want to take out that items first. Otherwise they where like “lost”.

So removing items from right to left is the best behavior.

For filling I could think about filling as you described. But i also think what you described is a very hard edge case...

Isn't that... an even harder edge case? I have literally never had a situation in which I needed inserters to prefer unloading stuff in the red before the unlocked stuff, whereas I have run into situations as I described all the time when trying to balance loads of trains.

[ssilk]

Well, I need the chest limit especially in the beginning. For example ammo: assemblies put ammo into a chest. At first I will leave a limit of 4 stacks and later I reduce it to 2 stacks for example. What to do with the filled 2 stacks? They should be used!

I have run into situations as I described all the time when trying to balance loads of trains.

Well, when I reread all, I think I don’t understand your use case. If I ever want to fill wagons with special amounts of items, I use the stack filters of the wagon.
https://wiki.factorio.com/Cargo_wagon

[SoShootMe]

Why?

I have built a pretty good and stable smart loading and unloading system. It uses circuitry to solve all kinds of issues related to stack size control and filter setting, as well as keeping track of what's in the wagon and what has been removed.
The last issue I face is the following:

As the loading inserters move the bot-delivered surplus into the wagon, the unloading inserters begin their work of balancing the load. This can cause previously filled slots to be freed again. As soon as one of the other items also has its surplus loaded, that surplus will end up in the newly free slot to the left of that item's old full-stack. The unloading inserters next remove that surplus from the full stack, leaving you with two partial stacks that would otherwise make up a whole. It happens only if you fill a wagon with different items.

I tried to build what sounds like a similar smart loading system, which I think would have the same issue.

I am not certain, but I think the problem you describe with the current behaviour can be reliably avoided provided that, for each item, the desired number is either less than its stack size or a multiple of its stack size.

Well, when I reread all, I think I don’t understand your use case. If I ever want to fill wagons with special amounts of items, I use the stack filters of the wagon.
https://wiki.factorio.com/Cargo_wagon

You can't dynamically set wagon stack filters, so they can't be used when what you want to load is dynamic.

[gghf]

Well, I need the chest limit especially in the beginning. For example ammo: assemblies put ammo into a chest. At first I will leave a limit of 4 stacks and later I reduce it to 2 stacks for example. What to do with the filled 2 stacks? They should be used!

I have run into situations as I described all the time when trying to balance loads of trains.

Well, when I reread all, I think I don’t understand your use case. If I ever want to fill wagons with special amounts of items, I use the stack filters of the wagon.
https://wiki.factorio.com/Cargo_wagon

Nothing about what I suggested prevents the stacks in the red from being used.^^ It just means that unless they are partial stacks as well, they may not get used up first.

I built a very advanced depot station which is remotely controlled by myself and any outpost that needs supplies. The number of items for each is also exactly controllable. So it is possible to load a train exactly to capacity in literally any combination of items, remotely, without having to manually interact with the train ever. No filter setting, etc.. It does it all automatically based on your order.
The problem is, that bots don't deliver exactly and that you can't physically connect neighboring chests into a single full set, as you might in Minecraft.
So if you make a system as flexible as the one I described, you end up exposing a ton of very unfortunately connected limitations of vanilla. It's a literal chase around the circle. If you fix one of these, you have to reintroduce another one. This circle could be broken anywhere, and the suggestion I make is one that does not make combinator contraptions too simple, so those that really enjoy getting into the nitty-gritty of building smart systems aren't basically punished for doing so by having their efforts voided. A change that I would not like, but a lot of people want, would be to allow filter inserters to use EACH as a stack size control signal. This in my opinion would be too easy a solution and the game would lose one aspect of its depth.

[gghf]

I am not certain, but I think the problem you describe with the current behavior can be reliably avoided provided that, for each item, the desired number is either less than its stack size or a multiple of its stack size.

That is a problem because this means that the number of errors a user of my blueprint can make increases.