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.
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.
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
Thank you for reporting this issue. We’re investigating it we will come back with a response.
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.
Thank you for reporting this issue. Would you mind sent me a repo?
It’s nice to see PathfindingService is getting some improvements. However, there’s still some issues that are plaguing its use from years past. One being, super poor navigation mesh generation. Below is a simple staircase, and the navigation mesh computes in a very abnormal way around it.
I can usually do some little ‘hacks’ to force the navigation mesh to recalculate so the area can be traversed, but I’m struggling a bit right now actually.
Thank you for your feedback on the PathfindingService and for highlighting the issues with the navigation mesh generation around staircases. We appreciate your detailed observations and understand the challenges you’re facing.
While we are aware of this issue, we have not yet been able to address it. If you could provide us with a screenshot of the repo where this problem is occurring, it would be helpful. This will ensure that when we fixing the staircase issue, we can also make sure to address your specific concerns in one go.
Thank you for your cooperation and for helping us improve the service. We look forward to receiving your screenshots.
Thanks a lot for your response. I really appreciate the interaction you have with us as developers, instead of sweeping it under the rug pretending like it’s not there.
Additionally, I did notice the navigation mesh is actually there, it’s just underneath the stairs so you can’t see it. And I did some further testing and the AI started working properly again, which is odd because I didn’t change a whole lot.
As of now, it does seem to be able to traverse the stairway properly. At one point it failed trying to reach a certain point of the top platform of the stairway, but for some reason it hasn’t been doing that again which is interesting.
If it continues to happen, I’ll send some screenshots of the problematic areas along with the generated navigation mesh.
Thank you guys for the pathfinding updates, it’s significantly better than it was.
Stairs are a major pain point for my game, which completely relies on pathfinding for the main gameplay loop. It’s been a headache for years and I was very disappointed to see basically no improvement with the new algorithm, likely because the navigation mesh itself still has many issues.
Here is an example of weird behavior with stairs. When the top stair has cancollide turned on, the navmesh looks like this.
When cancollide is turned off, the navmesh fixes itself. (mostly)
This is actually newly broken, as this map did not have pathfinding problems here until recently. Would really love to see more improvements, because as of now pathfinding incentivizes boring flat maps to reduce failures. We are definitely suffering a loss of players when they constantly encounter issues like this.
Edit: I’d like to add that many of these issues seem to not occur while testing in Studio. Once published and tested in game, the pathfinding breaks much more often. One of these problems is pathfinding directly through walls. On maps that I can’t replicate those bugs in Studio, I receive a large number of complaints from players.
Thanks for reporting these issues and I’m very sorry to hear about the frustration they’ve caused you.
Regarding the newly broken stairs navmesh, could you please send me a minimal place file that contains just those stairs? This will help us investigate what might have changed.
Regarding the through wall issues that are hard to reproduce in Studio, if you have a place file where this occurs in-game, even if you can’t reproduce it in Studio, please do send it over. We have received other reports of pathfinding through walls and are actively working on addressing these problems.
Hello!
From the debugging and testing we’ve done, “PathfindingUseImprovedSearch” can cause random server freezes/crashes.
We can’t find a way to replicate it at all, but we know that crashes happened every so often while the setting was enabled and since we disabled it, we had no report of crashes.
This is a medal clip from one of our players that shows the bug happen along with error/shutdown message and error code: bot commander freee/crash - Clipped with Medal.tv
We are not heavily relying on pathfinding for movements, only in specific cases when a bot is stuck and can’t move using :MoveTo
–
Also on another note, this issue is not solved with the “PathfindingUseImprovedSearch”: Pathfinding randomly returns NoPath when the agent is stuck to a wall