Change Details

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 simply stops popping after a while, making for overall saner 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. I've also increased the maximum # of failed paths from 15 to 20, as with 15 I still got some units to go in "IDLE" mode, which no longer happens with 20. I think this replay is a //really// extreme test of UM's ability, so that value probably shouldn't be bumped much further. Reported By: Angen

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

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 simply stops popping after a whiledeletes waypoints within a ratio of the search space, making for overall sanerto 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. I've also increased the maximum # of failed paths from 15 to 20---- 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, as with 15 I still got some units to go in "IDLE" mode,I've overall achieved that. which no longer happens with 20.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, I think this replay is a //really// extreme testbecause from testing it's still too low to avoid stuck units in plenty of UM's ability,cases... so that value probably shouldn't be bumped much further.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