I have a part which I want to be welded smoothly from the perspective of the player who has network ownership of it. I can’t do the welding server-side because that will cause the part to teleport on the client when it gets welded which just looks bad. Because the client has network ownership the server’s knowledge will always be outdated due to latency. So the only way I can avoid this teleport is by doing the weld client-side.
This create the following situation which I believe am unable to solve with the engine:
A client has network ownership of a part, and this part’s physics should be replicated to the server all the time. The client then locally adds that part to some assembly which either the client does not have network ownership over, or which does not exist on the server.
These conditions will cause the engine to disable all outgoing replication on the part until it leaves the assembly, even though the client is seeing the part be moved around and physically simulated.
(Anchoring the part locally instead of adding it to an assembly will also behave the same. Adding the part to an assembly that the client does have network ownership over is not relevant here because I don’t have something like that available, so any attempts at making such an assembly would just be moving the replication problem to a different spot.)
The closest alternative solution I can think of is making a client-side clone of the part which is simulated locally on the network owner’s client (and the replicated version of the part is hidden). Then the desired physics information can be manually replicated to the server using RemoteEvents. But I’d rather avoid this since that’s doubling the instances on the client.
A different solution is to locally CFrame the part every Heartbeat to make it appear as if it was welded, without changing anything else about the part’s physics. This works okay but it doesn’t scale very well, and would require another client-side clone of each part if you wanted full physics simulation (though in my case I don’t need that). It also has terrible performance for instances within character models due to this fast clusters issue
Lastly, though technically unrelated, I think it’s worth mentioning that I often have use cases for creating client-side welds for cosmetic or hitbox purposes, with no effect on the local or replicated physics of the main assembly. These use cases are made more difficult to achieve because normal welds interfere with replicated physics, and there is no way to create a one-way weld with guaranteed rigidity.