Teach bots to go down from crates and ledges (and climb them?)

[necessarily-equal]

So this is definitely an old issue, but it doesn't seem to have a dedicated issue so I'm opening one.

You can find interesting related discussion here #310 (comment) and below.

There are two major approaches that are being considered. The first is what freem calls "the lesser autojump", and the second would be navcons.

The Lesser Autojump

The idea is to change the walkable height in navmesh generation: we pretend the bot can walk up and down bigger steps, and then teach bots to detect something that looks like a ledge and jump if needed. The advantage is that this is very simple to implement in the navmesh generator, and @bmorel has an implementation already.

I can see three problems to this approach. First bots will not detect a jump as reliably and may continue to run too far and miss the jump. Second, it doesn't allow for a pathing cost either going up or down, so bots will try to cut corners very agressively. It also this doesn't allow for different jump height going up, and going down.

The Navcon Approach

The idea is that we would need to autogenerate navcons. For a start, only going down because this is a simpler problem, and unlike with the lesser autojump approach, we don't need to solve both problems at the same time. The other advantage of this technique is that we could have a pathing cost for jumps and falls, even though this would need patching detour. The downside is that this would be more complex to implement, but should hopefully still be doable.

I would prefer to implement this technique, but it is unclear how much work that would take.

Note about ramps

One interesting thing about ramps, that affects both techniques, is that bots may want to cut corners to do impossible jumps. In the picture below, bots need to get on a slope (black). Their path is in red and they have a bounding box at the highest point of the jump in blue. We can see on the first picture that the shortest path that has the right height would result in a collision. One needs to take a longer path (second picture) to be correct. This will have to be taken into account somehow. One can see an example like this in the Chasm map next to the human base.

Straight approach	Correct approach

[ghost]

I can see three problems to this approach.

You missed the most important problem: it's a hack, and to be reliable enough, the heights are capped to a ratio of the agent's height. While this is not a problem for battlesuits, tyrants or adv goons, it's a problem for all other classes.
Also, relying on traces, that is, computer vision, is slow. This have an heavy impact on server's CPU, which could be lowered if the trace's API could provide more information about the position and size where the collision is predicted to happen.
This still greatly improves the situation, though.

Second, it doesn't allow for a pathing cost either going up or down

You can. You only need to patch the navmesh generation code to include those information. It also needs to be done for the crouching feature. Oh, and it could be very useful for water areas. And for damage areas. Probably also for doors.
The only problem here is that it's not implemented. But when wandering around the code, you should see traces of the intent.

Last but not least, it has to be said that this technic can obviously not be used for wallwalking, walljumping, wallrunning, pounces, jetpack, notably because of the capping, but also because of how it would be intense for CPU with traces and the like.
Something that could improve on that would be to have actual ballistic prediction on the jump's arrival. But it's probably not worth the effort.

[necessarily-equal]

Let's note that if there is a navmesh in a dangerous place like in #2408, bots may just randomly decide to roam in it by jumping from a bridge. For example on anthill.

This is also a problem with non-dangerous pittraps. Bots would go down and never get out. for example on Yocto or Nexus6:

[ghost]

This is unrelated to the issue.
Bots currently fall in those pits because of #1673 and #2408. In one case, navmesh is generated when it should not (there are other cases of this, like navmeshes generated on the sky). In the other case, generating navmesh or not won't change anything because bots don't care about navmesh when they fight.

Also, it has to be noted that the lesser-auto-jump hack is not affected by that kind of problem, as navmesh will be generated to both go inside or outside, but only if this is possible.

[necessarily-equal]

It's not so unrelated to the issue, because this is a problem that should be solved as well, possibly before this issue is. This is to avoid creating more problems further on.

[ghost]

I think this issue is solely about pathfinding. The pit traps you mentioned are problems related to those maps. Neither bots nor players would be able to go out of those as tyrant, for example. And bots will only go there if they're fighting.

As for the anthill map, I strongly doubt the problem is about bots trying to jump in the lava: instead, my bet is that they slip, because of the geometry probably, which is the same kind of problems one can see in chasm: bots falling in the chasm because going too close to it, and geometry makes them slip in the chasm.

So, the 2 problems you are mentioning are basically:

• bots ignore navmesh when they fight (aka bots ignore navmesh when fighting #1673)
• some maps have slippy geometry. I do not think this has been reported, maybe it should though. I'd call that a map bug though.

Also note that the 2 pit traps you mentioned use ladders.
The solutions to go out of those are:

• jetpack and using ladders for humans, and jetpack support is very unlikely to be implemented soon (see https://github.com/recastnavigation/recastnavigation/blob/main/Roadmap.md about flying agents).
• wallwalking, walljumping and pouncing for aliens.
• Tyrants have to suicide.

I would call this a map bug personally, but I understand that people will disagree and call that a feature (this implies that in those maps, aliens can't use their theoretically stronger form to attack some spots. OTOH tyrants suck, it's not that new... so not a big loss).
Ladders being what they are in quake3 maps (#1660), that is, ugly hacks that does not work well even for players, it is going to be very tricky to implement automated support. We know it's possible to have limited and hackish implementation for that, though, as I had a PoC (see #1867). As for pounce and walljumps, this is going to be even worst.
The correct solution here would be to have proper ladders in the game, and off-mesh connections added accordingly. Not going to happen, I'm afraid, so if you consider this related, this issue will never be closed.

[ghost]

Can be done with properly placed navcons.