Version 1.1a is now available on the Asset Store.
Version 1.2 Changelist:
- Fixed an issue with Editor object showing the log message about no reference towards them when saving a scene. It was harmless, but annoying.
- Fixed an issue with internal texture showing the same log message.
- Fixed a index exception while deleting an item in some specific cases. It was harmless, but annoying.
- Fixed the multi-edition on boolean editor.
- Update some internal icon; +, -, open, closed and the drag icon. They should be easier to see in both light and dark.
- Added IPreview interface that gives control over the preview panel of the inspector. New class in the DLL; InspectorPreview.
- Added a new attribute; “Tab”. Draws toolbar-like tabs at the top of a script, similar to the SkinnedCloth component.
- Added the standard “on scene” collider editor on the Box, Capsule, and Sphere collider.
- Added a class named TypeUtility. It is used only to retrieve a type in all loaded assembly based on its name.
- Added SkinnedMeshRenderer, TextMesh and Mesh editor.
- Added “very large array” support. Any collection having over 50 items only displays 50, and have arrows at the top and bottom to navigate in them.
- Added UDictionary, a fully Unity-serializable dictionary for Unity 4.5 and later. Does not work on previous Unity version.
- Added RangeInt/RangeFloat, struct used to set a minimum and a maximum. They use Unity’s MinMaxSlider.
- The Space attribute can now add space before an item and/or after it. Before default size is 0, after default size is 1. Does not change existing behaviour.
Will soon be submitted to the AssetStore once the documentation is updated.
Tabs;
RangeInt / RangeFloat;
Dictionary (Unity 4.5 only);
Preview;
Very Large Collection;
For more information, see the WIP Thread; Advanced Inspector - WIP/Feature requests - Community Showcases - Unity Discussions
Version 1.2 is now available on the AssetStore.
Updated documentation can be found here; http://lightstrikersoftware.com/docs/AdvancedInspector_Manual.pdf
Congrats on the release! Just playing around with it now… Is it possible to rename or remove the labels on a list?
For example, I’d like where it says “TutorialStoryData+Story [Story]” to use the property of “Name”. And hide the label that says “TutorialStoryData+DateClass [DateClass]”
It’s actually very easy Essential, you simply need to overwrite the “ToString” method in your class. Every object in C# automatically implement this method. However, if you do no override it, it just output the class’ name.
public override string ToString()
{
return name;
}
or if you want nothing to show up;
public override string ToString()
{
return "";
}
Don’t hesitate if you have any more issues, feedbacks, ideas, bugs or feature requests. We’ll try to answer them as quickly as possible.
Thanks LightStriker, I was able to change the title but unfortunately I can’t seem to get rid of the ClassName in square brackets on the end. How can I get rid of that?
Sorry, not right now. However, in the next version (1.3), it shows that “[class name]” part only if the class is not the same as the collection base type.
If you do a List and they are all “Story”, it’s redundant to tell you it’s a story.
How it’s going to look like in 1.3;
Cool, I’m looking forward to future updates. I feel like telling extra info like this though (the variable type, class type, etc.) might be better to be an optional extra that advanced users can turn on if they want to show it. Is it necessary when entering data to know that the variable Nested List is an Array of NestedList? I personally want to try and hide that stuff to keep it as clean and simple as possible.
Generally it’s a good tool though, it’s saving me a lot of time. I have a bit more feedback, mostly relating to the display of lists, but I’ve included some general usage feedback too:
-
I think all values that can be inspected in the Unity Inspector should be set to Inspectable by default. I think it’s much more user friendly for someone to just add the [AdvancedInspector] tag to a script and have it automatically show in the inspector and then make adjustments based off that, rather than the current setup. I found myself having to go through a script adding the [Inspect] tag to many variables.
-
The list remove item buttons ( – ) are right in between the foldout arrow and the draggable control… I think this will result in accidental deletions. I think the remove button should be pushed over all the way to the far right edge of the screen.
-
I feel a slightly more user-friendly arrangement of controls is: draggable control first, foldout arrow second.
-
Is it possible for the remove item button to have a confirmation popup before deleting an item?
-
Foldout arrows, + icons, and - icons all have shadows but I think they’d look better being consistent with normal Unity GUI (no drop shadows).
-
As addressed in my earlier comment regarding changing the titles of elements, I’m not sure if it’s necessary to display object names by default — perhaps this should be an advanced option? The titles could also be formatted a bit cleaner… E.g., “List of Story (10)” looks a little better than “List of Story[10]”.
-
When hovering cursor over a draggable control, perhaps it could change to a different icon (hand?) to indicate that it is draggable.
Good point, since on a Dictionary, there isn’t even space for that info. I’ll make that the next version only display the collection type in advanced or debug mode.
Frankly, this is probably the thing that had generated the most back and forth at the beginning of this tool. The problem is the AI is completely uncoupled from the serialization, and we know by default the normal Inspector is only displaying serialized item. Which mean it can display everything Unity is usually unable to display. It’s most likely something we could tweak, but I feel we would have to be extra careful.
Reading what you just said gave me an idea… It could simply be a switch in the AdvancedInspector attribute, like “InspectDefaultItems” and it would parse the fields like Unity does. Adding [Inspect] only to the items Unity usually doesn’t display would add them to the list.
Far edge of the screen? Probably not. However, I do understand your concern and I have deleted a few items by accident myself. Good thing the undo usually works fine. However, moving the delete button… somewhere else, is really something I’ll look more into.
The problem I see with this is that for some item the foldout arrow come first, and for other it would not be first. Frankly, I prefer if the foldout arrow is at the same place for all item. However, if I move the delete control somewhere else, it will make the drag control right next to the foldout arrow.
I really don’t think this should be a default behaviour. If I have to delete many items, it would piss myself off to have to confirm it all the time. However, that could definitely be an option added per field or per object.
Point taken. The shadows were an experiment in the last version to see if I could make the control popup out more. I’ll revert those changes.
See my first comment… That title will now only show up in Advanced or Debug mode. As for [ ] vs ()… I truly have no idea. Usually, brackets are related to collection, no?
Very good point. Adding that.
1 Like
@LightStriker_1 Good points, and good idea with parsing the fields the same as Unity, I think that’s the most expected behavior. Then a user can tag items to customize further, or to hide, etc.
As for the delete item button, I was reminded today that Unity’s native Script Execution Order function arranges the controls like below, so perhaps you could do something similar.
I’ll look forward to future releases and keep an eye out for new features I can suggest.
Thanks to ton of feedback, the next version has the longest changelist and the biggest changes so far.
Changelist for the upcoming version 1.3;
- IMPORTANT: All classes related to the Advanced Inspector have been moved to the AdvancedInspector namespace, for consistency with other assemblies (Ex.: System.Serializable) and not to pollute the global scope.
- The AdvancedInspector Attribute now have “InspectDefaultItem” property, which emulate the way Unity display items without the need to add [Inspect] on all your items. You can still inspect item Unity would not display by adding the Inspect Attribute.
- Help Attribute can now be tagged on a class, giving a help box in the header or footer. You can also place multiple instance of the Help attributes, which displays multiple help box.
- Help Attribute now has the “Position” property, which place the help box before or after the targeted member, or in case of a class, in the header or footer.
- Expandable Attribute now has the “Expanded” property, which forces an item to be expanded by default when first viewed.
- Group Attribute now has the “Expandable” property, which when false, the group is not collapsable and remains open, serving has a dividing box.
- Added a layout “header” and “footer” at the top and bottom of the inspector, before and after all the fields.
- Added an interface; IInspectorRunning, which gives access to the Header and Footer zone in the form of a OnHeaderGUI and OnFooterGUI method.
- InspectorField now support SerializableProperties, but please do not use it, it’s most likely full of bug since SerializedProperty is anything but generic.
- CTRL + Click expand all the child of the item expanded. (Ex.: All the subobject in a list)
- Removed the “[class name]” part of the label of a list when that item is the same type as the list itself. (Ex.: List, no need to tell you it’s an item)
- The collection type is now only display in Advanced or Debug mode.
- Removed the “shadows” from the following icon; add, delete, folder open, folder close.
- Fixed a null exception thrown when using enums in a Dictionary.
- Added cubemap to the supported type in the Preview.
- Reworked the layout a lot, such as adding 4 pixel to the left of the fields so they don’t stick to the window. Now nested item are “boxed-in”, which should make multi-level items easier to read.
- Lined up lot of items and subitem that were not properly lined up in specific case in both their label and fields.
- Fixed the Example6 where nested class where not serialized.
- Added methods “GetAttributes” and “GetAttributes” to the Inspector field, returning all instance of a multi-attributes.
- Fixed the aspect ratio in the Camera preview on Scene.
- SkinnedMeshRender “Bones” property is no longer “read only”, but it is now an advanced property.
- Added LightEditor to support Unity’s Lights.
- Added support for the Gradient type, another of those fancy hidden thing in Unity.
- The cursor is now a “grab hand” when hovering over the drag control.
- Added an EditorWindow example of external inspector.
1 Like
The version 1.3 is now available on the Asset Store.
Note that for some reason the Asset Store flagged it as needing Unity 4.5, but it works on 4.3.
Online documentation have been updated to 1.3; http://lightstrikersoftware.com/docs/AdvancedInspector_Manual.pdf
Advanced Inspector looks great. I’m most of all interested in the SubComponents feature. I am now reading the documentation and you refer to the ComponentMonoBehaviour chapter in the section CreateDerived (page 22), but there is no such chapter. Have I overlooked one or is there a separate doc?
Oh… Ouch. Well, that’s what happen when nobody review the documentation. I’ll update it, sorry.
As for now, I can always explain what’s the purpose of this abstract class.
Unity’s issue is the lack of polymorphic support except in 2 specific cases; ScriptableObject and MonoBehaviour. Everything else loses its types and revert to the field’s type on serialization.
So a sub-component must derive from one of those two to retain its proper polymorphic property as serialization. Sadly, ScriptableObject are not save-able in prefabs, so that rules them out.
To make a MonoBehaviour to act as a sub-component of another, the AdvancedInspector perform quite a few tasks in background. The ComponentMonoBehaviour stores its parent at creation, so if the parent is destroyed, the sub-component is also automatically destroyed. The AdvancedInspector performs checks on any selected GameObject and destroy any orphan ComponentMonoBehaviour, so that no left over is wasting memory or performance.
Note that there is unlimited number of level of nested sub-component; sub-component can have their own sub-component too. The AdvancedInspector also makes sure the sub-component are not handled as standard MonoBehaviour, so they are not displayed independently in the inspector, but only as being part of their parent.
Finally, the AdvancedInspector handles sub-component differently when it comes to copy/pasting them. When you copy/paste an object deriving from UnityEngine.Object, only the reference is copied over. Everything else is deep-copied recursively. However, sub-component are handle as if they were not deriving from UnityEngine.Object, and are deep-copied, to keep the rule that a sub-component can only exist at one place and have one parent.
Here’s a camera system that have been built using this method, it’s a good example of a composition pattern;
The camera behaviour have been split into all its logical parts. So now the designer can assemble the camera he wants using all those separated blocks. In other words, this camera system can do EVERY camera you or the designer can imagine, and can transition from one context to another all by itself.
There’s a few very useful advantage;
- Very easy and fast to create or destroy sub-components, can be handled like lego blocks.
- Adding new sub-component type is as easy as writing the class, everything else is done by reflection.
- Unlike most AssetStore system, no extra GameObject are created per items, and the Inspector is not clogged with extra MonoBehaviour, the sub-component is only visible in its parent.
- Can be put in prefab, copied, and the system keeps its structure and integrity.
- Very hard to properly do composition pattern or your own component pattern without it.
Here’s example of a component-pattern system that was built around the ComponentMonoBehaviour;
Each “clip” in this logic flow chart is a ComponentMonoBehaviour added to the GameObject containing that chart. The parent of the clips is the chart itself. So if I delete the chart, all the clip are deleted too. In this case, the clips are not added in the Inspector itself, but in this custom EditorWindow.
The number of application is endless. Imagine you have a AI and you want to choose which attack pattern it should perform. The attack pattern can be a sub-component.
It’s a system I used on a daily basis, and my life would be quite more painful without it. 
Hey @LightStriker_1 — Just got the new version and it looks GREAT! Lots of nice little aesthetic changes to the way lists are displayed, and the little hand cursor just feels real nice now. 
But I noticed your technique to override the ToString method with my item names is no longer working… is that not possible to use with the new version?
I also have a small question regarding expanding. I don’t think Advanced Inspector currently saves editor prefs (e.g., which list items are expanded or not), and currently my lists all collapse after running the game. I’m hoping you can automatically save these properties in a future release, but in the mean time how can make all items in a list to be forced expanded? The manual says I need to set ‘Expanded’ to equal true, but I’m not sure how exactly to do this?
It still works… Only not in all cases. You see, right now I haven’t put in places check to see if your class really override ToString or it doesn’t, and I’m not even sure if it’s possible. When it is not overriden, the method ToString returns the class name, and I got people telling me they didn’t like that showing up, which is horribly ugly in case of nested class. So right now, the ToString is only displayed if the field type is not equal to the object type. So… if you are not using CreateDerive and ComponentMonoBehaviour, right now, it’s probably not showing anything.
I plan on doing a quick 1.31 version soon to add some quick fix. I need to find a way to sort it if ToString is properly overriden or not… Or make another method on my own. Still not sure, but quite open to ideas on this.
It’s true, currently nothing is saved and everything is flushed between reload. It’s a good idea to try to save stats in EditorPrefs, I’ll look into it. Save thing with the Basic/Advanced/Debug mode that should probably be saved too.
As for using “Expanded” property, let’s say you have the class;
[Expandable] // Usually you use that attribute to make it expandable
public class MyItem { }
And you want it to always show up as being expanded, you do;
[Expandable(true)] // Forces the default state to expanded
public class MyItem { }
In the examples, the class AIExample_ComponentA is flagged this way, and it always shows up expanded by default.
You can also put that attribute directly on a field/property to force that specific instance to be expanded by default;
[Expandable(true)]
public Camera myCamera;
It works on any item, list or dictionary included.
The version 1.31 is now available in the Asset Store with the following changes;
- Added a type-check when displaying an object label to see if the type overload ToString, so it would be called only if a proper implementation exist, and not the base one.
- Inspector Level and Sorting are now saved in EditorPrefs.
- Expansion state are now saved in EditorPrefs.
- Dragging a label to another label automatically performs a copy-paste of that field.
The version 1.32 s now available on the Asset Store with the following changes;
- Fixed undo issue with restricted field.
- Fixed undo issue with struct such as Vector, Quaternion, Bound, Rect, RectOffset.
- Fixed undo issue with string.
- Added some shading to the expandable boxes.
- Added the GameObject/Component picker tool.
Running out of ideas… So if someone want some feature in the Inspector, now is a great time to ask. 
I think the usage instructions are the biggest weakness currently. I still find it a bit confusing on how to do things. Perhaps it can be simplified or better explained in the manuals. Or even a video tutorial could be made.
I’m all for better documentation. I thought of making video tutorial, but since my spoken English is… well… not so good, I’m not sure how good it would come out. I thought of making written tutorials, but I simply have no idea where I could publish them, and I’m sure if bloating the packages with tutorials would be a good idea. I don’t think Unity’s forum would be welcoming of package tutorials. I’m all open for new ideas on how all this could be improved!
Do you have any specific point in the documentation that you feel is not well explained? Would help if I knew there was specific items in need to refining.
You can also mail me anytime you wish, and I would be pleased to explain how to do specific things.