What does this error mean exactly?

THANK YOU! I just had this happen 2018.3, and a restart saved me tons of time trying to figure out the issue.

 

I hate to bump, but I feel it's necessary to report that this is indeed still an issue in 2018.3.5f1.
Spent an hour scratching my head at it until I came across this thread, and like the recent posts are saying, restarting Unity does fix it for now.

 

Restarting Unity doesn't work for me. Is it fine to just ignore this error? :/

 

I had the same error. Even after fixing the actual error in my classes, the error persisted in Unity. This was only fixed by deleting the complete Library and obj folder in my project, thus reimporting everything.

 

I had this problem when using abstract classes.
I was declaring a variable in the main abstract class, then again in a class that inherited this one => this error

 

just re-import the code that have the error and it will get fixed. its just unity thing

 

So horrible trying to deal with some error like this that has nothing to do with compiler

 

"The same field name is serialized multiple times in the class or its parent class. This is not supported: Base(EnemyMiniFly) _timeBtwAttack"

this works for me.



I switched this:

Code (CSharp):

1. private float _timeBtwAttack = 0;

for this:

Code (CSharp):

1. private new float _timeBtwAttack = 0;

 

Most of the time when you need "the same variable twice", instead of creating a duplicate and potentially hiding it (using new), you often actually want to access this variable from your base class. For this you can make a variable protected, which basically means private to this class and all subclasses. I personally never really used 'new' for inheritance and consider it a very rare corner case.

 

Not sure if this is the case for other people, but any time I encounter this error, it isn't because I'm defining the same variable name in a parent/child child class (besides, you'd be getting warnings about that), it just happens seemingly at random.

The most recent case I had was really strange, because I had a class structure similar to this...

Code (CSharp):

1. public abstract class Parent : MonoBehaviour {
2.    private float parentField;
3. }
4.  
5. public class Child : Parent {
6.    private float field;
7. }

...And it was throwing the error with "field" in the Child class, even though the Parent class doesn't have a variable with the same name.
The error stopped occurring after I renamed the variable to something more specific:

Code (CSharp):

1. public class Child : Parent {
2.    private float childField;
3. }

Is it just the fact that both variable names contained the same word, case-insensitive ("field")? It can't be, otherwise "childField" should throw the same error, but it doesn't.

I have no idea what causes it or what fixes it.

 

I saw someone suggest rebooting the editor and script editor in an earlier reply, and that did the trick.

I'll explain my case in case that helps someone in a similar situation find this solution.

When I got this error it was because I had a ScriptableObjectB with a [SerializeField] private field that I deleted and then put in ScriptableObjectA (which was the parent of ScriptableObjectB).

I saved all my scripts in VS Community and saved my project in unity editor. Then rebooted both Editor and VS Community and the error went away.

I'm assuming it was because Unity Editor had some kind of cache of the ScriptableObjectB's field that it was holding onto even though i had removed the ScriptableObjectB's declaration of it in the script.

 

No, that's not a "fix". The issue here is that as most hopefully know Unity *usually* does not serialize private fields unless they have the SerializeField attribute.

However
Unity does serialize private fields in certain cases. Please read the last paragraph on the script serialization page. Though if you haven't seen this documentation page ever before I strongly recommend to read it completely, a couple of times ^^.

While from a pure OOP point of view it's true that private variables are private and no one should care about them except the class itself. However from a conceptional point of view there are very very rare cases where you would have the same private variable name in both the base class and a derived class. Keep in mind that, even the variables are private, they are still part of the derived class, just not directly accessible by the derived class. Variable names represent their purpose. Redefining a variable in a child class doesn't make much sense in most cases.

Analogies to biological inheritance are often hard to grasp since genetical inheritance works vastly different from class inheritance. Anyways try to envision this: Imagine you inherit your heart from your mother. You only have one heart and it has a certain purpose in the class. Redeclaring a variable is like having two hearts (one inherited and one newly added through mutation?). Both exist in the same body at the same time and both are working. However they somehow are responsible for different parts of your body.

Back to code. Yes there are situations where you may have an encapsulated private field on the base class for a certain purpose and you may need a similar field for a slightly different purpose in the derived class. Since variable names are bound to the human language we have to deal with multiple meanings of the same words all the time and this is no exception. However in almost all cases when you end up with the same variable name as it was used in the base class you either:

• Have used a bad, non descriptive variable name so it's easy to accidentally use it again (like "i" or "obj").
• or you new variable should actually serve the same purpose in which case it shouldn't be redefined. Instead you should make the field either protected or when having a wrapping property, have a protected setter so you can use it in your derived class.

By reading through this thread in most cases ppl just want to assign a class specific value to a variable. Redefining the variable does not do that. Like explained in the above mentioned SO question you can not "override" variables or fields. Many seem to look for a neat solution like field initializers to easily give a variable a class specific value. However this does not work for derived fields because field initializers are required to run even before the constructor runs. So when using a derived field you have to set the class specific value in the constructor. If the value we talk about is a "class specific constant", the best option here is to use a virtual readonly property. That way you can simply override it in the derived class and return whatever value you want.

Spoiler: Virtual Property Example

Code (CSharp):

1.     public class BaseC
2.     {
3.         public virtual string TypeName => "Base name";
4.     }
5.     public class DerivedC : BaseC
6.     {
7.         public override string TypeName => "Derived name";
8.     }
9.  

A common solution for more complex class specific "constants" like other classes is using a protected method which takes care of the creation of that object for the class. So a derived class can exchange the creation of the class but the encapsulation is still inside the base class.

Spoiler: Virtual Initializer Method Example

Code (CSharp):

1.  
2.     public class BaseC
3.     {
4.         public IReadOnlyList<string> Value { get; private set; }
5.         public BaseC()
6.         {
7.             Value = CreateValueList();
8.         }
9.         protected virtual IReadOnlyList<string> CreateValueList()
10.         {
11.             return new string[] { "One", "Two", "Three" };
12.         }
13.     }
14.     public class DerivedC : BaseC
15.     {
16.         protected override IReadOnlyList<string> CreateValueList()
17.         {
18.             // provide different implementation if needed.
19.             return new string[] { "123", "456", "789" };
20.         }
21.     }
22.  

In this example the Value property is read only from the outside and provides a reference to a certain object. The initialization of the property is done by the constructor of the base class but the actual creation of that object can be exchanged in a derived class.

 

Hi guys, a bit late well I had same issue in august 2020 when first came to this thread.
my personal observation as I had an issue with scriptable object where I deleted a SO and replaced it with a different class that had same field/properties/methods etc and removed inheritance from scriptable object to regular class. Unity was still under the impression that this new class was implementing fields and properties from previous class.
solution:
removing any dependencies of new class the deleting it
restoring the previous class then removing any dependencies then deleting it save project exit
reload unity add my new class no more issue.
So I guess persistence of some class like scriptable object or serialized fields would survive if you don't remove all reference to them from code/scene before removing altering them simply put
revert to before error happens clean then do what ever you were about to do

 

Certainly a strange error with still nearly 10 years later has no 'real' answer. Crazy. Had this error happen 71 times for my one scriptable object when i was creating a new one with my menu button. never seen the error before in the 5 years i have used unity, so i looked it up in google and first link was this page. After reading basically every post beginning to end i decided to just clear the console, and try button again. nothing appeared to happen because my SO existed and i have a check in the create method to find an existing if one if found return that asset else make a new one. This was designed to not overwrite existing data if there is any. Since my SO was just created and were testing out things still, I then deleted my SO and pressed the button again too create another new one. well this time no errors popped up And the SO created properly. I will add that when it made the SO the First time and did get errors, upon looking at the SO in the inspector all looked normal so the error really just confused the hell outta me and had to look it up. I did nothing but retry my button and it worked. no restart nothing. I guess when this error pops up even in Unity 2020+ just ignore it....... I dunno what else to say honestly.

CHeers,
Thamas Bell -> ZeredaGames

 

Is there any way if I want to have private members in both parent and child?

 

What exactly would be the usecase of that? You know that, given your example of class A and class B, that and instance of class B is also an instance of class A. So class B essentially would have the same field twice, one accessible and one in accessible from inside B but they are both there. When those variables need to be serialized you will have a problem as a single instance of your class B will have two seperate fields with the exact same name. Can you show me any practical example where you would need this?

Keep in mind if you want a field that is not public but can be used by derived classes, make it protected and you're done.

Code (CSharp):

1. public class A : MonoBehaviour
2. {
3.     protected int wiredMessageFireField;
4. }
5.  
6. public class B : A
7. {
8. }
9.  

Here both class A and B will have access to the field "wiredMessageFireField" but from the outside it is private. That's just normal inheritance. Technically having private fields with the same name in the parent and child class is possible. However any serialization system (which generally poke around in private fields as well) will trip on such constructs as there's a name collision.

Note that Unity "usually" does not serialize private fields unless marked with the "SerializeField" attribute. However inside the editor during hot reloads Unity does serialize all supported instance variables including private variables not marked with SerializeField. You can prevent this by marking your fields with NonSerialized as mentioned over here at the very bottom.

Again, if you really need / want to declare the same variable in a parent and child class it's a strong indication for a flawed design.

 

Guess what? This is still happening in ver 2021.1. And the error gone after I restart Unity and VSCode.

 

I was getting this error from one of my editor scripts that checks for missing references in scripts.

Code (CSharp):

1. The same field name is serialized multiple times in the class or its parent class. This is not supported: Base(MonoBehaviour) on UnityEditor.SerializedObject:.ctor

It confused me until I realized it was referencing a different script than the error pointed to. There was in fact 2 errors, and the second error told me the real variable that was the culprit. I then got confused because I was not a script inheriting from another base script. It was then I realized I was using the variable name on a script I forgot inherited from the base script I was editing.

 

Happened to me, too. I had just been copy-pasting some objects that had monobehaviours with serialized fields, and due to copy-pasting had duplicate object references that needed to be manually rewired. The messiness was expected due to duplicate references. Anyhoo, hot this error while cleaning those up.

Unity restart -> gone.

 

You can also get this error with:

Code (CSharp):

1.  
2. public abstract class Buff : MonoBehaviour {
3.     public virtual BuffMode Mode { get; set; } = BuffMode.Passive;
4. }
5.  
6. public class SpeedBoostShip : Buff {
7.     public override BuffMode Mode { get; set; } = BuffMode.Ship;
8. }
9.  

 

its kinda old, but if u inhert from a class, dont use the same name in the new class as from the base class

 

I just go this while refreshing the code. I didn't even change anything to a serialized type in a while as I avoid MonoBehaviours as much as possible.

Code (CSharp):

1. The same field name is serialized multiple times in the class or its parent class. This is not supported: Base(Tile) m_data
2.  

I do have a class called Tile and it does have a m_data field, and it does inherit a class that also has a m_data field. This is all part of my design. The thing is, Tile is not serializable and neither is the base class. They are only used at runtime so I have no idea why on earth would that error pop up.

 

Unity seems to visit all your member definitions during serialization even if they aren't going to be serialized. That's probably a bug, but I would still question the design choice. If you're essentially re-declaring the same variable in another part of the inheritance structure then the base member should probably be protected instead of private. If some inheritors don't use that variable (and therefore making it protected would include it where it's not needed) then it sounds like your design is violating a boundary somewhere.

 

I get that it's a bit weird but it's been more than a year since I've had it like this and it didn't create any issues. I essentially have a hierarchy of entities ranging from a stack of resources to buildings and humans all on a grid. For every type of entity (with some being abstract), I also have an associated data structure which follows the exact same hierarchy. These are scriptable objects so I can populate the game data. Note that GameObjects are not used except as a front end for rendering but no MonoBehaviours. Now, functions implemented in each entity class have access to a private m_data that is of the associated type so essentially each layer of the hierarchy redefines the m_data. It's the same value in all layers but of a different more extended type as the hierarchy goes deeper. I do end up storing it multiple times, but each time just a pointer/reference is stored so it's not that big of a deal. It is a bit shady but I'm not sure how else I could've achieved it without having to cast it every time or give up on having common base classes. This way I can have a List<Entity> but if it'd be some sort of generic I couldn't just List<Entity<WHAT_TYPE_HERE?>>. Sure, it's dodgy design in a sense, but hey, it works. I am interested in alternatives tho. Being used to mostly using C++ I miss some features and maybe I'm missing something about how C# can be used but afaik, there's nothing like reinterpret/god cast that just result in 0 CPU instructions.

 

Sounds like you'd want a generic constraint at the class level then.

Code (csharp):

1.  
2. public abstract class EntityContainer<T>
3. {
4.     protected List<Entity<T>> m_data;
5. }
6.  
7. public class SomeContainer<SomeType>
8. {
9.     // m_data is of type List<Entity<SomeType>>
10. }
11.  

 

I don't think you quite understood what I'm talking about:
So, there's a class called Entity at the root, then there's a Constructible class that inherits it, a Building class that inherits Constructible and then let's say a ConstructionTable that inherits the Building class. For each of those there's the same data hierarchy, so you have EntityData, ConstructibleData which inherits EntityData, BuildingData which inherits ConstructibleData and ConstructionTableData which inherits a BuildingData. Each class in the entity hierarchy has a field to the appropriate data. Like Entity has the private "EntityData m_data" field, then Constructible has "ConstructibleData m_data", Building has "BuildingData m_data" and so on. All m_data fields point to the same thing but it's just more and more specific as you go up.

Using Entity<T> where T : EntityData would be useless since then I can't just put different entities in a list or for instance, different Constructibles.

 

That sentence doesn't make any sense to me. Either you're pointing to the same data, in which case the field can be protected, or you aren't in which case it seems weird to re-declare in each type when the types are all related to each other.

This sounds super complex and confusing. What are you gaining from having an inheritance tree this deep?

Again, this stuff is technically legal and is just an issue because of an apparent bug in Unity's serialization pipeline. But it definitely seems smelly to me.

 

I'm on Unity 2021.2 and I started encountering this error. The issue started when I added member variables to an abstract class that derived from Monobehaviour. Suggestions in this thread didn't work: Restarting unity editor didn't solve the problem for me, marking the member-variables as protected didn't help me.

My conclusion: Until Unity can offer clarity on this, I'll avoid combining c# abstract classes with monobehavior. Instead, I'll follow the ECS pattern and create components to handle complexity and code re-use.

This is frustrating to me, and I hope it changes, but it's easier to adhere to this pattern than it is to fight obscure error messages.

 

@bradford And you are sure, that you do not have the same field twice in the same class? Keep in mind that a private field in the base class would clash with a private field in a derived class with the same name. You just bumped this thread but you haven't really added any useful information. At least provide details on your case or at least a reproduction case.

 

> And you are sure, that you do not have the same field twice in the same class?

Positive.

> You just bumped this thread but you haven't really added any useful information.

If you view the thread as a bug report, you're correct, I haven't provided any useful information. If you view the thread from the perspective of someone coming here looking for support, I'd hope that my suggestion of using components instead of inheritance provides a possible workaround. (I found no similiar suggestion when I encountered the error, and I would have saved myself some search time had it been suggested).

> At least provide details on your case or at least a reproduction case.

I've been able to reproduce the error in an empty project by following the below steps, but do note caveats below.

1. create three classes:

Code (CSharp):

1.  
2. // an abstract class with a public variable:
3. public abstract class AbstractClass : MonoBehaviour
4. {
5.     public RectTransform basePanel;
6. }
7.  
8. // class that derives from Abstract class
9. public class DerivedClass : AbstractClass
10. {
11. }
12.  
13. // derived class, doesn't yet inherit from
14. // abstract class, but will (in step 2).
15. public class DerivedClass2 : MonoBehaviour
16. {
17.     public RectTransform basePanel;
18. }
19.  

2. Attach DerivedClass and DerivedClass2 to empty objects in the scene, assign a gameobject to the basePanel field.
3. refactor DerivedClass2 so that it inherits from AbstractClass, and remove the existing basePanel instance (which is no longer needed, now that it's defined in the base class).

Code (CSharp):

1.  
2. public class DerivedClass2 : AbstractClass
3. {
4. }
5.  

This resulted in the aforementioned error for me. In the above case, I was able to fix the error by restarting the editor. In my larger, more invested project, restarting the editor or using protected did not solve the problem for me. I haven't been able to isolate the repro steps in the larger project, but I'll bump if it does.