Missing combinations for logistics chests

[lightdark]

I realised that the logistic chests form a sort of table, and not every cell in the table is filled in.

Essentially, chests are set up so that chests can be both filled and emptied, either passively or actively. This essentially gives us 9 options for logistics chests:

1. Actively fill, actively empty
2. Actively fill, passively empty (buffer chest)
3. Actively fill, don't empty (requester chest)
4. Passively fill, actively empty
5. Passively fill, passively empty (storage chest)
6. Passively fill, don't empty
7. Don't fill, actively empty (active provider chest)
8. Don't fill, passively empty (passive provider chest)
9. Don't fill, don't empty (steel chest)

Notice how #1, #4, and #6 don't exist, but maybe could.

#6 is a "recycler" chest, or passive requester chest. Basically, the bots won't go out of their way to move things into these chests, but they will be preferred over storage chests. Maybe you could filter each individual slot of these chests like you can with cars and cargo wagons. These would be useful for recycling materials back into machines in the factory, rather than requester chests.

#4 is an "overflow" chest, or "active" storage chest. and could be useful for when the bots are overworked. Specifically when there are no available bots of a given type, bots of that type can drop their items in the nearest overflow chest to free up their inventories. One example of this would be for when construction bots are deconstructing large structures; they could simply move the items to the overflow chests first and then logistics robots could take those items away. This would also be useful when there aren't enough bots to take all of a player's trash; they could dump the items into an overflow chest first and then take them away from there.

One other way of thinking of overflow chests is that they act like storage chests when bots aren't available and active provider chests when the bots are available.

#1 doesn't really seem like anything that would work, but maybe I'm just not thinking hard enough. I thought of it like an active buffer chest, but that really doesn't make much sense to me.

[DaleStan]

I'm not opposed to these chests in principle, but some of your descriptions make me think you're actually requesting chests with variable priorities, not chests that fill the missing slots.

#6 is a "recycler" chest, or passive requester chest. Basically, the bots won't go out of their way to move things into these chests, but they will be preferred over storage chests.

Thoughts: As I read your list of chests, a bot trying to decide where to unload should, in the absence of active requesters (#1, buffer, or requester) look for the closest passive requester chest, regardless of whether it's storage or recycler chest, and unload there. If the bot should unload to a further recycler rather than a closer storage chest, then you've introduced at fourth request priority. (For now, I'm ignoring the "take items to a chest that already has them" feature.)

Implementation in vanilla: I'm not coming up with a good way to implement this with the tools the game already gives us. You could turn a requester on or off by pairing it up a steel chest, and using inserters to move things back and forth between the chests, but I don't know what circuit conditions you would read to determine if you wanted the requster on or off. (Maybe the bot usage, as below?) Also, if other buildings take enough items out of the system that the steel chest runs empty, you lose the ability to turn the requester off.

#4 is an "overflow" chest, or "active" storage chest. and could be useful for when the bots are overworked. Specifically when there are no available bots of a given type, bots of that type can drop their items in the nearest overflow chest to free up their inventories.

Thoughts: Based on the list, overflow chest loading should work exactly like recycler and storage chests — closest chest wins. But the description here says that the overflow chest should change its behavior depending on how many bots are available in the network; requesting aggressively when most bots are in use, and not requesting when most bots are idle. If the provide priority does not change based on the bot usage, a bot that just unloaded will ask "Where is the nearest active provider?" The player's trash slots are active providers, but so is the overflow chest. Since the bot just delivered there, that's the closest provider, and the bot will pick up its delivery and take it elsewhere, instead of returning to the player.

Implementation in vanilla: If you're looking for passive-request, variable-provide chest, you can achieve this with a storage chest, a circuit-controlled inserter, and an active provider chest. Hook the inserter up to a roboport, probably via a combinator, and move items from the storage to provider if, say, (total logistic bots)/(available logistic bots + 1) < 5. In this example, the chests will only empty if network usage is less than 80%. You could also use count of free bots, instead of percent of free bots.

#1 doesn't really seem like anything that would work, but maybe I'm just not thinking hard enough.

Thoughts: I could make this work if it works like a requester or buffer set to "exactly", rather than "at least". It would actively request items if less than the target, and actively provide items if more than the target. I haven't come up with a definitely good use for this, but I can imagine it being useful for some of the semi-waste products in Angel's, such as mud.

Implementation in vanilla: As above, this could be implemented with a requester, a circuit-controlled inserter, and an active provider. Turn on the inserter if the requester overfills, and set the hand size to the overfill amount. If the requester requests multiple items, you need a filter inserter with a variable filter. I don't know how to set the hand size optimally in that case, but just clamping the hand size to 1 would probably do the trick.