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.
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.
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.
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?
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.
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âŚ?
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.