PathfindingService treats walk-through parts set by collidable groups as non-collidable and walks around them

Kampfkarren · May 25, 2018, 2:43am

Maybe this is supposed to be a feature request. Either way this is extremely annoying.

I have multiple NPCs in my game. They use PathfindingService to get around. I also made it so they walk through each other (but not fall through the floor) using PhysicsService collidable groups.

This happens every time and probably has always happened. It’s extremely annoying and as far as I’m aware is impossible to fix as a developer.

Here is a repro. The BoolValue in Workspace determines whether or not the test is using collision groups.

pathfinding bug.rbxl (16.2 KB)

WelpNathan · June 2, 2018, 10:58am

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.

TL;DR: Collision groups break the PathfindingService.

revcane120alt · July 16, 2018, 4:12pm

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.

peraldon · April 9, 2019, 3:57pm

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.

spliceosome · October 17, 2019, 4:52am

This is extremely limiting to pathfinding and it’s detrimental to certain use cases

Native_Clouds · October 18, 2019, 3:09am

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.

Kampfkarren · October 18, 2019, 4:10am

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

spliceosome · October 18, 2019, 10:08pm

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.

CLarramore · October 18, 2019, 10:23pm

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.

popeeyy · February 5, 2020, 10:29pm

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!

Corecii · April 7, 2020, 7:42pm

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.

RuizuKun_Dev · May 14, 2020, 3:43pm

I’m running into issues with this as well, please add support for better Pathfinding usage.

It’s been 3 years already since the new PathfindingService came out and we were promised many things that never got implemented

On other platforms they have Machine Learning now, Roblox needs to catch up.

xChris_vC · June 11, 2021, 2:18pm

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.

RecanValor · June 13, 2021, 2:44am

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.

IdiomicLanguage · July 22, 2021, 5:35pm

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.

RecanValor · March 6, 2022, 9:23pm

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.

IdiomicLanguage · March 6, 2022, 10:54pm

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.