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.
Also revert D2754 / rP23699 by handling it explicitly. Also revert rP22815 which is un-necessary now that I increment the fail-counter in HandleObstructedMove.
Reported By: Angen
