Improved Mover Constraints: Enhancing Stability and Network Ownership

Updates Announcements
#24

If I disable AlignPosition on the Client I need to disable it on the Server as well for a specific thing.

If I could somehow visualize physics parts from client and server at the same time, instead of server views it would confuse my head less.

19 Likes
#25

I think itā€™s great that they want to fix some bugs or glitches in the physics, I like that they give work to this kind of things as well!

23 Likes
#26

Finally, after all this time. I canā€™t believe it.

20 Likes
#27

Will parts on client still fall asleep very easily? Because I have a game with an explosion on the client and the parts get stuck the air because they fall asleep, but when the explosion happens on the server no parts are falling asleep and the explosion goes smoothly.

20 Likes
#28

feeling kinda dumb, cause i was thinking how the heck are you guys making knockbacks so smooth? and it turned out that yall were simply using body movers.

I researched a lot to find nothing new, this problem with LinearVelocity is 100% news to me, and the fact that body movers got deprecated just made it worse to find any solution cause in my head, I didnā€™t wanted to revert, not knowing they are still better right now.

20 Likes
#29

Why do we need to make the transition again? In every use case Iā€™ve encountered, legacy movers are easier to use and have more varied usage.

14 Likes
#30

You can already do this via scripting, eg catch the part getting replicated to client, hide it and clone a local copy w/physics.

12 Likes
#31

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.

16 Likes
#32

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.

14 Likes
#33

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.

24 Likes
#34

What even was the purpose of deprecating BodyMovers? i would say that this change had the opposite effects than intended

14 Likes
#35

This would vastly improve my boat physics!

15 Likes
#36

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.

9 Likes
#37

Yeah, can we please get a 0 attachment mode for the mover constraints? bodymovers didnt need you to do that nonsense.

30 Likes
#38

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.

9 Likes
#39

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

3 Likes
#40

Are you seeing this behavior with the new property enabled? You should see no changes with the property at its default value.

2 Likes
#41

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

2 Likes
#42

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.

3 Likes
#43

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 :).

3 Likes