Bots that are aware of their charge level and plan accordingly.
Posted: Sat Sep 10, 2022 11:25 pm
Presently, though they're certainly aware of their charge level for optimization purposes, the bots act like they have no idea when their charge will hit 20%, and instead always fly straight towards their destination until they reach 20% charge, then divert to the nearest roboport, leading to paths taken that look like this:
It's sometimes even worse, with bots heading to place an item, stopping a mere tile or two before reaching the destination, turning around, running out of charge before even reaching the roboport to charge, slowly slinking towards it, charging, then going back to place the item. Every time I see it, it strikes me as insane, because being a programmer myself, I imagine the way these things are implemented is that at the start of the journey, the game calculates where the bot will be at 20% charge, then just makes a note that it's on the way there until the game tick when it's going to arrive, rather than check the charge level every game tick, turning the bot's journey into one where it's location each frame can just be calculated with a simple equation rather than having to re-do the math to figure out how to move it one step closer to it's destination each game tick. So, as long as it's doing that, why on earth doesn't it just pick a different destination for the bot given that it knows it won't reach its actual destination?
Imagine if, instead of setting the bot's destination in the middle of nowhere, the game instead says "well, we can't reach that destination, so which of the roboports that we can reach is closest to that destination?
Well, step one looks like this: The roboports in the circle are close enough to reach (going all the way to 0% instead of only 20% charge, since, being smarter, the bots no longer need that 20% reserve). So it picks the one that is closest to the destination, and flies there.
No need to path-find (the reason suggestions about improving this behavior have been rejected in the past) but instead what's going on is similar to what already happens. Just, rather than waiting until reaching the 20% point to find the nearest roboport, we find it right from the start. So this doesn't require any more computation than the game already does.
Then, after recharging at that roboport, the bot does the same thing: It realizes that the destination isn't inside the circle, and so of the roboports in the circle, it picks the one which is closest to the destination.
Then, step three:
Then step four:
I actually stole the base image for this from another thread where Rseding91 said "As I've said before: this is not likely to ever happen. It would increase the CPU cost of robots by massive amounts for incredibly miniscule gains." However, again, I'm not suggesting path-finding the shortest path. What I'm suggesting is actually fewer calculations than the game already does.
Presently the game:
1. Checks if bot can reach destination. Upon realizing that it can't:
2. Calculate the point at which it would reach 20% charge, and set that point as the destination.
3. Once there, create a list of all nearby roboports, determine the closest one, plus some other considerations like how many other bots are already charging there.
4. Set that roboport as the new destination.
What I'm suggesting:
1. Checks if bot can reach destination. Upon realizing that it can't:
2. Create a list of all nearby roboports, determine the closest one, plus some other considerations like how many other bots are already charging there.
3. Set that roboport as the new destination.
It's one less step. Thus, this won't hurt game performance, it'll actually improve it.
These bots are able to pick up and drop off items on their own, and they're able to fix broken equipment, but they have no idea when they're going to hit 20% charge and no ability to plan recharges? It's silly. Especially since it wouldn't require any more calculation than the game already does, if a bot isn't going to reach it's destination, it should head for a recharge station instead.
It's sometimes even worse, with bots heading to place an item, stopping a mere tile or two before reaching the destination, turning around, running out of charge before even reaching the roboport to charge, slowly slinking towards it, charging, then going back to place the item. Every time I see it, it strikes me as insane, because being a programmer myself, I imagine the way these things are implemented is that at the start of the journey, the game calculates where the bot will be at 20% charge, then just makes a note that it's on the way there until the game tick when it's going to arrive, rather than check the charge level every game tick, turning the bot's journey into one where it's location each frame can just be calculated with a simple equation rather than having to re-do the math to figure out how to move it one step closer to it's destination each game tick. So, as long as it's doing that, why on earth doesn't it just pick a different destination for the bot given that it knows it won't reach its actual destination?
Imagine if, instead of setting the bot's destination in the middle of nowhere, the game instead says "well, we can't reach that destination, so which of the roboports that we can reach is closest to that destination?
Well, step one looks like this: The roboports in the circle are close enough to reach (going all the way to 0% instead of only 20% charge, since, being smarter, the bots no longer need that 20% reserve). So it picks the one that is closest to the destination, and flies there.
No need to path-find (the reason suggestions about improving this behavior have been rejected in the past) but instead what's going on is similar to what already happens. Just, rather than waiting until reaching the 20% point to find the nearest roboport, we find it right from the start. So this doesn't require any more computation than the game already does.
Then, after recharging at that roboport, the bot does the same thing: It realizes that the destination isn't inside the circle, and so of the roboports in the circle, it picks the one which is closest to the destination.
Then, step three:
Then step four:
I actually stole the base image for this from another thread where Rseding91 said "As I've said before: this is not likely to ever happen. It would increase the CPU cost of robots by massive amounts for incredibly miniscule gains." However, again, I'm not suggesting path-finding the shortest path. What I'm suggesting is actually fewer calculations than the game already does.
Presently the game:
1. Checks if bot can reach destination. Upon realizing that it can't:
2. Calculate the point at which it would reach 20% charge, and set that point as the destination.
3. Once there, create a list of all nearby roboports, determine the closest one, plus some other considerations like how many other bots are already charging there.
4. Set that roboport as the new destination.
What I'm suggesting:
1. Checks if bot can reach destination. Upon realizing that it can't:
2. Create a list of all nearby roboports, determine the closest one, plus some other considerations like how many other bots are already charging there.
3. Set that roboport as the new destination.
It's one less step. Thus, this won't hurt game performance, it'll actually improve it.
These bots are able to pick up and drop off items on their own, and they're able to fix broken equipment, but they have no idea when they're going to hit 20% charge and no ability to plan recharges? It's silly. Especially since it wouldn't require any more calculation than the game already does, if a bot isn't going to reach it's destination, it should head for a recharge station instead.