! Important Notice on BodyAngularVelocity

[kleptonaut]

Next week, we have a big physics update to the Part API, adding new properties and functions.

This new API will appear in next week’s release (10/14), but will not be usable until later when all clients have the update. (stay tuned for an announcement post in the next month or so!)

One of the new properties is BodyAngularVelocity.

At next week’s release, this property may cause disruptions to your game if you have a BodyAngularVelocity instance that you are accessing via index in scripts. For example:
workspace.Part.BodyAngularVelocity

Please note the BodyAngularVelocity instance is a deprecated object, replaced by the AngularVelocity Constraint.

The solutions are as follows:

1. Rename your BodyAngularVelocity instance to something else.
2. Access your BodyAngularVelocity instance via FindFirstChild or similar function
3. Replace your BodyAngularVelocity with an AngularVelocity Constraint.

After considering your feedback we have decided to delay this change for now. You do not need to edit your games, and we are going to think about alternative names.

Otherwise, I’d like to clear up some confusion on BodyMovers vs Constraints:
Not all the BodyMovers are deprecated, nor do they all have total backwards compatibility with a Constraint counter-part. The only missing behaviors I’m aware of are:

• BodyVelocity → There is no LinearVelocity Constraint.
• BodyPosition → There is no way to limit to specific axes in the Constraint alternative, AlignPosition.

Otherwise, the AngularVelocity Constraint should have total backwards compatibility with the BodyAngularVelocity mover, plus more features. (The BodyAngularVelocity Mover does use a vector for MaxTorque rather than a scalar, though I’m not clear on what advantage that provides. It won’t actually let you prevent spinning on a particular axis.) There is also the AlignOrientation Constraint, and Torque Constraint for other rotational behavior. I mentioned that it was deprecated, since there is a compatible replacement, but this wasn’t reflected in the documentation, so we will try to get that all updated.

I’ve marked @ContextLost’s reply as the solution to elevated it up here to provide more context:

[iWinterNation (mrbuns)]

Nice! You know what is funny? We actually just finished the physics of a pirate ship for my upcoming game and now we gotta redo it lol

[AREDEUS (ARES)]

when you just finished parsing the API dump for your plugin so now you have to parse again, but I hope the tests go well

[Avallachi]

[color=#D95D5D]Deprecated[/color] doesn’t mean unusable.

[ReturnedTrue (Raiden)]

Will this mean that existing games with BodyAngularVelocity, which have an unchanged name, will break after this update? Multiple games still use BodyMovers despite their deprecation.

[CaptinLetus]

I’m surprised you guys decided to name the new property the exact same thing as an object that has been used in loads of games over the years.

Personally, I think to support backwards compatibility (especially in old games or games that aren’t updated anymore), the new property should be renamed.

[DevSpec (iJava)]

Any reason why the property wasn’t just named something else, considering that naming the property after an instance which will almost certainly be parented to a BasePart in every use case will break tons of legacy games?

[IdyllicDestroyer]

I would personally highly recommend changing the name of the new property, rather than making god knows how many devs go change their code. I’d understand if it was some hidden or never-used object, but BodyAngularVelocity instances just don’t fit that description.

[buildthomas]

I don’t feel like less than a week (and right before the weekend) is enough heads-up for this change since the odds of naming collision are fairly high, since the property is named after something that is also a valid class name.

EDIT: Looks like it’ll be another month until the change goes into effect. Apologies for the misread.

[St_vnC (yxngStvn)]

Lol rip, idk bout u, but id use AlignOrientation to move a pirate ship. Might be inefficient if so, then I’ll switch to something else.

[iWinterNation (mrbuns)]

We actually used BodyAngularVelocity to help rotate the Pirate Ship.

[Maximum_ADHD]

For anyone interested, here are the properties being added in this upcoming update:

Added Property float BasePart.BodyMass [ReadOnly]
Added Property Vector3 BasePart.BodyAngularVelocity [<📁> LoadOnly]
Added Property Vector3 BasePart.BodyCenterOfMass [ReadOnly]
Added Property Vector3 BasePart.BodyLinearVelocity [<📁> LoadOnly]
Added Property Vector3 BasePart.LinearVelocity [ReadOnly]

Added Function void BasePart:ApplyImpulse(Vector3 impulse)
Added Function void BasePart:ApplyAngularImpulse(Vector3 impulse)
Added Function void BasePart:ApplyImpulseAtPosition(Vector3 impulse, Vector3 position)

When I noticed these changes appeared in Roblox’s CI branch, I alerted @ContextLost to the potential name collision, and hence… this topic was born. Looks like they’re pushing forward anyway, which is fine so long as people are aware of the edge case.

This isn’t the first time I’ve seen this problem occur and it probably won’t be the last either. Perhaps a better long-term solution is needed for these edge cases.

[Noble_Draconian]

Why is this new property named BodyAngularVelocity instead of AngularVelocity? The former seems more confusing / less concise in its naming.

[PeZsmistic]

Don’t BaseParts already have RotVelocity, Mass, CenterOfMass, and Velocity?

What is the difference between these BodyAngularVelocity, BodyMass, BodyCenterOfMass, and BodyLinearVelocity properties and the properties that already exist?

I don’t think breaking old games is worth creating new aliases if there is no difference.

[TheNexusAvenger (Nexus)]

From the name, my guess is this refers to a physics body of multiple parts instead of a single part, such as a part being welded to other parts. I couldn’t see this done through another method (like being a property of a Model) because a model could contain multiple physics bodies, or a physics body may not be fully contained in a single model.

[Polyhex]

You deprecated the BodyAngularVelocity instance before giving the AngularVelocity constraint one of its most key features? That’s a pretty big issue to me. It cannot be a replacement unless it can do everything the old object can.

[LouieK22]

Why this property name specifically? If it’s going to break existing games, why not just choose a similar name? I’m not seeing the point of this.

[St_vnC (yxngStvn)]

yeah that’s a good idea. BodyRotationalVelocity, xd

[ContextLost]

Why We’re Adding These Properties…

As some of you have guessed these new Body- properties pertain to the properties of the welded rigid body at it’s center of mass. So they apply to an entire collection of parts that all return the same GetRootPart().

The existing part properties pertain to the velocity of a single part at THAT part’s geometric center. If that’s not the same as the rigid body center (it’s usually not for asymmetric MeshParts or multiple parts) there’s a really complex relationship between angular and linear velocity. The rotation of the body adds additional linear velocity at any point outside of the center of the rigid body. The current part Velocity property getter accounts for this. The setter does not, and also redirects your assignment to the root part without any compensating for a different center. part.Velocity = part.Velocity isn’t a noop! This is straight up broken.

If you just want to simply do a one-time velocity assignment for a collection of parts reliably without constraints or BodyMovers, it’s extremely difficult to do. Basically impossible in some cases. This could and should be simple, but it’s not.

This is terrible. This must be fixed.

I believe what people want more often is to affect the velocity of the whole body, not a single part. So we’re adding these properties. The getters and setters are actually symmetric too! part.BodyLinearVelocity = part.BodyLinearVelocity doesn’t change anything! Amazing!

About That Name…

Some of the alternatives:

• BodyRotationalVelocity - Less correct, informal, longer, inconsistent with newer Constraint class names and properties. Google “angular velocity” vs “rotational velocity”…
• RigidBodyLinearVelocity / RigidBodyAngularVelocity - no abbreviation, holy heck that’s long. Especially when we want people to be using this more often than the per-part versions… I am the villain responsible for GetNonChatStringForBroadcastAsync, but still…
• AssemblyLinearVelocity / AssemblyAngularVelocity - You won’t know what Assembly means unless you’ve talked to me a bunch and are in on the dark, secret internal lore. It’s a very Roblox specific term… I finally got the documentation team to use the word in an article, but it took years of convincing.

Ugh.

I wrote the original proposal for the property. Honestly, I picked the name forgetting about the same-named BodyMover, probably for the same reasons the BodyMover was bestowed this name: It’s a good balance of verbosity.

So we know this is a potential conflict.

Not great. What’s worse is all the alternative names. They’re not nearly as good, by a long margin.

2 years from now, when BodyMovers are a distant memory, should we have picked a more awkward name on their behalf?

This is always a risk when we add nicely named properties. There’s super easy workarounds. Like FindFirstChild("BodyAngularVelocity"), but still. We know people directly index children sometimes anyway, including me when I’m lazy.

So we know there’s some risk, but our current plan is to roll forward and monitor closely. I think we have a good reason to add this property with this name.

If you know of old games that actually use x.BodyAngularVelocity that can’t be updated, let us know.

About BodyMovers and Alternatives…

We’re painfully aware that current set of constraints doesn’t have great alternatives to all the BodyMover functionality. It’s sad.

We’re going to try to focus on fixing that next year. LinearVelocity constraint, a bunch of single, and two axis options where relevant, etc. I can’t promise anything yet, but it’s very high priority on our tentative roadmap for next year.

These alternatives should be more powerful too. BodyMovers are limited to restricting forces on global axes. What about along an arbitrary axis, or on an arbitrary plane? We can do better.

Unfortunately we didn’t get much time to work on that this year, because we were asked to dedicate our entire team’s focus to performance. Good news there is we kicked ###. We made physics several times faster already this year, and it’s getting even better by the end of the year. If we weren’t busy with that we would have fixed some of these already.

[PeZsmistic]

Really appreciate the in-depth response, this clears up a lot.

That said though, I personally find “Assembly” to be way more descriptive than “Body”. I knew what assembly meant right away, while body is much more ambiguous. This shouldn’t be deep internal lore, people should learn what assemblies are in Roblox, Body doesn’t make any sense in comparison to Assembly with respect to what they’re supposed to mean here.

Constraints have already ditched the “Body” terminology, and BodyMovers are deprecated. I think it would be more beneficial to commit to using Assembly, and purge Body from the API.