koobas.hobune.stream
"Serialization depth limit exceeded" with non-serializable classes
I know there are many threads about this bug or whatever it is, but they all deal with actual serialization. I get these errors for classes that don't derive from unity classes, nor use the unity attributes, also they are loaded from the DLL. So for some reason Unity is checking my classes for its serialization system and feels the urge to tell me 1500 times per code load...
Any ideas how to get rid of it?
If you are using any of those non-serializable classes as public variables in a monobehavior, it IS trying to serializing them. You will need to use a [System.NonSerialized] attribute in front of each such variable to prevent it from serializing. Or make them not-public.
There are no public variables in any of my classes (i believe they are evil)
Even if i am adding no new classes, or modifying any monoBehaviours, the number of errors increases as i work.. it now takes tens of seconds just to print them. I don't understand why I can't have my classes not deriving from Unity.Object without the engine going nuts... this happened when i upgraded from 4.6.1 and happens on all 5.xs i tested too
ok, quick test. Create a new scene, in the same project, and open it in the editor. Do the errors continue on this blank scene? If so, hmm, that IS odd. If not, that implies you are mistaken, and SO$$anonymous$$ETHING in your (not empty) scene is attempting to serialize those classes.
So how do you access their data? Get/Set accessors?There are no public variables in any of my classes
You certainly SHOULD be able to use classes not deriving from unity.object without stuff going nutz, I know I do.I don't understand why I can't have my classes not deriving from Unity.Object
The same happens with the empty scene and all my custom editor windows closed (default layout). And yes, i use properties for everything
From: 4.5 - Serialization Depth
What 4.5 highlighted is that private and protected field, while not saved on disk, are still processed by the serialization pipeline. So while you think your public field does not offer any chances of dependency loops, your private/protected fields might, and the Editor doesn't like that one bit.
FIX
Obviously, the best fix would be for Unity to perform serialization as they advertised and ignore private/protected fields. However, for now, the workaround found was to manually flag your non-serialized field with the [NonSerialized] attribute.
Just want to add that Unity, when it comes to "normal" serialization, doesn't automatically process private and / or protected variables.
Only the Unity editor does this to allow an assembly reload at runtime. Actually that feature was flawed from the very beginning since static fields aren't saved / restored, so most singleton stuff will mess up anyways. Also if there are non serializable classes those will be lost too at assembly reload.
Usually Unity shouldn't touch instances which aren't serializable. However in your example error message we can see that the offending classname is "O$$anonymous$$.$$anonymous$$ath::Transform" it might interfere with "UnityEngine.Transform" since the class name is the same.
Yes, yes, Unity now supports namespaces, but actually, no ^^.
Thanks. I tried, and the name of the class is not causing the problem, seen in the example above.
It's good to hear that unity tries to improve assembly reloading, but still I don't believe i will ever rely on it's ability to update scripts during the playmode and keep everything valid.
Well, it shouldn't, but sometimes it did. Thank god, there is serialization as text, where you can fix it manually."normal" serialization, doesn't automatically process private and / or protected variables.
Still, it would be very useful if unity at least told me which object/class causes the error. This way i have no idea!
