Seems like some animators were maybe confused by this post, so here’s my summary:
Before Roblox would pick which side of the animation as the parentPart and the childPart based upon the assembly root part. This causes issue when root part swaps around.
Now parentPart is always Part0 and childPart is always part1
Other hot take-aways from this post:
Update animations on stepped, use transform only
Motor6D be cheap
Questions I have:
Does Motor6D velocity/desired angle/current angle do anything?
Why would you use this over a traditional hinge constraint?
Yep… Not that I’d recommend using them. If the Motor6D is not animated by an Animator or the Transform property it will function exactly as they do on the ancient legacy Motor instance that they are inherited from.
You might use the if you wanted something to have some constant rotation, it was a purely visual effect, and you wanted no amount of force to be able to stop it. Parts connected by a Motor6D are a single rigid body. The movement has no physical velocity attached to it and doesn’t apply any torque. It’s an animated weld. I’d usually use a hinge constraint instead.
Same performance cost of an animated Motor6D in general.
Best update ever. I had been dealing with this odd behaviour for a long while which lead me to either abandoning the project or create ugly solutions for those Motor behaviour.
Definitely looking forward to see how this gonna go!!
As much as I’d want to like this update, you just broke a massive amount of vehicles uploaded to Roblox, also putting tens (if not hundreds) of games on halt so we can fix our cars.
So whenever I try to animate my own custom rig with the legacy Motor6D handler, It gets weird (and frustrating real quick). Hopefully this works. Thanks.
This change just inverted all my DesiredAngle inputs…
I understand why this change has to occur but it sucks that many older games who dont update will now potentially have inverted Motor6D behavior with regard to DesiredAngle.
Swapping Part0/Part1 is probably the easiest way to fix that. This change makes this care about which part is assigned to Part0/Part1 instead of the implied internal spanning tree. Alternatively you can replace Motor6D with Motor (which retains the old behavior) if you’re just using it for CurrentAngle.
Did not work in my case, where I have a part called “Base”, to which I have 2 more parts (one for each wheel) and the wheel as well (welded in that order). You can see this in NWSpacek’s (featured) vehicles.
The fix for all games that use a chassis, based on NWSpacek’s (aka. Rockport/TRC)
FE script, on the while loop:
local steer = -(seat.Steer)
if car:FindFirstChild("LeftMotor") then
car.LeftMotor.DesiredAngle = steer*math.rad(40-RemoteControlled.Velocity.magnitude/4)
end
if car:FindFirstChild("RightMotor") then
car.RightMotor.DesiredAngle = steer*math.rad(40-RemoteControlled.Velocity.magnitude/4)
end
Under that, you should have a LocalScript called “CarSteering”. In it, change the same bits of code (around the 15th line). Keep backups of your old scripts in case this doesn’t work. It did work for me - 04/23/2020
Note: I highly encourage you to find another chassis or a scripter to rework that one. It has many flaws and worst of all, has no suspension (very bad at terrain).
If you are using a legacy Motor joint, the behavior of those is unaffected by this change.
If you want the new, more consistent behavior, try swapping in a Motor6D instead of Motor. Motor6D inherits from Motor, so it should be a seamless replacement.
I’ve heard of similar reports dating as far back as the 14th, before this change was released. This change just conditionally adds a couple CFrame:Inverse’s internally in a method just just assigns a CFrame. Pretty sure it’s not related to this change.