We actually used BodyAngularVelocity to help rotate the Pirate Ship.
3 Likes
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.
22 Likes
Why is this new property named BodyAngularVelocity instead of AngularVelocity? The former seems more confusing / less concise in its naming.
16 Likes
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.
18 Likes
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.
2 Likes
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.
33 Likes
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.
3 Likes
yeah that’s a good idea. BodyRotationalVelocity, xd
2 Likes
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.
51 Likes
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.
36 Likes
For what it’s worth, I would prefer the term Assembly be used in the future over Body. While it’s not an industry standard term, I think it makes more sense intuitively than Body.
Assembly to me calls to mind something like a Lego build, whereas Body makes me imagine a solid (a “rigid body”).
25 Likes
“Body” Makes more sense more than “Assembly”
1 Like
Oh well that’s a rip for a lot of vehicle games.
5 Likes
I have a strong grudge against a lot of the contraints given how restrictive they are over the old joints classes such as Weld, Hinge and Rotate.
Naming a property BodyAngularVelocity will destroy backwards compatibility and I suggest you rename this property to a new name.
It’s not.
11 Likes
Pretty sure I was told that the old BodyMovers are not depreciated as they still provide additional functionality - most notably maxTorque is a vector in BodyAngularVelocity, but a scalar in AngularVelocity constraints, same with maxForce in BodyPosition. If BodyMovers are being depreciated, can we have this functionality added to the constraints system?
10 Likes
Will be useful in physical model things in, yap’ hoping won’t be failed for sure.
1 Like
I disagree on this point and feel like Assembly is more descriptive than Body, as mentioned in previous replies.
After asking a few non-Roblox people, the word assembly seems more like a collection of singular things to them than Body does. Body, to them, seems like another singular thing, and not a collection. My sample size was low at 4 people, but seeing as most dictionaries also agree…
The terminology not being common on the platform, or not documented enough on the platform, does not seem like good enough reason to avoid it either. As a counterpoint: Will this post & the potential name collisions caused by this change be documented and easily available for years to come? Will new developers who might stumble upon legacy BodyMover objects know about it?
20 Likes
I have to agree that Assembly makes more sense for its purpose than Body does, especially considering the word Body has never been used for developer-facing API outside of BodyMover classes. If that name were to be used instead, I’d consider that a better outcome than this, especially when I think about all the old, unmaintained games that’ll end up breaking due to this change.
4 Likes
I think Assembly makes more sense than Body. It’s easier to understand, and it keeps backwards compatibility with games that use BasePart.BodyAngularVelocity. Using Assembly instead of body sounds like a win-win to me 
Also I’m glad to hear about new constraints and physics improvements, playing with physics is always fun
2 Likes
Just Rename it. (filler words here)
3 Likes