Factorio Forums

First, my apologies. It's hard to say if this is a bug or just a pathological use-case, and all of the solutions I can think of are giving me headaches.
When placing this blueprint, which contains 16 roboports, ~4000 other items, and a footprint of 168x168, the following behavior is observed:

The nearest roboports are placed by construction bots. This extends the construction range, and the next row of roboports is also placed. However, these ports are not guaranteed to be powered, as the substations may not be placed yet (either due to the distance to the supply chest, the order that tasks are assigned to the bots, or simply because there are not enough substations in storage). The ports have a small amount of battery power when placed.

When the new roboport is placed, the expanded construction range also assigns building tasks to new robots for the parts of the blueprint that are now in range. Construction bots fly to storage, pick up materials, and make several stops to recharge along the way. While they are en route, the roboports at the furthest edges will run out of battery power, shrinking the construction range. This cancels the build tasks for these robots, who are now ordered to return the materials to storage. Some of these materials will be substations. Some of those substations would have been meant for powering some of the further roboports. Consequently, these other roboports will also run out of battery power, leading to a cascade effect of bots flying back and forth and accomplishing absolutely nothing.

The "WTF" moment comes when you are standing between the construction zone and your storage area. When one of the distant roboports runs out of battery power and shrinks the construction range, you will see thousands of bots suddenly stop, turn around, and return the materials to storage, only to immediately take them out of storage and go to build them in the nearer parts of the blueprint. Again, making several stops along the way to recharge. This fracas will continue for long enough for the blueprint to time out, and if you personally refresh the blueprint, it can go on for much longer.

Actually, there may be a real bug buried in here somewhere. I've noticed that when a roboport runs out of battery power and the construction area is shrunk, many more bots than I would expect are sent back to storage. It seems like it's canceling the orders given to many of the bots and then immediately giving those same orders to other bots back at base.

EDIT: I can confirm this. When a far roboport runs out of battery power, even bots which are in range of a nearer, fully powered roboport will have their orders canceled.

Give me a few minutes. I'm going to tidy up a save file for you.

I suspect the last issue happens because all commands in the construction area of the powering-down roboport get cancelled, even if they're still in range of another (careful observation could confirm this)

As for the initial problem, this appears more of an issue of blueprint design than an actual bug. As someone suggested in a different thread, splitting the blueprint up into two parts might work better: one containing just power and roboports and the other everything else. Perhaps it could be alleviated somewhat by placing big poles next to roboports and right on the edge of each roboport's logistics range (but you'd sacrifice some solar panel density for that ).

As a suggestion to the devs, perhaps it would make sense to have robots give absolute priority to placing energy distribution entities. This might even go so far that a robot that was on the way to a power pole ghost will continue there even when the containing construction area disappears (and run the risk of running out of power along the way or on the way back and crawling the rest of the way - at least it will get the pole into position)

just a small addition to add to this report ...

removing any roboport in the network cancles all active build orders for the whole network and are reasigns to a new group

seen this when having a network with over 200 ports removing one on one end while having the build orders on the other end of the network send all bots with build orders directly to the storage chests network is build in a 10x20 shape with no overlaps for ports

reddutton wrote:just a small addition to add to this report ...

removing any roboport in the network cancles all active build orders for the whole network and are reasigns to a new group

seen this when having a network with over 200 ports removing one on one end while having the build orders on the other end of the network send all bots with build orders directly to the storage chests network is build in a 10x20 shape with no overlaps for ports

Thank you! This is the same thing I've observed too. Removing a roboport (or simply removing its power source and letting its batteries drain) will cancel ALL build orders for the entire network!

Since this is trivial to reproduce, I don't think I'll post a save file unless it's really needed. This save is... very cluttered, and all you need to reproduce the issue is a few roboports, a few hundred bots, and just a medium-sized blueprint.

Oups, my mistake ... I accidentally caused this behaviour, I thought I covered this by automated tests but apparently I didn't ... Thanks for the report, save is not needed

posila wrote:Oups, my mistake ... I accidentally caused this behaviour, I thought I covered this by automated tests but apparently I didn't ... Thanks for the report, save is not needed

Great news! Thank you very much.

For what it's worth, the bug didn't have a big impact for deconstruction. When the roboport is removed, bots with a "deconstruct" task just hover for a second before going back to their task.

If I could ask you for one more favor... When a construction bot is returning an item to storage, and there is a ghost for that item somewhere, do you think that bot could be ordered to build the item instead of continue moving it back to storage? What happens now is that if that item isn't in the network, it reports "Missing the material for construction" until the bot brings it all the way back to a storage chest, and then assigns a bot (often the same one!) to take the item back out of storage and build it.

codewarrior wrote:If I could ask you for one more favor... When a construction bot is returning an item to storage, and there is a ghost for that item somewhere, do you think that bot could be ordered to build the item instead of continue moving it back to storage?

Thanks for the idea. I'll add it into our backlog as it makes sense it should work this way, but it is not trivial change and could cause performance issues, so it probably won't be done in 0.12.