Give input inserters' sleep priority

[Dooces]

TL;DR

Give input inserters' sleep priority, or have distinct input and output buffers for asms/furnaces.

What ?

hcl69AU.jpg (466.84 KiB) Viewed 2412 times

Currently, an inserter will not sleep if it is oriented to take items off a belt segment with moving items when inserting into a furnace. In this case, inputting into a furnace with both input and output buffers full, and nothing but conbots on the belt. I am (perhaps naively) unaware of what checks the inserter may be doing, or how the result of any of those checks would result in any activity (if there was ore on the belt, it would still do nothing because the furnace is full). The same thing happens with inserters taking out of a chest, though only for 1 tick when the chest content changes.

It appears inserters can go inactive when [(output buffer * equivalent mats) + input buffer] mats are above a certain threashold (which also causes asm output inserters stay active longer)

WHAT do you suggest?

I acknowledge I know virtually nothing about why things are coded a certain way, or what their implications are with other entities, so my humble suggestion is in all likelihood an ignorant one: if an inserter's inactive state is contingent on the furnace they're feeding, regardless of what may pass on the belt, or what chest contents might change, not have a wake-up tied to their grabber parts (like how it works with asms).

Ideally, input buffer thresholds would be independent from output buffers for all furnaces / asms. With slow craft time recipes like LDS and prod modules, an input inserter can stay active for the duration of a craft, only to have productivity finish, its combined (output buffer * mats) + input buffer is now past its threshold, and input inserter goes inactive, without having inputted anything (though at least with asms, the input inserter doesnt have a wake-up tied to the belt/chest).

Why ?

If the input inserter's "active" state is singularly contingent on a distinct input buffer:

it would no longer go active for 1 tick after each craft (significant for fast crafting recipes likes copper cables) *edit* it would still tick active when the # of mats in the input buffer changes though
it could go inactive sooner
it could stay inactive if a belt moves, or a chest content changes (as the results of those checks would never be used)
it wouldn't need to "sleep" mid-pickup (which requires inserter to go through a "sleep" animation and consequently "wake-up" animation)
asms / furnaces could still be force-fed by a player past its normal input threshold

My base is by no means uniquely large, but by optimising our inserters interaction with belts we've gotten 20%+ more cpu efficient designs, yet they still require significant processing time. The recent (amazing, game-changing, epic, elegant, I could go on) belt optimisations make their use not just practical, but superior to bots cpu wise at any scale. Inserters interacting with the belts, however, require convoluted designs to take full advantage of what these optimisations offer:

kPEgm1o.jpg (534 KiB) Viewed 2412 times

(2x inserters are typically needed to supply this copper cable asm quickly enough to meet its demand, however requiring 2x inserters for all copper cable asms' copper input means extra overhead, as 2x inserters would be taking off a belt less efficiently, and 2x inserters would tick active after every craft)

I dont mind the slower (17.1 items/sec in this case) throughput of inserters taking off belts, but needing to have isolation splitters on all input inserters (especially, and specifically with ore/furnaces; if any inserter down the line of furnaces takes ore off the belt, the whole belt moves, causing all preceding inserters to go active) to allow them to go inactive (and the game run more efficiently), no longer feels like a design challenge, but a design constraint.

A more relevant "why" for me personally though, I can build bigger.

*An important disclaimer though, this suggestion is made reluctantly, as I feel if any suggestion I could make is reasonable, it has already been thought of, considered, and appropriately dismissed for any number of reasons I'm ignorant of. But the possibility of inserters being optimised as well as belts have been is exciting, and I wanted offer my suggestion for the possibility of reconsideration of inserter sleep wakeup lists.

[bobingabout]

I'm not quite sure what you're sugesting.... something to do with the internal behavour of inserters when configured to put items into a machine?

if I understand correctly, well, you can't exactly turn an inserter off when fed from a belt if you're looking for items like you can with chests, because a belt is moving, and constantly changing.

[Dooces]

I'm not quite sure what you're sugesting.... something to do with the internal behavour of splitters when configured to put items into a machine?

if I understand correctly, well, you can't exactly turn an inserter off when fed from a belt if you're looking for items like you can with chests, because a belt is moving, and constantly changing.

Inserters go active when their chest contents change as well, as if they're taking off a moving belt, and what I'm proposing only involves circumstances where inserter's shouldn't be looking for items, as it doesnt matter what it finds, it can never do anything with it (when asm/furnace wont accept ANY item - its full).

[mulark]

Labs also show this issue as well. Namely, when a lab has enough packs such that if any of the packs enters the belt in front of it, none can or will be inserted, but still the inserters will remain active at all times. The active state of the inserter should be linked to the quantity of items waiting to be processed relative to the maximum number insertable. For instance if an inserter won't insert a pack if the quantity of that pack is greater than 1, and all packs inside the lab are quantity greater than 1, inserters pointing into the lab should sleep.

[Stevetrov]

@dooces was kind enough to take the time to explain this to me last night.

And this is the way I see it:

Each inserter has a shopping list of items that the receiver is interested in. Eg In the case of an ASM this will a short list, for a furnace it will be something smeltable or more of what ever it is smelting, for a chest its anything (or if no slots are free stuff to fill partially full slots)

In some instances this list will be empty (chest full, ASM backed up etc.) and in these cases the inserter will still activate when a new item is available even though its not looking for anything.