Necessary and sufficient conditions for a ScriptableObject to behave like any menu created asset?

Unity Engine
1

Is it possible to work with scriptable objects (SO) as if they behaved like any other assets? In other words I’d like to:

  • Create them (preferably from menu).
  • Be persistent between Unity restarts (not turning into empty assets after each Unity restart).
  • The modifications of SO particular instances to be also persistent (if possible).
  • The references of the SO’s in monobehaviours (MB) to be persistent instead of losing them and have null references after Unity restart.

What’s the minimum scripting I’d have to do to achieve this?

So far I’ve tried:

  • [CreateAssetMenu] It creates the asset in Project. I drag the asset into a reference of some MB in Inspector but this doesn’t do anything about persistence of the SO’s themselves, nor of the references to them in MB’s.
  • Putting:
UnityEditor.AssetDatabase.Refresh();
UnityEditor.EditorUtility.SetDirty(this);
MonoBehaviour.print(this);
UnityEditor.AssetDatabase.SaveAssets();

into each SO’s Awake() still not solving persistence of any kind.
I’ve even had a Unity crash when I put the code in OnEnable().

2

All of those things should be work out of the box. If your SO’s are turning into empty assets after restart, then there’s something very wrong going on.

They do have the same restriction as MonoBehaviours in that they need the file and type name to be the same to be deserialized properly. Having those not match is the only thing I can think of that’d trigger the behaviour you’re seeing.

1 Like
3

A big thank you, Baste! I’ve been delving with this for some time… I had all SO’s in one file and this was the culprit. It didn’t occur to me that this was it because apart from serialization, all was/is working as expected. This is a nasty thing as I’d like to have SO’s by the hundreds and it’s not comfortable to fragment the code in hundreds of physical files.
I can understand that monobehaviours should match the file names but SO’s are a bit different in purpose and they should allow for proper C# syntax. BTW, I wonder what if somebody needs nested SO’s? I don’t right now but just wondering…