Does Roblox already handle .Touched optimization well, or do I have to make my own system?

So I have a lot of parts in a game that operate off of .Touched, though due to similarities in code they run the same function (groups include kill blocks, fall blocks, and others with other unique functionality). These functions are stored in a module as well. However there are about ~3000 of these parts.

I’m concerned that this might cause lag if Roblox isn’t already optimizing this on the backend of things, which would negatively affect player experience as this count increases with map size.

I’m currently thinking that to cut down I would hook and unhook the touch events based on player(s) proximity to each part, but that requires distance checks. Is there an easier way, am I overcomplicating things and Roblox already has this in mind?

For extra info: All ‘regular’ parts have .CanTouch off.

Well do you have lag now? It might not cause a problem tbh.

1 Like

It might just be due to the map size honestly, but considering the amount of parts using the touch function I’m not sure

One way would be to add all these parts to a folder or give them a specific name/tag. Then go through them via a for loop.

local parts = workspace.specialparts:GetChildren()
for _, part in pairs(parts) do
     path.Touched:Connect(function(hit)
          -- do stuff
     end)
end

I have implemented this, I’m just not sure if that’s the problem (assigning all these functions to all these parts rapidly)

Hmmm. I think roblox is adding a thing so only things you can see get rendered. If you want to solve this now you could remove unnecessary things or make it so (i’m assuming your map is an obby) when you want to play a level or difficulty it will teleport you to another server.

I might just have to check if there’s models I have to optimize since the point is climbing up entire mountains, chances are there’s probably a lot of them that just haven’t been optimized in the slightest

1 Like

Well what you could do (idk if this will do anything but) Pet simulator 99 has a thing so when you enter area the “breakables” render in a pop onto the screen kinda. I don’t know if this will do anything but you could try this. I would play the game to see this yourself.

If you have large finished sections with multiple simple block shaped kill Parts you could Union them all into one Union and have a single script for the Union. Players touching any one of those individual sections would trigger the Touched event.

That’s actually pretty bad practice.

~3k parts means you’re making about ~3k connections, each of which cost about 64 bytes of memory.

I’m not sure if connections actually cost that much memory (could be more), or if the engine internally optimizes it (could be less), but you’re effectively eating up hundreds of kilobytes of memory to do something as simple as that.

It may be a small amount, but you can absolutely put that memory to better use, and you don’t sweat your low-end devices out.

Why wouldn’t you bind a Touched event on the player’s character itself? It does the same thing at a lesser cost.

Better yet, why are you using Touched? Use spatial queries.

Also, please don’t do this. This is an even worse practice.

Unions are infamous for having bad collision geometry, and the resulting mesh usually takes up more memory than if they were parts because they generate a lot more triangles/vertices.

4 Likes

What I said was if you have simple block shaped items so there were no complex shapes involved.
What I should have mentioned is to make sure they aren’t very close together to cause the Union to be physically rendered different from their actual shape. Using PreciseConvexDecomposition instead of Default as the CollisionFidelity would help if that was the case.

The question was about having lots of Parts with separate scripts. I figured that having 1000 similar
kill Parts in a folder with the same script would probably be worse for optimization than 1 Union with 1 script.

Your suggestion of having 1 touched script (set up to handle all the different types of events) in the player with tags on the Parts would likely be better.

Kinda funny I thought of these a few days ago, right now I’m trying to learn blender though since my friend used so much unions for what could easily be a meshes

Anyways this seems like the way to go