Allow buffer chests to buffer deconstructed items

[dugen]

TL;DR

Buffer chests should have a minimum and maximum number like personal logistics, not just a minimum number.

What ?

Between the minimum and maximum numbers, the buffer chests should allow deconstructed items to be stored in the chest by construction robots, but not request the logistics system deliver more.

Why ?

Trying to use buffer chests while prototyping can be frustrating if there is a significant distance between where you are working and where your bots decide to store things.

If I'm far from my main storage, placing items down works as expected but when I try and make changes, the construction bots will start carting all my deconstructed items to oldest available storage chest. Then, as all the construction bots I was just using are wandering off taking my valuable parts with them, I'm left without items and even worse without construction bots as I try and keep going. New construction bots come out but they don't stay either, they also wander off leaving me frustrated and angry. With the items I can simply just use really big buffers to solve the problem, but with the bots, there isn't a way to tell them not to wander away or to tell the network to keep a bunch of bots nearby. I have tried various workarounds by creating buffer chests for each item and then automatically pulling one item out into a storage chest so it becomes a prioritized target but it is slow and tedious to set up, requires configuration for each item making changing configurations quite annoying, and it doesn't even do it right. Because bots take from storage chests first, they keep pulling the item out and there is no way to avoid the time gap when that chest is empty and my construction bots abandon me.

A buffer chest with an unsatisfied request is already a valid target for deconstruction, and I was surprised to find the construction bots seem to even prioritize the closest one which is very cool, but to use that I have to disconnect myself from any other storage or supply chests in the network which can provide those items because if any of those exist the logistics network will schedule a delivery and once the pening deliveries satisfy the request the buffer chest is no-longer a valid target for deconstruction. I'm sure there are challenges in how to add this functionality to the robot network but I think it should be possible and I know it would make buffer chests feel much more like buffers.

[ssilk]

I don't understand. Maybe due to the ultry-long sentences.

More seriously: You can turn off your personal logistic requests, there is a switch.

And: I don't understand how this from/to limit should work? What should happen, when there is more than the requested items in the buffer chest?

[eradicator]

+1

I don't understand. Maybe due to the ultry-long sentences. ;)

The one-sentece TL;DR seems quite clear to me. Make decon-bots prefer buffer chests in close proximity instead of storage chests at the other end of the map.

[dugen]

I don't understand. Maybe due to the ultry-long sentences.

I fixed some bad commas to try and make it more legible.

More seriously: You can turn off your personal logistic requests, there is a switch.

What I'm talking about has nothing to do with personal logistics so turning them off has no impact.

And: I don't understand how this from/to limit should work? What should happen, when there is more than the requested items in the buffer chest?

I was not suggesting changing the behavior when there is more than the upper limit, but changing it between the two limits. In that range, it would allow the chest to be a valid target for deconstructed items to be stored by construction robots, but would not actively request the logistics system schedule deliveries of more items. I edited my original post to clarify that. Thanks for the feedback.

[ssilk]

Much better now. So you want a buffer chest that works also as storage chest with a filter. The basic problem is, that this will then eat up twice the CPU-cycles because the game needs to check up not only storage chests, but also the buffer chests. And the rules here are more complex.

How will you explain that complexity:logistic chests are mainly thought for logistic robots, and now you have a new rule for supply chests.

I don’t know. I think this ads so much complexity, as it adds gameplay. I would have problems to understand this slider.

A super simple solution for this situation is - for example - to split your robotic network into more parts. Adds also a lot of gameplay, because everything goes faster then (if provided with enough items).

[dugen]

A super simple solution for this situation is - for example - to split your robotic network into more parts.

And then figure out a way to supply all the pieces to the place you are doing prototyping without having the ability to have robots get them there because it's a different network. That's "simpler" only in that it uses the existing system.

Buffer chests are great at helping to make construction robots efficient, but they only do half the job. They can provide materials for construction, but not a place to store deconstructed materials. This would fix that.

The basic problem is, that this will then eat up twice the CPU-cycles

That seems unlikely. Firstly this would only affect deconstruction which is a user initiated activity that happens rarely and secondly, buffer chests are already valid targets for delivery of deconstructed items, but only when they have an unsatisfied request. They are already being checked.

[ssilk]

And then figure out a way to supply all the pieces to the place you are doing prototyping without having the ability to have robots get them there because it's a different network. That's "simpler" only in that it uses the existing system.

Well, it’s not on me to tell you how to prototype efficiently. You seem to have very fixed ideas about how to do that.
But I throw some more ideas into the ring.

- build your storage chests near that place, where you plan to experiment, or (let’s) move them to that place
- research inventory and use your personal roboport to pick up the items
- use spidertron, car, tank to transport needed items to that place
- use storage chests filters and stack limits to force some items stored near your workplace. Btw. this is from the basic functionality the same suggestion as yours.
- use the edit mode https://wiki.factorio.com/Map_editor
- use mods like https://mods.factorio.com/mod/EditorExtensions
- use mods like https://mods.factorio.com/mod/GhostScanner or https://mods.factorio.com/mod/BlueprintSignals to count the needed number of items to the other network

I could continue a lot more. There are so many solutions to this problem, because it is a core problem in Factorio, that the bots aren’t efficient at longer distances.

Buffer chests are great at helping to make construction robots efficient, but they only do half the job. They can provide materials for construction, but not a place to store deconstructed materials. This would fix that.

Yes,no doubt this will be useful and I would use it. But you remove that part of the game, that is about handling this problem.
Well, I go with this suggestion so far, that it should be tried if it really improves the gameplay, but frankly I’m sceptical.

That comes from the user-interface. When I’m thinking about it, what bugs me most is the slider interface for this. It will be difficult to explain, what this will change. A user will see “oh,when I’m changing the lower border there will be items brought to that chest. Fine.”
But when he/she changes the upper border, nothing happens. It’s not clear that this is not part of the logistic network, but of the construction network. Well you can make two sliders, one orange for the logistic and an orange for construction. Or other UX improvements. But this will be still difficult to understand and use.

That seems unlikely. Firstly this would only affect deconstruction which is a user initiated activity that happens rarely and secondly, buffer chests are already valid targets for delivery of deconstructed items, but only when they have an unsatisfied request. They are already being checked.

Yes, you’re right.

[eradicator]

- build your storage chests near that place, where you plan to experiment, or (let’s) move them to that place

Compromising base-wide storage just to get easier prototyping is... quite inefficient.

- use spidertron, car, tank to transport needed items to that place

Hm... spidy already has support for player-like logistic requests and conbots. So while ugly it could serve as a quasi-buffer-chest for prototyping. Power supply isn't gonna be great though.

___
Personally I just got used to ghost-only prototyping in an area where the bots never go. One just has to get used to the required build+copy+remove of assemblers to set recipes on ghosts. Has the added benefit of being able to instantly move large parts of a build by a few tiles left/right/up/down via cut+paste. As it's in a remote location I go there by teleport thought because otherwise it would waste too much time on travelling back-and-forth.

[NotRexButCaesar]

+1: this makes sense to me.

[boskid]

I am not sure how are all the internals of logistic network implemented, but i know that having double slider for the "max value" requires an entity to work as 2 logistic members: requester for requesting stuff that is below given value, and as an active provided to get rid of stuff that are above of the max value. Active provider member is based on a trash slots. If there would be a decision to make a buffer chest to have double slider for the "request below, trash above", it would immediately make it to need a trash slots which would work as an additional chest inventory which is a clear no-go (or at least a really ugly solution). Other solution would most likely require large scale changes of the logistic network code to be able to work with single logistic member with active provider only above certain values which is not going to happen, at least not in 1.1.x. There are also other issues to solve, like the buffer chest would no longer internally work as an requester chest because then it would be unable to store more items than request threshold. For this it would need to also work as an storage chest with filter for multiple items assuming given items are within limit and stop working as a storage chest when a cap was reached. Because of this i am almost certain that this wont be implemented ever.

[ssilk]

I see it similarly, it would be a massive change of the logistic network with questionable outcome, because it shifts the balance of the storage- to buffer chests, making storage chests suddenly much less useful, because buffer chests then would have filters for many items instead only one. The fact that the buffer chest would take the deconstructed is only the half truth, it would then take back also the items from active providers. Changing that is part of the massive change, which also increases effort of implementation.

And after thinking a little I mean it might be possible to build something, that does a similar/equivalent job only by existing Factorio entities. Some combinator magic that tries to keep number of items in an area of storage/buffer chests at a minimum level by using requester chests or something like that. And as said, there are many other strategies that could go around or minimize this issue.

So moved to won’t implement.