Yes, this is correct. The animation is playing through all the way, but it’s blending 50/50 with the Idle.This is the known issue that must be fixed by developers, by playing the action (e.g. the punch) at a higher priority than the idle.
2 Likes
No, that doesn’t seem to be the case.
Even without the script I have beforehand set the animations’ priority to action4 and that is what you see in the video.
Edit: I seem to have fixed it by changing the priority of the wind-up to a lower Action enum than the actual punch animation but this is still non-scalable when there’s only 4 enums. Imagine if I wanted to make a sequence of animations eg. a combo of five attack right after another - the last one would get messed up.
3 Likes
Ah OK. We didn’t know this punch was more than one animation. So the problem is the same, it’s just that your wind-up and punch are blended, rather than idle and punch. The number of priorities we have available now is more than enough to do any combo, it’s just a matter of authoring it correctly so that animations are not left playing.
What developers used to do was just keep playing each stage of a combo with the same priority, and relying on the latest animation to override the others. There were 2 problems with this method: 1. It worked in studio and always looked correct for animations played on your client, but there was no guarantee it would replicate and look correct on other clients. Usually it did, but it could get re-ordered. For long animations overlapping in this manner, this method never worked for newly-connecting clients, by which I mean clients who join the game after the animations started.
The second problem is that stacking tracks like this left them all running. If you had a 7-move combo attack, by the time it’s finishing, you’d have 7 tracks playing on your avatar, all with the same performance costs as if they were all being seen. Only the latest would be seen, but the other 6 would still be getting fully evaluated. This just doesn’t scale well to large player counts, or work well on low-end mobile devices.
5 Likes
That is true. I wish Priority was a number-based value instead of an Enum-based value.
His case illustrates exactly why this would be a problem. If a developer could author a 7-stage combo attack just by using 7 priorities, they would, and performance would suffer. The whole combo could be done with 1 priority, if the parts are authored appropriately and crossfaded. The blending issue above occurs only when you just play all the tracks at weight 1.0 and leave them running, rather than crossfading them by using Stop() and Play() with matching fade-in and fade-out times.
4 Likes
Understandable, thank you very much for the explanation in both posts. I just wish this info on how to correctly use the new system was more wide-spread and available.
5 Likes
If I were wanting to add a high speed weapon swap system like doom’s, would that be possible with this change?
1 Like
Yes, how you would do this correctly is not changed by this update. Doom has a pretty standard setup where the equip and unequip animations are played sequentially. In Roblox, these would normally be played one after another, both at Action priority.
What might change for some developers is how weapon animations like firing/recoil are layered on top of the Idle animation of the weapon, when there is one. With the old animation system, there were multiple ways to do this: The right way was for the weapon Idle and Fire to both be Action priority, and to Stop() the Idle whenever Fire was Play()'d. A small fade-in and fade-out time could be used for fast blending. The wrong way was to just play the Fire animation with weight 1.0 without stopping the Idle. This would appear to work most of the time, but it would not always be correct on all clients** and it would also incur the full cost of playing both animations simultaneously for the whole duration of the firing.
With the changes to Animation priority and the weighted blend fix, the easiest way now is to just play the firing animation at Action2 priority, no need to stop the Action-priority Idle. This will only have the playback cost of the animations that are actually visible contributing, and it will be correct on all clients, 100% of the time. While it may be a bit painful for some devs to have to change the priorities of some animations to conform to this use pattern, the end result will be both better for performance and consistency for all players. And you can change the priority of an AnimationTrack in Lua now, and it replicates, so no need to republish the animation.
** Depending on exactly where the animations are triggered from, it would be possible for other players, especially newly-connecting ones, to see your weapon idling when it was supposed to be firing, or vice versa.
2 Likes
My game relies heavily on the previous behavior of “stacking” same-weighted animations to create fun and creative animation combinations (Such as using an animation to affect the upper part of the body, over the top of another animation). It also uses this behavior to “animate” using poses, where players can, for example, hold their foot in the air, then transition to a stomp, and then back to having their foot in the air by deactivating the stomp. It’s a little hard to explain, but I hope the gist got through.
Is there any way to preserve this behavior with these new changes? Animation combinations allow for my game to be so much more lively.
I am not sure if this is because of these changes, but I have noticed that walking and running animations have been playing weirdly across many games for me. I’ve also noticed that it is more prevalent on taller characters.
When the humanoid walkspeed is set higher, the animation appears to correct itself.
1 Like
I patched this issue a couple of weeks ago in our Animate script, but the fix requires developer action to complete for any place that is using stored copies of an older version of the Animate LocalScript (e.g. in StarterCharacterScripts, StarterCharacter, or a pre-build character in storage), or a developer-implemented animator that duplicates the behavior of the pre-fix Animate script.
The issue is caused by moving the player’s Character model out of Workspace temporarily and then returning it back later. The old Animate script was accumulating orphaned AnimationTracks in this case, which are now being cleaned up when the character is returned to the Workspace and the Animate script restarts.
3 Likes
This issue is still present for me, even on a blank studio baseplate that would not be using a stored copy of the Animate script.
I’ve noticed that adjusting the ScaleDampeningPercent that is parented to the Animate script reduces this weird animation and makes the animation play how it is intended, but I am not familiar with this value and I do not know the consequences of adjusting it.
ScaleDampeningPercent at 1 - which is what it was defaulting too for me.
ScaleDampeningPercent at 0.5 - which is what I adjusted it to just to illustrate the change
And this is the Run Animation I am using and how it is supposed to look.
1 Like
I’ve found a massive issue when switching animations in the Animate script, not sure if this is a current bug before the 3rd update, but it’s been irritating me and I’m not sure how to fix it.
Essentially I’ve stopped every animation the player is currently using for it to switch, but it seems like it blends the new set of animations for other people on my client. I’m using an edited version I made of the default animation script. This problem didn’t exist until the blend fix.
It either blends them weirdly or doesn’t stop the animation at all. You could look at me (how it’s supposed to look) and then the other player (how blending effects it), it’s not replicating at all. Any help here would be appreciated.
2 Likes
Ah, your problem is here. The Bubbly Run animation has a different number of frames than the standard Rthro run and walk, so if you equip it, you have to also equip Bubbly Walk as your walk animation, otherwise you will get the strange behavior you see. The problem comes from the Bubbly Run and non-Bubbly Walk blending together; since they are different length animations, and one is not a multiple of the other (39 and 15 frames), they go in and out of sync as you run around. This will happen regardless of the AnimationWeightBlendFix or Retargeting property settings, it’s purely an issue with the incompatibility of the two animation clips.
3 Likes
Does your game ever move the player characters out of the workspace, toggle the Animate script’s Disabled property, or do anything else that might cause the Animate Script to stop executing and start up again later? You could put a print statement at the top of your Animate script if you’re not sure.
If so, your issue could be the last one I fixed, which is the issue of the Animate script not cleaning up after itself if it gets stopped and restarted. Can you reproduce the problem if you use the latest Animate script? If not, you might need to merge your custom Animate script with the latest version, to be sure you have all of the fixes. I’m assuming here that your copy has minor changes, and is not a completely different system altogether, which of course could have a different problem.
This could also be a replication related bug. Historically, it’s been fairly easy to spawn Animator instances on both server and client, that don’t replicate to each other, unintentionally. A simplified repro case place file (.rbxl) would help test this out, if you have one.
5 Likes
I’ll try out what you’ve recommended, but I’ll describe my process anyway.
Basically my method was firing an event to the animate script, stopping/deleting all currently playing animations in the Characters Animator after replacing all the IDs in the animate script, which seems to change successfully for my character, just not anyone else’s on the client.
I don’t disable the animate, I don’t load in any others, and I don’t move the character out of the workspace. I just use the one that generates with the chosen character, which oddly works fine at first, until animations switch.
Also, a question to follow up. Have animation priorities changed for the default AnimateScript? I remember before the blend fix that all default animations were Core. Has this changed for this fix?
1 Like
No that is not it as this happens when using Rthro walk and run together too. This is a scaling issue that causes the animations to distort. This was not an issue a few months ago and has just now started occurring. I don’t know how else to explain it though but hopefully it is resolved eventually as it causes the animations to look very odd on taller avatars.
No absolutely not, This is a god awful change that breaks so many games using sped up and fast Animations,
Default:
Turned Off:
[Roblox as a platform just keeps getting worse and worse with each update I swear]
3 Likes
Roblox has had some good updates, SOME. This one in particular should’ve been pushed when everything was figured out and fixed, now essentially everything is broken and it’s irritating to look at.
2 Likes
Somehow, out of nowhere, our animations just decided to break. They worked totally fine even with the AnimationWeightBlendingFix property enabled. Just recently (like, really recent), a good number of animations have been broken. I thought this was to do with the update’s general scuffed-ness, but it turns out that our look-to-mouse script is no longer compatible with this update. It seems that the animations no longer consider that the UpperTorso is being rotated. They now only face straight forward. What gives?
(with AnimationWeightBlendingFix disabled, this problem doesn’t even occur)
With the look-to-mouse script enabled
With the script disabled
1 Like