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

What's the different between gameobject.active and gameobject.SetActive() ??

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

 

Use SetActive as .active is a deprecated function. Not sure what the technical difference is, but it's not recommended to use .active.

 

thanks! I'll update my code to using SetActive only.

 

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.

 

@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. ^^

 

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.

 

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

 

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