Update: not a bug. I misunderstood how this works now.
Deleting a part should wake the entire physics assembly it was an element of. Right now I get physics artifacts if I use a script to delete the last part that was holding up a structure.
Build a model of a wall of interlocked parts, clone it, and make this join
Test solo and select this brick in the first wall
This wall is now floating. It will stay this way until touched by the player.
Walls Behaving Badly.rbxl (20.0 KB)
I think this is intended since the part was deleted on the client and the network owner of the assembly is still the server since your character was not close enough. If the part was deleted on the server though, it would wake.
Due to how network ownership works, you won’t be able to set the player as the owner due to the API only working on the server. So the server still sees the the assembly is welded to an anchored part.
No this just needs to work.
It doesn’t matter who the network owner is, the physics are wrong. Ideally developers would not even have to think about network owners.
In this case, I’m testing locally. I’m not even sure there is a network owner.
Studio behavior has changed a lot. It now simulates both client and server separately.
The reason the wall isn’t falling is because you are deleting the brick client-side. (Notice the blue border on your screen.) Physics glitch out when stuff is changed only client-side, such as when deleting bricks.
Switch over to the server-side and delete the brick from there, then the wall will fall down.
Network ownership is present in local tests though.
Well it solves exploit related concerns preventing exploiters from teleporting unanchored parts around etc.
When a client deletes a part, it doesn’t replicate server-wide. In this case, the server still has authority over the physics of the assembly, so it doesn’t just fall. When a player touches the assembly or gets close enough, the network ownership is transferred to the client, but this is not replicated server-wide since the changes were made locally.
This is how network ownership has always worked.
Does that still work if the wall has the client as the network owner? That’s a wrinkle I’m still not sure about.
I.e.
I.e.
For my code to be bulletproof do I need to delete it on both the client and the server since I can not be sure who the network owner is at any given time?
When the part is deleted on the server, all clients will get the update, so the wall will fall regardless if the server or client was the network owner.
BaseParts actually have a function called GetNetworkOwner for you to see which machine is handling the physics, but this can only be used on unanchored parts.
I would guess that GetNetworkOwner can return a stale result because it’s probably not a 3-way handshake. The ownership update can be in the wire at any time, so client and server might disagree.
As long as you do everything server-side, physics work fine. You don’t need to worry about micro-managing physics control too much.
I have not enountered any disagreements between the client and server, I handle most of these stuff on the server anyway. But discrepancies may arise if the client was an exploiter or the replication was not handled properly.
You can’t set network ownership from the client though, so it would most likely be handled by the server.
If you modify an assembly at all via a non-physics action (such as deleting via the studio interface, or moving / modifying it with a script), the assembly automatically becomes server-owned until the server eventually decides to hand it back up to a client after some delay.
So, TL;DR: If you delete one of the parts on the server that forces it to be server owned as part of the deletion.
This is intended by roblox so no one can crash someones game, For example @Shedletsky
If a game has loads of free falling models it would lag the whole game and the “Player” would crash.
What roblox did is when there is free falling blocks, You need to be interactive with that object before it falls down.
I was thinking about this more and it seems to me that deleting parts locally is in general just a bad idea.
I can imagine a 2 player scenario where player 1 deletes this part and is standing on the fallen wall section while the server thinks the wall is unchanged. Player 2 would see player 1 floating in space.
I’m sure there are legacy reasons why LocalScripts are even allowed to edit datamodel properties that are filtered. I.e. functionality that depends on the ability to create a desync.
Not just legacy reasons. People do a ton of locally rendered effects these days, which are implemented though creating and modifying local objects which will never be replicated back to the server.
If you mean for server created objects, people still need to be able to edit these objects locally. For instance, if you want to implement any sort of dragging behavior, you need custom local control of the position so that the dragging is responsive even though the server will eventually get those changes too through remote events.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
