Bug ScriptableObjs edited during play mode will NOT update/refresh until you edit it again after

For example:

1. I have ScriptableObj foo that's for localization.
2. While playing, I realize foo.hello string serialized field had a typo.
3. So, I changed foo.hello from "h3llo" to "hello".
4. I stop playing.
5. I go to my Git client: The change is not there! The buffer was not .... forgot the verb: Pushed?
6. Np, save and refresh (CTRL+R)... which is supposed to push the buffer for these pending changes.
7. I go to my Git client: The change is still not there!

-> Now, if I were to do this exact change while NOT playing? It would work as expected.

*To clarify, I am talking about changing the SO mid-play then saving after stopped play (not saving during play)

The Ghetto Workaround:

1. After step #4 above, I go to ANY ScriptableObject and I make an arbitrary change and unfocus the ScriptableObject (sets as dirty, I believe).
2. [Not necessary to repro] I CTRL+Z undo that change, or delete what I just typed.
3. I save+refresh.
4. Suddenly, it's there.

So, the bug:
Seems like when you alter ScriptableObjs while playing, the SO's are NOT marked as "dirty". It's somehow still buffered (if I make an arbitrary change outside playing and undo that change, my actual change still registers), but doesn't recognize the change until after ghetto workaround step #3.

Repro:
Credit my account for my time for your bugs and you got it. Else, use your QA budget, buds - Any Jr Dev can repro this with incredible ease.

 

Did you try to hit ctrl + s after exiting play mode? I believe that changes aren't saved during play mode because saving during play mode is not supported at all

 

Yep ctrl s, still doesn't work until I edit any scriptable obj first. THEN it remembers.

And right, talking about changing during play then saving after stop playing. To clarify, I'm not trying to save during playing.

1. Play
2. Change
3. Stop
4. Save+Refresh. Won't work unless I edit 1 time outside of play, then play changes will finally show.

 

I'd rather publicize it here with the bug tag or it'll be sent into the QA void to forever be buried because I didnt provide a repro project. I'll take my chances - there's a roughly 80 percent success rate posting here vs bug reporter tool. I have a feeling your QA team may be burying bugs that are not publicly disclosed that constantly and mysteriously closes as resolved or unproducable. Thanks, though. I've had bad experiences that I cannot unsee.

 

How are you changing the value? Through editor inspector or runtime script? Is this unity's localization package you're using?

Modifying scriptable objects via runtime script means you need to manually set the object dirty: EditorUtility.SetDirty.

There's a bug in the localization package regarding dirtying scriptable objects. So that could be another issue you're hitting.

If it's none of these, should submit a bug or chances are it won't get noticed/fixed

 

Changing through inspector.

This is the reason why it's best to post in forums vs submissions:

https://forum.unity.com/threads/why...s-reset-my-default-value.681454/#post-6090186

^ One example of countless times Unity will ninja close tickets as fixed when they aren't. At least here there's a public record not sweeper under the carpet. It's all over Reddit: Unity has become infamous for this. Even my own submissions have done this before more than once. Remember UNET? Submitted about 30 bugs fully reprod. Not 1 fix. I'm on bug report tool strike. At least if it's here, it's immortalized and the public can see it.