Forums | Moodkie Interactive

Hi,
when I mark a field Dictionary<Stat, float> as [SerializeField] (Stat is Enum), it is not saved when object with the field is saved. (I am not attaching screenshot of saved file as the field simply is not there)

But when I generate ES3TypeScript for the object, the field is saved correctly - see the screenshot and the saved file below.
Is this intended behavior or a bug? I can workaround it as I can generate script for every file, but it would be more handy to when it works without need to generate scripts (and to regenerate them with every change in the object).

Best regards, Jakub

Hi there,

This is likely because the Stat class isn't automatically serializable. However, it's not possible for me to tell without being able to see all of the classes involved.

All the best,
Joel

Hi Joel, thanks for fast reply.
The Stat class is enum - so it should be serialized by default?

Hi there,

If you replicate your issue in a new project with a simple scene and private message it to me with instructions I'll be able to tell you exactly what is happening.

All the best,
Joel

Hi Joel,
you can find a simple scene with a few scripts here (made in plain 2D project in unity 2021.3.26, latest ES3):


It seems to me that serialization that is made "on the fly" (on the fields with [ES3Serializable] attributes) sometimes works for Dictionary, but not always. Once I generate the ES3Type files (without any change in selected fields - they are selected correctly by default based on usage of [ES3Serializable] attribute in classes), it always works.
I am actually fine with having ES3Type files (benefit is to see changes in git), so I don't need to solve the issue anymore, but I want to ask:
Is there a way to re-generate all the existing ES3Type files at once? (for example by calling some ES3 API?)
Or a way to generate/re-generate all ES3Type files for all classes with [ES3Serializable] attribute?
Or some better way how to manage ~70 classes other than search for every individual class, click "reset to default" and then "create ES3Type script"?

My way of thinking is to have all serializable classes with [ES3Serializable] attribute and from time to time simply regenerate all of them (to avoid problem with forgetting to manually refresh the script). I actually like to have the ES3Type files in this case, because I can see/evaluate changes to previously commited version of ES3Type file.

Thank you for the answers, I really appriciate your great support.

Best regards, Jakub

Hi there,

Thanks for sending that over. In the future please could you private message projects rather than post a public link, otherwise it is public sharing of the ES3 package which is against the EULA.

Regarding the behaviour you are experiencing, this is because Components are only saved on GameObjects if they have an ES3Type (see the Saving and Loading GameObjects guide: https://docs.moodkie.com/easy-save-3/es ... ts-prefabs). This isn't specifically about Dictionaries not being saved: the entire Component is not being saved.

Alternatively if you private message me your invoice number I can send you our upcoming update which adds a Component which allows you to select which Components on a GameObject will be saved, meaning you don't need ES3Types.

I would also recommend taking a look at the Saving and Loading Prefab Instances section of the guide linked above as currently it seems that you're trying to use ES3.LoadInto to load your prefab instances, but this can cause issues as certain things are resolved by reference rather than by value. Using the above guide simplifies this process and ensures that all references are correctly registered with the manager so that they can be saved and loaded with the correct reference IDs.

Is there a way to re-generate all the existing ES3Type files at once? (for example by calling some ES3 API?)
Or a way to generate/re-generate all ES3Type files for all classes with [ES3Serializable] attribute?

This wouldn't be possible because it wouldn't be possible to know what fields you wanted to be selected, and it's unsafe to assume that all are serializable.

All the best,
Joel

Hi Joel, great, thanks for help.
I missed this in documentation:

Components are only saved on GameObjects if they have an ES3Type

I thought that they are saved if the class have [ES3Serializable] attribute and that only applicable fields (that are checked by default in UI) are saved - now it is clear.

In the future please could you private message projects rather than post a public link,

sorry, I removed the share, will do next time

I can send you our upcoming update which adds a Component which allows you to select which Components on a GameObject will be saved,

it would be great, will do so

taking a look at the Saving and Loading Prefab Instances section

I started with this, but I was not able to say that I don't want to serialize some of the third party/unity native components (related to animations, where serialization takes a lot of space and actually doesn't make sense)
In game object, I solved it in the way that I put components I don't want to serialize to the child gameobject and serialize only parent gameobject - then when I instantiate a prefab (with both parent and child gameobject) and then loadinto parent game object, all works as expected
this approach works for me quite well, but if you have better idea how to manage it, I am all ears

it wouldn't be possible to know what fields you wanted to be selected

maybe the same logic that is selecting the fields in UI could be used. BTW I am marking all the fields either by [ES3Serializable] or [ES3NonSerializable] just to mark for myself if I choosed to serialize them or not, so it should be clear, but I understand that not everyone want/need to do it

BTW I am making pretty complex colony-simulation game, so my usecases when saving all the data are probably much more complex than in other games