While I’m glad you are able to opt-out for now, but it would be very beneficial to keep it togglable. Currently, my biggest game is completely animation focused, and today I woke up to my playerbase complaining about the animations being broken. I was able to fix it, but now it’s very distressing to know I will have to manually update 480+ animations when this could very easily be prevented if this update wasn’t forced.
5 Likes
my game has at least 90-100 animations and i dont feel like reuploading every animation. this is bizarre
4 Likes
100% agree. What is with ROBLOX and fixing things that aren’t broken?
Also, I’m trying to figure out where it would be preferable to have 2 animations overlapping and merging rather than have the latter one play to completion, then go back to the former.
Roblox made a really good mistake, then came back 8 years later to ‘fix’ it into something that has literally ZERO use cases.
Why!? It’s like they’re trying to make their beginner-friendly game maker platform as needlessly complex as they can!
5 Likes
Phase 2 only changes the Default setting of Workspace.AnimationWeightedBlendFix, it does not add anything new to test that hasn’t been live for months, and it has been enabled since last June in a sampling of top games in order to make sure any new (unexpected) breaking changes were not sneaking in to the new animation engine.
The purpose of the 3-phase rollout is to provide developers lots of forewarning when it’s known that a change like this is going to cause breakage, and plenty of time to test and prepare (Phase 1). In this particular case, developers had 8.5 months enable the new behavior and “smoke test” their games.
Phase 2 is the opt-out phase, so that any developer who did not test against the changes and is now discovering their game is broken is still able to fix the problems themselves by setting Workspace.AnimationWeightedBlendFix to Disabled and republishing their game. For these affected developers, now is the time to start working on addressing the problem animations to bring things into compliance with the published AnimationPriority API. I’ve added 3 more levels of priority specifically to address the known issue. In most cases, blending issues should be solvable by promoting any animations that were relying on stack behavior to use Action2 priority. Action3 and Action4 are also available to address the case where developers stack multiple Action-priority animations, though this is relatively uncommon. In some cases, code changes may be easier. Our recommended solutions are outlined in more detail in the original post.
For anyone who is discovering issues, please do still provide us with a link to your affected game. While a particular type of blending breakage is expected, we do want to know about anything unexpected that shows up, and playing known-affected games is the easiest way for us to identify any new issues.
1 Like
Although in my use case, thanks to the extra priorities, I was able to get away relatively scott-free, I can definitely see why other people are unhappy. They are going to have to reupload hundreds of animations.
If someone has an animation system set up where 50-100 animations all use the action priority specifically to overtake something, for example, different poses playing over another action animation, and they can’t lower the priority of the animation being over-written, they will have to manually reupload all of those hundreds of animations. Yes, they’ve been given a lot of time to do it, but most of them were blissfully unaware of the update, and a lot will probably continue to be. It’s not fun to do and it takes a lot of time. It’s incredibly labor-intensive for something that results in no pay-off beyond fixing something that was broken.
Given that animation-based games are a pretty significant genre of games on Roblox right now, I’d really be expecting this type of backlash to a much more severe degree once Phase 3 inevitably rolls out. Most developers unfortunately probably aren’t going to bother checking this until it’s already too late. Scripting is also a far from ideal solution, because I imagine a lot of animation-centric games probably don’t have many scripters, and so the only real workaround is reuploading things.
While I don’t take issue with most of the changes made, I do have to agree with TheCrimsonKing. I see no use case, at least for the average developer, where having the animations blend together is a desirable outcome. There’s just no reason to attempt to use it because it doesn’t look good. It looks broken and awkward because of the nature of a “middle” pose.
9 Likes
A lot of games that rely on the current behavior of same-priority animations overlapping based on which animation plays last, and in the case of my game I need to have a lot of animations which may cancel each other out depending on which was played last. So they need to have the same priority but also somehow replicate the old behavior of the roblox blending system. Because of that, it doesn’t seem to me as though any of the solutions mentioned in the original post will work for my use case (which seems to also be pretty general). How do you recommend I go about this?
6 Likes
In most games (outside of Roblox) where the player controls a character in first or third person, the character’s motion is a continuous blend between different locomotion animations that represent different directions, speeds, and postures. A typical FPS has an 8-way blend system blending forward, backwards, and strafing movements, sometimes even dedicated diagonal or “arc run” turning animations, with further variations for speed (walk, run, sprint) and stance (standing, crouching/sneaking, prone, etc.)
This type of system, a staple of modern video games, is very tedious to do in Roblox prior to this blending change, because it required developers to continuously vary (and replicate) weight changes to all currently-running tracks to maintain a weight sum <= 1. This is one of the main use cases and most-frequently-asked-for character controller features.
6 Likes
I completely understand what it does and how it is improved for those situations, what I don’t understand is why it is going to forced onto people.
It would be much better if it was disabled by default, because currently that is what most developers are already using, and if developers wanted to use this new feature, they could enable it.
As others have said, many, many developers do not have the time to reupload hundreds of animations, and there are many more who will not even know to be prepared when it is rolled out.
I would say the best option for everyone would be to leave it at phase 2, that way, the technology is there, for developers to freely choose, and many games on Roblox do not get visually broken.
Basically what I’m trying to say is:
Why not both? You already have a version implemented RIGHT NOW where you can toggle between the two, and it will be very easy to change the default setting to disabled.
6 Likes
If the current track is actually being cancelled, there is no problem, it just needs to be explicitly stopped when the one cutting it off is started. There are actually a number of Roblox games that don’t ever bother to Stop() animation tracks, they just keep playing new ones with weight 1.0, and many of these developers are probably unaware the animation engine continues to evaluate all of the overriden animations, something that can result in crippling framerates. In other words, just because you only see one animation track dominating, doesn’t mean the other 20 tracks you started playing on that same humanoid aren’t still running with considerable performance overhead. Humanoid:GetPlayingAnimationTracks() is useful for testing for this problem.
You would only need to make significant changes if you require stack behavior. i.e. You play track A (looping), then track B (non-looping) at the same priority overrides it, then when track B end, you expect track A to automatically resume as if it were running the whole time (which of course, it was!)
Most of the time, this can be handled by using the AnimationPriority system as intended; by making sure animation overrides are all being done by priority, not relying on Play() call order. In the very worst-case scenario, there is actually an Option 4 that I didn’t put in the original post. Option 4 would be to add a stack to your Lua animation script, to explicitly manage your own stack behavior for each priority level you need it for. When you push an animation onto the stack with weight 1.0, you have to adjust the weight of the previous top-of-stack track to 0.0 with the same fade time. You reverse this when popping the stack. If you need the suppressed track to appear to keep running, e.g. to stay in sync with other animations, you can either manually set the TimePosition, or–for a small performance cost–you can keep it running by fading it to 0.001 instead of 0.0, so that it doesn’t fully stop playing.
2 Likes
I can totally understand how, in isolation, maintaining two options forever could look like a simple solution since, like you say, the code’s already there. The problem is that if we did this for every change and key bug fix, the codebase would quickly become a bloated nightmare with multiple versions of each subsystem and branching special-case code all over the place keeping alive bugs that maybe only a few games relied on. It’s not a long-term solution because the amount of code to maintain would grow exponentially, and with it, instability.
3 Likes
I understand why this fix needs to exist, but only for certain use-cases. Too many developers on Roblox have based their entire animation style on this behavior and don’t care for the new technology, and it’s not simple to just change, not to mention the majority, including me, will be unwilling.
All these “solutions” aren’t really solutions, rather bandaid fixes to replicate a behavior that y’all would rather just delete instead of allowing players to toggle between this new tech and the old overriding behavior that so many developers (including myself) heavily rely on.
Please, I urge those on this project to make both sides happy by taking the extra time and resources to give developers the option to choose between both the new tech and the legacy behavior in a natively supported, cleaner, and more performant implementation.
Surely there is a way to implement both behaviors with the new changes without causing a mess.
9 Likes
Thank you. Yeah to me it seems like something I’ll just have to engineer myself. Just to paint a better picture for you as to what my use case is, I have a weapon system which utilizes a few different types of animations:
-Idle animation (Base animation, can be overwritten by Attack/Reload & equip)
-Equip Animation (Can be overwritten by Attack/Reload)
-Attack/Reload animations (These need to all overwrite each other. These include gun shooting, reloading, etc)
So obviously if I were to make this compatible, using different priorities would work for the idle & equip animations. But for all Attack/Reload animations, these should obviously play and overwrite other action animations previously playing. I had a system I was using in an attempt to make my animation system AnimationWeightedBlendFix compatible in which I would :Stop() other Attack/Reload AnimationTracks playing once a new one was played and resume them once the AnimationTrack stopped or was canceled. However, even while not being opted out, this really ended up having different - but similar - blending issues I noticed just by using :Play() and :Stop() without stopping other tracks. Really just resulted in a lot of jitter and weirdness in which, for example, an animation would play blended halfway the first time played, but then the second time it’d play completely correctly.
Obviously I haven’t extensively looked into this so I don’t know what could be causing it or if its - and this is most likely - user error, but maybe if it’s this convoluted and unintuitive for a lot of use cases it’s worth reevaluating?
4 Likes
For this type of situation, I highly recommend calling GetPlayingAnimationTracks() and printing the results to the output window any time you start or stop an animation, during the course of debugging and migrating your code. I typically print the track name, weights, speed, priority, etc. however much information is needed to get a full picture of what’s playing. If you do a lot of fading in and out with the Stop and Play calls, you might even add a function on RunService.Heartbeat that prints the tracks periodically, like a couple of times a second, while you’re debugging an issue like this.
3 Likes
Same here, I have a huge following for my napoleonic assets; all of which runs on animations that have markers on the final keyframe to denote they are finished. Hundreds of players in the napoleonic community are now reporting animation problems. Not sure where the animation blending comes in here, but I am wondering if this issue can be fixed for Phase 3, or whenever it is fully flushed out…
4 Likes
I wish this was announced in a more prominent way! Our game had game-breaking issues as a result of this, and caught our team completely off guard!
(Maybe a DM to the developers of experiences with the setting AnimationWeightedBlendFix toggled as default)
Here’s the bug report I submitted for weighted blending, seems like switching between positive and negative Z rotation values causes unintended behavior:
(Game-breaking regression on newest release involving Motor6D animations causing unintended changes in ZVector values)
6 Likes
I agree! I spent half the day wondering what broke in my game. My community’s concurrent playerbase was quite upset with, unfortunately, me. I checked the bug reports in the forum fervently for many hours and shared my concern in some developer discord too, no one had any clue. Some sort of warning or notification would’ve been really appreciated in this instance.
3 Likes
It should have been it’s own announcement tbh, it’s a big enough change to warrant that.
1 Like
I think there may be a separate issue here with room to improve the Announcements sorting. This thread would ideally have popped to the top of Announcements when I replied to it this morning, but I see now that it does if you sort by “Activity”, let not by the default “Latest”. I will inquire about seeing what it would take to make it so that staff replies to a thread can be used to bump them to the top. For continuity, I think this would be preferable to making a new post for each update, as discussion then inevitably ends up continuing on in each topic and it can become more difficult to aggregate and follow.
2 Likes
I guess today they just enabled it to be default on, For a second I thought I broke my entire game because all of my animations were broken, If anyone else’s animations broke, Go to workspace and disable the AnimatedBlendFix property. I legit spend hours trying to see what i did wrong
2 Likes
This is only temporary. Once Phase 3 rolls out, the option to disable AnimationWeightedBlendFix will be permanently removed. That’s why I’m already adjusting my game animations to this new property.
2 Likes