SerializeReference Attribute?

Experiencing the same thing. And the editor crashes every other minute when trying to work with this feature.

 

Do you plan guys to add support to serialize template classes without declaring specialized type?

Code (csharp):

1. [Serializable]
2. public class TemplateClass<T>
3. {
4.     public T val;
5. }
6.  
7. [Serializable]
8. public class TemplateClassInt : TemplateClass<int> { }
9.  
10. public TemplateClass<int> intClass1;
11. public TemplateClassInt intClass2;

intClass1 is not shown in the inspector

 

The doc link is broken, and searching for SerializeReference in the Manual or Scripting API pages for 2019.3 returns no results :/

 

This looks beautiful! I've tried it out (exact same code) in Unity 2019.3.0a11, the Trees field appears in the Editor but it is broken! (just shows a list of labels with no ability to add or edit anything) Is that normal?

 

Might I ask why? It really bothers me, as even Unity falls into this trap from time to time. Addressables and UnityEvents, for example, have clunky workarounds because of that. And we know it is possible from a usability standpoint. Odin Serializer is very much capable of working in tandem with Unity's serializer where the second can't, so I can't imagine why Unity's serializer couldn't use a hybrid approach to it, even if using the current way to do it is theoretically impossible. You'd just have to do it a different way wherever it is required.

Using generics in Unity is a nightmare the way it currently works (as in, it doesn't). In my last project I had to do so many workarounds to be able to serialize everything I needed that in the end I just gave up and refactored everything to go with Odin Serializer so my code could look like it should.

 

Such a shame in 2019...

 

This usage case is very close to what I am using this for. However, I could not get it to work at first. The elements in m_Trees were serializing references correctly, but the [SerializeReference] fields in the derived classes were not being serialized at all.

My Node class did not derive from anything, so noticing that in this example the base class was an interface I tried doing that and converting all my references in the derived classes to interface references. Then all the serialization worked as I had hoped!

Is it really the case that a class can't serialize its own type reference? It's not a problem to add the extra interface but I was wondering why using an interface "middle-man" makes this work.

 

Actually what I was seeing is that in your example, Root would serialize fine, but left and right would not. I'm not sure about extraData, but it probably would. It only seems to be self-referencing type fields that have the issue. Adding an "INode" interface to the Node class and changing left and right fields to be of INode type would get it to serialize correctly.

 

A quick sanity check here: all class definitions in your hierarchy are marked with the [System.Serializable] attribute, yes?

 

Here is a concrete example with results.

With the code set up like:

Code (CSharp):

1. public interface IFlowNode { }
2.  
3. [System.Serializable]
4. public class FlowNode : IFlowNode
5. {
6.     public FlowNodeId Id;
7.     public FlowChart Chart;
8.     public FlowSegment Segment;
9.     [SerializeReference] public IFlowNode Next;
10.     [SerializeReference] public IFlowNode Prev;
11.     public FlowRunMode RunMode;
12.     public FlowRunClause RunClause;
13. }

It serializes the references correctly. Here is the serialized output to the .asset file:

00000001:

  type: {class: FlowNode, ns: PF.Core, asm: Assembly-CSharp}

  data:

    Id:

      Index: 0

      Revision: 0

    Chart: {fileID: 0}

    Segment: 0

    Next:

      id: 6

    Prev:

      id: 5

    RunMode: 0

    RunClause: 0

However, with the code set up like:

Code (CSharp):

1. [System.Serializable]
2. public class FlowNode
3. {
4.     public FlowNodeId Id;
5.     public FlowChart Chart;
6.     public FlowSegment Segment;
7.     [SerializeReference] public FlowNode Next;
8.     [SerializeReference] public FlowNode Prev;
9.     public FlowRunMode RunMode;
10.     public FlowRunClause RunClause;
11. }

The serialized result completely ignores the FlowNode fields:

00000001:

  type: {class: FlowNode, ns: PF.Core, asm: Assembly-CSharp}

  data:

    Id:

      Index: 0

      Revision: 0

    Chart: {fileID: 0}

    Segment: 0

    RunMode: 0

    RunClause: 0

 

Wow! I am waiting for this feature for my personal framework forever. Do you have a time machine which is going forward in time faster than the standard 1 second per second rate? I want to be in 2020 today.

 

Nice

 

That is great! How does this work with custom editors?

 

FINALLY

 

I guess that would be even bigger Unite announcement than nested prefabs)

 

If the class name changes, the reference will be lost. Is it possible to store by GUID instead of the class name.

 

Woah. Does it mean this is going to work?

Code (CSharp):

1. public UnityEvent<int> eventWithAnInt;

I have like thirty wrapper classes for UnityEvent since I can't use it directly with template arguments in the inspector.

 

I am late to the party but wanted to chime in and say this is excellent news! Kicking goals, Unity serialisation team! I assume DoctorShinobi's case would be supported by this? Could we get a confirmation?

I have similar use cases - a generic class that I need to inherit every time just to specify the type so it is serializable.

Can the type T be any type, or are there limitations? Would it work fine if T was GameObject, or MonoBehaviour? Or must it be a plain old serializable class?

 

I would hazard a guess that if manually specializing it works, then leaving it in its raw generic form will work @Prodigga

 

Code (CSharp):

1. Generating diff  of this object for undo because the type tree changed.
2. This happens if you have used Undo.RecordObject when changing the script property.
3. Please use Undo.RegisterCompleteObjectUndo

Everytime when i trying to record object with [SerializeReference] attribute.

 

I reported a bug for it already:
https://forum.unity.com/threads/cas...or-undo-because-the-type-tree-changed.737390/

 

Is that also mean that, there could be a Dictionary serialization support in 2020.1 ?

 

Hi all,

I'm trying to figure out why this thing is that massive. Could someone explain why is it a great thing ?
I'm kind of new to C# and Unity, but if I can learn something to improve, I'll go for it !

 

Probably not, they're quite unrelated issues

 

It's for when you need to save/load data. If you use OOP features such as inheritance (to store many different Types in the same list, for example) you cannot easily save the data to a file. It will only save the serializable fields (strings, ints, etc) data of the base class and ignore the data from the children. This means you have to make an entirely different "saveable" or simplified version of each class (or use a better serializer system), which is harder when there are references to other things, because you will need a unique ID of some kind.

It looks like when SerializeReference is bug-free, I will just be able to put it on my class and it will save/load perfectly.

The best way to see serialized data is by making a ScriptableObject with some public fields, then you can open the asset in notepad, and see the data that was saved as YAML at the bottom.

 

Thank you for the explanation
It doesn't fully make sense, but it gives me an idea. We didn't tackle the save/load system yet, but I'll definitely check this out. Where can I find further information on the subject ?

 

Google is your friend.

But here are some resources:

• Unity Manual - Script Serialization (note that currently [2019.2] there is a section at the bottom that reads "No support for polymorphism").
• Unity Serialization Blog Entry c.2012
• Unity Serialization Blog Entry c.2014

All of the above strongly point out that you cannot type serialized fields using Interfaces, Abstract Classes, or a base class as the current serializer has zero support for it. This is why things like Odin exist and why everyone is so excited that Unity finally added support for some of the missing serialization features.

 

I'm experiencing an issue when duplicating/cloning the object. The references of the polymorphic object ([SerializeReference]) that refer to the game object or its components being duplicated are not updated. For instance when I duplicate a game object with a script named Foo that has a property holding the value of type Bar (serialized POCO) and it holds a reference to the game object being duplicated (Foo.bar.gameObject = Foo.gameObject) I end up with two scripts referring to one game object. When object is serialized by value ([SerializedField]) the references to the objects are properly copied/updated.
I hope this is something that will be changed/fixed in future releases? Otherwise the feature is quite useless.

 

But why? What in the design of the serialization system causes this deal-breaker? For a lot of people, I'm assuming. All that the assumed people and I need out of this feature is to be able to serialize a field that takes a MonoBehaviour that implements a specific interface.

 

+1

 

If I had to guess, most likely how it instantiates the classes on deserialization; using the method that every other class uses wouldn't work for UnityEngine.Object

Granted, I don't see why they don't just add a custom factory that uses the AssetDatabase for UnityEngine.Objects, but who knows, there may be something I'm not seeing

 

Guessing here, myself, but I think you're basically right. The added complication is that UnityEngine.Object references are properly restored, whereas POCOs are duplicated wherever a single reference was originally shared. To handle this guarantee in the serialization system would likely require additional metadata and, thus, changes to the serialization format itself. I'd be willing to bet that the code to serialize UnityEngine.Objects is both more complex and far deeper in the codebase and isn't something they are interested in touching...

 

It's for much, much more than that! (hint: the entire Editor is implemented via Serialization. Typically merely clicking things in the Inspector, or selecting objects, will break without correct Serialization).

...hence the huge excitement. This takes a lot of code that is correct C#, but bizarrely corrupts/breaks/decouples itself when running in Unity (and at unpredictable moments), and makes it Just Work. The traditional workaround has been to "write lower quality C# code (that avoids using many of the most important features of the C# language, because they break Unity)" or "write huge amounts of complex workarounds / buy complex workarounds from the asset store".