Are we allowed to set network ownership or not?

task.spawn(function()
	while not self.isDead do
		wait(.1)
		print(HRP:GetNetworkOwner())
	end
end)

HRP:SetNetworkOwner(nil)

I have a simple script.
I never anchor the HRP but I do enable, disable joints and enable/disable a linearvelocity, alignposition objects.
Neither of these should reset my explicitly stated networkowner.

Yet, somehow, after hitting the NPC a couple of times and having it ragdoll; it will randomly assign me as the networkowner.
Even though I’ve explicitly stated I do NOT want it to automatically assign ownership.

What’s the point of having a function that doesn’t care what you set network owner to?
To force users to create an inf. while loop just to ensure ownership?

1 Like

Sounds like you’ve got an assembly there :sunglasses:

You need to set each parts network owner to nil, because if one part assigns itself to your client, you get the whole thing:

If a physics-based mechanism has no anchored parts,setting ownership on an assembly within that mechanism sets the same ownership for every assembly in the mechanism.

Even if I do

for _, part in self.Model:GetDescendants() do
	if part:IsA("BasePart") then
		part:SetNetworkOwner(nil)
	end
end

Some NPCs will assign me as owner.

  1. Just confirming were using a server script and not a local script

  2. Method to confirm you have permission to set a parts NetworkOwner, example code shows how to get the relevant error

Otherwise not sure, id double check that all your parts are actually baseparts and not some other similar but different class like TriangleMeshPart

If the changes you’re making to the joints involve destroying or inserting them, I’d probably start there and remove that part of the functionality to see if it changes anything, as there may be some internal engine behavior that automatically sets network owners when deinstantiating or reinstantiaing humanoid models

  1. Yes
  2. If I couldnt set network ownership the script would get an error and stop working, but i see no errors and the npc keeps moving.

Yes, that’s my thought too. Which is why I’m asking the question if roblox is so adamant at deciding who gets to be networkowner then why even bother adding a function for it?
They’ll just overrule my decision anyways.

I have had effectively the same problem on a project. Haven’t attempted to fix it yet, but I think it’s related to when I despawn my humanoid-containing models, so … :upside_down_face:

I’ll follow up on this if I find anything

1 Like

You may not see it in a spawn like that … but it worked.
Not going to see this part … print(HRP:GetNetworkOwner())
Unless it’s warn (I think) try warn(HRP:GetNetworkOwner())

Following up –

I create my Humanoid containing NPC’s, which are entirely unachored and move using MoveTo(). When I spawn them in and call SetNetworkOwner(nil) on each base part, their network owner stays the same (i.e. the server).

If I call it on just the PrimaryPart the NetworkOwner of the assembly will still change as if still set to auto network ownership.

When I respawn the NPC’s, (i.e. setting the Model.Parent = nil and then later setting Model.Parent = workspace.Folder), the NetworkOwnership settings seem to revert to Auto, and I have to loop through each BasePart and reset the network owner – but it gets me the desired results and the NetworkOwner seems stable

Code for reference

for i, v:BasePart? in pairs(Model:GetDescendants()) do
	if v:IsA("BasePart") then 
		v:SetNetworkOwner(nil)
		task.wait() -- Hmmm
	end
end

I have that task.wait() in there to delay a frame just in case the physics engine / network acts up and tries to revert the changes – I’m not certain this matters, but I know for a while (maybe still? haven’t checked recently) that if you try to re-parent a players character too soon after player.CharacterAdded fires, it will revert to the previous parent and the output would print something about it.


Hope this is helpful