koobas.hobune.stream
Can I change variable name on inspector ?
Hello everyone,
I was wondering if can we change the variable name on inspector without changing it in script.
For example:
using UnityEngine;
using System.Collections;
public class Luces : MonoBehaviour {
[Header("Luces")]
public Light luzRoja;
void Update() {
// Some code...
}
}
Insted of saying "Luz Roja" on inspector, I want to say "Roja".
I have more code, but this is what I see now:
Thanks !
ANSWERED: Thanks everyone for the answers. I knew that maybe the best options was to create a custom inspector, but for this, is a lot of work and makes no sense... So, it will be Luz Roja :P
That does not seem possible at first sight.
The serialize property which is the link between your variable on script and the display in the inspector only provides getter for the name. So it seems modifying the name is not possible. I could be wrong though.
http://docs.unity3d.com/ScriptReference/SerializedProperty.html
It's always possible to write your custom inspector, but there's most likely an easier way of doing it. If all else fails though, you can try something like this: https://unity3d.com/learn/tutorials/modules/intermediate/editor/building-custom-inspector
(But at that point it's probably too much effort for what you want to do, so you might as well just deal with the default inspector.)
Here are some more resources if you do decide to go this path:
http://catlikecoding.com/unity/tutorials/editor/custom-data/
http://catlikecoding.com/unity/tutorials/editor/custom-list/
You can do this with PropertyAttribute:
using UnityEngine;
#if UNITY_EDITOR
using UnityEditor;
#endif
public class LabelOverride : PropertyAttribute
{
public string label;
public LabelOverride ( string label )
{
this.label = label;
}
#if UNITY_EDITOR
[CustomPropertyDrawer( typeof(LabelOverride) )]
public class ThisPropertyDrawer : PropertyDrawer
{
public override void OnGUI ( Rect position , SerializedProperty property , GUIContent label )
{
try
{
var propertyAttribute = this.attribute as LabelOverride;
if( IsItBloodyArrayTho( property ) == false )
{
label.text = propertyAttribute.label;
} else
{
Debug.LogWarningFormat(
"{0}(\"{1}\") doesn't support arrays ",
typeof(LabelOverride).Name ,
propertyAttribute.label
);
}
EditorGUI.PropertyField( position , property , label );
} catch ( System.Exception ex ) { Debug.LogException( ex ); }
}
bool IsItBloodyArrayTho ( SerializedProperty property )
{
string path = property.propertyPath;
int idot = path.IndexOf('.');
if( idot==-1 ) return false;
string propName = path.Substring( 0 , idot );
SerializedProperty p = property.serializedObject.FindProperty( propName );
return p.isArray;
//CREDITS: https://answers.unity.com/questions/603882/serializedproperty-isnt-being-detected-as-an-array.html
}
}
#endif
}
So you can easily override inspector labels:
[LabelOverride( "Awesome light" )]
[SerializeField]
Light _light;
To see what real name of this field is you must switch Inspector to Debug mode.
Just a quick note this wont work for Unity events but for most things its fine
If you don't want to write your own PropertyDrawer, you can use NaughtyAttributes.Label:
public class Luces : MonoBehaviour {
[Header("Luces")]
[Label("Roja")]
public Light luzRoja;
// ...
NaughtyAttributes is open source and available as a package.
If it could be done, it would have to be through serialization. The thing is that it is not a good idea to have a variable name for a script variable because, say that you want to access that variable through another script. Unity wouldn't know what to access once it finds a variable named 'Roja' because in the script it is called 'Luz Roja' so it won't make the connection.
I recommend changing it in the script if you don't want headaches.
Best regards and Good Luck!
1) I would recommend against changing the field names as they show up. The big reason (there are others), is think of anytime you have tried to GetComponent<...>() and couldn't find fields that matched the UI names. It makes it difficult to develop against in the future by you or others.
2) A common trick I do to help me organize my script fields, is inside of my MonoBehaviour, I create a small serialized class called (to mimic your system) public class LucesFields. Then I have fields for each one, such as public Light Roja; public Light Verde; etc. Then I create a public field call like this: public LucesFields Luces;
This gives you the header, but also makes the header collapsable. you can name stuff more simply, because if you have Roja field for a UI Slider and a Light, then the header separates it for simplicity. This also reduces junk in Intellisense. Instead of having to find LucesRoja in all of the members in a monobehaviour, you just type Luces (for the lights) then ".R" and intellisense will allready be simplified. I think this might be the better practice.
Don't get me wrong, I initially loved the helper attribute that @Hunter_Towe suggested above. But after consideration, the fact that it adds a "Magic" layer that hides how to find the variable in the code, I couldn't agree with it. Pretty, but the type of thinking that will help make code more complicated in the long run. (I mean no offense by that, I have had hundreds of instances like that, and I'm still catching myself doing things like these days)
Cant agree with your assesment here. Your creating an object not to improve management of data in memory or reduce code duplication but to adjust your dev time editor's display. So you are in effect making run time worce to improve your editor experience
Keep in $$anonymous$$d that creating that little class means that when you access the field Roja from your componenet you have the following steps
1. get the commonent pointer e.g. GetComponennet()
2. look up that object from that pointer
3. get the pointer to your Luces class
4. look up that object from that pointer
5. get the value of the Roja attribute of that object (a pointer to a light)
6. look up that light object
Compare that to storing it on the class directly
1. get the commonent pointer e.g. GetComponennet()
2. look up that object from that pointer
3. get the pointer for your light (luzRoja)
4. look up the light object
Increasing the depth that your code must traverse to get to the values desired does have a cost. Its a small cost yes but these sorts of things add up. If there is a good return on the investment of that e.g. if its worth it in making your code more maintainable or something similar then sure but doing it to make your dev time inspector more attractive? no
Either A) deal with the long name if you want to keep names identical
or
B) understand that the insecptor is a UI not a 1 to 1 name match with the code and that intelicense is a wonderful tool well able to locate luzRoja when you start typing ".Ro" it will show you all options wiht Ro in it sorting first yes thoughs that start with Ro but including thouse that simply contain it just below that
So I feel neither point 1 nore 2 is a good reason to avoid custom labels for fields on componenets
