Yeah thats seems to be the case. Going around is potentially related to old algo (unrelated to pass through) . New algorithm should fix that and that seems to work.
1 Like
Sometimes the new algorithm cant decide which path to take it happens when the 2 possible paths are close in length
I wanted to chime in and say this feature so far for my game personally has shown GREAT improvements with my pathfinding AI. some of my maps are quite complicate and the old pathfinding was fine, but with this enabled in studio the paths are a lot smoother/smarter, wall hugging was significantly decreased, and I notice they’re not getting stuck on terrain/objects as often as before. I am super excited to see this fully functioning in game and released 
1 Like
This isn’t related to the beta feature, but while you’re here…
Can this please be looked at? Clearly there’s enough space but pathfinding thinks otherwise. I can’t use a lower radius since the NPC would get stuck on corners. Happens when the parts are placed diagonally.
Also, what…?
Repro if interested:
DiagonalPathfindRepro.rbxl (45.7 KB)
4 Likes
found weird pathfind behavior when a part is angled
goes to the poked navmesh instead of taking the shortest path
issue is not apparent within the old pathfind algorithm
file: pathfindBug.rbxl (65.0 KB)
thanks for reporting. We will investigate.
1 Like
You might be able to get around this in the meantime by having them in different locations in world space (ie, if all were loaded at once, there’d be no overlap)
I’ve got a folder full of rails that the NPC shouldn’t step over in this new algorithim, how would you suggest adding to them because I don’t want to manually (or really through a script) add 13k PathfindingModifiers. It’s a waste of instances…
I am assuming you want to add modifiers because of new algorithm is misbehaving. If so this is a bug and we will investigate this. I requested the repro case in the DM.
Engineers, please consider this feature:
Adding an option to the PathfindingModifier for the object to be completely ignored in the automatic navmesh generator as if its collision is turned off.
During testing one of the maps in my game which involves physics objects falling down and NPCs chasing after players, the NPCs took significantly much longer to compute paths ranging from 5 seconds to 20 or more seconds because the falling objects has a collision shape that causes the navmesh to be more complex than it should, and in gameplay form, these NPCs need to ignore the falling objects that fall onto the ground. If you were to disable falling objects, the path computation does <1 second of compute time. These falling objects are integral to the gameplay, so they should not be disabled.
As far as I know, there is no work around this. Setting collision group for the falling objects to be true and setting CanCollide off does not work and will still treat the object as if it cannot collide. PathfindingModifiers’s PassThrough option does not work because it has to make a navmesh region for that part, which still contributes to unoptimized navmeshes.
Note:
Setting the collision fidelity to Hull does not improve the navmesh. Setting them to box would make their collision too inaccurate gameplay wise. But setting them to box collision does not help at all.
Note 2:
There’s a way to do it, and it’s pretty hacky. Making the object into a model and inserting the humanoid does the trick. Since humanoids are automatically ignored by the navmesh system. No wonder why there’s no option for humanoids to be considered in pathfinding.
4 Likes
@Phoenix1205555
we release a fix for PassThrough door issue.
If you have a repo could you try if the issue still exist.
Thank you.
2 Likes
@Phoenix1205555 : this above fix from @oldmannt should resolve the issue you reported. Let us know
1 Like
Yes, i tested it and it got fixed.
Could you guys remove agent CanJump : bool in favor of Agent JumpHeight : num ? so the path will calculate how much above the next waypoint can be because i want to make a pathfinding that can climb stairs but not jump on the staircase sides. Setting the pathfinding to canjump= false will not climb the stairs at all
1 Like
If CanJump is removed in favor of JumpHeight, there could be compatibility issues with old scripts that rely on the CanJump property right? Or they could add Agent JumpHeight and leave the Agent CanJump as it is or setting it to deprecated. 
1 Like
Also good, but too many variable will cause the pathfinding service to lag more
We have resolved the crash, but it is currently only available in Studio. As a precaution, we’re waiting until after the holidays to re-enable the new Pathfinding for all platforms.
Please continue testing and giving us feedback! If you have a specific test or debug scenario you’d like us to help with in the meantime, please don’t hesitate to reach out.
11 Likes
Having a lot of issues with the pathfinding , I have a large map with lots of terrain, some high, and for example here is an issue. I want pathfinding to find a path on the far right side of the mountain, and it works when I break it up into segments, but I’d like for the path to be able to work without having to break it into segments.
https://gyazo.com/891aec192746b46d72f0b2ee9569294f
https://gyazo.com/577fbe9312ce59ca308f6cfeb5a8e72c
*Edit - given the message 2 up that Pathfinding is studio-only, this is coming from the old version of pathfinding and I must have just missed it before. Would this update resolve this at all or is this limit still in place with the update?
I’m not sure if this is related to the new pathfinding or not, but I seem to be getting an error a lot:
'Failed to add navigation area ‘75’. Only 61 navigation areas per navigation tile can be stored. ’ With varying numbers.
I didn’t notice this before the update at all. Is this related to Costs? Or what exactly is this trying to tell me?