SerializedBaseClass

[Former user]

Currently you can serialize anything which inherits from some kind of Unity component (MonoBehaviour/ScriptableObject/Component/Object/ect), but you can't inherit from a class that doesn't inherit from a Unity class. There would be no way to do this:

    [System.Serializable]
    public class GasDetector
    {
        [SerializeField]
        private List<IGas> m_Gases = new List<IGas>();

So it looks like this:

Instead of this:

It's correct standard to expect to inherit from some Odin class, but I have a feature request that it doesn't necessarily need to be a Unity inherited class.

[Tor Esa Vestergaard]

Okay, so adding a base class like this is a thing you can actually easily do yourself using Odin's APIs (see also the source code for SerializedMonoBehaviour, etc.). The reason we haven't added it by default (this is something we debated internally ages ago) is that it makes it less clear where exactly Odin's serializer is active, since you could actually have a regular Unity-serialized MonoBehaviour, and if you add this "ordinary" non-Unity class, suddenly this class magically invokes Odin's serialization to serialize itself, despite the root object that "owns it" not being Odin-serialized.

To us, promoting that situation for unwary users seemed like a bad idea. We would rather stick with the pattern where a Component or ScriptableObject or whatever declares on the top level that it wants to use Odin's serialization for the data it contains, and that's then clear to everyone, instead of this situation where Odin might serialize any random object that wants it, regardless of context.

However, as I said, you are perfectly free to add this yourself and use that - we don't want to limit you, but the default API we ship with in some sense constitutes "things that we implicitly recommend people to use", and we don't want this to be one of them, so we won't add it to Odin by default.

Edit: Actually I just realized that you cannot verbatim use the examples as provided, since they actually do demand a UnityObject context. Give me a second to write up an example.

[Tor Esa Vestergaard]

This has turned out to be less trivial to add without changes to Odin internals than I would have immediately anticipated - primarily, this introduces the issue that Odin would assume your Unity object is ultimately Unity-serialized (which it is), and when it then encounters your special Odin-serialized class in the Unity object, it will still think that it is Unity-serialized, and will not show the Odin-serialized members, even though they are actually being serialized and persisted. 1.1 will have features to help with this. Otherwise, for now, you'll have to live without this, I'm afraid.

[Nigel Clark]

That's a great explanation, thank you. I understand and will follow your advice.