Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up when we have an update for you.
4 Likes
I am facing the same issue. Does anyone have a workaround until this is resolved?
1 Like
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
2 Likes
I’m having this exact issue too!
3 Likes
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.
2 Likes
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.
4 Likes
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.
2 Likes
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.
2 Likes
Still having this issue, this really sucks 
3 Likes
Was hoping to make a simple pathfinding system, but will have to use A* now. Why has this not been fixed?
4 Likes
Bumping. This seems to be the exact issue for me as well.
PathfindingService worked great for the past few months, but suddenly it no longer computes a proper path, even though it says that it does.
Seems to be fully disregarding the specified agent parameters.
Leave it to Roblox to sweep critical unnecessary bugs under the rug.
4 Likes
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.
1 Like
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.
2 Likes
Here is another pathfinding service bug I found with the same agent params as the last post (3 agent radius and basically infinite waypoint spacing)
This just happened after I scaled the part
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?
1 Like
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 
1 Like
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
If anyone thinks they could fix it, here you go:
Failed workaround.rbxl (75.2 KB)
1 Like
That’s actually what happened to me when I tried to implement it. I was trying to implement a system like that to a monster in my horror game but it just seemed to not work because the boxcast was registering a hit. I even tried using a spherecast instead and no hope. I was trying to manually map a new waypoint or adjust the old one and didn’t think of adding another part to wrap the part around. I am thinking of using another map, a simplified version on a certain offset of the main one, and just offset the waypoints as needed. This way, you can adjust the size of walls and things. The problem is that it would need to be done multiple times or using parts with different collision groups.