Agents stuck on ledges when following a target

[TheFamousRat]

System :
Godot version : 3.2.2
OS : Ubuntu 20.04
Version of the addon : last commit, 0616bae

Description :
Hello,

In my project I want to enemies to follow the player. Most of them are fighting in melee, which means they need to monitor the player's position very closely to deal him damage. To do that, I call the crowdAgent.moveTowards(target) method of the agents quite often, which I suspect might be the culprit.

The result is that when there are multiple agents, they will sometimes get stuck on ledges, overlooking the player as well as they can, but not going straight to him. That situation remains when the player moves : the enemies just slide along their ledge to get closer to the player, but don't take a path that leads to him.

Here is an illustration. On the first picture, they are on a location overlooking the player, and don't take a path that leads to him.

On the second picture, an illustration of the situation after the player moved. The enemies moved along the ledge, but again didn't take one of the paths leading to the player.

Steps to reproduce :

• Build a NavigationMesh on a map with ledges.
• Add a few agents, that will follow a moving target. In my case I did that by calling often crowdAgent.moveTowards(target). This was not done at every _process method call, but with a Timer. However, the problem occured with both _process or a Timer
• Put the target on the ledge, first, wait for the agents to start tracking him
• Move suddenly the target at the bottom of it, as if he jumped. The agents will get stuck on the ledge, even if a path to the target exists.

Thanks for your help,
TheFamousRat

[TheSHEEEP]

To be honest, that seems to be more of a problem with the underlying Detour/DetourCrowd and not really a godotdetour one.

Godotdetour "just" implements the library and reports the positions & velocities it gets from it back to the engine via the agents.
There's no pathfinding logic directly in godotdetour.
The only "special" behavior in godotdetour is the reporting of what godotdetour considers a stuck agent.

The situations you describe are typical fringe case scenarios for pathfinding that often tend to be troublesome - the target is very close, but actually very far away path-wise. This generally tends to make the pathfinding take a long time (it's kind of the worst case scenario, at least for A-Star implementations) and some algorithms might give up on the task before finding a route.

It's also possible this situation can somehow be avoided via different settings (larger/smaller cells or other changed setup values, maybe).
Either way, I'm afraid there isn't really anything I can do from my end to help you there. I'd suggest going over to the actual Recast & Detour repo and ask people there (they also have a mailing list) - they are bound to know a lot more about the internal workings of detour than I do.

If you do find a solution for this problem, please report back, as I'm sure others will have an interest in this as well.
And who knows, maybe there is something that could be done about it within godotdetour itself, though I have my doubts about that.

[TheFamousRat]

I see. Thanks for your quick answer.

I will try a few things on my side with godotdetour. The first curious element is that if I simply place the agents directly on the ledge and ask only once them to go the player beneath, they will follow the path. Similarly, it seems like if I update the requests very sporadically (once every 10 seconds), the agents will find the correct path. I suspect an underlying issue with the initialization of the agent's new path.

The second thing I will do anyway is clean up the navigation mesh here. It is quite dirty frankly speaking right now, which might not help. As you suggested, I will also try tweaking the parameters some more, it actually seemed to solve the issue for some ledges.

Will keep this thread updated if I find anything that might bring a fix.

[TheSHEEEP]

Yes, that does sound as if requesting a new path too often will cause problems. I'm not an expert of the internals of detour/detourcrowd, but that does sound plausible, considering detour is itself threaded.

While it is a very good pathfinding library, it is definitely not issue free and requires some workarounds every now and then.