C# "Get and Set" functions and the Unity Inspector

So, right now i am making a game where i have a player and his stats and a monster and their stats. I have the variables in private so that things cannot accidently manipulate them. But i also use the get/set functions to make the variables accessed if used correctly. However, the variables with the get/set do not show up on the inspector in Unity. Is there a way that i can make these variables show up without making the base variables public?

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class playerStats : MonoBehaviour {
5.    
6.     //these are the base variables; they cannot be seen by other scripts
7.    
8.     private int m_health = 10;
9.     private int m_damage = 3;
10.     private int m_strength = 2;
11.     private int m_maxHealth = 10;
12.     private int m_playerLevel = 1;
13.     private int m_experience = 0;
14.    
15.    
16.     // Use this for initialization
17.     void Start ()
18.     {
19.        
20.     }
21.    
22.     // Update is called once per frame
23.     void Update ()
24.     {
25.        
26.     }
27.    
28.     //these variables can be used by other scripts
29.     //they take the values of the base variables
30.     //however, they dont show up in the inspector
31.    
32.     public int health
33.     {
34.         get { return m_health; }
35.         set { m_health = value; }
36.     }
37.    
38.     public int damage
39.     {
40.         get { return m_damage; }
41.         set { m_damage = value; }
42.     }
43.        
44.     public int strength
45.     {
46.         get {return m_strength; }
47.         set {m_strength = value; }
48.     }
49.    
50.     public int maxHealth
51.     {
52.         get {return m_maxHealth; }
53.         set {m_maxHealth = value; }
54.     }
55.    
56.     public int playerLevel
57.     {
58.         get {return m_playerLevel; }
59.         set {m_playerLevel = value; }
60.     }
61.    
62.     public int experience
63.     {
64.         get {return m_experience; }
65.         set {m_experience = value; }
66.     }
67.    
68.     public void HurtMonster(int monsterHealth)
69.     {
70.         monsterHealth -= m_damage;
71.     }
72. }
73.  

P.S. If u couldnt tell by the title, i am using C#.

 

If you want to see it in the inspector try this: Hopefully it works

Code (csharp):

1.  
2. [SerializeField]
3.     public int strength
4.     {
5.         get {return m_strength; }
6.         set {m_strength = value; }
7.     }
8.     public int m_strength;
9.  
10.  

 

oops, wrong (good)

 

Sweet, the serilize field was exactly what i needed. I just needed to put it in front of my private variables like so:

Code (csharp):

1.  
2. SerializeField]
3.     private int m_health = 10;
4.     [SerializeField]
5.     private int m_damage = 3;
6.     [SerializeField]
7.     private int m_strength = 2;
8.     [SerializeField]
9.     private int m_maxHealth = 10;
10.     [SerializeField]
11.     private int m_playerLevel = 1;
12.     [SerializeField]
13.     private int m_experience = 0;
14.     [SerializeField]
15.     private int m_monsterHealth;
16.  

Now, do u know if i can put only one SerializeField in front of a block of code so that all of them can become serialized? And to clarify...these objects arent public, they are just seen in the inspector, right?

 

I don't know offhand but a quick way to test it would be to create a public value of the same type that could be seen in the inspector, and in the update function assign the private variable's value to the public variable. Then try to change your serialied field and see what happens to your public value.

Hope that makes sense.

 

You could make it private and if I understand you question correctly try this:

Code (csharp):

1.  
2. [System.Serializable]
3.     private class Health
4.     {
5.         public int strength
6.     {
7.         get {return m_strength; }
8.         set {m_strength = value; }
9.     }
10.     [SerializeField]
11.     private int m_strength;
12.     }
13.     [SerializeField]
14.     private Health health;
15.  

Hope this answers you question. Now I may be wrong but hope this helps.

 

nope

 

if they are all of the same type, sure, [SerialiazeField] applies to one line of code. For example:

[SerialiazeField]
private int m_health=10, m_damage, m_strength;

 

Don't go necro posting. This thread was 3 years old.

 

OCD much? It's still a relevant topic.

 

[SerialiazeField] causes compiler warnings when building using Microsoft's .NET 4.5.1 instead of Mono.NET. Just in case you're doing a Windows Phone or Windows Store build.

 

Unity, by default, only displays in the Inspector what is SAVED or CAN be saved on the disk.

Unity saves fields from a type deriving from UnityEngine.Object (MonoBehaviour/ScriptableObject), OR class with the [Serializable] attributes.

Only public fields are saved by default. Private fields are ignored, unless flagged with [SerializeField].

The Inspector will also ONLY display variable that Unity can save. For example, it will not display Hashtable, Dictionary, or nested list, because Unity is unable to save those types.

The Inspector only display fields, and ignore properties (get/set), events and methods.

If you want the inspector to work in any other way, you have to write your own Custom Editor. (Ex.: See my signature for Advanced Inspector)

 

I've not used it myself, but the OnValidate method in a MonoBehaviour could be useful for using setter methods via a default Inspector.

My untested assumption is that we could mark the backing fields with [SerializeField], make public setter methods which enforce whatever rules we want to have, and have an OnValidate method similar to the following:

Code (csharp):

1.  
2. [SerializeField]
3. private float privateBackingField = 0;
4. public float PublicAccessibleProperty {
5.     get {
6.         return privateBackingField;
7.     }
8.     set {
9.         privateBackingField = Mathf.Clamp01(value);
10.     }
11. }
12.  
13. void OnValidate() {
14.     PublicAccessibleProperty = privateBackingField;
15. }
16.  

I believe this would mean that every backing field is re-applied via its public property each time an Inspector value is changed. As long as you don't have any complex interdependencies between your properties this should be a pretty straightforward solution, in theory. (And even with complex interdependencies it shouldn't be that much more difficult, since you can just call whatever you're using to enforce them anyway.)

Heck, I bet you could even use reflection magic to automate this from a common subclass of MonoBehaviour.

Edit: Tested the above code. Works great. I will totally be using and abusing this from now on.

Edit 2: Of course the downside to this is that the getter isn't actually being used by the Inspector, so if we've got any kind of data transformation going on there it'll be getting ignored. So contrary to what I initially had written above, this is handy for applying rules on set but not so useful on get. For that I believe you would indeed need a custom Inspector, because you're looking to change the basic rules by which Unity displays stuff in there. (Or... hacky approach... have separate private backing fields for the Inspector and for runtime, and update the Inspector fields via their getters at the end of OnValidate... but that's really getting funky and I wouldn't want to maintain it on a large codebase, and it still wouldn't be particularly reliable for derived getters... I think a custom Inspector would be a clearer approach.)

 

You have it right that the getter isn't used... And in some cases - in some project I have been on - it wasn't enough. Data conversion between what is displayed and what is serialized is something we have done a lot of time.

Using properties to convert a format Unity is able to save from and back to a format the user is able to read is quite useful.

 

Is it possible to write a generic custom Inspector? I know that if we have ComponentX that if we write ComponentXInspector it does its thing. But can we write BaseClass and then have BaseClassInspector, will BaseClassInspector be used for derived classes? (I'll test this myself if the answer isn't known.)

 

Yes, it's possible. It's how I built the Advanced Inspector. I created a Custom Editor for "MonoBehaviour", so all script pass by it.

 

Righto. I looked it up on the Asset Store and I reckon I might buy me a license tonight.

 

An easier way to just see private variables in inspector (read only) is to put it into debug mode (top right corner). This way you don't have to mess around with all that attributes cluttering your code. If you need to save those values anyway go with serializefield.

 

Code (CSharp):

1. OnValidate()

is remarkably useful, for during development if nothing else. Thanks for that tip!

It's basically undocumented.

 

Thank you so much!

 

OnValidate is really helping! Thanks from 2016.

 

EDIT: I did a colossal blunder. Shame. Especially in a necropost.

 

Works fine for me. Maybe you are accidentally returning the property itself in the get accessor of your version?

 

You've been too quick! No, but still, it was a mistake on my part. Apologies for necroposting.

 

First people complain when you create a NEW post on a topic that's already been discussed.
Then people complain that you open this OLD post despite the above.

<Proud 'necroposter' cause its better if it's all in one place > ** /sigh

 

Necro-posting is fine as long as it contributes to the original topic.
This post you made just now does not. Nothing to be proud of.

 

= Irony

 

Yes, I see the the irony in my response.
Point still stands.

 

You must be at least 10 years of age by now going by your join date, why is it that you're acting like a 3 year old?

 

Since I just got a "like" on that post, an update may be in order.

First, for some things Unity now has attributes that can allow you to enforce simple rules on Inspector fields. Stuff like [Min(0)] and so on are super handy. Still doubling up on setters for applying constraints, but perhaps better than the hack I raised earlier. Up to personal taste.

Second, in my code I've been removing a bit of use of OnValidate of late. For trivial stuff it's great, but non-trivial stuff (I've done stuff far heavier than in the quoted post) it occasionally causes issues. This is most common when it uses other components or GameObjects, and tends to come up at load time rather than when editing.

Still incredibly useful in general, but... we'll, I did call it "abusing" in the quoted post.

 

I've noticed recently that in a setter invoked from OnValidate (like the examples outlined above) the private field and value will already be the same value now even before you've assigned it. How strange! I swear the private field used to contain the pre-assignment value. It was great for doing things like logging "This value is changing from [{A}] to [{B}]" for debugging.

 

What exactly has this to do with C# properties and get / set method of said properties? Really, you're not adding anything to the discussion about getter, setter or the relationship of the inspector. You seem to have a concrete issue in your concrete project. Create a seperate thread with a descriptive title and add more information on your actual issue. Because "everything is working" and "then broken" could apply to to literally anything.

Don't hijack other threads with other topics.

 

Code (CSharp):

1. [field: SerializeField] public GameObject myObj { get; private set; }

This is a thing now too if anyone's seeking solutions to the problem in the OP and can get away with auto property.

 

Right, this was introduced in C# 7.3.

 

Thank you, I've used this before but couldn't remember the syntax...