i think they are making a sarcastic joke
How cool, I wasnât able to participate in game development activities for a while and Iâm rewarded with broken looking cutscenes and animations in my games, thanks.
I really donât understand why such a big platform that hosts the ability to create games has to push updates that can affect a large portion of developers in a negative way.
Also seeing how âworkspace:SetAttribute(âRbxLegacyAnimationBlendingâ, true)â works, why not give us the choice in the first place? I understand opting out of the whole new runtime animation system can cause issues (even though it was forced onto us without much of a choice), but thatâs better than leaving folks in the dark.
I hope this can be brought up with the members working on your side, Iâm sure the intent was good, but when it comes to such a big picture like the amount of Roblox experiences, itâs not something you can simply flick on/off.
7 Likes
My bad, My mistake. I hope so, seriously.
2 Likes
I donât know if weâve always been able to adjust animation priorities in scripts, but this allowed me to work around this update by toggling between two of the priority states to dodge the forced logic of using priorities and deliberately stopping anims.
local function ChangeAnim(NewAnim)
if LastAnim then LastAnim.Priority = Enum.AnimationPriority.Action end
NewAnim.Priority = Enum.AnimationPriority.Action2
LastAnim = NewAnim
end
Running something like this right before an animation will make things work as they used to, given you apply this properly. This is just hacky though, and I feel like this change was completely unnecessary, especially given the huge negative response from all of us.
The only issue is that this causes Motor6Ds to become unresponsive to changes in C0 or C1. Setting the priority to Core fixes that.
Additionally, the weight property of animations doesnât appear to work anymore when blending animations on Core. Setting the priority does seem to work though.
I donât understand why this had to be rolled out whatsoever (even without any changes to the original announcementâs rendition which had been met with a ridiculously negative community response) when it seems like the blending behavior of this change could have very well been split from the optimizations and rewrites to the animation framework.
I am so utterly exhausted of writing paragraphs upon paragraphs of nothingness ranting about ridiculously unnecessary and inconveniencing changes to the engine that I just canât be bothered to make a full explanation of why people are so angry about this. I donât get why itâs being rolled out in this manner when even in this very post every single reply is loathing it. I donât understand why itâs been a month absolutely nothing has been done to remedy this.
Does the Roblox team think that developers donât have enough to do without having to constantly rewrite and overhaul massive elements of their gamesâ infrastructure every few months because of completely random and unnecessary changes they have no control over being thrown into their faces on top of already massive workloads? Why was this change so necessary? Who had an issue with the old system to the extent that it was necessary to ruin the animations of most of the games using them on the platform and force developers to spend hours compensating for it?
The only reason why I havenât spoken on my frustration about this sooner is because Iâve been so extremely loaded with existing pressures without the Roblox team already massively adding onto them as they have for the entire year already with the audio and material fiascos which were already absolutely abhorrent and robbed me of quite a lot of the motivation I had to work on the platform, and Iâve also found an extremely hacky workaround out of necessity (which should be a testament to just how badly developers do not want this).
I get that this was an attempt to solve a legitimate issue and that the team is working hard to adjust the future and soften the blow of its release but this is absolutely the wrong way to go about it. I and many others wouldnât be so extremely frustrated about this if this wasnât being rolled out in a way that ruins a massive part (character animations) of half the games on the entire platform for the millionth time. Why has Roblox gotten so accustomed to rolling out changes in this manner when it clearly stresses out and frustrates developers and turns the change into infinitely more trouble than itâs worth? When has this ever worked out? Iâm so confused. Whatâs more confusing is how dead set the team rolling this out is on rolling this out in this destructive manner despite the overwhelmingly negative response (which has, unfortunately, been a precedent on Roblox for far too long).
4 Likes
tl;dr (with a mildly shorter paragraph) please for the love of god just keep the old behavior in some manner, I get that itâd be inconveniencing for the team but 1. itâs more than worth it when the alternative stresses out, exhausts, and infuriates developers to this extent 2. while the new behavior may be more âââadvancedâ"" and optimized in some ways, the old behavior was far more convenient as you could just play animations without much worry whilst the new is just unnecessary work 3. why do you absolutely need to systematically ruin the animations of half the games on the entire platform, stir outrage in the development community, stress out developers (and yourselves with how chaotic the response to this was, sorry guys but remember that there are very legitimate and justified reasons for developersâ response to this) when nobody really had any problems with the old behavior, I get that you want to âadvanceâ the system and open the door to new features but is that worth all of this trouble when thereâs even probably ways to circumvent it and let people just have both somehow? I donât get why Roblox has NEVER been able to compromise with any of these sorts of ridiculous changes despite how destructive they are, please just try
just please. I know that it seems like developers are MASSIVELY overreacting (which they absolutely often are to some changes) but there is reason for such an intense response to this because animations are a very important, vital, and essential part of peoplesâ games. was it that bad keeping the option for both?
if itâs not telling enough that youâve ruined the animation system in favor of mundane âoptimizationsâ: every single person new to animations and development Iâve observed has made a simple animation only to find that it is extremely wonky and not like it was in the editor for seemingly no reason and believing it was bugged, why is this something that needs to be kept in by all means?
2 Likes
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.
The notion of âwe canât maintain legacy systems for the sake of developer preference because it quickly becomes extremely hard to maintainâ has been used to justify quite a lot of large-scale, controversial changes like this recently that uproot essential features and elements of developersâ games and ask developers to spend time and energy compensating for changes breaking major parts of their infrastructure that they had no control over.
I understand this completely from a development perspective and can definitely see the logic in not wanting to maintain two identical systems at once for backwards compatibility because of workload, but the main problem is that this behavior wasnât legacy until you made it legacy. I know you guys have been working hard on this and are doing this with the very good intentions of opening the door for new and exciting features (and I know that the public response to this seems extremely unnecessarily negative), but forcing developers to compensate for massive changes on core features that come as a result of this manually should be a last resort.
My point from this is that developers had no issue with the old behavior and preferred it as it was convenient to just be able to play animations over another. The issue came when this behavior was declared as an issue by the engineers, not the developers using it. Afterwards, not only has the old behavior been removed but itâs been removed for all existing games, scrambling a core part of many games depending on animations for the sake of changing the feature. It should be clear this is not a âhandful of gamesâ being affected based on the scale of the reception on this very post and the last, in fact this behavior was depended on by seemingly quite a large majority of games that used animations. Maybe it is our fault for not using animations âcorrectly,â but it worked better for us and became âcorrectâ when many people started depending on it. I always thought that the old behavior existed intentionally to make the animation system convenient and easy to use and get into, and with it being removed it seems essentially from our perspectives that youâre removing a big part of animation workflow just because you suddenly found an issue with it.
Priorities are not intended to be used to simply have the latest track replace previous animations that do not need to continue evaluating. That is a bad pattern, one that was causing serious performance degradation in a number of top games, and one that adding arbitrary integer priority values would have enabled and encouraged.
Maybe this wasnât how they were intended to be used, but it was how they ended up being used by many developers and how many developers got comfortable with the system. I know it seems janky and wrong on your end, but why not adapt the system to allow for this sort of thing instead of rejecting it? The ânot every bug has to be a bad thingâ lesson is something all developers encounter. I havenât had the time to read all posts clarifying the complexities of the internal system, so maybe this wouldnât be easy whatsoever, but an effort should be made to make this change more convenient for developers instead of essentially saying (this is a brash exaggeration but itâs necessary to get my point across sorry) âwe donât think we can do this so suck it up and fix your games.â
I know that the animation rewrite has already been made and applied, but there has to be some way that the new behavior can be made a little more convenient for developers. Stubbornly sticking to this change and forcing developers to take the blow for it shouldnât be the means to making this change, especially when Roblox honestly seems to punish developers for engine changes far too often in recent times. If Iâm honest, the purpose of a game development engine is mostly for it to serve developers, not the engineers working on it. Even if itâd be difficult to manage, maybe itâd be worth allowing for the old behavior to stick around with how fervently developers are defending it (and with the honestly largely negative reception of this change). Itâs always seemed like Roblox (blanket term for you guys sorry for generalizing 
) has been far too easily convinced that the better option would be to punish developers for a change they think has become necessary.
I think itâs pretty telling with how ravaged the animations of many peopleâs (absolutely including practically ALL of mine which are mostly combat games which Iâve paid a lot of attention to the animations of making this change pretty frustrating) games have been by this and how passionately people are rejecting the change. Iâm not all too well-versed in the technicalities of this so take it with a grain of salt, but this is my comprehensive take on it. Maybe an outside perspective could help.
3 Likes
I dont know if this helps because I replied 9 days later, but if you keep all animation priorities the same, it is definitely going to break. You will have to make everything a different priority, so it doesnt overlap.
I tried this on a game im working on with someone else, it fixed the problem.
Weird I can still revert the update by adding the attribute called RbxLegacyAnimationBlending then set the attribute to true and how is no one noticing this?
Also thank you @pankii_kust, @Withrill & @Buq0 <3
4 Likes
You saved me from a whole bunch of time. 
but my skateboard works.
I think this attribute can only fix the animation and not Motor6D try setting your animation priority to Core
1 Like
It doesnât work. I canât set the shoulder Motor6D C0 to any angle more than 0.010101965710543179 radians or else it will twist weirdly.
You just need to make your animation use the core priority.
I stated in my last reply. That didnât work.
it only affects the animation, not Motor6D
Actually, it does. C0, Transform, and C1 are all overridden by any playing animation above the Core priority.