Crouch-jump constants recalc for bot ledge NavAreas

[sunzenshen]

Description

Aims to fix bots trying to climb ledges that they don't have enough crouch-jump height to pull off, by recalculating the underlying constants used by the bot locomotion interface to determine climbing eligibility for adjacent NavAreas.

Toolchain

• Windows MSVC VS2022

Linked Issues

• related Spread out bot teammate path planning #1535 (This PR made the issue more obvious because earlier all bots would follow easy paths, but the newer dispersal logic encouraged bots to take paths that were of impossible jump height differences for their class choice.)

[sunzenshen]

In a similar situation portrayed in this clip, previously bots following the same destination would try to jump up onto the trailer despite not having enough jump height, because under the hood their teammates had reserved the lane besides the trailer for traversal. Also note, at the 10 second mark, that the Recon class that is intended to make the jump can still do so with the PR's changes. The theory for this PR is that now bots of heavier classes will classify the sides of the trailer as too high to jump on top, which prevents them from attempting the climb.

bot_jump_crouch_height_recalc_constants_clip.mp4

Here's an example prior to this patch where a bot decides that they can make the jump on top of the trailer as a shortcut to the objective, but then they get stuck repeatedly failing to make the jump:

20251210-1211-59.1626480.mp4

^ (Video credit and initial bug report: @AdamTadeusz )

[sunzenshen]

As a demonstration of the before/after A/B test for this fix, I used a cherry-pickable version of PR #1345 to demonstrate the effect these height constants have on pathing:

Before (on branch #1345 without the fixes from this #1558 PR):

bot_command_debug_before_jump_height_fix.mp4

After (by cherry picking #1345 onto a temporary copy of this branch #1558):

bot_command_debug_after_jump_height_fix.mp4

[sunzenshen]

To start the conversation, in my testing on different maps, it seems like Support struggles the most when trying to jump onto elevation changes that are within this threshold, while Assault and Recon are generally more adaptable given their more conservative thresholds. Maybe we should consider some sort of standard lift gap and make that consistent between all the classes? For example, what about a standard gap of 7?

e.g.

Recon: 54 + 18 - 7 = 65
Assault/VIP: 36 + 17 - 7 = 46
Support: 36 + 11 - 7 = 40
Juggernaut: 50.4 + 13 - 7 = 56.4 (or round down to 56)

[sunzenshen]

It's really important for behavioral smoothness for Support bots to have a different navigation height clearance so I went ahead with applying the consistent 7 unit gap to all classes, such that Recon has the same height budget as before.

[sunzenshen]

Clicked the rebase branch in the GitHub web UI, so this rebased build should have the bot commands feature.

One can test the jump heights attempts in maps by using the following commands:

sv_neo_bot_cmdr_enable 1;
sv_neo_bot_cmdr_debug_pause_uncommanded 1;
neo_ctg_round_timelimit 99;

Then one can press use on the paused teammate bots to get them to follow you, and then use the ping button to have bots walk between different areas that might be suspicious.

[sunzenshen]

Intentionally NOT rebasing on top of #1601, in order to make this easier to test.

But we probably should consider evaluating this before I either forget, or there is a need to resolve a merge conflict. But maybe neither of those scenarios is a big deal anyway.

[Rainyan]

Would be good to debug-assert sv_gravity == 800 here if we're hardcoding that assumption, so that this blows up more prominently when that is not the case.

[Rainyan]

Are these values intended to reflect the actual maximum crouch-jump heights for the classes? The recon (65 units) and assault (46 units) values are accurate, however the support value seems incorrect. Supports have the same max jump height as the assault, AFAIK.

You can test this in the devbox map with sv_neo_can_change_classes_anytime 1, using the ledges that go up in 1 unit increments (there's a visual marker per every 16 units).

As for the JGR, I have no idea, couldn't figure out how to spawn as one. I guess I can try to recompile the devbox in JGR mode later...

Also should be noted, the 65 and 46 values are for the crouch-first-then-jump (or possibly crouch & jump on same exact tick? i'm unsure) maximums; for a more typical user input (jump-then-crouch), the max heights are about 1 unit less. But I guess the bots should know how to use the optimum one, because some jumps in some maps do indeed use the crouch-first value as a form of a "trick jump", or just by coincidence, and we probably do want the bots to be able to perform these jumps that normal players also could.

[Rainyan]

Oh, I see you've touched upon this in #1558 (comment) already.

[Rainyan]

Personally not a huge fan of fuzzing the variables with some magic offset, especially with a descriptive name like <CLASSNAME>_CROUCH_JUMP_HEIGHT - would prefer we separated any such magic as its own value separate from what we know is the real max height clearance. But for the sake of getting these nav improvements in the game, I guess we can merge this and leave the refactoring for another time.

One way we could decouple the real jump heights could perhaps be to return <CLASSNAME>_CROUCH_JUMP_HEIGHT + /* some offset as required */ from CNEOBotLocomotion::GetMaxJumpHeight, so it was more obvious what's going on when looking at the code, rather than directly modifying the defines to differ from the empirical values.