Is there a better way of handling network ownership?

Hello,
Theres been this issue where roblox’s default network ownership would give too many blocks to the server and would result in blocks being laggy or stuck when trying to push them, I fixed it using this code but I have questions about if its optimized
(blocks are unachored objects, around 500 of them in servers)

Code

local function updateownership()
	for i,block in pairs(game.Workspace.Blocks:GetChildren()) do
		if block:FindFirstChild("MergeSize") and block.Anchored == false then
			local closest = {nil, nil}
			for i2,plr in pairs(game.Players:GetChildren()) do
				if plr.Character then
					if closest[1] ~= nil then
						if plr:DistanceFromCharacter(block.Position) < closest[2] then
							closest = {plr, plr:DistanceFromCharacter(block.Position)}
						end
					else
						closest = {plr, plr:DistanceFromCharacter(block.Position)}
					end
				end
			end
			if closest[1] ~= nil then
				block:SetNetworkOwner(closest[1])
			else
				block:SetNetworkOwnershipAuto()
			end
		end
	end
end

while task.wait(5) do
	updateownership()
end

.rblx File

codereview.rbxl (52.6 KB)

Please share any suggestions/optimizations, thanks!

This is cool but not practical.
Yes, it will make physics smoother (in some cases), however this will increase the load on clients, both network and processor load, thus more heat and less battery life, and it will make clients lag more than a laggy server.
Testing on studio is a bit misleading when it comes to different processors and network latencies. While it worked pretty well (physics were faster) on studio other than clients lagging, this would not work as smoothly in a live game since there’ll be many parts owned by many players, many different processing speeds and many different network latencies. Network ownership transferred parts are also vulnerable to exploits.

Might still have some use cases but I would not use a such solution in a live game which players play regularly.

The only real way of speeding up physics as a developer is really just optimizing the physics parts in a game by keeping their counts down, or if they have to be high in count, at least some should be in sleep state while others are not.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.