Reproduction: Get into a round and observe the NPCs stand idle as they can’t generate paths. Unsure what causes this specifically, though my first report of it was during the map “Verdant Meadows”, which is a large map that contains several physics-based missiles, vehicles, etc.
This issue is currently impacting certain places in my game as well. We have up to 50 NPCs trying to generate paths frequently, but the error described by OP occurs almost immediately and then every attempt to generate a path after that error results in a NoPath result. I don’t know when this started happening, but I do know that this was not happening just a few months ago. I have tried removing every part in the place, leaving only the terrain, and this still happens. Interestingly enough, this does not seem to happen in studio when the game is not running. Here is a place that is being impacted by this issue.
When I enable the “Show Navigation Mesh” option in Studio Settings, the Navigation Mesh seems to repeatedly regenerate and continually fail until it suddenly stops updating and I’m left with an incomplete navigation mesh visualization such as these:
I want to let you know that we are actively investigating this issue.
Since you are both dealing with large maps, and the same error message, it is likely that pathfinding is exceeding its memory budget and failing the path request.
Can you provide more information about how you are invoking pathfinding?
What’s the frequency of the path calls? How many agents?
Are you subscribing to Path.Blocked/UnBlocked?
Could you specify the (aprox) range of distances that you are requesting in the path requests?
If you can provide a bug repro example, it would be immensely helpful.
Pathfinding generation requests can be made several times a minute by several different NPCs. I would say on average there’s about 30 NPCs (agents) and each NPC computes a path roughly 5 times a minute, as if they don’t have sight to an enemy they compute a path, and as maps have lots of cover, they can lose sight of enemies often. Unfortunately this number can vary wildly due to the unpredictability of sightlines, amount of enemies, distance from enemies, etc and so I don’t know how accurate that estimate is.
No, I don’t use either of those events
Path distances can be anywhere from 800-1400 studs on the longer end, but I refuse to generate paths for positions over 2500 studs away (as your service tells me it’s too far away for most generations past that distance)
As a side note, I’ve noticed that truss parts that are loaded into the workspace after the game runs (via the map loading system) seem to be disregarded when the navmesh is generated. I toggled the visibility of the navmesh and I noted that it didn’t have the indicators that would suggest there was a truss that could be climbed.
I’ll attempt to get a reproduction file for this later today, and maybe see if I can get a more accurate read of my statistics mentioned above.
I usually have about 35 agents on the map I have been having issues with on average. The frequency at which I call Path:ComputeAsync(...) is not consistent, but for each agent it only happens when their target position changes, their path is blocked, or they previously failed to generate a path and it is limited to one call per 2 seconds. For the first 30 seconds to 1 minute of game time, all agents have one specific target position set that doesn’t change, so that’s 1 call per agent for the first minute until the NoPath errors start rolling in, and then for each NPC that got a NoPath result, it attempts to generate a path once every 2 seconds. Some of the agents do successfully generate a path at first, but once the “Path request failed due to a navmesh update error” happens (within a few seconds after starting the server), all attempts to generate a path afterward return a NoPath result.
Every pathfinding agent I use has a connection for Path.Blocked. When that event fires, I check if the waypoint that was blocked comes after the waypoint the NPC is currently at, and if it is then I immediately compute a new path, ignoring the 2 second cooldown I have set. I do not make any connections to Path.Unblocked, and I reuse both the Path and Path.Blocked connection for each agent.
Path requests at the start of the server, at the time I start seeing pathfinding errors, are typically 500-800 studs away and they’re all pathfinding to positions within a 50 stud radius around one position.
I will also attempt to make a bug repro example later today.
Here is a place file that consistently reproduces the issue. Just open it and run a server, and the TestPathfinding script under ServerScriptService will simulate the pathfinding usage that I described earlier.
The script will create parts that indicate success/failure with green/red colors accordingly for each path. It will also warn on errors and print path status after each attempt to generate like so:
Thanks for the repro!
In edit mode I also see the debug navmesh with big missing chunks.
The problem is caused by pathfinding is exceeding its memory budget and aborting the request.
It’s related to the terrain, but I can’t confirm just yet the actual root cause.
I’ll keep you posted on any other findings.
@sicknoobie re: truss issue, I will try to reproduce it on my side. If you happen to have a repro file, that would be great.
For the “navmesh update error” bug, we have a fix that will be deployed in next week’s release.
I will keep you posted.
Regarding the truss bug, this is a valid issue, and we were able to reproduce it. @sicknoobie, if it’s not too much trouble, would you mind reporting this in a separate dev-forum thread and tagging me? This will help us track it internally and allow other users to find the post if they encounter similar issues.
