How?
The system would do all the work for the animations, and when the code is just about to blend it, just double check that blending is enabled, and otherwise override the animations of the same priority.
The OP poster has already said, they cant support multiple systems. This has been said this multiple times, this is not supportable.
Please understand, they can’t support 2 different systems in the long run. End of story.
1 Like
Unless they do something to fix it in the long run, its so far just creating more bugs for me, and doesn’t help gameplay nor performance on my end (at least for me, maybe people want blending for their games, but so far its only causing me trouble).
Not even my walk animations work, as they blend with the idle, even though the idle has a smaller priority and shouldn’t be blending at all. It’s horribly unpredictable when I attempted testing it in games, and even upon changing the priorities it never seems to work properly, and causes more and more bugs. I feel like it’d almost be easier to code a custom animation player using cframes and motor’s that way the animations could at least work in a comprehensive way.
Edit; Haven’t been able to get it to work too well on some of my other games, but I did manage to get the system working on a separate game. Instead of using the :AdjustWeight() function (which didn’t work at all for me) your kind of forced to use priority. Which at the very least fixed my idle and walking animations, but I don’t think this would work for things like punches, which would overlap each other. Trying to use priority doesn’t work on stuff like combat, and using :AdjustWeight() only made things blend more for some unholy reason, Although that last part is probably my fault.
1 Like
Disabled (Before)
Enabled (After)
How do I fix this? All of my animations have their priority set to Action.
11 Likes
Ideal solution is just to make priorities for animations an integer value rather than sticking to enums.
That way, we can make an infinite amount of priorities and never have this problem again. (Assuming they don’t break the existing animations using enums.)
4 Likes
I’m not sure if this is intentional, but when I enabled this setting, all animations played on the server-side no longer fires markers or keyframe names that are located near the end of the animation.
Here is an example of a marker near the end of an animation track:
This also affects older animations using legacy keyframe names. Essentially this breaks all my animations which relied on end markers.
3 Likes
If you could provide an example place file that illustrates the problem you’re experiencing with the bouncy animations, I would be happy to take a look at it and see if it’s a use case we expect to have issues, or if it’s something new that we haven’t seen yet.
2 Likes
This isn’t intentional, it sounds like a bug. I’ll make a ticket for this. Any issues like this–ones that are not related to the blending change we know can’t be 100% backwards compatible–are things you can expect to see fixed before Phase 3.
6 Likes
I’m glad you recognize the importance of these features, but I don’t like it being left up in the air whether or not these things will be available before the update is forced on everyone. Confirmation would be nice since whether or not these things are available will change how developers approach fixing their games.
Maybe I am understanding wrong, but it seems like you are saying that if these changes are too difficult / time consuming then the update will get pushed anyways - I don’t see why this would have to be the case or what the rush is to get this update out. In my opinion delaying this update until we get these features is much better for developers and the best way to go about it.
8 Likes
I’d love to see a repro case for this too.
This sounds like the walk track isn’t getting all the way to weight 1.0. At weight 1.0, no lower-priority track will even be evaluated for the joints that are influenced by the higher priority track. I’d have to see how it’s coded to know for sure what the issue is here.
1 Like
I’m not going to pull up the code as of right now (mainly because its a bit of mess) but I’m pretty sure it was an issue with :AdjustWeight() not working. Animations would work fine with blending enabled as long as the priority was set, however when I tried used adjustweight instead of priority it caused all the animations to blend together instead.
Code was on the client, but I’ll recreate what it looked like
Idle:Play(.2)
Idle:AdjustWeight(0,0)
All walk and run animations played after the AdjustWeight function was used would blend. Maybe the walk/run animations by default had a weight of 1, so it went over 1 thus causing the blending, but it wasn’t something I had tested at the time. And even if it was, the Idle was set to 0, which would still keep the weight of the walk animation at 1, meaning it shouldn’t blend.
That’s all I know of as I only tested it for a short time in an attempt to get it working with one of my projects, hope it was useful though.
Edit; By the way, you should really make priority’s be a number/integer. That way things like a punch barrage for a fighting game could simply add a +1 to the priority until the animations finished, which would solve a lot of issues.
Please do not force the animation blending fix to be permanent in phase 3!
My game relies on the current functionality and there is no workaround. I do not want animations blending overlapping keyframes when one is played over the other. I only want empty tracks to overlap.
Example: I have animation A and B, they are both the same priority (“action”). A animates just the legs. B animates all parts of the player. Players can use these animations individually, but if they chose to use them together I don’t want the legs in animation A and B blended, or they will be at unnatural angles! I want whichever animation was played second to override the previous animation. In the case that B is played first, I want the arms/torso/head to continue to play, and the legs to be overridden. There is no workaround for this! There is no other option to create this effect!
This feature is used to mix animations in the Roblox dance community without the limbs ending up in unnatural directions. It is a feature of my game Dance Your Blox Off (99+ million plays), and my group Focus Dance and Gymnastics (400k+ members). It will be a feature in all sequel projects in this line, as I only intend to make the animation system more complex and increase the possible animation combinations to give players the full freedom to enjoy a fully virtual dance experience.
Could we, instead, have a toggle when creating animations that allows us to chose between blend or override for that animation? This way the new functionality is fully applied, but a new rule is made for specific animations only.
Edit: Another possibility, allow us to change animation priority on runtime, so I can set the new animation at a higher priority with a script!
14 Likes
You are correct that this is a usage that does not quite fit the two intended methods of achieving the desired result. The two ways to do it that use the weight and priority API as intended (and that will continue to work as expected) are as follows:
You can have a hard separation of upper- and lower-body animations, so that you can freely play any combination of them, at the same priority level. This is the preferred solution for when all the available partial body animations make sense to have the same priority, e.g. they are all walk animations.
If the animations are not naturally the same priority, then you could have a partial-body animation play on top of a full-body animation, but that partial body animation would need to be a higher-priority track. This is the solution that’s preferred when it’s clear that the overriding animation has precedence. A typical example would be a full-body walk animation at movement priority, with a hand-waving emote that is upper-body only and temporarily overrides the upper part of the walk animation by being played at Action Priority.
So the question is: what is the best way to make your existing case compliant, and could we do that would make it the most painless. If the situation is that animations are already basically using higher-priority levels than usual (e.g. a walk is Action priority), it seems to me that the least work (for you) would require both an additional priority level above Action, and ideally the ability to override priority from Lua easily without having to republish all the animations. Is this accurate? IIRC, you have a lot of animations in the affected game, right?
The trouble with this one is that the current override behavior, which works most–but not all–of the time in a live game, is just a consequence of the order animations are getting evaluated. The underlying code doesn’t have a stack implementing priority based on playback time, it just happens that there was a bug in the math there newer animation weights were stomping over the weights of already-evaluated tracks, because of a math bug in the blending normalization. In the old system, evaluation order of the tracks matches Play() call order most of the time, because the list of active animations was never maintained sorted by priority for optimal speed.
I think too, that a checkbox for “override” is really just a different UI presentation for “play this animation at a priority higher than published”, so it makes the most sense to me to achieve the end result by allowing higher values of priority.
4 Likes
Bit of unintentional behavior I found with this recent update; I’ll leave a repro save file below (using Roblox’s public animations for this example.) Use the Studio Play option instead of the normal player option so that the animation replicates correctly.
When an animation over the priority of a currently playing animation is played, it will proceed as normal; up until the end of the animation, where the blending of it results in a strange ‘bounce’ effect. I’m seeing animations with the same priority acting as it should, however.
Note that this doesn’t seem to affect looped animations.
Intended effect:
Actual effect:
animation_blendingissue.rbxl (31.0 KB)
6 Likes
Thank you for this, I will take a look.
Just from inspection though, I can tell you that this is not an expected issue related to the blend fix (which is limited to same-priority tracks). I think there is something slightly off with the fade-in/fade-out behavior in this example.
2 Likes
Just to clarify, those of you who are seeing this “bounce” of the shoulder joints at the end of animations, is it only on R6 avatars?
2 Likes
I used the R6 rig since the global Roblox animations commonly only supported that rig. Though, I have seen this bug occur on every single rig I’ve seen, which includes R15, R6 and non default rigs.
1 Like
In the video I posted, you can see the idle animation skips frames, and the equip bounces.
Sure thing! You should receive it in your DMs.
This is correct I currently have over 150 animations with more on the way. Honestly, if I could just control animation priority with lua that would be fantastic. But I think it would require more than one additional priority level.
Say the player presses animation A and its at “action” priority, then they press B and I script it so that its at the next priority up from “action” (lets call that “super action” priority for lack of an actual term). What happens when the player presses animation C? There’s already an animation at a high priority playing. If I set C to “super action” priority, now I have limbs combining into unnatural angles again.
Players sequence these moves, sometimes very fast. I’d need enough priority levels to keep increasing the chain until all playing animations end, then I could set the priority back down again before the player restarts a chain. Would it be unreasonable to make priority an int value you can increase as high as you need to? (Essentially a Z Index for animations)
There’s a few problems with this.
- The issue above, we have a lot of animations. Separating everything would nearly double that count.
- Related to issue 1, we have everything keybound which means we can have 20 animations in one keyboard loadout. We don’t have the space to split animations from one loadout further than they are already split.
- If we did split them we’d have to remap a lot of the keybinds. This would require players to completely relearn the system.
- For future games this is a possible option but it still doesn’t give us the flexibility we currently have for player creativity.
Not going to work because this would prevent some animations from playing when the player presses a key, because a higher priority animation could already be playing.
We’re using the right priority levels for things like walk and idle (“movement” and “idle” respectively). Dance animations are on “action” priority and are all expected to behave at the same priority. They are of equal importance.
No, because they are overriding animations of the same priority because essentially every animation has the power to override every other animation. We need the order they are pressed to dictate their priority, with the last one played expected to play at the highest priority (and its the player, not me, who decides this order).
I might put together a video example of how this works, what our players do with it and why its so important to the community. Our players aren’t just playing a game, their participating in a digital art form. I don’t want to take away a tool they’ve started to rely on.
9 Likes
I can imagine on a larger scale (which it sounds like your game has) is a lot harder to deal with than something like what I’m going to have to fix. So many games have hundreds if not thousands of animations, and this is going to mean a lot of work for those games. Roblox REALLY needs to consider the repercussions of making this not backwards compatible.
While I think this update could work if priorities become integer values, I’d much rather see backwards compatibility, though I see why it isn’t feasible right now. I’m really annoyed that we’re going to have to update stuff again, though. I want to move on from my current project so having to retroactively fix it is certainly a hassle. I just wish there was some way the “standard” behavior without needing customized scripts for it. It has become “normal” after all.
5 Likes