New Part Collision Property: CanTouch [ACTIVATED]

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

63b0bb343bec216df1df843d68932ce4

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

Is it weird how I only noticed this just now?

1 Like