New Part Collision Property: CanTouch [ACTIVATED]

[kleptonaut]

Hi devs! Here’s a quick overview of a new collision property for BaseParts.

BasePart.CanTouch lets your determine if the part will trigger Touched/TouchEnded events on other BaseParts with TouchTransmitters.

• All BaseParts have CanTouch set to True by default.
• A BasePart's Touched or TouchEnded event will only fire if otherPart has CanTouch set to True.
• You cannot set up a touch event on a BasePart that has CanTouch set to False. Trying to do so will throw an error. If you set CanTouch to False on a part after a Touched event is connected, the event will be disconnected (TouchTransmitter removed).

Here’s a non-colliding part with a script telling it to turn green when touched. First, on the left, we drop parts that are CanTouch. On the right, we drop parts that are not CanTouch.

This behavior will also extend to BasePart:GetTouchingParts. This function ignores all parts with CanCollide set to False, unless the caller part has a TouchTransmitter (is listening for touch events). If that’s the case, all parts with CanTouch set to False will still be ignored.

Collision Groups

This collision logic is also being introduced to Collision Groups, which can be enabled with the Workspace.TouchesUseCollisionGroups property. With this enabled, parts in different groups set to not collide, will ignore collisions and touch events. The CanTouch property is ignored in this case (much like how the CanCollide property is already ignored for parts in seperate non-colliding groups).

Performance

There’s a small performance gain on parts that have both CanTouch and CanCollide set to False, as these parts will never need to compute any kind of part to part collisions. (They can still be hit by Raycasts and Region3 queries however).

(Note: Not all performance improvements are active yet, so you may not see a big difference for now)

---

Try it out now! Leave feedback or questions below!

[nooneisback]

Just noticed it this morning. An amazing feature that made working on my car chassis 10x easier.

[PysephDEV (Pyseph)]

This is definitely a great new property! If I may ask, could I know by how much this makes performance better? My game has ~90,000 parts, and after disabling CanTouch on each object, I didn’t notice any noticeable difference.

EDIT: I’m aware not all optimizations are in place yet, I’m just curious by how much it should be improving performance!

EDIT 2: Just realized that they meant both CanCollide and CanTouch must be off to see a difference. Whoops…

[SirMing]

Is this still necessary?

Simple trick to make GetTouchingParts work with non-CanCollide parts

NOTE: This is obsolete in favor of better bounding box checking API now: https://devforum.roblox.com/t/introducing-overlapparams-new-spatial-query-api/1435720 Suppose you have PartA and PartB in workspace that intersect, but both are non-CanCollide (or only one of them is non-CanCollide): [image] You might know that the following call will not yield any results in that case: local results = workspace.PartA:GetTouchingParts() print(#results) --> 0 However, if you attach an empty Touched ha…

[Cristiano100 (Cristiano)]

I think this will make alot of things much easier, and CanCollide parts will no longer need a hacky work around to work with Touched.

[UnderMyWheel (Wheely)]

You probably won’t notice much of a performance difference until all improvements are enabled as stated in the original post:

@kleptonaut

( Note: Not all performance improvements are active yet, so you may not see a big difference for now)

[PysephDEV (Pyseph)]

I’m aware. I’m wondering by how much it should increase performance, though.

[octav20071 (OctaViano)]

I found this feature 2 days ago. It is pretty cool, allthough it is confusing when going to unanchor or cancollide properties. But cool feature, tho!

[MetaParameter]

Fantastic! I feel like this could really bump up performance, and, as @nooneisback said, make creation much easier.

[Vmena]

It shouldn’t improve performance. Collisions are still calculated for parts with CanTouch set to false, events are just not fired for Touched and TouchEnded.

[Blizzya (Blizzy)]

What if you disable CanTouch after connecting .Touched? would that disconnect Touched automatically or just make it not work?

[TheSuzerain]

Actually was testing this out on a spawnpad, got this warning:

13:10:51.808  SpawnLocation has TriggerTouchEvents set to False. No TouchInterest will be created.  -  Studio

It also never printed “Touched!” like I asked it to in the script:

script.Parent.Touched:Connect(function()
    script.Parent.CanTouch = false
    print("Touched!")
end)

[nooneisback]

These 2 aren’t related. The topic you linked is about a replacement for the GetTouchingParts method of parts. This feature allows you to entirely turn off collision detection for parts, solving the issue of unneeded Touch event fires.

The simplest example of why this is useful is for background meshes. Imagine you have an enormous mesh that covers the entire map, but cannot collide with anything. By setting CanTouch to false, you can avoid unnecessary collision checks.

[BenMactavsin]

@Blizzya

would that disconnect Touched automatically or just make it not work?

It just stops event from firing when ConTouch is set to false. It doesn’t disconnect the RBXScriptConnection so when you set the property to true again it calls the connected function when it collides with another part.
Here is a video:

[kleptonaut]

It is still necessary if you want GetTouchingParts to detect CanCollide=false parts. Using CanTouch will let you do this and still filter out parts you don’t want to fire Touched.

However, we will be introducing another API soon that provides a better alternative than using this “trick”/

[focasds]

I think it will indeed improve because currently it has to detect if the part has been touched, there is work behind firing that event. It checks and if is touching then it fires the Touched event. That’s what I think.

[MRBOGO_YT (Bogo)]

I just changed my detectors for a sliding door to use this! It runs so smoothly! This is a great update for programming!

[BullfrogBait]

@kleptonaut

There’s a small performance gain on parts that have both CanTouch and CanCollide set to False , as these parts will never need to compute any kind of part to part collisions.

Will it be worth it to set ~250 background parts both to false, or should it be for much larger scale projects?

How small is the performance gain?

[Vmena]

It’s still detecting collisions (“touches”) for physics despite this property. Performance will not improve when you disable this property as collisons are still calculated for these parts. Going through your entire game and disabling this property for all your builds won’t improve performance in your game, especially considering no Touched events are connected to these parts in the first place.