I’ve been exploring a setnetworkowner for moving objects, and I’m wondering if it can be applied to replicate specific character movements instead of relying on remotes. I believe the player already has its network ownership, but I’ve noticed that character-based joint/weld/movement exploits replicate , because they’re local. Is it possible to achieve this without using remote events? For instance, in a VR scenario I created, I managed to replicate hand movements using only setnetworkowner, although to be fair those were using alignorientation and position
As far as I know it only replicates position, so cframes pretty much.
It just gives the client control over an object’s physics, nothing else.
You still gotta create welds on the server to make it replicate.
Yes i think so, CFrames are just custom datatype holding position and orientation of a part.
So you can weld your parts and use Network Ownership to do the work, but i suppose you can also use the new unreliable remote events but because you don’t want remote events, network ownership is your friend.
I wish there we’re more replication options on Roblox, we have remote events/functions for client-server communcation, we have network ownership for physics-based stuff but i think there should be bit more but that’s off-topic and not related to this.
Ill try welding them. I mean remote events arent unrealiable per se, but networkownership is a very conservative and modest option, compared to how much bandwidth could be potentially lost (consider movement being updated every frame for each client). i also agree there should be more replication options and more control over what we already have
1 Like
You can weld them on client-side and it weld creation won’t replicate, but movements will as long as you have network ownership it will never desync.
When you give networkOwnership to some client he has full control over velocity, position, cframe, and position and any bodyMovers(alignPosition, alignOrientation, …) work as intended because the only difference is the fact that physics are calculated on client and not on server.
Also, player which had networkownership over parts could destroy them, parent them(depending over what), that meant that those animation based exploits were possible, although roblox patched it with RejectCharacterReplication, it is still possible to destroy parts by using FallenPartsDestroyHeight.
RejectCharacterReplication can be disabled for now, but this will be patched soon since i don’t think this value supposed to stay for too long, i don’t even know why it has a seperate tab in workspace when it can just be in the same list as any other temp opt-in’s.
Also you can’t control the replication with this, since any value you put in StarterCharacter with this value set to Disabled will mean client can change any instance’s value in their character so i don’t recommend this.
So yeah, while it would’ve been cool if there was a way to select which instance’s properties changes will be sent from client to server (like giving client authority to an instance), you have to use remote events, network ownership to send data over the network. These are the two options.
How much better are unreliable remote events than standard remote events for such a usecase? (30-40 players firing every 0.1-0.5 seconds to replicate cframes), or would network ownership be superior? i also tested using welds and sadly they wouldnt work for such a use case so i guiess i have no choice but to use remotes.
Network Ownership would be better but you won’t have control over the physics since it’s handled automatically by the engine, but i heard unreliable remote events can also be used since they are somewhat made for rapidly being fired unlike standard remotes which will lag the game if you fire them constantly, e.g RunService loop.
I think there is a DevForum post about UnreliableRemoteEvents
I ran a benchmark where i used a pretty laggy effect replication as a test scenario. the unreliable events reduced sent kb/s by 65-70%. (native roblox networking) maybe a network library in conjunction with unreliable events could come close to network ownership and reduce the kb/s greatly
1 Like