Filters overrides stack size
Moderator: ickputzdirwech
Filters overrides stack size
Applying filters on inserter also overrides stack size based on the incoming numbers in logistic network
Re: Filters overrides stack size
Can already be done by utilizing Decider+Arithmetic combinators if you want first signal, or Selector+Arithmetic if you want signal with highest value.
.
.
Re: Filters overrides stack size
Can not see your blueprint, `Error while importing string, unknown item name carbon`. Actually, I know how to do it via combinators but do not really like this approach. But it will be good to see your fixed creation. Thank you.
Re: Filters overrides stack size
Actually no, I do not know how to do it, so please fix your blueprint
Re: Filters overrides stack size
Here is a non-SA blueprint:
Re: Filters overrides stack size
Thank you. Actually, it is not what I really need, at least I can not adopt your blueprint to my suggestion. So, I still suggesting `Filters overrides stack size` to the game.
for better understanding, example, I need to strictly only 14 copper plates and 22 iron plates in chest. Train contains 100 belts, 200 iron plates and only 11 copper plates. We also have stack inserter attached to train and chest that already contains 3 iron plates. After unloaded 11 copper plates (existing in train) and 19 iron plates (+3 in chest=22), stack inserter should still have filter for 3 copper plates. Go
Starting blueprint:
for better understanding, example, I need to strictly only 14 copper plates and 22 iron plates in chest. Train contains 100 belts, 200 iron plates and only 11 copper plates. We also have stack inserter attached to train and chest that already contains 3 iron plates. After unloaded 11 copper plates (existing in train) and 19 iron plates (+3 in chest=22), stack inserter should still have filter for 3 copper plates. Go

Starting blueprint:
Re: Filters overrides stack size
The issue with trying to combine stack size with filters in your example is that there are multiple filters but only one stacksize.
Going with stack size of 1 is always a safe bet when trying to hit an exact target.
This contraption can handle up to five different supplied items.
It selects the minimum of items as stack size, so when transferring e.g. 100 iron + 1 copper stack size 1 will be selected and if iron is being transferred first, it may take a while.
If you want to transfer more than 5 types of items, as your image implies, a more complicated version will be needed.
See for example SR-Latch + Dynamic Filter for a contraption that seems to handle more item types and batching, but does not set stack sizes, so ideas merging will be nededed.
With train contents reading incorporated, an alternative is to calculate demand-supply, from this select highest signal with Selector, and apply the result as an only filter and stack size.
Going with stack size of 1 is always a safe bet when trying to hit an exact target.
This contraption can handle up to five different supplied items.
It selects the minimum of items as stack size, so when transferring e.g. 100 iron + 1 copper stack size 1 will be selected and if iron is being transferred first, it may take a while.
If you want to transfer more than 5 types of items, as your image implies, a more complicated version will be needed.
See for example SR-Latch + Dynamic Filter for a contraption that seems to handle more item types and batching, but does not set stack sizes, so ideas merging will be nededed.
With train contents reading incorporated, an alternative is to calculate demand-supply, from this select highest signal with Selector, and apply the result as an only filter and stack size.
Re: Filters overrides stack size
The key to exact unloading is the ANY wildcard. As output from a decider combinator, you pick one signal from all the signals that represent what you want to unload. The condition in that decider should have an EACH operator with a condition to select the things to unload, and as output use ANY.
With another decider operator, you cast the signal to the <S> signal to use it as stack size. Then feed both to the inserter and set it to filter from circuit and set stack size from <S>.
To prepare the list of things to unload, you need to obtain a list of things you already have (for example in a chest) and a list of things you want the chest to contain (for example in a constant combinator). Read the chest, subtract it from the constant combinator value to have the things you need to unload as positive values. Feed this list to the 2 combinators I mentioned above. Total 3 combinators.
This is the first iteration of a supply train unloader. The second one deals with the issue this contraption stalls, if there are not enough items in the train. In this case, the inserter stops and waits infinitely for an item that's not there.
You need to include the actual train content into the calculation. You need to unload the difference, but not more than in available from the train. For this, you need to add a MIN(demand, train content) operation, which can be accomplished with 2 additional decider combinators. (example: see viewtopic.php?t=124776)
There's an alternative. Further down the mentioned thread, there is an example how to iterate over a list of items over and over again. With this, you can ignore the train content and just switch from item to item every tick, and if the item is available, it's picked by the inserter. However, this uses a minimum of 2 combinators, so it's no advantage over the MIN(x,y) solution above.
If you use this for train unloading with multiple wagons, you need 3 combinators per station (1 for computing the diff and 2 for computing MIN()) and 2 combinators per wagon (for selecting an item and computing stack size).
With another decider operator, you cast the signal to the <S> signal to use it as stack size. Then feed both to the inserter and set it to filter from circuit and set stack size from <S>.
To prepare the list of things to unload, you need to obtain a list of things you already have (for example in a chest) and a list of things you want the chest to contain (for example in a constant combinator). Read the chest, subtract it from the constant combinator value to have the things you need to unload as positive values. Feed this list to the 2 combinators I mentioned above. Total 3 combinators.
This is the first iteration of a supply train unloader. The second one deals with the issue this contraption stalls, if there are not enough items in the train. In this case, the inserter stops and waits infinitely for an item that's not there.
You need to include the actual train content into the calculation. You need to unload the difference, but not more than in available from the train. For this, you need to add a MIN(demand, train content) operation, which can be accomplished with 2 additional decider combinators. (example: see viewtopic.php?t=124776)
There's an alternative. Further down the mentioned thread, there is an example how to iterate over a list of items over and over again. With this, you can ignore the train content and just switch from item to item every tick, and if the item is available, it's picked by the inserter. However, this uses a minimum of 2 combinators, so it's no advantage over the MIN(x,y) solution above.
If you use this for train unloading with multiple wagons, you need 3 combinators per station (1 for computing the diff and 2 for computing MIN()) and 2 combinators per wagon (for selecting an item and computing stack size).
Re: Filters overrides stack size
I know easy solution, just "hardcode" 1 as a stack size for inserter

Re: Filters overrides stack size
+1
Using combinators is not always convenient due to the tick delay, and sometimes it is impossible when there are many signals.
Using combinators is not always convenient due to the tick delay, and sometimes it is impossible when there are many signals.
-
- Filter Inserter
- Posts: 299
- Joined: Sat Oct 07, 2023 6:44 am
- Contact:
Re: Filters overrides stack size
And you will get a delay of 2 ticks.
Re: Filters overrides stack size
Viidi wrote: Sun Mar 09, 2025 12:23 pm Using combinators is not always convenient due to the tick delay, and sometimes it is impossible when there are many signals.
Well, it is possible to make it by one decider. It selects one positive item from the list and creates S the Control Stack value to unload the Exact amount : Self feedback on RED_WIRE makes the exact stack. Because Output is Wild ANY it pass only one item. Another trick is, when inserter gets item signal and Stack is not_defined it starts move it starts to move anyway, then one tick later he gets the stack. For some reason, size of the Stack is locked by inserter only in case it is non zero number. You cant change non zero Stack when inserter moves. However, you can change the Stack, if it has non_defined value in the beginning of the move. Therefore it works reliably.Tertius wrote: Sat Feb 22, 2025 11:31 am The key to exact unloading is the ANY wildcard.
... you need to unload as positive values. Feed this list to the 2 combinators I mentioned above. Total 3 combinators.