Ok, today is Monday. I don’t see the update in production. Works fine in Studio with the beta checkmark. When does it hit production?
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 thechildPart
based upon the assembly root part. This causes issue when root part swaps around. - Now
parentPart
is alwaysPart0
andchildPart
is alwayspart1
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?
- Are these properties performance friendly?
Thanks for the summary.
Answers I have:
- 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.
It’s in the release queue, but the queue is long today. Might be later today or more likely earlier tomorrow at this rate.
Took an extra day but it’s enabled now, as of 4:14 PM, April 21st PST.
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!!
I can’t seem to see this option in my Beta list in Studio.
The update is live now.
(30 ch)
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.
Interesting… Not on my screen.
This is so epic. Mind blown.
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.
“If you think this change might affect you, you can enable it now in Studio Beta Features:”
A warning was set out a week ago to tell users to enable the beta in studio to test it and prepare their games for the fixed release.
I think that this could be a useful change!
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.
Is this change maybe causing this bug? A few games that set the Transform are now seeing this
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.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.