@zeuxcg Possibly :AdjustWeight(float weight, float fadeTime) doesn’t work as intended? As you likely know, the idle and walk animations in the Character’s Animate script are Core priorities and have a weight of 9 &1 (idle Animation1 and Animation2) and 10 (WalkAnim).
I tried running another Core priority animation and called :AdjustWeight(11,0.1) on it, but it didn’t quite give the desired result. Is there something I’m forgetting, or something I didn’t know? I assumed the default weights from the Animate script itself.
Here’s the code:
local anim = script:findFirstChild("SecondIdle") -- Idle animation inside localscript
local myHum = game.Players.LocalPlayer.Character.Humanoid
local loadTrack = myHum:LoadAnimation(anim)
loadTrack:AdjustWeight(11,0.1)
loadTrack:Play() -- This still results in default idles overlapping it. (The custom animation only has the Head and Right arm moving, so that the Left Arm, Torso and Leg movements of all other animations remain.
No, that’s exactly what this update didn’t do. You’re thinking that the animation with the highest weight will keep playing in each priority level, but they will instead get blended into each other depending on their weight factor. (this is precisely the message of the OP, it’s all written there.) If you only want your animation to play, you’ll have to either pause all the others or play your animation at a higher priority level.
Play() overrides the weight of the animation. If you want to play an animation with a weight of 11 for whatever reason, just call :Play(0.1, 11).
Weights in the Animate script are unfortunately a different concept from blending weights - they are randomization weights used for selecting the animation for every loop cycle.
If you want to play the animation, as @buildthomas suggested you should just stop the other animations. Or replace the Animate script with the logic you want. Or somehow change the Animation instances used by Animate script before it runs (not sure what’s the best way to do that…)
Since many people seem to be confused by the new behavior, and in many cases the system actually behaves the same, I want to do a poll as to which behavior is better.
I liked old behavior (if 5 animations with weight 1 and same priority are playing, you only see the last one)
I like new behavior (if 5 animations with weight 1 and same priority are playing, you see a blend between all of them)
I liked the old behavior, and I like the new behavior. The new behavior is the kind of behavior you’d expect out of animations had we never had the old behavior, and I believe the new behavior is the proper behavior. But, with a lack of priority levels, the new behavior can be difficult to work with, so until we get more priority levels for animations, if ever, I’d have to say the old behavior is the most appealing.
The game I’m working on has a custom model with an animation that smashes its arms downwards. The arms are supposed to play this animation even while jumping, so the smash animation had the leg parts excluded. Now I can’t play the smash animation at the same time as the jump animation without another another priority level. I can’t stop the jump animation, the legs wouldn’t animate the way I want.
With the current blending I can’t animate my model the way I want it to without having more priority levels.
Fire a bullet twice will cause the second fire animation to be weak unless u play it EXACTLY after the first animation stopped OR stop the previous animation, which require alot of unnecessary coding and variables.
I have a tri-combo punching effect, if u punch them now u sorta just hold ur hands in ur stomach cause the animations just blend together into an incomprehensible pile of garbage.
I don’t think those who voted for the second alternative have much experience working with animations. If they did they could easily just adjust their maskweights instead of messing the whole thing up for the rest of us.
Secondly I voted for the second option and I’d argue I have experience with animations This system is definitely better because we can accomplish more than we could before. It does however mean that you’ll need to run your animations properly, which you could bypass doing before so yes there was a behavior change.
Regarding your use case, if your fire animation is being overridden, it means you should be stopping the previous one before playing it again? Or am I missing something.
The vote has nothing to do with MaskWeight. MaskWeight never really worked well and was not supported by the editor, so it has been discontinued and is not coming back.
Right, so obviously adding more priority levels is not too complicated. The reason I posted the poll is slightly different.
When I originally made the change I had two possible behaviors in mind - new & old - and was picking between them. It felt that new is slightly better and, when asking the question to some people at HQ “what should the behavior be if I play two animations with weights that add up to more than 1” the answer was “weighted average”, which is why the update shipped with this as the default.
However, I started thinking that:
There are clearly cases where the new behavior is harmful - some people have pointed them out in this thread. While you could solve them with priorities and stopping animations, there are some cases where you have to stop the animation & restart it again which is kinda cumbersome. I’m not clear that static assignment of priorities can solve all cases - what if you want every successive user action to overlay over the currently playing animation? - and forcing devs to keep track of currently playing priorities & play new animations with the next priority level seems like an overkill.
I can’t imagine any specific usecases where you may want to leverage new behavior - that is, when the new behavior is clearly more convenient. There are cases when you want to explicitly blend several animations instead of doing a transition but then it seems like it’s very easy to normalize the weights to add up to 1.
I am currently leaning towards switching the update to use old blending behavior (fortunately I anticipated that I may need to do this…). It’s interesting that poll is 50/50 though.
Maybe I’m only thinking this because I figured out a neat way to do fast blending that only works for old behavior…
Why not mix it together?
Use the weighted average, unless we say “don’t use it”.
Another parameter in Play, a boolean property in Animation or KeyframeSequence, …
To be honest I think this should stay. I was initially confused by it, but as zeux said, keeping animations running without stopping them isn’t a good practice. We DO need more priorities, however.
That’s right, but having a method to say “only this animation should run right now” might be very useful. (Well, if the animation only animates the arms, only the arms should be “reserved” by the animation)
the overhead is still there though - it’s better practice in the long run to close unneeded threads
i think the diagram you made is a bit biased too, you haven’t even mentioned the advantages the new animations supply, so obviously it’s going to look like the old animations are better
This system is definitely better because we can accomplish more than we could before. It does however mean that you’ll need to run your animations properly, which you could bypass doing before so yes there was a behavior change.