Behavior: Errors deserializing BehaviorGraph JSON after re-creating related GameObjects

Hi @adrian-miasik,

I have made tickets to investigate both of these issues. I will be looking into the type construct error today & we will look into the other asap.

Thanks for reporting!

1 Like

For this issue, I am still investigating. It seems like something is going wrong with polymorphism & inheritance in this case & it’s tricky to track down.

For now, a workaround could be using the base type inside the graphs, you can then cast inside your node yourself if you need the child class functions.

I believe I have now found a fix for the type cast issue.

I need to write some more tests to be sure but we should have this fix out in the next release.
There should be workarounds you can do for now to continue making progress, let me know if you need help with any of those.

1 Like

Impressed you’ve got a fix for the type cast issue so quickly. Very fast turnaround for identifying and implementing a fix! (Good workaround solution too) I’ll resort to using base classes and cast into their specific types in the meantime/perhaps wait for the next package update.

But I’m mostly blocked on the different node states on deserialization, any guidance there would be appreciated. :pray:

I’ve also looked through the Unity issue tracker and couldn’t find any new tickets related. If the tickets are public could you please link me so I can track their resolution? Cheers

Thanks! The PR is up for it now. I can let you know once it’s merged, thanks for the report. The issue was inside our serialization package in the end.

I will start looking at your other repo project soon and investigate that myself also.
I have a few things to wrap up before then, so I will start investigation tomorrow.

Sorry that you are experiencing these difficulties, but your reports are invaluable for us solving these quickly so thanks very much doing so.

I am not sure how to workaround your current problem yet, so I will get back to you when I understand the issue more :slight_smile:

There are no tickets up for these issues at the moment, I just went straight for fixing.

Thanks again for your patience!

1 Like

Okay understood, i’ll change gears and will revisit behavior graph a bit later.
Please do let me know how it goes! :slight_smile:

I have started to look into the issue today @adrian-miasik. I will keep you updated!

Hi Again!

I spent a long time today trying to figure out exactly what the issue was. I did not manage to solve it easily.

But what I did do, is make a replication of what you were trying to achieve from our sample.
I may also update our sample in the future to include some of these additions once cleaned up.

Hopefully this should help you achieve what you want to, unless I am mistaken there seems to be an error somewhere in your current setup. Not sure if it’s our fault, or something you did.

I tried to strip things down until I could repro in the most basic form & by swapping to our navigation node without your QueueSlot / QueueBase or new navigation node & I could still repro in your project.

So in my package example, I do not include those for now as they didn’t seem to be the cause, maybe something to do with your saving could be the root cause, I am not sure.

But restarting fresh allowed me to get to this package state below which is what I believe you were trying to achieve :slight_smile: Please let me know if this helps!

In this sample, you can serialize & deserialize between play mode playthrough’s similar to what you had in your sample.

ReplicateUsersProblem.unitypackage (45.3 KB)

Heya,

I’ve messed around with the package and yeah this sort of is what I am trying to achieve, though I’m still noticing some issues in the provided package.

The good news is that yes, I can now see that the navigation node is running and the final log node does execute with correct debug statuses.

However, the “Choose Target Position” node still doesn’t show a status on debug mode. While the “Choose Target Position” code still runs and the saved/loaded JSON indicates the node status as 2 (Success), I don’t see it appear in the behavior graph window. Nor does the behavior graph path/branch highlight in blue.

Can you please confirm you’re getting the same results here?

When I debug to an agent:

As soon as I deserialize/load, and debug to the same agent:

{
  "$type": "Unity.Behavior.SerializationExample.ChooseTargetPosition, Assembly-CSharp",
  "CurrentStatus": 2,
  "TargetPosition": {
      "$id": 4,
      "GUID": "a9e5ffaa6712c3bca2466c9637b65fa4",
      "Name": "Target Position",
      "m_Value": {
          "x": -3.365585,
          "y": 0,
          "z": -6.944277
      }
  },
  "Min": {
      "GUID": "",
      "Name": "",
      "m_Value": {
          "x": -20,
          "y": 0,
          "z": -20
      }
  },
  "Max": {
      "GUID": "",
      "Name": "",
      "m_Value": {
          "x": 20,
          "y": 0,
          "z": 20
      }
  }
},

Raises some questions:

  • Are processed/succeeded nodes not recovered on deserialization?
  • Perhaps it’s the sequence node that is only keeping track of the current child? So upon deseralization only the current child is recovered? (Even if so, the inactive choose position node eventually runs and is unable to produce a debug status/trigger a breakpoint via the graph window. Unlikely related.)

Something of note:
I seem to only be experiencing these problems when I exit play mode, enter play mode, and attempt a load. When the saving/loading is done in the same play session. Debugger works fine, and I don’t run into these issues. (Though I haven’t fully confirmed that)


Sadly, even restarting fresh these issues still persist. I have yet to see an example of the behavior graph fully saving and loading properly between runtimes. Edit: Processed (Success/Failure) nodes are ignored as indicated in comment #31.

I’m not sure what the root issue could be, and I’m really not sure where else to investigate either. :frowning_face:

Hi Adrian,

Just to answer this specific message, the behavior you are describing is currently expected.

Yes, you are right, we only serialized currently running or waiting nodes, so deserializing would not show previously completed (success or failure) nodes. This is done in part to reduce the size of the serialized string and make the serialization faster when working with big graphs.

Hope this helps.

1 Like

Hello @MorganHoarauUnity,

Thanks for clearing that up!

100% makes sense on why you wouldn’t want to serialize something that doesn’t need to be for improved performance/smaller size. It would be nice if this tidbit could be included in the documentation somewhere indicating what gets serialized and what doesn’t, to avoid any confusions.

I also know you were just addressing those specific questions, but just to highlight the concern so it’s not missed, the “Choose Target Position” node never shows a debug status state, nor triggers a breakpoint ever again…upon loading in the case above.

Once again, thanks for clarifying my questions.
Always appreciated :slight_smile:

I’m going to try to rebuilding my behavior graph from scratch again to see if that fixes my issues. But it would be nice to find the underlying cause of this. I hope I don’t have to rebuild my graphs/nodes from scratch everytime I run into this.

Will report back later this week.

Definitely let me know what you find @adrian-miasik & I can investigate.