I just encountered this and realized it was never solved… What???
Roblox seriously hasn’t fixed it when this bug was posted roughly 2 years ago?
as stated in a earlier post this will not be fixed Animation cubic easing direction reversed - #56 by INT_L
Hello, while we have made the decision for now to preserve the reversed behavior for compatibility, we understand this is a pain point. Updating the preview in the Clip Editor to match the runtime behavior is a good suggestion, since that would at least give a clearer idea of the runtime result without changing existing animations.
In the meantime, as that earlier post noted, we have now released to beta a new Animation Curve Editor. Please take a look, as it provides fine-grain and visual control of the easing behaviors by directly editing the tangents of the curves.
I am noticing this bug still, more than 2 years later.
Animations keyframe EasingDirections In and Out are incorrectly swapped when playing animations. Animation editor correctly displays the expected result though.
A Roblox animator, @SnyFort, has made a plugin for this. This has been a Roblox bug for pretty much forever. Plugin link: Revert Cubic Easing Direction - Roblox
Any idea when something might be done Studio-side to make this less ridiculous? Developers are having blindingly frustrating issues and getting stuck on export because of this obscure issue. Most recently, Animation loop is not seamless in-game. (Mesh deformation). Not to mention, it is incredibly demoralizing to find after 8 hours of animating, your walk cycle is a mess when you export it and you have no idea why.
If this cannot be actually fixed, adjusting the Studio tooling to compensate is the next obvious thing to do. Curves solve the problem if you can figure out how to use them, but people will continue to use the baked in easing styles because it’s easier at a glance.
For anyone who continues to have this issue, I have a temporary solution, a script which swaps out the easing direction of keyframes for a model named “AnimSaves” placed inside in ServerStorage. All you need to do is copy & paste the AnimSaves folder from inside the character into ServerStorage, run the script or copypaste into the command bar, and it should fix the animations in question. I’ve had to rely on this for however long this has been an issue, swapping and then exporting the fixed animations.
for _,d in pairs (game.ServerStorage.AnimSaves:GetDescendants()) do
if d:IsA("Pose") and (d.EasingStyle==Enum.PoseEasingStyle.Cubic or d.EasingStyle==Enum.PoseEasingStyle.Constant) then
local Switched = false
if d.EasingDirection == Enum.PoseEasingDirection.In and not Switched then
d.EasingDirection = Enum.PoseEasingDirection.Out
Switched = true
end
if d.EasingDirection == Enum.PoseEasingDirection.Out and not Switched then
d.EasingDirection = Enum.PoseEasingDirection.In
Switched = true
end
end
end
print("Fixed Animations!")
Still a problem in mid 2023, I’ve just encountered this bug
I just noticed this bug when testing an animation. I’m using the latest version of the animation editor. Very annoying to have to re-upload every animation that uses the cubic easing style.
Any news on this? The bug is still there even today and it’s very frustrating.
Can something finally be done about this bug? I’ve never seen fruit hanging this low, yet here we are 4 years later. I understand there may be more pressing issues but this is something any developer will run into on their first day of learning how to animate. Please don’t sweep this issue under the rug.
Poking here again because (with respect) this is inexcusable. “Just use curves” is not a solution for this - curves are a radically different method of animating within the engine. Telling people to turn their workflow upside down, and delay artists for N hours/days/weeks, while they learn a new animating method when the keyframe method is tried and true and has a practically infinite amount of resources and strategies already available, is completely negligent.
If you are concerned about backwards compatibility, add a version field to animation assets and fix it for new published ones. This is absolutely garbage for the end user to slam into, and is another one of those cuts involved in the “death by a thousand cuts” problem that Studio already has. Fix it and rip the band-aid off.
And honestly, it doesn’t matter where you fix it - in the asset playback or in the authoring tool. As long as the tool shows what’s going to be uploaded, nobody cares. Just fix it.
Bump. HOW is this still a thing???
What kind of decision is that? Who would want to see their animations not play out correctly because you chose to preserve it for “compatibility”? And compatibility for what? It’s only a Studio issue. Either update the plugin playback or the whole animation on-upload.
I was reading through this thread, seeing as I was having trouble and this response really doesn’t make sense to me. This is a current Roblox Studio feature with a BUG that makes animating so much worse. Switching to another animator won’t do since that’s got the same bug, and I will not be using the highly-unintuitive curve editor until its own bugs and issues get fixed. With all due respect, the “compatibility” argument is very lazy and anti-developer to me.
If you guys are really hellbent on preserving “compatibility”, then fine, keep the BUG in, but at the very least give us an official solution to quickly toggle easing directions among all keyframes! Something like a “reverse easing directions on all keyframes” button, because I’ve been dealing with this BUG for years and I’m getting very, very tired of it. I don’t want to have to change the easing directions on all keyframes of an animation; some of my animations got a lot of keyframes, and most of the time I spend on animations is JUST for switching directions around. Not fun, and the team and I need these animations.
Somehow in updating all of studio’s UI they still haven’t figured out how to switch two bits of code in a single built-in plugin. You can’t even say “just use moon animator” anymore because it costs… THIRTY DOLLARS?
In all seriousness this issue is a headache every single time i have to animate something. because first I have to animate it properly to see if it looks good, then I have to manually switch around all of the EasingDirections. I would really like for some info on what actually makes this such a difficult change or preferably just a fix outright.
At the very least. Just document it. SOMEWHERE. This issue is never mentioned in the Animation Editor docs despite them showing off the cubic EasingStyle on said page.
??? Preserving a bug for compatability?
tbf, its so that all animations dont break, but the fact that they havent just reversed the editor to show the end result is truly baffling
Why not just correct the animation editor so that all animations going forward are uploaded properly? Or just as you suggested, make the editor itself display the inverted behavior that we see in-engine???
A new CubicV2
easing direction was added in v646, so I guess this is actually getting fixed at last!