Search Unity

Different between gameobject.active and gameobject.SetActive();

Discussion in 'Scripting' started by Gaspedal, Aug 15, 2018.

  1. Gaspedal

    Gaspedal

    Joined:
    Mar 29, 2009
    Posts:
    369
    What's the different between gameobject.active and gameobject.SetActive() ??

    I have tested both and works fine. which is better?
    thx
     
  2. RavenOfCode

    RavenOfCode

    Joined:
    Apr 5, 2015
    Posts:
    866
    Use SetActive as .active is a deprecated function. Not sure what the technical difference is, but it's not recommended to use .active.
     
    Gaspedal likes this.
  3. Gaspedal

    Gaspedal

    Joined:
    Mar 29, 2009
    Posts:
    369
    thanks! I'll update my code to using SetActive only. :)
     
  4. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,977
    This is a remnant of a very old Unity functionality.

    Back in Unity 3, setting the 'active' property of a GameObject didn't necessarily disable all its children as well. Instead you had to call the method 'SetActiveRecursively' to disable a GameObject and all its children. This wasn't very intuitive, and the state of children couldn't be maintained when enabling or disabling parent objects. It was an all or nothing fair.

    So in Unity 4 they changed the behaviour so that if a parent GameObject was disabled, its children were. This allowed you to have some children disabled, and some children enabled, and toggling the parent wouldn't change that.

    But this also changed the meaning of 'active'. Is the GameObject disabled because IT is disabled... or is it because the parent is disabled and that cascaded down on itself.

    So unity introduced 2 new properties:
    'activeSelf' - https://docs.unity3d.com/ScriptReference/GameObject-activeSelf.html

    'activeInHierarchy' - https://docs.unity3d.com/ScriptReference/GameObject-activeInHierarchy.html

    Where activeSelf tells you what the GameObject is set to, regardless of the parent. And 'activeInHierarchy' is the effective state of it (its activeSelf and the impact of any parent object on it).

    'active' and 'SetActiveRecursively' was thusly deprecated, marked obsolete. Unity doesn't just immediately throw out old methods, they just deprecate them. This is a common practice in maintaining a framework over the lifetime. It's similar to why the 'rigidbody' property technically still exists on Component.

    ...

    As for why they didn't just make 'activeSelf' read/write instead of requiring calling 'SetActive'... well. From a design perspective there are arguments for it. A common argument amongst C# programmers is that if your property does extra work when its value is 'set', you should have that marked as a method rather than as a setter. This way the user understands more is going into this action than just modifying the state of that property (in this case, children are effected as well).

    BUT... it's not like Unity follows this standard consistently.

    So, I would argue, it's just Unity being its usual nonsensical self... and just accept the strange inconsistency of their interface design for what it is.

    tldr;

    'active' and 'SetActiveRecursively' are deprecated, should be avoided all together (for both read and write).

    They are remnants of a time long passed when GameObject hierarchies behaved differently than they do now.

    Use 'activeSelf', 'activeInHierarchy', and 'SetActive' instead.

    Unity is weird.
     
  5. Gaspedal

    Gaspedal

    Joined:
    Mar 29, 2009
    Posts:
    369
    @lordofduct

    Thank you for your great infos about new active functions. I'll take a look to "activeSelf" and "activeInHierarchy" too.

    I have restarted with unity again a new project and my last project I have developed 2013. A long time and a much of new functions. Even java is dead. ^^


     
  6. Deleted User

    Deleted User

    Guest

    I believe the active and SetActiveRecursively are now completely gone. It was pretty confusing when they made the change back in Unity 4, so I wrote about it back then

    https://medium.com/@technicat/demystifying-setactive-343e14714a4d

    I think the change would have been clearer if they just changed it to active/localActive, similar to position/localPosition, etc.
     
  7. Gaspedal

    Gaspedal

    Joined:
    Mar 29, 2009
    Posts:
    369
    Thank you too for your very good examples and explanation!
    I was confused too, because "active" is still works fine and it's not read only.

    gameObject.active = false;

    still works like

    gameObject.SetActive (false);

    But as you said, it would be better if unity would be clearer with the active calls. It's pretty confusing. But after reading your text on your website now I understand it better. :) thx
     
    Last edited: Aug 16, 2018
  8. Deleted User

    Deleted User

    Guest

    Oh, that’s interesting. I didn’t see active in the GameObject script reference, anymore, so I thought they’d removed it, but I guess not.

    https://docs.unity3d.com/ScriptReference/GameObject.html

     
unityunity