have i derive from MonoBehaviour to expose fields in inspector?

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