Is it stable enough to become live feature?
Yes, but we are waiting for the dragger update that allows you to still select parts which have CanQuery turned off. This should be enabled in tomorrows update.
Physical dragger’s right? Im assuming that.
No I’m referring to all forms of selection in general.
As outlined in the initial post:
You may have realized that excluding a part from raycasts will lead to the part being unselectable by the Studio dragger tools. You’re right, this is a known issue. The dragger tools will be updated to override the property in Studio during the beta so you can still select things.
Oh okay, got it. Got confused.
Would it be possible to bring this back? It turns out this entire time I thought this bug was an intended feature lol
I had created a plugin that replicated Visibility Groups from the source 1 map editor Hammer. I had been using CanQuerry in conjunction with transparency to effectively remove player clipping parts and other trigger parts from my game while not in use, and reenabling them before publishing the game.
It seems like this “bug” had been fixed and now my cherished CanQuery no longer does what I thought it was meant for haha
I found it super useful for “ignoring” the query collisions of parts that got in the way when adding details. I often create things that have BasePart boundaries or BasePart water. The ability to ignore those parts when placing stuff inside/underneath them was super useful. The “Locked” property does not solve the same use case, nor should it.
I also want to stress, this isn’t a one-off use case. I had used it all the time for boundaries, BasePart water/grass, carpets, and overall decor. It was a really nice QoL when I used it intentionally.
@cloakedyoshi @ShadowFox2
Also, as mentioned in the original post:
We realize that the ability to disable selection on parts can be helpful. Over time, the dragger’s behavior will be extended to allow this. Tell us your thoughts on this!
Do today’s release notes (505) mean that CanQuery is becoming a live feature in the near future?
Please, I beg you to implement this feature already! I really need it urgently to fix a really annoying problem in my game 
CanQuery is now out of beta and available to use everywhere! If you run into issues, please post a new Bug Report and tag me in it.
Thanks for your patience, and happy new year!
AYOOOO sick. Keep up the great work guys!!!
I don’t think this has been mentioned yet. I read through most of the replies and didn’t see it. But is there some special reason why CanCollide must be false for CanQuery to be false? I have a situation where I would like collisions to happen but not allow raycasts to detect the parts. I was excited to utilize this new property but quickly realized it wasn’t available while the part is still collidable.
THANK YOU SO MUCH! THIS IS AWESOME, Really great job guys im extremely thankful for this update, it’ll help me a lot
Is it affecting SurfaecGui’s intentional? Spent an hour trying to debug why my SurfaceGui wasn’t taking inputs, only to realise that this property was unticked. Didn’t realise it’d stop those inputs from firing
Yes that’s expected. Detecting a click works via raycast, and a Part with CanQuery turned off won’t be hit by raycasts.
In general I would recommend only turning off CanQuery on Parts you know will never be involved in any form of interaction.
I think it would be ideal if raycasts wouldn’t detect parts with CanTouch set to false.
This property is amazing, it really helps a ton with filtering parts such as invisible hitboxes/parts without having to use a separated folder of all the invisible blocks or go through all of workspace with a for i loop to search invisible parts.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.