Construction bots pickup preference

[Stimpatch]

TL;DR

Construction bots should / could use items from storage chests first, like logibots do

What ?

Logistic bots use a pretty clear priority system for item pickup. Quote from Wiki:

Logistic robots will pick up items in the following priority: active provider chests > storage chests > buffer chests > passive provider chests

Construction bots do not. The only care (afaik, the wiki does have no additional information here) for distance to the possible pickup targets. It ould be nice if that would change to a similar pattern the player can kind of predict or use to his advantage.

Why ?

But why? Distance to pickup is not forseeable for the player... and worse, it can lead to clutter in the network when items get moved around by the player. But thats no problem you say. all Items will be used up eventually. Sadly thats not ensured.

Lets construct a case:

I defend my base with gun turrets from biters from the west. To automate my defense, i have set up a blueprint i plop down a few times, the construction bots go out and place the gun turrets for me. They get the turrest from the factory in the middle of the base, where they are produced at a limit of one stack in my provider chest.

Later, i move out to mop the enemy up. For now, the west is safe so i deconstruct the defense with bots. Oh, wait, the bots need a storage option to store stuff in, okay, plop down a storage chest in the west.

2 Minutes later i see a thread in the east. Okay, put some blueprints down there. The gun turrets get placed, and boom, now there may be up to 50 more turrets in the network. Because the old turrets are in a storage chest far in the west, construct pickup nearest... if they are still in the west wing, they may get the old turrets, if they are in the east, they pickup from the passive provider chest.

The increase of items in the network is not forseeable.

And no, i am completly aware that there are ingame solutions to this. From circuit-limitiations to requester chests to filtered storage... yes, you can work your way around the problem. The thing is... all these solutions in the end are either focused on bringing the existing items from the network back to the central provider chest OR prevent the factory from creating more new items while there are items in the network. So, in a way they both enforce (kind of, from my point of view) the behaviour logistic bots already have.

Your opinions pls.

[Theikkru]

My opinion is: not necessary and sometimes counterproductive. Construction bots exist to build things as fast as possible, because most of the time the player wants that blueprint built ASAP. In your example, if you find a threat on the east side, and construction bots are going all the way to the west to find that box of turrets you left behind, they could easily take too long to build the blueprint; the biters could catch you with your defenses half-built and eat everything. Construction bots don't bother with the same logistics priorities because that isn't their job. That's what logistics bots are for. If you don't like leaving random boxes of materials around, set up your logistics to recycle everything properly. If you can't be bothered, then just produce extra and leave the boxes lying around.

[ssilk]

That’s basically why buffer chests exists. Place buffer chest where you eventually may need support, and remove them, where you don’t and you have an implicit, self-configurated pickup preference.

[ickputzdirwech]

Boskid wrote the following in the discussion of this bug report (duplicate and not a bug) with the same request:

Current solution is good for what construction bots are designed to do so it is not going to change.

I therefore suggest moving this topic to Outdated/Not implemented.

On topic: I agree with boskid, Theikkru and ssilk. I want construction robots to build something as fast as possible. If you want to recycle deconstructed items, there are plenty of ways to achieve this (see the thread linked above for an explanation on how I do it).

[ssilk]

moved to not implement — ssilk
Reasons explained above...