UnitMotion sometimes deletes the next long-waypoint when pathing, to account for cases where it might be inside other entities, and thus unreachable.
However, it doesn't make sense to pop _too_ many waypoints, since at some point the enxt waypoint will be so far away that the short-pathfinder won't be able to find a path that makes sense anyways, and it kind of plays badly with the incremental search-space feature.
This deletes waypoints within a ratio of the search space, to improve behaviour.
If you check the original replay from #5795, you can see this bad behaviour as units try to go through both dead ends around the corridor, before turning back. With the diff, they no longer do that.
----
See comment below:
- Rename m_FailedPathComputations to m_FailedMovements. m_FailedPathComputations was really more of a counter since the last time we moved, and as noted in D3209, I should increment on obstructed moves, not only failed paths. This enforces that.
- PathRequest also doesn't immediately re-request paths, that's handled in Move() entirely, making the logic there smaller. Should also help request fewer paths.
- This cleans up the different paths in PathResult(), making the function smaller and easier to read.
- Tweak of a lot of the magic numbers surrounding obstacle avoidance and shortpathing. Overall, my goal was to speed up short path computations by doing computations less often and over a shorter distance. From some testing, I've overall achieved that. I think the stability remains good because the overall behaviour doesn't change and UM had pretty good heuristics for stability.
- Increase the # of failed movements, because from testing it's still too low to avoid stuck units in plenty of cases... 30 is only 6 seconds in SP (15 seconds in MP) and that's sometimes not enough for units around to move.
----
Reported By: Angen