Can I have multiple public variables of the same name is separate scripts?

Questions & Answers
1

Let me explain. I have 5 scripts for 5 enemies, and they all have the variable “activatedFlag” to determine when they are active and can move. These variable are declared as such:

    object class
    {
        public bool activatedFlag = true;
    
        start
        {
            if (activatedFlag == true)
            {
                do stuff;
            }
        }
    }

The variable is only changed by another script, the Game Controller. It activates and deactivates enemies. Normally its set to false.

Now I already had this working with my enemies, but I was making a new enemy and was writing it from scratch and for debugging purposes had it set to true and to public. The problem was that it wasn’t working. In the inspector, it stays false even though it’s set to true. As soon as I changed the variable to private, it began to work.

Normally, my other scripts work. They’re public and set to false, and so long as my Game Controller script changes the variables in every enemy instance on and off, they’re good. But I’m not able to get them to work if I set the individual instance to true.

Why is this?

I declare and initialize the variables in the class space, not in any function. They’re also not static so they shouldn’t be causing problems outside of the class.

Am I not able to have public variables of the same name in different scripts?

2

@gameangel147, the problems you describe are separate from the question you’re asking.

The issue of the “fantom bool” state is not of C#, but of the Unity editor. You may be setting the value to true in your code, but check the interface on the inspector in Unity and you’ll probably find it is overriding your code!

That’s actually by intent.

It also only applies to public variables. Unity’s editor doesn’t show the private variables on the inspector. This is done so you can change values, for debugging and configuration, in the Unity editor without recompiling.

As to your headline question, sure, you can have the same name in different scripts because they are each different classes. The names enclosed within a class are limited to the class, and don’t conflict with the same names in other classes. The subject is known as name mangling. Effectively, if you have class A and class B each with a bool “what”, the names of “what” are actually A::what and B::what (I know, in code you write A.what and B.what - it’s complicated, one is a scope, the other is a vector into an object - each variable has a position at some distance from the beginning of an object, and the ‘.’ operator is how that is accessed).

However, you bring up an opportunity to point something out far more important about object oriented thinking and design. It’s an important point:

Every time you find yourself doing something “again” (and again), you’ve hinted at the existence of an object you haven’t written.

In this case, your “activatedFlag” is not merely something your doing in all those objects, but it represents a concept that is common to all those objects. This observation is all but jumping up and down, yelling at you to create a base object.

So, try this. I don’t know your actual purposes of design, but I’ll run with the fact this is an “activateable” object, so I’ll call the class “activateable”. Your common theme is very likely more complex, and a much better name is likely in your mind. In this example, “activateable” would be created as a base class to hold the “activateFlag”, and would derive from monobehaviour if your original scripts derived from that. Then, each of the several classes you’re creating, which currently inherit from monobehaviour, would instead inherit from “activateable”. They would all “inherit” from monobehaviour as the “grandparent” class.

Now, however, each of your classes don’t need their own duplicated code.

Read that again, because it is the purpose of doing this. It may not seem important for a single variable, but I seriously doubt there’s only 1 variable these classes have in common.

3

That is an awesome way to work through this! Is it and has it, I will redo my concept and play with it. Thank you!