Is there a way to directly expose Auto-Implemented Properties to the inspector, without creating a separated editor script per component?
[System.ComponentModel.DefaultValue(90)]
[SerializeField]
public float test1
{
get { return test1; }
set { test1 = Mathf.Clamp(value, 0, 360); }
}
public float test2;
Both are public, but only “test2” is automatically exposed to the inspector?
I dont think Unity provides this functionality, you need to do it yourself. Heres a wiki article i found on this topic, looks qutie promising.
http://wiki.unity3d.com/index.php?title=Expose_properties_in_inspector
public float test2; is not a property, its a field. Fields that are public do get serialized and shown in the editor. Private fields don’t get serailized and shown in the inspector by standard.
public float test1
{
get { return test1; }
set { test1 = Mathf.Clamp(value, 0, 360); }
}
is a Property, big difference. The way to show it in the inspector is to use [SerializeField] on a private field, or to use a custom editor as you can show properties that way. Also it is bad practice to use properties like you have. These are the two proper ways for a property
private bool myBool;
public bool MyBool {
get { return myBool; }
set { myBool = value; }
}
public bool AnotherBool { get; set; }
You can put almost anything you want in a property so you’re not constrained to those 2 examples by any stretch of the imagination. I will agree though that calling a method inside a property isn’t so good. The general assumption is that a property call is a trivial operation.
But I’ve done things like this before:
private DataObject data;
public float DataObjectFloat
{
get
{
return (this.data != null) ? this.data.someFloat : 0f;
}
}
I should have stated that its not limited to those, but was a general idea of what a property should be used for, and the fact that auto-properties should not really modify themselves.
Yeah i’m new to c#, coming from c++ and noticed the “auto implemented properties” examples that seemed like a nice way to remove all those tedious set/get calls u normally implement if the value cant be made public or u need to-do extra checks/stuff on the values itself. I failed to realize that “public bool AnotherBool { get; set; }” will actually create a hidden/internal bool field that is not named “AnotherBool”. So its more like a convenient way to define a function/accessors with a automatic field, which explains why my example was bad practice.
thx
PS: The idea was to be able to clamp a editor set variable to a range, without the need to create a extra EditorClass. This is possible in UDK via some metadata, so i was thinking Unity might have something similar, but i cant find a way to clamp editor exposed variables to some min/max range.
UDK requires it cause it has no custom editors.
Unity on the other hand gives you the full power to expose it the way you want to do, where you want to do it and how you want to do it, including the possibility to expose it as slider instead of numeric for example. But the trade for this power is that there is no need to offer highly limited meta configurations everywhere to make stuff work at all.
Hehe nice sales pitch 
Its not a game breaker, but i find it tedious to create a separate EditorClass for every class that might have 1 member that needs a min/max range. From my experience many editor exposed members need such behavior and being able to easily define such ranges would be a welcome addition. I don’t like the split between EditorClass and real class and the need to change both on any changes to the class internals. I’m also quite happy most of the time, with the default Inspector GUI and see no need to change any of the GUI widgets graphically.
Agreed. I usually just apply the clamping afterwards, but it’d be neat to be able to add [ValueRange(0,1)] or similar to it. Or even supply a static function to run whenever the value is changed. Actually, that’d be super useful in other ways, too…
The problem i often encounter in the Unity Editor are unexplained value ranges. This means some plug-in or simple script did not go through the “hassle” of creating a separate editor class, be it laziness or simple missing knowledge. So i often find myself randomly enter values in the “fishy” named/explained fields, to figure out what value range this field actually expects. The biggest problem are fields that expect -1 to 1 float values, but by intuition u often try values between 1-100. Even worse, if the field has no direct measurable result its basically guessing or checking the code manually if possible.
This also adds more work to the programmer, since a artist or level-designer often works with those editor exposed values, without any deeper technical knowledge. So in return u might be forced to add EditorClasses to code/library’s u did not even design, which adds extra code/project maintenance, since the code can break/change after each update.
Since with Unity 4 PropertyDrawers were introduced it should be possible to not have to write an editorclass for each class that only has one custom member.
The Unity Script reference has an example at their PropertyDrawer Page for a min/max range.
If you just need a float slider it is enough to write[Range(min,max)] above your variable since the RangeAttribute is already defined.
class test
{
public float normalFloatDisplay;
[Range(1,10)]
public float LimitedFloatWithCustomInspectorDisplay;
}
There is also a thread from when PropertyDrawers were just introduced.
http://forum.unity3d.com/threads/150337-PropertyDrawers-for-easy-Inspector-customization
On page 2 HunterPT has added a nice example script if you only need int values. Then you would just need to add his “IntRangeAttribute” and “IntRangeDrawer” script. Then you can use [IntRange(min,max)] for float variables.
class test
{
public int normalIntDisplay;
[IntRange(1,10)]
public float LimitedIntWithCustomInspectorDisplay;
}
There is a nice Range attribute
[Range(0f,360f)]
public float vmu;
No need for external editor script
OMG, thx u soo much!
This solves my problem and i’m baffled that this feature is not better listed/explained in the main runtime/editor class attributes documentation. I completely missed this!
This basically addressed all my critics and solves the whole separate editor class handling for me. I cant wait to play around with this
Haha, I discovered this not 5 minutes ago and was just looking for the thread to share it!
Yes, it should definitely be better advertised. Both the manual and tutes should put stuff like this front and center where it talks about exposing publics for the inspector. Actually, they should go one step further and not encourage publics, but also show how to use [SerializeField].
Known about it since i started using unity in January 
Where’d you find out about it?
I guess that since I haven’t re-read any of the entry-level docs since somewhere around Unity 2.5 it’s quite possible that they’ve been updated with a few gems I haven’t discovered for myself…
If anyone is wondering in 2024 how to expose properties in the derived class of unity’s libraries, just enable “Debug” mode.
Please don’t necropost.