I was having a hard time getting the “enemy” (cone) to stop before the collider collided with the player (cube), so I did what here in Brazil we call “Gambiarra” (it’s improvisations) and the result was that:
Basically they are two cubes, one of them is navagent and goes to the player when he is at a specified distance, the second (the cube behind), is in parent with him, then the enemy (the cone) is in navangente following the parent cube ( using “On Update”, because we always want him to follow this cube), so we have no problem with the enemy n bugging the parents.
Tomorrow I should record a video showing how I did it with audio in Portuguese for my followers, if anyone wants me to make a video in English too, just write the request here in the comments.
Update:
I had problems with the enemy’s Z vector putting it as NavAgent, to solve that I put a “set Transform” node, to receive from the second cube (which is parenting with NavAgent) the X & Y vectors, receiving from it the ‘Z’ '(this was important for node “set transform” not to set the value 0 to vector Z).
I had problem with node “remove object” too, if I remove an object with NavAgent script the game crashes.
with the navmesh in the BGE, your npc can’t jump from it (1 level to another 1), and dealing with stairs is an horror ; your npc is stucked … worst , it’s stuck sometimes, so it makes you waste time trying to fix it.
With a checkpoint system, your npc can move more freely. Just have to pose checkpoints empties on the map , then use a shortest path algorithm to indicate a steering actuator the way to go.
the NavMesh system is the BGE is very bad. It’s better with Armory ?
Not sure how bad it is in BGE, but in Armory is quite … limited at the moment.
The navigation work is delegated to the javascript port of the Recast library which works fine. The port uses js Workers to have the heavy stuff of the library work smoothly and not choke the application. This bring a problem to the table, Krom, the technology behind Armory for JS, currently doesn’t support workers. This means that right now there are some limitations when using navigation, for example, not being able to have multiple agents navigate and not collide each other with the power of crowds.
A fast but maybe not so ideal alternative would be to patch out the worker usage in the library port, it may work fine when having a few agents in the scene, so it may be worth the try.
On another note, there is currently an issue with the “height” information that the library returns to Armory when doing the calculation on meshes with height that is worth investigating.
You might have noticed that the character probably have their feet or more of their body sunk in the mesh when going over meshes with different heights.
I tried to workaround it with a patch on the “agent mover” code but it had inconsistent results so I had to remove it when updating the navigation code.
At the moment you might have to find a solution that suits your project for yourself, like reapplying the offset in the agent mover, or maybe something like raycasting the character in the Z axis and make it stick on the floor.