Give input inserters' sleep priority
Posted: Fri May 18, 2018 12:47 pm
TL;DR
Give input inserters' sleep priority, or have distinct input and output buffers for asms/furnaces.What ?
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: (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.