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 this is a really good change, well done!
1 Like
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???
10 Likes
Wait will I have to redo my custom animations for my game? If so I’m not gonna get sleep for the next 3 days lol
3 Likes
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.
Below is my example with Caliber.
Source: roblox this is an issue
19 Likes
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.
9 Likes
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.
2 Likes
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.
2 Likes
You’re oversimplifying the work of the engine. Maintaining two logic chains would do more harm than good in the long run.
1 Like
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.
7 Likes
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.
The OP poster has already said, they cant support multiple systems. This has been said this multiple times, this is not supportable.
Please understand, they can’t support 2 different systems in the long run. End of story.
1 Like
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.
1 Like
Disabled (Before)
Enabled (After)
How do I fix this? All of my animations have their priority set to Action.
11 Likes
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.)
4 Likes
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.
3 Likes
If you could provide an example place file that illustrates the problem you’re experiencing with the bouncy animations, I would be happy to take a look at it and see if it’s a use case we expect to have issues, or if it’s something new that we haven’t seen yet.
2 Likes
This isn’t intentional, it sounds like a bug. I’ll make a ticket for this. Any issues like this–ones that are not related to the blending change we know can’t be 100% backwards compatible–are things you can expect to see fixed before Phase 3.
6 Likes
I’m glad you recognize the importance of these features, but I don’t like it being left up in the air whether or not these things will be available before the update is forced on everyone. Confirmation would be nice since whether or not these things are available will change how developers approach fixing their games.
Maybe I am understanding wrong, but it seems like you are saying that if these changes are too difficult / time consuming then the update will get pushed anyways - I don’t see why this would have to be the case or what the rush is to get this update out. In my opinion delaying this update until we get these features is much better for developers and the best way to go about it.
8 Likes