Scriptable Objects only maintain values until application is closed?

Hi,

am I seeing that correctly, that a scriptable objects keeps its changed values only as long as the application is running?

I tried using a SO to store the last level the player successfully finished, as I thought the value changes I do in the SO are permanent. (Which they “are” until I close the build or the unity editor).
Can I tell that the changes in the SO during runtime should be made permanent or do I have to create my own methods to save data to the disk to accomplish this?

Thanks

Alex

From the manual, does this help;

When you use the Editor, you can save data to ScriptableObjects while editing and at run time because ScriptableObjects use the Editor namespace and Editor scripting. In a deployed build, however, you can’t use ScriptableObjects to save data, but you can use the saved data from the ScriptableObject Assets that you set up during development.

Data that you save from Editor Tools to ScriptableObjects as an asset is written to disk and is therefore persistent between sessions

1 Like

so rtfm would have helped…

sorry and thank you :wink:

This happened a lot when they were first introduced. They were built up as this incredibly useful breakthrough thing that could do everything. They were to go-to for every problem for a while: “how to use an SO to feed my fish?”. When mechanically they don’t add anything we couldn’t do before with prefabs. People had been abusing prefabs for years as a way to store cross-scene data in an inspector-friendly way, which is all scriptableObjects do. In a sense , SO’s are Unity saying “that’s a cool trick, why don’t we give it a name and it’s own icon?”. But then people who wrote guides jumped all over them.

1 Like

Why abuse? Ain’t that a nice thing to do? I thought a lot of people prefer that over a singleton.

Singleton? Way back people made Inspector-friendly globals by having a script attached to a gameObject. That meant it was in a scene, which was destroyed when you loaded a new one. They then solved that by having it persist with dontDestroyOnLoad. People here called that exact construct a Singleton.

Of course now that we can have multiple scenes loaded at once, dontDestroyOnLoad is pretty much obsolete.

Hmm. Never used or read into that.
So much to learn still ^^