RedViper wrote: Fri Sep 01, 2023 3:44 pm
Regarding the pathing over lakes: it seems that now you are using the selection of a roboport closer to the destination basically as a failure mode for when the ...
This has a few problems, first it's more UPS intensive, I think the devs have stuck with the "path in a straight line" because of just how fast it is.
I've heard this a lot "it's more UPS intensive" seems the catchall counter to "bots should be better". I don't see any reason why this would be noticably more UPS intensive. The operations involved are:
1. like 4 multiply operations to find the location the robot would recharge at
2. "find roboport to recharge at" (notably this operation would have had to be done anyway)
3. literally nothing else
I'm not clear why it's believed this problem exists, and I'd like you to explain what you think would be so UPS intensive
Second, in several situations it would actually be slower to do what you suggest than just path in a straight line. Even the implementation show here suffers from this, it takes longer to go to a nearby port and recharge than it would have taken to just fly on low energy to the final destination.
Well, no, the implementation shown here is objectively better than the original, performing at least as well. Note that in the original, flying on low energy to the destination was not the behaviour the bots showed. They just got stuck. The new behaviour is an improvement.
The solution we are proposing can *literally never* result in a longer path than the new behaviour. It doesn't result in the best possible behaviour, but it is a good approximation, and a consistent improvement is a consistent improvement.
Proof that it is always better:
- If the previous behaviour would reach the destination without recharging, the proposed behaviour would also do so.
- If the previous behaviour would not reach the destination without recharging, it would instead take a non-straight-line route to the charging point. The proposed behaviour takes a straight line route to the charging port, which is shorter.
There are no other cases, so the proposed behaviour is always as good or better than the new behaviour, which is as good or better than the old behaviour.
There may be other behaviours which are better yet, but again, improvements are improvements.
If you can find a flaw in this proof, (or just a counterexample), I'll consider it, but, like, those are the only cases.
To fix the second issue you'd need to make estimates for how long both paths would take and how long it would take the robot to recharge, but again this makes robot significantly more UPS intensive.
Yes, path finding would be better for bot routing, but would be UPS-intensive, hence, the proposed solution is not path finding.
kajacx wrote: Fri Sep 01, 2023 12:44 pm
...
This is adressed in the last topic of the FFF.
And see above for why your proposed fix doesn't work (Imo anyway)
No, the last part does not address it. If there is no closer roboport to the destination than the drone currently is, the drone will still turn around, away from the destination to recharge, at least, that's my interpretation. They stated:
...so that the robot tries to always charge at a roboport that is closer to the destination than the robot is...
so the current logic would seem to apply in there were no roboports closer than the robot. Of course, that's up to interpretation, and we'd have to get the devs involved to clear it up. Either way, it's not clear they've solved this, though crawling to destination would be an 'alright' solution. It's just really annoying to be waiting for a drone to do something, and watch it almost get there, then turn around and recharge. This hasn't changed.
Same as above, this solution, while it works, can make the robots slower is some situations and would make them massive performance hogs.
Again, same as above, this can't make the robots slower in any situation, except in comparison to a hypothetical alternative routing system, which doesn't exist.
Also same as above, it doesn't seem to add any non-trivial performance cost to robot journeys. A single linear extrapolation per flight is, like, almost exactly nothing. If you want, I could work out some sketch code, and count processor cycles for you, but that seems unnecessary.
The proposed changes by the devs do solve, like, a lot of the issues, reducing the savings from this approach, but a huge factor is how much it would reduce the visual annoyance and make the robots look smart(er).