I worry mostly because, OP said “before phase 3,” but that doesn’t necessarily mean we’ll be given ample time to effectively port (I don’t think 8 weeks is enough either but I digress.) The fact that this was announced before more priorities and replicated priority levels have been added (which OP only announced when the concern was brought up, least this is the first time I’ve heard it confirmed in any way) leads me to believe this is being somewhat rushed.
I really hope the backlash pushes them into adding something like Animator.BlendBehavior = Enum.BlendBehavior.Overwrite/CombinedWeight at least.
Very doubtful. Sorry but the backlash is nowhere near bad enough for the engineers to seriously consider backwards compatibility - this year is just gonna be the year of backwards incompatible updates, as it seems they’ve realized it’s best to push for everything now rather than later - the best time to have done so would’ve been 5 years ago, but the second best time is now.
If Roblox were super cautious, making sure not to break old api and systems, then there would be very little progression in the entire engine, I get that this is super annoying to deal with, I myself will have to go through all my previous and current games to update to the new engine (although not on the severe scale that you will), but in the grand scheme of things, its moving the platform forward and you gotta just buckle down and deal with it.
I think your best bet right now is for this to be a property you can toggle, like how it currently is but permanently.
I am working in a project that has 72x player animations with complex states that it blends between - this change caused two minor issues when blending between states that took like 10 minutes to fix.
So can anyone tell me WHY my tools make a weird bounce after using them??
Idle animations are priority Movement, use animations are priority Action
The tools also use a script that removes the Grip weld, and instead adds a Motor6D, so the tools themselves can be animated.
This is NOT expected behaviour, this whole update can breaks so many games its unbelievable.
Noone had an issue with the old animation engine, this is unnecessary
EDIT: I tried everything, this issue still persists. Removing the Motor6D changed nothing, even deleting ALL the default animations did nothing. What am I supposed to do???
Really excited and glad to see how this animation engine is finally getting some changes and improvements as few days ago I was losing my mind over playing few animations at the same time and some fading / interpolation bug.
I hope other things like animation replication will get addressed soon, right now even if a client plays the animation on a server created animator under character’s humanoid, it still does not replicate sometimes.
This update seems like what programmers call a “band-aid solution.” This fix just caused more bugs that need fixing as well. Animations are now janky, bouncy, and overall, this update just feels unpolished.
I see I’m not the only reply as well, other developers such as @RVVZ have pointed out disgusting behavior.
Adding onto this, even if they managed to fix the many issues it has. Look at how many animations would have to be changed in just 1 of my games
Edit;
And while people say its impossible to have a option to turn it off, because they would need both systems. They DON’T need both systems to function. In lua you could literally do something like this;
if BlendingEnabled == true then
--Blend animation function
elseif BlendingEnabled == false and PriorityNumber == PastPriorityNumber then
--Override animation function, mimicing the previous system without REQUIRING a previous system, as its built into the new code.
end
In fact if done like this, it should actually be easier to add than the blending animation, as over-riding should require way less math.
This will cause bugs because devs were relying on bugs to fix bugs. Should it have been fixed a long time ago? Yes. The problem is if they don’t fix it now, it’ll be an even bigger problem in the future and affect more people. The current codebase is unsustainable with a new one on top of it. Think about it. Sooner or later this would be fixed and sooner or later your game will break, whether it’s now or later makes no difference because eventually this is a must needed change. Using a bug to fix another bug is the real band-aid solution.
Just REWORK the old base into the new one.
If you have the “blending setting” off, then just override animations of the same priority instead of blending. Problem solved, and doesn’t require any bugs or secondary systems to function.
There is typically nothing to polish with respect to math corrections and optimization.
People should be suggesting tools or API changes to help them correct their animations programmatically or with more ease if they have a lot of animations that need updating. I would much prefer this fixed behavior over the old behavior, because this behavior is expected, while the previous behavior was very unexpected and downright broken in ways not easily visible.
How?
The system would do all the work for the animations, and when the code is just about to blend it, just double check that blending is enabled, and otherwise override the animations of the same priority.
Unless they do something to fix it in the long run, its so far just creating more bugs for me, and doesn’t help gameplay nor performance on my end (at least for me, maybe people want blending for their games, but so far its only causing me trouble).
Not even my walk animations work, as they blend with the idle, even though the idle has a smaller priority and shouldn’t be blending at all. It’s horribly unpredictable when I attempted testing it in games, and even upon changing the priorities it never seems to work properly, and causes more and more bugs. I feel like it’d almost be easier to code a custom animation player using cframes and motor’s that way the animations could at least work in a comprehensive way.
Edit; Haven’t been able to get it to work too well on some of my other games, but I did manage to get the system working on a separate game. Instead of using the :AdjustWeight() function (which didn’t work at all for me) your kind of forced to use priority. Which at the very least fixed my idle and walking animations, but I don’t think this would work for things like punches, which would overlap each other. Trying to use priority doesn’t work on stuff like combat, and using :AdjustWeight() only made things blend more for some unholy reason, Although that last part is probably my fault.
Ideal solution is just to make priorities for animations an integer value rather than sticking to enums.
That way, we can make an infinite amount of priorities and never have this problem again. (Assuming they don’t break the existing animations using enums.)
I’m not sure if this is intentional, but when I enabled this setting, all animations played on the server-side no longer fires markers or keyframe names that are located near the end of the animation.
Here is an example of a marker near the end of an animation track:
This also affects older animations using legacy keyframe names. Essentially this breaks all my animations which relied on end markers.
