C# custom class display in inspector

Unity Engine
1

in javascript,
if I code

class customClass{
  var customInt : Int;
  var customString : string;
}
var customTest : customClass;

and the customTest varible will display in Inspector like a tree,
I can change customTest.customInt and customTest.customString in Inspector.

but in C# , how do I make it?
I tried

public class customClass{
  int customInt;
  string customString;
}
customClass customTest;

but nothing display in Inspector, why?
:face_with_spiral_eyes:

2

Mark the variables as public or add the [SerializeField] attribute above the members. And mark your class as Serializable

[System.Serializable]
public class customClass
{   
  public int customInt;   
  public string customString;
} 

public customClass customTest;
20 Likes
3

[System.Serializable]
it work, but Im wondering what is this line mean?

4

It puts MetaData to the class which could be retrived by reflection and used by Unity. With this Unity knows that it should/can serialize the class.

If you want to know more searh for C# Attributes (System.Attribute).

1 Like
5

brilliant, thank you!

6

Thanks for that!

Someone should FIX THE DOCS

There’s no [System.Serializable] in this example :frowning: as of 2016/08/05

1 Like
7

sorry to bring up an old thread, but i seem to have some issues with [System.Serialisable] when using it on a class in a different file i no longer can see the class in the inspector, anyone know whats up with that?

8

Is the file in a different namespace or even different project? Usually files in the normal project cannot see files included in the Editor project. Can you tell us some more info about your classes?

9

I notice you wrote that “[System.Serialisable]”, but it should be “[System.Serializable]”, so if you typed it that first way, that would be why you’re not seeing it.

1 Like
10

Wow so I spent like 6 months of developing not knowing this. Great.

1 Like
11

found the answer, when you create a new calss in unity it automatically derives from MonoBehaviour
 remove that and add [System.Serializable] and you will be set

1 Like
12

MonoBehaviour is already serializeable, so you don’t need to add it to a class that inherits from from it.
But it’s perfectly fine and recommended to remove the MonoBehavior inheritence if you do not need to make any use of monobehavior stuff like Update(), Start(), and many other runtime features it provides.

13

is there any way to show classes from other namespaces in the inspector?

14

It doesn’t matter what namespace they’re in, if the class has a reference defined in some Monobehaviour based script that is being displayed in the inspector, then all that matters is that the class definition has [System.Serializable] above it, and that you put [SerializeField] beside the reference you want to indicate should be shown in detail in the inspector.

15

so the problem was that I defined my reference with { get; set;} at the end so it wouldn’t show in the editor. is there any way around it? keeping { get; set;} format?

16

Properties are basically methods, they don’t hold references to anything. What happens when you define an auto-property like that is that an actual reference variable is created at compile time that your Property “gets” and “sets” to.
What you should be doing is:

[SerializeField] private SomeClass myClassRef;

public SomeClass MyClassProp
{
    get {return myClassRef;}
    set{ myClassRef = value;}
}

This is how you’re supposed to use a Property. Otherwise there isn’t much point in making a property, things can always be refactored later if you need Property functionality (i.e to make certain things happen if you set or get a field).

2 Likes
17

Honestly this C# seems a big stepback. I’m fed up to search for things that used to wok in Unityscript and are now broken.
We have computers that can recognize your face in a fraction of a second, but you still have to type 1.0f to make a compiler understand you’re dealing with a floating point number, or type “;” to finish a line, or more intricate things like the above. Also documentation in some areas is lacking. By the way, thanks for the help here, which would not be needed if Unity did proper documentation.
This is not about democratization anymore, but nerds and shamans ruling.

1 Like
18

So you decide to revive a 2 year old thread to rant about unity not doing proper documentation?

19

It probably means that the problem is still there!

20

Unityscript was used about 14.6% globally(actually it’s way less than that, as 14.6% was the percentage of projects that contained at least one js file which can also be attributed to StandardAssets, not the percentage of projects exclusively in unityscript which was about 0.8%). Does it make sense to continue supporting this backend and allocate resources for it? It didn’t make sense to have multiple backends anyway. The fact that Boo made it as far as it did is surprising enough.

The docs themselves do cover the issue at hand.
Unity - Manual: Script serialization and also following some of the links from this page you discover
Unity - Scripting API: Serializable
Not to mention all the sticky threads and Unite videos featuring Tim Cooper talking about serialization.

You don’t have to become a nerd or shaman.