A LinearVelocity Instance Causes the Massless Property to be Ignored

When you apply a LinearVelocity instance to a Part’s attachment, if this Part’s massless property is set to false, it will behave as if it has mass. Even if it’s not the root part of an assembly.

Below is a rbxl file that can replicate this issue:
Place1.rbxl (58.4 KB)

Instructions:

  1. Draw your attention to two identical sets of assemblies connect by a spring constraint. Pay additional attention to two parts with the brick material. Each are completely the same. Both have their massless property set to true. The only difference is that the right part has an attachment which has a LinearVelocity being applied to it. Please note that the LinearVelocity’s MaxForce property is 0. Therefore, both assemblies should have the same mass. However, this is not the case and can be seen by reading the mass property of each part.
  2. To confirm the different behavior, play the level by going to Home → Test → Run and observe that the right assembly displays more weight than the left.

Visual aid:
image

Expected behavior

I expect a non-root part to always have no mass when the massless property is set to true. Regardless if a LinearVelocity instance is applied to it. Besides, there is a deprecated class called “BodyVelocity”, superseded by the LinearVelocity class, which respects the massless property. This leads me to believe this is a bug.

5 Likes

Thanks for the report! Just to confirm, we have a ticket filed and we’ll follow up when we have an update for you.

3 Likes

This is indeed a bug and we have a fix for it. Unfortunately, many mechanisms rely on this bug in order to function as the creator intended so the roll out of it has been slow. We will be trying again soon once we address one of the issues found during the last attempt. Sorry for the inconvenience. In the meantime, I believe you can avoid most of these issues by moving the LinearVelocity constraint to the Root part of your assembly. As you found, the part with the linear velocity constraint is going to end up as the root part due to this bug so, if possible, you should move it to whatever part the root should be.

4 Likes

There is a fix available for this issue in the form of a new workspace property that is part of a three phase rollout. More details can be found here:

Let me know if Enabling the new property fixes the issue for you. Thanks.

3 Likes