Page 1 of 1
Calculate roboport wait time
Posted: Mon Jun 20, 2016 5:30 am
by DaveMcW
A roboport should keep track of how many robots are waiting to charge at it.
It can be as simple as:
- Robot chooses to recharge at roboport; roboport +1 bots charging
- Robot is finished charging and flies away; roboport -1 bots charging
Once we have an easily accessible robot count at each roboport, we can do some fancy calculations.
Code: Select all
Recharge time = (Flight distance to roboport) / (Robot low energy flying speed) + (Robots charging at roboport) / (Robot charging speed)
Then it becomes easy for robots to pick the roboport that will recharge the fastest.
Another problem is the roboport with the shortest wait time might be in the opposite direction the robot is trying to go. So there should also be a penalty for going backwards.
Code: Select all
Flight distance = (Robot to roboport distance) + (Roboport to destination distance)
This assumes that the robot will fly to its destination on zero energy, which means going backwards is penalized a bit much. We can fix that by adding a discount for flying on a full charge.
Code: Select all
Discount = MIN((Roboport to destination distance), (Max robot range on a full charge)) * ((Robot high energy flying speed) - (Robot low energy flying speed)) / (Robot high energy flying speed)
So the final formula is:
Code: Select all
Trip time = (Robot to roboport distance + Roboport to destination distance - Discount) / (Robot low energy flying speed) + (Robots charging at roboport) / (Robot charging speed)
Re: Calculate roboport wait time
Posted: Mon Jun 20, 2016 12:20 pm
by Rseding91
That sounds nice when you type it out but if that was implemented in the game you would need to run that logic against every roboport in the logistic network every time a robot tried to find a roboport to charge at significantly slowing it down.
Picture some 400 roboports and 15000 robots in the air. Right now they already do a large amount of distance calculations and count checks against the number of robots charging at the roboport. If they had to do angle calculations and energy over time that would add a lot to the simulation and slow it down for not much gain.
Re: Calculate roboport wait time
Posted: Mon Jun 20, 2016 12:59 pm
by Harkonnen604
What would be nice (without need for serious cpu cost or writing fancy algos) is that bots predict point where they become out of power and start heading towards nearest roboport (relatively to that point) right from the start. Currently I see a lot of situations when robot flies to some crate, once out of power or nearly so it changes direction towards nearest roboport, then the bot continues its path towards the crate. The idea is that bot knows its current charge level and distance to the target crate beforehand, so with simple math it may predict a point on its path when it will decide to charge, and thus pick roboport for recharging right away and head right there from the start. That will save some time for bots, for their paths will become "Start->Roboport->Crate" instead of "Start->SomePointTowardsCrate->Roboport->Crate". It's same number of heavy select-roboport calls, they just would happen earlier. And since it will shorten overall distance traveled by all bots, they will recharge less frequently and overall cpu cost will decrease
Re: Calculate roboport wait time
Posted: Mon Jun 20, 2016 1:53 pm
by DaveMcW
Rseding91 wrote:Picture some 400 roboports and 15000 robots in the air. Right now they already do a large amount of distance calculations and count checks against the number of robots charging at the roboport.
Great! So adding some simple calculations shouldn't make things any worse.
Rseding91 wrote:If they had to do angle calculations and energy over time that would add a lot to the simulation and slow it down for not much gain.
No trig functions involved. All the travel speed stuff can be optimized down to 1 or 2 constants.
Re: Calculate roboport wait time
Posted: Mon Jun 20, 2016 2:20 pm
by bobucles
I think there's only two real issues with roboport recharging
1) The critical drop in charging speed after bots run dry. Bots with energy can reach the charging pads at full speed, while empty bots limp over at partial speed. Once a line builds up all the bots are guaranteed to run dry, making the charging process twice as slow, which makes it worse.
2) There's no dedicated charging station. There are all sorts of port/charging station combinations in mods, and most of them are excess baggage. The 3x3 charging station however is just damn nice to have. 4 pads can barely sustain a single stack of logistic drones.
Re: Calculate roboport wait time
Posted: Mon Jun 20, 2016 4:12 pm
by ratchetfreak
Rseding91 wrote:That sounds nice when you type it out but if that was implemented in the game you would need to run that logic against every roboport in the logistic network every time a robot tried to find a roboport to charge at significantly slowing it down.
Picture some 400 roboports and 15000 robots in the air. Right now they already do a large amount of distance calculations and count checks against the number of robots charging at the roboport. If they had to do angle calculations and energy over time that would add a lot to the simulation and slow it down for not much gain.
You'd cache the time per roboport
This allows the robot to search a bit wider for a roboport with the lowest delay until he gets to his destination.
Re: Calculate roboport wait time
Posted: Tue Jun 21, 2016 5:27 pm
by TheSkiGeek
DaveMcW wrote:Rseding91 wrote:Picture some 400 roboports and 15000 robots in the air. Right now they already do a large amount of distance calculations and count checks against the number of robots charging at the roboport.
Great! So adding some simple calculations shouldn't make things any worse.
Rseding91 wrote:If they had to do angle calculations and energy over time that would add a lot to the simulation and slow it down for not much gain.
No trig functions involved. All the travel speed stuff can be optimized down to 1 or 2 constants.
A proper distance calculation requires a square root, at least. If you only care about relative distances sometimes you can compare the squared hypotenuses (hypotenii?). Or maybe you could use Manhattan distances, but then sometimes it will be inaccurate when flying long distances "diagonally".
Edit: not saying they couldn't do it, but a straightforward implementation would definitely need to do some nontrivial computation per bot per frame.