Update Princess hazard calcs and settings

[Sleet01]

Adds a hazard estimate for Deep Snow and Rubble to Princess' path planning, which previously would cause frequent bog-down rolls due to ignorance Deep Snow's effects and PSRs from entering Rubble willy-nilly.

Deep Snow has no innate damage hazard, but contributes two hazards that could lead to sub-optimal performance for most units:

1. +1 to all PSRs made within the hex.
2. Chance to bog down, leading to the unit taking more damage or being unable to fight effectively.

Like Mud, I've used a base hazard of 10.0 to represent the difficult-to-quantify negative score of the possibility of making a PSR or bogging down in the Deep Snow hex.
This is further modified by the units' piloting abilities and the estimate of how easily the unit might bog down, added to the number of turns it would take on average for this unit to escape being bogged down.

Conversely, Rubble can cause a PSR to affected units but only Ultra Rubble increases the PSR target by +1.

This patch now also includes updated titles for the bot config dialog's sliders, as well as corrected Bravery slider labels.

Note: given that Deep Snow does provide some benefits (additional heat dissipation for leg-mounted heat sinks; -2 to ejection rolls) we may wish to rank this hazard slightly lower than mud; in that case, I'd guess a hazard of between 5.0 and 8.0 would be appropriate.

Testing:

• Ran bot-vs.-bot tests with average IS skill pilots on a map with many centrally-located Deep Snow hexes.
• Ran all 3 projects' unit tests.

[pavelbraginskiy]

Would it be possible for the hazard level to be lower only in the case that the unit in question actually has leg-mounted heat sinks? Because it's not a very common feature at all.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 28.97%. Comparing base (2582273) to head (4532350).
Report is 3 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #5857      +/-   ##
============================================
- Coverage     28.98%   28.97%   -0.01%     
+ Complexity    13909    13908       -1     
============================================
  Files          2512     2512              
  Lines        267268   267308      +40     
  Branches      47786    47798      +12     
============================================
  Hits          77464    77464              
- Misses       185854   185895      +41     
+ Partials       3950     3949       -1     

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

[Sleet01]

Would it be possible for the hazard level to be lower only in the case that the unit in question actually has leg-mounted heat sinks? Because it's not a very common feature at all.

It would be possible, but would require either plumbing in that information as a parameter, saving it in the basicPathRanker, or calling some equipment access functions on the unit from within the hazard assessment functions, which I really don't want to do - these get called multiple (possibly hundreds) of times for each unit / possible path / hex and I'm worried about the performance hit.

Actually, now that I look at this, we probably want to be caching the hazard value for each unit / hex / movement mode combo. And in fact there's a TODO in the PathRanker.java file requesting this...

[NickAragua]

I would recommend adding "leg heat sink presence" to the CachedEntityState (more generally, add a hasWorkingEquipment(location) function and supporting data structure).

[Sleet01]

I would recommend adding "leg heat sink presence" to the CachedEntityState (more generally, add a hasWorkingEquipment(location) function and supporting data structure).

This sounds like the best option, but at this late stage of 0.50.0 development I don't want to start work on it. Seems like a good candidate for 0.50.1.

[Sleet01]

Going to add Rubble handling as well.