For once I actually managed to prepare for an update, this is a first!
As a side note I’m seeing some funky behaviour when setting Motor6D.C0 or Motor6D.C1, sometimes it works and sometimes it appears to try and blend with currently playing animations (when it should still completely override them). This does not occur at all when Workspace.AnimationWeightedBlendFix is disabled.
(Probably) Related:
Should’ve kept AnimationWeightedBlendFix to default… Terrible update. Please reconsider before it’s not too late.
Our custom rigs in World // Zero for both players, and mobs (dragons, horses, mythical beasts, etc) all work fine with this change. Roblox isn’t removing support for anything, you just have to set up your animations for the new system.
If your animations look different, its because you are playing them on top of other animations. In the old system, there was a hack that would give the latest played animation 100% of the blended weight. You can’t rely on this hack anymore and need to stop other animations from playing that shouldn’t be playing.
I 100% support this change because I initially thought this is how animations worked (as they do on every other platform, including Blender) and it was weird to learn that you had a lack of control on Roblox due to the hacky play order.
+1 for more Enums though
It is disappointing how this feature is being forced on all games (from what I can tell), as this broke my game’s animations (it works, but they look really weird), and I’m not easily able to get a fix out until after the deadline.
While the issue is minor for me now, this will likely break animations in many older games, especially RPGs, and many of these developers aren’t working on them anymore or don’t have the time to fix them.
Please make sure that any new change will never be forced on older FE-compliant games! It’s disappointing to have to constantly pop back into old projects just to fix another feature which Roblox unintentionally broke.
Nope.
No, no, no. No thank you.
This update is awful for games with really snappy animations, such as mine.
Here’s an example. This is how it’s supposed to look:
Here’s the “”“fixed”"" version:
It looks gross. It might seem minor but it mars the complete aesthetic of the game. I put so much time and care into making sure it looks snappy and sharp, and now it looks smoothed out without any attention given to priority.
The great thing? All the animations stop. The animations don’t overlap, at least not for very long. And the priority enums are used. So what gives? There’s no rhyme or reason for any of this, and this leaves SO much room for unpredictability.
I genuinely don’t understand why this update is being forced. I understand the idea behind it – there was a bug that’s been here since the beginning and now it’s being ironed out. But that’s the thing: everyone developed their games thinking this is just how it was supposed to be. So why not create modifications that emulate the feeling of the old system? Otherwise, a bunch of other games are being left in the dust.
The really big question is this: Who is the majority that gains from this, and why can we not have our cake and eat it too?
We’re aware of the issue where setting Motor6D properties from script does not behave as it used to. This is not directly related to the blending or evaluation order changes, it appears to be an unintentional behavior change that just coincidentally happens to be in the new runtime evaluator code branch only. A few recent avatar and animation features, including retargeting and IK, were developed in the optimized runtime branch, so the AnimationWeightedBlendFix is now enabling more than just the original blending math corrections.
The looped property of animations does not replicate across the server/client boundary. This has been a problem for years. Can you PLEASE look at it?
I don’t understand why they’re “”“fixing”"" this “”“issue”"" yet they’re refusing to fix the inverted easing styles bug? If Roblox is gonna make our development a hellscape to deal with, could they at least be consistent so we can expect what gets/is getting fixed and what isn’t?
I understand how, from the developer side of the API, it seems like we’re merely fixing a bug that some games rely on. In truth, calling it a bug fix at this point is misleading in regard to the scope of the change. The “fix” became a choice to not re-implement the incorrect blending math when we rewrote the animation track evaluator from the ground up to scale for the future needs of the avatar system. We had to make the blending work as intended, and as it has always been described in the online documentation. Correct linear blending of tracks is essential for things like multi-way locomotion controllers, FACS facial animation, and runtime retargeting. Freedom from play-call-order dependencies was also important, as I noted previously (above), especially for improving replication performance.
The old runtime’s evaluator did the blending math with a combination of CFrames and Euler vectors. The new runtime does all its math–interpolation and blending–with quaternions, converting to CFrames only at the very end when applying to Motor6D.Transform. The old runtime evaluated tracks in low to high priority order, the new runtime reverses this to avoid evaluating anything that does not contribute to the final animation. The old runtime stored transforms in memory as CFrames, the new one uses least-3 quaternions encoded in a packed integer format, in order to support much larger animations. These are just a few of many very significant low-level differences.
The reason the old animation runtime cannot stay around is simple: it’s impractical for Roblox engineers to maintain redundant evaluators and to have to always consider both when features are added or changed. Branching core parts of a game engine to preserve backwards compatibility for a handful of games is a slippery slope that quickly leads to a bloated codebase that is a nightmare to work on and super confusing for new engineers to come up to speed on.
What I dont understand is the decision to NOT add int priorities. Now that animations dont play on top of each other it would be more useful than ever.
I can see some bit of potential with this (eg. flinching animations not completely interrupting idle animations) However, why is it that we’re not allowed to change animation priority by script/runtime? If we don’t feel like reuploading, we should at least be given the option to change them by code… Unless there’s already a way to? it’s pretty necessary to include something like this so we can at least swallow this mandatory update a bit better, especially when i have 10+ pages of animations to convert
So essentially what you’re saying is that you’ve optimized out a feature and aren’t adding it back because its inconvenient to maintain
(Not talking about blending but rather newly played animations of the same priority overriding old ones)
It’s all well and good saying you can’t maintain backwards compatibility, because you can’t forever and that’s reasonable, but developers can’t always go back and “fix” their old projects. I am aware this won’t happen but thought it is worth a mention, with other game engines you can usually play any old games, as they essentially “come with” the older version of the engine.
There’s no reason Roblox couldn’t popup with a popup saying “this game was developed using an older version of Roblox, in order to play it you must download it.”
(Okay there are lots of reasons why not, but we can dream okay)
There is a way.
AnimationTrack.Priority = Enum.Priority.Action
Pretty sure they made it replicate now too
I feel like someone at roblox or in contact with roblox devs really just didn’t feel like learning how to make animations not affect other body parts, so now we have this disaster on our hands.
Now all of my animations feel sluggish and don’t move to the keyframe positions where they are supposed to be, thanks a lot
it’s impractical for Roblox engineers to maintain redundant evaluators and to have to always consider both when features are added or changed.
It’s impractical for developers to deal with all the crap you put us through. And besides, a “handful of games” is a MAJOR understatement, since it literally means nearly all games created with animations before this update.
any idea when we will be able to overwrite animations by scripting the c0?
C0 and C1 property of Motor6D is affected by animations, which is unintended behavior.I believe that this is a bug that came with this new feature, and it has been causing issues. Any animation playing over the priority of Core will affect these properties of Motor6D:
C0C1TransformFrom my testing, this appears to happen with humanoids, but let me know if it happens on animation controllers too.
This issue needs to be fixed before the removal of Workspace.AnimationWeightedBlendFix as this is game breaking for many experiences that rely on scripted motor6ds and animations.
Found a bug report for it, best to support it for visibility:
Where do I put a request for a game to have this feature disabled?