Read inserter stack size from the picked item's channel

[ignatio]

TL;DR

When the inserter stack size is controlled by the circuit network, make it possible to read the size from the same channel as the item it has picked up.

What?

E.g. if a filter inserter has chosen to pick up pumpjacks, the stack size for that particular pick would be read from the pumpjack channel. The UI to select this mode of operation could be an "each" option in the "control signal" selection dialogue. This feature would fit well with the "set filter" mode since the signals on the network set both filter (>0) and stack size at the same time.

Why?

This is useful when one wants to fill a chest or wagon with several different items to exact counts. It's not a problem to determine how many units of each item to transfer, but extracting the right count to a statically configured channel is to my knowledge difficult (i.e. it requires O(number of item types) amounts of combinators). There is no way of knowing in advance which of the enabled items a filter inserter will pick up.

The only feasible alternative I know is to have a second filter inserter that moves items in the opposite direction: When the first inserter is starting a pick that overshoots the target count, the second inserter takes out the difference by looking at the item type and count in the hand of the first one. That method has some practical limitations that are hard to overcome though - it is e.g. not always the case that enough items to carry out the reverse pick are available in the same chest/wagon it picks from.

[Omnifarious]

E.g. if a filter inserter has chosen to pick up pumpjacks, the stack size for that particular pick would be read from the pumpjack channel. The UI to select this mode of operation could be an "each" option in the "control signal" selection dialogue. This feature would fit well with the "set filter" mode since the signals on the network set both filter (>0) and stack size at the same time.

I agree strongly with this. On the loading side I've resorted to a design in which overshooting is acceptable because I leave extra space in wagons for every item where the limit I really want is near the maximum stack size. And on the unloading side, I just took the time hit and set the hands size limit to 1.

I was really surprised that filter inserters didn't work this way already. It's such a logical and intuitive way to handle setting the filter and hand size limit at the same time.

[Impatient]

I am not sure if understand this right but I am interested in the topic as I engaged heavily in finding efficient precise counting solutions lately myself.

So, ...

This is useful when one wants to fill a chest or wagon with several different items to exact counts. It's not a problem to determine how many units of each item to transfer, but extracting the right count to a statically configured channel is to my knowledge difficult (i.e. it requires O(number of item types) amounts of combinators). There is no way of knowing in advance which of the enabled items a filter inserter will pick up.

Does the suggestion result from the limitation, that the stack size only can be set for all filtered items and not for each one?

In that case I fully back this feature request.

When the inserter stack size is controlled by the circuit network, make it possible to read the size from the same channel as the item it has picked up.

E.g. if a filter inserter has chosen to pick up pumpjacks, the stack size for that particular pick would be read from the pumpjack channel.

So you suggest the stack size for a particular type of item is set to the value in the signal that sets the filter? I think this is a great, because very simple solution.

[Omnifarious]

Does the suggestion result from the limitation, that the stack size only can be set for all filtered items and not for each one?

I came here because I was about to make the same feature request and was pleased to note that someone had already done it for me. So, I will attempt to answer your question with what I'm trying to do...

I have a station that loads up a two car wagon with a whole bunch of goodies. Belts, inserters, roboports, turrets, walls, electric poles, factories... all kinds of stuff. A giant laundry list. I use the circuit network and filter inserters to make this happen.

I have some constant combinators that list out how much of each item I want, then I multiply that by -1 and add that to the train contents. Any item that's still less than 0 gets forwarded on to set the filters on the filter inserters. So as soon as the number in the train meets or exceeds the level set by the constant combinator that filter turns off.

Unfortunately, inserters typically move several items at a time. So the number that is loaded into the train usually exceeds the requested number by some amount. This is especially irritating when I'm requesting a full stack of items, because any extras bleed over into another stack and take up more space than I planned.

So I wanted to also set the number of items the inserter moved to always be less than or equal to the number of items needed. I'm already figuring that out anyway, and just need a way to use that information to set the stack size on the inserter.

Unfortunately, a filter stack inserter can only be set to one item, and even a normal filter inserter only 6. My train frequently needs to unload or load 10-20 different items for a particular part of my base. So the filter just randomly picks (well, according to some system, but the system isn't obvious or easy to create a circuit network around) some subset of the signals its being sent to set the filter. It's impossible to know what filter is actually set unless you wait for the filter to pick something up and read the hand contents. By then it's too late to do anything about making sure it doesn't pick up too much.

It would be possible to make a complex circuit network to set the filter to one item at a time and then set the stack size correctly for that item. But I can't think of a design for such a network that would use less than one combinator per item, and with 20-30 different items, that's a LOT of combinators just for a loading or unloading station.

The best option for this situation is if the inserter just set the stack size from the number for the signal for the item. It's intuitive and obvious. A signal of 0 already turns off a particular item for the filter.

But, there are good reasons to have the filter size signal be separate as well. Other use-cases than mine. And so the old behavior should be kept and a special thing (like the each, any, all selections for combinators) be set up for this behavior for inserters. And luckily, just re-using the 'each' signal is the intuitively obvious choice in this case. Both the OP and I thought of it independently. And I, for one, was frankly surprised that it wasn't there already.

[ignatio]

Yes, I think the "each" (yellow star) option is fairly obvious for the interface.

As I touched on in the OP, I have been able to work around the problem using the "reverse pick" trick:

If I want, let's say, 50 splitters in the train and it currently has 46, then I have one inserter loading the train with a full hand of 12 splitters, and some circuit logic that makes another inserter simultaneously unload the excess, i.e. 12+46-50=8 splitters. The circuit reads the item type that is in the hand of the loading inserter and only checks the counts for that specific item, so it avoids the problem of not knowing what the filter inserter will pick up.

The excess unload pick is done in parallel with the loading one, so the item level in the train will temporarily go from 46 down to 38 and then 50 when the loading pick lands. This means there can be edge cases if I want low item levels in the train and there just isn't enough items to fulfil the unload pick.

In practice though I've gotten it to work pretty well, although the circuit network becomes quite a mouthful:



Granted, this monster also does some other stuff: It allows setting import and export item levels (the constant combinators to the left with "I" and "E" in them - this particular station only imports items) and has some logic to send back import items that overflow the local logistic network.

Also, the bit to the right is a somewhat separate thing: a "superchest" which allows me to keep small stacks (<= 50 items) of many different item types in the main chest and store excess items in the line of chests going off to the right. It's important though to have all different item types that I might want to load in a single chest - makes things a lot simpler.

The white stack filter inserter in the middle right is the loader, the one to the left of it is the import unloader, and the last one to the left is the excess unloader that counters overloading.

I use just a single wagon, so this setup is limited to max 39 different item types (the wagon needs at least one empty slot). It can be scaled further by adding more wagons and simply duplicating the stuff above. I think the speed is decent because most picks will use the full 12 item hand capacity, but of course this system has its limits if one want lots of a few item types.

[Omnifarious]

You've gone a lot farther than I. Any given station can only do either export or import. I've considered adding export capabilities to remote station to move out rocks and wood to feed into stuff that can use it. I guess when I expand and want to deconstruct a wall maintenance station a more comprehensive export could be helpful.

Now, where I have really tricked out the circuit network is in building things to automatically switch fuel between wood and coal when I have an excess of wood. Green chests are going to make that a LOT easier.

Also, uranium processing. I have lots of circuit network stuff to deal with that. Green chests won't make that easier.

[Omnifarious]

I'm curious if this is a "won't do" or not.

[masonl]

Heya folks (first post),

I've written a guide to creating fast & exact inserter systems: https://mason-larobina.github.io/factor ... ution.html

I'm using an index trick to isolate individual items for processing one at a time. This allows me to set a second signal for the hand size at the exact number of items needed (because I no longer have a mixed-item signal). However the designs and blueprints in that post require manually creating an index.

I've just finished a circuit that will generate the index automatically. Here's a sneak peek:



I'm in the middle of a second post to describe how to build the auto-indexer.

I would love this feature -- but then I would never have created the indexing system. I've enjoyed discovering/creating a workaround for this limitation.

[uthbees]

It seems to me that you could just filter the cargo wagon slots:

[masonl]

Yes, that's exactly what I did in the early game.

[Omnifarious]

It seems to me that you could just filter the cargo wagon slots:

Yeah, I tried that. But the inserters would get stuck holding an item that couldn't fit in the inventory and not pick up any of the other items that could go in the inventory. That works for one chest per item, (and I notice that you seem to have exactly that) but otherwise fails.

[Omnifarious]

Heya folks (first post),

I've written a guide to creating fast & exact inserter systems: https://mason-larobina.github.io/factor ... ution.html

I'm using an index trick to isolate individual items for processing one at a time. This allows me to set a second signal for the hand size at the exact number of items needed (because I no longer have a mixed-item signal). However the designs and blueprints in that post require manually creating an index.

Interesting. I made a system that would set the smallest stack that would work for any of the inventory items. It was faster than a stack size of 1, but still not that fast.

I made an index system for an auto-deployment of radars using the recursive blueprints mod to handle the different deployment stages. I didn't think to use anything like that for this. That is clever, though very circuit-logic heavy. And you're right, having '*' would've meant you never tried.

Though, I built something of similar complexity because I wanted to make something nifty with recursive blueprints, so...

[ssilk]

Look into the LTN board: it’s possible to build insert into train without getting stuck.

[BloodyRain2k]

Can't just the 'Each' signal be added to the filter inserter where it will use each filter signal it's being supplied that's above 0?