I think a large part of the problem everyone is having is the fact that the very process of changing an animation’s priority takes too long in the first place. It’s tedious as there’s really no good way to search your published animations from within Studio (such as by name), nor is there a way to organize them (a recurring theme with Studio).
3 Likes
this legitimately breaks my melee kit.
6 Likes
Any solution for this bug?
Only happening with this change
I was experimenting with the new Animation Engine update yesterday and I have found something very interesting that I felt must be reported on…
I have a little script that keeps track of all the playing animations for your own Character. As you can see in the video below everything works just fine with no tool equipped, but playing an animation from your tool is a different story…
If you equip your tool and use the animations the printing goes insane with repeating names that aren’t recognizable to your own tools animations…
It will just keep printing the exact same 2-3 animations to the point an error shows up saying the AnimationTrack has hit the limit. Once this occurs you can barely use your animations from the tool anymore.
If you trace the name of these animations being repeated you will find them inside of your Character within the default Roblox Animate local script.
If you Disable AnimationWeightedBlendFix this problem no longer occurs and it prints normal. I imagine this is due to some bugs occurring from a miscorrelation in the relationship between the Animate script and the new Animation Engine Update?
Anyways I felt like this was important to bring up. I’ll keep everybody updated if I find anything else interesting about the new Animation Engine update. Thanks for reading.
8 Likes
Don’t forget we can’t bulk-upload them either, or just do “update asset” based on the animation ID, or something like that. We have to manually scroll through an arduous menu and find it buried amongst hundreds of others.
2 Likes
Please revert this update till you guys have found a better solution to implement this new system. Several of my games now have broken animation issues.
3 Likes
You can disable it by changing the AnimationWeightedBlendFix property in Workspace to Disabled.
1 Like
Soon that option is going to be removed, and it will be forced to always be enabled.
1 Like
@AllYourBlox There’s a pretty glaring bug related to this change and the default character animation script.
Considering the following:
-
A new
AnimationTrackwill now evenly blend between itself and an olderAnimationTrackof the same priority and weight instead of overriding it completely, -
The default character animation script is a child of the character and not a child of
PlayerScripts, -
The default animation script never cleans up (or reuses) old
AnimationTracks previously loaded onto aHumanoid,
Anything that halts and restarts execution of the script will break the character’s animations permanently until a respawn, such as the common practice of moving the character into ReplicatedStorage then back into Workspace for gameplay-related reasons.
Video demonstration:
This is a big problem for us on our game Crown Academy, where we parent player characters to ReplicatedStorage when they interact with an NPC, then back into Workspace when they’re done. I’ve also noticed this occurring on production in games like Jailbreak when using the jetpack (perhaps @asimo3089 can speak more on that).
This honestly should have been foreseen and it’s crazy that it wasn’t. Honestly, the default character animation script could use a bit of a rewrite much like what was done for the default character sound script. Turn it into a player script instead of a character script.
6 Likes
True, but hopefully they allow AnimationPriority to replicate before then.
Yes, this is expected. Same-priority tracks are supposed to blend, this is the bug being fixed. Overriding should be done using AnimationPriority. Relying on AnimationTrack:Play() call order to override wasn’t an intended feature, and it never worked reliably due to being sensitive to replication order. It’s just that when it did fail, it was difficult to spot because the bug would present only as different clients seeing a different animation take precedence. Because for a player’s character it always looked as-intended on their client, and would only ever be wrong on the server or other players’ clients, developers simply were not aware of when this trick was failing. Upcoming changes to how animation events replicate, along with animation evaluator parallelism, throttling and LoD, all prevent us from maintaining this call-order-based behavior.
I agree this is the real source of the blending problem you are seeing. We should not be letting old instances of the Animate script leave orphaned AnimationTracks playing on the character’s Animator. This is what really needs to be fixed in this case.
One good thing that has come out of the blending change breaking games is that it exposes cases like this where animation tracks are orphaned. While those orphaned tracks were previously being suppressed by the most-recently-played tracks, they were still accumulating on the Humanoid every time you did this reparenting trick. Some players might have hundreds of animation tracks running on their Humanoids, which the old animation runtime still evaluates. This results in serious performance decreases over time, and in some cases event markers firing multiple times and causing other hard-to-find bugs.
FWIW, this failure to clean things up can also cause characters to get stuck animating with no way to stop them. This could happen even before the blending fix. Like if you’re emoting or using a tool when your character happens to get stashed, you might be stuck doing that animation until reset.
While this should definitely be fixed, it’s more of a bad assumption from many years ago than a new bug. The Animate script is very old and was written with the assumption that characters spawn into the Workspace and when they are removed from the Workspace, the removal is permanent (reset, disconnect, hitting kill plane, etc.) The idea of client-side stashing of a character somewhere outside the Workspace to save its state just wasn’t designed for.
Also, parenting things to ReplicatedStorage also falls into the category of implementation-defined behavior, and this is not a best practice. ReplicatedStorage has only one supported use, which is to replicate instances from Server to all Clients. LocalScripts adding children isn’t generally a problem, but that’s not to say it won’t ever be; this could be explicitly disallowed in the future if some reason to do so arises. For performance reasons, keeping the character in the Workspace is the best option, as this avoid rebuilding of the rig and other overhead. LocalTransparency can hide characters, as can locally moving them anywhere the camera can’t see them. If you really need them to leave the Workspace, you can parent them to nil also: Player.Character is a strong reference that will prevent them getting garbage collected locally.
6 Likes
I’m going to push for us to fix this, which means that a lot of places that have animation problems right now like walk and running looking funny (from stacking, orphaned tracks) will not require developer changes to fix for Phase 3. Developers should only need to make changes if they were intentionally trying to get same-priority animation tracks to override each other, not if it’s due to this unintended accumulation from our Animate script.
8 Likes
will we be able to test the fix before phase 3? i’m concerned that it’ll just push in phase 3 without a chance to see if that bug is the source of our troubles on this matter
2 Likes
Still waiting on a way to use easing styles with :AdjustSpeed() and :AdjustWeight(), which would definitely be useful for animation fidelity. Other than that a pretty good adjustment to animation weight, even if it shouldn’t be forced as prominently yet.
2 Likes
If you’re going to continue pushing on for Phase 3 (which in my opinion, should keep the toggle to preserve older games from breaking, as several do have inactive developers and may not know about this change), could it at least be possible to make it more convenient and faster to change animation priorities, rather than having to open every single animation up in the editor and change the setting or opening up every script and adding a line to change the priority from there?
Like, maybe a property to edit an animation object’s priority in the explorer (if I have all my animations as objects, stored in a folder) or mass selecting animations that you have created to change priorities in less clicks?
5 Likes
It would be great if we could just have a “reupload asset” button of some sort alongside this. It’s kind of ridiculous that we have to manually seed through every single animation. I also always keep backups of my animations, so I have to basically do twice as much work.
2 Likes
Also, really wishing that old animations could be fully deleted.
2 Likes
Yes. Phase 3 won’t be enabled until well after of these other bugs (unrelated to the blending math fix) are addressed.
4 Likes
Make AnimationTrack.Priority work from the server.
3 Likes
Can you guys change Core, Idle, Movement, and Action into the new priorities automatically (Action, Action2, Action3, and Action4)? It would make this troublesome problem for most developers vanish into thin air.
1 Like