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.
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
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.
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.
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:
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.
I am still constantly paranoid about this update as so much of my work depends on the old animation blending behavior.
What happened to this update? Is it shelved, completely canceled, is it still coming? I’m paranoid about whether or not I should waste precious development time making code to get around this update, and I’m already on a bit of a tight schedule as is.
It’s already a lot that Roblox came in and suddenly announced that basically 90% of all animation behavior in games is just going to break due to a update, and that we have to fix it ourselves. But we also have no idea of what even happened to this update. We have no idea if we’re going to be able to change animation priorities in Lua and have it replicate properly (was confirmed earlier in the post), and we have absolutely no idea what the status of this update is.
Please just give us an update about what is happening, thank you.
Are these your own animations? This video has the characteristic look of multiple walk/run animations being blended out-of-phase with each other. Roblox’s catalog walk and run animations are designed so that the cycles have the same duration and phase (i.e. left and right footfalls occur on the same frame numbers). If you blend in a walk-cycle that has a different framecount, or different phase (e.g. character’s left leg steps forward first in one animation, but the right leg leads in the other), you’ll get this look. Humanoid:GetPlayingAnimationTracks() can be useful for debugging this situation: you can print out the playing tracks, their animation IDs, and their TimePositions, and see if you have more tracks active than expected, or if they are not in sync.
As I write this, this change is still in Phase 1 of a 3-phase rollout, but is about to go into Phase 2, which is the developer opt-out phase. You can pre-emptively opt-out by setting Workspace.AnimationWeightedBlendFix to “Disabled” if you’re certain your game is going to break due to the change in the handling of Enum.AnimationPriority. The other blending-related issues called out above, such as the jerky animations and joint popping/sliding during the fading in and out of different-priority-level animations, should all be fixed now, leaving only the non-backwards-compatible Priority blending change.
I haven’t been in studio for a few days so I’m not sure if this was silently fixed but to answer your question no, they’re the default Roblox animations. If it’s still like ‘broken’ I’ll try your suggestion and see what’s going on, thanks!
I hope you’ve got integer based priorities planned before Phase 3 rolls out. I really do not think it’s a good idea to be rolling out an irreversible change like Phase 3 without having at least some workaround that doesn’t involve ridiculous amounts of programming to circumvent this.
They could have actually fixed this just by keeping the programming for the blending the same, but they decided to fix an “issue” from the original animation player, or whatever it is, from what I remember.
If I may ask a simple question to those in charge of the update, who benefits from the blending behavior change? I have not seen anyone being able to find a good use for the new blending behavior, nor can I think of a single situation where it would be beneficial to a game or its animations. It certainly has not had a positive impact on any of mine, and it has definitely had a negative one.
One of my friends, @BoojieQ is actually working to restore the old behavior, to less-than-desirable results, but what he’s managed is still better than the new behavior’s default.
It’s been a while and we haven’t heard anything about the status of this update besides being told over a month ago that Phase 2 would be rolling out soon, which it still hasn’t. No word on integer-based priorities to counteract all of the negative change this will bring either, and that would at least alleviate some of the workload.
I stand by what Boojie said, I am paranoid about this update and I do not like having to limit my workflow to compensate for this update. It is a looming sense of dread and uncertainty that is incredibly demotivating.
As I see it, this update is not coming from a developer-first mentality. I see no actual benefit coming from the blending priority change, nor have I seen a single example where that kind of behavior would be more useful than the original. I think this update would be much more graciously accepted if the blending properties had just been left well enough alone.
Obviously. I just wish we could get some proper answers from them about why this behavioral change is necessary and some examples of how this new blending behavior will be useful in terms of actual visuals, because I see absolutely no use for it and nobody I’ve asked does either.
I also hate how little attention this thread is getting for how detrimental it will be for developers in the near future if they still go through with this update.
