Factorio Forums

Deconstruction of something big causes bots to fly ridiculously long distances just to put it in a crate already having those items. While that logics is generally good, it's still not quite so necessary with everything being accounted at logistic network as total and usable by smart inserters. Sometimes it causes deconstruction to take long times when you put some furnace area, then you understand that the whole thing should be rotated 180 degrees, then you deconstruct it (long bots flying to crates where some furnaces were dropped for the first time), then flying back to build it again. I've put a storage crate specifically for them to drop stuff there, but they ignored it. The proposal is that bots seek for same-type-of-item crates only within 3-4 roboports range area (e.g. screen size completely zoomed out), not further. That will also provide better random distribution of items over time.

I feel like this is getting rid of some potentially desired behavior in some cases while fixing it in others. I think a better solution lies in filtered storage where I have control over what goes where. Yes, I know this requires more work but I can't think of a good alternative that retains the old behavior and allows what you suggest to be true.

Not the solution you are suggesting but as a work around you can drop a nearby storage chest and put at least one one of each item you are deconstructing in it. Then the bots will drop it all in there.

Yeah, I thought about this workaround afterwards.

As for damaging other cases - they will not completely suffer since items are still available for bots, just at the price of longer trips later. After all you may mark that temporary chest for deconstruction when you have finished and all items will go to their original places (or not so far away). I understand why items are grouped - better stacking, more predictable bot routes. But with distance of like 8-9 roboports this bonus becomes heavily outweighted by distance they travel and recharge.

Hm. This suggestion is thought too short. It fixes a temporal problem.

The basic problem is, that the routing of the bots is currently very simple. This is planned to be changed.
See viewtopic.php?f=80&t=18093 Roboport/Logistic Network/Robot enhancements
-> Handling of Robot-Routing / Pathing

or others there, like
viewtopic.php?f=6&t=10152 Controlling robot distribution
...

If this happens, this suggestion might make no sense anymore and vice versa. So I would say it's a good idea to pause this.