This update has ruined thousands of animations & is strongly disliked by developers
Please consider reverting it or making it an option
5 Likes
Some bold opinion: I like the new blending… but theres a problem
Why would you have to make players unable to disable blending?
I feel like the blending is kinda cool, and good for roblox (maybe). But…
Why would you have to make the blending permenant?
Atleast make it a checkbox. I know you guys worked hard on this update (probably…), but atleast make it so you can turn it off!!
6 Likes
Which update was worse:
- The Advertising update
- AnimationWeightedBlendFix
- The audio update
0 voters
jokes aside, when I’m developing my non-viewmodel FPS game, I encounter issues with animations and I had to redo the walk animation to get it to work. This update appears to have several issues, but my biggest concern is Motor6D CFrame properties are overridden by animations, which is clearly a bug and is causing issues with arm movement.
4 Likes
hey, for anyone looking to fix their animations in their game, I fixed it by adding a boolean attribute to workspace named RbxLegacyAnimationBlending and setting it to true. 
22 Likes
I’m surprised Roblox wouldn’t make that a FastFlag.
One caveat about this: this attribute is only intended for use in legacy experiences that are no longer being actively developed and will not be updated to use any recent or upcoming animation engine features.
All new animation engine features (IK, retargeting, animation curves, strafing, face animation, animation throttling/LoD, animation parallelism, etc.) are being built atop the new animation runtime with the corrected blending math. Since this attribute affects all animators in a place, and comes with no guarantee of being futureproof w.r.t. any new features, it should not be enabled long-term in any new work or any game that’s still being actively developed and updated.
Wouldn’t this be bad for engine performance and slow down engineering time to have 2 different systems? Why not just fully switch over to the new version?
Because the old system doesn’t have the contortion issues that the new implementation has
2 Likes
It’s all still running under the new animation engine, even with this attribute set. All the attribute does is force the new animation runtime to use the old blending math–bug included–when blending same-priority animation tracks. But this blending math is not guaranteed to give the correct results for any new feature that blends animation tracks and expects the track weights to be correctly normalized. All other optimization benefits of the new animation runtime are still realized with the attribute set.
1 Like
Why not just keep a flag on workspace for this, then??
9 Likes
This change has made me extremely upset. What’s the thinking here? Yes, let’s break every game ever just for a “bug fix” (a trait of the animation system that literally every developer has gotten used to and expects), and some optimization. It’s not worth it, and it isn’t worth my time to go through every game I care about and individually fix every single animation. I could be doing plenty more productive things, but no. I am forced to fix something I shouldn’t even have to fix entirely because of Roblox fumbling with their own engine.
Even if you keep the new animation engine, do NOT remove the ability to change the blend behavior of overriding. I am so sick of Roblox changing fundamental aspects of their engine and dropping support for the old stuff, and every developer has to clean up after them. It’s amazing how consistently Roblox drops the ball with these inconsiderate updates.
13 Likes
Why not fix this issue and make all the newer animation features compatible with the property? The majority of roblox games with animations use the old animation blending. Why would you remove the AnimationWeightedBlendFix property from workspace to easily fix this issue for older games?
You should keep the old animation blending methods as it really does make working with combining animations a lot easier (eg. for tools and such that may have seperate idle and use animations)
2 Likes
The community has made it clear.
We desire the option to keep the old animation blending method if we so choose, return the optional property and allow developers to decide whether or not to use the old system.
You can keep legacy support disabled by default, just as long as it’s an option at all.
8 Likes
not just that, but it bends the player’s neck when they are using the default walking animation only if humanoid.RigType == Enum.HumanoidRigType.R15 then is used, you can commonly find them on @IamRoBuilder 's videos made after the update
I seem to be in the minority of people who actually prefer this update over the old runtime. I no longer have to mess with fading or anything of that nature for overlapping tracks to look good and fixing weird looking overlaps was pretty easy given that the animation priority property now replicates. I am however happy to see that the update can be disabled with a property if necessary and I hope that this is the norm for future engine updates (especially ones as impactful as this one).
1 Like
What are the people making these updates thinking? They role out terrible updates again and again and never listen. Who wanted this? What does this fix? Just keep it optional.
8 Likes
If it were going to be such that animation overlapping is to be done with priorities then making it an integer implementation was the most user-friendly approach, and they didn’t even do that.
Making it toggled by default made any game that has animations running on the same priority not display the animations the way the developers intended. So long as they don’t remove the functionality entirely, even if we have to do a weird attribute workaround, I’m fine w it, because old projects can function as expected after a single patch
1 Like
haha workspace:SetAttribute(“RbxLegacyAnimationBlending”, true) go brrrrrr
18 Likes
What exactly does this update do in the first place? It seems like they just removed animation priorities and made them into weights instead. This is a real issue since Motor6D.C0 is now treated like an animation.
1 Like
I would be completely fine with this update if it weren’t for the fact that there are only 3 more priority enums. This completely destroys many games that rely on the “priority stacking” functionality, which could have been remedied if there were simply an unlimited amount of priorities, or if another option was added to negate certain animations from being affected by animation blending.
3 Likes