[0.10.9] reassign pending construction robots with cargo

[boro]

When a construction robot is carrying an item to a destination, and that destination becomes no longer valid because the ghost time has run out or you manually removed the ghost, it will just keep hovering on the spot, until you remove the item from it, put down a storage or requester chest, or it runs out of energy. If it runs out of energy and flies to a roboport, it will keep hovering there, and you can no longer touch it as it falls in the same selection box as the roboport.
A similar thing happens of course with logistic robots that no longer have a requester/storage chest or chestspace available, but were already underway.

Steps to reproduce:
-have provider chest with walls
-shoot down a wall
-wait for a construction robot to grab a wall
-remove the ghost

or

-place a blueprint
-wait till the time has almost run out (why is there a time limit anyway)
-provide the goods
-when the time runs out while they are carrying the item they will stop on the spot

Now when your construction robots are in their hovering state, you would think that when you give a new target, like the same blueprint, or by shooting down another wall, they would fly over there with priority but instead other idle construction robots will go pick up new goods. Not even when all other construction robots are busy or there is no more of that item in the logistic network, does the hovering construction robot go back to action.
I always end up tearing down my roboport to free my robots of their burden, as I don't like putting down a temporary storage chest and having all my logisitic robots bringing it stuff unnecessary (and possibly starting the loop all over again as I pick up the chest at an awkward time).

[boro]

Thinking about it some more I guess I wouldn't have this problem if I used only passive provider chests and a storage chest for these situations but still.

[kovarex]

Thinking about it some more I guess I wouldn't have this problem if I used only passive provider chests and a storage chest for these situations but still.

Yes, your system is probably created in a way, that you don't use storage chests. In that case, it is better to use really the passive providers everywhere, so you can place the storage chest safely.

But I agree, that the robots that are in the pending state (They want to get rid of the item they hold, but they have no place to put it), could be send to be used when their cargo is needed to build something else.

[kovarex]

Moved to ideas and suggestions (I sticked it, as I want to do it, but it is feature, not a bug fix).

[Slayn25]

I pretty much only get pending robots when I'm clearing out a forest or expired mine via personal roboports without realizing that I'm near my border defenses (which I line with roboports filled with construction bots+repair tools, but only sometimes storage chests).

Definitely not a big problem but for ease of use I would suggest one or both of the following:
1. Bots will not initiate deconstruction orders if they do not have a place to put the items after picked up
2. The player serves as a storage chest for deconstruction purposes only

[AutoMcD]

+1
I think it is a bug if the drone gets "stuck" and just hovers there indefinitely. That's not intended behavior, especially in cases where there's plenty of storage chests and everything. Not your fault if a build ghost expires and the bot can't just give up on the idea. Logistic or construction attempts should expire or time-out to cover these cases.

In the case where there is no storage, a time-out should result in the drone just dropping the item near the roboport (or player). Same as if you try clearing trees with full inventory.

[ssilk]

Hm. Quite old and I think this is wrong here and it seems, that I was a bit to busy with it and didn't thought much. Sorry for that.

Kovarex moved this topic to Suggestions and made it sticky, and I moved it to "ready for implementation" subboard cause I thought it would be a good idea to put all the topics into, that are marked as sticky.

But now I want to clear that subboard, cause it has obviously no relevance for the devs and so I'll move this one to "confirmed bugs" (even knowing that this is not a bug, but wanted to be implemented). Perhaps it's already implemented. In any case it's in my opinion not useful to keep it into Suggestions, cause there it is out of view of the devs.

Hope I didn't make things more worse.

[Rseding91]

I was looking into this to see what it would take to fix it properly and it's going to require some large changes to how robots are dispatched which I don't want to do for 0.13. I've made a to-do for 0.14 to look into this again.

[Sandman]

This still happens in Version: 0.14.21
Or at least something very similar.
Now around 80% of my bots just float around the port with no way to reset them.
I have no construction bots.
I think it happend when I placed a active provider chest and the bots started to transport to the storage chest, but stoped for some reason. They did not run out of space to put stuff.

[Rseding91]

This still happens in Version: 0.14.21
Or at least something very similar.
Now around 80% of my bots just float around the port with no way to reset them.
I have no construction bots.
I think it happend when I placed a active provider chest and the bots started to transport to the storage chest, but stoped for some reason. They did not run out of space to put stuff.

Please upload your save.

[Sandman]

There you go.

[Rseding91]

There you go.

You have 151 logistics robots and 1 roboport. They can't charge fast enough - you need to build more roboports.