-- can we have the ability to forcibly end a transition between animations PLEASE. i have to do so much excessive hacky garbage in order to work around this fix in order to keep the behavior of my animations and no matter what i do i have to now either stop having my animations transition back to idle when they’re completed or just have this horrendous slow smooth transition play if one starts during the transition that ruins the snappiness of the animations. not every use case requires animation transitions number 1 and number 2 having no control over animation transitions at all is unacceptable
-- and here’s how they look with the new fix: https://i.gyazo.com/0da89429682da23db20f5cb9cc965be0.mp4
-- if the player makes an input during the animation’s fade out then it makes this horrible smooth between the two despite me running :Stop(0) on the track (it does nothing since technically it’s already stopped, even though the animation is still playing through the transition and affecting the player visibly)
-- i was originally perfectly happy with moving over my code but there is literally no way for me to reproduce these same visuals with the new system, at least not that i can find. PLEASE give us control over animation transitions
-- edit: okay so i fixed the problem by, every time an animation is played, iterating through every possible track of the same priority and doing :Play(0) :Stop(0)
-- this is bad and i really hope this isn’t going to be the only way of fixing this ever
For goodness sake, listen. For once in this company’s miserable publicly-traded life, listen. It’s the first and best thing any of you can do and it seems like you all actively avoid doing it wherever possible.
Nobody wanted this change. It breaks more than it solves. It resolves essentially no issues.
I tested this in my WIP game and it makes every animation look gutlessly smooth - which is not what I want!
You can take your “new animation runtime (that) gives us huge performance benefits, especially on mobile devices” and put it right next to the ‘making audio public’ option, UGC moderation and the solution to this platforms’ meddling game discovery - to say, the closest bin.
I like to have animations that work as I made and scripted them for the way they have worked for years, thank you.
So, i noticed that i cannot anymore manually update the arms Motor6Ds CFrame, that it has no effect when there is an animation playing at action priority. How is one suposed to manually CFrame arms now?
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.
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.
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.