Requster / Buffer / Provider chest combination

[mrvn]

TL;DR

There should be a chest that combines the requester, buffer and provider chest.

What ?

I'm asking for a generic logistic chest that mimics and slightly extends what the personal logistic (request / auto-trash) allows but for chests.

request-chest-plus.png (250.06 KiB) Viewed 532 times

The chest should allow reading the content alongside it's other functions as this is often required. It should also allow setting requests, provides and trash values either manually or via circuit wires. For the content output and each of the 3 inputs there should be a choice which wire color is to be used. This would allow for example reading the content on the green wire while setting the request on the red wire.

Manually setting values has 3 sliders (values set via circuit logic are ignored). The left slider sets the request value. If fewer items are in the chest then the difference is requested from the logistic network. The middle slider sets the provider value. If more items are in the chest then items are passively provided to the logistic network for pickup. The right slider sets the trash value. If more items are in the chest the excess items are actively provided to the logistic network, they get remove into other storage.

Another feature is the request priority. A chest can request items from other chests that have a lower priority. A chest with low priority acts like a buffer chest with the requester set to use buffer chests. Except now this allows many levels so rings of chests can be placed around the base where each acts as buffer to the outer rings.

A value of X/inf/inf with high priority would make the chest a requester chest, a buffer chest with low priority. A value of 0/0/0 makes the chest a active provider chest. A value of 0/X/inf makes the chest a passive provider chest. Other combinations have even more useful effects.

Given that there is only a red and a green wire not all values can be set independently. But that is life. You can pick different functions of the chest by selecting which colors match. Setting only request and provides via circuit wires and setting the trash value manually or similar should also be an option. This gives the most flexibility.

Construction bots:

I haven't included anything about construction bots in my mockup because I only considered them afterwards. My first thought was that construction bots should always take items out of the chest. But then maybe you don't want that. A simple "Allow construction bost" checkmark would be an option there.

SLightly more complex there could be a pulldown menu to select if construction bots are allowed to take items: Never / Above Requests / Above Provides / Above trash.

There could also be a 4th value for each item to set the construction limit. If more items than the construction limit are in the chest then construction bots can take some out of it. This would also be a better fit to be controllable via circuit logic. But wouldn't fit nicely into the scroll bar for manual input.

Storage chest:

Also not included in the mockup. I think there should be a checkmark "Allow item storage". If enabled then up to the trash value number of items can be stored in the chest. This would finally allow storage chests with multiple filters. Or allow items to be returned to provider chests by construction bots when a ghost is removed.

Note: Not all features used at the same time are mend to be meaningful. For example reading the content on green and setting requests on green will probably set the request to the content + whatever is on the green wire resulting in the value getting larger every time something is added to the chest. This is intentional. Not every combination has to make sense.

Why ?

When the personal request slots and auto trash slots got merged this was a great quality of live improvement. One frequently want's some but not too many items. The same can be said for logistic chests.

A circuit controlled requester chest will request items. When the signals change those items still arrive and remain in the chest and might not be of any use anymore. Getting rid of now unneeded items is possible with more circuit logic and active/passive provider chests. But it's a pain to do so every time. Setting the provider/trash limit for the new chest would make this easy.

I also often want logistic chests as buffer between assembler, specifically the belts and inserters come to mind. There should always be some transport belts buffered for the construction bots. Excess belts can be used to build underground belts or fast transport belts. This can be done with a simple wire to the inserter. Construction bots should be allowed to take transport belts out of the chest. But there is no way to prevent construction bots from draining the chest empty. The above construction value would allow setting a minimum number of transport belt left in the chest. That way undergound belts and fast transport belts can still be build parallel to constructing yellow belts. Deconstructing transport belts or removing ghosts should return the belts to the chest so they can be reused to make fast transport belts. This requires the chest to be a storage chest with a filter and limits it to one item per chest. I often put pipes and underground pipes in the same chest. With the new chest both pipes and underground pipes could be returned to the same chest.

The buffer chest is mostly useless in the game. If it is too near to the base then construction bots take forever to take items out of it and they hardly increase the construction speed. If they are too far from the main base then the logistic bots take forever to fill them with items and again their use to speed up construction is nearly zero. It's impossible to set up a sequence of buffer chests that each move items along for a short distance. The new priority setting gives more control over where items are sourced from and allows setting up a chain of resupply depots where each supplies chests with higher priority.

There are probably a million more use cases.

PS: a chests could have more wire terminals allowing for more wires to choose as input / output option. Probably something for a 2x2 chest.

[Illiander42]

So, buffer chests?

[mrvn]

So, buffer chests?

That's one use of the combined chests. But it's so much more.

[Illiander42]

Buffer chests are the combo requester/provider chest.

So you're asking for a combo requester/requester/provider/provider chest. Ie, a combo buffer/buffer chest.

Or...

A buffer chest.

[mmmPI]

Given that there is only a red and a green wire not all values can be set independently. But that is life.

PS: a chests could have more wire terminals allowing for more wires to choose as input / output option. Probably something for a 2x2 chest.

Aren't those two conflicting descriptions of what is being suggested ?

[mrvn]

Buffer chests are the combo requester/provider chest.

So you're asking for a combo requester/requester/provider/provider chest. Ie, a combo buffer/buffer chest.

Or...

A buffer chest.

No, I'm asking for much more. The effect of a buffer chest is just one of the modes the combined chest can be in. For example a buffer chest won't actively provide (i.e. trash) items above some limit.

[PennyJim]

I think this would be a nice thing to have, in a mod. I personally hope it doesn't get implemented in the base game; I feel like it very slightly trivializes some bot logistics, when bots themselves already trivialize many things.

I also don't think your imagined plan for a 3 number slider would be very practical to use. I think that it would be better if it just functioned as a buffer chest with an upper limit that gets discarded actively.
And setting the lower and upper bounds separately with circuits makes no practical sense implementation wise. Maybe you can have it be a condition that saves all the signal values as its upper or lower bound when true (like a set signal), but that's pretty different than any other circuit connection I've seen.

I don't know how possible that is with the current api, so maybe some additions need to be added to be able to do it (without a dose of jank), but I don't think it fits un-modded and therefore seems unlikely they'll introduce api functions specifically for this use case.

[mrvn]

I think this would be a nice thing to have, in a mod. I personally hope it doesn't get implemented in the base game; I feel like it very slightly trivializes some bot logistics, when bots themselves already trivialize many things.

I also don't think your imagined plan for a 3 number slider would be very practical to use. I think that it would be better if it just functioned as a buffer chest with an upper limit that gets discarded actively.
And setting the lower and upper bounds separately with circuits makes no practical sense implementation wise. Maybe you can have it be a condition that saves all the signal values as its upper or lower bound when true (like a set signal), but that's pretty different than any other circuit connection I've seen.

I don't know how possible that is with the current api, so maybe some additions need to be added to be able to do it (without a dose of jank), but I don't think it fits un-modded and therefore seems unlikely they'll introduce api functions specifically for this use case.

I don't see a big problem with the 3 number slider. The config of the chest is three numbers A <= B <= C which fits those sliders nicely. If you move C below B then B moves as well just like in the 2 number slider case. The only problem is that with A=B or B=C the B slider would get squished on one side. With A=B=C the middle slider would be 0 size and impossible to pick up. But well, move A or C out of the way first and then you can pick up B again. Or edit the numbers directly.

You can not mod this. This would require having a requester or buffer chest alongside a active provider chest and LUA code to scan it every few ticks and transfere items between the two chests. That would quickly burn out your CPU. Inserters would also have problems picking up items because they would only use one of the chests. And the requester priority isn't possible to do at all as that would require programming your own bot logic in LUA.

[Illiander42]

Could you give a blueprint of something that does this using requester, buffer and active provider chests?

Might make it more clear what you're actually after.

[FuryoftheStars]

I'd be curious to know if adding this would make the others obsolete, and if not, what unique functions would be retained by the originals.

[mrvn]

Could you give a blueprint of something that does this using requester, buffer and active provider chests?

Might make it more clear what you're actually after.

No, I can't. It's impossible to do the things in this idea with existing chests. You can approximate the functionality but not match it.

For example a trash chest:

trash-chest.png (27.44 KiB) Viewed 294 times

The buffer chest will request some iron plates. And if too many end up in the chest they are moved to the active provider chest to get rid of them. But now items are spread over two chests, inserters can't take from both. Items taken out of the buffer chest disappear from the logistics inventory until they are put back in the active provider chest. And it only works for one item. For 2 or more items you need combinators to calculate what to take out yourself.

Or this example:

buffer-chest-chain.png (30.63 KiB) Viewed 294 times

There is a storage chest on the left and a chain of buffer chests leading to a requester chest. Now the idea would be that when the requester chest needs something it takes it from the buffer chest next to it. For that there is a checkmark in the UI. But then the buffer chest should get refilled from the buffer chest before that, which in turn refills from the one before that and so on.

The logistic robots then all only have to fly a short distance between adjacent chests. Instead in the game now only the last buffer chest is used and the logistic bots have to fly all the way to the storage chest and back to the last buffer chest to refill it.

I'd be curious to know if adding this would make the others obsolete, and if not, what unique functions would be retained by the originals.

Depending on the implementation the combined chest could replace all others. But you would have to configure a more parameters to mimic the other chest. I would also expect it to have a higher tech requirement. So you get storage and provider chests first and only later you get the all powerfull combined chest.

There could be unique functions only the original has. For example construction bots never take something out of a requester chest while the combined chest could be implemented to always allow construction bot access like a buffer chest. It all depends on how much the combined chest is made to be an universal chest that can be fine tuned by the user to any function. If only a subset of functions is tunable then the original chests retain unique features. And will still be simpler to put down a requester chest if all you ever need is request items. No need for a cluttered UI if you only want that subset of features.

[Illiander42]

Depending on the implementation the combined chest could replace all others.

Ahh, I get it now. You want LTN, but with logi bots instead of trains.