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.
Still having this issue, this really sucks 
Was hoping to make a simple pathfinding system, but will have to use A* now. Why has this not been fixed?
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.
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.
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?
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
If anyone thinks they could fix it, here you go:
Failed workaround.rbxl (75.2 KB)
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.
This explains a lot… I’ve been wondering why my NPCs kept getting stuck on doorway edges and stuff, while other times I test they don’t even go through the doorway and give the NoPath error.
Please revisit this issue, the issues with pathfinding service have made it so unreliable that I’ve resorted to visually teleporting the NPCs to where they need to go just to avoid issues of getting stuck.
Bump. This is bothering me a lot because bigger npcs always get stuck, and since they are enemies, this basically means a free win.
This definitely affects my game as well, I’ve had to add large avoid zones on corners but even that won’t fix it
I just turned of collision on my enemies so that they wouldn’t get stuck.
Bumping, it’s been almost three years, this is still a major issue with the PathfindingService making it nearly unusable, my game suffers heavily from this issue and I’m starting to think making my enemies walk through walls would be a better solution 
It’s been a long journey friends, but I believe we may have the solution: Improving Pathfinding Quality With New Algorithm
