I understand this new property’s application for performance increases and convenience, though I am kind of confused what it would be used for otherwise. Are there any example use cases where this is foremost necessitated?
P.S Saying it determined first impressioned me it returned a comparison result if they could, but I realized it sets the property instead.
It can simplify your Touch event filtering.
Let’s say you have a car game with cars made of ~100 parts each. Maybe you have a Part on the car with a touch event listener for processing vfx when the car hits obstacles (maybe there’s more than one!). Let’s also say there are several other cars, but none should collide with one another (ie ghost racers).
Without CanTouch, whenever cars move through each other there could be 100+ touch events firing on each car. You would need to manually add logic to the touch event connector to filter out those parts and still take the performance hit of 100 touch events.
With CanTouch (and Workspace.TouchesUseCollisionGroups), you can easily filter out the parts you don’t want to fire touch events, without adding more code.
I don’t think there are use cases that absolutely necessitated this property, but it can significantly simplify things.
Setting CanTouch to true for a part with CanTouch set to false which is within another part will cause a crash in both studio and in-game 100% of the time:
If you want an object to be completely ignored in .Touched events, this new property is a much better solution than creating a global ignorelist table.
What can I expect in terms of performance optimizations for a game where literally every single object in workspace is Anchored and non-CanCollide? This also includes things like humanoid character models – literally everything is Anchored and non-CanCollide. I also don’t use any raycasts, region3’s, etc; humanoid state is set to not do anything. I also move every single part in workspace with one BulkMoveTo batch CFrame update call.
This could’ve been really handy several years ago! My friends and I ran an experiment back in 2014 with two identical cars: one drove and the other flew. The flying version generated measurably less lag because the wheels never came in contact with the ground. Putting this level of control in our hands opens intriguing possibilities.
Does/Will this also apply to terrain? There are touched events on terrain too since it inherits from BasePart and large-scaled terrains can definitely cause performance lag.
I can definitely image large terrain without detecting touched events faster.
I am pretty sure Touched events work with terrain, I’ll test again when able to
Yeah, but some BasePart properties apply to all parts except for Terrain (such as Anchored, CanCollide, Transparency, Color and etc), so will this property work or not?
I recommend disabling the Touched event if the CanTouch property is disabled. It’s most likely to not impact the server’s performance, instead of throwing an error.