Serialization of interfaces issue

[William Besnard]

I cannot serialize any of my interfaces: I have a set of classes that derive from monobehaviour, but implement a given interface. The value is passed properly when I drag and drop one of these behaviour from the scene, but it won't serialize (when I change the focus the stored value is gone) When I try to pass in a SerializedMonoBehaviour I get a warning and an exception, even though the class implements the interface.

I tried to add the attribute [SerializeField] or [OdinSerialize], but it did not change anything

I attached some illustrations of my problem.

Thanks!

[William Besnard]

additionally, I don't see anything from the drop list for the interface (EDIT nevermind, I saw in a previous issue that it is something you guys are aware of)

[Tor Esa Vestergaard]

Hello, and thanks for reporting this issue!

It seems like we have two different issues here. One is the exception you're getting - that was an easy one, I've just implemented a fix for that.

For now, setting the value to null and then setting it to the value you actually want will prevent that error from showing up. It should be fairly harmless, though; even when you get it, the value should still be set properly.

Now, the second issue is more tricky. I can't replicate just losing the interface value when I change the selection - it's all saved properly, as long as the interface field is declared on a SerializedMonoBehaviour-derived component. I can replicate losing the value when I apply instance changes to the prefab. That is a currently known bug that we're working on a solution to. Right now, if you refer to scene objects in a prefab instance, and then apply changes in that instance to the prefab, references to those scene objects will disappear.

Does that conform to what you're experiencing? If not, then I'm afraid I've been unable to replicate it, and will need a fuller set of example code that I can run and test.

[William Besnard]

Hi, and thanks for the super fast answer!

The first workaround also works for me, so that's great. For the second issue, I think I found a better way to reproduce it. To give a bit more context, it seems like the value is lost when you have two SerializedMonoBehaviour trying to reference the same interface, even when referencing two different objects ( I attached few images to illustrate) I do try to put these references on an instance of a prefab, but I do not lose the value when applying the changes to the prefab as all these references are within the same prefab: could that be the source of the issue?

On the STEP 1 image, this exception pops but gets cleared with your workaround, the reference isnt lost by changing the focus nor by applying the changes to the prefab On the Step 2 I try to reference another interface on another object (in that very case on the one I just referenced in the first class, but that would also work with any other SerializedBehaviour On the Step 3 I select back the first object I selected, and see that the interface reference has changed. that is true for that precise case, but in other cases the reference is entirely lost Here are some extract of these 3 classes:

The same can be reproduced in other situations:

The first interface that was linked is gone when it is selected again for a different object (the two classes also derive from SerializedMonoBehavior)

Does that help more identifying the problem?

[Tor Esa Vestergaard]

Alright, that helped me reproduce it, thanks. It seems that the issue happens when you have an interface reference in a subordinate prefab gameobject (A), to a different object in the same prefab (B), and then select the "root" gameobject of the prefab (C) (or just one that's higher up in the prefab hierarchy, not sure yet). When the root gameobject is selected, A's interface reference to B disappears for some reason.

This is seemingly a very odd case you've stumbled into, here! I'm not really sure what's going on exactly, though I have some suspicions. Definitely related to the prefabs though. I will be investigating this issue promptly, but it looks like it'll be one of the really "interesting" ones to debug, and it's 2:30 am here in Denmark, so I don't think I'm up for it right now :D I'll get on it first thing tomorrow, though, and let you know how it goes. Hopefully I'll have a hotfix available for you with relative promptness, or at least a status update.

Meanwhile, I'm afraid it seems like you'll need to avoid triggering this particular case. Sorry for the inconvenience.

[William Besnard]

Thanks for your dedication :) In the mean time I will try to break the prefab instance and see if the problem occurs or not. I'm writing from Poland so I'm also up late :D

[William Besnard]

Hi, I can confirm that breaking the prefab instance does solve the issue: it is surely only linked to the prefab as you said.

[Tor Esa Vestergaard]

To give you an update on this, I've fixed a lot of issues with Odin-serialized Unity object references in prefabs. Required some fairly extensive changes here and there, though, so we're currently doing a thorough testing run, throwing totally crazy stuff at it and trying to break it apart, to see if it works, and if we accidentally broke something else. The good news is that in my current build, I have been completely unable to provoke this issue in any way, despite trying rather hard at it - so it looks like it was indeed a symptom of many of the other prefab issues we'd been running into.

If you send me an email at [e-mail] with your invoice number in it, I'll make sure to send you a build including the fixes once we've finishing putting the new code through its paces. Then, if you confirm that the issue is fixed, I'll mark this issue resolved.

[Tor Esa Vestergaard]

Just noticed this issue wasn't actually opened - whoops.

[William Besnard]

thanks a lot for the update, I'm sending you an email with my invoice number right away. It hasn't been such a big blocker, as simply breaking the prefab instance allowed me to go on with the development. I'll definitely rely as much as I can on direct class reference instead of interfaces references though :)