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:
- Something is wrong with LinearVelocity and Tools, unexpectedly changing the NetworkOwnership
- A LinearVelocity Instance Causes the Massless Property to be Ignored
- Switching LinearVelocity.VelocityConstraintMode freezes replication
- LinearVelocity has an inherent replication delay when created on the server and viewed on the client
- LinearVelocity is absolute garbage (can’t make bug reports)
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:
LinearVelocityAlignPositionAlignOrientationAngularVelocity
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:
- 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.
- 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!
Best,
M0bsterLobster
