New Animation Runtime Rollout - Upcoming Property Removal

Updates Announcements
, , , ,
#175

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
#176

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
#177

Congats you just broke my animations!! so cool!!!

image
image921×608 74.2 KB

1 Like
#178

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 :sweat_smile:) 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
#179

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.

#180

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
[SHOTGUN] UTPS.dsk - an Open Source weapons animations for developers
#182

You saved me from a whole bunch of time. :pray:

#183

Doesn’t work for me. I guess…

image
image474×575 27.8 KB

image

#184

but my skateboard works.

#185

I think this attribute can only fix the animation and not Motor6D try setting your animation priority to Core

1 Like
#186

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.

#187

You just need to make your animation use the core priority.

#188

I stated in my last reply. That didn’t work.

#189

it only affects the animation, not Motor6D

#190

Actually, it does. C0, Transform, and C1 are all overridden by any playing animation above the Core priority.

#191

Everyone noticed it because it’s the only fix for the problem— the issue the community has with this ‘fix’ is that it’s a manually applied attribute you have to search the dev forum to learn about instead of keeping an exposed bool flag on workspace.

It’s not a big ask to just expose LegacyAnimationBlending so it’s more accessible if they’re not going to rip the functionality away entirely. I, probably like many others, have no intention to learn the new system as it does not make sense to me why I would strictly rely on priorities when the legacy blending is more intuitive.

3 Likes
#192

Try set “Standard” in Game Setting → Avatar try

#193

The ability to have the old animation logic as a workspace property would still be highly appreciated, even if it’s just copying the logic of the legacy animation attribute.

2 Likes
#194

need motor6D manipulation support

1 Like
#195

Yes, this is still an issue as well. I think it’s a bug since they changed it without notice.

1 Like