Recently, in the update notes for update 460, I noticed that .CanTouch is going to be added as a method to turn on and off .Touched events. This makes me have a couple questions about how .Touched works because I thought that it only fired when an event was connected.
Does .Touched fire when there are no events scripted to connect with it? What about when there are no events connected to it and it does not have collision?
Will replacing large parts with tiny parts with meshes to make them look large improve performance? If it does, then if I have collision turned off would it still make a difference because of .Touched or something?
The events will call the listeners that are connected to the event!
As far as I know depends a lot on the mesh you use, if you have too many triangles, it will still cause performance issues.
Though, Meshes support LOD (level of detail) so it should help with performance, and parts don’t have LOD
Parts with collision off can fire the .Touched, Big meshes with tiny parts will not fire the .Touched if it’s outside the part size/position.
I think his question could be better worded as “Does the backend code to handle collision detection (pertaining to the event) still run even if there are no events set up in the current system”
To my knowledge of Roblox’s Script Signal system, I don’t know how they would implement something for that. On the other hand, didn’t there used to be some TouchListener or something that got automatically inserted whenever you set up the event? I don’t know myself, maybe you know better?
JarodOfOrbiter seems to understand what I meant and reworded it, basically I was curious as to whether saying “part.Touched:connect(function() end)” added a new event that gets fired with collision that wasn’t there before.
This helps answer my question some if .Touched does its calculations by polygons instead of the size of an object. I doubt that level of detail would make a difference if we’re talking about .Touched here, because I thought that that was for rendering.
This does make me think though, is the reason why a bunch of 2048x2048x2048 parts lags more than a bunch of tiny parts physics or rendering?
It would be difficult to test, but that would make sense. I guess we’ll be able to verify when .CanTouch comes out by comparing performance.
Ah, TouchInterests, I forgot that those are actually even still a thing. Whenever you add a .Touched to a part they still show up. They aren’t there otherwise. I guess that the existence of those things answers my first question.
I’m going to mark this as solved after a little while once I see if anyone knows more about the second question.
Edit: It doesn’t seem like replacing large parts with small parts with large meshes makes a difference. Not sure why it would either though
