Maybe this has already been answered somewhere, but then, what’s the point of priorities? What is the intended way to override specific animations?
Edit: Ok I just realized I misread what AllYourBlox was saying, sorry for that!
Priorities are meant for overriding specific parts of a rig’s animation, not completely replacing an animation that’s playing, i.e. a weapon idle animation can have a higher priority than the default walk animation, where the leg animation from the walk still applies but not the arm and head animations. The wrong equivalent would be having a custom walk animation with a high priority to override the default walk animation, instead of just not having the default play or changing the default animation ID.
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.
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 Motor6DCFrame 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.
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?
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.
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)
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
