If we attempt to create a Path using ComputeAsync with the pathParameter of “AgentCanJump” set to false, it will always fail to create a path if the destination is next to an obstacle that the Agent would ordinarily be allowed to jump over.
Note that, if the part that the agent would ordinarily jump over is scaled such that the Agent could not jump over it, or that part’s material is blacklisted by the Costs parameter (it cannot simply have a high cost - it must be blacklisted using math.huge), the Pathfinding Service will be able to compute a path (even if the destination part is the blacklisted material itself)
This issue occurs even with PathfindingUseImprovedSearch Enabled. For this Repro file, it is set to Default
Notice that Rig never moves, and Enum.PathStatus.NoPath prints in the output
Alternatively:
Create a part that is large enough to stop a player from walking over it but not large enough to stop them from jumping over it. Anchor this part.
Create another, smaller part adjacent to that large part. This will be the part our Rig will attempt to path to. Anchor this part as well.
Add a Rig on the opposite end of the obstacle from the small part we’ll attempt to path to.
Add a script that uses PathfindingService to create a path from the Rig’s position to the target part’s position, with the pathParam’s AgentCanJump set to false.
Run the game, and notice that the script fails to generate a path.
Video showcasing the bug, and its workarounds, is attached below. Although workarounds exist, they cannot always be implemented as they might interfere with other game features (as is the case in the game I am working on where I first discovered this bug)
System Info: Intel i7-11700F @ 2.50GHz
16.0 GB RAM
NVIDIA GeForce RTX 3060 Ti
Expected behavior
ComputeAsync should be able to find a path around the obstacle
Thanks for your report and repro file, and we’re sorry for the delay in getting back to you. I looked into the issue you are experiencing. The behavior you are seeing is by design, but can feel unintuitive.
In this case, the Rig can be made to always move towards the goal Part even when a complete path cannot be found by allowing the pathfinder to return partial path results. In the script you provided, you can do this by adding ["PathSettings"] = { SupportPartialPath = true }
to pathParams, and the Rig should move next to the smaller Part regardless of the size of the larger Part. Note that this requires PathfindingUseImprovedSearch to be enabled in order to work.
The reason the Rig fails to move in some cases but not others is related to how navmesh is generated over small surfaces. When the two Parts are similar heights, their combined area is just large enough that a small island of navmesh can be generated across their surface. In this case, the nearest point on the navmesh to the goal is a position on this island, but it is only possible to reach this area by passing through a jump link, and because jump links are disabled, pathfinding returns failure.
When the height of the obstacle Part is much taller than the goal Part, this splits up their walkable surface area. The surface of smaller Part on its own is now too small to generate navmesh over it, leaving a hole in the navmesh around it. In this case, the nearest point on the navmesh to the goal is a position on the ground next to the part. Since it is possible to reach that location without using a jump link, pathfinding returns success.
If you need an NPC to always try to move as close as possible to a destination, even if it may not be able to reach it exactly, using partial paths should produce the expected behavior.
Thank you for getting back to me, and no worries about the delay. I appreciate that you took the time to explain this to me!
I did not realize that this was what PathfindingService was doing behind the scenes. I (wrongly) assumed that it was still pathfinding over the part.
Although I will probably be able to use ["PathSettings"] = { SupportPartialPath = true } for most cases, I forsee this being a problem if, for example, I needed an Agent to path up a stack of objects, or a steep flight of stairs.
In the following video, I modify my original repo file such that the Agent attempts to walk up two steps to a destination (the green part, noncollidable). With ["AgentCanJump"] = true, the Agent is able to walk up the steps without any issue. However, if ["AgentCanJump"] = false, the Agent fails to generate a path to the destination.
I assume this is because the NavMeshes for each step are connected by jumplinks. However, as demonstrated, the Agent does not actually need to jump in order to path over these steps. Is there any way I can adjust either PathParams or the NavMesh itself such that the Agent would be able to climb steps like these without requiring ["AgentCanJump"] = true? Should I put in a feature request?
Thank you for the video. You are correct that the agent in the video can walk up these small steps without jumping, so for a normal-sized character like this, the ideal navmesh would be one that is connected across the entire staircase instead of broken up on each step and connected with jump links.
Unfortunately, navmesh generation settings cannot be adjusted. Our current navigation system uses a single navmesh, shared by all characters regardless of their size, and so the maximum climbable step height has been set to a low value to ensure that very small characters will be able to navigate up small steps like these by jumping, although it means larger characters will also need to pass through these jump links even if they don’t technically need to jump.
Please feel welcome to submit a feature request; while we don’t have a timetable for addressing this right now, it’s useful for us to refer to use cases like these when planning future work. If you do submit a feature request, could you please add a link back to this discussion? Thank you!
