Let construction robots place items that were just deconstructed nearby

[BLucky]

This probably got requested already but I couldn't find another existing post with a similar suggestion, and the FFF discussion bot improvements didn't mention anything like this, so I decided to make a post

TL;DR

Make moving buildings better by making it so that construction bots don't have to travel all the way to a storage chest to store a deconstructed building just for another bot to immediately grab it and carry it all the way back to move that building one tile left

What ?

Pretty much the title: let construction bots select a construction ghost as the destination for a deconstructed item instead of just chests, massively optimizing bot usage in cases when you need to move a big selection area a small distance

Why ?

This would really reduce the amount of bots flying about when moving large blueprints around (for example making way for a rail, or aligning something with the 2x2 rail grid afterwards, etc), would make it faster, since there's less roundtrip time, and will also remove the problem of producing extra unecessary items in the mall and overflowing into storage chests if the factory being moved uses buildings produced in a mall (which is almost always)

[Illiander42]

I have a feeling that if this were easy they've already have it in 2.0.

...

Do they already have this in 2.0?

[Koub]

I think if this change had been planned/implemented for 2.0, we would have seen it in this FFF : https://factorio.com/blog/post/fff-374.
And I can't find a previous thread with this exact same suggestion either.

[computeraddict]

It seems like this logic would only have an effect if you did the deconstruction order before the construction order was assigned to a robot, otherwise the items would already be en route. Or did a super force build that issued the orders simultaneously.

[Murklak]

This would significantly increase the chance of personal robots becoming deadlocked. More frustrating than it's worth.

[BLucky]

It seems like this logic would only have an effect if you did the deconstruction order before the construction order was assigned to a robot, otherwise the items would already be en route. Or did a super force build that issued the orders simultaneously.

I was initially thinking about cut and paste, but super force build works as well



but yeah, reading the discussion here I realized that in both cases this would require changing the robot's task queue since if a deconstruction order was placed first, it would already be assigned to a chest, and if a construction order was placed first, it would already have items en route as you said. The only case where this wouldn't need any extra logic would be if there's no items stored in the logistics network for that, making the deconstructed item the only option, or if there isn't enough bots to fulfill all the tasks, making it possible that both a construction and deconstruction order exist at once when a bot gets around to it, but with the 2.0 changes allowing for a task queue instead of 1 task per bot, that wouldn't work either

[Qon]

If when placing a blueprint, instead of just provider and buffer chests being queried for available items, bots in the air on their way to dump their inventory were also queried within a smaller distance than the found item. And with some max radius to speed up the bot search as well.
And bots that are on their way to a roboport with an empty inventory could likewise be found instead of bots inside roboports.
Similarly ghost on ground can be seen as preferred alternative to dumping item in a chest and deconstruction orders can be seen as preferred alternative to finding item to supply a ghost.

That would require some extra computations, but the computational load could be mitigated. Instead of each ghost querying for items in the network and then choose a chest and a robot, those computations could be batched to find all the flying and other tasks (ghosts+decon orders) robots just once around all the ghosts just placed.

Also the integrated CPU load over the duration of the build could be actually lower than without this feature.
First: The amount of game updates required can potentially be thousands of times faster in a best case scenario of a big area being cut and then quickly pasted a few tiles away (so a lot of overlap) and storage chests very far away from the active area. Bots from nearest roboport could fly in, move the items a few tiles and then fly out and complete the order in a few seconds, instead of overloaded for 15 minutes of bots flying around in chaos. And all those active bots flying around for temporary and unnecessary transportation cause further issues down the line because all the roboports get blocked because they get overwhelmed.

But it would be tricky to write optimized and correct code for this feature, and the devs might now want to rewrite the entire core of bot, chest and item finding/assignment for jobs and introduce more things than can randomly re-assign jobs at any point. So I don't think this is very likely. But it would be a very cool feature if they did make it!

[Koub]

I was thinking something like "flag marked for deconstruction items as stored within the logistic network, as if they were in a virtual container with just the item". Like that, a bot assigned a construction job could be sent to that particular "marked for deconstruction" item it needs, instead of a random storage.
I have no idea if the current code would make this an easy change that does the job, or if it would fuck everything up, or need a complete rewriting of the code. But the idea seemed to make sense.

[Qon]

I was thinking something like "flag marked for deconstruction items as stored within the logistic network, as if they were in a virtual container with just the item". Like that, a bot assigned a construction job could be sent to that particular "marked for deconstruction" item it needs, instead of a random storage.
I have no idea if the current code would make this an easy change that does the job, or if it would fuck everything up, or need a complete rewriting of the code. But the idea seemed to make sense.

I like it. The issue is that this alone is not enough, and it might actually already kind of be the current implementation to some extent. But if you cut a few hundred or slightly more (depending on timing, 10 entities/tick I think...) then it doesn't really matter, the deconstructed entities are already reserved the tick the bot is released from the roboport to pick it up. And reserved items cannot be reserved again, so they are essentially already locked in their destination chest until they actually arrive there, even though the bot hasn't yet traveled to pick it up and not traveled to deposit in the chest. So the deconstructed item will be permanently scheduled to be transported away within seconds, before you have time to paste. This is the bigger and trickier issue that needs to change, I think.

[nethus]

I work around this by placing a (yellow) storage chest, and placing one of each item that I expect to be deconstructed in it (belts, inserters, AM's, power pole,...). All bots will dump the deconstructed items in the chest and go wait in a nearby roboport, and once you start reconstructing, both bots and items are nearby.
But you have to be there to place and pre-fill that chest in the first place, and wait some seconds before you start constructing again or a nearby bot might grab the single or last e.g. inserter, and all deconstructing bots will ignore that chest and revert to the far away chests to dump their items. And off-course you have to remove the chest afterwards, or it'll interfere with building later on.

But that's only a workaround. I'd also love smarter behaviour when deconstructing/constructing.

Maybe by having the bots pausing for some seconds after deconstructing, to see if you paste the items you've just cut? I don't think those extra seconds before they head back to the mall to drop their load if you don't paste the recently removed items will make a significant difference.

[pleegwat]

Perhaps if you could do that with a filtered storage chest instead?

[Illiander42]

Maybe by having the bots pausing for some seconds after deconstructing, to see if you paste the items you've just cut? I don't think those extra seconds before they head back to the mall to drop their load if you don't paste the recently removed items will make a significant difference.

Or if cut waited for the next blueprint interaction before dispatching bots?

I use the CUT shortcut as a quick way to get a decon planner onto my cursor, so whatever the solution is shouldn't break under that use (it seems such an obvious shortcut).

[computeraddict]

I use the CUT shortcut as a quick way to get a decon planner onto my cursor, so whatever the solution is shouldn't break under that use (it seems such an obvious shortcut).

...how is ctrl x faster than alt d?

[Illiander42]

I use the CUT shortcut as a quick way to get a decon planner onto my cursor, so whatever the solution is shouldn't break under that use (it seems such an obvious shortcut).

...how is ctrl x faster than alt d?

1) I didn't know about ALT+D.

2) ALT requires moving my thumb from the centre of the spacebar to a rarely used key, CTRL+X is pure muscle-memory due to everything using it.

[computeraddict]

I use the CUT shortcut as a quick way to get a decon planner onto my cursor, so whatever the solution is shouldn't break under that use (it seems such an obvious shortcut).

...how is ctrl x faster than alt d?

1) I didn't know about ALT+D.

2) ALT requires moving my thumb from the centre of the spacebar to a rarely used key, CTRL+X is pure muscle-memory due to everything using it.

Alt is also used for turning personal roboport on and off with alt R, exoskeletons with alt E, changing windows with alt tab...

[Illiander42]

I use the CUT shortcut as a quick way to get a decon planner onto my cursor, so whatever the solution is shouldn't break under that use (it seems such an obvious shortcut).

...how is ctrl x faster than alt d?

1) I didn't know about ALT+D.

2) ALT requires moving my thumb from the centre of the spacebar to a rarely used key, CTRL+X is pure muscle-memory due to everything using it.

Alt is also used for turning personal roboport on and off with alt R, exoskeletons with alt E, changing windows with alt tab...

I don't use them either.

(When I did use ALT+TAB that's a full hand movement from the wrist, rather than a deep thumb curl. But with 3 monitors and a 5x5 grid of virtual desktops I have no need of ALT+TAB anymore )