Except you can use an integer for weight. What I did in my game is made a weight Enum for different types of animations. All my animations actual priority are Action, but the weights are according to the enum.
You can find many enum libraries by searching
That’s still going to require programming to fix what wasn’t broken. It again would just be easier for 99% of people to get integer priorities and reupload the animations…
More than 4 priorities is a must-have feature. It would also be nice to be able to assign different priorities to different bones in the same animation. For example while swinging a heavy sword, you’d want the character to move their feet a little bit, and ideally the legs would have a priority of “idle” while the upper torso has a priority of “action”, that way movement only overrides the legs, and while moving you can still swing the sword and the animation blends nicely.
Right now the only solution is to animate the legs and upper body separately, which is a huge pain. Or alternatively you just don’t animate the legs at all, which doesn’t look as good.
I’m… expected to use a pattern that requires me to either attempt to use the total of 4 animation priorities we get, which isn’t enough… or write a workaround for a workaround?
number-based animation priority should have been rolled out long before this fix was.
I am noticing buggy behavior with this turned on and its ability to detect the “End” keyframe in a non-looped animation. I’m sure you’re aware of the keyFrameReachedFunc function in the default player Animate script, this listens for a keyframe named “End”. With the AnimationWeightedBlendFix set to Default, my non-looped animation has the “End” keyframe detected properly. With it set to Enabled, I no longer get “End” keyframe detection and so the character freezes. If I go and change the animation from play-once to looped, it then starts detecting the keyframe, but now it’s also looping the anim. My workaround was to add a second keyframe named “End” right after the first one. This worked which suggests a one-off problem in the code, especially since I added a named keyframe in the middle of the anim and this one did fire through keyFrameReachFunc while it still missed the “End” keyframe. So, seems like something about the last frame in the anim.
I’m having an issue with the old animations being paused when they are overridden.
In my game, I play a looped “Ride” animation whenever a character enters a vehicle. This pauses all animations with a lower priority such as WalkAnim and RunAnim. Because I don’t use BodyMovers, I continually change the WalkSpeed between 0 and >0 to simulate movement. This causes more WalkAnim and RunAnim tracks to be added.
Since all the WalkAnim and RunAnim tracks are paused, they never end, which eventually leads to “AnimationTrack limit of 256 tracks for one animator exceed. No new tracks will be played.”
Is there any recommended solution for my use-case? Can you change the behaviour of this fix? Can the Animate script just not create new WalkAnim and RunAnim tracks when there paused ones loaded already?
Repro: _RideBug.rbxl (28.9 KB)
This issue is also happening to me!
Weird… What happens if you simply play the animation outside your game, in a place without any scripts other than the minimum ones necessary to start the animation? (with default fade time and weight)
It’s been a while since we got any update on this, and Phase 2 hasn’t happened yet either. Could we get some form of update about the status of this and any other details we might want to know?
There should be an option to make an animation not blend when asked to, because this is causing tons of issues with all of my animations… You mentioned a “50/50 blend” between the two animations, so how do we have control over this ratio in blending the animations?
This update is absolutely busted. It’s now impossible to get a smooth transition between animations without it flashing to no animation and then resuming the other animation.
I would totally love to go through hundreds of animations just to fix all these dumb issues as stated by many people previously. It’s ridiculous
So is this not happening? I would be glad if it didnt.
We didnt get any update in a while, no fix for the bounce, phase 2 didnt happen either, no new priorities
Is this update postponed or cancelled?
I imagine they’re waiting to push it until they can come up with a solution for us.
That, or they’re waiting until we can’t voice our frustrations to push it out of nowhere.
My guess though, is that they’re waiting for integer-based priorities before pushing, which would solve everything and mean both parties win.
Still wouldn’t fix the bug where the rig resets to the default pose before resuming the next animation.
Either an override feature or something like it, because I’ve found nothing but problems from this new evaluator, from the easing to the blending of same-priority animations.
Part of what made the overriding behavior so much better for me, and probably others as well, was how easy it was to just jump into Roblox and make stuff. You play the animation from a script, and you see it play exactly how you made it. It is intuitive, straight-forward, simple!
But now that we have this new evaluator coming out, it’ll probably get tougher for new arrivals to get accustomed to, given the fact that they have to take into account same-priority animations playing at the same time.
If I were to say something I don’t recall reading from this thread, it would be that the blending feels too additive in some cases, like the torso or limbs moving too much. Things just feel like we took a step forward, but two steps back, and then pause for a great while because we need to readjust our code/assets to comply with the new API.
It’s everything a Roblox update shouldn’t be for developers who are used to the old evaluator and how it handled things, especially since this is supposed to be enforced without option. Mind you, just about every developer who’s worked with animations up to this point are likely used to the old behavior, and will now have to spend precious time and energy to fixing something that broke because of a Roblox update.
I hate how familiar that sounded, “broke because of Roblox updates”.
I understand the underlying intentions with this proposed evaluator, but it misses more than it hits when compared with the current evaluator in regards to easing and excessive blending, especially since there’s no expressed plans for an override feature.
This update isn’t needed to begin with. If they wanted to improve it, they should just make an optimized version of what we have now.
What Roblox doesn’t seem to realize is that nobody was complaining about it before. They’re making changes nobody asked for, fixing what isn’t broken.
Yeah, they really need to get this sorted beforehand.
I had this enabled in the game I’m working on for about a month, and today I finally decided to turn it off. Almost every day since I’ve had it on, there has been a new animation blending bug discovered by my testers, which I have to waste my time fixing. Like others have said, no one has asked for this change and it’s not necessary. If anything, it should stay as an option and not be forced.
Apparently, there is a bouncing bug with the blend fix, those weird blending issues I’m having and maybe you too, could be because at the end of the animation there is an exaggerated “bounce” and that bounce is causing weird things to happen between each animation, It’s annoying and they haven’t fixed it yet. I also have the feature turned off until they fix it.
In other words… Their Fix is Broken.