NOW LIVE
This change was enabled on January 30th at 4:40 PM PST. It should take effect within 10 minutes on servers and upon restart for clients and studio.
We made some changes to the behavior of the BasePart.Velocity and BasePart.RotVelocity setter. If your game assigns to these properties you should read this.
The value returned by the Velocity and RotVelocity getters is unchanged. Only the behavior of assigning to these properties was changed.
What Changed?
Previously, if you ever tried to assign to to Part.Velocity in a less than trivial mechanism you probably had a bad time. The old behavior was to find the part that was the “mechanism root” and assign the Velocity to that part’s rigid body. That part may be on a completely separate rigid body from the one you are assigning it on… it might even be the Baseplate.
We changed this to instead assign the velocity the part’s Assembly, such that the part you assigned to ends up with the given Velocity, as intended. If an Assembly is not grounded it will have a single rigid body in the physics engine. Velocity will now always assign to the rigid body of the part that you’re actually assigning to. Unlike before where it would sometimes do… something else.
This is very similar to the change we made to the CFrame setter before. I’ll link to my original video for the CFrame change to illustrate the difference. Imagine the same thing for Velocity instead of position.
How Does This Affect My Games?
Before you were not able to set the velocity of a rigid body that was not the mechanism root. Now you should finally be able to set the velocity on any rigid body.
Previously if you tied a character to a boat with a RopeConstraint and tried to set the velocity of the character it would probably set the velocity of the boat instead. Now it will actually set the velocity of the character.
Unaffected
If you only ever set the Velocity on the largest or “most rooty” rigid body in a mechanism you should be unaffected.
Affected
If you were somehow relying on the setter assigning to another part instead, this will affect you, e.g. if you set wheel.Velocity = blah on the wheel of a car and expect this to change the Velocity of the car body it won’t anymore. This would have previously set the velocity on the the larger body of the car that the wheel is connected to with constraints instead. Now it would only assign that velocity to the wheel.
If you are concerned this change might negatively affect your game, let us know.
Sidenote About Velocity
Note that the Velocity property getter compensates for rotational velocity and the offset of the part from the body’s center of mass, returning the linear velocity of the part itself, and not its rigid body.
In contrast, the setter assigns linear velocity directly to the rigid body at its center of mass. Because of this part.Velocity = part.Velocity is not a no-op if the part is rotating because the getter and setter work with the values of two different things.
We plan to add new APIs in the future to address this. Probably a BodyVelocity property where the getter and setter both talk about the same thing.
Appendix
Definitions that might help.
A “rigid body” is a single moving body in the physics engine. A point mass that has position, velocity, and inertia. This follows the traditional definition for any physics engine.
An Assembly corresponds directly to a single rigid body but might not be simulated. An assembly has a root position and collision shapes. Internally an assembly has one rigid body or none at all. An assembly is a rigid body if it has no anchored parts and it is in Workspace, otherwise it is not and is fixed in place. The parts in an assembly always move together. Rigid joints like Welds and kinematic joints like Motor6Ds link multiple parts into an Assembly.
A Mechanism is one or more assemblies linked by constraints. It has a root computed by the same rules as assembly roots. The way we break down mechanisms is totally bonkers broken in some cases and you should never have to think about them. We’re trying to hide it as a concept that ever leaks into the API and replace it with a better constraint graph islandization system in the places where it’s used. Network ownership units roughly correspond to mechanisms, except network ownership excludes anchored parts while a mechanism can have an anchored root. There are some Studio settings that will let you visualize Mechanisms, but the concept is not generally useful.
