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
Place1.rbxl (63.2 KB)
(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.
8 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
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.
6 Likes
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.
3 Likes
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. 
4 Likes
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.
3 Likes
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
Any chance that the pathfinding system could support agentās maximum turn radius as a parameter in the future?
Up until now, it has been very difficult to have a vehicle type entity that canāt just rotate instantly in place to follow a path. While it can be somewhat solved by having a huge agent radius to give the moving entity more space, it is still very unreliable and I feel like it is one of the few more important features missing to make the pathfinding truly usable for a wide array of cases instead of pretty much just humanoids as it has been up until now.
1 Like