If you have a ScriptableObject with, let’s say an int field initialized to 100
[SerializeField] private int _health; // set to 100 in inspector
and that value is modified during the course of play in editor mode, then the next time you press play in the editor mode, the value is not reset. It stays at whatever value it had at the end of the last run.
Presumably this is because the ScriptableObject survives in memory across editor mode play runs (I don’t think the raw .asset file for the ScriptableObject is modified, the value still shows 100).
But why is this the behavior? This makes it impractical to use ScriptableObjects to manage mutable state, as you would have to manually reset the state every time you press play. Are ScriptableObjects intended only to hold immutable state? If so, why are ScriptableObjects touted as event-passing middlemen? Events are mutable state - collections of function references.
@ajb112 if u restart the editor the values will reset by editor.if u dont want to mess ur SO data then use Instanciate function to make a clone out of ur SO.
When you run the compiled program it will behave as you expect - losing the SO data between runs, unless you load from a file or another source.
The editor is designed to save scriptable object variables automatically at run time whether you want to or not, as I think they were originally meant to be used for parameters/settings that don’t change at run time.
As others have said - either
instantiate a new copy
use one SO for variables that change and another for those that don’t.
Have private or public [System.NonSerialized] variables that store your current health and store the default 100 in another variable that is serialized. e.g. public int DefaultHealth=100, and set health at runtime.