A wonderful feature in the old pathfinding service that, unfortunately, is missing in the new one.
Previously, if you wanted a path between START and FINISH, but no path can be established (e.g because of a wall surrounding FINISH), the status of the path would be âEnun.PathStatus.ClosestNoPathâ, and would return the closest path that it can find to FINISH, which doesnât actually reach it. This was great for AI that chases the player because if the player is hidden somewhere or is in a spot that glitches the pathfinder (e.g in furniture or a bunch of small parts), then the robot would at least have a lead to work with, the closest path to the player. From there, it can try other methods of locating the player.
However, the new PathFindingService allows only 1 status for an unsuccessful path, âEnum.PathStatus.NoPathâ, while returning an empty path object. No closest path. This makes it unbelievably frustrating to work an AI because of constant terrain glitches that result in no path and with no lead for the AI to take.
In short, I think that the old âClosestNoPathâ status should be returned with its associating function that gives you the closest path to FINISH, even if a normal one is impossible.
ClosestNoPath was a PathStatus, it wasnât a parameter from what I can tell. You arenât telling Roblox to find the nearest path to the goal, Roblox is telling you it canât find a path but will give one that gets you as close as possible to the goal.
This feature would be pretty cool if it isnât already a thing, for purposes like the example given in the main post.
Computing another path may not be that performant, so i suggested a parameter that would tell roblox to try to find the closest path(maybe use the same PathStatus even)
I really hope that this feature gets added, because the current pathfinding makes RTS games using it extremely unreliable. For instance if the last meter of long path is unreachable, it doesnât make any sense for the path to be completely invalid in my opinion.
This is the exact reason why Iâm honestly finding the pathfinding system unusable. I want the AI to flee from battle. To do this, I have them path towards their spawn. They dropped down a ledge when getting out of spawn so they canât get to the spawn itself, only close to it. But because they canât get to the exact vector3 I specified for the destination, it wonât even try so when my AI should be fleeing, it instead sits there and dies.
I canât imagine how Roblox thought this would be desirable functionality. Iâve spent countless hours trying to âfixâ my crude paths so the character will actually move instead of just sitting there complaining. I canât just give it a random point in a sphere to walk to, itâll just complain. I have to pick a random point in a sphere above the ground, raycast downward, and then tell it to walk there, where the raycast hit.
I am this close to just giving up and writing my own crude A* pathfinding solution using millions of workspace:GetPartBoundsInRadius calls.
Also, when Iâm calling PathfindingService:CreatePath and describing to it how much space my character needs, why canât I describe its jump height? It keeps trying to jump up heights my character cannot jump up.
I would imagine itâs a byproduct of how the path is computed. Unreachable is unreachable, you would not want an agent slamming into a wall because the target is on the other side, nor would you want the agent to say it can get to the target even if there is a wall blocking the route out, because the âget as close as possible to the targetâ logic could make the agent walk up to the wall because thatâs as close as it can get to the target. I think there should be a way to specify it should get as close as possible instead of it being default behavior.
Currently, the path will return a status. This status has multiple options. One of those options is status.success which indicates that the path is able to reach the target. Another option is status.closestnopath which indicates the AI is unable to reach the goal but will try to get as close as possible. This option is unused. If it wasnât unused, you as a Roblox developer could detect when a path returns this result and instead of following it treat it as a failure and recalculate. Unfortunately, you donât get that choice for some reason because this status is unused. Instead, you only ever get status.nopath where the AI refuses to give a path even if it could get very close to the target.
Iâm sorry, but your reasoning for why they might not use status.closestnopath just doesnât add up. If it was used, a developer could choose if they want to use the functionality or not.
To make it abundantly clear how this worksâŚ
you ask the pathfinding service for a âpathâ object which I will call an âagentâ since that makes more sense.
You then ask that agent to generate a path with a specified start and end pos with an async function.
You check to make sure that agent.Status ~= nopath, and if it does, pick a different destination and try again.
You then use GetWaypoints() to get a list of vector3s you manually make your character follow.
If Status.ClosestNoPath was actually used, then in step 3 above you could check if agent.Status == ClosestNoPath and treat that as a failure and pick a different destination if you donât want that functionality. Your character doesnât move until you manually make it move and follow the waypoints so you can just not do that if you donât like the agent.Status. With the currently implementation however, if I do want that functionality and do want the character to get as close as possible even if the target cannot be exactly reached, I cannot. Either the target can be exactly reached, or I get Status.NoPath. No in-between.
I was suggesting why their reasons might have been to not make âget as close as possible even if there is no direct pathâ default behavior. I still think it should be a feature that can be used by developers that need it:
This is something I really need, in fact is not like is just one occasion where I need it. I need it everywhere as I am in need of making the NPCâs walk towards a specific position which can be blocked by another object.
At the current moment I am using PathfindingModifiers to kind of ignore the object and the path would complete to success, and then I would fix the path, so it stops before going inside the target using raycast.
I am honestly tired of doing this as a work around to ignore objects, please make it so there are Waypoints still inside that can be used to walk the NPC.
For example, I have a lumberjack in my game, he gets the nearest trees, and he needs to walk up to them. The path will automatically fail since I use the Pivot position for it which can be inside the terrain, trunk, etc.
I recommend just adding the Waypoints when requested if the path created specifies to do so for Pathfinding because developers are still assuming the Waypoints list is empty when there is no success for the path.
Unrelated But Needed
Please fix the Waypoints, I hate when they are inside of terrain or even really close to each other (sometimes in circles). My NPCs are also jumping around like crazy in places where jump is not required.
I use pathfinding for any object as it seems to work perfectly fine for them. However, since Waypoints are underground sometimes how am I expected to make those objects walk to it, if they donât react in the same way a Humanoid will which just walks to the X and Z axis.
Iâm not sure why they wouldnât want it to be the default behavior. Itâs kind of useless otherwise. I understand that there may be use cases where a developer might not want the character to even try to walk somewhere unreachable, but that doesnât make sense to be the default.
Thatâs not default behavior anyway. You implement the default behavior. All it does is return a status and a path. Itâs up to you to check if you got a status you want and to choose if you want to follow the path or not.
Yes!! I donât know why they seemingly just ignored ClosestNoPath when the pathfinding system was rewritten. This makes pathfinding service borderline useless, or just hellish to work with.
There also could at the very least be some sort of way to implement custom character movement, for example: letâs say the player can dash. They can use this dash ability to jump longer distances. Thereâs no way to implement this, aside from spamming pathfinding links in every gap, every angle that they can dash from. Right now it doesnât even use the characterâs jumppower!
Thereâs also the path range issue, nowhere in the documentation or anywhere in general is the max distance a path can span over. And, said max distance is also inconsistent! Iâve seen peopleâs paths not compute over how long they are, only for the map to be moved around (not shrunk or anything, same for the points) and the path computes! Or, how sometimes theres an error message that says path is too long, while other times it just returns NoPath!
Reviving this old thread because this would be crucial for NPC development. It is currently impossible to recreate what PathStatus.ClosestNoPath did. The only way to mimic such behavior would be to create your own pathfinding system.
But this is very limiting and/or less performant (since PathfindingService is embedded into the engine and can therefore run a lot faster), especially for environments that are dynamic and change overtime.
I see a lot of room for improvement regarding PathfindingService and I hope this gets added one day.
Donât understand why this was ever removed. I check this post once in a while and it seems like this is not even a priority (or acknowledged?) while it is arguably very necessary. Weird.
This is something I really need, in fact is not like is just one occasion where I need it. I need it everywhere as I am in need of making the NPCâs walk towards a specific position which can be blocked by another object.
I am honestly tired of doing this as a work around to ignore objects, please make it so there are Waypoints still inside that can be used to walk the NPC.
I recommend just adding the Waypoints when requested if the path created specifies to do so for Pathfinding because developers are still assuming the Waypoints list is empty when there is no success for the path.