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.