New Animation Runtime Rollout - Upcoming Property Removal


We are nearing the completion of the multi-phased rollout of our new, optimized animation runtime. The new animation runtime gives us huge performance benefits, especially on mobile devices that majority of Roblox players are using.

For full details, please reference the original announcement here.

On November 1, 2022 we will conclude the rollout by:

  • Removing the Workspace.AnimationWeightedBlendFix property
  • Permanently enabling the new runtime and the blending fix for all places

If you have a place file that currently requires Workspace.AnimationWeightedBlendFix to be Disabled to function correctly, you will need to address it before the November 1, 2022 deadline. We have a list of recommended solutions to make your code complaint at the bottom of our previous announcement.

During the first two phases of this rollout, we made a couple of changes to the animation system to make this easier and to reduce the need to republish animations:

  • AnimationTrack.Priority now replicates between client and server
  • Enum.AnimationPriority has 3 additional priority values available for developers to use for overriding animations, rather than relying on the old runtime’s implicit stacking behavior

We are also monitoring the thread to troubleshoot the transition with you and answer any questions you may have. Please reply here or to me directly with your concerns and a link to your experience so we can work with you on a solution ahead of November 1st.


This topic was automatically opened after 10 minutes.

And if we dont? Im curious to know the answer, unless its already there


The option will disappear and will act as if it’s always enabled. The old system will no longer be present.

(Well, it will be present while the fast flag exists, but it will eventually be completely removed.)


Bad news here. A person with bad news.

I have a game that requires Workspace:AnimationWeightedBlendFix and if i turn it off, players can spam my attacks and my animations will look super stupid.


If we feel like Abandoning it do we have to still address it?


We use a forked animation script with several modifications for a custom R6 emote wheel. Was the animate script changed? Will it break in the future?

Also we have a tool that allows users to sit and it feels like the player ragdolls and falls over a lot more now as opposed to when the property is set to disabled. Is this something that needs to be addressed as well or is it just me overanalyzing things?

For reference, disabled:



Is this supposed to be “compliant?”

1 Like

Extremely Disappointed. After an incredible amount of backlash and feedback from the developer community, I thought Roblox’s announcement about pausing the process and reconsidering the removal of weight blended fix would result in a better long term solution to support both systems.


What kind of sadistic joke is this? My game’s running animation looks like a constipated man when this so-called weighted blend “”"""""""""""""""""""""""""""“fix”""""""""""""""""""""""""""""" is enabled, and a massive amount of games could break from this too. Don’t blame ME for not being a scripter and not wanting to burn out a scripter just to do extra work to fix the previously perfectly functional animation-related scripts in my game. I also don’t want to see games that lack updates be broken by this either.

This is on the same level as the initial idea of forcing the 2022 materials and I hope Roblox reconsiders this. Facial animation also kinda breaks with this enabled, as playing animations with facial animation in them then stopping to play them still keeps the facial pose baked.


Oh boy, get ready for people complaining about this.

I mean, Roblox gave every developer over 1 year to find a way to implement this change into their game. If you didn’t act and decided to stick to the old behavior knowing really well that it was going to change at anytime, it’s your fault.


Is there any reason why we cant just have an optional argument when playing an animation that makes it override the currently played animations with the same priority? The backlash isn’t about the blending, it’s about the stacking. Let us at least keep the stacking by making it an optional feature.


Sad to see there’s no plans for extending the functionality of AnimationPriority. The given enum names are very use-case specific and go against the norm for how other priority enumerations like RenderPriority behave. (I mean common, why’s ‘Core’ all the way at 1000 while the rest go from 0-5? Too late to change it now, I guess.)

Perhaps adding some API parity with AnimationTrack.Priority like OrderPriority that accepts a number instead of an enumeration? Right now, 8 (badly named) enums are barely cutting it and it’s only going to get worse going forward.


Why do you gotta remove the setting? It’s not our fault we thought the old behavior was intentional and so it was used in literally all our code.


Yes, we looked at a few possible ways to do this, and they all had the same problem, they result in animation tracks having a de facto priority level that is entirely call-order dependent, whereas explicitly assigning animation tracks a priority value does not.

Explicit priority makes it so that the resulting behavior does not depend on play() call order, coroutine/event handler call order, property replication order, etc. This makes parallelization of the animator easier and less prone to bugs, and it means we don’t have to have an additional layer of complexity to maintain an explicit stack and sync it between server and clients to ensure consistent behavior on all clients. It also allows for more efficient optimization of the animation evaluator when track priority is known at play() time and cannot change. Order dependencies are particularly troublesome in games where both server and client scripts start animation tracks playing on the same animator, since there will inevitably be race conditions.


Then, if we are forced to adapt the new pattern of not stacking animations, shouldn’t there have been adjustments to make the switch easier? Its obvious that we are going to be forced into an FSM approach once the fix is out, so wouldn’t it only be fair if we got an FSM implementation for animations right in the engine or at least as a public resource?


I wonder what they were thinking when they first implemented these 8 garbage enums. Not having the same (or even half of the) flexibility with AnimationPriority as we currently do with RenderPriority is undesirably restrictive. You wouldn’t only allow 8 different Z-index values for gui elements, so why would this ever be the case with animations…?


The only issue is the lack of enums. Should’ve been values instead.


My animations look horrible with this enabled. The movements of all the animations are very constrained (ex. the run animation’s legs don’t go nearly as far/stretch, so it looks super, super stiff).

Do you guys not want to support custom rigs on the Roblox platform? To my knowledge, with this change, there is no way to fix this unwanted behaviour that would impact every single one of my games.

Edit: I should also specify that the difference between the animations with this feature enabled/disabled is so substantial that it’s gamebreaking. There’s no reason why our animations should appear differently than how we animated them (with Blender, in my case) in-game.


The low amount of enums as a “fix” is absolutely horrible. I use “emote stacking” in one of my games and it’s a feature that many people love. The stacking allows for characters to be able to stack one on top of another in any order they want instead of blending them together. However, with me being forced to limit this is absolutely annoying. If there was a way to use an integer instead of an enumeration; I’d be okay with this update.