Make Variables discard playmode changes about unity-atoms HOT 6 CLOSED

could be implemented like this: soraphis@f95307c

from unity-atoms.

This is a great feature and something that I've been thinking about / toying around with myself. However, I think there are different use cases, sometimes you want the value to persist between scenes and plays and sometimes you want it to be reseted to an initial value. Therefore, I propose that the ScriptableObjectVariable should also contain a ScriptableObjectVariableBase called initalValue (this will need to be part of the generic signature in order to be serialized properly). If the constant (ScriptableObjectVariableBase) is set we set in OnAfterDeserialize, otherwise we don't. Would gladly accept a pull request (but I might also try to implement this right away - so check if it has already been implemented before doing a pull request).

Side note: when you want to reset something at the start of a scene you can use OnStartHook combined with SetVariable.

from unity-atoms.

sometimes you want the value to persist between scenes and plays

this is a dangerous thing! while you might want it for in-editor features this will never happen in builds. because of that I highly recommend implementing a reset system.
(also: in-editor features will probably not use unity-atoms)

Therefore, I propose that the ScriptableObjectVariable should also contain a ScriptableObjectVariableBase called initalValue (this will need to be part of the generic signature in order to be serialized properly)

I'd argue against that, because: you'd need for nearly all variables an additional variable for resets. this reset variable would have its own description fields, old values, events, and so on

while all you actually want is: a boolean flag whether or not you wanna reset, with a default on true. (because really, I can't imagine a case where you want to store something inbetween editor sessions)

Side note: when you want to reset something at the start of a scene you can use OnStartHook combined with SetVariable.

which will introduce WAY MORE assets than i actually need (it doubles the amount).

in the game we made the other week, we had around ~10!? unity-atom variables. that would be 20 + the OnStartHook.

from unity-atoms.

while you might want it for in-editor features this will never happen in builds.

Risking sounding like a noob. I have been looking into this before, but I remembered that it actually was saved between plays in build. Just tried it, and yes you are right. Thanks!

I'd argue against that, because: you'd need for nearly all variables an additional variable for resets. this reset variable would have its own description fields, old values, events, and so on
So because of the above reasoning I agree with you 👍

Maybe it would be great though to be able to persist state between plays, by serializing to json / xml for example. What do you think? Should I create a new issue for that?

while all you actually want is: a boolean flag whether or not you wanna reset, with a default on true. (because really, I can't imagine a case where you want to store something inbetween editor sessions)

On a second note, yes a boolean would probably be much easier and will introduce way less asset files (a good thing).

Question, do you know if OnAfterDeserialize and OnBeforeSerialize are called when switching between scenes? Is it different when running in the editor vs in an actual build?

from unity-atoms.

Maybe it would be great though to be able to persist state between plays, by serializing to json / xml for example. What do you think? Should I create a new issue for that?

for me, that is the job of a savegame system. In the game project I worked the other week i also have a savegame system. I read values from atom-variables and on load i feed them back in.

Serializable variables - for me - are mainly a way to provide vales across multiple scenes (or across multiple prefabs).

Question, do you know if OnAfterDeserialize and OnBeforeSerialize are called when switching between scenes? Is it different when running in the editor vs in an actual build?

In the editor: they are called when entering playmode. they are not called for scene changes (neither playmode nor edit mode). they are called when unity recompiles and maybe on a few other ocassions.

in the build: "OnAfterDeserialize" is called once, when the game starts.
(i just tested that with a debugger)

In my project I'm currently using my fork of unity atoms, and I have not found a problem with OnAfterDeserialize yet. and it reduced "initialization code" - code lines where i just made sure that on game start the atom-variables have a specific value.

from unity-atoms.

Implemented in 06eab90 and fixes in ed57421

from unity-atoms.