Edit: For those wondering, this is still not fixed as of 2024.
Pathfinding Service will occasionally generate a path that is unable to be followed by larger characters. This is due to a waypoint being too close to an object, preventing wider characters from reaching said waypoint.
Showing the character attempting, but failing to reach the generated waypoint; they idle there until “.MoveToFinished:Wait()” times out
This issue occurs in both studio & live servers. I’ve witnessed this issue for a few weeks as I have only recently began debugging these issues, although it seems others have had this and similar issues in the past as well.
This ‘unfollowable path’ seems to only generate when there is an unobstructed path between the start and the finish
I am using PathfindingService:CreatePath and ComputeAsync with the proper Agent Parameters; I have already adjusted AgentRadius. This issue occurs 100% of the time.
The expected behavior is a path generated far enough from a wall where the character doesn’t try walk right up against it & get stuck due to being too wide. This expected behavior is currently only achieved when an obstacle is between the start and finish.
A hacky solution I came up with was allowing the pathfinding character to pass through obstacles using collision groups and teleporting them to the final goal position if they aren’t close enough after the waypoints run out, although these two workarounds only work situationally and are nowhere near the desired effect
A potential workaround could be to check if there’s anything near/colliding with the waypoint, and if so, manually change the moveto point to avoid the collision. This is likely the solution I’m going to use, though I’m very confused as to why this is still an issue, as it’s very game-breaking on an otherwise very nice pathfinding system. So much work roblox put into pathfinding only to let it be basically useless.
Please do update us if your workaround ends up being successful. I have thought about cheap ways of doing so, and the best I’ve come up with is a GetPartBoundsInBox check followed up with a Raycast to see how close the waypoint is to the collision spot.
Although I don’t usually complain about any Roblox team since they work hard to deliver good a experience for us, support for climbing trusses and pathfinding links was introduced before a fix for this critical bug. Perhaps the priority of this report should be bumped up a bit.
This is likely similar to how I’m going to do it, but I believe It’d be better to use a part like a sphere and GetPartsInPart - getting Bounds would mean large shaped meshes with big bounding boxes would trigger unnecessary avoidance, and only GetPartsInPart uses actual geometry collision.
That being said, using a real part makes it even more a pain in the butt of a workaround.
This is an issue that need to be addressed. If Roblox is trying to deter people away from programming their own pathfinding, this bug must be squashed.
May we please have some transparency from Roblox as to why this issue has gone ignored for 2 years? This is not a niche bug that impacts a few small games. I see this issue occur frequently in various front page games and am even able to break some of them just from walking near a corner.
I don’t know why Roblox can’t fix their own pathfinding service. In pathfinding service, if the path does not turn around a part, the pathfinding service ignores agent radius and just moves straight forward.
This is a path generated with the waypoint spacing being a really high number and 3 agent radius. It looks fine.
Now here is the same agent params but with a different end point.
Here is another example but with the endpoint being closer to the wall.
If there the space between the two points is empty, the pathfinding registers that as being traversable and doesn’t check for agent radius.
I found a temporary solution that would only partially fix it, but it works for my use.
I’m going to put it here anyway. You would need to edit some of it to incorperate other features in the path, and to just get it working for yourselves.
local rayParams = RaycastParams.new()
rayParams.FilterType = Enum.RaycastFilterType.Include
rayParams.FilterDescendantsInstances = {workspace.Map} -- put your own folder here that stores the parts that you want to be included when checking your path.
local function checkWaypoints(waypoints)
for i, v in ipairs(waypoints) do
if i ~= #waypoints then
local firstPosition = v.Position
local secondPosition = waypoints[i+1].Position
local direction = (secondPosition - firstPosition).Unit
local distance = (secondPosition - firstPosition).Magnitude
local raycast = workspace:Raycast(firstPosition, direction * (distance + agentParams.AgentRadius), rayParams)
if raycast then
waypoints[i+1] = {Position = firstPosition + (direction * (raycast.Distance - agentParams.AgentRadius))}
end
end
end
return waypoints
end
The problem with this is that it would kind of fix the issue when the path is in front of an object that it needs to go to. This does not fix clipping corners in some scenarios, but would fix things like diagonally gliding across the wall when moving with a wide NPC. I’m working on a new version that will shoot raycasts on each side of the path to check if there is a part there, and adjust the path accordingly. Note: I probably need to edit this script because it works, kinda.
Great example, this issue certainly does get worse along a lengthy wall. Whether it be a wall or corner, the issue certainly does come from there being no regards to the agent parameter’s size if a raycast initially determines there is no obstacle.
A year ago, I understand why it would seem difficult to fix due to requiring many more raycasts and may impact the performance of some games. However, now that shapecasts have been released, would a simple internal fix not just include shape casting the radius of the agent parameter instead of firing a single ray?
That’s what I was working on adding, originally I was going to fire two rays on each side of the NPC, but I was finding an alternative using a shape and slightly moving the NPC’s goal based on the position. I think I finished or mostly finished the two ray alternative but I’ll try to make one using shape casts instead. Basically, I forgot about shapecasts for some reason.
I tried using a shape cast with default roblox pathfinding and it kind of works in some scenarios, unless I coded it wrong. It’s mainly because roblox still tries to find the closest path, even if it clips the corners, and I’ve tried with a bigger agent radius. At this point, making a third party pathfinding solution or using one that was already made will probably be the best solution to this problem. Another solution would be to make a bunch of parts in the corners or just make certain paths and map each point the pathfinding service generates, to the closest point on these paths, or use a system that would just use these points by themselves. I’m thinking that this would be a decent solution to things like NPCs chasing the player in smaller maps, and switching to pathfinding service when close enough to the player. I think that this logic can be applied to most instances where someone would use pathfinding service, although there are sometimes where this wouldn’t work. I still hope that roblox improves their own pathfinding system so developers wouldn’t have as much of an issue with it
I’ve attempted a workaround by checking if the path is blocked via a raycast, and if not, then double checking with a spherecast the size of the character’s radius. If the spherecast hits an object, I create a part to block the path in order to force pathfinding to wrap around rather than attempt to travel through.
Although in theory this should work fine, it appears to break pathfinding completely and almost never returns any waypoints. How the small red square makes the path invalid, I have no clue
However, If you make the part small enough, the path will generate around the corner like intended. This reduces how efficient the workaround is and is not ideal
