SetNetworkOwner is being handled on the server even though the object does not exist

Okay so in short I have this zombie that is always a ragdoll, they are connected to the HumanoidRootPart on a prexisting rig that has nothing but the humanoidRootPart (see below) via a ballsocket constraint

and a local script adds the ragdoll to another folder called ZombieRagdolls. Even though on the server all the zombie is, is just a basic single part the ragdoll seems to be really persistent on freezing up if the player gets too far

what the client sees:
image

and what the server sees:
image

any ideas?

1 Like

You could get the :Dot() product of the zombie with the player as your first parameter (zombie second). And then calculate angle at which you want to fling the zombie.

You can also get how far you would like to fling the zombie based on distance I believe.

For applying velocity, I think the zombie needs to be an Actor or something, never applied velocity to npcs so I don’t really know a foolproof way.

I don’t think you read the topic at all

sorry for the snarky response I was just a bit upset trying to figure this out, the issue im having is the server is attempting to take network ownership over the physics even though the object(s) do not exist on the server

You’re right I didn’t read the contents of the thread lol

Wait, if this is a simple NetworkOwnership issue why not just tie the ownership to the player that hit it last?

When you get close to a part that’s on the server, it will be tied to your ownership until you leave the radius of the part.

I don’t usually solve problems by just talking, so I usually just script an example and make comments.

The issue is since the objects do not exist on the server I actually cant set the network owner lol, on the server all that is visible is a single part that represents the zombie and on the client everything visually is added including the ragdoll. and if the items are added on the client shouldn’t that mean that everything added from the client be automatically owned by the player?

and plus in the video (if it does load idk why it isn’t) the zombie’s ragdoll works fine if theyre close to the zombie but the second they get about 6 - 7 studs away the zombies ragdoll freezes as if the network owner is being changed to the server

I mean why not just print(Target:GetNetworkOwnerShip:()) & see if it still being tied to the player?

And why aren’t the limbs of the zombie not being replicated on the client anyway? I find it weird that you’re representing a humanoid with just a part on the server.

Hoooolllddd on a second does even getting the NetworkOwnerShip be allowed in a local script?


thats a no

Figured as much, (again) when I place a part via on the server and constantly check it’s ownership, when a player walks about ~10 studs in its range it sets it to the nearest player.

Don’t know if there is a way to change that, because your part only exist on the client.

And because the part exist only on the client, no rendering & thus physics simulation is conducted on that part. So when the ownership is set to “nil”, nothing happens as it’s not being rendered/simulated at all.

It will take the angle & position of it’s latest networkship owner.

Hope this helps, I actually read your post this time.


on the server only the player has the network owner set to them and every other object is just defaulted to the server

seems to be a similar issue on the client except the parts added to only the client are included

this very much could be an issue since the ragdoll parts that are attached to the main part are being changed to the same network owner as the main part but I’m not sure how I could change this from the client.

1 Like

Sorry I haven’t responded, but yeah I suggest that you host the ragdoll limbs on the server as well.

This will enable you to use the built in NetworkOwnership API to allow for more ping/internet control over more instances.

Alternatively, another possible solution is to fiddle with the properties under the Streaming tab in the workspace instance.

If you still have problems, I’ll be able to test other solutions for you later.

The part might be put in a sleeping state? Try setting AllowSleep to false in studio settings and see if that fixes your issue.
If this is the issue, I’m not sure how you’d go about preventing it from sleeping though besides having it on the server.

streaming these parts onto the server will drastically increase the amount of server lag, im planning to have upwards of like 700 zombies in the scene at once, plus I want each zombie ragdoll to be on the client so if 2 players are looking at one zombie its not like one player sees the zombie laggy and the other sees it smooth


nope sadly still broken

I’ve read up and I don’t know exactly how to solve this because I haven’t encountered the problem before. I’ll offer some debugging motivation/advice.

a. Have you made sure that this works with a completely client-sided zombie ragdoll?
b. Have you made sure that this works with a completely server-sided zombie ragdoll?

Works fine if its fully on the client and also works on the server albeit slightly choppy, but that’s to be expected.

I’m currently trying to make it fully on the client but I’m worried about desync. I’m still going to go back to what I was doing before if all else fails and keep on trying

Ok I broke it down to its most basic parts. Basically it seems like what you’re trying to do is impossible (impossible to do smoothly).

My take: you can’t have a server-sided hrp and a client-sided socket constraint attached to it because the server is trying to compute physics on the hrp which is conflicting with the client trying to compute physics on the same “assembly”.

Zombie Ragdoll Network Ownership Testing.rbxl (61.2 KB)

2 Likes

Maybe the issue arises because the root of the assembly (the HRP) network ownership is set to the server/auto? I would not attach the limbs to the HRP but maybe a ghost part that is in no way attached to the HRP but has the same CFrame.

That is disappointing and partly what I was worried of, I just was hoping it was a different answer, thanks anyways

1 Like

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