New ScriptableObject in Runtime.

Inventory is my ScriptableObject .

My code

Start()
{
Inventory = new();
}

I don’t want this data to be saved.
I’m curious if this will leave any data on the computer?

I want to save the only one inventory as standard.
And save/load binaryData when I need.

Assets can’t be changed in a build. The scriptable object will just exist in memory until you destroy it, or the application closes.

Scriptable objects, or any UnityEngine.Object, can’t really be written to disk either (aside from the highly limited JsonUtility).

If you don’t actually need Inventory as an asset on disk, then consider if it can be a plain C# object.

3 Likes

Using ScriptableObject for runtime-only stuff could make sense if you prefer to use some of the events for setup or teardown (Awake/OnDestroy/OnEnable/OnDisable), but then again, you can do similar things with plain C# objects (IDisposable pattern with/without a finalizer for disposing unmanaged resources) and those don’t have whatever overhead that using UnityEngine.Object-derived types might have. In either case, you can create your object and do whatever with the data it holds without fear that it does anything with storage unless you specifically serialize/deserialize it. If you’re actually trying to save/load the inventory object itself, I’d tend to go for the C# object route and either use JsonUtility with [System.Serializable] on the type or the “Unity Serialization” package.

Side note: a common pattern (not sure if this is considered best practice) is to initialize a component’s own data in Awake, so all the components are at least internally set up so when Start is called, everything can start hooking up with each other. You might consider initializing your inventory object in Awake. Also, when you post code, especially larger fragments, make sure you use code tags for readability.

2 Likes

Also to create any Unity object (MonoBehaviour, SO…), don’t use new SO() but ScriptableObject.CreateInstance<SO>() in this case

3 Likes