Advanced Inspector - Never Write An Editor Again

I think that the biggest confusion for me is the lack of UnityScript documentation. It’s a shame that some of us were raised on UnityScript and haven’t yet mastered C#(!) but some UnityScript examples alongside the C# examples in the manual would be incredibly helpful to me personally.

Another thing that confuses me sometimes in the manual is that some of the language sometimes is a bit too technical, for example…

“The base abstract class ComponentMonoBehaviour is an important part of the composition/sub- component pattern. You should never apply the CreateDerive attribute on a field or property that does not derive from ComponentMonoBehaviour, otherwise your object will revert to the field type on the next serialization reload.”

Pardon? :sweat_smile: A lot of the manual is written like that. I’m sure it’s the correct terminology and a lot of people will understand it but I struggle with it sometimes, and I’ve been learning programming for a few years now! You’re not the only Asset Store author who writes like this though, but maybe the manual can be written in a more general layman manner and include the technical language for the more advanced users in sub-sections.

I would personally not mind if there was an extra pdf included in the package that was aimed at people like me, with simplified language and a walk-through written tutorial on how to use it.

The rest of the manual is well documented though, and is impressively illustrated with lots of good screenshots! That side of it is certainly excellent.

I’m sorry about that, but I have very little experience with UnityScript, so translating the whole documentation could take a long while, or even be inaccurate. However, from what I see, it’s usually just a matter of syntax… So even if the doc is in C#, you should still be able to decipher it somehow.

I see what you mean. I guess it’s the issue with terminology, if I use other words, they won’t be as accurate and someone could get confuse. On the other hand, proper terminology is not easily accessible.

Now, that is something I could do, even if I somewhat expected the 18 example classes in package to be helpful in that matter.

Do you have some ideas of what topic would be more useful for such tutorials?

Yeah, I have used the example scripts to some success, but it’s less than ideal; it’s a bit like using them as a rosetta stone to translate the main document, if you know what I mean? But yeah, a separate tutorial would be much more useful!

I’m not sure of what the tutorial could focus on, but it should be a serialized data object that could be useful in common game development (perhaps an object that keeps track of all enemy data, level data, or item data in an RPG; something which can show off as many features of Adv. Ins. as possible in one project). I think the ideal tutorial approach would be to build it a step at a time, beginning by showing how to display a few simple variables, then slowly adding features such as sliders, colors, dynamic attributes, etc. so the reader can learn how to utilize as many features as possible.

I think this would also be great marketing for the plugin, as you can show off what kind of an advanced project can be done with Advanced Inspector. And if this written tutorial included both UnityScript and C# code, then the existing manual pdf should ultimately be a lot more easily understandable for UnityScript users as well, as we will have learned the differences in syntax from this tutorial.

If you go ahead in trying the idea I will be happy to help test out the resulting tutorial.

hello, i’m having some issues with advanced inspector.

I have this code in a script

[Inspect]
private Priority priority = Priority.Normal;

In editor I set the priority to be Priority.High , but after I press play the priority resets back to Priority.Normal.
If I change the code to the classic

[SerializeField]
private Priority priority = Priority.Normal;

this works as I want and it won’t change back to Normal after pressing play.

Halp please :slight_smile:

Private field are not serialized - saved - by Unity by default. The Advanced Inspector does not change any of Unity’s serialization. Unlike Unity’s Inspector, what the Advanced Inspector displays is not limited or linked to what is saved.

In other words, the Advanced Inspector has no issue displaying items Unity is not saving.

You have two ways to make the Advanced Inspector display your private field while having it saved by Unity;

    [AdvancedInspector(InspectDefaultItems = true)]
    public class MyClass
    {
        [SerializeField]
        private Priority priority = Priority.Normal;
    }

The “InspectDefaultItems” makes Advanced Inspector display all the items the same way Unity would without the need to flag your items with “Inspect”. Meaning everything that Unity save would show up. This is the fast and easy way to convert a class to work with the Advanced Inspector.

Otherwise you can force items to be displayed as;

    [AdvancedInspector]
    public class MyClass
    {
        [SerializeField, Inspect]
        private Priority priority = Priority.Normal;
    }

You are not limited to a single attribute by item. Here’s an example of a field with multiple attributes;

    [SerializeField, Inspect, Group("Gameplay"), Descriptor(1f, 0.8f, 0.25f, Name = "NPC Weapons")]
    private WeaponType weapon;

The fact that Unity’s Inspector only display items Unity is able to save is great for new comers. It makes it easy to do the relationship between what is saved and what is displayed.

However, when you go a bit further, and you need to display debug info, stuff not saved, properties, custom type and so on, Unity usually asks you to write your own custom editor, which is a major waste of time.

For this task, the Advanced Inspector display item by reflection. It is completely disconnected from what is saved or not saved. So it is up to you to make sure that your items are saved properly following Unity’s rules;

  • public fields are saved, unless flagged with NonSerialized.
  • private/protected fields are not saved, unless flagged with SerializeField.

Wow, nice.
Works like a charm, thank you!

My pleasure.

Don’t hesitate if you have other issues.

with lists is there any way to hide the re-order and remove buttons? artists accidentally re-ordering and deleting items too easily…

thanks.

Size attribute removes the “-” button and prevents creating or removing items from a list. It forces a collection to be of a fixed length.

The following leaves the size of the array to be controlled by your own code;

        [Size]
        public int[] myArray = new int[10];

Or you can force a collection to be of a fixes size directly from the attribute;

        [Size(10)]
        public List<int> myArray;

Also note that if they delete an item by accident, they can undo it with CTRL+Z. However, there’s a bug on an undo where the Inspector is not properly refreshed, but the item is really properly undo’ed. Re-selecting the object show the undo happened.

As of version 1.32, there is no way to remove the re-ordering control. I’m noting this for 1.33.

Just checked back, and yes, you can remove the ordering control with the Size attribute. You have a “Sortable” property in it that removes the control to sort a collection.

My bad. I will probably rename that Size attribute for something more fitting.

Great, thanks for the fast response LightStriker! Just an idea, could add an “artist” view-mode like you already have basic/advanced/debug etc.

And what would an “artist” view do?

hide the re-order and remove buttons. Different view-mode seem more intuitive than adding " [Size (false)]" to everything.

hey I used that great idea you had in another thread for displaying the name of an item in a list of custom-classes. Override ToString() and return the name string. Works great, a bit like how adding “public string name” in the default inspector would name array items.

Is there any way to make the name display on the left where the “[0]” is, instead of on the right?

1730282--109173--Screen Shot 2014-08-11 at 7.12.22 pm.png

I see your point but I think a lot of artists in other projects would need access to the reorder and remove controls for certain elements, so what happens in those situations? Though perhaps a flag [showInArtistView] could solve that.

Really? You got some weird artist on your projects if they never have to handle lists in any way.
Frankly, at that point, I have the feeling what you are more looking for is a global option specific to locking collection, instead of shoehorning that feature into another system.

Maybe an option in the contextual menu?

The issue I see if I was to do that is when displaying dictionaries. The value between the [ ] is not a number, but a key, and can be really long already.

thanks light striker, something in the contextual menu was exactly what I was looking for! cheers! Is this a feature in the next update or something?

is there some way to override what advanced-inspector displays in that bit? (where the [0] is)

Yes, it’s already coded and will be in the next version. The next version is taking a lot of time because of some features requested that are really not straight forward… Like the ability to only display one item from a collection at a time. You can see from my last image that the second “list” has a drop down menu on the right. On top, I’m writing extensive tutorials for newcomers. (Like “How to save and display Type”)

There’s also the ability to color the background;

Not currently. In the case of a dictionary, the “key” displayed in between the “[ ]” is the ToString overload. In case of a IList (array/arraylist/list), the value displayed is the index. I think removing the [0] could become very confusing very quickly. However, text could always be added next to it. Now just need to find the proper, cleanest way to do that.

awesome man thanks for that, looking forward to the update!