ScriptableObject+XmlSerializer=sad

Question

Hello friends, I've been banging my head in the wall for a couple of hours with this:

I am making an editor extension and I have that Node class which has a lot of children classes. I also have a List with all the nodes. At first I had the problem that this list didn't survive through serialization (when I hit play all the children specific data was lost, including their Type). I read a lot of crap about Serialization and I finally managed to fix it by simply making the Node class driven by ScriptableObject. Though that ended up coming at a huge cost, because that means I can't create nodes with new Node(), but with CreateInstance. For me that's acceptable, but for my buddy - the XmlSerializer it isn't, since who am I to tell him how to Deserialize his objects...

Long story short - XmlSerializer uses the Node() constructor and ScriptableObject doesn't like that so I'm looking for a way to make my Nodes list survive 'assembly reload' or whatever happens when I hit play without the making them ScriptableObjects.

Things I can't do:

Ain't no way I'm replacing XmlSerializer because I'm inlove with it
Also I can't make multiple Lists for each type of nodes because that would fuc...screw up the entire code logic (which is a lot of junk to fix, believe me)
I also really don't want to create another Node class that won't be driven by SO and also keep the old one for editor purposes

I'm aware that this question has kind of been asked before about 50 times but I didn't find an acceptable solution. Also it's worth mentioning that everything related to my editor extension is in a custom namespace if that makes any difference.

Please help me if you know a solution, I really am stuck. Also I need to get some sleep, I'll check back here tomorrow.

Thanks in advance guys

Answer 1

Best Answer

Answer by rutter · Aug 08, 2014 at 06:55 PM

Unity's serialization isn't polymorphic at all. It's usually fine, but once you end up with a fairly experienced programmer who expects to be able to use all of their OOP skills, it can be a harsh gotcha.

If you can serialize to XML, it might be easier to just do that and have Unity keep track of a string. Every time you make a change in the editor? Write out the XML. Every time you play the game? Load in the XML. You can even use lazy instantiation principles to make sure the data is always available when it's needed.

Depending on your specific needs, this string could be kept in a TextAsset, a ScriptableObject, or just a serialized field in some component.

It's fine to use custom serialization, as long as you do it in a way that plays nicely with Unity -- usually that means serializing out primitive types, like strings, byte arrays, and so on. You can also use resources and streaming assets if you're in a pinch.

The only Unity-specific part of this question is getting Unity to handle your data. After that, it's important to remember that you have the full power of the .NET framework at your fingertips -- anything from XML to JSON to SQL is completely accessible, just as long as you can handle the data.

1 Show 1 · Share

$$anonymous$$ · Aug 09, 2014 at 07:20 AM 0

Share

Thanks for the reply. I know that serializing and deserializing each time something happens is a possibility, it just felt like there must be a sexier fix. Probably it's because the ScriptableObject thing was so straight forward. The alternatives just don't feel right. Whatever, I'll give it a try and see if it'll make me change my mind

Answer 2

Answer by $$anonymous$$ · Aug 10, 2014 at 11:00 AM

I just found that:

ISerializationCallbackReceiver

How have I been so blind not knowing about its existance. It does wonders, allowing to quickly load and save the data and even dodge making my classes serializable while Unity does its stuff.

0 · Share

ScriptableObject+XmlSerializer=sad

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions