A Needed Stack Size Option For Inserters With Filters Set

[KeithFromCanada]

TL;DR

Add the 'Each' signal to 'Set Stack Size' for inserters to use the count of the first item in the filters list or, if there are signal(s) matching the item(s) available for pickup, use the signal count of whatever item is going to be picked up.

What?

I have a defences resupply train. To avoid having to add and maintain filters to the cargo wagon, I multiply its contents by -1, add them to the signals from a constant combinator that sets the desired amount, then feed that through a selection combinator to choose the highest need, and finally feed that to the inserters loading the cargo wagon. This works great, except I have to either have a second set of inserters that remove any excess, set the stack size to 1, or have one inserter for each item* to avoid creeping excess filling up the wagon.

*(Setting stack size to the (single) item type being transferred will insert the maximum amount until the desired quantity drops below that, whereupon the stack size will be automatically set to the exact number needed to fulfill the request. It's a nifty trick and I wish I could remember who I snagged it from.)

If the 'Set stack size' option allowed for the 'Each' signal to be set--which uses the count of the item in the first slot of the filters list--then the handy trick mentioned above could be used with an arbitrary item list to ensure that only the exact amount of a requested item will be inserted.

Factorio Set Stack Size Idea.png (116.9 KiB) Viewed 1019 times

(In this image, the current ammo count is 191 out of 200, so the stack size is automatically set to 9 to deliver exactly the amount required.)

Why?

It will allow delivering exactly as much of an arbitrary item as necessary without requiring a lot of messy circuits/etc. on the player's part.

[KillingTimeItself]

this would admittedly be a pretty nice QOL change for us using a circuit enabled mixed loading setup. Currently you need two additional combinators to make this work nicely, one for setting the stack size, and one for delaying the filter timing so it's actually functional. Though its not like this is a huge technical limitation, just sort of arbitrary.

But i assume there's a reason the devs didn't implement it so who knows why.

[Koub]

For completeness, this suggestion is similar (albeit with "Anything" signal) : viewtopic.php?t=128426

[Th13f]

TL;DR:
Allow `Any` virtual signal in `Set stack size` inserter control. Drop boilerplate combinators for exact item+count controlled inserters from three to zero.

The bottom half of the screenshot show current subsystem needed for exact item control, the top half shows the hypothetical feature request world.

What:
- When `Any` is applied in `Set stack size`, the set filters option adjusts internally and only allows one signal through even if multiple exist, following the same logic of decider combinators in the case of (input: `Each` output: `Any`).
- When `Any` is applied in `Set stack size`, the UI set of five options for the inserter filters drops to one.

(A follow-up feature request could be to allow `Each` virtual signal in `Set stack size` inserter control; this has more nuance to consider; at least including how to intelligently apply stack size values to filter values based on what is being picked up, or what is about to be picked up).

Why:
- If the `Any` virtual signal were allowed in `Set stack size` inserter control, two or more boilerplate combinators could be removed from all places exact inserter control is needed over multiple possible input signals.
- Use Case: Controlling an inserter filter and stack size across multiple possible input signals. Example: a source chest has multiple items, an inserter controls input to a sink chest with item filter and exact item count stack size control.

Current Design:
A minimum of three combinators are needed here:
1) A decider to take as input a possible multiset(`Each`), and output `Any` to reduce to one signal.
2) An arithmetic to translate that signal to a stack-size virtual signal variable.
3) Another combinator to act as signal delay so the filter signal and stack size signal arrive at the inserter at the same tick.

The current situation is the bottom half of the image; with constant combinator represenging input signals we have 1) the filter and 2&3 the stack-size virtual variable and signal delay, then lastly the inserter.
With `Each` implemented for inserter `Set stack size` control the above path of source -> inserter would work, and cut down on boilerplate combinator setups I have copy-pasted around my builds.

07-06-2026, 12-18-45.png (366.71 KiB) Viewed 124 times

[Th13f]

For what it's worth, I would have named the title of this request: "Allow Any Virtual Signal for Inserter Stack Size".

[redrook]

Seems like the variant where each filter's exact value is also the stack size for items of that kind is the nicest generalization.

If we wanted to get complete / fancy I suppose "each" could mean the above, where "any" could mean that the stack size is the same for all items, but the values is either the value of the first filter in the UI, or the largest filter (first in lists of signals as they are usually sorted - I don't actually know what the tie breaker is for signals with the same value, is it alphabetical on the name maybe?), or actually randomly selected one for extra fun. But really whatever "Any" usually selects in other contexts where it's already available.

Alternatively "Any" could mean the max among filters, "All" could mean the min among (non-0) filters - or vice versa, whichever is more consistent with other instances of similar elsewhere (any/all among locomotives for fuel-related wait conditions come to mind, and suggested below semantics for Enable on inserters themselves as well), and "Each" could mean each item type from filters gets its own stack size.

[redrook]

If we wanted to get fancy and/or complete along another dimension, we could also support Each in Enable.

Each in Enable automatically sets filters as a way of implementing Enable: Every signal S that passes the Enable check when Each is substituted for S is set into Implicit Filters as S=1

An item can pass iff it's simultaneously allowed by Implicit Filter and Explicit Filter, consistently with the current behavior of Enable (and Filters).

Why?

I've encountered this on Gleba where I'm getting started using Sushi chest-inserter chains: I have an inserter in this postion:

Code: Select all

<-inserter- [D chest] <-inserter- [S chest]

and I want the inserter to keep moving items of kinds A and B from S chest to D chest without ever using all slots in D chest for the same kind of item, blocking the transfer along the chain for the type. Here B is often the spoilage result of A.

With the feature above I could just set "Each < <not quite the full capacity of the D chest>" in Enable, and achieve the desired result - allow as much buffering as possible flexibly for whichever item dominates (A or B), but never block pass-through of the chain for either A or B.

[macdjord]

+1