[BUG] Using it in List makes all of the same type be a single reference
What happened?
In most cases when you add an element with the same type on a list, they have the same reference, so when I edit one of the, the other also get editted.
On the following image, whenever I change "Burn" to anything, both changes. Look that 'Element 2' is of the same type but I can set another value for 'Status Effects', don't know why on this one worked ok.

Also, sometimes the layout of the inspector is not resized correctly when you change types.
(and I'd say its better empty than
Package Version
1.1.6
Unity Version
2020.3.3f1
Now I've seen that is like a duplicate from this issue but didn't get solved, so I guess the issue still exists.
Also on my test, I got the Element 2 that was not the same reference (really odd), so guess it should be avaliated.
Well, I guess that when you select the desired type it creates a new instance of the object via an Instantiator like Activator.CreateInstance(objectType) or something like it, so it should be different reference then the other elements, right?
Hi.
Since this functionality is implemented by PropertyDrawer, it is impossible to customize the behavior of the array in the inspector.
Basically this is a Unity specification and therefore difficult to fix.
Originally, SerializeReference is used to serialize node references of node-based features, etc., so it is undesirable behavior for references to be changed.
If you want to customize the behavior of an array, you will need to extend the editor.
- Create a custom inspector inheriting from
UnityEditor.Editor. - Use
ReorderableListto display theSerializeReferencearray and observe the addition of elements. - When an element is added, set its reference to null.
I hope this helps.
Also, sometimes the layout of the inspector is not resized correctly when you change types. (and I'd say its better empty than for the "missing type select")
This has been fixed in Unity 2020.3.31. https://github.com/mackysoft/Unity-SerializeReferenceExtensions/issues/9#issuecomment-1085368327