I am creating an unanchored part on the server, and calling :SetNetworkOwner(player). The client anchors the part and then begins setting it’s CFrame, which works great locally - but, when I set .Anchored to true on the client, all CFrame replication stops from the client to the server - even though on the server, it has NetworkOwnership assigned to that client.
Replication works fine without setting .Anchored to true on the client - but this results in unsmooth CFraming on the client, as physics runs faster than Heartbeat.
As far as I understand, the part should maintain NetworkOwnership even after the client locally assigns the anchored property… am I wrong?
Any help is appreciated.
the only way I can get around this and get smooth replication while letting the client control the CFrame is using AlignPosition and AlignOrientation objects - setting both Attachment0/Attachment1 on the server, then having the client set the Attachment1.WorldCFrame. This feels like such a hack - why can’t I just manipulate the CFrame of an anchored part with replication?
Parts do not have the capability of network ownership whenever they are anchored, and this is because this property is meant to be used for objects that have active physics. Anchoring the part locally is a pretty radical idea, I’m surprised it doesn’t work.
The only way you would be able to replicate moving anchored parts from client to server while keeping it anchored is through remote events, and the events throttle if you fire them too many times.
You can also instance the AlignOrientation and AlignPosition locally, and the physics of the part would still replicate.
This is what I’m settling with for now., it just feels so hacky . I suppose I can understand replication through SetNetworkOwner only works when the part is not anchored, as when it’s anchored it is simply ignored in the physics loop. This makes sense for why local constraints work with SetNetworkOwner, too.