FYI, animation priority replicates from client to server (they introduced it a few months back), so you wonât need to reupload all your animations.
as it is pretty annoying a good work around i found for my game is giving each animation a different priority, not saying it will work for everyone but it stops it from weighing it down at least for me.
This update has ruined thousands of animations & is strongly disliked by developers
Please consider reverting it or making it an option
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!!
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.
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.
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
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.
Why not just keep a flag on workspace for this, then??
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.
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)
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.
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).
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.
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
haha workspace:SetAttribute(âRbxLegacyAnimationBlendingâ, true) go brrrrrr