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.
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.
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.
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!
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?.
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.
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.
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?
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.
Just a quick update on this rollout. Fixes are now live for the 4 main, unintended bugs developers were seeing with AnimationWeightedBlendFix enabled.
Keyframe markers and events near or at the last frame of an animation should now fire reliably. Previously, behavior for non-looping tracks resulted in these markers not firing most of the time.
AnimationTracks which are playing, but not currently contributing to the final result due to being completely overridden by higher-priority tracks, will now still update their TimePosition and fire Stopped events on time, rather than deferring these updates until they are once again contributing.
A numerical stability issue in our math libraries causing visual glitches with small rotations of joints (rotations near identity) is now resolved and will not result in tiny rotations about an arbitrary axis.
Our default Animate LocalScripts will now clean up any pre-existing AnimationTracks playing on the Animator instance they are associated with, and replicate this cleanup to the server. This addresses a long-standing issue of the Animate script leaking still-playing tracks when avatars were temporarily unparented from Workspace and stashed somewhere else in the datamodel like ReplicatedStorage, Camera, or Lighting, which was made more visible apparent with the new blending model.
AnimationTrack.Priority, in addition to having new values, has now been added to the list of AnimationTrack properties which replicates between Server and Client, bidirectionally. This will allow for easily assigning a new priority at runtime without needing to do it independently in both server and client scripts.
If you have disabled AnimationWeightedBlendFix due to issues in your games, I strongly encourage you to test again now with the property enabled, to make sure the fixes listed above have addressed your games’ problems, and report any issues still occurring. As of now, there is no set date yet for moving to Phase 3 where the new animation runtime will be enabled for all places.
