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?
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.
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
I like “Assembly” a lot better than “Body”. Not only does Body not make sense but it also has a name conflict. Assembly is the go-to naming convention for an “assembly” of parts so it makes sense.
As mentioned above, old BodyMovers still have their uses because new constraints do not provide the necessary flexibility to accomplish what you could with the old ones.
Only realizing after reading this thread that ‘Body’ is meant to reference a collection of parts. Like many others have said, ‘Assembly’ would convey the meaning you’re going for much more clearly in my opinion.
BodyMovers still make up a larger percentage of the Roblox active game universe. They have been used longer than constraints, are far more flexible than constraints, and have been replicated in models through games at least tens of thousands of times.
Adding a part property named BodyAngularVelocity, is a horrible way to make the game universe better. It will if it already hasn’t, break part of the functionality dozens of games active even today.
I imploy you to change change the property name. This is a matter that’ll impact not only playtime, but the Developer community, DevExing. Roblox Corporation income, marketplace and more.
EDIT: I’ve been making edits due myself thinking this property was about BodyGyro. Apologies for the initial statement being way off.
Does anyone have an example of old (free model or otherwise) legacy content using BodyAngularVelocity? I tried a brief look and couldn’t even find anything that uses it. Almost all legacy content uses BodyGyro for physics based orientation manipulation, not BodyAngularVelocity.
I think that BodyAngularVelocity and BodyGyro are being confused a bit here. If BodyGyro were potentially broken in this way we would absolutely have a problem and need to roll things back, however, it’s not. BodyAngularVelocity much more rarely used object.
I have a model that uses it. I wanted to make particles “orbit” around a central core for visual effects, so I make long invisible parts centered on the origin with beams on the edges, and use BodyAngularVelocity to have them orbit around. I use BodyAngularVelocity as opposed to the constraint version as it allows me to do a per-axis speed to have more variety
Out of interest would Roblox be able to automatically rename and change all references to all existing BodyAngularVelocity objects to something else (a vague name such as ‘__BodyAngularVelocity’) before the update?
This would likely prevent most old games from breaking.
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:
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.
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.
