- Home /
have i derive from MonoBehaviour to expose fields in inspector?
hi, i wasn't able to find an answer in docs after quick search, so may be someone will tell me. is it mandatory for class to be derived from MonoBehaviour to have its fields exposed?
If you add the [System.Serializable] attribute to any class whose members can be serialized, you can expose fields or collections of such objects in the inspector. But those fields or collections must belong to a monobehavior-derived object to be visualized in the inspector.
The alternative involves an editor script which somehow bypasses this requirement; in effect, it IS possible to edit non-monobheavior-derived objects in the inspector, but you will be coding every aspect of this custom inspector behavior yourself.
In five years, I've only done this once. I decided it was more trouble than living with the inconveniences associated with exposing serializable objects via an otherwise-useless monobehaviour derivative.
thanks. since the representation of classes i wanna to expose will be heavily custom itself, i will be writing custom editor scripts for it anyway
just for information: you say 'fields or collections must belong to monobehavior-derived object', but if just some object (non-monobehaviour-derived), that contains those fields and collections belongs to monobehavior-derived object it will not work, as i guess?
You kind of lost me there. Hard to word these things sometimes. The gist is, without a custom inspector and methodology for handling everything, exposing anything requires at least one monobehavior.
Where else could you observe it? But you can "drill down" as far as you like, I think... Been a while since it's come up; I stuck with practices that circumnavigate these situations.
// you can edit aFloat and anInt from this object
public class Holder : $$anonymous$$onoBehavior {
public SomeReferenceType someRefType;
}
[System.Serializable]
public class SomeReferenceType {
public float aFloat; // this field will be visible
public AnotherReferenceType anotherRefType;
}
[System.Serializable]
public class AnotherReferenceType {
public int anInt; // this field will be visible
}
Hi, you can also derive from ScriptableObject if the data you want to edit/store/read does not need to be attached to a gameobject. You can also have custom inspector etc...
thanks guys for you patience. i'd be like 'just f**king try it', if i were you
and i will try it, of course