Are local parts guaranteed to have network "ownership" set to the client that created them?

I want to have items players can pick up from the world. When they get close, the item starts moving to them with physics. However, these pickups are local, and not created on the server. I tested to see if I can control local parts physically, and it seems I can. In the below video, I created a local part near another player, far across the map, and was able to move it physically (in this case, just straight up):

https://gfycat.com/ShorttermFluffyBaiji

However, I’m not sure how much I can rely on this since local parts aren’t officially supported and AFAIK the engine doesn’t expect them. Will I always be able to move local objects physically, or will I ever encounter cases where the client thinks someone else should own it and gives up control?

4 Likes

As far as I know, the client will always have ownership of local parts because the server decides what should have network ownership, not the client. Otherwise a malicious client could decide it has network ownership over everything and move it into the void.

In general, any parts spawned on client should by default be owned by the client as far as the client knows. If we somehow broke this behavior, even though it is not officially supported you can feel free to file it as a bug.

Be careful, if you make the objects big enough, they will compete for “Root” with the “HumanoidRootPart” if you weld them to the character. This is the most dangerous part because if Client and Server disagree about Root, replication will break.

15 Likes

I create local vehicles for my players to sit in while they customize their cars - could this break replication? They are welded to a smaller seat but the assembly itself is definitely contains bigger pieces than the root part.

Oh wow. I kind of wish I knew this earlier, it explains why my humanoid enemies broke a while back.
Please, can we just get more documented information on Humanoids? Can’t remember who said it, but they have been a ‘black box’ for years and we developers have no idea how they work, so we can’t tell what bugs we cause by doing things like this. Either that or port it to Lua as @EchoReaper suggested when he made a thread about (I think…) .

1 Like

Despite the wiki, ReceiveAge seems to return 0 when you own the part. A quick way to check if the client owns network owner without relying on server replication.

Uh, yeah, if it’s local then no other client (or the server) can see it, so it’s owned by the client that made it

That would likely break replication.

1 Like

This has little to do with Humanoids in general, and has everything to do with an internal concept of a “Spanning Tree” in Roblox. Its one of the deepest rooted concepts from the origins of Roblox that defines how things replicate, how simulation is organized, and how things interpolate. It is something we will be attempting to address and make less obscure in the next year or so, but it will take a lot of work because it is essentially like ripping out the roots that hold everything together.

So much makes sense now - I’ve been having lots of weird replication issues and this is likely a big piece to it. Thanks for the response.

Just FYI, the general rule right now is that it attempts to use the size of objects to pick which should be the root in the entire construction. Some objects have a special multiplier, like HumanoidRootPart and Seat. Roots matter currently in Roblox because depending on who the root is, when you weld 2 parts together, the non-root will be teleported to the “root”.

Anyway, if you spawn local parts and weld them to an object the Server knows about in a way that makes the Client and Server disagree on who the root is, you will essentially break all replication for that part.

Don’t rely on this size thing, because when we start trying to refactor this, it will NOT be the way the new system works.

1 Like

Does the “root” have any relationship to PrimaryPart?

1 Like

Nope. No-user facing APIs modify it.

1 Like

Ahh, my bad. Still interesting actually.

1 Like

No “my bad” is necessary, there is little reason why you would know this without looking at our source. It is unfortunate how much this internal mechanism is affecting user-facing events. This is why we have a plan to try to refactor a lot of this, but it won’t be easy.

Right now it is obscure, obtuse and not fun to reason about. We plan to make it better. It just will take some time.

5 Likes

Parts placed in the server’s local camera try to have their ownership set automatically which causes my locally simulated NPC’s to freeze. I know this isn’t an actively supported feature so I just manually set ownership.

1 Like