Perfect example as to why it’s necessary for new features to go through thorough beta testing before full release.
2 Likes
This is gonna be incredibly useful. No more debounces, I suppose.
2 Likes
Looks interesting, can’t wait to see it in action!
1 Like
Currently to disable raycast and region3 queries on parts universally (which is good for general situations, such as in Studio plugins when making visualizations the dragger shouldn’t be able to touch) we have to use a collision group that doesn’t collide with default. Is Roblox considering a parallel property like this one to cover raycasts as well to satisfy the use case for this weird behavior of collision groups? Worryingly, some engineers have expressed wanting to fix this behavior without necessarily preserving this use case.
2 Likes
FYI you should be using HandleAdornments for these, then you also won’t have to worry about lighting issues.
2 Likes
This does not work for what I am doing. See Studio Tweaks’ selection box override and selection face adornees - I need a part to encompass the selection upon which I can set adornments because this is part of a hack used to hide the big fat selection boxes we all know and hate (i.e. I use glass on a part slightly bigger than the extents of the selection box to hide it), plus I need a part upon which to put surfaceGui for the text version of the part face visualizer, since these cannot be attached to models. My use-cases extend further into other things, including volume visualizers in Studio.
2 Likes
Yes, the plan is for another property like this one that covers raycasts, region3, and other upcoming spatial queries
4 Likes
There’s no documentation for this whatsoever, if possible could this be overlooked and documented anytime soon?
2 Likes
A great feature, truly. That would help a whole lot with some of my systems and prevent the massive lag spikes the touched event can sometimes cause.
Sad to see that it’s not stable yet, can’t wait to see it fixed and released!
1 Like
Even after the CanTouch Update was disabled, I was still having trouble opening and editing my games.
2 Likes
Is Disabled That’s Bad. What Am I Going To Do.
2 Likes
Look’s Amazing! Keep developing.
1 Like
Its re-enabled now for anyone wondering.
1 Like
Just noticed when I was testing something and noticed the property is back. So I came here to see if they had updated this post (and apparently they have not still).
2 Likes
Only kleptonaut can edit the post and it’s quite early in the morning. It’ll be updated shortly!
2 Likes
As others have already said, yes! We back!
7 Likes
Yes we need descriptions on https://developer.roblox.com/, however we do have a definition in the original post:
I recommend turning it on, as it’s a more consistent behavior. (Groups set to not collide should not fire each other’s touch events)
Do you have any questions about this?
2 Likes
When creating a tool that doesn’t need any sort of collision, this warning pops up when taking it out of your backpack.
Is this an intended feature?
1 Like
The tool’s handle is trying to connect a Touched event, probably so players can pick it up or it has some behavior when hitting something.
If it’s not meant to have any kind of collision interaction with anything, you should edit the script to not connect a Touched event. Otherwise, keep CanTouch set to True.
EDIT: Correction, it looks like Tools will create a Touched event with the handle internally for backend processing, so really you should never disable CanTouch on a tool’s handle.
If you really want to keep Tool’s handle from firing touch events, you could set Tool.requiresHandle=false, and weld a mesh onto the character seperatly.
4 Likes
I’ll just keep the CanTouch property for the handle true. I was only disabling them to slightly improve performance, since my guns don’t need to collide with anything.
1 Like