[0.16.51] Lost/lazy bots

[Ghoulish]

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.

What happens in the early game when you may have slow bots and fast player speed with exoskeletons? How about those who used modded exo's? You'd basically have to be stationary to make the bots do anything. If I'm laying a big mining field I might run to the other side of the ore - doesn't mean I want the bots to stop until I get there - eject from my roboport, do some work, find me on the other side of the field. I have to disagree with this idea.

- 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).
I haven't noticed this behaviour. If I make a blue print and place it outside the green area for my roboports - the bots do nothing until I move closer. I must be missing your point.

- 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).
What happens when the player does move? Wouldn't any fix or new code be negated, thereby making said fix kind of redundant? Players tend to move a lot..

- Robots out of charge should return to the player's inventory BEFORE recharging, not recharge floating around.
So the bots return to you, uncharged. jump into your roboport, you issue a new command and what, nothing happens whilst they charge? I'd find that annoying myself might even lead to people thinking something was broken?

- 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.

I most definitely don't want this behaviour, you could end up with no bots easily, and have to travel miles to get new ones. Bad bad idea. My bots need to stay mine until I choose to reduce the number or a biter nibbles on them.

For me the simple solution is best, personal roboport is auto disabled when you get on a train. Add a toggle to turn the port on and off, then you can have your bases construction bots build stuff local to the player and not use the players bots or items should you choose. Add a UI element to show total number / in use for your bots.

This is such a common annoyance for many that I hope the devs fix it, we should not have to rely on mods for a mechanic that should be standard, this isn't a won't that be cool feature - it's a needed one. Add it (edit: ANY suitable solution devs!! ) Pretty please.

[Ghoulish]

Addendum

I was thinking about the idea of just disabling personal bots in trains, then thought that it would effect FARL and almost fell off my chair (no idea if that's the case but just the possibility was enough). Also I guess some people might be on a train and manually laying a blueprint as they move the train along.. ie. laying track. So this idea wouldn't float. Best bet imho, a toggle to turn your port on and off.

[mrvn]

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.

What happens in the early game when you may have slow bots and fast player speed with exoskeletons? How about those who used modded exo's? You'd basically have to be stationary to make the bots do anything. If I'm laying a big mining field I might run to the other side of the ore - doesn't mean I want the bots to stop until I get there - eject from my roboport, do some work, find me on the other side of the field. I have to disagree with this idea.

Except that is not what happens. What happens is that while you run across the field the bots launch. Then they have to catch up to you to take something out of your inventory to build. That can't happen because you are running away from them. So when you reach the other side it takes minutes for the bots to reach you and then they see that the thing they wanted to build is too far away and give up. They probably also used up too much charge and will recharge from you before doing anything new.

How is that better than starting fresh when you stop moving? Also note that launching the bots doesn't take much time. Just pause for a second and 60 bnots launch. It's not really costing you time.

- 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).
I haven't noticed this behaviour. If I make a blue print and place it outside the green area for my roboports - the bots do nothing until I move closer. I must be missing your point.

Say a bot did go off to do some work. While it's gone you drive across all your base with a train. You then place a ghost. That one bot right across your base that is an hour away from catching up to you is already outside your inventory and idle. So it gets the job to build the ghost. So for an hour nothing happens till the bot catches up to you, recharges, takes the item out of the inventory and actually starts the job of building the ghost.

- 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).
What happens when the player does move? Wouldn't any fix or new code be negated, thereby making said fix kind of redundant? Players tend to move a lot..

The bot can't know beforehand if the player will move. And once it is on the way there is little point in turning back. Also if you just move 2m to the side you don't all bots to turn back. The point is to not allow bots to start a job they know they can't finish (assuming the player doesn't move). Let them recharge first as flying without charge is many times slower.

- Robots out of charge should return to the player's inventory BEFORE recharging, not recharge floating around.
So the bots return to you, uncharged. jump into your roboport, you issue a new command and what, nothing happens whilst they charge? I'd find that annoying myself might even lead to people thinking something was broken?

- 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.

I most definitely don't want this behaviour, you could end up with no bots easily, and have to travel miles to get new ones. Bad bad idea. My bots need to stay mine until I choose to reduce the number or a biter nibbles on them.

For me the simple solution is best, personal roboport is auto disabled when you get on a train. Add a toggle to turn the port on and off, then you can have your bases construction bots build stuff local to the player and not use the players bots or items should you choose. Add a UI element to show total number / in use for your bots.

This is such a common annoyance for many that I hope the devs fix it, we should not have to rely on mods for a mechanic that should be standard, this isn't a won't that be cool feature - it's a needed one. Add it (edit: ANY suitable solution devs!! ) Pretty please.

Yeah, those last two are bad ideas.

[L0laapk3]

I think a big part of the problem is that bots are assigned work before they are available, in some sort of queue for each bot. This is not a problem for stationary drone ports, but when you are moving, this leads to problems like you described, or simply when working with big blueprints, this pretty much always leads to some bots seriously bottlenecking the entire construction. The problem is that the system that assigns the tasks to each bot, cannot predict exactly how long each task will take because of unpredictable player movement and it snowballs further by changingbthe order of charging of bots, etc.

The only real solution to this was to store the building queue on the player instead of on each bot, and only assign single jobs to bots that are currently available for work (the moment they are finished charging and go in the player inventory).

Ofcourse there are some other problems, but this at least would make much of it far less worse.