Theres a problem where the arms will stay in place when you try to set the M6Ds CFrame, all the methods listed in list of recommended solutions to make your code complaint were applied but none fixed the issue.
AnimationWeightedBlendFix Disabled
https://gyazo.com/e530c931aa86906d825e417bb23b1d75
AnimationWeightedBlendFix Enabled
https://gyazo.com/3c881613145776b65c2cf2e833031d63
A lot of third person games will be having the issue on rollout please fix ASAP!
Thanks for fixing something that wasn’t broken
I couldn’t agree more with you, but I don’t exactly get what you mean with “forcing the 2022 materials” - The last time I looked you could disable them in the MaterialService (‘Use2022Materials’ property)?
Horrible update. The old behavior was intended behavior for years, so why go back now and change it, claiming that THIS is actually intended behavior?? If it was actually broken it would have been fixed quicker, not 10 years later.
Just let us disable the blending. Wouldnt it be so much more performant if there was no blending, and animations just played on top of each other?
I have the exact same issue with my shooter game, im moving the waist using motor6d to tilt it to follow the camera, but that no longer works. It took me hours to backtrack why that suddenly stopped working a few weeks ago. (animationblendfix was changed to be disabled by default by roblox)
Maybe you should re-check your code on that last one, this shouldn’t affect animations from playing at all AFAIK.
Apparently it was a bug according to the linked post;
What I don’t understand is why the optimizations are all under the same hood as this option. Why? It seems like it could be split off so the blending change could be a separate option that can be used for older games with potentially hundreds of animations, where adding 3 new enums doesn’t solve a thing.
To clarify, they’re not forced anymore. They initially said they would be forced in the announcement, but in the most surprising, incredible and unlikely turn of events, they listened to community feedback and made the 2022 materials optional instead.
My game has AnimationWeightedBlendFix set to Default. Does Default stand for Disabled or Enabled?
It should be enabled with Default.
Please implement an integer priority system before releasing this. The extra enums we got are not enough, and will not be enough in the long term. Implement a proper long term solution before going through with this.
No one wants to deal with having to micromanage playing animations at different priorities or constantly stopping animations to retain the ideal behavior.
I genuinely hated this as a feature on workspace and it always broke my animation systems.
Now it’s REQUIRED?
Why? Why. WHY!
This blend fix literally breaks so often and has broken my games for a long, long time. I never knew to fix it until I disabled the blend fix.
I genuinely think this should be reconsidered.
Edit: What I’ve realized here is that you basically now need to code more just to make it work as intended. I still don’t retract my opinion that this should be reconsidered.
For once I actually managed to prepare for an update, this is a first!
As a side note I’m seeing some funky behaviour when setting Motor6D.C0 or Motor6D.C1, sometimes it works and sometimes it appears to try and blend with currently playing animations (when it should still completely override them). This does not occur at all when Workspace.AnimationWeightedBlendFix is disabled.
(Probably) Related:
Should’ve kept AnimationWeightedBlendFix to default… Terrible update. Please reconsider before it’s not too late.
Our custom rigs in World // Zero for both players, and mobs (dragons, horses, mythical beasts, etc) all work fine with this change. Roblox isn’t removing support for anything, you just have to set up your animations for the new system.
If your animations look different, its because you are playing them on top of other animations. In the old system, there was a hack that would give the latest played animation 100% of the blended weight. You can’t rely on this hack anymore and need to stop other animations from playing that shouldn’t be playing.
I 100% support this change because I initially thought this is how animations worked (as they do on every other platform, including Blender) and it was weird to learn that you had a lack of control on Roblox due to the hacky play order.
+1 for more Enums though
It is disappointing how this feature is being forced on all games (from what I can tell), as this broke my game’s animations (it works, but they look really weird), and I’m not easily able to get a fix out until after the deadline.
While the issue is minor for me now, this will likely break animations in many older games, especially RPGs, and many of these developers aren’t working on them anymore or don’t have the time to fix them.
Please make sure that any new change will never be forced on older FE-compliant games! It’s disappointing to have to constantly pop back into old projects just to fix another feature which Roblox unintentionally broke.
Nope.
No, no, no. No thank you.
This update is awful for games with really snappy animations, such as mine.
Here’s an example. This is how it’s supposed to look:
Here’s the “”“fixed”"" version:
It looks gross. It might seem minor but it mars the complete aesthetic of the game. I put so much time and care into making sure it looks snappy and sharp, and now it looks smoothed out without any attention given to priority.
The great thing? All the animations stop. The animations don’t overlap, at least not for very long. And the priority enums are used. So what gives? There’s no rhyme or reason for any of this, and this leaves SO much room for unpredictability.
I genuinely don’t understand why this update is being forced. I understand the idea behind it – there was a bug that’s been here since the beginning and now it’s being ironed out. But that’s the thing: everyone developed their games thinking this is just how it was supposed to be. So why not create modifications that emulate the feeling of the old system? Otherwise, a bunch of other games are being left in the dust.
The really big question is this: Who is the majority that gains from this, and why can we not have our cake and eat it too?
We’re aware of the issue where setting Motor6D properties from script does not behave as it used to. This is not directly related to the blending or evaluation order changes, it appears to be an unintentional behavior change that just coincidentally happens to be in the new runtime evaluator code branch only. A few recent avatar and animation features, including retargeting and IK, were developed in the optimized runtime branch, so the AnimationWeightedBlendFix is now enabling more than just the original blending math corrections.
The looped property of animations does not replicate across the server/client boundary. This has been a problem for years. Can you PLEASE look at it?
I don’t understand why they’re “”“fixing”"" this “”“issue”"" yet they’re refusing to fix the inverted easing styles bug? If Roblox is gonna make our development a hellscape to deal with, could they at least be consistent so we can expect what gets/is getting fixed and what isn’t?
I understand how, from the developer side of the API, it seems like we’re merely fixing a bug that some games rely on. In truth, calling it a bug fix at this point is misleading in regard to the scope of the change. The “fix” became a choice to not re-implement the incorrect blending math when we rewrote the animation track evaluator from the ground up to scale for the future needs of the avatar system. We had to make the blending work as intended, and as it has always been described in the online documentation. Correct linear blending of tracks is essential for things like multi-way locomotion controllers, FACS facial animation, and runtime retargeting. Freedom from play-call-order dependencies was also important, as I noted previously (above), especially for improving replication performance.
The old runtime’s evaluator did the blending math with a combination of CFrames and Euler vectors. The new runtime does all its math–interpolation and blending–with quaternions, converting to CFrames only at the very end when applying to Motor6D.Transform. The old runtime evaluated tracks in low to high priority order, the new runtime reverses this to avoid evaluating anything that does not contribute to the final animation. The old runtime stored transforms in memory as CFrames, the new one uses least-3 quaternions encoded in a packed integer format, in order to support much larger animations. These are just a few of many very significant low-level differences.
The reason the old animation runtime cannot stay around is simple: it’s impractical for Roblox engineers to maintain redundant evaluators and to have to always consider both when features are added or changed. Branching core parts of a game engine to preserve backwards compatibility for a handful of games is a slippery slope that quickly leads to a bloated codebase that is a nightmare to work on and super confusing for new engineers to come up to speed on.