koobas.hobune.stream
An alternative to unstable ScriptableObject?
I have one major problem with ScriptableObject - if I mess around with the code of the scriptable object, I can run the risk of losing data.
For example if I change "public int cost;" to "public int price;", I've now lost the data for the cost entirely for over 200 objects and need to manually re-enter.
In contrast, if I was using XML I could just do a find-replace-all in my text editor for "cost>" to "price>" and everything's just fine.
The catch, unfortunately, is that if I use XML I lose the fairly vital inheritance functionality as XmlSerializer doesn't let me pick and choose which element of the array will be which child class.
Example:
<animals>
<animal> name </name>
<cat> name, age </cat>
<cat> name, age </cat>
<pterodactyl> name, age, flightspeed </pterodactyl>
</animals>
Is there any middle ground that lets me edit data outside of unity in one large file, thus preserving its integrity, while also allowing me to pick and choose which child class will be used in a convenient way?
I suppose the nasty method would be to create scriptable objects that take a text asset as their input and put every individual element in its own xml file but.....urgh. There has to be a better way.
Being able to tell the xml serializer what each array element is would be ideal but failing that is there a happy medium?
Particularly I'd like to avoid too many inidividual files to ensure it doesn't affect load time too much.
from my little experince with scriptable objects they may not be the best way to store data espeacially if you have a lot of small objects as you have said, 200 or something.
best to use this asset
https://assetstore.unity.com/packages/tools/integration/simplesql-3845
I've did some test and works great once you got the hang of how all is connected. you can then edit and update a database outside unity with ease in a free third party datase editor.
I'll give that asset a try, thanks! Seems I already picked it up a while ago in a sale, no reason not to tinker then. If not, it's on the right trach that using some kind of external DB does seem like the logical middle ground.
