I’m also having this problem, theres a invisible box that the pathfinding ai is in, and since its in there, it wont move or move out of it.
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.
This is extremely limiting to pathfinding and it’s detrimental to certain use cases
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.
This is very much a bad solution:
- 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.
I’m running into issues with this as well, please add support for better Pathfinding usage.
On other platforms they have Machine Learning now, Roblox needs to catch up.
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.
Bumping this because it is needed to be fixed.
Currently about to release my game, which depends on AI to give the user a sense of realism.
The AI instead fails and ends up not to work because of this problem.
This is crucial as it is part of the gameplay and if I am unable to be able to fix that I would not know what to do.
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.
this helped thank you so much
Another bump, Still amazed how this hasn’t been fixed yet
Hasn’t it been 6 years now? I need my chasing npc to walk through doors but since it’s tall it can’t
this is still a problem by the way, there’s no easy way to use pathfindingservice with collision groups. pathfindingmodifiers aren’t good enough for multiple entities with different collision groups.