Factorio Forums

I noticed this behavior mostly deconstructing with bots from my personal roboport, but I also experienced it in large constructions in roboport-covered areas.

Basically, bots don't always keep constructing/deconstructing until the job is done. I would expect them to pause for recharge and then resume, but instead they seem to attempt one pass and then quit even if the job is incomplete. The exception seems to be when "something" (not sure what action) resets their memory.

The easiest way to reproduce is to give a deconstruction order for more items (I.e.:, tracks) than you have personal bots, in an area with no roboports.

So, is this a bug or intended?

EDIT: Added screenshot to show the problem. In the screenshot:

- I have lots of rail in inventory.
- I have full batteries in the personal roboports.
- I have 37 construction bots with me.
- I have been sitting here for quite a while (several minutes IRL), so the bots are fully charged.
- I am completely out of range from any roboport (as you can see in the minimap... there is nothing nearby besides rail, powerpoles and signals.
- And yet, those missing rails are NOT being constructed.

The reason? When I was by the base 13 robots took off from the train to do something as the train went by, getting left behind. All rail construction halted until those stray robots finally caught up with me across the long distances.

I agree that this is almost certainly "working as designed", and yet... it is very annoying and hampers gameplay.

It needs to be addressed in a near-future patch.

Personal bots don't deconstruct items that have a bot assigned from the normal roboports. Those are on the way. Just wait and you will see them coming.

mrvn wrote:Personal bots don't deconstruct items that have a bot assigned from the normal roboports. Those are on the way. Just wait and you will see them coming.

Not quite what I described. I can be in an area outside of the normal roboport range and the deconstruct just stops after the first pass of personal bots.

To make them finish the job I have to cancel the deconstruction then request it again. Or (better) simply request smaller deconstructions one after the other, annoying as it partially defeats the purpose of bots but works.

sometimes it takes some time until bots reattempt to fullfill a certain task - especially if you have a lot of queued tasks already

zOldBulldog wrote:

mrvn wrote:Personal bots don't deconstruct items that have a bot assigned from the normal roboports. Those are on the way. Just wait and you will see them coming.

Not quite what I described. I can be in an area outside of the normal roboport range and the deconstruct just stops after the first pass of personal bots.

To make them finish the job I have to cancel the deconstruction then request it again. Or (better) simply request smaller deconstructions one after the other, annoying as it partially defeats the purpose of bots but works.

This would be the behaviour if the queue is full, but it should only be happening if you have large amounts of jobs open that can not be assigned.

Loewchen wrote:

zOldBulldog wrote:

mrvn wrote:Personal bots don't deconstruct items that have a bot assigned from the normal roboports. Those are on the way. Just wait and you will see them coming.

Not quite what I described. I can be in an area outside of the normal roboport range and the deconstruct just stops after the first pass of personal bots.

To make them finish the job I have to cancel the deconstruction then request it again. Or (better) simply request smaller deconstructions one after the other, annoying as it partially defeats the purpose of bots but works.

This would be the behaviour if the queue is full, but it should only be happening if you have large amounts of jobs open that can not be assigned.

This concerns the overall number of ghosts in the game. When you deconstruct an area first all personal robots are assigned to ghosts. Then the rest is assigned to bots from a logistic network (if any). Any ghosts that then remain are put in a global list and processed again and again one ghost per tick. The later part can take long.

Note: A safegame showing the problem always helps.

mrvn wrote:This concerns the overall number of ghosts in the game. When you deconstruct an area first all personal robots are assigned to ghosts. Then the rest is assigned to bots from a logistic network (if any). Any ghosts that then remain are put in a global list and processed again and again one ghost per tick. The later part can take long.

Note: A safegame showing the problem always helps.

True, but still annoying. If you have a large area covered with concrete it can easily be more than the queue size. The fact that this interfers with the behaviour of my personal bots feels awkward.

Another issue is this:
If you blueprint in a no-robo-port-coverage area more stuff than your bots can build with your inventory, some stuff cannot be build. Logical. If you return to this spot with the needed stuff in your inventory, your bots start to build the missing pieces. But even if you have hundreds of bot, the job is done by only a few (3-5) bots flying back and forth several times. Bug?

Updated the original post with a screenshot and additional details that show an example of the problem "in action".

zOldBulldog wrote:Updated the original post with a screenshot and additional details that show an example of the problem "in action".

Except you failed to make the screenshot with good timing, so the "601" on the notification isn't visible. And once it is visible there's really not much to be said. The more ghosts you have on the whole map the longer it takes for any bot to arrive at any particular ghost, because they're randomly distributed.

You can fiddle around with the queue length, but nobody guarantees good performance for that:
LuaForce.max_successful_attemps_per_tick_per_construction_queue
LuaForce.max_failed_attempts_per_tick_per_construction_queue

eradicator wrote:

zOldBulldog wrote:Updated the original post with a screenshot and additional details that show an example of the problem "in action".

Except you failed to make the screenshot with good timing, so the "601" on the notification isn't visible. And once it is visible there's really not much to be said. The more ghosts you have on the whole map the longer it takes for any bot to arrive at any particular ghost, because they're randomly distributed.

You can fiddle around with the queue length, but nobody guarantees good performance for that:
LuaForce.max_successful_attemps_per_tick_per_construction_queue
LuaForce.max_failed_attempts_per_tick_per_construction_queue

I am not sure what you mean by the 601. If you refer to the things "pending construction", those are mostly in the base and there are far more than that. That part is not really relevant.

The primary issue - in this particular example - is that construction was assigned to personal robots that were left behind by the base (when they abandoned the train to place stuff), dozens of chunks away. It took them several minutes to return.

If I had not stuck around but rather moved on placing the missing rail by hand... as I am often forced to do, those bots would have likely not reached me for a long time since they'd continue moving at "out of power" speed. No matter how you look at it, it is extremely annoying and a bad gameplay mechanic.

The only solution I can think of at the moment is to assign construction tasks to specific personal bots only at times when they are physically in the personal inventory, to avoid assigning tasks to bots that are so far away that they might not be able to execute them.

As to preventing bots to take off from a train (or a fast running player) to do stuff... I don't know if that is even feasible.

zOldBulldog wrote:I am not sure what you mean by the 601. If you refer to the things "pending construction", those are mostly in the base and there are far more than that. That part is not really relevant.

600 is the default queue size. Any new ghosts get an instant personal construction attempt, and if that fails are moved to the queue. And it doesn't matter if those ghosts are "far away", there is only one queue per force (well, two technically, but that's details hopefully not needed here).

Trying to read again what you wrote...are you saying the jobs were assigned to bots lost in transit? And those exact bots instantly built the missing rail pieces when they finally got back? And it's not just random coincidential timing? And you had enough additional bots available that could've done the job instead? And you placeded the rail while it was within your construction range? (don't skip any of the questions...) If you can reproduce that while the queue is empty that might be a bug. With a full queue it sounds like the usual "the whole queue thing is an unexpected mechanic", which it sure is, but that's a very old and boring debate.

eradicator wrote:

zOldBulldog wrote:I am not sure what you mean by the 601. If you refer to the things "pending construction", those are mostly in the base and there are far more than that. That part is not really relevant.

600 is the default queue size. Any new ghosts get an instant personal construction attempt, and if that fails are moved to the queue. And it doesn't matter if those ghosts are "far away", there is only one queue per force (well, two technically, but that's details hopefully not needed here).

Trying to read again what you wrote...are you saying the jobs were assigned to bots lost in transit? And those exact bots instantly built the missing rail pieces when they finally got back? And it's not just random coincidential timing? And you had enough additional bots available that could've done the job instead? And you placeded the rail while it was within your construction range? (don't skip any of the questions...) If you can reproduce that while the queue is empty that might be a bug. With a full queue it sounds like the usual "the whole queue thing is an unexpected mechanic", which it sure is, but that's a very old and boring debate.

I don't think it is a bug, I think it is a design oversight.

Answering your questions:

- It is not a matter of queue size. There were only about 50-100 items being placed, far below the queue size. (there are many hundreds other items to place but that is unrelated to the issue discussed here, they are not part of what the personal bots are trying to do).
- The personal bots "on me" placed a round of items fine, so they obviously were not assigned to any queue back at the base.
- The jobs were assigned to personal bots... that were extremely far away. Far enough to take minutes IRL for them to arrive.
- Once assigned, no other bot attempts to place the items. Per design, obviously.
- Several minutes later the bots arrived and placed the missing rails. I think it was those exact bots - that arrived from the far distance - but they had to grab materials from me first. I am 99.99% certain it was not coincidental timing.
- Yes, everything was in construction range (or rather... part of the blueprint was and the other part was beyond the range). I was right at the end of the previous blueprint when I placed the new one, and as I drove on the rail the bots "on me" went placing stuff... until I reached a rail that was assigned to a bot still in transit from the base. That is when I had to wait.
- Reproducing the problem is easy:
(1) Have a very long section of rail that goes far away from where you start.
(2) Get on the train.
(3) Place a blueprint where you start (or in the path of where your train will pass) that will engage about half of the personal robots.
(4) Get the train aimed to the stop that is far far away from the base.
(5) As soon as you get in range of the blueprint you just placed by the base some of your personal robots take off to construct it. But by the time they are done you are out of range, as you were already going to your destination.
(6) Once you get to the destination place a blueprint.
(7) The bots on you start building it, but some of the items are assigned to the personal bots that were left behind.
(8) Once the bots "on you" finish their task, the items assigned to the personal bots far away are not constructed.
(9) At this point you have two choices: ( A ) Wait some minutes for the far away personal bots to arrive and complete the job. Or ( B ) manually construct the missing pieces and move one.

Of course, if you use option ( B ) it is quite possible you will run out of resources, head back to base station on automatic control, pass the "left behind" bots too fast for them to catch up, load up with new resource, and repeat the cycle... waving at the "left behind" bots every time you go past them. This is a worst case scenario, but it has actually happened to me, and the only way to break the cycle is to stop and wait for them to catch up.

The reproduction steps work and make it far clearer what your actual problem is. (Because your constant repetition of "queue size doesn't matter" is just wrong, and doesn't help at all :p).

Might be worth a shot at a bug-report. "Personal robots out-of-range should not be assigned new jobs". But that hinges strongly on the definition of "out-of-range".

eradicator wrote:The reproduction steps work and make it far clearer what your actual problem is. (Because your constant repetition of "queue size doesn't matter" is just wrong, and doesn't help at all :p).

Might be worth a shot at a bug-report. "Personal robots out-of-range should not be assigned new jobs". But that hinges strongly on the definition of "out-of-range".

Will make one.

Seems like a simple matter of not knowing how the game works.

- Your personal roboport has a limited control capacity. Even if you have 100000000 bots it can only control a handful (see description).
- Bots that are flying around but idle get the next job first.
- If you run around, worse drive by train, and come across ghosts then personal robots will emerge. They then need to catch you to get materials for construction. But you are faster than the bots so you scatter them all over the world (see bugs about that).
- Bots that can't get materials for some time or something revert to being idle and can take really long to get back to you. All the while blocking the roboports control slot.
- Bots that take too long run out of fuel, making them take even longer.
- Ghosts are processed in the queue only, except when you more ore place new ghosts. So the queue size very much matters.

So it seems you have combined all the problems of the bot system in one go.

eradicator wrote:The reproduction steps work and make it far clearer what your actual problem is. (Because your constant repetition of "queue size doesn't matter" is just wrong, and doesn't help at all :p).

Might be worth a shot at a bug-report. "Personal robots out-of-range should not be assigned new jobs". But that hinges strongly on the definition of "out-of-range".

"out-of-range" can be defined as out of construction range or out of charge. When either of those conditions is true don't pick up new jobs.

If the personal bot is trying to pick up items and it ran out of charge then abandon job (so other bot can pick it up)

I doubt you will get this passed as a bug. Either don't leave your bots behind OR take your personal roboports off when it occurs.

You can take your personal roboports off either by taking your power armour off OR by taking the personal roboports out of your power armour. It's a quick thing to open your power armour then ctrl-click on a personal roboport, then ctrl-click again on the personal roboports in your inventory to re-equip them.

Obviously it is not a bug but a very annoing feature. Simple solution would be if personal bots gets their jobs assigned either if inside your backpack or charging. And only in those situations.

Szpak wrote:Obviously it is not a bug but a very annoing feature. Simple solution would be if personal bots gets their jobs assigned either if inside your backpack or charging. And only in those situations.

But then a bot can't fly out, place a rail and then deconstruct a tree on the way back.

Yeah, you're right. Solution that i'm using is to drop bots intro trash slot temporary when going on a looong train ride