This issue is one I’ve already committed the fix for, due as part of next week’s regular client update.
1 Like
Do you by any chance ever move a player’s character out of the Workspace and back, either on the client or server? Or toggle the Disabled property of the Animate script? There is a known bug associated with our Animate script that is not tolerant of these and results in multiple copies of your walk and run animations blending. The duplicate tracks were always there (a performance problem), but with the fixed blending math they are now visibly contributing. This is my highest-priority issue right now.
If you don’t mind me asking, could you clarify what exactly the cause of that is? I did some further testing with the flag enabled and noticed if you play AnimationA and AnimationB, with AnimationA being higher priority, AnimationB simply hangs until AnimationA stops execution. This does not occur with the flag disabled.
Ah OK, there could be two things happening here. My initial assumption was that you had code waiting for a KeyframeReached or GetMarkerReachedSignal event at the end of your animation. If this is the case, this will be fixed.
The case you mention of animations A and B, it’s expected behavior that if the higher-priority A track has weight of 1.0, that the lower-priority B track will not contribute to animation of any joint which A is also animating. Track B doesn’t “hang” per se, the time position advances in real-time, it just doesn’t affect any joints that Track A is animating. If Track B has animation channels for some joints that A does not, those will still animate with the full weight of track B.
If the higher-priority track A has a weight of less than 1.0, it will allow track B to contribute to bring the total weight per-joint up to 1.0. In other words, if track A has weight 0.9, track B will still be able to blend in as if it has weight of 0.1, for all joints they have in common.
1 Like
See that was my assumption, but that is not the case in my testing. I have a repro of it actually hanging. Meaning, animation B does not physically continue execution while animation A is playing, resulting in any code that waits for animation B to complete hanging.
Should I file a bug report for this, and link it here? I have a repro file that I can DM you if you’d like.
Yes, you should file a bug ticket for this. Animation B should not be getting evaluated, but the intention is for its Stopped events, named keyframes, and AnimationEvent “markers” to still fire. Its TimePosition should still be advancing according to the AnimationTrack speed as well. A repro place file could be very helpful, in the event that there is some specific detail about your setup that is required to reproduce the problem.
1 Like
Will do. I’ll link you to it once I’ve filed it. Will likely be filed tomorrow 
1 Like
What I do to myself is:
I make my character invisible, after that I slap another full model(without a humanoid) inside my character and a new animate script.
The new animate script is called “Animate” while the original one is renamed in which way I can use Emotes.
I updated it a few times so I can have my animations continue playing by deleting the old and making a new Animator object and after that enabling the original animate script.
Hope that made sense.
Heya! I’ve filed the bug report : `Workspace.AnimationWeightedBlendFix` infinitely hangs concurrently running animations
Is there per chance an ETA for this? My characters currently slide awkwardly on the floor; but I’m also going into all of my places to replace sounds, so I may try to fix this while I’m in these places.
Also I’m unsure why, but my fix for this works in Studio, but not in the actual Roblox app. Any idea why it would behave differently? It appears to be related to anchoring the HumanoidRootPart.
Hey, I just realized that my game has had its animation being played differently without being touched, and quite oddly for many weapons. It seems the cause of this is this new feature, as when the property is Enabled/Default, it’ll be present, but if I disable the property, it goes back to old behavior.
I’m a bit confused to how weights exactly work, but I have tried adjusting the weight of the most recent played animation, and changing the weight of the old one to 0.00001 instead of stopping it as the post said could be a possible solution (Not exactly sure if this is what my case is)
I do apologize for the late concerns - I’ve only just now noticed since I haven’t paid too close attention to animation playback for these sorts of weapons.
AnimationWeightedBlendFix Enabled
AnimationWeightedBlendFix Disabled
Due to stylistic choice, I play the same animation (often longer than weapon cooldown), so it’s very common to overlap and have multiple active at a time at the same priority & weight. If they go fast enough (like for this weapon in the gif above), it can cause it to go ‘out of sync’ and look buggy.
While disabling it would be a fix, I assume it’ll only be a temporary one?
What should I do in my case if these solutions didn’t work for me? I’d be happy to supply any extra information about the animations needed!
1 Like
Weight refers to how much an animation overlaps from 0 to 100%. For example, if you only had one animation playing, it would play at weight 1 and not blend. If you had two animations playing at once, each would play at weight 0.5 and each animation is blended 50% and so on when you add more animations.
If you’re creating and loading multiple attack animations with no overlapping idle animation you could keep an array of previous attack animations and stop them every time you play a new attack animation. If you need to keep the animations playing for it to hit a marker or something, then set the array of all previous animations to weight 0.000001 and if that doesn’t work I’m not sure what you can do.
I didn’t understand this update very well, I think just is bad, anyways how would prevent my animations from breaking?, Do i use the new actions like a cape?, as i was drawing?.
Before the update:
After the ‘update’:
That’s just a single example in my combat-based game, even changing the priorities to Actions 1-4 can’t fix it because the endlag is too short and restarting the attack combo from the end of Action4 to the beginning of Action1 looks just as weird and malformed.
4 Likes
Getting the same issue, makes me want to cry. I exported my sword slicing animations and switched the priority to Action 4.
still acting strange.
1 Like
A big thank you to everyone again for their input on this topic and patience while we regrouped to discuss the next steps. We would like to share the following updates:
- We will fix the long-standing issue of animation priority not replicating and ensure that it does BEFORE Phase 3 of this runtime system release. This will give everyone an alternative option to set animation priority at run time rather than being required to reupload your animation clips.
- We are actively working to address all of the identified bugs and unintended changes in the new runtime system and will reach out to affected Devs to confirm their experiences are fixed so that they can opt back in once that has happened.
- Please note that there is currently no set date to enable Phase 3 of this release and we will provide the community with ample notice before it happens.
- We have already expanded the Action priority enums available to use and can work with you on how to best leverage them in your experiences to get your desired animation results.
In addition, we are committed to delivering many of the other improvements mentioned in this thread and elsewhere. We will have some exciting announcements coming later for those, but Phase 3 of this release is a necessary stepping stone to get those improvements out to our community.
For anyone that still feels that they cannot reasonably make the transition to the new system with the new priority enums and added priority replication, please reply here or to me directly with your concerns and a link to your experience and we will absolutely work with you on a solution.
6 Likes
Hi, even if i readed all i dont understand, I have my flashlight that when you equip it , it reproduces idle animation and then when you click a “on/off” animation, but this just breaks, what’s the problem?
You can fix your animation by changing the AnimationWeightedBlendFix property in Workspace to Disabled. This will disable this new feature.
Just curious but is there a reason why priority isn’t just instead using integers?
I’ve tried to stop the previous animation before each new one is ran but it’s still being offset over time, so no luck there. Lowering the weight to almost 0 didn’t fix it either, and I don’t have any markers for it. I run animations like this for its style, and I’m afraid if this does eventually get forced and won’t be permanently opt-out (which is rare in case of Roblox features - for example, ‘Legacy’ lighting mode was eventually removed in favor of Compatibility, which still lacks the same look)
My experience is having issues as shown in my earlier post here. I’m currently unable to figure out how to pull off the same behavior with the weighting changes. All I know is that this used to run how I wanted it to, but now it doesn’t. My issue here is specifically it losing its accuracy over time for consistent looping of different animations, same id.
Link to my experience -
Thank you
2 Likes