- Home /
How to group variables in the Inspector?
I'm creating a dynamic GUI which requires lots of variables in it, just wondering how i can group variables under a title so that it looks organized and easy to change values?
now included in Unity .. [Header("Hi there!")]
Answer by Fattie · Dec 11, 2014 at 04:58 PM
It's this simple:
[Header("Hi there!")]
since about 2014, cheers
Note that
[Space(10)]
is also quite handy.
There's also a Range slider which is very handy
[Range(5,9)]
doco ..
http://docs.unity3d.com/ScriptReference/RangeAttribute-ctor.html
http://docs.unity3d.com/ScriptReference/HeaderAttribute.html
etc
Note; there was previously an "order" attribute .. Unity have completely removed it around 2016. They also much improved the general functioning of the "Header" system.
Note that you cannot, for example, follow a "Header" line with an enum. You have to go enum - header - variable; you can't go header - enum - variable !
And each "header" must be followed by at least one variable. You can't (currently) have a header then a gap and then another header, even if you use space.
The system is a bit quirky but one of the nicest things in Unity.
I don't know how I missed this! Awesome! You sir, are a dude :)
Answer by Stardog · Mar 16, 2014 at 03:24 PM
You can group things in a new class:
[System.Serializable]
public class Movement
{
public float moveV;
public float moveH;
public bool isRunning;
public bool isLooking;
}
public Movement movement;
Answer by terrehbyte · Jun 12, 2017 at 08:46 AM
I would advise against @Stardog's suggestion to create an entirely new struct since it would introduce structural changes to your code in order to achieve a specific result in the editor. In this case in particular, it would be less than preferable because it impacts the way those variables are accessed.
In principle, the editor provides an interface for working with your scripts, so you should avoid making those changes of accommodations for the editor unless it's an editor script, which explicitly serves the purpose of defining specific behavior for the editor to follow.
Rather than accessing them directly as a part of the namespace of that class, it's now part of a member struct of that class.
No Changes
public float moveV;
...
moveV = 1.0f;
Enclosed in a Struct
[System.Serializable]
public class Movement
{
public float moveV;
public float moveH;
public bool isRunning;
public bool isLooking;
}
public Movement movement;
...
movement.moveV = 1.0f;
In this case, an entirely new data type is being created and instantiated in order to take advantage of editor's preference to display structs as a foldable section.
An easy alternative would be to follow what the selected answer has done, which is to use relatively innocuous attributes to insert header labels in the inspector view. That approach does not make any structural changes, which means that the manner in which that data is accessed will remain unchanged.
If it's sufficiently complex, then you could opt to leverage an entirely custom solution where you define a custom inspector script for a particular component. Something like a foldout to go as far as creating a little arrow that can expand and collapse a number of members. It will add some overhead in terms of the amount of work that must be done to expose new variables to the editor. That would be not be a cost you would incur if you were opt for something more lightweight, like the editor attributes mentioned in the selected answer.
This should be the accepted answer. You doesn't have to change your code for the inspector, you only add another file to configurate that, without adding more behaviours than necesary to our code.
This is a great point about not changing your code for visual layout in the inspector. It's also worth pointing out that structs cannot be assigned default values, and if you switch to classes, well then more allocations.
Answer by luislodosm · Jan 20, 2018 at 11:29 AM
Example:
public class Player : MonoBehaviour
{
public float health;
public float stamina;
public float speed;
public CombatStats combatStats;
[System.Serializable]
public class CombatStats
{
public float attackPower;
public float defense;
public float dodge;
}
}
Answer by reddtoric · Jul 22, 2019 at 02:25 AM
I agree with @terrehbyte's response.
Creating a class (or even a struct, because classes create more garbage) for the sake of organizing inspector is a bad solution.
However, if for example the fields belong together such as @luislodosm's example, it is a good idea (and should be used) but use structs rather than classes.