koobas.hobune.stream
Hide public field on base class but show it on derived class
Hey guys, quick question... I have my base class setup this way:
using UnityEngine;
using System.Collections;
public class PowerUp : MonoBehaviour {
public bool displayIcon = true;
public Texture2D icon;
public Vector2 iconPosition = Vector3.zero;
public int uses = 5;
public float passiveLifetime = 20;
[HideInInspector] public bool isActive = false;
[HideInInspector] public bool isPassive = false;
[HideInInspector] public float dieAt = 0;
// Functions and more below....
}
Now I have my derived class:
using UnityEngine;
using System.Collections;
public class StickyWheels : PowerUp {
public Texture2D stickyWheelsIcon;
void Start() {
// Init stuff...
}
}
All the public fields show up in the inspector on both classes. But I really don't need them to be displayed on the base class, since they are different based on the object the scripts are attached too.
Is it possible to force the public fields to be hidden on the base script, and only have them visible on the derived class?
Thanks for your time guys! Stephane
Why would you want that?
If you have an object that uses the base class you'll want them to be shown so you could tweak them, and if you don't use the base class (the likely scenario for this sort of setup) then they shouldn't be hidden at all.
Either way, I don't see a reason to hide those fields on the base class in the first place.
You can also make your base class abstract. This way you cannot drag the script PowerUp onto an object, only the derived versions, which is most likely what you are interested in.
Well my properties don't show up in the inspector - just variables. There is this script which can be used to show them.
Umh, all the functionality contained in the base class is also available/present in all derived classes, that's the whole point of class hierarchies. For the same reason you can see the public fields of your base class in your derived classes. So it doesn't make sense to attach another base class object somewhere in your scene, since every Component that's derived from the base class will already "include" such a base class object, although it's not visible as an independent Component in the inspector.
If you do have some global parameters/settings/things that are identical for all objects of type "PowerUp" (which per definition includes all derived objects as well), you might want to consider making these static ins$$anonymous$$d.
As a result of the rather long discussion in the comments, it turns out there wasn't actually a need to do precisely what was asked in the question. After clearing up some misunderstandings concerning class derivation, it turns out the problem was related to an unnecessary base class instance somewhere in the scene, and the fact that the base class initializations of derived instances never happened.
So the solution was for each base class to call their associated base.Start() as described below (my original comment copied from the question):
For your information, the "correct" way to do it using object-oriented programming is, you can keep the Start() in your base class. But declare it like this:
protected virtual void Start()
Then, in your derived classes you use this instead:
protected override void Start()
So if the object initializes, the Start() of the "most derived class" will be executed. But not the one from the base class - which probably caused your problem. You need to explicitly call it. So in your derived classes, you would write:
protected override void Start() {
base.Start(); // initialize base class
// your regular Start() code here
}
Note you'll need to do this in every derived class, and it also works if you have multiple derivations, ensuring that all Start()'s of all ancestors are called.
See any OOP tutorials on the web for more info.
NOTE: as @asafsitner pointed out, it isn't actually mandatory to provide the protected virtual/override modifiers, so you can just use your regular void Start() syntax. The important thing is that each derived class needs to call base.Start() in its Start() call (and similarly for each method of the base class that is overloaded this way, e.g. call base.Update() if both base and derived class have an Update() function, and if both need to be executed.
