I have a GameObject with an Animator component. Totally works fine until… I disable and then (later) re-enabled the game object via SetActive calls. When the object is re-enabled, all the state of the Animator component is lost.
Is there any way to retain the Animator state??
This is the expected behaviour but we would like to change this.
Until we do this you need to save manually the state of the controller.
For each controller layers you need to save the current and next AnimatorStateInfo
Also you may need to save all the parameter values.
When you are ready to active your animator you will need to push back all this information
Thanks for the quick reply! I’ll get started writing a component for that.
Out of curiosity, why is it implemented that way? It implies that best practice for Unity is to never disable an Animator. Is that so? If that is true - should I be arranging my project in some different way?
Because it the standard in Unity, when a object become disable it has to free all the resources that it is using: asset, file, memory used, etc …
I just experienced the same issue and was surprised that the animator loses its state when it’s disabled. My scripts all seem to pick up where they left off when I reenable them, so I expected it to work the same with the animator. I’m looking forward to a fix for this.
Mecanim.Dev, this only works on Unity5 correct? If I’m not mistaken, Unity4’s API doesn’t allow us to fetch parameters…
yes you can do it in unity 4 too but you need to know at runtime what are the parameters to save, either you hardcode them or you build a dictionnary in the editor with all the parameter you would like to save
Animator.GetBool()
Animator.GetFloat()
I think it should be explicitly stated in documentation.
Unity - Scripting API: Behaviour.enabled — it says nothing about it.
I do Unity development for several years and I learned this from you now.
It looks like innocent boolean flag and it may ruin state of your object completely. It feels wrong.
I’ve never met this behaviour in Unity in other places. Can you show some more examples of MonoBehaviour subclasses which unload their state on Disable and don’t load it on Enable?
Yikes. Enable and disable have never cleared state on monoBehaviours or models for us… We use enabling and disabling heavily for our project and all state and assets persist for us.
This issue with the animator is now affecting us too for enabling and disabling.
Problem is that now that StateMachineBehaviours are in the mix - SMB’s are great for making new instances of prefabs when you enter a state. I need to make sure I don’t create another one just for this enable / disable case.
Hey Mecanim.Dev, it looks like this still hasn’t been fixed. I’ve put together a script per your suggestion, and it does seem to work. (I’m not bothering with using CrossFade with the NextAnimatorStateInfo, but I assume that works too).
One issue for folks to remember: Components are disabled in order from top to bottom in the inspector. If your script that’s trying to save state is below the animator, trying to save the state / parameters will not work!
Also, keep in mind that calling animator.parameters won’t get the current values! It will only fill in the default values, and it’s up to you to save the current parameter values yourself. If you want to save the value of a trigger, you’ll need to use GetBool, and then Set/ResetTrigger.
Seriously, how is still not fixed?
Why would anyone want to reset state when disabling an object? Restoring a complex animator while keeping script execution order is a major task and shouldn’t be necessary.
Year and half later this is not changed. Any updates?
The behaviour won’t be changed, unfortunately we must keep the backward compatibility with existing project and many project rely on the fact that disabled GO hierachy don’t consume any memory.
What we want to do is provide an API that would allow you to save the current state of the animation system and we are still working on this
I’d just like to chime in here and ask that this be fixed. I don’t understand the explanation: Objects that are disabled surely consume memory, for the state that they retain on all of their components. I’ve never had the expectation that disabling an object in the hierarchy would free up memory, other than perhaps textures or other assets.
But we’re talking about component data here, or what’s at least conceptually component data. I would hope that the current state of an animation tree is perhaps a few hundred bytes at worst, and I think on balance, it’s totally reasonable to spend a few hundred bytes to keep whatever chunk of memory you’ve allocated around while an object is disabled, so that this component behaves like every other component in Unity.
At very least, please provide a checkbox somewhere to “keep state on disable” or something like that, rather than requiring developers to use an API so they can make this component behave like every other component seems to behave.
I’m jumping on this one too.
It might internally be unity’s internal design philosophy but from the developer perspective this rears it’s head as unexpected behaviour.
A boolean value that defaults to true with “keep state on disable” could be added and be defaulted to false for old projects. It could even have a default setting in projectSettings.asset to cover dynamically added animators.
As it stands the current behaviour is just a bug waiting to happen for anyone who hasn’t experienced it before, and a headache for those who have.
Any update on this? In my opinion this is a bad design decision on the user point of view because it is counterintuitive, it is expected when an object is disabled and then reenabled it should be exact the same way it was when disabled. Do velocity on rigidbodies reset when disabling? No.
The expected behaviour should be the object to retain all of its states during disabling and enabling.
I’m my opinion this is a bug and should be adressed.
Mecanim.Dev how do you restore state properly if the animation was in a transition? Like, i know you can save and reset all the parameters, and that you can set the currently playing state (and time in that state) with Play(), but what if the animation is currently transitioning when you are saving?
Incidentally, I agree with other posters that this is very unintuitive that the animator loses all state on disable/enable, since this is not the case for the vast majority of Unity components. There should be a checkbox or something to change this behavior. At the very least, there should be a simple pair of methods like GetFullAnimatorState() that returns some (possibly opaque) object representing ALL animator state, paired with a RestoreFullAnimatorState(), so it’s easy to do this yourself, just save in OnDisable() and restore in OnEnable().
This thread popped up again, and what? What do you mean that disabled GO hierarchies doesn’t consume any memory? They totally do. They don’t magically go away from memory once they’re not visible.
People are expecting the Animator to function like all of the other components in Unity, and not just randomly dump all user data due to getting their GO turned off. MonoBehaviours doesn’t lose their state when they get disabled. Colliders doesn’t lose their state when they get disabled. NavMeshAgents doesn’t lose their state when they get disabled. The animator does!
You would be breaking projects that rely on deactivating and reactivating the objects in order to reset the animator if you fixed this. That could be easily fixed by just exposing a method to reset it, which doesn’t exist right now.
Also, you don’t have to be backwards compatible! Unity is in no way backwards compatible in any way shape of form! Every major version change breaks something. Refusing to fix a broken feature due to backwards comparability would be yet another thing that the animator would be doing completely different from the rest of Unity!
Please, don’t spend a bunch of time creating tools that your users can use to work around the animator breaking when it’s GO gets turned off. Just fix the bug!
I also ended up here now after several hours of trying to figure out what happend there. Does anyone already have a workaround for this problem?
Same issue here…