Add the ability to exclude a model or part from pathfinding

Currently you can only exclude part’s volume from pathfinding through the use of PathfindingModifier instance, however, there is no way to exclude model or part itself. If I have model or a part that I want pathfinding to ignore (don’t confuse this with avoidance) I have to parent Humanoid to it, this is an awkward workaround, not to mention negative performance impact that it has.

For example: If I have a floating pet that has no collision, there is no way for me to make NPC go through it because it thinks that it is an obstacle. I want to be able to exclude it so that pathfinding completely skips it and acts as if it didn’t exist.

Additional note: It would be nice if I could exclude object per agent basis, not just globally. For example: If I have blue agent, and red agent, I want the red and blue agents to ignore their teammates, but not their enemies.

8 Likes

IIRC you can avoid parts with pathfinding using PathfindingModifiers + a very high pathfinding cost for that modifier.

Is this a different application than what you’d like with this new feature?

I want to exclude the model or part entirely from pathfinding, as if it didn’t exist for the agent. It’s not about avoidance. If I have a pet that is can collide false, I can’t make NPC go through it because it thinks that it is an obstacle.

2 Likes

Ah, so you don’t want them to be calculated/considered at all. That makes sense. Phrasing had thrown me a bit off, thanks for clarifying.

3 Likes

Does making the Parts, Unions, or MeshParts CanTouch false and CanQuery false help?
I know CanQuery prevents things like raycasts in game from recognizing them, or makes it so plugins in Studio can’t select those items.
Give it a try.

Setting collision group of an object to not collide with ‘Default’ collision group helps, but it obviously is not a great solution. Often times you still want ignored objects to collide with ‘Default’, like for pets, npcs or temporary debris. Being forced to use humanoids for this is quite ridiculous

I think a solution on Roblox’s end that could work is allowing them to use CollisionGroups in general. Raycasts, shapecasts, and getpart(s) functions already use something similar with their params systems, so why not pathfinding?

I commonly use a CollisionGroup for AI Zombies called Zombies to allow them to go through parts collision-wise, so I don’t see a reason why it shouldn’t also be applied to calculating the path either. I have noticed that some of the custom pathing that the Roblox default click-to-move pathing has also made it so players would get stuck against invisible walls that zombies normally go through just fine.

Also, it’s a pain to balance so many PathfindingModifiers all the time. I think that it should be optional for things like swinging doors or destructible walls. Heck, even for part-specific changes like dangerous fire!

1 Like