Bool Parameter does not persist through deactivation/reactivation -- except if set in Editor!

For some reason, when I set a bool mecanim parameter as "true" through code, that setting disappears (becomes false) upon deactivating/reactivating the object through code with SetActive(). HOWEVER, if that parameter was set to "true" through the state machine editor (and then deactivated/reactivated through code), its setting persists through both deactivation AND reactivation (in my case, this is the desired behavior -- except I want it to do this through code too!)

Any idea how to get the setting through code to persist through deactivation/reactivation too?

Or is this a bug?

If so, is there any workaround? (I'm using 4.6.1 if that helps!) I need it to be able to remember the bool setting from code in order to fork my state transition at the start of the animation the next time it plays (i.e. after being reactivated). I'm playing an intro animation only once, then it should transition directly to the other animation state every time after that (upon being reactivated), making this decision initially upon gameobject reactivation!

 

I believe this is a known issue. @Mecanim.Dev should be able to confirm.

 

I started a conversation with him with the same title as this topic.

Not sure if that's the right/fastest way to go about reporting this, but I can't find any issues on the unity issue tracker that even remotely relates to this Bool Parameter / SetActive(false); issue, therefore I'm not sure if it is indeed a known issue or not.

It definitely is an issue though -- and I need a work around ASAP.

Though, since mecanim is a closed system, I don't know how much I can do... if anything at all. D:

 

I doubt you'll find it in the bug tracker, as one could claim that it's "by design." Although, if I remember correctly, I think they're planning to change this in a future version.

For a workaround, you can use a script this like:

Code (csharp):

1. public class SaveTheBools : MonoBehaviour {
2.  
3.     public string boolName;
4.  
5.     private Animator animator = null;
6.     private bool boolValue;
7.  
8.     void Start() {
9.         animator = GetComponent<Animator>();
10.         if (animator != null) boolValue = animator.GetBool(boolName);
11.     }
12.  
13.     void OnEnable() {
14.         if (animator != null) animator.SetBool(boolName, boolValue);
15.     }
16.  
17.     void OnDisable() {
18.         if (animator != null) boolValue = animator.GetBool(boolName);
19.     }
20. }

This saves the bool just before you deactivate the GameObject, and restores the value when you re-activate it. Pardon typos; I typed this straight into the forum editor, so I also haven't tested it for all cases. For example, I'm not sure what happens if the Animator gets disabled before this script does.

 

@ToniLi

Thank you for that workaround. To avoid the Animator getting disabled first, I had to move it below the calling script (otherwise I got an error/warning about parameters -- which can't be checked whether they exist or not). I had completely forgotten about the OnEnable/Disable events. They work for my case for right now, but I really hope Unity fixes such an obvious bug. I would hope they wouldn't use that whole "it's by design" thing. That is such an obvious cop-out for such wildly inconsistent behavior.

@Mecanim Devs (if you guys are reading this):

This bug should probably raise a flag that Mecanim is too walled-in. Just the fact that people still use the old animation system because it's easier to understand and work with should be a solid case that Mecanim really does need some reworking in the "consistency / accessibility" department -- (more akin to the new GUI system treatment in 4.6 where it was made open-source and also more consistent with standard workflows in Unity by using gameobjects for the gui, in which something similar could be done with Mecanim to allow it to be more malleable and standardized w/the rest of the Unity interface.)

Logic-driven animation, for example, is such a vital part of modern interactive applications, and yet, because Mecanim is such a walled-garden, this is painfully hard to accomplish a lot of the time. Attaching behaviors to states is a great first step in Unity 5, but the Animator is still a black-box in cases where you might want to modify its internal behavior (or add your own -- which might potentially even be completely decoupled from any Animation at all!) -- while retaining the ability to set and even define states and parameters -- through code if desired -- to go alongside Mecanim's native state logic flow.

Without a core logic state machine to couple with the animation state machine, what you end up with is a ton of bastard-child code to handle logic used alongside Unity's Mecanim to handle animation, tossing parameters and blendtrees to the side (except in cases where they're *really* needed, which, until Unity 5, used to require me to Frankenstein all other systems together somehow with Mecanim -- if possible -- or write my own sub-par version of Mecanim if it wasn't.)

I love Unity, but this could be SO much better if you could seamlessly provide the comfort and control of a native state system like Mecanim while still allowing users to modify its functionality through code -- even down to individual curves -- if we wanted to.

Not complaining -- Just offering some food for thought!

 

This is not a bug, this is by design.

You setup the default value of all you parameters in the editor, when your game object is enabled everything is reset to the default value: parameter, state machine current state is reset to the default state.

There is no built in workaround for this. But it should be easy to write a small script based on a scriptable object that push and pop all your parameter value on enable and disable like @TonyLi did.

As a service we could add a new feature for the animator. Something like Animator.keepCurrentState that would keep all the internal data. The reason why you lose everything on enable/disable is because normally in unity when an object is disable it does free all the resources used by the gameobject: memory, asset, handle, etc...

 

Yes, that service would be MUCH appreciated by new users (and old users alike!) -- also, maybe consider offering a way to set what data you want to preserve between de/re-activation (to keep things optimized, since optimization was the key reason I was de/re-activating my gameobjects to begin with!)

In my case, I used the state editor to debug my code, so I thought (for weeks) it was somehow my own code having the "bug" somewhere in it, and wasted a ton of time until I (finally) gave up and came on here. Even when I did, nobody seemed to know whether this was a bug or intended behavior -- which is a huge problem for Unity's "user-experience" side of things.

To me, this really did seem like a bug (it's inconsistent with the mecanim editor's de/re-activation behavior after all), and anyone not familiar with the internals of Unity (i.e. a non-Unity-Dev) would expect the same thing ( i.e. it's a bug in their own implementation, or after thorough bug-testing, mecanim is working but SetActive or SetBool is broken somehow.)

I love Unity -- it's an amazing platform! -- but tiny quirks like these need TLC too! -- (otherwise frustration ensues! D

 

I have a question about this that I've posted
http://forum.unity3d.com/threads/unity-manual-howto-uiscreentransition-problem.329222/

Is there any way to call SetActive(false) and then have the state machine re-enter where I deactivated the object?

I would like to be able to call SetActive(false), but it seems that even if I cache the bool parameters, the statemachine will re-enter into the orange state and not the state where I called SetActive(false).

Is there any way to do this? I would like to be able to call SetActive(false) on UI elements that exit the screen, but they have to re-enter from the direction that they exited

 

you need to save the current state before calling SetActive(false) with
http://docs.unity3d.com/ScriptReference/Animator.GetCurrentAnimatorStateInfo.html
http://docs.unity3d.com/ScriptReference/Animator.GetNextAnimatorStateInfo.html

If you have more than one layer you will need to save the current state of each layer

and when you reactivate the animator you will need to set the current state with
http://docs.unity3d.com/ScriptReference/Animator.Play.html

 

thank you, I was missing Animator.Play. This is great

 

@Mecanim.Dev - I tried implementing a hybrid solution for keeping Animator state across disable/enable via a script like @TonyLi but calling the GetCurrentAnimatorStateInfo() function. Something like this:

Code (CSharp):

1. public class SaveAnimatorState : MonoBehaviour {
2.  
3.    public AnimatorStateInfo animatorStateInfo;
4.  
5.    private Animator animator = null;
6.    private bool saved = false;
7.  
8.    void Start() {
9.         animator = GetComponent<Animator>();
10.    }
11.  
12.    void OnEnable() {
13.        if (saved && animator != null) animator.Play(animatorStateInfo.shortNameHash);
14.    }
15.  
16.    void OnDisable() {
17.        if (animator != null) {
18.            animatorStateInfo = animator.GetCurrentAnimatorStateInfo(0);
19.            saved = true;
20.        }
21.    }
22. }

However, I find that the AnimatorStateInfo struct that I get back in line 18 has 0 for all of its members - this doesn't seem like a valid state - is it? One thing to note - my state machine is a pure state machine, that is, it has no animations/avatar. Does this type of state machine not return a valid GetCurrentAnimatorStateInfo()? Or is calling this inside OnDisable() too late?

Any help would be greatly appreciated. For now, I am using a variable outside of the state machine to track what state it's in and then I call animator.Play("stateName"), but it would be best if I could get that information from Mecanim somehow instead of duplicating the information in my class.

 

+1 for making this configurable. In my experience the use case of wanting to keep the bools happens more often than the complete reset case.

Here's the little wrapper I ended up with:

Code (CSharp):

1. public class AnimatorBoolSaver : MonoBehaviour
2. {
3.     private Animator _animator = null;
4.     private Dictionary<string, bool> _boolValues = new Dictionary<string, bool>();
5.  
6.     public void SetBool(string boolName, bool value)
7.     {
8.         _boolValues[boolName] = value;
9.         if (_animator != null)
10.         {
11.             _animator.SetBool(boolName, value);
12.         }
13.     }
14.  
15.     private void Awake()
16.     {
17.         _animator = GetComponent<Animator>();
18.     }
19.    
20.     private void OnEnable()
21.     {
22.         if (_animator != null)
23.         {
24.             foreach(var keyValue in _boolValues)
25.             {
26.                 _animator.SetBool(keyValue.Key, keyValue.Value);
27.             }
28.         }
29.     }
30. }

 

This is not yet configurable, right? Would be a nice option as we have had problems with this....

 

I've been looking around and found no acceptable working solution for general Animator loss of state/params when disabling the gameobject.
@Mecanim-Dev: Removing the Animator data when disabling parent gameobjects sounds strange to me as this is convenient way to reduce overhead, in which case it should not immediately mean *removing* the object resources, after all wouldn't you be destroying the gameobject if you want that ? (or is that like a Unity no mem leakage absolute rule ?)
Anyways, while writing my own AnimatorStateSaver, I've hit the same problem as virtra_asilva with the null animator.GetCurrentAnimatorStateInfo(0) in the OnDisable event method. Even setting a very low script execution order doesn't change that. So my guess is that the Animator instance is cleaned up even before OnDisable events are handled.

Eventually I think the lesser evil would be to call a static function to save the animation data before disabling a gameobject here's the code:

Code (CSharp):

1. using System;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. /// <summary>
6. /// Saves Animator state and restores it automatically when the object is activated
7. /// Code must explicitly call Reset() to reinit the animator,
8. /// and call AnimatorStateSaver.SaveAnimStateRecursive() before deactivating any parent
9. /// </summary>
10. public class AnimatorStateSaver : MonoBehaviour
11. {
12.     private AnimatorStateInfo _savedAnimatorStateInfo;
13.     private AnimatorControllerParameter[] _savedParameters;
14.     private Dictionary<string, System.Object> _savedParameterValues = new Dictionary<string, System.Object>();
15.     private Animator _animator = null;
16.     private bool _isSaveAvailable = false;
17.  
18.     public static void SaveAnimStateRecursive(GameObject pGameObject)
19.     {
20.         AnimatorStateSaver[] animatorStateSaversArray = pGameObject.GetComponentsInChildren<AnimatorStateSaver>(false);
21.         for(int i=0; i<animatorStateSaversArray.Length; i++)
22.         {
23.             animatorStateSaversArray[i].SaveAnimState();
24.         }
25.     }
26.  
27.     public void Start() {
28.         _animator = GetComponent<Animator>();
29.         Debug.Assert(_animator != null);
30.     }
31.  
32.  
33.     public void OnEnable() {
34.         if (_isSaveAvailable && _animator != null)
35.         {  
36.             _LoadParams();
37.             _animator.Play(_savedAnimatorStateInfo.shortNameHash);
38.         }
39.     }
40.  
41.  
42.     public void SaveAnimState() {
43.         if (_animator != null)
44.         {
45.             _savedAnimatorStateInfo = _animator.GetCurrentAnimatorStateInfo(0);
46.             _SaveParams();
47.             _isSaveAvailable = true;
48.         }
49.     }
50.  
51.  
52.     public void Reset()
53.     {
54.         _isSaveAvailable = false;
55.     }
56.  
57.  
58.     private void _SaveParams()
59.     {
60.         _savedParameters = _animator.parameters;
61.         for (int i=0; i<_savedParameters.Length; i++)
62.         {
63.             switch(_savedParameters[i].type)
64.             {
65.             case AnimatorControllerParameterType.Bool:
66.                 _savedParameterValues[_savedParameters[i].name] = _animator.GetBool(_savedParameters[i].name);
67.                 break;
68.             case AnimatorControllerParameterType.Float:
69.                 _savedParameterValues[_savedParameters[i].name] = _animator.GetFloat(_savedParameters[i].name);
70.                 break;
71.             case AnimatorControllerParameterType.Int:
72.                 _savedParameterValues[_savedParameters[i].name] = _animator.GetFloat(_savedParameters[i].name);
73.                 break;
74.             case AnimatorControllerParameterType.Trigger:
75.             default:
76.                 // we don't care
77.                 break;
78.             }
79.         }
80.     }
81.  
82.     private void _LoadParams()
83.     {
84.         for (int i=0; i<_savedParameters.Length; i++)
85.         {
86.             switch(_savedParameters[i].type)
87.             {
88.             case AnimatorControllerParameterType.Bool:
89.                 _animator.SetBool(_savedParameters[i].name, (bool)_savedParameterValues[_savedParameters[i].name]);
90.                 break;
91.             case AnimatorControllerParameterType.Float:
92.                 _animator.SetFloat(_savedParameters[i].name, (float)_savedParameterValues[_savedParameters[i].name]);
93.                 break;
94.             case AnimatorControllerParameterType.Int:
95.                 _animator.SetFloat(_savedParameters[i].name, (int)_savedParameterValues[_savedParameters[i].name]);
96.                 break;
97.             case AnimatorControllerParameterType.Trigger:
98.             default:
99.                 // we don't care
100.                 break;
101.             }
102.         }
103.     }
104. }
105.  

with this:
* in the editor, place an AnimatorStateSaver component on every Animator gameobject that you want to save
* call SaveAnimStateRecursive(yourGameObject) before deactivating any parent gameobject
* animation restore is automatic
* call yourAnimationStateSaver.Reset() to discard current state/params backup

Limitations:
* as you can see this only handles animation on layer 0,
* it does not save progress in the animation itself, just the state it's in
* don't overuse this, as GetComponentsInChildren and therefore SaveAnimStateRecursive() are slow
* only tested for UI stuff and bool params

 

Experiencing same problem.
Just place your script above Animator component, So it will receive OnEnable event before Animator component.

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3. using System.Collections.Generic;
4.  
5. public class AnimatorKeeper: MonoBehaviour
6. {
7.     private class AnimatorParameterValue
8.     {
9.         public AnimatorControllerParameterType m_Type;
10.         public float m_Float;
11.         public bool m_Bool;
12.         public int m_Int;
13.     }
14.  
15.     private class AnimatorLayerState
16.     {
17.         public int m_ShortNameHash = 0;
18.         public float m_NormalizedTime;
19.     }
20.  
21.     private Animator m_Animator;
22.  
23.     private Dictionary<int, AnimatorParameterValue> m_Parameters;
24.     private AnimatorLayerState[] m_LayerStates;
25.  
26.     private void Init()
27.     {
28.         m_Animator = GetComponent<Animator>();
29.  
30.         m_Parameters = new Dictionary<int, AnimatorParameterValue>();
31.         foreach(AnimatorControllerParameter acp in m_Animator.parameters)
32.         {
33.             if(acp.type != AnimatorControllerParameterType.Trigger)
34.             {
35.                 AnimatorParameterValue apv = new AnimatorParameterValue();
36.                 apv.m_Type = acp.type;
37.                 m_Parameters.Add(acp.nameHash, apv);
38.             }
39.         }
40.         m_LayerStates = new AnimatorLayerState[m_Animator.layerCount];
41.         for(int lidx = 0; lidx < m_LayerStates.Length; ++lidx)
42.         {
43.             m_LayerStates[lidx] = new AnimatorLayerState();
44.         }
45.     }
46.  
47.     private void OnEnable()
48.     {
49.         if(m_Animator == null)
50.         {
51.             Init();
52.         }
53.         if(m_Animator != null)
54.         {
55.             foreach(KeyValuePair<int, AnimatorParameterValue> kvp in m_Parameters)
56.             {
57.                 switch(kvp.Value.m_Type)
58.                 {
59.                 case AnimatorControllerParameterType.Bool:
60.                     m_Animator.SetBool(kvp.Key, kvp.Value.m_Bool);
61.                     break;
62.                 case AnimatorControllerParameterType.Float:
63.                     m_Animator.SetFloat(kvp.Key, kvp.Value.m_Float);
64.                     break;
65.                 case AnimatorControllerParameterType.Int:
66.                     m_Animator.SetInteger(kvp.Key, kvp.Value.m_Int);
67.                     break;
68.                 }
69.             }
70.  
71.             for(int lidx = 0; lidx < m_LayerStates.Length; ++lidx)
72.             {
73.                 m_Animator.Play(m_LayerStates[lidx].m_ShortNameHash, lidx, m_LayerStates[lidx].m_NormalizedTime);
74.             }
75.         }
76.     }
77.  
78.     private void OnDisable()
79.     {
80.         if(m_Animator == null)
81.         {
82.             Init();
83.         }
84.         if(m_Animator != null)
85.         {
86.             foreach(KeyValuePair<int, AnimatorParameterValue> kvp in m_Parameters)
87.             {
88.                 switch(kvp.Value.m_Type)
89.                 {
90.                 case AnimatorControllerParameterType.Bool:
91.                     kvp.Value.m_Bool = m_Animator.GetBool(kvp.Key);
92.                     break;
93.                 case AnimatorControllerParameterType.Float:
94.                     kvp.Value.m_Float = m_Animator.GetFloat(kvp.Key);
95.                     break;
96.                 case AnimatorControllerParameterType.Int:
97.                     kvp.Value.m_Int = m_Animator.GetInteger(kvp.Key);
98.                     break;
99.                 }
100.             }
101.  
102.             for(int lidx = 0; lidx < m_LayerStates.Length; ++lidx)
103.             {
104.                 AnimatorStateInfo asi = m_Animator.GetCurrentAnimatorStateInfo(lidx);
105.                 m_LayerStates[lidx].m_ShortNameHash = asi.shortNameHash;
106.                 m_LayerStates[lidx].m_NormalizedTime = asi.normalizedTime;
107.             }
108.         }
109.     }
110. }
111.  

 

Seems like a configurable version of the SetActive should exist as a command-set or have flags or something. Being able to call SetActive(false , bool,myClass,etc.); should be possible imo with a single call to allow you to keep a particular set of data active despite the rest of the object being deactivated.

 

Just curious if this was ever solved with an update as I hit the problem. I have anims to transition UI pages in and out and want to be able to hide and reveal them without it triggering the default transitioning anim. It really seems that this optimisation of clearing out things should be the exception rather than the rule. Freeing and reallocating stuff like this could stress the GC too.

 

If you disable only the animator component it should keep all the current state/ parameters and the component won't get ticked anymore by the engine so it won't consume any cpu but it will left the memory as is.

https://docs.unity3d.com/ScriptReference/Behaviour-enabled.html

Not at all, in this case the memory is allocated by the native side of the engine so there is no GC involved

 

@Mecanim-Dev

Is there any consideration about the configurable/customizable SetActive() call mentioned in the above post by myself?

I feel that this would really help with general enable/disable issues, which Unity definitely has when you consider all the overhead the developer has in managing optimization over loads and loads of various types of specially-programmed gameobjects across many spectrums of functionality.

Could you at least pass this request along to the dev or team responsible for its general implementation, if it were considered?

 

If you have an idea or you would like to give us feedback please do use the proper channel for it so we can at least track it and see if others agree with you.
https://feedback.unity3d.com/

Giving feedback in a two years old thread in the animation forum has a low chance to get noticed.

 

So I assume it won't be changed and is not a reasonable option to have in Unity? Can't just disable the animator as I need to also hide all the children that are animated. I guess I could introduce a single "frame" object parent under the anim object that I can disable instead but I can't do that without needing to then fix all the existing anims. Perhaps a plan for my next project but feels a real faff!

From my side, I've looked into the feedback system and it amazes me that anything comes from such a convoluted jumping-through-hoops system. Limited votes so you can't actually canvas all opinions?!!

P.S. If it's not a GC issue then surely there's an overhead for reallocating and filling the data on enabling. I would have thought the option to not do this would be a good optimisation option.

 

Never says never, it on our roadmap since a long time but we never had the time to actually implement it as there is always more important stuff to do.

 

The sad thing is there will always be more important things to do.

I do agree with @Nodrap that the limited vote system is very prohibitive. Even a simple "like/dislike" system would be loads more effective.

This is the exact reason I asked for help in passing the customizable SetActive along -- there are just so many major Unity features that are incomplete (Timeline [no animation or Timeline events] and even Mecanim [no generic skeleton/bone retargeting or texture swapping in the animations] -- and those are only two very basic systems right of the top of my head that are clearly not ready for primetime).

I totally get you guys' workload is impossible, but it would help if people could at least get the features that suit the common workflows of the industry(s) instead of some endless arbitrary feature list that I or anyone else suggests at a whim. The list you guys have now should be for wish list stuff and anything in the meantime should be about polishing the features you currently have, including adding features that complement (or complete!) existing feature sets (Timeline, I'm looking at you!)

 

It is very annoying me about using GameObject Pool.

All re-active GameObjects are recreate their Animator's StateMachineBehaviour script.
It makes garbage and It needs re-bind their callbacks.

 

Would you look at that.

Available in 2018.1, sometime.

 

Woohoo! -- Something I requested actually made it in!!??

I wonder... is Unity.... actually...(gasp!)... listening to us...? D:


We did just get Probuilder as part of the standard Unity package... Maybe all my hopes and dreams are not for naught... Maybe they really /are/ taking steps to fix some of these longstanding issues. Keep up the good work Team Unity! -- I'm looking forward to more awesomeness from you this year!!

 

we are always listenning to you guys, but we have over ~2 millions users each having different need and request so we can't make everybody happy.

 

If this is in response to the tone of my previous comments, I hope you'll please reread the last paragraph again.

Regarding my sarcasm, I just wanted to point out that it was directed at the fact that lately I have been noticing a LOT of highly-requested things finally making their way into Unity -- including things I've personally requested. My comment and sarcasm was actually intended to praise you guys for legitimately taking on such an impossible task and still working as hard as you can, ultimately doing your best to accomplish this very thing -- i.e. trying to please everyone -- despite the very nature of such a task being ludicrous and impossible. That was intended as acknowledgement (though poorly worded I see now) of how great you guys are, and also intended as a way of saying "thank you" as well.

The fact that you guys work so hard on this means a lot to me (and to a lot of other users I know!), so I apologize for how my comment came across. I really did mean to sound sarcastic, but the sarcasm was meant to point out the contradiction to the common thinking that if we request a feature, nothing will ever happen. In fact, as I already stated, you guys recently integrated Probuilder and have otherwise been doing a lot of service to your users over the past couple of years, so that sarcasm wasn't pointed at what you /haven't/ done -- on the contrary, it was actually meant to point out what you guys /have/ done for us.

Granted, I did state there were lots of longstanding issues, but (as I also stated) I feel like you guys are already taking steps to address these as well. For example, I noticed a menu bug was fixed in the 2018 beta the other day that nobody had ever reported. This helped me directly and I didn't even have to say a thing about it to you guys!

I know you guys get a LOT of flack for "not listening to us" by many people, but I for one understand that we do ask of you guys a lot more than you are reasonably able to give sometimes. I hope you understand that I did not intend to make you feel like your work on getting the feature I requested in was not appreciated, nor did I intend to make you feel like what you guys do (once again) went unnoticed. I can assure you that the longstanding Unity users like me do highly appreciate all of the little things you guys are willing to do for us.

So I hope it's clear that what I meant to say was -- thank you.

 

Could this feature be visible in the Animator Component GUI? Shouldn't be hard as it is already serializable and visible/editable in debug mode.

 

Yes please, do not hide it in the debug inspector. This is a much needed feature for UI work.
Glad that it's finally available anyway, and thanks Baste for making us aware of it!

 

Thanks so much, this worked perfectly!

 

Happy finding that `keepAnimatorControllerStateOnDisable` has been added to the Animator, but it really should be set to true by default.

My opinion is that it goes against all the other Unity designs to have something lose data or lose a state because it is disabled and doesn't match any other Unity usage pattern. Objects are disabled as a temporary measure and expected to resume where they were when enabled - and this is true everywhere else in Unity components. Anything counter to that would be an anti-user design paradigm.