Hi Maloni, thank you for reporting this problem.
Would you mind create and upload a repo place for this issue. That will be really helpful for investigation.
Thank you.
Happens every now and then, but the waypoints generated will be spaced far apart. This has only been an issue for me when waypoints are really far apart, and my system detects that it hasn’t reached the next waypoint in sometime so it jumps automatically to unstuck itself, when it’s not really stuck, just that the MoveTo operations are further apart than expected.
1 Like
Hey there, is there any ETA on when this will get enabled on live? Been working with the new pathfinding and was hoping for it to be enabled on live sooner rather than later. The old pathfinding system just straight up bails on me and doesn’t compute the admittedly large paths I’m asking for it to compute. But the new pathfinding has no issues with the large paths, so I’d like to use it on live. 
3 Likes
Im fairly certain it is already available to be used in live experiences.
Hey, I’m having issues with the new pathfinding involving agent costs. As someone previously stated the agent radius doesn’t work in areas with costs where the pathfinding will now place waypoints on the very edges of areas it’s supposed to be avoiding.
(Note: I haven’t set a cost for “Avoid” in this screenshot, but it is set up in others after this one)
I’ve also had some oddities where “math.huge” costs just don’t seem to work as intended. As shown in the screenshot below the pathfinding just creates this sort of gap in the danger zones and goes through it, possibly could be caused by the layout of the danger zones. Having a bigger agent radius such as 4 causes this occur more often. This can sometimes happen with the older algorithm.
Last but not least, the pathfinding acts really strangely when it has to go into area with a cost. Shown below it causes this weird circling near the end point and introduces some even weirder problems such as incorrect waypoint labels.
Overall, pathfinding costs are currently inconsistent and don’t work as expected with the new algorithms.
I have a copy of the map where I tested the pathfinding if it helps: MapWithPathingIssues.rbxm (71.3 KB)
Here’s the pathfinding agent settings I’ve used:
AgentCanJump = false
AgentRadius = 4
AgentHeight = 5
Pathfinding costs used:
Danger = math.huge
Avoid = 20
Plugin used to visualize pathfinding: Pathfinder - Creator Store
Hopefully these can help with reproducing the issues shown above!
6 Likes
robloxapp-20250211-2205160.wmv (317.5 KB)
No matter how I adjust the parameters, it never takes the shortest path. This issue can be reproduced with just a block.
I tried to repro your case locally since I dont have the exact case you are running. I am seeing this behaviour with old algo but not with new. If its happening with new algo for you, could you please share the repro case
When useImproved disabled
When useImproved enabled
Place1.rbxl (63.2 KB)
I think the correct is the left half to move left and the right half to move right. like this image
(Nevermind, see next post)
I’m having a problem with the new algorithm where it pathfinds directly through 2 walls.
Without the new enabled it works completely fine:
But then with the new enabled, look what happens:
I’m not too sure why this happens. Here’s the navigation mesh (while not in test mode):
Here’s a chopped of version of my pathfinding code:
...
local RobloxPath = RobloxPathfindingService:CreatePath({
AgentRadius = Settings.NPCRadius,
AgentHeight = Settings.NPCHeight,
WaypointSpacing = math.huge,
AgentCanJump = false,
Costs = {
Snow = math.huge,
Metal = math.huge,
},
})
...
local Success, _ = pcall(function()
RobloxPath:ComputeAsync(FromPosition, ToPosition)
end)
Wow nevermind, I forgot I had a cap for the amount of waypoints… oops.
After adjusting this things are working completely fine, but It’s a bit concerning how many more waypoints are generated with the new algorithm. This is a bit specific for my scenario, but the waypoint positions are serialized and replicated, so I’d prefer the least amount of waypoints possible (I already have WaypointSpacing set to math.huge)
Here’s before:
With the new algorithm:
There are a lot of unnecessary extra waypoints around turns. Is this intended? Are there any plans to reduce this?
That’s a keen insight. You’re right, the new algorithm dynamically generates two or three waypoints based on the sharpness of the turn. This refined approach ensures smoother NPC navigation, especially around bends. The previous production algorithm, which simply offset by the agent width, often resulted in NPCs getting stuck in tight spaces.
This improvement focuses on having the NPCs intelligently follow the approach direction and adapt to the shape and curvature of obstacles.
If you notice any performance impact from this, please let us know. We plan to optimize it further down the line.
3 Likes
The smoothened turns compared to the old algorithm does seem like it’d be very helpful in most uses but is actually not what I’m looking since in my case the ‘quality’ of the path is not worth the extra waypoints. This is because I’m using the waypoints to construct a custom path which is then serialized into a string and replicated. Having just a couple more waypoints means a larger string to replicate and therefore isnt favorable (I’m looking for performance over quality).
It’d be nice to have an option to disable the agent adapting to turns, maybe a new option like this:
Maybe im doing something wrong, but the new pathfinding doesnt seem to work in studio, even though i have turned the setting on.
I’m not sure if you’re taking feature requests from here but…
Could there possibly be an agent parameter that determines how far of drops they can take? It would help a lot in cases where we want NPCs to avoid taking fall damage, the NPCs in most games I’ve worked on currently just have a bad habit of just jumping off cliffs instead of walking the way down because it’s directly a shorter path to the end goal. (THEY’RE MANIACS!!)
The reason I’m asking this is because these drop points seem like it could easily support such a feature as seen here.
A lot a people before me have already asked for this as well but possibly we could introduce parameters for how high an agent can jump; I’m bringing this up now because I want to have the NPCs in my game be able to drop down from safe distances, but I also don’t want them to be able to jump. Falling down being separate from “AgentCanJump” would be very much appreciated!
I look forward to seeing how the current pathfinding features can be improved and expanded upon.
7 Likes
Please @watIsInTheName There is a critical bug that causes the new pathfinding to stutter left and right on a moving target!
Please check the Rep:
PathfindingTest.rbxl (80.8 KB)
Also Like @HuntDownTheXboxMan said if the pathfinding could add AgentJumpHeight : float in favor of the current AgentCanJump : boolean and, AgentFallHeight : float as a feature suggestion, since i cant post on feature suggestions. A lot of poeple will find it very usefull
2 Likes
Thank you for reporting this issue. We’re investigating it we will come back with a response.
3 Likes
I think I’ve found a bug.
0:00 to 0:22 is what it should do (the old Pathfinding).
0:22 is the bug (the new one).
Hi Creators,
PathfindingUseImprovedSearch is now restored. If you have already opted in to PathfindingUseImprovedSearch, please opt out now to avoid any unexpected production changes.
Tomorrow, on March 11, we will officially re-enable the production opt-in. We will update this post once re-enabled, and you can opt in again to take advantage of these improvements.
For more information, read here.
2 Likes
Thank you for reporting this issue. Would you mind sent me a repo?
2 Likes