Not really possible, at least not as it is now.
1 Like
I will go and cry while I get enough courage to do this grind.
3 Likes
So, I’ve tried editing the animation track’s priority via scripts, and it doesn’t work. Editing from the server does nothing. Meaning the only way we can change priority is by opening it up in the long way.
What the hell? That’s it, I’m sorry, but this is where I snap. Normally, I’m supportive or apathetic to updates, but not this time.
So first, you’re forcibly pushing blended animations (which at this point is widely used so it would break thousands of games), which is a red flag at the start. Why should we have to sift through tens, if not hundreds of animation files, import them onto a rig to change the priority, just because someone thought it would be a great idea to not have the property be toggleable. I’m astounded. We don’t even have a good way to edit a lot of assets we make at the same time, or anything.
In addition, that’s 7 priorities we now have. That is very limited. Some people need more than 7 priorities to make animations. It doesn’t look like we’re going to have animation priorities replaced by numbers going from 1 - whatever maximum you need.
I don’t understand why it’s going to be mandatory. Isn’t it better to keep the disabled option on the priority to preserve developers’ experiences without forcing them to go through a mindless grind? Isn’t it better to introduce it as a separate feature for developers to voluntarily use? Yes, the current method is a “bug”, but it’s a convenient method.
I’m sorry if I’m sounding aggressive, but this has really pissed me off. If I’m wrong about anything, or misunderstanding something, please let me know and correct me.
15 Likes
You can sync all clients by connecting them to a module and using an event to make the new priority actions replicate. Well, that is what I’m doing, let the suffering, blood, sweat, and tears get this grind. 
Cause whoever’s in charge of how this update is being rolled out doesn’t seem to care about the amount of games that will be forever broken by it, nor the amount of work accommodating the change makes. I still wanna give credit to AllYourBlox for getting those new 3 priorities in, but that really only did the bare minimum of making this technically feasible. Those didn’t account for how monotonous of a task this is, though, and I guarantee that once this update hits Phase 3, complaints will come flooding in because of the intense workload.
Most are probably just disabling the change right now as a fix, and hoping the update doesn’t go through. I encourage Roblox to keep this in mind.
5 Likes
Could you please give some context as to how this is going to act on legacy animations in various ROBLOX experiences? How are developers going to manage with the new update being enabled and older animations having to be reinserted manually?
I hope that there is a plan to simply convert all animations over to phase 3 without the errors that are showing up. It is a catastrophic setback for me and several others to do this manually.
3 Likes
I’ve talked to quite a few people about this change so far, most haven’t realized that the setting to fix this is going away; I think that’s the primary reason people haven’t gone doomsday mode yet @_@
4 Likes
Yeah, once that goes… There’s gonna be carnage, really.
Remember, the materials update only went full-on doomsday after they said “toggle go bye bye”. That did not end well for Roblox. They need to learn from that mistake again, clearly.
4 Likes
Hey developers,
We just wanted to take a moment to thank you for all of the feedback on this feature. We hear you and we want to make sure we’re taking the right steps going forward.
We’re going to take a beat to regroup internally, come up with a plan and properly address concerns. We’ll post an update in a few days.
For now, if you do want to opt-out of this you can do so by setting Workspace.AnimationWeightedBlendFix to disabled in your Workspace properties.
Your feedback revealed an unintended issue involving the runtime system that we will address in a separate post. We’ll share a link here once that is live.
We will work to address the concerns you’ve shared here. Until then, please continue to reach out if you observe anything unexpected.
Thanks again!
14 Likes
This would be helpful. Also having .Looped property replicate.
I am just so unhappy that I have to completely redo all the animations for this to work. Previously I WAS using animation priorities, but bue to the fact that we only had four available at the time, I had to rely on overlapping aswell.
The fact that this is going to be removed soon is just so disheartening.
I sincerely hope Roblox finds a good way to implement the new changes while not breaking old games.
2 Likes
Glad to hear this.
Since you are reviewing current plans, does this mean it is safe for me to pause the overhaul of my game’s animations and wait until an update?
Also, the removal of animation orders acting as pseudo-extra animation priorities will break my game. Is it possible that we could get more animation priorities, perhaps just as a number value? Ie 0-20?
3 Likes
Thank you. Although I obviously don’t know what’s going to change, I’m glad to see that the team is taking the feedback seriously and seemingly learning from where the materials update failed. I very much appreciate it, and I’m sure everyone else does as well. Keep up the good work!
1 Like
Is there going to be an easier way to mass-change the priorities of animations in-website?
The current most “efficient” way is to drag the animation into studio, change the priority, then click “Save to Roblox” then scoll down until you find the animation you have to overwrite.
And then repeat that like 500 times for each animation.
1 Like
It’s looking pretty buggy, but I just can’t help, but laugh at the default Rthro animations becoming this after I slap another model inside my character: https://gyazo.com/86d487e0e34fb13d6543a57cb19ddfeb
I figured I would mention, this breaks my game Super Skyward Towers. I have code that yields for an animation to complete if a player is hurt. As soon as this change was flipped to Enabled (which is what Default is now), that code infinitely yields, resulting in the player’s movement completely bricking. When this is set to Disabled, the code continues to work as normal.
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.