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?
1 Like
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?
1 Like
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.
5 Likes
This is what I mean
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
10 Likes
A few people have reported this, someone even claimed they said it’d be fixed, but it still isn’t. It’s been 8 weeks, so much for that phase idea, huh?
4 Likes
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?
3 Likes
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.
3 Likes
Still wouldn’t fix the bug where the rig resets to the default pose before resuming the next animation.
3 Likes
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.
7 Likes
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.
3 Likes
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.
7 Likes
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.
2 Likes
Kind of disappointing that 4 months after the initial post, Phase 2 hasn’t even been hit yet. It makes me wonder if they’re having that hard of a time working on it, or if they’re waiting for something.
I’d appreciate if we got some form of update on it, considering that it’s still broken and it was supposed to be pushed at least a month or two ago.
I don’t blame you for disabling it, though. I’ve heard nothing but negativity about this change coming from other friends of mine who are developing projects. One of them has to make a bunch of changes to accommodate this that make the code significantly less efficient to work with.
3 Likes
I’m not sure if this is a new bug, unintended behavior, or maybe it always acted this way, but it relates specifically to LoadAnimation, and indirectly affects AnimationTrack:Play, and all the animation priority work here.
Issue: Animation priority is set at some undefined interval after LoadAnimation.
Testing:
After LoadAnimation, with no wait.
After LoadAnimation, with wait()
And finally, with wait(1) CORRECT!
My results were not consistent. Sometimes Wait(0.1) was not long enough. I have caught incorrect priorities after AnimationTrack: Play is called.
Especially since this value is stored in the animation AssetID, I would expect no errors when retrieving it. I can’t even wrap my head around what visual errors this would cause if an idle animation is actually “Active” for 6 frames or longer.
Anyway, I found this trying to take advantage of these runtime changes, and rebuild Animate script to be compatible with my skinned meshes. Right now, I would say the field is unreliable. Thanks!
My test code… pretty basic:
local function playAnimation (actor, animation)
local animationTrack = actor:LoadAnimation(animation)
-- animationTrack:Play()
print(animationTrack)
-- wait(.1)
print(animationTrack.Priority.Name)
return animationTrack
end
1 Like
Note: Only 4 months left and they haven’t given us any updates on this or fixed any of the annoying bugs. It’s almost like they just dropped it and didn’t choose to tell us.
6 Likes
AnimationWeightedBlendFix enabled seems to break the Animate script or something, I don’t have any issues inside Studio, but I do in-game. Just happened after this Wednesday’s update.
https://cdn.discordapp.com/attachments/876283641624416296/897980397609185320/zVa90mv01s.mp4
As @BullfrogBait mentioned, this seems to be happening on Studio too now.
4 Likes
I’m having a similar issue but it happens in Studio and live servers. It’s a bit hard to see but the animation seems really rigid, even though it wasn’t like this a few days ago.
For replication purposes, these are my Workspace properties and my currently enabled Beta Features:
4 Likes
I have been working with my animations to make sure they are in line with the changes, however I have run into an issue with the .Stopped event. When I have this fix enabled, it seems the .Stopped event for AnimationTrack is not fired. If I disable the fix (going back to the old animation handling), the .Stopped event begins firing again.
Is this expected behavior or a bug in this change? The animations are being played out of a LocalScript.
Thanks