Should Construction Robots Prioritze Storage Chests ?

[TheRailmaker]

I just saw, that Construction bots don't prioritze buildings from storage chests before passive provider chests.

Should they ? We all know that logistic bots prioritze them, what is great. Wouldnt it be nice, if buildings like belts/inserters or even reactors staying in the storage chests would also be prioritzed ?
It could take a bit longer, but only till the storage chests dont have any building left. So this shouldnt be a big deal. But it would assure, storage chests dont run full, if you deconstructing /moving big building blocks like walls or belts multible times.

[FuryoftheStars]

If this is indeed true, I would agree. Storage should be prioritized (for both) so that these are emptied before taking from passive providers.

[Koub]

But it would assure, storage chests dont run full, if you deconstructing /moving big building blocks like walls or belts multible times.

You could also read the logistic network, and enable/disable your infrastructure building assembling machines (or rather the inserters feeding them) if the logistic storage is over a certain threshold. You would still not be able to deconstruct more than your storage's size, but you wouldn't build more until all that was deconstructed is used again.

[TheRailmaker]

You could also read the logistic network, and enable/disable your infrastructure building assembling machines (or rather the inserters feeding them) if the logistic storage is over a certain threshold. You would still not be able to deconstruct more than your storage's size, but you wouldn't build more until all that was deconstructed is used again.

I know, that there are some options to work around, but i ask, if they are neccecarry. Logistic bots try to empty storage chests first, so why not Construction bots. I can't immagine a Scenario, where you want Bots, not to take from storage first, cause those chests work like a buffer for all items at once anyway.

[posila]

Currently, construction bots try to find the chest that is the closest to the ghost they want to rebuild.

Idea is, that players want to bluprints to be built fast, so construction robots shouldn't travel over large distances (system that manages this is still pretty simple, though, so it's not that great) ... and you can use buffer chests to make logistic bots bring items closer to the construction site and construction bots will use the closest chest.

[jodokus31]

Some people use buffer chests as output for a construction assembly and request that specific item with a high number. This way all items of that type are delivered back, if the chest is big enough

[TheRailmaker]

Currently, construction bots try to find the chest that is the closest to the ghost they want to rebuild.

Idea is, that players want to bluprints to be built fast, so construction robots shouldn't travel over large distances (system that manages this is still pretty simple, though, so it's not that great) ... and you can use buffer chests to make logistic bots bring items closer to the construction site and construction bots will use the closest chest.

you could also use buffer chests with storage prioryty. seprate networks or just wait till the storage is emty (what should be fast anyway)

Do you think more people profit from the shorter distance while building, compared to the work, using logic, to keep the storage clean ?

[jodokus31]

Do you think more people profit from the shorter distance while building, compared to the work, using logic, to keep the storage clean ?

I guess it depends, what you mean with keeping the storage clean. Do you keep filling and overflooding it, while producing more items in the mall area?
Otherwise, it's just a preference, that you sometimes have "some" building items in the storage.

f.e. you deconstruct 2000 walls which are now in storage and you have your wall producer with 500 pieces in a red chest.
Now you build another wall and the bots take from the red chest because it's nearer. After the red chest is empty they take from the storage.
The question is now, what does the wall producer assembly do? It should not produce more, because there are enough in the network. Otherwise you might flood your network. Then after the storage amount goes down to 500, the wall producer gets active and produce again. The bots now take those from the red chest again. So 500 walls in storage might remain untouched, while the wall producer produces more. Slightly annoying...

I can see, that it could be nice, that bots take from storage first, but I think the effect is minor. The only annoyance might be, that a certain amount of building items remain in storage

[posila]

Do you think more people profit from the shorter distance while building, compared to the work, using logic, to keep the storage clean ?

Well, I think bots traveling shorter distance is generally good, as it makes blueprints being built faster and consumes less electricity on bot recharging, so it affects the pace of the game. And I think keeping the storage clean is not gameplay mechanic but preference some players have and is completely optional.

[Abarel]

In short, I prefer bots using nearest box.

If you like simplicity, some huge amounts of stuff stored in yellow boxes and big swarms of bots flying everywhere in a giant bot network should not be a problem for you.

If you love organization, maybe you are comfortable using separated bot networks, one for the mall, one for each outpost, and using trains and/or any modded way to deliver stuff from mall to each outpost. Items from deconstructions could also be delivered back to the mall/storage, and treated accordingly.
I prefer using buffer box (green box), on both the output from mall and the central storage if any (and just a few yellow boxes for these item types I didn't set a buffer chest), for most item types, specially the items that can be used as ingredient to craft higher tier ones (don't forget to set requesting also from buffer boxes); to limit production depending on available items, my preferred way is to set conditions reading contents from the local logistic network. I usually apply limits on the ingredient input, by wiring request boxes if bot based, or wiring inserters if fed by belts.

[Qon]

Some people use buffer chests as output for a construction assembly and request that specific item with a high number. This way all items of that type are delivered back, if the chest is big enough

Filtered storage chests is lower tech and achieves similar result. Bots prioritize filling filtered storage chests over unfiltered storage chests. It doesn't pull from general storage to the filtered output storage chest so not exactly the same, but in many cases this works well enough for me.

[JimBarracus]

If you want to priotize storage chests you can use active provider chests.

Active provider chests are usually empty.
Produced amounts are controlled by the inserter removing the produced item from the assembler.

[FuryoftheStars]

If you want to priotize storage chests you can use active provider chests.

Active provider chests are usually empty.
Produced amounts are controlled by the inserter removing the produced item from the assembler.

I feel like this is prioritizing putting to storage vs taking from?

[jodokus31]

If you want to priotize storage chests you can use active provider chests.

Active provider chests are usually empty.
Produced amounts are controlled by the inserter removing the produced item from the assembler.

I feel like this is prioritizing putting to storage vs taking from?

I used it extensively in my seablock brave new world attempt.
You can place storage chests as input for the main crafting assemblers (you can't handcraft in brave new world) and with the active providers you throw items in the network and the storage chests collect everything. It's easier than to set requests for everything you need on blue chests.

Basically it's nice, if you want have everything more or less central. and with filters, you can decide, where the specific items go.

[JimBarracus]

I feel like this is prioritizing putting to storage vs taking from?

In the first step yes.
Active provider chests are usually empty or close to empty.
Bulk storage happens in storage chests.

Priotizing storage chests means that everything is in storage chests. Construction bots have to take items from storage chests, there are no passive provider chests at the mall, or elsewhere.
They cant skip items in storage chests because their highest priority are the storage chests.

Problem solved.

[FuryoftheStars]

So, essentially, what I'm getting from everyone's suggestions on alternate workarounds is if one wants to avoid bots not taking from storage/make them take from storage first, is you would need to:

1. Put everything to storage, essentially meaning you can only use one chest type (active provider) at the factory output and, you know, still putting things to storage that you don't want there, or
2. Put and set up buffer chests prior to a construction job, requiring manual setup or stamping of a universal blueprint that could potentially call more (or less) than what you want for the job, then wait for logistic bots to fill them up (or at least pull enough from storage that they can finish cleaning out storage before the con bots use up everything in the buffers) before you can even stamp the actual blueprint, or
3. Configure every factory output inserter that makes a final/buildable product that would go to a logistic chest to disable if contents of the logistic network as a whole are "too full". Which wouldn't guarantee emptying storage, either, considering once the total cumulative amount of the product dips below a certain level, the factory will automatically start outputting again, which, of course, means the con bots will start taking from there instead of storage again, or
4. Use buffer chests (or filtered storage) as the output chests from the factory for buildable entities, having the same affect as option 1 in that you're only able to use one chest type there, though at least in the case of the buffer chests does mean storage will be kept empty, but this also means that everything will always be at the factory (always traveling long distance)
   
   Does that about sum it up? Because those seem like some crappy options to me (and maybe that's just me, but that's my opinion). :/
   
   ---------------------------
   Edited #3 based on better understanding. Still don't like it.

[jodokus31]

So, essentially, what I'm getting from everyone's suggestions on alternate workarounds is if one wants to avoid bots not taking from storage/make them take from storage first

Construction bots take from the nearest source, because it's designed like that. If you want bots to take from the storage first, you have to ensure, that either storage is empty or storage is nearest. That results in those clunky solutions.

But you also should consider to change the goal. Current goal is:
Storage should be used first before taking from other source and before producing more. Building can be slowed down as long you have items in storage.
Changed goal:
Storage should be used before producing more (except a certain residual). Building should be as fast as possible.

[SoShootMe]

Does that about sum it up? Because those seem like some crappy options to me (and maybe that's just me, but that's my opinion). :/

They seem like crappy options to me too. I guess (like always) it depends on your setup but instead of seeing the problem as construction robots taking items from passive provider chests rather than storage chests, you can see it as being the resulting unwanted production if/when that occurs. Koub's suggestion of reading the logistic network to disable the inserters that fill output chests with construction items when you have "enough" (rather than eg limiting the output chests) addresses that.

If you want all your construction materials kept in a certain area, you can place (optionally filtered) storage chests there and use active instead of passive provider chests for the assembling machine output, with the same inserter control.

(As I go to post this, I see...)

Current goal is:
Storage should be used first before taking from other source and before producing more. Building can be slowed down as long you have items in storage.
Changed goal:
Storage should be used before producing more (except a certain residual). Building should be as fast as possible.

The latter is exactly what Koub's suggestion achieves.

[FuryoftheStars]

Construction bots take from the nearest source, because it's designed like that.

Yes, posila's post makes that clear.

If you want bots to take from the storage first, you have to ensure, that either storage is empty or storage is nearest. That results in those clunky solutions.

(emphasis mine)
Which is why the OP made this thread, and I'm in support of their idea.

But you also should consider to change the goal. Current goal is:
Storage should be used first before taking from other source and before producing more. Building can be slowed down as long you have items in storage.
Changed goal:
Storage should be used before producing more (except a certain residual). Building should be as fast as possible.

Except I'm ok with the "current goal" whereas the "changed goal" is exactly the "clunky options" I don't like? I mean, provided I don't have hundreds or thousands of what I'm building all in storage, once it's cleaned out, building then follows normal priority, so it shouldn't slow things down that long. And the "changed goal" is just a way of forcing it take from storage by letting the primary sources run out, which means it goes "slow" anyways.

Koub's suggestion of reading the logistic network to disable the inserters that fill output chests with construction items when you have "enough" (rather than eg limiting the output chests) addresses that.

Yeah, if I understood Koub's post correctly, their suggestion falls in on #3 from my previous post.

[SoShootMe]

Koub's suggestion of reading the logistic network to disable the inserters that fill output chests with construction items when you have "enough" (rather than eg limiting the output chests) addresses that.

Yeah, if I understood Koub's post correctly, their suggestion falls in on #3 from my previous post.

Yes, it's functionally equivalent to your #3, except there's no circuit wire everywhere. You stressed the latter so infer that is a significant aspect of what makes it "clunky" to you, but it is not a necessary part. The only downside I see is the need to configure the inserters, which I think is much more fiddly and (therefore) error prone than limiting a chest. Do you see more or something else, or do you think it is just weighting (ultimately, opinion)?