Search Unity

C# custom class display in inspector

Discussion in 'Scripting' started by Hao-Cher-Hong, May 19, 2011.

  1. Hao-Cher-Hong

    Hao-Cher-Hong

    Joined:
    Dec 15, 2010
    Posts:
    127
    in javascript,
    if I code
    Code (csharp):
    1.  
    2. class customClass{
    3.   var customInt : Int;
    4.   var customString : string;
    5. }
    6. var customTest : customClass;
    7.  
    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
    Code (csharp):
    1.  
    2. public class customClass{
    3.   int customInt;
    4.   string customString;
    5. }
    6. customClass customTest;
    7.  
    but nothing display in Inspector, why?
    :confused:
     
  2. Marrrk

    Marrrk

    Joined:
    Mar 21, 2011
    Posts:
    1,032
    Mark the variables as public or add the [SerializeField] attribute above the members. And mark your class as Serializable

    Code (csharp):
    1.  
    2. [System.Serializable]
    3. public class customClass
    4. {  
    5.   public int customInt;  
    6.   public string customString;
    7. }
    8.  
    9. public customClass customTest;
    10.  
     
  3. Hao-Cher-Hong

    Hao-Cher-Hong

    Joined:
    Dec 15, 2010
    Posts:
    127
    [System.Serializable]
    it work, but Im wondering what is this line mean?
     
  4. Marrrk

    Marrrk

    Joined:
    Mar 21, 2011
    Posts:
    1,032
    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).
     
  5. TheWarper

    TheWarper

    Joined:
    Nov 3, 2013
    Posts:
    99
    brilliant, thank you!
     
  6. greggman

    greggman

    Joined:
    Nov 30, 2013
    Posts:
    20
    Rodolfo-Rubens likes this.
  7. RealSoftGames

    RealSoftGames

    Joined:
    Jun 8, 2014
    Posts:
    220
    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. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    146
    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. Invertex

    Invertex

    Joined:
    Nov 7, 2013
    Posts:
    993
    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.
     
    npatch likes this.
  10. astracat111

    astracat111

    Joined:
    Sep 21, 2016
    Posts:
    567
    Wow so I spent like 6 months of developing not knowing this. Great.
     
  11. RealSoftGames

    RealSoftGames

    Joined:
    Jun 8, 2014
    Posts:
    220
    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
     
  12. Invertex

    Invertex

    Joined:
    Nov 7, 2013
    Posts:
    993
    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. ahmadian

    ahmadian

    Joined:
    Nov 24, 2015
    Posts:
    44
    is there any way to show classes from other namespaces in the inspector?
     
  14. Invertex

    Invertex

    Joined:
    Nov 7, 2013
    Posts:
    993
    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. ahmadian

    ahmadian

    Joined:
    Nov 24, 2015
    Posts:
    44
    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. Invertex

    Invertex

    Joined:
    Nov 7, 2013
    Posts:
    993
    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:
    Code (CSharp):
    1. [SerializeField] private SomeClass myClassRef;
    2.  
    3. public SomeClass MyClassProp
    4. {
    5.     get {return myClassRef;}
    6.     set{ myClassRef = value;}
    7. }
    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).
     
    Rutenis and ahmadian like this.
  17. acme3D

    acme3D

    Joined:
    Feb 4, 2009
    Posts:
    185
    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.
     
    Gabe-Tucker likes this.
  18. ProtagonistKun

    ProtagonistKun

    Joined:
    Nov 26, 2015
    Posts:
    292
    So you decide to revive a 2 year old thread to rant about unity not doing proper documentation?
     
  19. acme3D

    acme3D

    Joined:
    Feb 4, 2009
    Posts:
    185
    It probably means that the problem is still there!
     
  20. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    146
    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.
    https://docs.unity3d.com/Manual/script-Serialization.html and also following some of the links from this page you discover
    https://docs.unity3d.com/ScriptReference/Serializable.html
    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.
     
  21. Invertex

    Invertex

    Joined:
    Nov 7, 2013
    Posts:
    993
    Your anger comes from a lack of understanding about why things are the way they are, and instead of learning about them you are assuming to know what is best based on what you like and know so far. You assume because you liked and put time into learning UnityScript that most other people must have too and that other ways are worse.

    We type
    f
    for floating point because C# supports double-precision values natively as well, which is what a fractional value will default to, full 64bit precision value, the f lets the compiler know "hey I don't want you to try converting this value from a double-precision to single-precision (32bit) float at runtime", as in most cases that would be a waste of an operation. Being able to type
    f
    is a very simple way to differentiate these precision types... Takes a second to learn and get used to, shouldn't be a complaint.

    The semi-colon is important because it allows YOU to be in total control of how the code is structured and ends instead of being at the will of some tab/newline-based compiler where the layout of the lines can screw things up easily. Just a tap of a key and you know for sure a line end will be processed... This is especially important with all the neat types of syntactic sugar C# has these days that can allow you to make complex/adaptive functionality with simple code, the semi-colon makes it visually easy to see every line-end.

    It is democratic, otherwise C# wouldn't have grown as popular as it has been, and as @npatch said, it was and is used by the vast majority of users, for good reason. Instead of getting upset about change, take it as an opportunity to learn something new and expand your knowledge, you'll be much better off knowing C# which you can apply to more than just Unity if you ever feel like it in the future.
     
  22. acme3D

    acme3D

    Joined:
    Feb 4, 2009
    Posts:
    185
    Honestly I don't care about how many person use a tool, and the fact that a lot use it doesn't automatically mean it's the best in the world.
    What I care about, is that computers should be a tool helping humans and not vice-versa. And this should apply to programming tools and programming languages too.
    Having to explicitely define what a variable is in 2019 is pure nonsense. This made sense when you had 8 or 16 bit processors with very limited memory (and very expensive memory) and therefore optimization was paramount. Also, processing power was limited, a compiler already had enough to do than trying to figure out what a variable was (shouldn't be that difficult after all). Today we have 64 bit processors and gigabytes of RAM: who cares?? Wasting what?
    Swift for example can use type inferencing and doesn't need a semicolon at the end of each line. But ok, it was designed a few years ago, not centuries. It simply means that another world is possible.
    And if I have to write 3 lines of code instead of the one I had before, yes, I do complain.
    Or should we talk about how yield is handled in C#?
    So, sorry, it's hard to accept that things are still in the Paleozoic. And, believe me, I've been learning and using quite a few programming languages, from assembly to Hypertalk or Pascal just to name a few.
    I know why you have to write "f" in a compiler: it simply shouldn't be compulsory or make sense today. In 2019 a damn compiler on 64 bit processor could figure out what goes into that variable. And if it can't and it's using 2 more bytes for that variable, honestly, who cares?
    After Forth I think C# and Objective C are among the most unhuman languages. A so-called high level programming language should be as close as possible to how humans naturally communicate and think.
     
  23. Hikiko66

    Hikiko66

    Joined:
    May 5, 2013
    Posts:
    1,021
    C# does have type inference. It has it with vars (which are type safe like swift vars), and it also has it with things like generic params or lambda params, the type is inferred by the argument, so specifying the type becomes optional because you've indirectly been explicit enough that it knows what type you will be using at compile time...

    So, swift defaults to double if you don't explicitly specify a float.

    C# defaults to double if you don't explicitly specify a float.

    You add an f is you want to explicitly make a number a float in c#. Unity script was the other way around. Default was float, you had to be explicit about doubles. Really you should just always be explicit.

    Who cares about efficiency? A lot of people. Far more people care about being explicit than about being efficient, though. How hard is being explicit, exactly? Did you spill coffee on your keyboard, and your F key is broken, so you have to copy and paste it every time you need to use F? I've been there.
     
  24. acme3D

    acme3D

    Joined:
    Feb 4, 2009
    Posts:
    185
    Sorry to deceive you, no coffee spillage on my keyboard. It's just that today's system can have the power to understand if a float is a normal float or a double, depending on the value you assign to it. Is it so difficult and frustrating having a system that does that for you? Or you feel some lack of control because you can't be explicit? When you write a number on paper, do wrote "f" or "double" or "int" after it? I don't think so, you just write it, and it can be understood by other humans, We want AI? Let's start from the small things please...

    I'll tell you one anecdote, back from the first days of the Mac (the 1Mb Mac Plus was a few months away).
    I was in contact with a company that was developing a hotel management program using 68K assembly language. They had the first beta after 6 months of hard work. Then the Mac Plus and HyperCard came out... In exactly one day I was able to replicate the same thing that these guys did in six months, and the product was even more stable: no bombs! You might say whatever, but that's what I care about. Period.
    If I have to choose a tool, I choose one that allows me to do the job in less time and have more fun. Then I'll probably spill my coffe on my pants while enjoying a sunny morning at the sea.

    Honestly I have more interesting things to do in my time rather than typing "f"s, even if the key is not broken. May
    We live in a free and very interesting world after all.
    さよならストリクトタイプさん
     
  25. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    146
    Sure it's your choice. Everyone has their own criteria and experience. "Honestly I don't care about how many person use a tool, and the fact that a lot use it doesn't automatically mean it's the best in the world." Nobody is claiming Unity is best in the world. On the other hand, Unity is a company and has to make decisions based on its users and their own vision for the engine. If you were to see it from a business point of view, does it make sense to continue allocating resources in order to support something that gets used very little and adds a significant maintenance cost especially because you want feature parity? Or did you mean to ignore the 85-95% of the other users and remove C# instead of Unityscript?

    Personally I don't like type inference because readability gets reduced big time, if it's not your project and your code exclusively. You might have the experience and knowledge and have no issue with that, but it doesn't mean others do as well. Even in the web world where JS is prevalent, there's still a good percentage of people that wanted Typescript to be made and a good portion of them using it. Perhaps it's not used primarily, but it's not negligible either. So it doesn't seem to me to be a solved problem.

    You speak about democratization not being the goal anymore, yet you are disregarding(in every step, quite literally "Honestly I don't care about how many person use a tool") what the majority wanted(given the statistics) and how Unity handled it.

    Personally, I'd rather have to write types and f for floats all the time than go back to the times I had to do hacks because the .NET profile was restricting me from using stuff that were available in .NET 4.0. But then again that's my personal opinion and situation. Except it was also a majority one, given the .NET profile upgrade, along with Nested Prefabs and better GC, have been the longest awaited feature requests in the engine's history. So from my perspective, they have been good on their part. Perhaps a bit late, but still good on their part when it comes to democratization.

    Lastly, you claim to care about efficiency and to have more *important* things to do, but here you are ranting in a random thread, long dead, about things that have nothing to do with this thread, about changes that happened 2 years ago, instead of looking for a tool you would be more comfortable with. I get that you want to rant because Unity has become uncomfortable for you but especially when you have so much experience to be wiser than the rest of us, that seems like a very inefficient thing to do.

    There's also the choice of making your own tools(see Jonathan Blow and Jai) in case nothing else suits you, which I'm sure you've thought about. Most of the veteran programmers constantly argue that ideally the best choice is to have your own tools as you have ownership and control over it and you seem to have the know-how for it. Honestly, I'd do so myself if I had the time to invest(also as a learning experience). But right now I don't and Unity gives me way too many things out of the box, or at least a way to do my work in the time budget I have.
     
  26. acme3D

    acme3D

    Joined:
    Feb 4, 2009
    Posts:
    185
    This thread might be two years old, but these debates are much older. And they will never end...
    Time to use my time for something more interesting and go for a coffe by the seaside!
     
  27. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    146
    Sure, they are older. I agree they will never end. Even C++ is still being debated over, so many versions after its birth and the users are still divided in three equally big camps. The ones that like C++ as it is and where it's going, the ones that don't but still have to use it because it was chosen years ago by their employer and they can't step away from it and also complain about the insufficient tooling even though it's that old, and the ones that migrated over to other languages and have moved on(Rust has been getting a lot of attention in the last couple of years).

    Anyhow, may you find a tool that satisfies you.
    Have a good coffee and a good day!
     
unityunity