Yeah, this confused me seeing that it’s a property of Workspace and not PathfindingService. That doesn’t really make sense to me.
Also, are these properties for opt-in betas hidden once the old version no longer exists?
1 Like
Could you please DM me the file(s)
Or a maximum drop distance. As well as maximum jump height.
1 Like
I’m so glad these issues are finally getting fixed! I can confirm this completely solves what I faced in my original bug report; large characters now properly walk around corners in every case I’ve tested.
4 Likes
This is absolutely amazing. Thank you so so much to the Movement and Pathfinding team as well as everyone else!!!
I really dislike this “we know better than you!” approach where Roblox decides to blackbox the internals of their features. We see this with StreamingEnabled as well and it took years before they even gave us basic Atomic/Persistent control, as Roblox thought the existing Streaming algorithm was so perfect that nobody needed finer control. Turns out it wasn’t.
Your pathfinding isn’t perfect, it never will be.
Your Navmesh generation is never perfect, it never will be.
Your goal shouldn’t be to create ‘perfect’ blackbox features that never get expanded access.
“we sincerely believe that should no longer be necessary” should NEVER be an excuse to not give developers deeper access to features. Basically saying you made it so good that you don’t need to give out API access is such a weird mindset, as if giving out more access is a bad thing. Please reconsider this.
Let us access the navmesh directly. Why? Because it’s cool and opens up additional deeper uses beyond what your team envisions.
10 Likes
y’all the goats man i thought my day couldn’t get any better
Ok after doing some testing, this runs abominably worse than the old algorithm. NPCs can take up to 7-9 seconds to compute paths they could otherwise do in < 1 second. Also it can crash on larger areas now randomly with bigger NPCs.
Could I please get the repo place where it is taking long to generate the path.
1 Like
I see no problem in exposing nav mesh a little bit, people who do not want to mingle with it just won’t. Being able to make your own nav mesh out of thin air actually sounds freaking amazing.
That being said, these are actual features that could be useful:
- Getting a closest nearby point on nav mesh, for example to return npc back to nav mesh after it fell out of it.
- Getting nearby nav mesh points/polygons, in order to easily make wandering npcs who walk around randomly. Right now we are forced to raycast and hope the raycasted point is accessible.
- Checking whether a point is on nav mesh at all. This could be very useful to prevent some useless path searches.
- The way roblox finds nav mesh points under the query start point could be very useful thing to expose. This would maybe remove necessity to raycast down for some npcs that move strictly on nav mesh.
- Excluding parts from nav mesh. Right now we have to add Humanoid into models to make them be ignored, which is kinda stupid. You can also remove collision with ‘Default’ collision group, but you normally still want collision with that group, for example for temporary debris or npcs without humanoids. Some other way to exclude parts or collision groups would be useful.
7 Likes
This is excellent, addresses every issue I’ve had with PathfindingService and more! Looking forward to using this in future projects. Thanks for this!
This can be achieved using pathfinding modifiers and setting the PassThrough to true. You can parent this to individual parts.
1 Like
Finally, better pathfinding. Its been bad for a long time and i hope it continues to improve, cause the nav mesh is still a little weird
THIS IS THE PEAKEST PATHFINDING UPDATE EVER.
Thank you for your hard work.
I 100% agree. giving access to the navmesh would allow for much more possibilities.
I’ve heard tyridge had to make a custom pathfinding implementation (which turned out to be much faster than robloxs) through a custom generated one. giving creators more freedom through gaining access to theirs and doing what we want with it would be a lifesaver here
1 Like
Speaking of navmesh generation. could we be able to have a method that gets the vertex positions of the navmesh generation in a range or region like these in the image:
@watIsInTheName @oldmannt
1 Like
agent CanJump = false will make the npc not fall from higher parts
1 Like
A simple use case for access to the navmesh would be fine-tuning the generation of “Jump” pathfindingLinks. Right now, the navmesh will automatically generate “Jump” links based on the default humanoid jumpheight (and in a lot of cases, it won’t generate links in places where a humanoid can very clearly jump from one point to the next).
It would be super useful to finetune the navmesh to either allow the configuration of those links’ heights and lengths, or to have several jump-like links of varying intensities with different labels, in case a character in our game has different stats than others. This would obviously cause either performance issues, or a slower-updating navmesh, but developers could test this approach and weigh the pros and cons themselves.
3 Likes
I found another issue with the pathfinding. after it reaches the destination once if i move it again then the npc starts jitterning and pause between waypoints
robloxapp-20241115-1140185.wmv (497.2 KB)
its ran with this exact code
local PathfindingService = game:GetService("PathfindingService")
local Players = game:GetService("Players")
local RunService = game:GetService("RunService")
local path = PathfindingService:CreatePath({
AgentRadius = 2,
AgentHeight = 5,
AgentCanJump = false
})
local character = script.Parent
local humanoid = character:WaitForChild("Humanoid")
local TEST_DESTINATION = Vector3.new(100, 0, 100)
local waypoints
local nextWaypointIndex
local reachedConnection
local blockedConnection
local function followPath(destination)
-- Compute the path
local success, errorMessage = pcall(function()
path:ComputeAsync(character.PrimaryPart.Position, destination)
end)
if success and path.Status == Enum.PathStatus.Success then
-- Get the path waypoints
waypoints = path:GetWaypoints()
if #waypoints < 2 then
if reachedConnection then
reachedConnection:Disconnect()
end
end
-- Detect if path becomes blocked
blockedConnection = path.Blocked:Connect(function(blockedWaypointIndex)
-- Check if the obstacle is further down the path
if blockedWaypointIndex >= nextWaypointIndex then
-- Stop detecting path blockage until path is re-computed
blockedConnection:Disconnect()
-- Call function to re-compute new path
followPath(destination)
end
end)
-- Detect when movement to next waypoint is complete
if not reachedConnection then
reachedConnection = humanoid.MoveToFinished:Connect(function(reached)
if reached and nextWaypointIndex < #waypoints then
-- Increase waypoint index and move to next waypoint
nextWaypointIndex += 1
humanoid:MoveTo(waypoints[nextWaypointIndex].Position)
else
reachedConnection:Disconnect()
blockedConnection:Disconnect()
end
end)
end
-- Initially move to second waypoint (first waypoint is path start; skip it)
nextWaypointIndex = 2
humanoid:MoveTo(waypoints[nextWaypointIndex].Position)
else
warn("Path not computed!", errorMessage)
end
end
while wait(0.3) do
followPath(workspace.Target.Position)
end
3 Likes
Nope, this does a slightly different thing.
Problem is that parts with such modifiers still modify navigation mesh.
An obvious issue is that a debris or an npc with PassThrough will simply nullify any other uses of Modifiers in the same area, making an impassable region passable again.
A less obvious issue is that constant rebuilding of nav mesh when such parts move is very problematic. An npc with PassThrough simply does not function, because it breaks it’s own path that it just built, and even debris rebuilding paths can cause stupid behavior.
4 Likes