Oops, sorry about that - ModifierId is now called Label. We are reviewing the documentation. Thank you for pointing out to this.
2 Likes
Totally. Thanks for the heads-up!
2 Likes
Pathfinding Modifiers were designed with the idea in mind that most of the world has default navigation cost, whereas some parts of the world may need their traversal cost tweaked. Thus, not every Part needs to be tagged for navigation purposes, and we can save some memory by only tagging Pathfinding Modifiers instead.
That said, if you need to tag many Parts differently, that would be valuable food for thought for us, so don’t hesitate to share such a situation with us.
2 Likes
i will definitely use this on a future game of mine, thanks for releasing this ^^
sounds very useful and promising
1 Like
is something like pathfinding for agents that can fly planned in the future?
1 Like
Unfortunately it looks like the update has critically changed the behavior of PathWaypoint.new()
A heads up would’ve been nice 
2 Likes
Sorry about that. We have reverted the flag and it should behave as expected. PathfindingModifiers should continue working as expected as well. If you could share the use case of why you create new Pathwaypoints in your game would be highly appreciated. This would help us understand the needs better.
1 Like
Not the original commenter, but I create PathWaypoints by hand to fix some waypoints. For example, I have an issue where the jump action is used unnecessarily, so I manually override some waypoints. Usually, for me, it’s just for manual path creation/fixing the existing path calculation.
1 Like
Thanks for sharing. Appreciate it.
In my use case, I manually create waypoints when the NPC spots a player. If no players have been spotted, they go from A to B normally, the second a player is in view I add new waypoints to their path table to force them in the direction of that player.
1 Like
Awesome to see this come out! I have been waiting for this to come out for months now fully as there are many things that I want to try out with it! It’ll be nice to see what others make out of it too.
1 Like
This is one of my favorite updates as I am a huge fan of making AIs and this opens up the opportunity to do some really creative improvements to NPCs! Good job.
4 Likes
This is one of my favorite things as I’m constantly working on games that uses NPC’s and it can also developers a lot, Nice job guys
3 Likes
I cannot wait to use this in my game! The opportunities pathfinding modifiers have on AI and pathfinding is infinite! This is probably my favorite update to studio to far! Thank you!
1 Like
Extremely excited about this change! Creating Smart AI has gotten so much easier over the years thanks to a handful of updates like this one. Thanks 
1 Like
I know, I know, HUGE bump, but I can’t make a feature request so any minimods will have to deal with me bumping the most relevant thread ¯\_(ツ)_/¯
Anyway, I feel like PathfindingModifiers are a PERFECT candidate for a way to have custom waypoint actions, there could be a new boolean property (it could be called
IsCustomActionRequired) and a new method for PathWaypoint to get the Label property of that modifier, so I could have a volume in a vent shaft and have a PathfindingModifier’s Label property set to “Crouch”.
Like this:
local PathfindingService = game:GetService("PathfindingService")
local Path = PathfindingService:CreatePath()
local Waypoints = Path:GetWaypoints()
for _, Waypoint in pairs(Waypoints) do
--I mean, there's even an enum for this...
if Waypoint.Action == Enum.PathWaypointAction.Custom then
local Action = Waypoint:GetModifierAction()
if Action == "Crouch" then
--Make AI crouch before going to waypoint
end
end
end
Maybe even like… just allow us to get the Label of the pathfinding modifier the waypoint is inside of? That’s probably the easiest way to do this.
2 Likes
PathWaypoint.Label was enabled last week.
It is not reflected in the reference docs yet, but it’s safe to use just as you described.
1 Like
I’m sure not, but I think this change might have introduced some instability with navmesh regeneration when ungrouping a ton of models. I ungrouped a giant (in terms of number of parts) playground model with many nested models, and now the navmesh seems to have given up with my shenanigans and just won’t generate, making ComputeAsync always fail and give a status of NoPath, even if I run the game, even if I restart Studio, the file just seems to be completely broken. Maybe some new optimization with models is the reason to blame?
(“Show Navigation Mesh” is very clearly turned on, but there’s no navigation mesh in sight)
The dummy rig attempts to pathfind to the block right in front of them with the following code:
local PathfindingService = game:GetService("PathfindingService")
local NPC = script.Parent
local Humanoid = NPC.Humanoid
local HumanoidRootPart = NPC.HumanoidRootPart
HumanoidRootPart:SetNetworkOwner(nil)
print("make path")
local Path:Path = PathfindingService:CreatePath()
Path:ComputeAsync(HumanoidRootPart.Position, workspace.SlideStart.Position)
print(Path.Status.Name)
for _, Waypoint:PathWaypoint in pairs(Path:GetWaypoints()) do
print(Waypoint.Label)
if Waypoint.Label ~= "Slide" then
Humanoid:MoveTo(Waypoint.Position)
Humanoid.MoveToFinished:Wait()
else
Humanoid:MoveTo(HumanoidRootPart.Position)
Humanoid.Sit = true
end
end
But Path.Status is always NoPath, and no waypoints are generated!
But anyway, thanks for pointing this new property out!
2 Likes
Could you create a separate bug report for this and @ me, or send me the repro place in a private message?
Thanks!
Sure thing! I’ve just sent a DM.