blueprinting and deconstruction order of operations and options

[coffee_fiend]

TL;DR

When placing a blueprint, have bots prioritize deconstructing first then placing buildings

What ?

When placing a blueprint, have bots prioritize deconstructing first then placing buildings.
When you place most blueprints over uncleared areas, many or most of the bots try to place items before clearing the area.
This results in slower construction because many or sometimes a majority of bots sit there and do nothing but wait for the few remaining bots to get around to finally clearing the natural item blocking placement.
I don't think I've ever had a situation where all bots were occupied trying to place things in blocked locations, but I have seen it where most bots were doing so.
The simplest solution seems like bots should prioritize deconstruction first before even trying to place items.
Even better might be if certain items were given a higher priority after deconstructions like power sources and roboports.

Why ?

To speed up building
And so we don't end up in situations where most or all bots are trying to place items and waiting for someone else to first deconstruct the item blocking construction.

[mrvn]

Probably not possible the way the devs have described how bots work in the past. From memory they have a single big list of ghost entities and deconstruction jobs. Every tick one item in the list is looked at. If a bot is free (and the item to build the entity is available) the bot is tasked to that job. Otherwise nothing happens and next tick the next item is looked at.

So they don't even know if there are any deconstruction jobs to be done.

My suggestion would be that if a bot gets tasked with placing an entity but that collides with a deconstruction job then it should just do the deconstruction instead. It wouldn't be so much an ordering of all deconstructions before construction but more a case by case reordering on the fly.

[SoShootMe]

Probably not possible the way the devs have described how bots work in the past. From memory they have a single big list of ghost entities and deconstruction jobs. Every tick one item in the list is looked at. If a bot is free (and the item to build the entity is available) the bot is tasked to that job. Otherwise nothing happens and next tick the next item is looked at.

So they don't even know if there are any deconstruction jobs to be done.

My suggestion would be that if a bot gets tasked with placing an entity but that collides with a deconstruction job then it should just do the deconstruction instead. It wouldn't be so much an ordering of all deconstructions before construction but more a case by case reordering on the fly.

I think your suggestion of "deconstruct instead" would work better than absolute priority to deconstruction.

If there is a "single big list of ... jobs" like you described, it might also be useful if when a bot is ordered to deconstruct instead, the same construction job is considered next time. With sufficient bots, this would quickly order additional bots to complete all necessary deconstruction, and finally a bot to do the construction.

There is a possible (but admittedly unlikely in practice) deadlock if a bot is allocated to a construction job before bots have been allocated to all colliding deconstruction jobs. The simplest demonstration: place a roboport and storage chest, add one bot and an assembling machine, then place a ghost assembling machine overlapping a cliff. The bot will be dispatched to construct the assembling machine but wait forever, even if cliff explosives become available later.

Having written that, I realise there's a similar deadlock with needing space for wood after chopping trees. Short of reserving space (probably impractical) this can't be guaranteed to be avoided but why order a bot to chop a tree when (at that time) there's nowhere to put the logs afterwards?

[mrvn]

The way it would work without repeating the entity is that once per loop through a bot would get tasked to construct the entity, find there is something in the way and deconstruct that instead (unless there already is a bot tasked for it). But would that be so bad?

Remember all the jobs are in one big list. Say the entity is blocked by a tree. The first bot gets retasked to chop the tree leaving some wood behind. The next loop through the list the bot potentially gets retasked again to collect a wood. But that is where it stops usually. Because before the list comes around to the entity again the remaining woods will have been processed and bots dispatched. Assuming there are free bots.

If you don't have enough bots then possibly every time the entity comes around the bot gets retasked. But hey, if all your bots are busy then things will take time no matter what. It will be just bad luck a bot happens to be free whenever the entity comes around. Will be totally random if the wood gets picked up first or the entity tried again. Either way a wood gets picked up till the entity can be build.

Note: When deconstructing a chest I think the chest will get a bot assigned every tick until there are enough bots to pick up all the contents. So maybe there is precedence for trying a ghost again when it can't be handled directly.

[SoShootMe]

The way it would work without repeating the entity is that once per loop through a bot would get tasked to construct the entity, find there is something in the way and deconstruct that instead (unless there already is a bot tasked for it). But would that be so bad?

My thinking was that by not advancing through the list you effectively increase the priority of deconstruction needed before construction relative to other deconstruction, and therefore get construction completed sooner. This is partly due to "once per loop" which seemed to disadvantage blocked construction, but reading the rest of what you wrote I'm doubting the benefit.

The important thing is (per your first post) to avoid bots taking construction jobs before deconstruction jobs that block them, because whenever that happens it can result in bots being unavailable but doing nothing (ie, wasting time). As long as that is the case, the order of jobs doesn't change the total time to do all jobs, ignoring construction that changes bot behaviour (eg roboports, poles, buffer/storage chests).

[mrvn]

It might be that the original thinking was based on a few assumptions like:

- you have enough bots. Come on, you automate bot production and flood the system with bots over time.
- construction and deconstruction will be scheduled far quicker than bots travel. Even 600 ghosts take just 10s to process but bots will take far longer to reach the area.
- construction will have to take a detour to fetch the item to place the entity, it will arrive later then deconstruction.

So by the time the construction has to happen the deconstruction will be finished anyway, no need to design anything for it.


Obviously that doesn't work. The most obvious thing being trees leaving wood around when deconstructed, requiring a second wave of bots being send.

Which brings me to the point of my post actually. Even the clever algorithm(s) above won't help with trees and stones. Because the wood/stone that is in the way of construction won't exist untill the deconstruction bot arrives. By that time the construction bot has probably been send too. It will then have to wait for additional deconstruction bots to arrive. Depending on the distance from the nearest construction bot that can take a long time. Especially because all the nearest bots will already have been tasked for the original deconstruction and construction jobs.

So I think what needs to be added is a little forsight. The game knows that deconstructing a tree or stone results in extra items. Like with chests it should send enough deconstruction bots to the tree to deconstruct it and collect all the items it produces.

[Qon]

Obviously that doesn't work. The most obvious thing being trees leaving wood around when deconstructed, requiring a second wave of bots being send.

Wrong. The deconstructing bots picks up the wood, like any other regular entity deconstruction.

[mrvn]

Obviously that doesn't work. The most obvious thing being trees leaving wood around when deconstructed, requiring a second wave of bots being send.

Wrong. The deconstructing bots picks up the wood, like any other regular entity deconstruction.

Except the one bot send to the tree can't carry all that wood.

[Qon]

Wrong. The deconstructing bots picks up the wood, like any other regular entity deconstruction.

Except the one bot send to the tree can't carry all that wood.

Ah, you are talking about unupgraded bots that can't carry all of it. Oki. Fully upgraded bots can carry 4 wood.

[NotRexButCaesar]

Wrong. The deconstructing bots picks up the wood, like any other regular entity deconstruction.

Except the one bot send to the tree can't carry all that wood.

Ah, you are talking about unupgraded bots that can't carry all of it. Oki. Fully upgraded bots can carry 4 wood.

Maybe dropped items should be auto marked for deconstruction.

[mrvn]

Wrong. The deconstructing bots picks up the wood, like any other regular entity deconstruction.

Except the one bot send to the tree can't carry all that wood.

Ah, you are talking about unupgraded bots that can't carry all of it. Oki. Fully upgraded bots can carry 4 wood.

Maybe dropped items should be auto marked for deconstruction.

They are. The problem is the time it takes for new bots to be dispatched to pick them up and for them to arrive to do so. All that time the bot trying to construct the entity has to wait and ocasionally even flies back to recharge.

[SoShootMe]

Wrong. The deconstructing bots picks up the wood, like any other regular entity deconstruction.

Except the one bot send to the tree can't carry all that wood.

Actually, it looks like bots ignore cargo size when chopping trees and destroying rocks: they can always carry all the wood from a tree or all the stone from a rock in a single trip. But coal rocks leave coal to be collected.

Maybe dropped items should be auto marked for deconstruction.

They are, and this is another possible cause of the original issue of blocked bots waiting to construct something, reducing the number contributing to progress.

However, I'm no longer able to recreate this problem behaviour, except for the cliffs case I described.

[mrvn]

Is it just modded trees/rocks that have that problem now?

[Qon]

Is it just modded trees/rocks that have that problem now?

I have never seen the behaviour you are describing. Sounds like a mod issue and not a game issue.

[NotRexButCaesar]

Is it just modded trees/rocks that have that problem now?

I have never seen the behaviour you are describing. Sounds like a mod issue and not a game issue.

Sometimes the big sandy rocks(the ones that yield coal) will leave some coal on the ground.

[mrvn]

Is it just modded trees/rocks that have that problem now?

I have never seen the behaviour you are describing. Sounds like a mod issue and not a game issue.

Sometimes the big sandy rocks(the ones that yield coal) will leave some coal on the ground.

In Angels mod iirc the bigger rocks leave rock and coal so that makes sense. Can't pick up rock and coal.