I was just about to make the same bug report. It’s a shame because the PathfindingService is flawless apart from this bug. Here is what I’m currently dealing with.
The below image is the PathfindingService using the ‘Default’ CollisionGroup which works flawlessly. The part’s CanCollide is set to false.
However, if we set the part’s CanCollide to true and add a collision group to this, where that group’s collision is set to false, as you mentioned, it walk around the part which is incredibly frustrating. This seriously limits how we can use the PathfindingService.
Looking to bump this back up, as it is still outstanding, and currently providing headaches for me as well. I’m now having to make the blocking parts on the client, which not only is pretty hack, but also would compound when faced with the necessity for any form of Anti-Cheat validation.
While pathfinding service doesn’t support ignoring the part, create an “Model” and put the part in it with collide true and part going through them. and changing the part to “Head”,
and creating humanoid in model, it will ignore the part as it is alive humanoid, Name on head can be hidden by toggling visible name and health.
That how it works, i used it on colliding doors for npcs to go through.
Any code that wants to deal with Humanoids (weapons, etc) now have to understand that they must ignore these
Unless you’re making sure to disable all the Humanoid state (and even then) you’re going to have performance issues when doing this multiple times
Unsure about if this is still a thing with the new lighting system or if this persists in Compatibility mode, but on the old lighting system Humanoids have expensive custom lighting calculations
Not to mention that I’m using custom humanoids (for efficiency reasons and greater control over AI behaviour), so adding humanoids to avoid this bug is entirely counter intuitive.
I had ran into a similar problem myself. While this is a bad solution itself, I had decided to make a workaround solution that doesn’t involve humanoids and that is to re-parent such parts to the player’s client. I know it’s not that good but it is my temporary workaround which seems to work until there is such function to ignore parts.
This is currently a problem for me. I’m trying to stop cars from going somewhere NPCs can. When I set the NPCs collision groups to allow them to go through these blocks, PathfindingService fails to find a path because of this brick, even though there is a way!
We just ran into this issue while implementing a new feature. We use large “blocker” parts in a different collision group to prevent vehicles from physically entering certain parts of the map. Because of this, it’s not possible for us to pathfind into and through certain areas of the map.
I expected pathfinding to only work on the Default collision group just like raycasting does.
We’re now discussing how we might need to move away from PathfindingService someday because of its limitations. In the short term, we’ll probably implement a “hacky” solution just to work around this long-standing issue in PathfindingService.
Edit:
We are now taking advantage of this behavior, so the only solution that would maintain our current features now is support for collision group filtering in pathfinding.
Roblox Pathfinding is not just a guideline for inexperienced engineers, it’s being used by experienced programmers who don’t want to create a whole A* pathfinding on their own, just because of aforementioned issues.
Roblox has to address those, and that is my intention with this message. The issues are still present at time of writing, and caused me to write this post.
It doesn’t have to be on the extreme high level as other platforms immediately, as we all acknowledge that cross-platform and performance is one of the main objections by Roblox employees. It doesn’t have to be machine learning & that level neither. Just come with a few fixes (on suggestions highlighted before) on the current pathfinding system, and I am already happy.
On behalf of all the developers here I say, We’ve Had Enough!
I understand that implementing this feature requires a huge change to the Roblox pathfinding system. Since Roblox uses Recast & Detour which is a navigation mesh generator and pathfinder, having each actor ignore different parts based upon their collision group means that multiple navigation meshes need to be created and upkept. This could create havoc in an unaware developer’s game.
However, this feature is needed for many games. Since this is the case, I’m putting together a pathfinder that will support this feature (making creating meshes explicit), and others, to supplement or wholly replace the Roblox pathfinder. You can join the community following its development and contributing on Discord.
Another bump.
I do not want to have to make my own pathfinding algorithms because of an outstanding bug. This is crucial bug, and my paths are currently failing because of this.
Well, you don’t have to because I did. Polaris-Nav development is going well. I’ve added manually placed jump connections until the automatic ones are finished. I’m currently revamping the plugin UI and will be done soon.
I came across this issue and didn’t realize that you can parent a PathfindingModifier to any part and enable PassThrough. This somewhat solves our issues with pathfinding and collision groups.
