This appears to have broken NPC walk animations in universes of mine with 50+ subplaces and hundreds of NPCs.
Any chance that toggleable workspace behavior could be added to the universe settings as a whole in the future? Entering 50+ individual places to switch it off and/or replace the default Roblox animation scripts is a bit tedious.
Also this fix appears to only be visible in a playtest mode with a client, meaning the behavior when running solely the server previews the animations just fine. Was weird to repro.
Let’s say you had an idle animation playing. You initiated a sword swing animation to play, of the same priority. You no longer see the idle, and the sword swing plays over it, and when it is finished, returns to the idle.
Now, you could set the idle to a lower priority to the sword animation, but that would get you the EXACT same result, so there was really no point in organizing priorites as it saved a little bit of time.
And about them not playing over the default character animations, when using the Moon animator plugin, exporting an animation automatically sets it to the highest priority, “Action”.
So, what I meant was that while priorities are needed, there was (usually) no need to manually set them.
This forced change would be easier to deal with if animation priority replicated. That way we could at least correct animations in game without having to reupload dozens of not hundreds of animations.
Man Roblox does the same thing with the mass + joint system too.
I don’t want a uniform hierarchy. I just want within my set of highest priority animations the ability for them to supersede each other. I do not care about their weight in the first place. Most animators don’t, not just because the code was bugged.
It’s not even a great hierarchical system, either. I’m being told to reproduce all my animations (NOT in real time since for some reason priorities cant replicate if changed live) to a list of 4 states where if I don’t want my animations randomly cancelled by a player movement then my list of usable priorities was… 1.
The blended weight sum is like, by technical wording a fix (and by note really the only actual fix presented), while it can work okay in my game the headwork is completely unnecessary, unprecedented and obnoxious. Lots of developers probably have independent code/modules that hook on to the animation system and now they’re told to casually make a queue system that real time updates the weights across all animations as they start and finish (or alternatively run :GetPlayingAnimationTracks() every frame, which is unwanted). Most do not wish to do that, alongside the large sum of finished codebases nobody can do that for.
We should only be beginning migration after the new feature set is introduced. I’m excited for what nuanced blending / parallelisation options are in future however the planned implementation misses the mark for how developers actually use the animation system.
If this is going to improve our client’s performance, then I’m for this change. However, it is a huge undertaking to try to reupload all our animations with a different priority.
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).
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.
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.
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.
@AllYourBlox There’s a pretty glaring bug related to this change and the default character animation script.
Considering the following:
A new AnimationTrack will now evenly blend between itself and an older AnimationTrack of 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 a Humanoid,
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.
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.
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.
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
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.
