.Touched event and some tools/vehicles cause extreme lag?

[ForeverHD (Ben)]

Entering a part with a .Touched event normally works fine:

https://i.gyazo.com/e34f4089d532e121109f7e4af30f9c07.mp4

However, if I do the same with this tool then lag skyrockets, as shown on the profiler:

https://i.gyazo.com/9a7d03d6d5c1add1e48a3986f7ceccdc.mp4

The tool I used contains multiple ManualWelds inside of its Handle:

The same thing happens when I drive vehicles into the event area, however the vehicle contains Constraints and Motor6Ds instead.

Any ideas to what might be causing this and how I can fix it?

Thanks

[sleitnick]

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)

[ForeverHD (Ben)]

The framework looks something like this:

local detectArea = Instance.new("Part")
detectArea.Shape = "Cylinder"
detectArea.CFrame = d:GetModelCFrame() * CFrame.fromEulerAnglesXYZ(0,0,math.rad(90))
detectArea.Transparency = 1
detectArea.CanCollide = false
detectArea.Anchored = true
detectArea.Name = "DetectArea"
detectArea.Touched:Connect(function(hit)
	-- main function
end)
detectArea.Parent = workspace

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.

[sleitnick]

@ForeverHD

I tested the .touched event with the function inside removed, but no difference.

Cool, that’s a good test of it. Then I guess I don’t know what would be causing this. Hopefully someone else has more insight than me!

[ForeverHD (Ben)]

Ok so changing the shape from a ‘Cylinder’ to ‘Block’ of the ‘touch’ part appears to reduce the lag for the tools:

https://i.gyazo.com/72d28c4a4f6e5959c57ff6dfbe4521bb.mp4

There is still significant lag for the vehicles though.

[CompilerError]

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?

[HaxHelper (ken)]

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

[1Joeb (joeberson)]

I thought it might be because of the parts as well

[devSparkle]

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.

[colbert2677 (ImagineerColbert)]

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.

[ForeverHD (Ben)]

@CompilerError @HaxHelper @devSparkle @colbert2677

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.

[ForeverHD (Ben)]

The gun only contained 4-5 MeshParts, but as mentioned by HaxHelper were comprised of complex shapes so were quite intensive.