NavMesh Path Dispersal: Oilstain

[sunzenshen]

Tweak pathing flow for ntre_oilstain_ctg bot paths.

Leverages a new NavArea reservation system where bots can spread out which paths they take. This example NavMesh tweak to ntre_oilstain_ctg tweaks the NavAreas to encourage bots to spread out when crossing hallways.

• Related: Spread out bot teammate path planning neo#1535

[sunzenshen]

Probably needs NeotokyoRebuild/neo#1535 to be merged in first to have significant effect, but navmeshes can be previewed by executing nav_edit 1 in the console

CC: @AdamTadeusz for previously generating the navmeshes.

The impetus for this PR is that when combined with NeotokyoRebuild/neo#1535, we can use the NavMesh generation process to influence the navigation path selection of bots. The map oilstain was chosen to demonstrate these navmesh tweaks, as it is a map with many long hallways. The pattern implemented with the NavAreas is intended to slightly encourage multiple bots to walk down one dedicated side of a hallway as opposed to walking in the middle of the hallway in a line.

For example, the hallway leading to the office goal point:

Or the hallway leading to the maintenance corner:

(Incidentally, the Areas around the box to the left and another in this hallway needed fixing as well.)

The end result ideally leads to better usage of space in hallways, as opposed to the prior behavior of following in a single file line:

It's also possible to encourage bots not to walk across more sparsely populated large NavAreas, by clustering multiple lanes of navmeshes around such open spaces:

---

Beyond tweaking the navmeshes around bottleneck areas, there were a couple disconnected navareas were manually connected to fix bot pathing issues between those areas.

For example, bots would never cross this doorway threshold because the NavAreas between had no connection until a nav_splice was executed between these points:

With demonstrated crossing:

Another added connection point is this squeeze point in front of this parked car:

(Admittedly to my observation, bots still prefer to hop over the hood of the car to pass by.)

There is also fix for an impassable area in the basement, as well as the aforementioned boxes leading to the maintenance corridor.

---

The difference is not visible from the diff, but I did capture a size comparison compared to the console log:

[sunzenshen]

Attached the platform with the trailer to hint to bots that they can jump over:

Reattached the jump up points on the trailer for Recon:
(We might need to adjust the max jump height costs for other classes but I consider that outside the scope of this PR)

Added a splice connection in a shortcut in basement:

Fixed some intersecting navareas with the maintenance corridor crates:

<img width="1372" height="829" alt="Screenshot 2025-12-11 204025" src="https://github.com/user-attachments/assets/535fa17c-63c6-4d13-83b8-6a75af99

559b" />

Attempted to discourage bots from running into some physics props:

Decided to go for a diagonal connecting pattern for corners, with the hope that bots will cut corners when pathing:

[AdamTadeusz]

I don't know if this is a good solution, the size of the navigation mesh is now more than double, and I think having to make all these additional areas is going to make it more difficult for mappers to make nav meshes for their own maps. Perhaps the reservation system is flawed.

[AdamTadeusz]

I think this is a pretty major change to how navigation meshes are made, we should probably have a discussion about whether its worth it, maybe there are other ways to solve the problem that the reservation system fixes without making the navigation meshes stray so far from their auto generated initial state

[sunzenshen]

@AdamTadeusz That's a good point about mappers making maps outside the official lineup, I was kind of in a mindset that any set of manual customization would be worth it for an initial impression, but I admit even I was finding this approach a bit hairy. The reason the sizes of the navigation meshes was doubling was because I was literally splitting up hallways 2x/4x (even 8x in the case of the roof of ntre_bullet_ctg) but if we don't go that route then the rest of the NavMesh tweaks should have more modest impact on file sizes. Another doubt I had about this approach is that splitting up hallways also makes CTG ghost carriers more likely to choose a path that will encounter an enemy due to the increased "flow" capacity of those routes thanks to the NavArea splitting, so maybe having the bots share hallways was too much of an over-micromanagement. It would have been nice for bots to somehow split up a room through pathing, but I did notice that splitting up the NavMeshes had marginal effect of this behavior compared to what I hoped, as the bot routines for combat strafing or retreating largely overrode the effect of careful hallway/room splitting of NavAreas.

I also based the path cost code on \neo\src\game\server\hl2mp\bot\hl2mp_bot.h which in turn is based on \neo\src\game\server\NextBot\simple_bot.h, so based on that "simple" name I guess I shouldn't be that surprised that there might be edge cases from reusing that code with the more complicated movement differences with NT's classes/etc. Thankfully I've also been treating the exercise as a testbed for my CTG bot branch, so the experiments with navmeshs were still worth the effort in my mind. There are some serious auto-generation errors as I've pointed out in the screenshots, but perhaps there are ways to improve that code as well, so that any mappers can inherit any tweaks straight from autogeneration rather than needing to make tweaks.

Immediately to mind here are some ideas we could try:

• Tweaking the path cost for NavArea transitions that are more difficult for bots to transition between. Increasing the jump penalty might be one way to do this. Something like modifying this snippet:

			// jumping is slower than flat ground
			const float jumpPenalty = 2.0f;
			dist *= jumpPenalty;

• Tweaking how NavAreas are generated automatically based on class movement details. For example, while Crouch-jump constants recalc for bot ledge NavAreas neo#1558 addressed class jump heights, I noticed that the automatically generated NavMeshes have awkward crouch under obstacles, so maybe it's worth looking at how nav_crouch annotations are enabled during generation.
• I wonder if there's a way to consider phys objects in the path choices. There are many physics props like chairs and motorcycles that the bots keep tripping over. Instead of manually editing NavMeshes to have bots avoid these areas, maybe we need to either revisit the collision group of phys objects, or see if there's a way to consider the presence of phys objects in path costs.

I do still want to revisit the nav meshes to fix the really broken issues like completely missing NavAreas, broken pathway/doorway connections, but maybe we should look into the NavMesh generation first before then.

For now I'll draft this and the related PRs so I can use the comments as a reference later, but I can look at other ways to address the NavMesh pathing issues through code instead of NavMesh editing.

[DESTROYGIRL]

I agree that if we're deviating from the standard that's defined by nav_generate we should be implementing changes like these into the generator itself instead of editing in post.
It feels pretty hacky splitting areas like this to get the bots to move in a certain way and seems like it would be best handled in their movement code but you can take what I say with a grain of salt because I'm not familiar with it.

I wonder if there's a way to consider phys objects in the path choices. There are many physics props like chairs and motorcycles that the bots keep tripping over.

In these cases, please make a note of problematic areas because real players suffer with the same problem. There shouldn't be so many physics props littered around the floor now that they actually move correctly, so most of the time they can be fixed from within the map by turning them static. This is probably the best course of action here for 90% of the occurrences.
I'm working on an upcoming map fixes PR for the parallax corrected cubemaps, so if a list could be made I can go through them in there