Ikr, I’ve tried this already but it’s painful when it comes to reconnecting multiple attachments, movers etc. after cloning. Such option could be implemented by adding a new Network Ownership call variant such as :SetNetworkOwner(true) on the server where “true” would stand for individual client sided replication on each client.
this is absolutely great! will you ever fix PrismaticConstraints deleting attached parts that have too much mass though? I’ve wanted this to be fixed for a long time.
Now that you are looking at mover constraints, could you make AngularVelocities to be able to not set a torque on ALL axis´? the old BodyAngularVelocity allowed this, and i think a big downside over the new AngularVelocity is that you can’t set a MaxTorque via a Vector3, allowing the user to just set torque in the axis’ they want.
What even was the purpose of deprecating BodyMovers? i would say that this change had the opposite effects than intended
This would vastly improve my boat physics!
this looks very promising, my npcs have a tendency to have delayed movements due to latency and the solution was always to set ownership to the server, but even then it still looks wonky.
hopefully with this new rollout they can soon look much more fluid with their movements.
Yeah, can we please get a 0 attachment mode for the mover constraints? bodymovers didnt need you to do that nonsense.
I’ve been experiencing issues when changing the Network Ownership of a part. If Ownership is forced to be the server instance, there’s a noticeable delay of about 0.6 seconds before the part’s physics are calculated.
Here’s a video showcasing this issue:
If Ownership is set to a player, the part might freeze in place until touched by another physics object or the Ownership is changed. This is more likely to happen if the AssemblyLinearVelocity is set to a blank vector before or after the Ownership change.
Again, video evidence to backup my claim:
The first time I throw the radio, it eventually falls because I set a 3 second timer to transfer the Network Ownership from the player to the server.
I have a system that makes a shuttle spin, it worked perfectly fine till today:
When I apply AngularVelocity or a VectorForce everything goes wild:
This totally breaks my game so yeah, try to fix it please
Fixed it
Are you seeing this behavior with the new property enabled? You should see no changes with the property at its default value.
Hi, I found the cause of the error and I think it has something to do with this update.
The new property was on and it affected how very dense parts moved.
I found that three parts of a model had a mass of around 43700 while their size magnitude didn’t exceed 10 studs.
This was causing the error and it didn’t occur before the update
Thanks for checking. I’d be happy to take a look if you’d like to DM me the model. I’ve debugged a few of these already and the required changes to get everything working again tend to be pretty minimal.
I can DM you the model but I’ve already fixed the issue, if it’ll help fixing some bugs with this new implementation then I’ll go ahead :).
I really hope this gets fixed soon! My train games are all kind of screwed over right now.
I experienced an issue related to NetworkOwnership / Assemblies / MoverConstraints that I feel may be good to address with this change. I had it on default, tried it with disabled / enabled, and it didn’t solve it.
For more information: Weird in-game AlignPosition issue (Big objects getting pushed by smaller objects)
Let me know if you have any questions.
I’ve run into the problem where, upon cloning an airplane that uses the LinearVelocity mover, changing the LinearVelocity.Enabled value on the client doesn’t change the active value of the constraint. I have to switch it on from the server. After that it can be modified on the client. This is very unusual, as it doesn’t make sense why the client, when possesing network ownership of the plane, cannot enable the mover.
MoverConstraintRootBehavior is disabled.
Why can’t the server apply impulse on a client owned physics object?
The MoverConstraintRootBehavior set to “Enabled” just doesn’t solve the issue.
LinearVelocity parented (on the server) to an attachment under the RootPart (NetworkOwner set to ONLY server).
it still has a super large delay and snaps…
I’m running into an issue that appears to be caused by this:
Attaching unachored parts to a locally instantiated anchored part via a rope constraint causes the entire physics assembly to freeze
Correct behavior: