Need help with explosions and optimization

In a previous thread, I was looking into optimizing explosions for a new game I am working on, where explosions are an important part of gameplay.

The solution I came up with was, whenever a part is exploded and physics is enacted on it, I change the NetworkOwnership to the player who blew up said bricks. It seemed to reduce a lot of performance issues, but it still seems like there are some issues.

The next system I have planned is, when a part is blown up, it would either wait 5 seconds after the explosion, or until it stopped moving, and then the part would be anchored. The part would also have a Tag added to it via CollectionService, where if the brick had an explosion enacted on it and it was now anchored, further explosions would un-anchor the part and then re-affect it again.

I personally did not want to do this, but, for the sake of optimization, it was either this, or having parts get destroyed/regened after being blown up (not something we want to do).

The issue I am having is, which system do I pick? The waiting 5 or whatever seconds after explosion would be the most optimal, but that wouldn’t account for uncommon occurrences where a brick is still moving around after a big explosion after 5 seconds.

The other option would be far more accurate and precise, but it would require a RunService connection on almost all affect parts, which I’d imagine would be pretty bad for performance.

How do I go about this?

Effects = Client
Calculation = Server

If it’s an effect for the game, only the client should have a say in it.
For Projectile based systems, the Server should have a say in that.

For the Debri (if done by Server), physics should be calculated using the Player who fired the Projectile.
Otherwise it’s a client thing.

Why all parts? That just sounds like a waste of resources.

1 Like

Well, the explosions are breaking the joints/breaking buildings in our maps, so it absolutely has to be on the server. As for Debri, we already set Debri to have its NetworkOwner set to the player who blew up said Debri, but that doesn’t solve 100% of the performance issue.

On almost all affected parts, e.g., when a part is blown up, a RunService connection is established that waits for when the part stops moving (I forgot what property this is called off the top of my head), which would then anchor the affected part, disconnect the RunService connection, and then wait to be blown up again, where it would get unanchored, have its NetworkOwner set to the client while it flings around, and have the same RunService thing repeat. Parts that have not been affected you would not have a RunService connection established to them.

Came up with this script. The explosion script I have is supposed to add the part to a dictionary that gets checked every 5 seconds to see if any parts that were added to it have stopped moving.

local expl = {}
local checking = {}
local RunService = game:GetService("RunService")
local CollectionService = game:GetService("CollectionService")
local Time = 0

RunService.Stepped:Connect(function(t,dT)
	if Time >= 5 then
		Time = 0
		for part,val in pairs (checking) do
			if val ~= nil then
				if math.floor(part.Velocity.Magnitude) == 0 then
					part.Anchored = true
					CollectionService:AddTag(part,"anchorExempt")
					checking[part] = nil
					print("anchored "..tostring(part))
				end
			end
		end
	else
		Time += dT
	end
end)

function expl:Add(part: BasePart)
	checking[part] = true
end

return expl

Is there anyway I could optimize this further?

Ok, I am having an issue where:

  1. Some parts anchor prematurely, mid air, like seen in the picture below
    image

  2. Some parts have weird collision/physics properties, even when anchored, like in the video below.

How would I fix these issues?