Keeping default Unity behavior of instantiating fields when they are null instead of serialization and keeping null?
oxysoft opened this issue · comments
I am looking into using Odin Serializer to greatly simplify serialization of some data in our game. (Mainly the data for the battle system in a super flexible JRPG engine, loads of skills and configurables like procs, effects, triggers, etc.)
The most infuriating pattern I've noticed over and over again that is very irritating is a workaround I use due to missing support of polymorphism by default in Unity. I use an enum and pack all the fields of every 'type' in there, and there's a weird switch statement somewhere. We use VFW for advanced drawers and attributes (unfortunately perhaps we should have been early adopters of Odin it looks like, as Odin was just coming out at the time.) so we have a visibility attribute which grabs the enum field and changes the visibility based on the value and stuff. Basically it makes it a pain to add new stuff, and it's neither maintainable or readable. The fact that it's everywhere makes it worse, and even more-so when there's multiple layers of enums in there. On top of that, the naming of variables is insane.
So I got Odin Serializer and so far it seems to work perfectly fine and I was able to write a much more sane configuration setup that allows for a clean hierarchy and structure, but the only hiccup is that it seems to leave values at null, whereas the default serialization in Unity will instantiate. Any way around this?
note: If this isn't possible, it's no big deal since I've modified VFW many times before and I can easily add a button to instantiate if a field is null.
I'm afraid there is no easy way to do this - you could do it, of course, by modifying the core deserialization code somehow, but it's not exactly straightforward and you might need to do it a few spots. If you're only interested in doing it for "root level" Unity object members, you could modify UnitySerializationUtility.DeserializeUnityObject to keep track of which potential members to deserialize into were not actually assigned a value, and use UnitySerializationUtility.CreateDefaultUnityInitializedObject to create your default instances for the rest of them.
Meanwhile, this is not a feature that is going to be added to the core code, so I'll close this issue on that basis.
No worries, I've already added the feature to VFW and made sure it interfaces a better with VFW. I would suggest specifying somewhere on the main readme of the project this pitfall that I ran into, how you have to make sure to instantiate your types. It was an unexpected catch for me that left me puzzled for a moment. Also, we are almost definitely switching to Odin Inspector in the future, and we may try to move over some of our VFW code depending on how compatible the two API designs are.
@oxysoft can you share how you did it? I ran into the same problem myself and would be interested in a clean solution.
I understand that it might be specific to your game but if you paste some pieces of the code I might be able to modify it for ours :)
Thanks!
We've switched to Odin Inspector a long time ago and actually haven't carried this feature over from VFW, so at the moment we just manually instantiate through the dropdown and try remembering to assign default values to our types that are frequently used.
Yeah we are doing that as well, this is nitpicking at this point but was something that was nice to have :)
Thanks you for your fast reply!