In my game I have a garage door that is connected to an invisible anchor part with a hinge constraint. This makes it so when a player drives into the door, the door will rotate and can be broken off. If the player crashes into the door at high speed, they will not get a chance to claim network ownership of the door before the impact so the door stays fixed. When the player is near the door or crash into it at slow speed, it behaves as expected
If the physics for nearby parts with no network ownership were simulated as if the client owns them, any physics interactions with those parts would (I think) be much smoother
Creating them on the client means they’re not synced with the server, and unless I manually set up networking for it then every player sees something different. I want the world to be consistent for every player.
Creating them on the client also involves code which not everyone can do. Developers should be able to have smooth physics without having to manually hack around stuff like this
What benefits are there to creating it on the client?
I need this. I’ve been trying to make server-based CFrame trains that use server network ownership, and they use velocity to make them less jumpy (240hz physics fighting 60hz, fun).
On the clients though, only the CFrames get replicated and not the movement from velocity, which causes the trains to jump erratically, especially in high ping situations.
All parts that are not owned by players are owned by the server, there are no “unowned” parts.
Unless I am misunderstanding, what is stopping you from manually forcing it’s network owner to be any player (with :SetNetworkOwner) within a certain range of the door, and removing their ownership of it when they exit it’s radius?
I just found out that there is a local-space simulation, but I don’t know if it would help in your case because it is intentionally limited to reduce discrepancies and tends to rubberband the physics of anything your character touches, not very ideal for fast cars.
Set player disconnects while the part’s physics is handled by that player’s device
Also you have to get the first player, either you save the first joined player into an object value or you make a volume trigger where first player who triggers it “owns” the unanchored parts around the area, and when they leave they are assigned to server. Which at that point just let Roblox engine do it for you.
That would just return the ownership back to the server.
The issue is that it only automatically assigns ownership for parts close by, as you can see in the first video of the post they keep the car very close to the door to not lose ownership of it. But, with a manual technique, they can give ownership to the player as soon as they get close enough to the door that, at the car’s fastest speed, they will collide with it in about half a second. Plenty of time for the ownership to go through and reduce physics lag.
ngl i wrote this while i was baked but ill try to summarize what i was thinking
client side would solve your issue ofc
mostly a personal preference since i prefer all dynamic objects be handled client side as much as possible (sanity checks on the server depending on the feature ofc)
true there is a possibility of desync but it shouldn’t be an issue if you run the same door opening code for everyone in the game (on your client ofc) it shouldn’t happen too often if implemented properly
not to mention the bandwidth saved from not having to replicate the physics object from server to all clients
overall i personally think the benefits outweigh the small chance of a desync which should only cause a minor visual bug
By unowned parts, i mean parts owned by the server. The server should still have authority but the client should locally simulate the physics instead of waiting for the server to update them. As soon as another client takes ownership of the physics, the local simulation stops on that part
AFAIK, that’s how a lot of AAA titles handle this, like GTA V. They’re basically running a single player game, then resyncing and snapping everything back every few milliseconds. Roblox just replicates CFrames and velocities, then interpolates the parts for a smoother experience, which obviously won’t work well if there’s a lot of interaction.
I’m somewhat surprised this isn’t a thing yet. It’s not easy to implement, but also not some weird rocket science. You just have to partially simulate constraints on the client instead of treating everything like sleeping parts with velocities.