Hiding inherited public variable in the inspector?

Unity Engine
1

Is it possible to make a public inherited variable to not show up in the inspector? Its only needed in the parent class and cluttering up the inspector for the other classes.

5 Likes
2

In the parent class, if you have access to its source, put the HideInInspector attribute on the field:

1 Like
3

I have one problem with this, the HideInInspector attribute has to be in the class scope, but i cant access a public variable there, just able to declare them…

2 Likes
4

What? You apply that attribute where you declare the field.

What are you talking about?

5

But i want it to appear in the parent class but not in the child class as i wrote in the first post. And because i declare the variable in the parent class it cant be hidden with this method in the child class it seems. Might have been a bit vague, i’m sorry about that.

7 Likes
6

Anyone?

1 Like
7

So you have two behaviours. Let’s call them CompA and CompB, CompB inherits from CompA.

public class CompA : MonoBehaviour
{
    public PropA:string;
}

public class CompB : CompA
{
    public PropB:string;
}

Now if you add CompA to a gameobject the inspector has a property for PropA.

If you add CompB to a gameobject the inspector has properties for both PropA and PropB.

You want it that when you add the component for CompB there is ONLY a property for PropB, and if you add CompA there is ONLY a property for PropA?

Why?

I’m not trying to be mean here. I just don’t understand why this is needed for you. Does CompB set PropA to something and it doesn’t want it changed ever?

8

Simple.
CompA has some config values i want to be able to set in the inspector that affects some common functions for all children, and CompB has some own specific values i want to set, this cant be that strange?

14 Likes
9

Are these static properties or something?

How is CompA effecting for “all children”? What “all children”? For all instances of CompB out there? So CompA is a manager for CompB?

I don’t think you understand how inheritance is supposed to work.

1 Like
10

I know how inheritance is supposed to work, don’t worry about that.
If you really need to know its a path to a folder i want to be able to set through the inspector, but what or why im doing stuff is not really a part of my original question.

Still wondering:
Is there a way to hide a inherited public variable so it does not show up in the inspector?

7 Likes
11

no, you can’t

and this doesn’t make sense at all. If you attach a CompA to a gameobject and a CompB to a gameobject, and you set the property of CompA to be something… the CompB attached elsewhere isn’t going to know unless it gets a reference to the OTHER CompA. This can only be done by having CompA’s property be static, or if the CompB is given a direct reference to this CompA.

Either way… CompB doesn’t have to inherit from CompA for any reason.

The point of inheritance is to inherit functionality. So CompB should have this property, so that it can have it to do its work. The CompA is arbitrary now…

12

CompB dont need to know the property, its only used in CompA, maybe its a way to make CompB not inherit it to begin with?
CompB inherits from CompA for many reasons, to use common functions and stuff, of course there is also other classes that inherits from CompA.
This particular property is only for configuration of one specific thing in CompA, there are a lot more to it than that, but its not the point of this thread at all.

2 Likes
13

Why is it only for CompA and not CompB?

If CompA has something that CompB shouldn’t have… then CompB shouldn’t inherit from it.

If you’re configuring CompA, then you’re configuring CompB as well! Because CompB is a CompA.

Sounds like you’re shoving way to much functionality into 1 single class. Try breaking this up into multiple classes (inheritance is not breaking up into several classes if you’re just going to inherit all the functionality of each other).

And no, you can’t NOT inherit part of a class when inheriting from it. If you don’t want to inherit part of it, then you should inherit at all.

There’s a reason what you want doesn’t exist. Because it doesn’t make sense.

1 Like
14

yeah, yeah.
CompB uses all functions and variables of CompA, except for this single variable that is used to configure a path that a function in CompA uses, this path is same for all classes that inherits from CompA and i would like to set this from the inspector, why is that so strange? How would you implement this single variable then? And why do you care so much what and why i do something? : p

Edit: Its not a big problem really, just a matter of cleaning up the inspector.

1 Like
15

because that doesn’t make sense

this variable, of CompA, the value you set for the single instance of it, is not going to change said value for ALL CompB’s… every other CompB is still going to have the default value CompA has before setting it in the inspector. So if CompB calls this function, it will fail.

That’s fine though. If you want to use poor design, and insist that the programming language bend to your bad design instead of just fixing it, you go for it.

Have fun.

It’s like you came in and asked, “Why won’t this screw come out?”

And you received the response, “That’s a hammer… and you’re banging the screw in with it.”

“Yeah, well why do you care how I use my hammer? How do I get my screw out with it!?”

1 Like
16

Well, maybe some one can come and screw you instead : p
You have no insight in my class and as such cant tell me if what im doing is right or wrong.
Its working perfectly well what im doing and its not a bad design, all i did was asking a simple question, please keep to the subject instead of playing “mr know it all”.
Finally got my answer, thread closed.

14 Likes
17

I actually gave you the answer quite some time ago.

And I have enough insight to your class from what you explained here to know you most likely have a bad design somewhere. I can bang a screw in with a hammer… doesn’t mean I should.

18

Why don’t you just write a custom inspector for the derived class?

4 Likes
19

I’m going to have to disagree there - this is a slightly unusual case, but not necessarily bad design.

Simple Example:
Class: Enemy. Property: Attack animation.
Class: Warlock, derives from enemy. Does not animate differently when attacking, instead has separately moving ghosts. Attack animation property is useless in inspector, as it is unused.

Now technically, you could say that the hierarchy should then be:
Enemy → VisiblyAttackingEnemy → …
Enemy → Warlock
Or something like that.

But IME, there are always going to be cases where trying for a 100% pure model has more downsides than benefits.

10 Likes
20

That’s not a comparable scenario though.

Their description was more like:
Class Enemy. Property: Attack animation used by all Enemies and classes that inherit from enemy.
Class Warlock, derives from Enemy. Enemy already has Animation defined and a function to handle it… so not necessary here.
Attack animation property is useless in inspector because it was already set for Enemy.

Not logically sound, or not properly defined.

Also in your example. I wouldn’t have enemy contain the AttackAnimation. And instead each type that happens to have one has the Attack Animation. Enemy would just define a method called ‘Attack’, and the child classes that have animations would override the function and play the animation that is needed (or do something else such in the of the Warlock). If there is a generic enemy component that Enemy is supposed to act like and can be added to gameobjects, I’d just create another class GenericEnemy and implement it there.

class AbstractEnemy
->Attack

class Warlock : AbstractEnemy
->override ->Attack - do something unique

class GenericEnemy : AbstractEnemy
*AttackAnim : Animation
->override->Attack - play Attack animation

2 Likes