I was also told that BodyMovers are legacy, not deprecated, mostly because of their wide use in games and how there’s no intention to remove them. Constraints are still pretty powerful and I’d prefer to use them, only if they can match up to their predecessors (they’re doing well, but aren’t completely there yet as far as I’ve heard).
Relevant (oops, just realised someone else linked my thread):
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:
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.
Hey!
Unrelated to the discussion of body movers, but using the ‘.’ index to get children isn’t being lazy to avoid using FindFirstChild - it’s a bit more serious than that.
If you use FindFirstChild, Intellisense doesn’t seem to figure out the methods/properties of the item you’ve just found, so you lose the ability to intellisense on the variable you’ve just declared.
That, obviously, is super annoying. Manually writing FindFirstChild six times in a row? Nooooo thankyou. I actually suggested giving us shorthand aliases for the big method names (but it was shot down, reasonably) since it gets fatiguing to write them out so often.
If we aren’t supposed to dot index children, well… I must have missed that memo, cause I actually reverted a bunch of old code from FFC to dot index because of the intellisense shenanigans. Oopsie.
–
My 2 cents on the naming issue - whatever you do, please don’t give it an “algebraic letter” name like “Omega” or something. I guarantee someone uses a different letter for angular velocity somewhere. Cryptic algebraic letter variables are the bane of my existence.
I know this is probably a given, but just to be safe… (ahem, old body movers having properties “P” and “D” - yes, I know, I know, deprecated)…
Don’t worry, that style of naming comes from the very early days of Roblox when it was intended as a physics simulator where the target audience would understand those terms. All new APIs added these days use more verbose understandable naming conventions.
Thank you, thank you, thank you for changing the name!!!
Latest release notes from Release Notes for 455 include details from @Maximum_ADHD, and I see that the naming has changed!
From BodyAngularVelocity, it is now going to be AssemblyAngularVelocity, from what I can tell.
I’m so glad that the old BodyAngularVelocity BodyMover will be safe from confliction with a property.
Thank you guys for reconsidering! 
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
