implement DONOTENTER material to discourage a bot to enter a place while providing a navmesh to escape from it

[illwieckz]

In Quake3, the DONOTENTER contentparm is preventing a bot to go into some place, while allowing it to be pushed into that place (for example from explosion pushback). That can be set in places filled with lava that would not instantly kill (so they may have time to escape), or places that are not very bot friendly.

The tracing like implemented in #2575 for playerclip material surfaceparm may prevent them to go there from their own. The drawback of such clipping implementation may be that a bot may be blocked if it believes there is a route but the route is clipped for it, and it has no easy way to walk around.

A second way to implement the feature may be to compute but disable navmeshes in brushes having DONOTENTER (like if it was an unopenable closed door or a large model), and to deactivate the blocking when a bot is inside the said brush.

[Viech]

Adding a reference to #1443 for a related contentparm.

[ghost]

The tracing like implemented in #2575 for playerclip material surfaceparm may prevent them to go there from their own. The drawback of such clipping implementation may be thatt a bot may be blocked if it believes there is a route but the route is clipped for it, and it has no easy way to walk around.

Exactly.
We need to stop relying on traces to drive a bot's direction, this only gives us troubles and should only be used when there is no other choice.
The only valid case for the use of "directional traces" is to steer around other players, because we can not use DetourCrow. For all static or predictable dynamic map elements, we should rely on recast, and only recast.

The reason we can not use DetourCrowd is that our agents needs their own navmeshes, because of their different sizes, and DetourCrowd requires all agents on the same navmesh. We could be able to use DetourCrowd a bit to improve navigation though, as most humans have the same size (except for BSuit), and I even think we could simulate naked, light, medium, BSuit, dretch, and mantis on a same navmesh, as their widths are the same, and that's probably the most important thing.
At the very least, we could use crowd for all classes which have the very same sizes, so, all humans except Bsuit, and dretch+mantis.
This would possibly help a lot, but this should be considered post-stable considering the complexity and risks.

The solution to implement the requested feature is, instead, much more simple: we need to increase the tile travel cost of those areas. Oh. And to implement #1673 obviously.

[illwieckz]

The solution to implement the requested feature is, instead, much more simple: we need to increase the tile travel cost of those areas.

Ah yes, right! Cost solution is better.