Generics serialization

Nice, refactoring made easier

 

First of all, great work! This feature simplifies so many cases and workflows.

Got a question for you. In my project I defined the following generic ScriptableObjects:

Code (CSharp):

1. using System;
2. using UnityEngine;
3.  
4. [Serializable]
5. public class BaseFoo<T> : ScriptableObject
6. {
7.   [SerializeField]
8.   private T _bar;
9. }
10.  
11. [CreateAssetMenu(menuName = "Foo", fileName = "FooSO")]
12. public class Foo : BaseFoo<float> { }

I then created an ScriptableObject asset from Foo. I also created a MonoBehaviour looking like this:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Baz : MonoBehaviour
4. {
5.     [SerializeField]
6.     private BaseFoo<float> _foo;
7. }
8.  

The field serializes and I'm able to assign my Foo ScriptableObject to the field. so that is great! However, the default search functionality for the property drawer is not finding Foo ScriptableObject (see attached screenshot).

I guess this is because Foo is derived from BaseFoo<T> and instead of being a BaseFoo<T>. Is this something that is going to be fixed or is this the intended behaviour?

 

Is it possible to support `SerializeReference` on generic type in the foreseeable future?
It just show an error message if I try to add `SerializeReference` on a field of generic type.

"This is not supported. You must create a non-generic subclass of your generic instance type and use that as the field type instead."​

 

serializing of generics is coming in 2020.1. I don't know if this includes serialize reference, however

 

Neither of 2020.1b nor 2020.2a have introduce this feature already.
In the meanwhile, Odin(Serializer) provide alternative way to serialize generic field with `SerializeReference` attribute.

 

The Newtonsoft.Json package available in the Unity asset store puts the Unity serializer to shame. It can work off the main render thread and it supports a range of generic serialization options. I prefer it because it works server-side so that I get the same serialized JSON on game clients and server.

 

Yeah, been using that for many years now but you do have to remember that the scope and purpose of it is very different to the Unity serialiser and their use can be combined. We've had polymorphic serialisation with proper UnityEngine.Object references and inspectors that look like the regular properly drawers for years now, but performance is not amazing.

Saying that, I wonder how the Json.Net package manager package behaves with AOT etc.

 

In what Unity version was this introduced? I can't seem to find it anywhere in the 2019 Release Notes.

 

Will the abstract be removed from an UnityEvent at the final release of unity 2020.1?

[EDIT] Yes they did, awesome!

 

I am also having this exact problem. Its holding me back from using generics because of this

 

Hey, I've read through this thread and I'm wondering if I understand the implications of the following point correctly:

As far as I understand, it basically means that I can do this:

Code (CSharp):

1. public class GameEventListener : MonoBehaviour
2. {
3.     public UnityEvent<GameEventArgs> Response;
4. }

Instead of this:

Code (CSharp):

1. public class TypedUnityEvent : UnityEvent<GameEventArgs> { }
2.  
3. public class GameEventListener : MonoBehaviour
4. {
5.     public TypedUnityEvent Response;
6. }

It that it? I am aware that it saves a lot of boilerplate code, but I feel like there must be more to it. You gave some examples in this thread, but they were quite difficult for me to understand and I would be thankful if someone could point me towards some simple use cases.

Secondly, I'm working on a event system and I would like to extend the code to accept different types of event args, something like this:

Code (CSharp):

1. public class GameEventListener<T> : MonoBehaviour where T : GameEventArgs
2. {
3.     public UnityEvent<T> Response;
4. }

I am aware that this is beyond the point that I quoted, but could you maybe point me towards some solution different than subclassing GameEventListener for each type of GameEventArgs? Thanks

 

Same question. I would love to directly serialize generic type by reference.

 

I get the warning "Generic MonoBehaviours are not supported!" when I call ScriptableObject.CreateInstance on a generic class extending ScriptableObject in Unity 2020.1.3f1. Shouldn't this be supported with the new generic serialization feature?

 

No. You still need to derive a concrete UnityEngine.Object derived instance for the engine to actually support it. This feature is about normal classes.

 

Thanks, good to know. Does anyone know if the feature (serialization of generic classes derived from UnityEngine.Object) is planned? This would greatly influence the design of the system I am building.

 

I’m curious on exactly this too.
I have been using (more likely abusing, tell no one) the Events as SOs idea from Ryan Hipple 2017s presentation. It’s so great specially at the prototyping phase or dropping incredibly flexible events on animations (as objects with a single hard coded function “RaiseEvent” on the animator).

The main drawback is exactly what you say, having dynamic UnityEvent<T> calls would still require creating Listeners with the corresponding response type. It gets exponentially worse with UnityEvent<T1, T2> and more.
Calling them is easy, can just RaiseEvent<T>(T value); that’s the raiser basically.
It would be great to do something like:

Code (CSharp):

1. public class Listener<T> : Monobehavior
2. {
3.     public GameEvent<T> Event;
4.     public UnityEvent<T> Response;
5.  
6.     // Register to event’s list
7.     void OnEnable();
8.  
9.     // Deregister from event’s list
10.     void OnDisable();
11.  
12. }

And say, “I want this listener to listen to Vector3s” because the event happens to output positions that could be used by sound emitters, particles systems for effects, etc

 

We need more we need serialization of generic interfaces.

class MyDamnComponent<T>:MonoBehaviour,IInterface1<T>,IInterface2{}


[SerializeField]
public IInterface1<T> variable;

 

We need even more, we need unified interface serialization for both System.Objects and UnityEngine.Objects. And it's not that hard as it appears, e.g. you just check assignee Type and handle UnityReferences with old sturdy [SerializeField] mechanism. BTW, why bother [SerializeField] at all? To get dupes after deserialization? Same for arrays/lists. If you serialize one-of-a-kind reference to object, it still behaves as a unique object after, like it was a value. Then why these overcomplicated segregation and list-of-refs rules? That's serialization racism! Just use serialization context and serialize in place if there's none. Unified [SerializeReference] must be a "new" standard (I'd rather call it just [Serialize])! Unify it ASAP; for now it's just ridiculous! And work out all the generics of course. It still warns"This is not supported" on open generic type fields in generic classes, althought it meant to be concretized on declaration.
P.S.: Incomatibility with legacy serialization system? Consider a conversion mechanism, to load as old and save as new. Everyone more or less experienced in Unity knows: that's the lesser "evil" that must be done. Serializer is the Editor's weakest point, that ruins solid C# workflow.

 

Was / is there any chance that serialization of generics (other than List and friends) will make it into 2019 LTS?

 

Since LTS is meant to be the longterm stable release, adding new features after the fact would probably be a bad idea.

 

Thank you for adding that! Do you work on the LTS team?

 

For those of you are eager to have generic type support on `SerializeReference`, here's my workaround solution:
https://github.com/quabug/GenericSerializeReference