This is cool, but there’s going to be so much chaos in Tools with older animation systems being broken, I cannot wait.
1 Like
Welp, this is gonna break every game I’ve ever made within the past few years. I appreciate performance improvements (however much of a non-issue they may be in real usage), but I would REALLY like current behavior to stay the same, and you aren’t even giving us more animation priorities! Four is not enough!! Make it an integer!!! As others have pointed out, the lack of animation priorities means that for a lot of people, setting priorities higher is simply not an option. I would also like to point out that Roblox default animations are the max priority, if I recall correctly. :upside_down_face (Edit)
As others have pointed out, there are some serious conflicts that arise with this. I predict it breaking a large number of games (as I said before, it breaks all of mine). Something as simple as, say, using the default animator script and having a tool play an animation is broken now. This “unintended behavior” was neglected for years, and has become standard within Roblox. This is not the same case as Filtering Enabled, which was a major security risk and did a lot to help Roblox save face. This is a performance improvement for something that is almost never a bottleneck.
I am okay with this changing, however conflicting it might be with priorities and use cases right now, I know hope Roblox will fix those things. I’m okay with this behavior being default, all I want is opt-out to remain. The legacy system can be left to rot, just let me use it. Bury it within game settings, display 15 warnings asking if I’m really sure I want to enable it, just please let me use it.
6 Likes
Looks like you didn’t even see what I said after this, you should scroll up before you assume things.
8 weeks to reupload thousands of animations if more priorities aren’t added when phase 3 rolls out, aka; literally as close to working at a sweatshop as you can get on this platform.
This is like saying the materials update is justified. Breaking thousands of games is not justified for an update. Unless there’s a reasonable way to fix it (more priorities), none of this is okay. You’re forgetting just how many animations RELY on that “bug” to work, when it was never said until now that it was unintentional and it’s gone unfixed for four years. People using it isn’t their fault if it seems intended.
2 Likes
I am well aware of what Roblox offers for free, and I am very appreciative of it, but that does not mean I have no right to give my thoughts on something. It is important for us to give feedback on what Roblox provides for us, even if it is negative.
I stand by my original point. I am not going to be a yes-man, as that provides nothing of value to them or myself.
You don’t see me bashing a lot of the updates, you don’t see me constantly ragging on display names or making videos about this one minor change and acting like it’s the end of the world, when ultimately doesn’t matter in the grand scheme of things. I actually talk very highly about some of the things that Roblox does, especially in terms of what they’ve been doing with the API and Lua environment, I think that stuff is amazing and they have been killing it in that department. But if I am dissatisfied with something Roblox is doing, I will say something about it.
You should also realize that Roblox is an online game platform with a game engine, and that Unity is just a game engine. When it comes to Unity, I can simply choose not to update to that version of the engine, but if Roblox updates something, I cannot stick to one version and one version only, I have no control over that.
6 Likes
You shouldn’t have to worry TOO much.
OP said that they’re going to push for more priorities (HOPEFULLY integer) before Phase 3 rolls out (and Phase 3 is the no-more-option part.)
While it’s not a guarantee, I imagine because of the backlash materials got, if this breaks a lot of games during Phase 2, there’d be similar backlash, so I’m confident we’ll get more priorities prior to that. It’s not ideal, but at least more priorities would make it possible to fix it semi-reasonably.
Listen. I understand your doing this change to help the platform overall and improve performance. But by making it not work with older animations, you have ruined thousands of games that still use this behavior as part of their core code.
And even if the developer who owns said game is there for it, they are not going to want to reupload possibly hundreds of animation tracks just so they work properly.
There should be a way to detect if an animation was created past a certain date, and if its played, make the old behavior come back for those animations, or at least, on older animations auto-disable blending to save games that can’t update.
Personally I already have several PAGES of animations for one game, and I can’t imagine the living hell it would cost someone to go through and reupload every, single, one, manually. No sane person wakes up one day and wants to reupload animations from sunrise to sunset. Not to mention the fact that as of right now, there’s only four options for priority.
Imagine you have a fighting game, where you click the mouse 6 times to do a little punching combo.
Each punch is a different animation.
After you get past the 3rd or 4th punch (WITH them reuploaded to be compatible with the new system mind you) they’ll start blending together, sense there’s no more priority’s for it to go through.
In short;
This was a good idea in someone’s head, but not in execution, at least so far. If you want to fix this, just make older animations that have no been reuploaded override other animations of the same priority. Otherwise it ruins countless games, and to fix them you either spends days reuploading content, or you let all the animations blend together into a horrible mess.
(*not to be rude here either, but how much of an fps boost is REALLY worth causing creators everywhere to go through the painful process of reuploading all their content in animations?)
6 Likes
This isn’t sustainable or supportable, like said above having multiple different ways of running the animation engine defeats the whole purpose. This is the same reason you can’t have old and new materials, its not supportable with the way Roblox stores material files.
That’s completely fine to share your opinions! (May have come off a bit harsh in that post, sorry! 
)
Fair.
Quickly correcting you here - The old materials and new materials will both be supported in the future. The backlash was so severe that Roblox ended up having to cave and allow for both to be usable. We don’t know the specifics, but they aren’t getting removed and both will be able to co-exist in some capacity.
2 Likes
In my opinion they could just add a setting to flick off “blending animations” under workspace or something.
It really shouldn’t be hard to tell the system that if there is no priority given, auto assign it, and if said priority is the same as an already running animation, play said animation on top of it instead, which would mimic the old system, thus solving the issue of it breaking games.
They said they were thinking about ways of supporting both sets of materials, they have not confirmed anything yet. As I said, the current way of supporting materials does not support MULTIPLE sets of materials. That’s why they were planning to remove the old set.
Like I said, this defeats the whole purpose of this system and does alot more damage in the long run, then good. See here from the OP;
AKA: Roblox can’t support 2 different systems (old way & new way) of running the animation engine in the long run.
2 Likes
I didn’t mean simultaneously. But we are confirmed to be getting both “accessible” for the foreseeable future. I imagine they can work simultaneously and they just would have different mapping, but I’m not exactly a tech-head in that regard so I’m not certain. I’m just saying we know they will be accessible in some capacity.
1 Like
This is really how it has to be. If any time Roblox added a new system they had to keep its predecessors around indefinitely in the current version of the engine, the codebase would grow explosively and very quickly become unmaintainable and unstable. “Just keep the old system available forever via a checkbox” isn’t a solution, it’s a pathway to bloatware hell and employee attrition, because no engineer would want to work in that codebase.
12 Likes
It has been my experience that if you change priority when playing an animation on the client, it will not replicate that priority to the other clients (this also happens with animation speed)
So that other clients see your animation play differently.
Will this or has this been fixed, considering your option number 3 is changing priority via code?
Thanks for putting this on a temporary property, I really appreciate this rollout strategy. Happy to report that nothing in my game is broken by this change. Something hacky I was doing to implement neck turning animations behaves a little bit funny now, but I’m phasing that code out anyway. This change actually simplifies some things I’ve been meaning to do with respect to a custom animation manager.
I think changing the enum to a simple integer priority will solve the majority of any other issues I might see arise because of this change. It’s just unfortunate that priority is not a trivial thing to change on the asset page, and changing it via code does not replicate properly. Updating animations if necessary is very tedious because of the workflow required to find animations to import and re-export them.
4 Likes
If we’re talking about animation bug fixes, what about the fact that changing properties of animations in runtime DOES NOT pass the client-server barrier? Also, you cannot change animation priority because, again, this does not replicate from the server to the client currently (and vice versa). So I do not understand the solution here.
The animation blending feature is something I have been wanting for years! Thanks for the upcoming update!
I am not sure what is animation blending (yet), but I will learn it, just as IK!
If performance is improved, that’s gonna a big yes for my game. It requires a bunch of rigged parts, on a laptop 
Unless it’s not what I am hoping for.
I worry mostly because, OP said “before phase 3,” but that doesn’t necessarily mean we’ll be given ample time to effectively port (I don’t think 8 weeks is enough either but I digress.) The fact that this was announced before more priorities and replicated priority levels have been added (which OP only announced when the concern was brought up, least this is the first time I’ve heard it confirmed in any way) leads me to believe this is being somewhat rushed.
I really hope the backlash pushes them into adding something like Animator.BlendBehavior = Enum.BlendBehavior.Overwrite/CombinedWeight at least. 
5 Likes
Very doubtful. Sorry but the backlash is nowhere near bad enough for the engineers to seriously consider backwards compatibility - this year is just gonna be the year of backwards incompatible updates, as it seems they’ve realized it’s best to push for everything now rather than later - the best time to have done so would’ve been 5 years ago, but the second best time is now.
8 Likes
If Roblox were super cautious, making sure not to break old api and systems, then there would be very little progression in the entire engine, I get that this is super annoying to deal with, I myself will have to go through all my previous and current games to update to the new engine (although not on the severe scale that you will), but in the grand scheme of things, its moving the platform forward and you gotta just buckle down and deal with it.
I think your best bet right now is for this to be a property you can toggle, like how it currently is but permanently.
5 Likes