Make construction bots smarter to avoid deadlock

[gyorokpeter]

To reproduce:
- Have a storage chest filled with items for which it is the only chest in the network that will accept it
- Try to move the chest by cutting and pasting it
This results in construction bots picking up the items from the chest and getting stuck in the air as they have nowhere to drop the items. Normally this should last until the chest is built at the new location, but in this scenario, the chest never gets built, despite there being spare chests and idle bots in the network. I guess the task of building the chest is over-optimistically assigned to one of the bots taking items from the chest, and is not reassigned to another bot when the original bot fails to finish its task on time. The workaround is to either manually build the chest or deconstruct the ghost and then immediately undo the deconstruction.

The suggestion is to make bots smarter in this case - if the bot fails to find storage for an item, it should cancel any tasks it has queued and let another bot take them.

[Stargateur]

this is too much of a edge case to bother about it. Just build two storage coffer.

[gyorokpeter]

I don't think this is an edge case. To me it's a legitimate way to play to make sure all chests have proper filters instead of having a large dump of unfiltered chests sitting in one corner of the base getting filled with random items. There is no guarantee that those random items will eventually get picked up and free up the space. Instead I prefer to have everything in its designated chest. It's the same mindset as not littering in real life and reusing/recycling as much as possible.

As mentioned, it is already possible to fix the deadlock by deconstructing the ghost and then cancelling the deconstruction. Building another chest is a variation on that, it's an equivalent UX issue.

In fact this is a regression introduced by https://factorio.com/blog/post/fff-374. Assuming that the robot is able to finish its task is too optimistic, so there should be a correction that if the bot is unable to drop the item it's holding, it should cancel its queued tasks, allowing other robots to take them.

[robot256]

I have played using networks with no unfiltered storage as well, and think it is too much of an edge case to deserve dedicated code to work around it.

A much better, more universal solution will be to have the scheduler detect when a job is stuck in a queue for any reason and reassign it. That is what I would hope to come from this thread.

This is a serious problem in several different scenarios (mainly tiles and elecated rails):

viewtopic.php?t=122567
viewtopic.php?t=122829