0.13 Count Perfect Chest Item Count

[Miravlix]

With the changes in 0.13 and with logistics robots, getting precise item counts has become a lot harder, for a while I thought it was actually impossible.

I wanted to create a chest with 5/5 robots and a roboport for picking up when I create a outpost maintenance network, but logistic robots did something like 6/6 and far too many robo ports.

So how about a requester chest and inserters filling a chest with the numbers I want, nope doesn't work either due to inserter item stack bonus...

Accidentally while trying to put item on ground between inserters, I finally found the "solution", emptying a chest is count perfect.

If I tell any inserter to remove items until there is five left of an item, it will do just that and leave five in the chest, no matter the inserters stack bonus.

[DOSorDIE]

A good question ... it should be able to disable the "Item Stack Bonus" for inserters.

[Zeblote]

What's the use of having an exact number of items in a chest?

[Miravlix]

What's the use of having an exact number of items in a chest?

A classic problem of automation is that inserters get stuck with an item in hand if the destination is full, if you have the item count perfect you can ensure safe unloading of multiple items chests.

I generally design my systems with just enough mentality, instead of some of the silly 3 million buffer craziness some use. The ultimate just enough is that I can use a single belt to transport every item in game, but only put enough item on the belt as is needed. Instead of needing one belt pr. item or at best 1 belt pr. two items, because if my count isn't perfect or I loop the belt, I risk deadlocking, because the surplus items fill up the belt.

[MrGrim]

What's the use of having an exact number of items in a chest?

I don't expect people to defend how they want to play the game, and I'm sure there are many interesting uses for count perfect designs. Though, I will admit I almost always think in terms of stacks and not single items. When it's outpost building time I'm usually running around to chests going, "hmm, a few stacks of those, a stack of that, a couple stacks of that.. and.. screw it ctrl click that and see what happens."

[Jupiter]

So I came up with the following setup in an attempt to create an inserter that can grab only a specified number of items at a time. This only works when grabbing from belts. Grabbing out of anything with an inventory (trains, chests etc) does not work at all. A work-around is of course to put a belt between the inventory thing and your inserter.



In this setup I use arithmetic overflow of signal values in a network to let the signal be >0 (thus removing the filter from the inserter) when I want it to and otherwise be some (high) number above 0 otherwise (and activating the filter). As shown, the constant combinator outputs 2 signals of the type of item that you're going to grab. One signal is always 2^31 - 1= 2147483647. By experiment I found out that signal values are stored in 32-bit signed 2-complement integers thus the number of bits signifying the magnitude of the number is 31 (so 2147483647 is the biggest positive number possible and -2147483648 the largest negative).
The second signal is -x + 1 where x is the limit of items grabbed at a time.

So how this works is that the inserter also reads what it is holding and adds it to the big number. As long as it doesn't reach the item limit then no overflow will occur. When it does, then overflow occurs and the signal value will be -2147483648 and it removes the filter from the inserter. The small signal from the combinator will prevent overflow from happening for a while so it controls your item limit.

[MeduSalem]

So I came up with the following setup in an attempt to create an inserter that can grab only a specified number of items at a time. This only works when grabbing from belts. Grabbing out of anything with an inventory (trains, chests etc) does not work at all. A work-around is of course to put a belt between the inventory thing and your inserter.

[...]

In this setup I use arithmetic overflow of signal values in a network to let the signal be >0 (thus removing the filter from the inserter) when I want it to and otherwise be some (high) number above 0 otherwise (and activating the filter). As shown, the constant combinator outputs 2 signals of the type of item that you're going to grab. One signal is always 2^31 - 1= 2147483647. By experiment I found out that signal values are stored in 32-bit signed 2-complement integers thus the number of bits signifying the magnitude of the number is 31 (so 2147483647 is the biggest positive number possible and -2147483648 the largest negative).
The second signal is -x + 1 where x is the limit of items grabbed at a time.

So how this works is that the inserter also reads what it is holding and adds it to the big number. As long as it doesn't reach the item limit then no overflow will occur. When it does, then overflow occurs and the signal value will be -2147483648 and it removes the filter from the inserter. The small signal from the combinator will prevent overflow from happening for a while so it controls your item limit.

Sir, this is ingenious!

Let's see if I can build a smart furnace setup using belts this way... It might be possible with that setup.

Though I question myself what happens if the output side of the inserter gets clogged? Is the setup stall resistant or does one have to ensure that it never gets clogged on the output side?



I wish though that the devs will wrap their heads around the counting problem and add a manual override for the stack size inside the inserter menu... something like a slider or number field that explicitely tells the inserter how many items to grab before moving.

I already thought about what if for filter inserters the number that comes with the filter signal does specify the number of items to grab... It could be basically a checkbox saying "use item count specified by filter signal as stack size". Might be a suggestion/thought worth following?

[Jupiter]

Sir, this is ingenious!

Let's see if I can build a smart furnace setup using belts this way... It might be possible with that setup.

Though I question myself what happens if the output side of the inserter gets clogged? Is the setup stall resistant or does one have to ensure that it never gets clogged on the output side?

Just tested it and it is stall resistant.

I wish though that the devs will wrap their heads around the counting problem and add a manual override for the stack size inside the inserter menu... something like a slider or number field that explicitely tells the inserter how many items to grab before moving.

I already thought about what if for filter inserters the number that comes with the filter signal does specify the number of items to grab... It could be basically a checkbox saying "use item count specified by filter signal as stack size". Might be a suggestion/thought worth following?

I completely agree. A slider is the best option. I don't see any reason to rob the player of the possibility to turn off some upgrades/techs. Though it would be totally awesome if this number can also be controlled by the circuit network.

[Makk]

With the changes in 0.13 and with logistics robots, getting precise item counts has become a lot harder, for a while I thought it was actually impossible.

I wanted to create a chest with 5/5 robots and a roboport for picking up when I create a outpost maintenance network, but logistic robots did something like 6/6 and far too many robo ports.

So how about a requester chest and inserters filling a chest with the numbers I want, nope doesn't work either due to inserter item stack bonus...

Accidentally while trying to put item on ground between inserters, I finally found the "solution", emptying a chest is count perfect.

If I tell any inserter to remove items until there is five left of an item, it will do just that and leave five in the chest, no matter the inserters stack bonus.

I've noticed similar. Although I rarely bother with it too much because give or take 5 in a chest off-count doesn't hurt much in most scenarios

[TheTom]

It does hurt now if you plan to fill up for example a supply chest via the new filter mechanism.

Old way: One chest and smart inserter per good.

New way: One inserter using a filter condition. SADLY - it may get stuck.

Same situation as old way:

Loading trains with filter on what they can load. Yes, the chest can request and hold many items - but the moment the inserter can not insert something into the wagon, it stops until it cans. Which means you better make sure the inserter inserts single items.

[MeduSalem]

Though I question myself what happens if the output side of the inserter gets clogged? Is the setup stall resistant or does one have to ensure that it never gets clogged on the output side?

Just tested it and it is stall resistant..

Well I found a little problem... or at least some awkward behaviour if the belt the inserter fetches from isn't fully utilized or unevenly populated with more than one item type.

What happens then is that for example the stack inserter will time out in its quest to wait for the next arriving item and then move whatever number of items it currently has in the hand.

So for example I tried to continously move 5 items per turn, but then when the belt emptied up too much the Stack Inserter timed out and moved 4 or less items which shouldn't happen, but it did.

Probably it happens because the filter is still active during the same tick when the waiting period times out. And since we don't perform an actual check if the inserter has exactly 5 items in the hand during that period it will move whatever it currently holds.

I completely agree. A slider is the best option. I don't see any reason to rob the player of the possibility to turn off some upgrades/techs. Though it would be totally awesome if this number can also be controlled by the circuit network.

I'll look if a thread suggesting to set the stack number via circuit network exists... and if not I'll make one.

[Jupiter]

Though I question myself what happens if the output side of the inserter gets clogged? Is the setup stall resistant or does one have to ensure that it never gets clogged on the output side?

Just tested it and it is stall resistant..

Well I found a little problem... or at least some awkward behaviour if the belt the inserter fetches from isn't fully utilized or unevenly populated with more than one item type.

What happens then is that for example the stack inserter will time out in its quest to wait for the next arriving item and then move whatever number of items it currently has in the hand.

So for example I tried to continously move 5 items per turn, but then when the belt emptied up too much the Stack Inserter timed out and moved 4 or less items which shouldn't happen, but it did.

Probably it happens because the filter is still active during the same tick when the waiting period times out. And since we don't perform an actual check if the inserter has exactly 5 items in the hand during that period it will move whatever it currently holds.

I completely agree. A slider is the best option. I don't see any reason to rob the player of the possibility to turn off some upgrades/techs. Though it would be totally awesome if this number can also be controlled by the circuit network.

I'll look if a thread suggesting to set the stack number via circuit network exists... and if not I'll make one.

I am aware of this behavior bit did not think it would be a problem. But you are right, for a smart smelting build it does matter.
Maybe you can create buffer boxes between the stack filter inserter and the smelter and only empty the chest into the smelter when you have exactly the required number of items in the chest. Use the chest contents as your limit-signal instead of setting it on the constant combi (I'm assuming here that you cannot hook up a smelter to the circuit network, to lazy to test now).

[MeduSalem]

I am aware of this behavior bit did not think it would be a problem. But you are right, for a smart smelting build it does matter.
Maybe you can create buffer boxes between the stack filter inserter and the smelter and only empty the chest into the smelter when you have exactly the required number of items in the chest. Use the chest contents as your limit-signal instead of setting it on the constant combi (I'm assuming here that you cannot hook up a smelter to the circuit network, to lazy to test now).

A buffer chest wouldn't help much to overcome the problem... once the wrong number of items is inside the chest... it's inside. And how do you correct it to the intended number? :s

Inserting Items one by one would help preventing the problem, but the problem is that you can't set a filter and a logistic condition at the same time (which is honestly stupid somehow because how to make that inserter work on a logistic condition other than the filter signal without using additional combinator crap, which requires more space...). On top of that one-by-one insert is very slow... and becomes a throughput bottleneck.

[Jupiter]

A buffer chest wouldn't help much to overcome the problem... once the wrong number of items is inside the chest... it's inside. And how do you correct it to the intended number? :s

You do it like this, you feed the box contents back to the stack filter inserter:



The constant combi and the stack filter inserter have the usual settings. I've included the settings for the normal stack inserter. To be clear: there is a green wire between the box and the normal stack inserter.

I have tested this setup and it works. The green inserter won't grab if there are not enough items and the white inserter won't grab more items than is needed to top off the box to the required amount, even if it already has some items.

I picked a limit of 5 plates for the recipe of steel (using this for smelting iron is unnecessary as it used just one ore for one plate).

[MeduSalem]

You do it like this, you feed the box contents back to the stack filter inserter:

[...]

The constant combi and the stack filter inserter have the usual settings. I've included the settings for the normal stack inserter. To be clear: there is a green wire between the box and the normal stack inserter.

I have tested this setup and it works. The green inserter won't grab if there are not enough items and the white inserter won't grab more items than is needed to top off the box to the required amount, even if it already has some items.

I picked a limit of 5 plates for the recipe of steel (using this for smelting iron is unnecessary as it used just one ore for one plate).

Ahh... I fiddled exactly with the same ever since I last posted, but seems like you beat me to it

I also thought about using the box contents to manipulate how many items the white inserter grabs the next time... because when there are already 2-4 items inside then the number from the constant combinator basically gets counteracted and the filter nullified sooner, correcting the fail from the last insert.

From the box into the machine is then a cakewalk.


The entire thing could even be scaled up... for example to take more advantage of the stack inserter's huge stack bonus. So if you specify 10 items as limit it will work too, which is what I also tried.


That said... the buffer box requires additional space... which is a problem because I would have liked to fit the entire thing between beacons and with the buffer chest that's not really possible. Altough above is a fine and working solution it requires too much space. That said I am still positively surprised that it actually works.



Though the Devs should really implement an easier solution to manipulate the stack size directly. Circuit network fun is one thing, but practicability is another... and currently it is anything EXCEPT practicable.

Currently it is more like "Yeah hypothetically possible, but not worth the trouble so I would never use the solution in real applications".

[Neotix]

The main problem with all solutions is that they won't work if belt is not saturated enough because filter inserter don't wait long for items. If there is big gap between items, it will move less items then is setup.

[Jupiter]

The entire thing could even be scaled up... for example to take more advantage of the stack inserter's huge stack bonus. So if you specify 10 items as limit it will work too, which is what I also tried.

I think that you're right (not in the position to test right now). Smart . I first thought it would cause problems but I think it won't. But this will only be useful if one stack inserter cannot keep up with the smelter's speed (this may happen if you have an electric furnace with lvl 3 speed mods + beacons everywhere).

That said... the buffer box requires additional space... which is a problem because I would have liked to fit the entire thing between beacons and with the buffer chest that's not really possible. Altough above is a fine and working solution it requires too much space. That said I am still positively surprised that it actually works.

To cope with the extra size you may want to try to fit the box in between the smelters and have the stack filter inserter and the normal stack inserter be at a right 90 degree angle. This will make your smelting array longer but not wider.

You might even try to have 2 smelters take out of the same box.

The main problem with all solutions is that they won't work if belt is not saturated enough because filter inserter don't wait long for items. If there is big gap between items, it will move less items then is setup.

This is what the buffer box idea solves.

PS: I just got another idea. Instead of having the buffer boxes you might want to try to read the belt contents instead. You let the stack filter inserter only grab items if there are enough on the belt in front of it (and maybe one belt before that one). That way it won't ever try to grab less items then are required. You don't have to worry about a smelter never getting to work if resources are sparse because in a smelting array, if no smelter does anything then the resources just pile up until there are enough resources to have 5 ore in front of the inserters.

[MeduSalem]

To cope with the extra size you may want to try to fit the box in between the smelters and have the stack filter inserter and the normal stack inserter be at a right 90 degree angle. This will make your smelting array longer but not wider.

You might even try to have 2 smelters take out of the same box.

Yeah I thought about the 90° angle too, but fitting the belt delivering the items becomes a bit tricky then... Though I might have an idea for that... One would have to run the belt orthogonal to the furnaces/beacons with Underground Belts. Then the 90° solution may fit within the 2x2 tile space that is left and even leave 1 tile for the necessary electric pole.

With that approach one could possibly build a smart furnace smelting Iron/Copper/Steel Plates... because there is only room to implement 2 such 90° solutions on each side of the furnace. One would be used by Iron+Copper and the other by Steel.

PS: I just got another idea. Instead of having the buffer boxes you might want to try to read the belt contents instead. You let the stack filter inserter only grab items if there are enough on the belt in front of it (and maybe one belt before that one). That way it won't ever try to grab less items then are required. You don't have to worry about a smelter never getting to work if resources are sparse because in a smelting array, if no smelter does anything then the resources just pile up until there are enough resources to have 5 ore in front of the inserters.

That would be definitely worth a try too. But one would have to ensure that the belt with the resources never gets stuck so that the resources continue circling or otherwise the inserter times out again because it waits for items to come along, but they don't since the belt doesn't move. Which basically means you have to leave gaps on the belt on purpose, reducing the throughput.

The rainbow belts thread (viewtopic.php?f=8&t=28414) has a similar problem if the belt becomes clogged and stalls. So eventually a way of controlled item input to the looping belt would become necessary to ensure reliability.

[siggboy]

Hi,

I've run into a related problem that merits discussion in this thread, maybe somebody has good ideas.

I need a train loader that loads items according to a filter. It's not a loader for a supply train, it's a regular outpost loader that supplies more than one type of resource.

For example, imagine an outpost that buffers both "Coal" and "Iron Ore". Before the train arrives, the outpost will be notified of the resource that the train wants to pick up. The filter on the loading inserters will then be set accordingly. This ensures that the train won't leave with mixed cargo and only the one type of resource that we want to transport.

The problem here, of course, is that if we try to fill the wagons completely, or just load an arbitrary amount, then one or more inserters will have "leftovers" in their hands -- in the general case. Obviously, if you make sure that the wagon does not fill up completely, this is never a problem (my current solution).

I'd like a solution where I don't have to limit the buffer chests, so I can just rely on loading as much as possible and still won't have inserters with leftover items when the train leaves.

None of the solutions that are currently being discussed all over the forums really satisfy me -- most of the time simply because they're too complicated. I don't want my loader to require more combinators than my actual smart outpost.

One idea that I have works like this: assuming you want to load X units into the wagon (X will decrease as you keep loading). You'd divide X by <stack limit> (e.g. 13 at full tech), the result S is how many full stacks you can still insert. You then disable inserters successively, as soon as S drops below the number of inserters. If you have 12 inserters at the wagon, as long as S is greater than 11, you can have all inserters operating, as they'll all be able to insert a full stack. When S becomes 11, you disable the 12th inserter, and so on, until it becomes 0, that means you have fewer than 13 items of space remaining, so you have to stop loading.

As long as you can ensure that the inserters are synchronized, this should work reliably...

If only we could use the Filter and the Enable/Disable mechanic at the same time. But we can't . And I do not want to put a driver combinator in front of every inserter just so I can give them individual disable conditions.

Maybe somebody has an idea how to solve this.

[Jupiter]

Hi,

I've run into a related problem that merits discussion in this thread, maybe somebody has good ideas.

I need a train loader that loads items according to a filter. It's not a loader for a supply train, it's a regular outpost loader that supplies more than one type of resource.

For example, imagine an outpost that buffers both "Coal" and "Iron Ore". Before the train arrives, the outpost will be notified of the resource that the train wants to pick up. The filter on the loading inserters will then be set accordingly. This ensures that the train won't leave with mixed cargo and only the one type of resource that we want to transport.

The problem here, of course, is that if we try to fill the wagons completely, or just load an arbitrary amount, then one or more inserters will have "leftovers" in their hands -- in the general case. Obviously, if you make sure that the wagon does not fill up completely, this is never a problem (my current solution).

I'd like a solution where I don't have to limit the buffer chests, so I can just rely on loading as much as possible and still won't have inserters with leftover items when the train leaves.

None of the solutions that are currently being discussed all over the forums really satisfy me -- most of the time simply because they're too complicated. I don't want my loader to require more combinators than my actual smart outpost.

One idea that I have works like this: assuming you want to load X units into the wagon (X will decrease as you keep loading). You'd divide X by <stack limit> (e.g. 13 at full tech), the result S is how many full stacks you can still insert. You then disable inserters successively, as soon as S drops below the number of inserters. If you have 12 inserters at the wagon, as long as S is greater than 11, you can have all inserters operating, as they'll all be able to insert a full stack. When S becomes 11, you disable the 12th inserter, and so on, until it becomes 0, that means you have fewer than 13 items of space remaining, so you have to stop loading.

As long as you can ensure that the inserters are synchronized, this should work reliably...

If only we could use the Filter and the Enable/Disable mechanic at the same time. But we can't . And I do not want to put a driver combinator in front of every inserter just so I can give them individual disable conditions.

Maybe somebody has an idea how to solve this.

What comes to mind is to use buffer boxes near your station. Not to store resources but they will contain just the right amount of resources to fill up a wagon. So let's say you are filling up your wagon with 2x6 inserters. Then you would have one chest for every inserter. A wagon can contain 40 stacks. If you divide those stacks as equally as possible among those chests then you'll end up with 4 chests that have 4 stacks and 8 chests with 3 slots. So the logic goes like this:
If chests aren't full (as in, have just enough) then you keep on filling them regardless of whether a train is waiting at the station. You don't start loading your wagon as long as the chests aren't topped-off.
As soon as the chests are full you start loading your wagon. The amount in the chests will obviously decrease but you don't start filling them until the wagon is full and on its way. Otherwise the items that should be in the train are mixed up with the items that should not and things will go wrong. So now the train is gone and you fill your chests again.

Btw, how are you detecting what resources a train actually wants to pick up?

Another idea popped into my mind, why don't you just mix the resources on a per-wagon basis? So first and second wagon gets iron ore and rest gets coal or whatever. This would also simplify unloading your train at mainbase.