You mention there being a Touched event. What’s happening there? Do you have a function executing on-touch? I would be interested in seeing that function first (although it might be something different according to your microprofiler)
The main function itself just opens/closes an anchored door using TweenService when appropriate. I tested the .touched event with the function inside removed, but no difference.
I ran into this issue a while back. I was hoping to use the .Touched event for a more event driven architecture than using Region3’s. It seems like the .Touched event fires every single time an object moves inside of the part, since part positions are updated about 60 times per second per block that might be what’s responsible for the lag spike. If you stand still inside the block I would bet it doesn’t lag at all.
I don’t think the tools/vehicles are the issue here, I think the issue is much more likely the .Touched event firing thousands of times per second. The fact that converting from a cylinder to a block also supports this theory since the collision detection because significantly more complex for a cylinder than a block.
I’m not really sure what you can do about this, it’s unfortunate that the API doesn’t just ignore the part until the Touch has ended and then allow this to fire again. It’s really not very useful for the .Touched event to fire 60 times per second if the touching objects are moving. In the end, you’re much better off using a loop and a .magnitude test instead (assuming you can, not entirely sure of your use-case here.)
Out of curiosity, how many parts are on the gun/car?
This is most likely being caused by unions or meshes with complex physical geometry and/or too many parts hitting your touch-interested part (judging from what you say about vehicles and tools causing issues)
Try using Character.HumanoidRootPart.Touched or Humanoid.Touched
I’ve faced this issue before, particularly with meshes and unions. Detecting whether a mesh or union is being touched is far more consuming than a simple part. Multiply this by several small parts touching each other, and you’ll experience lag.
PS: You could consider replacing the detecting part with a simple brick.
Simplify it. You can realistically only have a few parts running Touched connections at the top-level. Be sure to also debounce it, otherwise you may end up with an enormous mass of events being called every time a touch has been done. You can also manually set Touched states by using its counterpart, TouchEnded. Not sure how reliable this is though.
Appreciate all the responses. I’ve decided to create a table containing all the doors, then looping through this table every second, checking their magnitude in respect to the player.
I’ll take this all onboard next time using.Touched events, thanks.