Serialization Depth Limit???

Hi,
I spent about a month working on code only to find that when I fixed all my errors, I get a bunch of “Serialization Depth Limit” errors. I don’t know WHAT I did last to MAKE these errors appear (what classes of arrays or lists I added inside classes of arrays or lists) and don’t have a backup copy of an earlier C+ file. How can I make these errors go away without having to deserialize anything? Thank you.

Do a search, it’s a common issue. These ‘errors’ were always present in unity, they just failed to serialize that far silently. You should just be careful about what you make public. For example a list of references to the same type of the list as a public serializable field will do it… or anything that in theory would have recursive serialization (even if it doesn’t).

Indeed, it would be a good idea to read this blog post about serialization in Unity if you have a few minutes on hand to get a better understanding of what is and is not allowed, so you don’t run into this problem again in the future without knowing why it happens.

1 Like

What if I need everything publicized because I want to be able to set everything in my inspector, and I want to SEE my results in the inspector?

If you want to edit values in the inspector, they have to be serialized, or else Unity can’t save your changes.

If you have a very specific serialization need that is not possible using regular Unity serialization, take a look at this very easy work around I posted here. You can use the NonSerialiazed attribute on your public fields you want to see in the inspector but are causing issues for Unity, and use the byte array serialization behind the scenes.

I don’t fully understand, but wouldn’t it be a great idea in the next version of Unity to not have to make serialization THIS complicated and that it would automatically do whatever it needs to do to make multiple serialization possible?

This is an optimisation though, and it’s just being honest - Unity always did this but silently failed. It led to poo bits for everyone. You’ll have to just live with it.

… so a man can create a rocket, but can not figure out a way around this? It seems like it would take MORE code involved to write something that would stop code from compiling after certain levels of serialization, than to just let it compile freely. I just wish I could ‘comment out’ whatever code does this.

Do you have any classes that are marked serializable, but don’t inherit from MonoBehaviour or ScriptableObject?

If so, does that class have a reference to a class that can create a structural recursion, for example:

public class Foo
{

    public Bar Obj;

}

public class Bar
{

   public Foo Owner;

}

or something like:

public class Foo
{

    public Foo[] Others;

}

Where that Foo references a Bar, which references a Foo, which references a Bar, which references a Foo… so on and so on.

Thing is that during serialization, all objects lose their object identity and collapse into data. So if Bar references Foo, which references that same Bar… they become 2 distinctly different objects during serialization.

It’s the same reason a struct can’t reference a struct of its own type:

public struct Node
{

    //this will throw a compiler error
    public Node Next;

}

It’s just that during serialization it’s not allowed in classes as well, but for the same structural reason.

1 Like

That could be it. Thank you.