Detatch CanQuery from CanCollide

Feature Requests Engine Features
, , , ,
#1

It is currently impossible to omit a BasePart from all spatial queries while still having collisions enabled.

The Problem

The CanQuery property is tied to the CanCollide, meaning you can’t disable the querying of a part without disabling collisions along with it.

Using CollisionGroups is not suitable because they require ensuring all raycast/shapecast queries are set to the "Default" group, and they may cause unintended behavior if workspace.TouchesUseCollisionGroups is enabled.

The Proposal

Detach the CanQuery property from CanCollide so we can disable querying without disabling collisions in a straightforward manner.

22 Likes
#2

Agree! For invisible-collidable things that use ProximityPrompts it’s annoying to make a seperate part for a prompt

3 Likes
#3

To parrot the guidelines on this category - you should explain why, what are you trying to do?

1 Like
#4

I’m fairly sure the CanQuery property is tied to CanCollide because in order for touches to work the engine needs to query nearby colliders. If so, then decoupling those might be a big ask.

I’m curious how you came to this conclusion. I’m making heavy use of collision groups, raycasts and other querying methods in my current project. Most of my raycasts use non-default collision groups and everything works fine. My maps are surrounded with barriers that prevent players from going through them, but raycasts and objects in different collision groups can pass through them just fine. Is there anything you tried to set up in your game where collision groups were simply unable to achieve the right result?

#5

It can parent an attachment instead allowing you to bypass the need for a part.