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
Im sorry but im with the majority on this one, I understand they want to enhance the current animation system but many developers included myself dont have the time to go through 100’s of animations to set them accordingly, Plus we’ve built our entire games on the old framework. I’m sure the majority will agree with me on this and would rather Keep it as a toggleable feature. Not trying to be offensive but Im already used to how the old way works with overwriting anims with animation priority, I dont need it to blend with eachother, It legit broke all my animations and i thought i broke my whole game, Spent 6 hours to realize it was roblox adding something
10 Likes
Please read and tell staff at roblox that this change is not needed, Or keep it as a toggleable feature
Im sorry but im with the majority on this one, I understand they want to enhance the current animation system but many developers included myself dont have the time to go through 100’s of animations to set them accordingly, Plus we’ve built our entire games on the old framework. I’m sure the majority will agree with me on this and would rather Keep it as a toggleable feature. Not trying to be offensive but Im already used to how the old way works with overwriting anims with animation priority, I dont need it to blend with eachother, It legit broke all my animations and i thought i broke my whole game, Spent 6 hours to realize it was roblox adding something
6 Likes
I got complaints from some of the users today about the animations not working as intended. I had an inkling there was some sort of Roblox update that caused it. I’ll disable AnimationWeightedBlendFix to solve this issue for now, but just as @OneOzy pointed out… I despise the day I have to go through 200+ of my animations to tweak each one to adjust to this new update. Is there any possible alternative here? Please for the love of everything tell me some good news that there could be another possibility than to adjust all my animations to get them to work properly with AnimationWeightedBlendFix enabled. I am just a very concerned developer. If you do happen to know a solution, I am all ears. Thank you!
9 Likes
Same boat here - my game has hundreds of animations as well. It’s going to be VERY tedious to go through each one individually to implement the fix.
7 Likes
Hi, can you confirm that adjusting weight on animations loaded by the client and played by the client replicates to the server? Since AnimationPriority doesn’t, I only see changing weight as the solution, and it’s working fine currently.
1 Like
100% agree here. I tested it and it completely broke all of the animations I have uploaded so far and I’m only just getting started (I have at least 50 animations at the moment). I don’t have the time to have them all manually corrected.
Even though I have written a custom animation handler, it still relies on Roblox to play animations and the system was built and tuned around the way Roblox handles animations in it’s current state.
Even if I don’t end up needing to literally reupload animations, I could still need to change significant portions of my framework and reconfigure dozens upon dozens of animations. This is no small task.
It will require extensive testing, adjustments, etc to many animations to fix this.
Please Roblox, do not remove the disabled option
As a programmer, I understand the idea that it’s hard to maintain two completely different systems, but in all honestly that doesn’t seem like a valid excuse in this scenario. This will break many current and old games. I understand the need to overhaul the system but I think supporting the old system for longer is a necessity and frankly maybe I’m being naive but I don’t really see why it can’t just become the “legacy” animation system so as to not break existing content but just not receive major upgrades.
Roblox isn’t supposed to be Unity or Unreal engine, but for all the effort that’s going into advancing the platform it sure feels like anotner step backwards just to throw developers under the bus. It’s understandable that as time moves on, older systems will be phased out and older games that aren’t being updated anymore will break, but this is unacceptable…
Also, I think I noticed a bug with this change, will do testing and post later.
7 Likes
Besides going back and manually reuploading every animation, is there anyway we can make our old animations work with the new engine?
2 Likes
Your options are reupload or write an animation framework to account for the changes. (Or make an entirely independent animation system, which is frankly what I’m considering at this point)
1 Like
Couldn’t they make AnimationPriority replicate? This would fix everyone’s issue with this new system, as you would be able to set AnimationPriority via script instead of reuploading.
2 Likes