The solutions listed so far are either impractically slow or very specific. The solution used abroad is neither of those, though it does NOT support dynamic maps; if a part that the humanoid has to cross moves, you will have to use one of the methods people have told you.
The usual method of solving this is literally copying the entire map, removing all parts you want the humanoid to ignore (like the doors), placing the map roughly 100,000 studs away from the original (far enough away so it doesn’t render and does not cost anything), and using it for calculating your path. With this new map in place, simply take the start and endpoints of your needed path, translate them 100,000 studs in whatever direction you sent the pathmap (as I call it), calculate the path, and translate all the waypoints of the path 100,000 studs back. This will create a path that effectively allows you to ignore certain parts while being very cheap processor-wise.
The map is way way way too big to copy all it. 
As long as there is less than say 100k parts, you can easily copy everything during a loading screen. Remember that this needs to be done only once when the server starts up, never after that.
Its a very big map… spanning a wide range with a lot of parts… and a lot lot lot of terrain.
How does one create a ray along a non existing/blocked path. And if the path is detected its blocked wont it detect any wall thats in the way? @Jaycbee05
This is hardly cheap and efficent at all; This solution is not any better than the rest. If anything, it’s a hacky solution. Also, pathfinding isn’t always a one time thing, so you might have to run this multiple times. At that point, the map would have to be fully cloned, replicated to the client, destroyed, and removed from all clients - not a quick and cheap process.
You misunderstand how a pathmap works. It is created ONCE on the server, and never again. Once a pathmap is made, all pathfinding (when specified of course) will use the pathmap instead of the normal map to create a path. It can easily be made so a client can use the pathmap without having to make its own.
The pathmap is never removed; it is kept and saved for the duration of the server or until a new map is made (such as in a round-based game).
Once a pathmap is made, the only expense is adding Vector3.new(100000,0,0) to the start/endpoints, and then subtracting it from the output waypoints. This is an expense that is so small that it is literally impossible to measure.
The only downside of this method is that it doesn’t work for dynamic maps, those that have moving parts.
Yet again, this depends. If the map is dynamic, one path map will not always work. Even cloning the entire map once is a huge process to do on the server (not to mention if the client has to replicate it)
Either way, it’s still a hacky solution, and not cheap and easy. While your solution works, I wouldn’t consider it the end all be all like you implied.
If you want to continue this argument, I’d suggest taking this into DMs. I don’t want to clutter this topic unnecessarily.
You are echoing what I already noted while adding in something that is simply not true.
Yes, this method doesn’t work with dynamic maps; I stated this 3-4 times now. If it did, it would be the perfect method.
Cloning the entire map is not as bad of a process as you may think, especially when it is not even rendered in. My game clones maps of 50k parts every round and it is not even noticeable.
As for the client side ‘lag’, there is none. Period. If you clone the map 100k studs away, there is no significant latency or processing on the client’s part. The client simply receives data that the new instances were added without rendering it.
It is not a ‘hacky’ solution, it is cheap, and it is easy to do as I am sure even a novice scripter can do it.
Please do not make things up. I never implied that it is the perfect solution or even applicable everywhere as I numerously wrote it’s main limitation, while still noting it’s superiority over other solutions in non-dynamic maps.
How many parts are in the map? If it is below 100k, it is doable. If it is below 50k, it is not even a problem. Above 100k and it kinda stops being practical as the map size is just too large; I would be curious of how long the pathfinder takes to make a path through it in the first place.
so, ive done some playing around with path finding, and found out that firstly if the part is set to can collide fasle in most cases the pathfinding service will not detect it, however this means setting the entire object to not collide, along with other disadvantages leads me to believe that a more customizable option (recommendation) is to create your own pathfinding system(preferably using A*), yes dont get me wrong there are many other alternatives but it boils down to the customizability and performance.(generalizing, not saying my solution has great performance)
if you still wanted know how you could find blocked part using the possible (untested) solution I gave:(might need some tweaking…)
local Ignorelist ----Folder or Table containing parts
for i, obj in pairs(ignorelist:GetDescendants()) do-------Loop through descendants or children to set all parts to false in the ignore list
if obj and obj:IsA("Part") then
obj.CanCollide = false
end
end
local Path = PathfindingService:CreatePath()
Path:ComputeAsync(Start.Position, End.Position)
local waypoints = Path:GetWaypoints()
for i, waypoint in pairs(waypoints) do
if waypoints[i + 1] then
local Dist = (waypoints[i].Position - waypoints[i + 1].Position).Magnitude
local ray = Ray.new(waypoints[i].Position, Vector3.new( 0,0, -Dist/2))
local raypart = workspace:FindPartOnRay(ray)--Finds the "Touching" part
if raypart and raypart:IsDescendantOf(ignorelist) then
local PartBetween = {v, waypoints[i + 1]}---- Waypoints neighboring the part
------- finish the rest, Tween Here and finish path
end
Just some thoughts, Have a Great Day or Night!
I would add that custom A* implementations can be MUCH faster than the built in pathfinder and don’t come with the restrictions. For example see
and
The most essential part to making a faster A* implementation than the built in one would be to use a map representation other than a simple grid. The larger the nodes, the less need to be traversed to reach a goal. Don’t use a simple grid, use navigation meshes, rooms, areas, regions, or something similar. Hierarchical implementations are a little more tricky but have HUGE payoffs.
This may be a little complex for what i need. I have a huge map with mostly terrain. This is a lot of extra learning to implement this than i think i’m willing at the moment.
Its a large open world… i’m not sure how computing the whole map would be pracaticle in this way. NPC Path finding right now is limited… and my biggest problem is finding a way of ignoring doors… because when the npc approaches the door… it will open and therefore the path can be recomputed. Another issue is the fact that doors are often within models… not easily indexable… and theres a lot of them. An npc may have need to follow a path but the door thats an issue is far away… so searching in magnitude may not work as well… i find @Jaycbee05 idea of the raycasting interesting… and if anyone has anyideas on how to add to that… that would be really great.
I could detect just the one door that may be in the way… if the path is blocked… then what i could do is change the path to the doors door sensor… when the npc hits the door sensor… the door will open… and the path can continue. The problem is… and this is the problem with @Jaycbee05 solution… is that because its blocked it cant detect a path to the final destination. So… it can’t find the possible door that is in the way. Nor would it put the player in the path of the door necessarily. The only thing i can think of is manually making a path… but i’d like to avoid that for reasons of… going forward i may have a lot of npcs that go through paths… and i’d like it to be fail safe if there may be a door in the path.
@IdiomicLanguage
@REALTimothy0812
One of the things i’ve been experimenting with has been right before the path is created, i loop through all the doors and uncancollide them… then right as the path is finished being created, i recancollide them… and the path works. I just wish i didnt have to loop through all the doors in the game to do that.
Create nodes inbetween the door and then have the pathfinder go to that door and then from the door you can calculate your next route. I would also setup some regions so the bot can choose a much more optimized path rather than have the pathfinder do all the work.
Hi! I’m sorry, this is an old topic, but i’m revisiting the system. @Solar_Wraith are you suggesting I acctually map out all the paths with nodes?
I was talking about nodes inbetween the doors.
I’m probably a little too late but, this may help you if this is still unsolved.
Specifically the PassThrough property of the PathfindingModifier.