Unity 2018.2.0b7 / FlowCanvas 2.8 exception during deserialization

Forums General Discussion Unity 2018.2.0b7 / FlowCanvas 2.8 exception during deserialization

This topic contains 4 replies, has 2 voices, and was last updated by  Gavalakis 10 months, 4 weeks ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #1832



    I recently tried upgrading our project to Unity 2018.2.0b7. The game runs correctly within the Editor, but I get a bunch of errors like the ones below when I attempt to build a stand-alone Win64 player. This prevents us from moving our game to Unity 2018.2.

    Example callstack:

    The gist of this seems to be that AnimationCurve.GetKeys() (a Unity API method) is not allowed to be called from
    within ISerializationCallbackReceiver.OnAfterDeserialize().

    At least one – and probablly all – graphs which exhibit this problem contain a node which references an AnimationCurve like this:

    Now I’m not 100% certain, but I suspect that this is the story: when Unity decides that it is time to deserialize, it will begin deserialization of a lot of things, across multiple threads. It will invoke OnAfterDeserialize() for each object right after deserialization has completed for that particular item. At that point in time you cannot be sure that all other items also have completed deserialization, and therefore the API remains in “serialization ongoing, do not disturb” mode even whileOnAfterDeserialize() is triggered for some objects. This causes potential problems for all the *_DirectConverter classes. Again, not 100% sure if this is the problem, and if so, if this is intended behaviour or a bug in Unity 2018.2.




    Thanks for letting me know. NodeCanvas indeed does use the OnAfterDeserialize to deserialize all things that need deserialization (graphs and blackboards more specifically).

    Unity has a bad habit of changing critical things like these. I also don’t know if Unity changing this was intentional or a bug, but to me it seems un-intentional, since keyframe[] should be possible to access like most other “normal” API can.

    I will try to find an alternative solution (probably with a reflection hack) to get this working, or maybe Unity changes/fix this in a later version.

    Is it possible for you to remain on your current Unity version? If not, let me know and I will take a look at this sooner for you.
    Thank you.



    We are considering moving to 2018.x within the next few months. This is the only blocker that we know of. I can’t seem to find any good way to get more info on this on a timely manner from Unity themselves (looking at reference C# code, …)

    If you can find a workaround, that would be appreciated.



    Good news: This has been reported, and fixed, in the latest 2018.2 beta.

    Original Unity Issue Tracker report here

    The 2018.2.0b8 patch notes includes the note, “Animation: Fixed use of AnimationCurve scripting API in threads. (1041793)”

    I have confirmed that we can build a player without errors with 2018.2.0b9.

    In other words: no action needed on your part!



    That’s awesome and thanks for the follow up!
    I knew it was going to be one of those Unity accidents 🙂

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.