koobas.hobune.stream
.enabled not working
MeshFilter nem = ne.GetComponent<MeshFilter>();
nem.enabled = false;
So i'm trying to disable a MeshFilter Component but Unity gives me an error that points to ".enabled" and says
"error CS1061: Type UnityEngine.MeshFilter' does not contain a definition for enabled' and no extension method enabled' of type UnityEngine.MeshFilter' could be found. Are you missing an assembly reference?".
I don't get it, every component should work with .enabled, what's wrong?
Uhm, no. Not every component can be enabled or disabled. Only those which actually have a checkbox in the inspector. The Component base class does not have an enabled property. The Behaviour subclass does have one. There are many components which can not be disabled and MeshFilter is one of them. It also wouldn't make much sense as the MeshFilter only holds a Mesh reference. It doesn't do anything. You may want to disable the MeshRenderer?
I've never realised that meshfilter doesn't have a checkbox in the inspector, this makes so much more sense now! thank you for an another great answer mr. bunny!
Disabling $$anonymous$$eshRender is indeed the way to go, e.g.:
public static void SetActive$$anonymous$$eshRenderers(this GameObject gameObj, bool isActive)
{
foreach ($$anonymous$$eshRenderer child in gameObj.GetComponentsInChildren<$$anonymous$$eshRenderer>()) // GameObject recursive call, including this gameobject
{
child.enabled = isActive;
}
}
No, a Component does not have an enabled property. A Behaviour which inherits from Component defines the enabled property. And of course all Behaviour subclasses also inherit the enabled property, e.g. MonoBehaviour.
However, a MeshFilter inherits from Component, not Behaviour, and that's why the enabled property is not available.
Though what many people confuse is that there are other built-in components which are not derived from Behaviour but do have an enabled property. Renderer and Collider define their own enabled property. Unfortunately since those enabled properties are not the same they can't be treated in a generic way. Though if you want a flat class hierarchy you have to live with such reimplementations of the same concept. $$anonymous$$aybe one day Unity implements some common interfaces which the built-in components implement (like an IEnableable which however is a horrible word ^^)
