I can’t seem to find a pattern or consistency to this so I’ve tossed my hands in the air and I’m asking for the answer. Why is it that public variables don’t always display in the editor when you click on a script?
I’m not referring to a script that is attached to a GameObject. I’m talking about in the Project window, under your Assets… When you click on a script, in the Inspector it displays the information for that script. At the top, sometimes public variable fields show up to allow you to set their default value, but other times they don’t display.
It seems like it’s only object reference values that show up. So both primitive values (integers, bools, etc.) and custom Serializeable classes will not be shown.
This is probably because there’s already a way to set the default value for those things - by assigning a value in the script itself. So if you have an explosion script, the divide should be pretty clear:
public class Explosion : MonoBehaviour {
public float radius = 5f; //default value
public ParticleSystem particlesPrefab; //default value must be set in the inspector
}
It’s obvious why you can’t set the default prefab from code. Why you can’t set the default value of the floats, etc. from the inspector is less clear. I’m guessing it’s becuase it would be hard to know which one was prioritized, and it could be confusing if you tried to change one, but the other one was overriding it.
At the same time, it’s a bit messy that the default values are set two completely different places.
@karl_jones I think @Baste hit the nail on the head. It seems that primitives (int, float, bool, string) won’t show up, but more complex types (Transform, GameObject, etc) will. However, I sincerely wish there was support for primitives.
The design decision about not showing the primitive here make sens: you can already set the default value for theses types from code, it would have been confusing if you could setup the default value from two places. Suppose it was possible, what would be the real default value then? The one in the code or the one in the inspector?
It makes sense in THAT scope, but not in others. What about derived classes?
public class A : MonoBehaviour
{
public string name;
public int age;
}
public class B : A
{
//Other variables unique to class B go here.
}
public class C : A
{
//Other variables unique to class C go here.
}
In the scenario above B derives from A and C derives from A. However, B and C also have their own unique variables. B and C get attached to multiple different GameObjects, and the variables are adjusted according to those GameObjects. HOWEVER, name and age should never change. Since I can’t set the name and age of B or C in the editor, the only way to do it is by using the Reset() method…and I was hoping to avoid that. I just find it easier to simply enter the values in the editor for the derived fields, rather than type a Reset() method out for every class that derives from A (or entering the information into the field in the Inspector every time I attach the script to a GameObject).
@DRRosen3 . You can still defined default values for each derived class.
public class A : MonoBehaviour
{
public string name = "defaultNameForClassA";
public int age;
}
public class B : A
{
void Awake()
{
this.name = "defaultNameForClassB";
}
//Other variables unique to class B go here.
}
public class C : A
{
void Awake()
{
this.name = "defaultNameForClassC";
}
//Other variables unique to class C go here.
}
That’s no different that writing a Reset() method for each class. Writing a Reset() method or an Awake() method where you set the variables is just more typing that simply plugging values into the editor, that’s what I’m getting at. Effort to Result ratio I suppose you could say. I know in terms of writing one or two scripts it seems minimal, but when you start writing dozens of scripts you look for ways to make your workload easier and your workflow faster/more efficient. Especially when the class that is being derived from has a dozen and a half variables to assign values for.
If class A has 20 variables, and classes B, C, D, E, and F all derive from A, and you need to assign values to all 20 variables from class in B, C, D, E, and F, then you’re writing upwards of 135 lines of (unnecessary) code.
Oh. I see where your are leading. You want the script inspector from of the project folder to be the same as a script inspector attached on a gameobject in the scene. That would make it more consistent.
On the other hand, editing 5 times 20 variables in the inspector, would be about 135 (unnecessary) mouse clicks and as many (unnecessary) keystroke sequences, is not more fun.
And it get even worst when you rename the variables (which happens during code refactoring) and lose your hard edited values.
I mean, honestly, it’s a matter of perspective, but like I said, it’s effort-to-result ratio. Writing code requires more effort than just plugging values into the editor. Each nets the same result. So, naturally, the more efficient way to go is plugging values into the editor.
I’m not saying writing code is better than plugging value from the editor, if you believe I’m arguing about that :).
Actually, I don’t know if there is one way better than the other. Ultimately, you need to put you data in the system somehow. Which one is better? A lot of contextual parameters needs to be taken into account before favouring a method against another.
To override default values without creating new C# script, need to create Prefab or GameObject with script with this default values. But what if we do not want to create Prefab or GameObject for this script? We want just add component with this script to already created GameObject dynamically.
I never noticed this feature. Thanks for mentioning it! It could be put to good use.
