Rfe 6295: teach princess that leaping is dangerous

[Sleet01]

Summary

This patch looks to fix a long-standing issue with Princess pathing where she needlessly risks her units while attempting to close with opponents. The title RFE refers to Leaping (from TacOps) but this likely applies to any number of hazards, specifically during the early turns before fire is exchanged.

Problem

Currently Princess generates a large set of prospective paths for every unit she controls:

1. first every hex on the map* is added,
2. then every invalid / un-occupiable hex is removed,
3. then every path with invalid steps is removed,
4. then every path which takes too many MPs is removed.

This produces usually dozens or hundreds of possible paths to choose from, all valid from a movement standpoint.
During most entity behaviour types, such as fighting or retreating, we then rank all these paths to find the best (or least-worst) option among them.
But during the period where Princess's units are closing on but not yet engaging their enemies, we ignore these paths completely and try to create a very few longest-distance-possible paths to guide each unit towards A) a known enemy position, B) a suspected enemy position (esp. for the heat map), C) a strategic target, or D) the opposite map edge.
The problem is that we currently replace all pre-generated paths with these longest-distance paths, which may mean that a myriad of movement options are replaced by a few, or even just one, prospective high-speed movement path meant to close on the destination as soon as possible. And the way we generate these long-distance paths is ignorant of hazards and PSRs.

Given single, or a small selection of, very bad paths, Princess unfortunately just takes the least-bad option. In testing this bug I found that if one long-distance path contained a leap step, it was highly likely that all did, because they were selected to maximize movement towards a specific hex in a nearly-straight line; no paths that avoid the leap (or other hazards) completely could be generated. I warrant that this is true of other hazard types as well based on code inspection.

Solution

I chose to attack this issue in two ways:

1. Using the generated longest-distance paths (specifically their original destination hex coords), add back some of the already-generated normal paths that provide nearly the same MP usage and progress toward the ultimate destination. I chose +/- 2 MP usage and +/- 2 hexes from the distance travelled towards the destination; this should restrict alternative paths to those that travel in the same direction but leave some leeway as far as positioning.
2. Add additional expected damage calculations for the Leap PSR itself, and for the Fall PSR that accompanies it. These take into account leap damage, leap critical damage, and fall damage, but not Pilot Hit damage (yet)

I additionally tweaked the way that the bravery mod and expected success values apply to the expected outgoing and incoming damage values, to prevent the Bravery/Aggression setting from completely overwhelming the damage avoidance setting in the Bot configuration.

So far I have not seen any noticeable difference in path calculation times between the new and old code, likely because:
A) the unit paths I'm selecting from were already pre-calculated and validated by the time they are added back to the prospective paths list, and
B) the new PSR checks only trigger when leaps are included in paths to be ranked, which should happen less often now.

Testing

1. Added new unit tests to validate the Leap and Leap Fall PSR damage calculations
2. Updated existing path unit test to account for tweaked expected damage values.
3. Ran all 3 projects' unit tests.
4. Ran many Princess vs Princess simulations with Leaping, Sprinting, etc. enabled, using generated maps with large elevation changes:
   4.a. Large and small armies
   4.b. Large and small maps
   4.c. New and old code
   Leap instances were definitely reduced, although not completely removed from every simulation run. They should still be available, after all, just not used inadvertently.

N.B.

*There is almost certainly an opportunity to speed up the initial unit path generation process by restricting its radius to the current unit's maximum MP in hexes, although comments in that code state that this process should be relatively fast even when scanning the entire map.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 28.97%. Comparing base (d326780) to head (b8a0d70).
Report is 41 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #6311      +/-   ##
============================================
+ Coverage     28.95%   28.97%   +0.01%     
- Complexity    14031    14074      +43     
============================================
  Files          2672     2672              
  Lines        269238   269373     +135     
  Branches      47913    47949      +36     
============================================
+ Hits          77964    78053      +89     
+ Misses       187372   187351      -21     
- Partials       3902     3969      +67     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.