Inserting arbitrary hand sizes by using "Set Filters"

[BlakeMW]

When a filter inserter has no filter it simply dumps its load. This can be used to have a filter inserter pick up items until it has the desired amount in its hand - then you cancel the filter forcing it to dump its hand. This only works when picking up from belts, and only under certain conditions, as explained later.

• Set filter inserter to "Set Filters", and "Read Hand Contents: Hold"
• Feed signal from inserter into Arithmetic Combinator set to "In: Each * -3, Out: Each" using Green wire and return the signal from the Output using Red wire.
• Use a constant combinator (or anything else) to output the "set filter" signal - the magnitude is the desired hand size. Use Red wire.

Finally you need to regulate input to the filter inserter. The basic condition is that the belt must not be moving (it could also be unsaturated - but not moving is probably easier to guarantee). If the belt is moving the inserter can pick up two items in one tick (or perhaps 2 items in 2 ticks), this is because the belt itself moves the item into the hand and the inserter doesn't have time to change its behaviour. So the belt has to be stalled. The easiest way to stall a belt is connect the belt using a wire and do nothing more. A connected belt with no conditions will allow a single item to enter it (for some reason!) and nothing more. This tricks works whether the stalled belt receives items from a belt or an inserter.

So here's an optimized setup which uses a single arithmetic combinator to feed 1 iron plate at a time:



A belt set to be unconditionally stalled and "read contents: hold" can receive a single item, when it has an item it outputs a "item = 1" signal to the inserter, which then sets the filter allowing the inserter to pick that 1 item up. The inserter outputs its hand to the arithmetic combinator which returns a negative signal cancelling out the positive signals, clearing the filter and forcing the inserter to drop its load.

Note that with a couple extra belts and some more combinator logic you can buffer up 5 iron plates and cause a stack filter inserter to pick up exactly 5 items or any other desired hand size. Unfortunately the inability to both set filters and set a condition for activity means you have to make sure there are (at least) "desired hand size" items ready to be picked up on the belt system (plus those already in the inserters hand) as a condition to have the inserter's filters turned on.

There are probably some approaches I've not thought of. One thing I can think of: with the Stack Filter inserter it only has 1 slot, you can suppress picking up by sending another signal (for example Wooden Chest). How it decides which filter to set is still a bit of mystery to me (though it seems that being earlier in the crafting tabs gives higher priority), but a system which controls the inserter through a suppression signal may well be simpler than one which directly (un)sets the filter for the desired item.

[roberwt]

Nice idea! However I don't see much use of it.

[Tinyboss]

A connected belt with no conditions will allow a single item to enter it (for some reason!) and nothing more. This tricks works whether the stalled belt receives items from a belt or an inserter.

I think this behavior (at least for belt-to-belt transfer) is going to change for 13.9 (see here). IMO non-moving belts should act exactly like empty ground (which is why exactly one item may be placed on them by an inserter--that should stay).

[BlakeMW]

Yes, I expect that part doesn't work anymore.

[siggboy]

The basic condition is that the belt must not be moving (it could also be unsaturated - but not moving is probably easier to guarantee). If the belt is moving the inserter can pick up two items in one tick

There are even more factors at play:

• If the inserters gets a mix of items it's different to when it gets a straight row of the same item.
• Belt speed matters.
• Belt direction matters (I think).
• Inserter orientation matters (I think).

I'd have to run more tests.

In one experiment the technique did not work 100%, so I slowed the input belt down from blue to red, and from then on it worked flawlessly.

So you do not have to stop the belt from moving entirely, slowing down is often sufficient. Also, if you do not have to be count-perfect, then it's OK to accept the inserter grabbing one item too many here and there.

Note that with a couple extra belts and some more combinator logic you can buffer up 5 iron plates and cause a stack filter inserter to pick up exactly 5 items or any other desired hand size. Unfortunately the inability to both set filters and set a condition for activity means you have to make sure there are (at least) "desired hand size" items ready to be picked up on the belt system (plus those already in the inserters hand) as a condition to have the inserter's filters turned on.

That's actually not true. See here what player Jupiter came up with: viewtopic.php?f=5&t=28110#p181710

The trick of using -2^31 to provoke the filter-clear is really very valuable; I've already found a way to improve the smart loader with it for 0.13, but I'll make a separate post about that.

There are probably some approaches I've not thought of. One thing I can think of: with the Stack Filter inserter it only has 1 slot, you can suppress picking up by sending another signal (for example Wooden Chest). How it decides which filter to set is still a bit of mystery to me (though it seems that being earlier in the crafting tabs gives higher priority), but a system which controls the inserter through a suppression signal may well be simpler than one which directly (un)sets the filter for the desired item.

I'm pretty sure it's the order of items in the menu; the game appears to iterate over the signals in "sort order", or the "sort order" is the same as the order in the internal symbol table. It's not something the player can rely on. The lack of control over which signal will get used for the filter slot is a problem, as it's very difficult to pick a single signal (preserving type) from a set of inputs.

In any case, if you want to avoid certain signals to become filters, but you can't drop them, then making them negative instead can be an option.

A few more things:

• Virtual signals (like "A", "Red", "Green", ...) can not be used as a filter. You can safely mix them with entity signals.
• With "Read hand contents: hold", the inserter reads the hand content to itself. If it still has an item in the hand, and you drop the external filter signal, the filter will remain (the item in the hand will set the filter).
• If the previous situation occurs (inserter is stuck with item and thus with the filter), then the only way to replace the filter is to overwrite the filter signal with a negative one and input another filter signal simultaneously.

[BlakeMW]

I think there are going to be some changes to inserter behaviour anyway. In particular I believe it's now considered a bug that an inserter with stack bonus which has some items in its hand and has been turned off by the circuit network continues to wait for more items instead of dumping the items it has picked up already.

Once that bug is fixed it'll be a lot more straightforward to have the inserter pick up 5 items then drop them, as you can simply use the enabled condition instead of the filters.

As for exploiting overflow, it's an impressive technique, but as a programmer it is horrifying to me.

[siggboy]

Once that bug is fixed it'll be a lot more straightforward to have the inserter pick up 5 items then drop them, as you can simply use the enabled condition instead of the filters.

That might become a bit easier. If you need to set the filter, however, you can not use the enable condition. The game does not allow to use both at the same time (in my opinion that should be changed).

The integer overflow technique is very useful if you need a dynamic filter and a perfect item count at the same time. You can even set the filter and the item count with the same signal. I have to design a smart furnace column that uses that approach.

As for exploiting overflow, it's an impressive technique, but as a programmer it is horrifying to me.

In a higher level programming language, the overflow usually indicates a bug, because it normally happens when your bounds checking is incorrect. That's probably why it's horrifying to you .

I would also like to point out that adding 2^31-1 to a signal in order to make it negative is NOT exploiting overflow. It's just a simple integer addition. Just because the game interprets the integers greater than 2^31-1 as negative (2s complement) it appears unnatural. (Causing overflow would be to subtract from -2^31, or to multiply the most significant bits out of the number; BTW that's also useful in advanced circuits.)

The combinators in Factorio are a programming language, but they're much closer to a very simple assembly language than to anything remotely high level. In that environment you have to use things like the 2s complement to your advantage.

[BlakeMW]

That might become a bit easier. If you need to set the filter, however, you can not use the enable condition. The game does not allow to use both at the same time (in my opinion that should be changed).

You can still set the filter manually, just not using a circuit condition. I agree that both should be possible although it wouldn't be so important if you could actually turn an inserter off while it has items in its hand, atm the only way to make it drop is to clear the filter or cut the power for a while before restoring power.

The combinators in Factorio are a programming language, but they're much closer to a very simple assembly language than to anything remotely high level. In that environment you have to use things like the 2s complement to your advantage.

That's a debatable point. The "length" of a combinator program is often about the same as the length of the equivalent program in a scripting language. But that depends on what kind of task you're trying to perform. I'd say for factory management tasks it's a lot closer to a high level scripting language than an assembly language, as an example earlier I developed my own belt throughput reader. I wrote the program in 3 lines of pseudocode and then implemented it in 3 combinators. On the other hand, if you're trying to say print words on a display, it probably is closer to an assembly language.

[siggboy]

You can still set the filter manually, just not using a circuit condition. I agree that both should be possible although it wouldn't be so important if you could actually turn an inserter off while it has items in its hand, atm the only way to make it drop is to clear the filter or cut the power for a while before restoring power.

Yes, that behaviour makes no sense but I'm pretty sure they will fix it in 0.13.

as an example earlier I developed my own belt throughput reader. I wrote the program in 3 lines of pseudocode and then implemented it in 3 combinators. On the other hand, if you're trying to say print words on a display, it probably is closer to an assembly language.

Can you show the pseudocode? I'm pretty sure you're handwaving over the issue here.

Pseudocode as it's usually written assumes an imperative execution of the program, and that you have variables where you can store values. That's absolutely not what combinators do, because there's not even a "memory" combinator.

You can make contraptions that do very specific things, such as "loop a value between 0 and 100", and then kind of develop your own pseudocode "language" around that. That would not map any longer to single combinators and their very limited capabilities.

Hence my comparison to a (simple) assembly language, where you have instructions like "add x to register A", "jump to z", but nothing like the high level constructs that you use in typical pseudocode.

Sure, if your pseudocode is "If Oil < 100 then enable pump", that happens to be a thing that can be translated into a combinator setup very easily. But you can't just simply say "Loop { C = 0; While (T < 60) { C += BeltContent; T += 1 }; Output C/60; } and then expect anybody without good combinator knowledge to be able to translate that into a circuit. It probably feels straightforward to you because you know how to setup registers and loops and all, but all of that is nothing that follows from the pseudocode.

[BlakeMW]

Basically:

Code: Select all

each tick:
  counter += input * 60 
  counter -= counter / 60

Value of counter is average throughput per minute, divide by 60 to get average throughput per second. The result is probably not entirely statistically sound but is good enough.

Also, the "each" "anything" and "everything" pseudo-signals are basically equivalent to high-level functions like "map" and allow for some surprisingly expressive combinator-programs, such as the ability to count multiple signals.

[siggboy]

This is actually a really good algorithm. Still useless pseudocode for somebody who's not already good with combinators, but for me it was helpful.