Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feedback Please provide main thread serialization / deserialization callbacks for arbitrary classes

Discussion in 'Scripting' started by KAJed, Feb 18, 2021.

  1. KAJed

    KAJed

    Joined:
    Mar 15, 2013
    Posts:
    122
    ISerializationCallbackReceiver.OnBeforeSerialize and ISerializationCallbackReceiver.OnAfterDeserialize() are incredibly handy. But, especially when it comes to editor time, they are less than ideal due to the constraint of not being able to run Unity API's. They also happen to be the only functions that fire for Component / ScriptableObject before their less than perfect lifetime callbacks (Awake/OnEnable).

    I understand that there would be performance hits for requiring a class to have a main thread callback but it would alleviate a lot of pain points when trying to do what should be very simple things. In my most common use case this is ensuring data remains consistent when certain Unity object fields change (or are changed in version control without updating related fields).

    Often times I find myself fighting with Unity to come up with a good solution when the solution would be simple if given this functionality. I would even settle for an editor time only method or callback that can fire on arbitrary classes (limiting this to only behaviours / scriptable objects would be just as messy to solve).

    One thing to note is that it is possible to use Unity Editor API through OnBeforeSerialize but this often produces an error as well as causing Unity to become unstable at times.

    I also understand the reasoning for the current limitations as detailed in a number of threads, but that doesn't particularly change the need. As a happy alternative I might even accept if UnityEngine.Object derived things would expose their GUID/LocalId (since this is my usual use-case)