How to detect if something is blocking a pathfinding path?

I am working on a system for a npc to walk along a sidewalk but I’ve ran into the issue where pathfinding only detects something blocking the path the moment the calculate the path and not while moving. So if something starts blocking their way while they are walking, they will get stuck, but if that obstruction was in the path the moment it was calculated it walks around it. Does anyone know how I would be able to detect if something starts blocking the path while it is moving? Any help would be appreciated!

Here is the pathfinding script:

local pathfinding = game:GetService("PathfindingService")

local function GetPath(character, destination) 
	local pathParams = {
		["AgentRadius"] = 5,
		["AgentHeight"] = 5.5,
		["AgentCanJump"] = true		
	local path = pathfinding:CreatePath(pathParams)   


	return path

local function WalkToWaypoints(character, path, tableWaypoints)
	local hum = character:WaitForChild("Humanoid")
	for i,v in pairs(tableWaypoints) do		
		if v.Action == Enum.PathWaypointAction.Jump then
			hum.Jump = true

function WalkTo(destination)
	local path = GetPath(script.Parent, destination)
	if path.Status == Enum.PathStatus.Success then
		WalkToWaypoints(script.Parent, path, path:GetWaypoints())
			script.Parent.HumanoidRootPart.Position - 
				(script.Parent.HumanoidRootPart.CFrame.LookVector * 10)

Oh man it is, not sure how I managed to do that, my bad

Use the Path.Blocked event to detect when and where the Path is blocked.

In my experience, and in the many issues I’ve seen on the forum, the Path.Blocked fires unreliably or even not at all.

It’s another one of the issues I am looking to solve in the new navigation mesh pathfinder I am working on. You can follow it’s progress here: Polaris-Nav. In addition, nav meshes offer advanced methods for path modification when blocked. Unfortunately, Roblox does not allow using these for quickly avoiding an object, let alone detecting it.

It fires if any waypoints are blocked, and it doesn’t care if your humanoid is in front of the waypoint or not.

Here is an open bug report about it:

Many developers saying they can replicate it here:

And I am sure you can find more if you dug more. I’ve tested it myself, albeit a while ago.

What I would do instead is get the waypoints and fire a raycast starting from the first waypoint to the next waypoint and put the character in an ignore list.

1 Like

It still doesn’t account for issues like the floor dropping, obstacles coming close to the path, or above / below. Much better than nothing though.

Well that could be fixed by many ways such as;
Firing the raycast multiple times,split the waypoints into smaller pieces and raycast with the smaller pieces so it can go slower, or have a part slowly more to every waypoint and raycast with the part’s position to check if it got blocked or use the touched event with the part.

I posted that bug report; in my experience and testing of it, the Blocked event is fine (except for one bug I mention below) if you use it exactly as they intended, which is this:

  1. Generate the path
  2. Listen for path.Blocked
  3. Travel through the path
  4. If path.Blocked fires at a waypoint that is ahead of your npc, recalculate the path from the current position. You can ignore it if it fires for a waypoint behind your npc.
  5. Destroy the path or have it compute a new path (I assume that calling ComputeAsync will reset how Blocked works).

The bug I reported (that you linked) is only a problem if you are trying to use a path for more than one npc at a time, or if you want your npc to stop/slow down in response to certain obstacles rather than recalculating.

Note: there are still other bugs with PathfindingService as a whole, which I’ve reported here: Pathfinding Incorrect Behaviour

The 3rd bug I listed in that post does reveal one more deficiency about Blocked, and that’s that it simply won’t work at all if there are any jumps in the path for any waypoint before the final jump. If your npc doesn’t need to jump/fall down, disable jumping for the pathfinding to avoid this (hopefully temporary) bug. If you do need to jump, you could do the pathfind as normal but then break up the pathfind into smaller segments (based on where the jumps are) and repeat the pathfind for each segment - and perhaps you only pathfind for each segment when you’re getting closer to it, to reduce wasted calculations for when the npc does get blocked.

Theoretically you could raycast in front of an npc to try and do your own pathfinding (including finding dips in the terrain and other obstacles), but raycasting will never return a perfect result unless you send out perhaps dozens or hundreds of raycasts, but raycasts aren’t cheap if you have to do them regularly and for a lot of npcs, so make sure to test how expensive your algorithm is (how laggy your place gets) if you have a lot of npcs.


Path.Blocked never work fine :joy:

This still appears to be an issue.

Blocked seems to not fire how I think it should.