Issue Type: Other Impact: High Frequency: Constantly Date First Experienced: Date Last Experienced:
Reproduction Steps:
Create a part on the server, give physics ownership to the player and fire a client event the player to create VectorForce within that part. Set the VectorForce to suspend the part in midair.
Expected Behavior:
I expected other clients to see the part in sync as the client who has physics ownership of the part.
Actual Behavior:
What actually happens is when a client, other than the client who has physics ownership of the part, walks near the part, the vector force no longer has an effect on the part. It drops to the ground. However, for the client who owns the physics of the part, it is still suspended in the air.
This is expected behavior. By creating a force in a local script and not creating it on the server, you are generating a physical modifier that only exists on one client.
This means if a different player gets close enough to trigger “local space simulation”, they are missing key information to be able to locally simulate the motion, IE: the Vector force.
To fix this, you should create the VectorForce on the server so that every client about it. While you may want to modify the properties via local script for responsiveness, you will need to make sure the server replicates those settings so that they show up on other clients.
You’re still modifying the the property of the force on the owning client only. This doesn’t replicate to server and other clients for security purposes.
You either have to modify it on every client, or on the server.
Network Ownership simply tells the game who is responsible for authoritative physics simulation. Network Ownership does not allow you to modify properties in a way that replicates to other clients.
If you make local modifications to some object’s properties, they will not replicate to other clients. If these modifications are to properties crucial for correct simulation, then approximate simulation on other clients will not work correctly.
Part of why your case is extra problematic is because you are essentially using a constantly updating force to apply “Zero Gravity” on the part, which causes the source simulation to fall asleep and never correct other player’s errors in local simulations. In most other cases, missing some force update on their client would get corrected in the next render step because its constantly receiving updates from the source. Your part is sleeping on the source, so no updates arrive to correct the bad simulation.
So what are my options for getting pass the “sleeping on the source” issue that causes no updates?
No other games have this issue; I assume because they don’t have the same case as me. Afaik, they just give the client network ownership and go about their day without forcefully sending extra data.
There is actually a way around this: re-setting the network ownership to the player on RunService.Stepped will cause the player to be the sole owner of the part, and no other client will ever take control of it on their end. https://streamable.com/woas66
Here’s an edited version of your repro file, with the only change being it sets the network owner on Stepped. repro test.rbxl (26.6 KB)
Thank you! Is this way standard or is it unconventional? I thought that once you set networkownership, nothing else could change it? Or has this property changed?
You should never have to call SetNetworkOwner on RunService.Stepped. SetNetworkOwner is a persistent state.
The issue here isn’t that ownership isn’t sticking. The issue here is that when you get closer to an object someone else owns you may start to simulate it locally in approximation so that you can bump into it without weird interactions.
The issue here is that the local simulating client lacks the simulation information about the VectorForce that the Authoritative client has. The only way to solve this is to make sure that every client has a local script modifying the vector force OR that you modify the VectorForce on the server as well.
I actually bypassed this issue by preventing the system from ever going to sleep on the source. I did this by having a constant force that shifts the assembly up and down consistently, changing its velocity. This seemed to do the trick.
A dirty fix but until this issue is fixed, I don’t know what other options I have besides this and the one you listed.
I apologize; it appears I spoke too soon. A few months ago, I had an issue where if a player touched a player with its network owner set, sometimes the network owner would change anyway (note that this is NOT regarding local simulation; the owner changed completely, and the original set owner lost control of it resulting in massive latency), leading to me resetting it every .Stepped and believing there was an issue with network ownership. It appears something has changed between then and now, as I just opened that same place, removed the .Stepped set, and it works as expected.
Regardless, I now see this is not the same issue I had before and, in this case, is actually intended behavior. Sorry for misinterpreting the topic.