Advance notice does not justify it, and I believe most developers would rather be working on new content for their games and projects rather than cleaning up messes that weren’t their fault.
The workflow for updating animation priorities in mass is not good either, there are many ways to approach this, but I believe most people would:
Load up their animation editor of choice, let’s assume it’s the default one.
Scrolling down to select individual is not an option in this case as it is inefficient, so let’s assume they copy and paste IDs.
They paste in the ID, load it onto the rig, change the priority, and export it. They have to wait for that export to finish, and carry on with the next.
You can of course use a script to automate inserting raw animation keyframes and changing their priority, but you’d still have to export them again, either as a new animation or replacing a new one.
Changing the animation priority in a lua environment is also not an option, as animation priorities do not replicate across the client - server boundary. Roblox encourages developers to do animations for the player on the clientside, and many including myself do that already.
The final solution proposed by Roblox is to “manage blend weight sum from Lua”, which means you will have to play around with an already finnicky API that is not well documented outside official documentation. I have had experience with this myself and even if I take care to avoid setting the weight to 0, I still get replication issues.
Eitherway, there is no clear solution that won’t take up immeasurable amounts of time or be a hassle to implement.
It’s not a fangame, it’s just a model I’m particularly fond of from back in the day. I appreciate the compliment regardless.
Unfortunately, this isn’t exactly something that can just be “fixed”. The whole point of this was to have certain animations play over others (for example, crossing your arms while flying, which has an action animation, or tapping your foot, etc.)
For one morph? Sure. Can’t be that bad, I can reupload those as movement priority, or even lower.
For nine? Hell no. That’s at least 450 animations right there. (And FYI, that’s just including the Sonic stuff I’ve made. That’s not even all of them, that’s just the ones “up to date”, and I’m already in the process of reprogramming them with my friend.)
I’ve also got a R6 morph base and other rig sets that use altered systems. This would just break everything catastrophically.
Yeah, priority is still a property of AnimationTracks so it doesn’t replicate. The only thing that replicates is the playback of the animation data at the time of loading by right of the Animator object.
So do you see the problem now? There’s no way to fix this one and done, this is literally like being a sweatshop worker and having to do the same thing over and over hundreds of times a day. And we don’t get paid for it, nor is it our fault it’s happening to begin with.
Not particularly. I see as much validity in the perspective of some projects taking absurd amounts of time to fix this as I do respect the fact that this behaviour never was intended. I get it, but I would still encourage you to fix your animations anyhow. It’s real curious if you’ve been “used” to setting every single animation to Action priority and expected this never to change.
There are still a number of things I disagree with you on, but I do like Boojie’s response since it provides more perspective on the matter. You just need to calm down a little bit though. There are some things that aren’t entirely justified throughout, especially wrt mobile.
How am I supposed to remain calm when I’m told 4 years of work is going to break because of an update that barely has a positive impact?
If the behavior wasn’t intended, it should have been fixed WHEN it wasn’t intended. It’s become a literal staple, at this point, thousands of games use it.
I literally just drafted a “what if I fixed this” type thing by checking the priorities of my animations.
It is literally impossible to fix this to a point where it restores parity with the original intent.
One issue with the workaround of relying on the stack-like behavior of animations with the same priority and weight 1.0 is that it works in Studio where there is near-zero latency between client and server, but it doesn’t always work reliably in a live game. Different clients can end up seeing very different blend results, depending on whether or not the game’s Lua coding results in all Play calls being reliably ordered under any replication scenario. Everything might appear to work fine, but a player you see tapping his/her foot could be seeing themselves crossing their arms, for example. Many of the affected games are already subtly broken, just in a way that’s impossible to observe from a single client’s point of view.
In this particular case, the blending math is unambiguously wrong and actual game engine behavior does not match the intended behavior described by the API documentation for AnimationTrack weight. A lot of developers have pointed this out, because if you actually want to do blending of same-priority animations–such as in an 8-way motion system–you will get nonsensical results unless you manually manage your weight sums.
Our hope is that the impact is minimal. When this change was first enabled at the end of 2020, we saw only 4 examples of places that had cosmetic issue with animations because of it, only one of which was a published game with players. Any game that’s using priority and weight in the intended manner should not be affected. Additionally, the few games that are affected should require only minor changes, and the extent of any breakage should be cosmetic (visual glitches).
In the short term, this is opt-in, but it’s just not feasible in this case to maintain two almost-identical animation runtimes in order to achieve 100% backwards compatibility with all possible uses (and misuses) of the system
This change is more on the scale of the physics solver replacement that was done about 3 years ago, than the materials update. What is being enabled is not just a bug fix or two, it’s actually a completely new animation evaluation engine. The blending bug fix isn’t so much a fix to existing code as a choice we made to not to preserve the bug in the new system. The benefits of having mathematically-correct weighted blending outweigh those of preserving a bizarre, non-deterministic, and fundamentally incorrect blending behavior for the sake of perfect backwards compatibility in a handful of games.
So do you just expect me to reupload thousands of animations in a vain attempt to maintain parity? Do you REALLY expect that of developers?
There’s not exactly a workaround for two movement-priority animations stacking, and in this case, I can’t make them action either, or they’ll conflict with the action-priority ones, such as tools.
What is your plan to circumvent this without thousands of reuploads?
If we even had a fifth priority, this would be fixable, and not only that, but maybe within reason. But we don’t.
Please at least address the Priority functionality before any of this. It should be a number data type, so we at least are given complete control of where each animation should lay.
Hard to do that with only like 4 enums. I’m so lucky I’ve yet to make a heavily animation-based game.
This would literally fix every problem with this except the transitions being changed. I could work with this by simply upping the priority of a few animations across my rigs RATHER than having to update literal thousands to be in a messy system that requires loopholes and copious amounts of lua to fix.
Duly noted. The extension of priority level is something we’re already planning. Additionally, we’re changing AnimationTrack.Priority to replicate, so that it will be easier to change priority at runtime/load time without republishing an animation or having to changing it in two places (client and server code).
So will this be pushed before this is forced on everyone or after? I’d rather not have a doomsday materials situation where the old materials are only usable once custom materials are fully implemented.
If this was before, I’d be fine reuploading a few animations to a higher priority or something to cooperate with the update. But if I have to use the old priority system because that doesn’t exist yet, all of my stuff’s going to be broken until that’s finally added.
This is part of what doing this as a 3-phase rollout is meant to solve. It works both ways: to give developers time to make changes, but also to give us time to make changes if we become aware that there is a much bigger impact than we anticipated. So the short answer is that it depends on extent of the negative impact of the changes as to whether or not the final phase gets held up waiting on additional changes at our end (like making priority an integer).
Fair enough. I will give you and the rest of the people working on this the benefit of the doubt in hopes that you’ll have a simpler solution by the time this does become a requirement. Just please keep in mind launching without a priority feature is probably going to result in a fair amount of backlash, and that’s why the materials update had to be delayed. I’m sure if it’s properly accounted for before it’s no longer optional, it’ll be fine, just like the materials now are.
I’m certainly going to push for this (more priority values) to happen sooner, ahead of Phase 3 where this is deployed to everything. I can’t say for sure about the replication changes to AnimationTrack priority, that one is a significantly more complex change.
Just want to point out that, well, that’s why I said the things I did. Roblox doesn’t release massive impactful changes like this for no reason. Having them roll out in phases gives developers time to migrate, provide feedback on updates or for Roblox to reevaluate how this update might go.
You have time to update your animations, or if not that then at least ask/wait for more information about the update. It really does benefit everyone in the end. There does need to be a bit of legwork done by developers anyhow to keep their games up to standard, it can’t be a completely passive effort. I do appreciate the update too because it let me learn something.
Allowing animation priority to replicate would be pretty awesome. On that note, a question:
Does this have to do with the hundreds of support topics about animations not replicating properly and resulting in other clients not seeing an animation or seeing a different one than the client sees? Wondering if this’ll fix those issues and if they had to do with blending or if it’s a genuine replication issue that they were facing.
Really nice to see that Roblox finally looked over the animation engine. Can we expect any more updates to it in the next 3 years? Perhaps support for exporting animations as an instance that we can use instead of uploading them only? Sometimes I want to quickly share or test my animations and Roblox is forcing me to upload them which just creates pure mess in my inventory and I can’t even delete them.
