Reversible Inserters

[loganb]

Hello,

This is a tl;dr from the trains post I made (viewtopic.php?f=6&t=39559), which I split out for because I realized it's really a separate feature with multiple use cases.

Suggestion

Inserters driven with a negative value from the circuit network (filter and otherwise) should reverse-load a resource. That is, they will run backwards, taking resources from the input stack of their destination, and return them to the source, presumably at reduced speed. This solves a large number of interesting problems.

Example: Unstick Deadlocked Inserters

If stack inserters are loading a train with multiple resources, sometimes they can become "stuck" holding a stack they cannot put down and thus are deadlocked. With reversible inserters, logic to automatically unstick all inserters might look something like this:

Unstick Inserters.png (845.82 KiB) Viewed 3570 times

This example uses the SmartTrains mod to detect the presence of a train. The hand contents of the Stack Inserters is being read, multiplied by -1, and then passing through the shown Decider*. When a train leaves, all the inserters are fed a -1 value for the resources they collectively hold, which will cause them to attempt to reverse load them and drop them back into the crates. Thus, once a train leaves, the inserters all "unstick" themselves if they were trapped holding a resource they could not load.

Example: Unload Stuck Furnace

Since reversible inserters unload from the input of their destination when in reverse, they unload inputs to a furnace that would otherwise leave it stuck. Imagine you have a shared furnace that you wish to flip from processing Stone to processing Iron Ore. Since each Stone Brick takes two Stone, there may be one Stone in the input slot, leaving the furnace unable to being processing a source of Iron Ore.

Unstick Inserters.png (845.82 KiB) Viewed 3570 times

In this example, feeding the loading Filter Inserter -1 for Stone Ore causes it to remove the lone Stone Ore from the furnace and deposit it on the far side of the belt. The Filter Inserter then proceeds to attempt to load Iron Ore from the same belt.**

Example: Balance two Chests

This also allows for interesting ways to balance the contents of adjacent chests.

Chest Balancer.png (337.24 KiB) Viewed 3570 times

The Filter Inserter in this case is being driven with the value (Left Chest - Right Chest). Thus, if there is more of any resource in the Left Chest, the Filter Inserter will move it to the right. If there is a surplus of any resource in the Right Chest, it will see a negative value on the circuit network and thus move that resource to the Left Chest.***


* There's an issue with this layout because the stack inserters are all wired together, and thus their hand contents influence each other. This could be solved using a combinator as a buffer for each one, but I think there's a more general problem in that it's basically impossible to read an inserter hand's content while simultaneously controlling it. There are a number of solutions for that problem.
** Implementation Note: Filter Inserters should always attempt to unload, if possible, before attempting to load.
*** A somewhat more complicated set of combinators could handle the case of an odd number of a resource causing it to bounce back and forth

[ssilk]

Good reasons and not the first, who suggests so this. The examples are excellent.

What if the inserter cannot put back the item, cause the chest/furnace/wagon etc. is meanwhile completely filled?

Inserters are delicate, cause even one CPU cycle more influences game performance much. Have you thought about that? How many CPU will it take to perform the circuits every time the inserter grabs?

What I mean is: is this a good idea to change such a very basic element of the game without such knowledge? Wouldn't it be smarter to search for a different solution?
Wouldn't a better suggestion not sound like: "As player I want a solution for the three examples I made."

? Too simple?

[Gertibrumm]

Right no I am using this setup for counting large throughputs:

counter.jpg (93.79 KiB) Viewed 3539 times

The bottom two filters are to exsert or "reverse load" the belt form any item the stack filters inserted too much.
I could use this feature to simplify the circuit, but just as ssilk said "there are other solutions".

[loganb]

Good reasons and not the first, who suggests so this. The examples are excellent.

Thanks! I know the inserter-deadlock problem has been talked to death, and I know people have suggested that inserters put stuff back, but I hadn't seen anyone suggest it do so only through circuit network control.

What if the inserter cannot put back the item, cause the chest/furnace/wagon etc. is meanwhile completely filled?

Absolutely a case that must be planned for. My suggestion is that if you tell an inserters to reverse load but they can't, they become locked just as they would today. The difference relative to today is that I can plan for that using the circuit network and ensure it never happens.

Inserters are delicate, cause even one CPU cycle more influences game performance much. Have you thought about that? How many CPU will it take to perform the circuits every time the inserter grabs?

As a software engineer, I'm sympathetic to the desire not to change hot code paths. But I'm not qualified to estimate the performance impact since I don't know the Factorio code base.

On the plus side, this suggestion only affects inserters connected to the circuit network and further only inserters with a negative value on the circuit network. So were I to speculate, in the common case, non-connected inserters could have a flag indicating they don't need to do any backwards loading, so in assembler code it would be an indirect LOAD followed by a BRANCH to check the flag and skip the complex work (with very good branch prediction accuracy), probably introducing a 2-5 CPU cycle penalty per inserter.

What I mean is: is this a good idea to change such a very basic element of the game without such knowledge? Wouldn't it be smarter to search for a different solution?
Wouldn't a better suggestion not sound like: "As player I want a solution for the three examples I made."

? Too simple?

Hahaha, I like how you phrased this thread as a User Story. So yes, I'd say this, "As a player, I'd like a solution for these three examples. More broadly, I'd like to be able to spend more mental energy to use the circuit network and other tools to make more compact (and more complex designs) rather than do the naïve thing and mindlessly stamp out a simple design over and over."

Having thought about all these problems, I believe no (reasonable) solution exists and as a Software Engineer, I just assume everyone sees the problem and just straight to discussion solutions.

[vipm23]

I'm with loganb in that you don't need to check the inserter for reversing every time it does something, just when it's getting fed a negative value for the resource it's holding.

possible Pseudocode:

if circuit.connected() = true
---if inserter.c_set_filters = true
------foreach(circuit.channel x)
---------if x.same_as(inserter.itemheld())
------------if x < 0
---------------inserter.reverse()
------------else
---------------inserter.insert()
---else
------inserter.insert()
else
---inserter.insert()

[bobingabout]

I think the biggest issue with this is basically... Drop position has an offset, so it places it on the far side of a belt, pickup position does not. So if an inserter runs in reverse, assuming the input is a belt, where does it place the item?

Just something to think about.

I've had plenty of people asking me to allow inserters to pick up from a specific side of a belt before, currently the game doesn't really make allowances for that.

[TheCardinal]

Another use for such an inserter would be to load a buffer (f.e. a chest) from a belt als long as there is ample supply of an item and replacing the items when supply of the items is low.