Currently, Models containing a Humanoid instance, including typical player characters, will not be considered for path computation or path blockage, although the agent may still be blocked by those models physically.
How can this problem be avoided?
I dont scripter but what about make part-hitbox?
1 Like
This might be a duct-tape style approach, but what I would do is make a folder in the workspace and name it something like “PathfindCharacterParts” or something, and when you need to run the pathfinding, iterate through all of the characters you need to avoid, put a part in the folder, make it the size of the character, set the transparency to 1, and CanCollide to false, then weld it to the character’s HumanoidRootPart, and either leave them there or remove them when you finish pathfinding.
I feel like there definitely could be a better way than this. I’m not the best with PathFindingService, but this is the only thing I can think of at the moment.
In this case, the character’s AI will stop in its hitbox.
The path computation is continuous and asynchronous. This method will be inefficient because of the asynchronous approach.
I know pathfindingservice has an ignore variable, maybe have it so it is ignored by those NPCs?
Like I said before, I’m not very good with pathfinding, what does this mean?
It is possible to create a part and bind it to HumanoidRootPart. But I don’t know how to make it ignored by the script responsible for the AI of this NPC it is bound to. That would solve all the problems.
Pathfinding - finding the shortest path from one point to another, taking into account other models
Well, yes. I got that part. But what would be the difference between “Asynchronous” or “Synchronous” pathfinding.
Same for continuous.
I just don’t know what those mean in regards to the path the function creates.
In my case there are several NPCs. Each of them has a script responsible for its AI. In this script there is a loop. Each time a route is calculated. From the route, the next point the NPC goes to is taken. Then the script waits until the NPC reaches that point, and the cycle repeats again. In the sense that there are multiple scripts and they work independently of each other, I mean the asynchronous approach. Perhaps it fits the description of multithreading better.
Yes, but how to implement it so that it works properly?
Ah, that makes more sense. Thank you.
I remember doing something similar to that with Pathfinding Modifiers but I can’t remember exactly what. I’ll do some digging and get back to you.
Actually, I have a better idea for you. Let me know if this could work for you.
What we can do is, make it so that the NPCs do not collide with each other using collision groups. Create a collision group named “NPCs” or something like that then iterate through each NPC and for every basepart in the NPC update BasePart.CollisionGroup
Here’s an example of how this could be done with a script duplicated and put into each NPC character:
local PhysicsService = game:GetService("PhysicsService")
local NPCGroup = "NPCs"
local NPCCollisionGroup = PhysicsService:RegisterCollisionGroup(NPCGroup) --this creates a new collision group with the name "NPCs"
PhysicsService:CollisionGroupSetCollidable("NPCs","NPCs", false) -- this makes it so any parts with the "NPCs" collision group will not collide with each other.
function setcollisiongroup(model: Model,group: string)
for i,v in model:GetChildren() do
if v:IsA("BasePart") then
v.CollisionGroup = group
end
end
end
--[[
I recommend putting a script like this in each NPC
run the setcollisiongroup() function on the NPC.
example usage:
local NPC = script.Parent
setcollisiongroup(NPC,NPCGroup)
--]]
I will try. If everything looks good visually, then this will be the solution