Improved Mover Constraints: Enhancing Stability and Network Ownership

Over the past several years, we have made a concerted effort to move creators away from the legacy BodyMover instances and towards mover constraints, which we believe have improved functionality and flexibility.

Unfortunately, this transition has come with some regressions in the form of laggy behavior, inconsistent network ownership, and non-intuitive assembly formation. We’ve received many reports of creators encountering issues with the LinearVelocity constraint:

After spending some time understanding these edge cases and developing solutions, we are now ready to address this root cause and improve the logic for all mover constraints. Because this update can break existing mechanisms and because restoring existing behavior may require some iteration, we are deploying the update with a workspace property via a phased rollout.

What is the change and who will it impact?

This update changes the way mover constraints influence the construction of assemblies, specifically the selection of the root part. The following constraints will be affected by this update:

  • LinearVelocity
  • AlignPosition
  • AlignOrientation
  • AngularVelocity

With the new logic, these constraints will affect assembly root selection only when they transmit forces between two parts. When operating with a single attachment, these constraints will be ignored when determining the assembly root part. While the change in root part selection is the only outwardly visible change, the improved logic has a number of internal consequences that make network ownership more stable and improves the responsiveness of the physics solver when adding these types of constraints.

While this change potentially affects anyone who uses any of these constraints, we believe that the vast majority of mechanisms will continue to operate as they do today.

Why should you care?

The updated logic fixes a number of issues related to Mover constraints but there is the potential that it could break things for your users. To avoid any impact, you should verify that any mechanism in your experience using these constraints works as intended with the fix enabled. If not, it will need to be updated before the end of the rollout.

Phased rollout details:

During the rollout, you will be able to control if this updated logic will be used in your experience through the Workspace property MoverConstraintRootBehavior with the options: Default, Enabled, and Disabled.

This phased rollout is meant to help you test whether these changes affect any of your existing mechanisms. You can do so by setting the MoverConstraintRootBehavior property to “Enabled” during the first phase and testing your mechanisms.

This phased rollout will also provide a buffer to creators who may miss this announcement and experience breaking changes once we go to the second phase — switching the MoverConstraintRootBehavior property to “Disabled” during the second phase will provide a buffer for fixing any broken mechanisms prior to applying these changes unconditionally.

Identifying and addressing issues:

All mechanisms we’ve encountered where this new logic causes a breaking change relate to the improper use of the massless property and improper CFrame manipulation.

Massless assemblies

If every part of an assembly is marked as massless, there is a good chance the updated logic will cause behavior changes. Because an assembly must have mass, this property is ignored on the assembly root part. Under the old faulty logic, this root part was virtually guaranteed to be the part that had a mover constraint applied to it. With the new logic, the typical rules for root part selection apply.

To ensure the behavior of a mechanism doesn’t change, you should verify that the root part of the assembly does not change when using the new logic. If it does, you should be able to recover the existing behavior by disabling the massless property on the part to which the mover constraints are applied. You can also change the RootPriority to ensure the appropriate part is selected as the root.

In-script CFrame manipulation (very specific conditions)

During testing, we encountered rare situations where the new logic appears to break replication for some mechanisms. This breakage occurs when the CFrame of an anchored part is modified in a script. The anchored part is connected to another part through a constraint (such as Ball-in-socket or Plane constraint) and this part has a LinearVelocity constraint. Under these specific circumstances, the presence of the LinearVelocity constraint using the existing logic allows the CFrame for that part to replicate.

To restore the existing mechanism behavior, you could modify the setup a few different ways:

  1. Rather than using a script to manipulate the movement of an anchored block, you could unanchor it and use constraints to achieve the motion you desire. Scripts can be used to manipulate the properties of the constraints without breaking physics replication.
  2. Manually replicate the position changes for parts that are attached to the anchored block through mechanical constraints.

As always, please let us know if you have any questions or concerns!




This topic was automatically opened after 10 minutes.

Will these changes do anything to fix the breaking of physics replication under certain scenarios?


We need an option to force parts present on the server do the physics on each client individually not relaying on and not replicating to other clients. This would be extremely useful mixed with for example custom local tween modules.


Does the change fix all the listed bug reports or will they be fixed in the future?


So, can I test this already? With something else? Because, the fixes come right in time to test if something else that I found recently, is still broken or not.


Will we see any form of 240hz physics loop access? I ask because many physics based projects suffer extreme instability at low frame rates because how we don’t have access to any “loop” other than RunService events that are linked with the client’s framerate.
We really need a framerate-independent way to do physics stuff.

This would another be another huge change for physics stability


Is FFlagSimSolverEnableMoverConstraintRootBehaviorPhasedRollout what I need to set to true to have it all enabled?

oh wait it’s on Workspace, oh…


Can we get a heads up on the changes to the constraints mentioned ?
Im doing some stuff related to them so


Will we see any form of physics and replication control whatsoever? The lack thereof has been a huge bottleneck in game development for me and countless others.


So the consequence of the new logic is that Part B’s CFrame will not be replicated? (This is never stated clearly so I’m clarifying.)


This has finally fixed a long standing issue where adding a LinearVelocity to my vehicles would just freeze them! Thank you.


Why am I not seeing where to turn this on and off? Is it a beta feature?


It’s in Workspace as a Property


I looked in there, I didn’t see it.


Are you using something like third-party utilities to install a Roblox Studio? :thinking:

even though, I think it takes all the properties from the API and ReflectionMetadata


nope, stock install. can you show a screenshot of it


This is so awesome! I remember having huge latency issues with the newer constraints, which forced me to revert back to bodymovers. Hope its been fixed!



BodyMovers have had less issues and are easier to use in all the cases I have needed them. I very much dislike most of the constraints and liked the simpler surface and BodyMover systems since they worked every time

Until you update the default jeep to use constraints im not moving smh /j


nevermind, i just had to restart studio for some reason, it didn’t update but it made the property show up: