[0.16.51] Lost/lazy bots

[zOldBulldog]

Most people will think of this as a bug but to be technically correct it really is just a very annoying design flaw or "feature".

Symptom: You pick up supplies at base and use a train to go build something (like a new rail line) far from base. Your robots refuse to do any work.

What is really happening:
- You have a number off ghosts in place on the route to the workplace.
- As you zoom past (even at full train speed) the robots notice the ghosts and leave the train to construct them.
- By the time you reach the destination, your bots are far behind and pout of charge. It will take them minutes IRL to catch up with you. And worse, they might be coming towards you by the shortest route so you might not even see them if you go back to try to find them.
- Now you place a new ghost at destination and the lost bots receive the construction assignment. You could even have additional bots with you, full battery charge and lots of resources and nothing gets built.
- After minutes of wait you might get tired of waiting and start placing more rail ghosts and start placing rail by hand ahead of you one one side of the line until you run out of supplies and return to base for more supplies.
- Unfortunately that leaves even more ghosts on the way to the build site. So you now have a vicious cycle and keep losing your bots every time you resupply, assuming they are even able to catch up with you.
- The problem is most severe the slower your bots. So, inexperienced players with just red/green bots will suffer from this issue most, and they will not be able to recognize what is occurring.

Easiest way to duplicate:
- Make a long rail line, like a partially constructed perimeter rail.
- Place blueprint ghosts along the line.
- Pick up resources at base.
- Get on train and go to rail end.
- Place new blueprints at rail end.
- Scream in frustration.

Workaround/band-aid:. You have to manually remove your roboports from your armor before each trip. It is annoying and very easy to forget, but doable.

Possible fixes:.
- Block the ability of bots to deploy for construction/deconstruction if the player is moving above a certain speed.
- Only assign personal bots to jobs if the bots are close enough to the player.
(Distance in both suggestions above might depend on the current robot speed)

Additional details:. The following discussion thread covers the issue very well and has a number of additional fix ideas:. [viewtopic.php?f=18&t=61340

[zOldBulldog]

Curious, moved to "not a bug" without even a reply.

Does this mean the devs consider this behavior acceptable and desirable? Seems strange given the consensus in the original discussion thread that it is a problem.

Would be good to understand the devs thinking about why this is ",good enough as it is".

[Loewchen]

As you said yourself, none of those issues describe bugs. All of this has been documented already, you could look for the existing feature requests intended to remedy the issues and state your support.

[zOldBulldog]

As a software developer myself I understand that it is not a bug from the strictest technical definition of bug (failure to perform a function as designed). I reported it here because it is a non-trivial flaw that impedes gameplay and there is no category for this kind of problem.

Does being moved to "not a bug" mean that this issue is not considered relevant beyond as a low priority suggestion?

[Koub]

[Koub]Moved to Ideas and suggestions. It may not be a bug, but be a suboptimal design nonetheless

[herkalurk]

This sounds to me like my suggestion to have an indicator to show if any bot is out of the personal roboport.

[zOldBulldog]

This sounds to me like my suggestion to have an indicator to show if any bot is out of the personal roboport.

Not quite. It is more than that. It is about fixing things so that bots won't leave at times when it is clearly undesirable (a train moving at max speed is an extreme example and easy to grasp, but there are other cases when it also happens).

[metis_seeker]

Personally, I'd consider it a bug in the spec. It's definitely a serious annoyance and I take steps to work-around it, but I wish I didn't have to.

[PsychoticLime]

I don't really know if that is possible, but maybe a fix would be to implement some sort of cycle that says "every x seconds (maybe once a minute), reset all work assignments to robots, then reassign them based on the new situation": this way, a worker robot that is already near the construction site with the materials in its inventory would (almost) surely get reassigned to the same task since it ranks higher in the algorithm that assigns bots; while a worker robot that is far from home and with low battery would not get reassigned.

This doesn't really fix the larger problem but it addresses at least the part where robots won't do a task because it is already reserved. If the algorithm is strong enough, one would ideally never even notice the resets happening, unless in these situations.

[ratchetfreak]

I don't really know if that is possible, but maybe a fix would be to implement some sort of cycle that says "every x seconds (maybe once a minute), reset all work assignments to robots, then reassign them based on the new situation": this way, a worker robot that is already near the construction site with the materials in its inventory would (almost) surely get reassigned to the same task since it ranks higher in the algorithm that assigns bots; while a worker robot that is far from home and with low battery would not get reassigned.

This doesn't really fix the larger problem but it addresses at least the part where robots won't do a task because it is already reserved. If the algorithm is strong enough, one would ideally never even notice the resets happening, unless in these situations.

The bots are dumb enough that something like that will be very noticeable.

Personal bots should not accepts jobs when too far outside construction range and closer bots should be able to take over jobs from bots flying in from across the map.

For the latter part there are going to be a lot of edge cases:

for example what if the current bot with the job has the object needed for construction, but is stuck in a very long recharge queue? If you then make it put the object into a storage chest then you could end up with too many buildings being manufactured depending on how you limited supply.

[PsychoticLime]

I see, maybe then a sort of safeguard that automatically recalls personal robots when the player gets too far, maybe also as a function of available charge? But this does nothing against the problem if you're already moving fast enough to leave them behind in the first place, I'm afraid

[zOldBulldog]

I see, maybe then a sort of safeguard that automatically recalls personal robots when the player gets too far, maybe also as a function of available charge? But this does nothing against the problem if you're already moving fast enough to leave them behind in the first place, I'm afraid

A recall won't do anything if the distance is significant or the speed too much.

There are quite a few things to fix about personal robots, but the most critical are:

- Robots should not be assigned any task if the player (on foot or vehicle) is moving faster than the robots can move.
- Robots should not be assigned any task if they are outside of their work range (the distance from the player beyond which they currently don't get an assignment).
- Robots should not be assigned any task if they don't have at least "x%" charge (not sure what x% is, but it should be enough to do the job and return if the player doesn't move).

Besides that, the following would help:

- Robots out of charge should return to the player's inventory BEFORE recharging, not recharge floating around.
- Robots should pick up supplies from the player's inventory BEFORE being assigned a task. If they haven't yet launched... before launching.
- Robots that are so far away that it would take minutes to return to the player should be released from the player's personal roboport and allowed to go to a roboport in the nearest large logic network (500 bots or more) at their own pace, or to the largest logic network if they are all under 500 bots. The player can then simply have a logistic request to restore his personal robot count to the right number, so that he'll replace the bots when he passes near base.

[mrvn]

- Robots that are so far away that it would take minutes to return to the player should be released from the player's personal roboport and allowed to go to a roboport in the nearest large logic network (500 bots or more) at their own pace, or to the largest logic network if they are all under 500 bots. The player can then simply have a logistic request to restore his personal robot count to the right number, so that he'll replace the bots when he passes near base.

No way. That would leave the player quickly without bots. And finding where the bots ended up would be a major undertaking. Requesting new bots also only works when you build more bots. Reclaiming existing bots from the network is not going to work well.

[zOldBulldog]

- Robots that are so far away that it would take minutes to return to the player should be released from the player's personal roboport and allowed to go to a roboport in the nearest large logic network (500 bots or more) at their own pace, or to the largest logic network if they are all under 500 bots. The player can then simply have a logistic request to restore his personal robot count to the right number, so that he'll replace the bots when he passes near base.

No way. That would leave the player quickly without bots. And finding where the bots ended up would be a major undertaking. Requesting new bots also only works when you build more bots. Reclaiming existing bots from the network is not going to work well.

I understand the drawbacks, and that is why I put it in the additional/"nice to have" section of my list instead of the main/critical one.

But what we have now is far worse:

- If you have a full load of bots at your base and use a train for a significant distance passing an area with some ghosts... your bots leave and stay way behind.
- When building rail at the perimeter of my controlled area, it's taken me 10 minutes in real life to recover bots because they end up out of charge. 10 minutes waiting for bots to catch up to you is unplayable.
- Once you know it will take 10 minutes to recover your bots, you can either leave the computer and do something else, or give up on bots and place manually.
- If you give up on bots and place manually, since the rail is an arc around the perimeter and the bots come in a line through the center, they will never find you before you go back for more construction materials. At which point they reverse direction and still can't reach you.

In these situations I leave the game running and go take a shower, fix stuff, eat, etc to let the bots catch up. But it is just plain stupid that I must do this.

What is worse, I seriously doubt the bots will be fixed any time soon, as it only affects players before launching the rocket. Experts and devs are likely playing with long established maps, and have done extensive space science research to speed up bots to the point that they are no longer left behind.

I am enduring it while still working on achievements, but as soon as I'm done with those I'm going to hunt for mods that eliminate the buggy/lazy/lost bot problem. Not waiting for a vanilla factorio bot fix, that could take months or years.

[mrvn]

So stop hiding the symptoms and fix the problem: Bots leaving while moving.

[Aeternus]

Yup. The personal roboport just needs a simple on/off toggle.
Suggested implementation (should be scriptable if I understand how Factorio works):
When on it uses it's normal coverage area based on the roboports you have in the armor.
When off, coverage area drops to 0. (calculate/get the current coverage area, invert the value and add it to the coverage area, effectively making it 0).

That should keep your personal bots from ever trying any jobs, it'll just be up to the player to remember to turn the thing off before travel. I'd code it myself if life permitted me to dig a bit further into Factorio modding... but time's an issue.

[mrvn]

Yup. The personal roboport just needs a simple on/off toggle.
Suggested implementation (should be scriptable if I understand how Factorio works):
When on it uses it's normal coverage area based on the roboports you have in the armor.
When off, coverage area drops to 0. (calculate/get the current coverage area, invert the value and add it to the coverage area, effectively making it 0).

That should keep your personal bots from ever trying any jobs, it'll just be up to the player to remember to turn the thing off before travel. I'd code it myself if life permitted me to dig a bit further into Factorio modding... but time's an issue.

Can one change the coverage area using lua at runtime?

[zOldBulldog]

So stop hiding the symptoms and fix the problem: Bots leaving while moving.

There are multiple problems. They all need fixing. I think I listed the critical fixes above, which includes bots leaving while moving.

[Philip017]

lol i have this issue ALOT, my resolve to take off my armor and put it in my inventory before i hop the train, or if i don't care about the robots that are lost, take off my armor, and put it back on, thus the robots are no longer assigned to me, after i get to my destination just so i can get back to work,

here is a mod that will help address this i have used:

https://mods.factorio.com/mod/folk-stopthat

[Aeternus]

Can one change the coverage area using lua at runtime?

Not sure if it can be done using lua, but it is done at runtime each time you add/remove a roboport. I am not much into Factorio modding yet so I simply do not know.