The author of Advanced Inspector gave me a free copy over Christmas. I’d considered it many times, and always ended up choosing not to buy, and write my own fixes/workarounds instead. So I was keen to try this out on a hobby project and see how well it works in practice.
What is it?
A replacement for Unity’s built-in Inspector. This (optionally) changes the editing interface for every single Component in your Unity projects.
Why do we need it?
When you run Unity, you get the standard multi-pane IDE that is the Unity Editor. Whether you’re a programmer, a designer, or an artist, this is your main portal into Unity, and the starting point for all your work.
Anything you select in the 3D/2D scene causes an Inspector panel to appear, with all the editable data about that thing. Unity’s built-in Inspector is very basic; by modern standards of GUI/UX, it sucks. Fixing GUI is very expensive, so instead … Unity has gradually been making the Inspectors more and more customisable.
Traditionally this was very hard to do; in the last 12 months it has become much easier, and Unity has unlocked more features. To date, I’ve not been sure if the 3rd party plugins are fully using the new features.
Unity’s default Inspector: Issues we want to solve
This is NOT an exhaustive list, but these are some of the problems I hit on a regular basis:
- Prefabs don’t fully work in Unity yet
- Try nesting your prefabs; weep.
- Personally: I don’t dare do this, I saw too many Unity projects get corrupted this way. But some of the 3rd-party Inspector replacements introduce workarounds for this.
- Core C# is blocked/unsupported:
- Dictionary is unsupported; you cannot view them, you cannot edit them
- NB: there was historical reason for this: Unity itself doesn’t support Dictionary(!), and until very recently it was very difficult to add the missing support.
- Unity still doesn’t support Dictionary, but since 2014 you can add the support in approx 10 lines of code.
- You still have to copy/paste that code into every class that uses a Dictionary :(. But it’s better than nothing!
- Dictionary is unsupported; you cannot view them, you cannot edit them
- List’s cannot be re-ordered (Unity has a private class that allows this. It’s very good (I’ve used it), but it is not supported yet, has a couple of serious bugs still.)
- Inspector customization requires one new class … for every class you want to customize
- There is a half-implemented system for reducing this burden (see below), but it doesn’t fully work yet.
- Inspector customization on a “write once, run many times” basis doesn’t work yet:
- You CANNOT customize the rendering of Generic types (anything that looks like: “List<string>”) – the feature for this (CustomPropertyDrawer) isn’t fully implemented
- Until Unity fixes this, it’s surprisingly difficult to manually add support for Dictionary (it’s possible, but all the solutions are ugly and require copy/pasting code in your game projects. Error-prone and time-consuming)
- You CANNOT customize the rendering of Generic types (anything that looks like: “List<string>”) – the feature for this (CustomPropertyDrawer) isn’t fully implemented
Advanced Inspector
This plugin aims to add some of the missing features (Dictionary! List!), while also removing the need to keep writing new classes every time you want to customize something.
The most exciting for me was Generic List’s and Dictionary’s. Adding support for Dictionary would be transformative on the quality and speed of coding in Unity. It’s also (so far) hard to write yourself!
What do we hope for / expect from this plugin?
Price: $20-40
This is a low-cost plugin. It’s not expensive, so we expect something relatively simple. Professional devs would buy it without blinking – it’s practically free for them – but hobbyists will want to be sure this works well across the board.
NB: “total conversions” of the Unity IDE are especially dangerous: a bug in these can cause mayhem in your dev process. e.g. “I can’t edit the data any more!”. So … we have a higher bar of quality here than normal.
Documentation: PDF Tutorial
Personally, I greatly dislike PDF documentation – HTML is far better for a bunch of reasons. But this PDF (and the more technical PDF Manual) is well written and clear, with liberal use of screenshots.
Verdict: Better than expected for the price range
Core Features:
Here are the stand-out features I noticed in the docs/official page:
- “Every non-static fields, properties or parameter-less method can be exposed.”
- “Every list and array’s nodes can be dragged around to reorder them.”
- “Every field can be expanded to display the inner fields, being in a list or not.”
- “Every fields can be copy/pasted, even complex type, such as struct, or ComponentMonoBehaviour hierarchy.”
- “Every fields can be apply or reverted independently. No need to apply/revert the whole prefab.”
- “Every fields is fully dynamic; can be hidden, renamed, change color, display help box or change how the data is exposed at runtime.”
- “The inspector is now separated into two columns, one for the labels, one for the editing field. The separator can be moved around, no space wasted.”
- “Add new data type, like Unity-friendly Dictionary, Ranges or Action Bindings”
- “Control the Preview section of the Inspector without a custom editor.”
Advanced Inspector: Basic usage
Out of the box, Advanced Inspector doesn’t do anything. As the author puts it:
“By default, the Advanced Inspector does not change any standard behaviour on how your MonoBehaviour or your ScriptableObject are displayed in Unity’s inspector. This behaviour of being “off” is wanted.”
To enable it, it’s not a simple “on/off”. Instead, you have to edit every single source file and copy/paste some new code into your scripts. How much code? As it turns out, this bit is much less painful than it sounds. All you need is:
[csharp]
using AdvancedInspector;
[AdvancedInspector(InspectDefaultItems = true)]
// …your "public class BLAH : MonoBehaviour {" goes here
[/csharp]
Do this, save, and … Advanced Inspector immediately starts working, out of the box. You don’t have to click, refresh, or anything; Unity immediately changes the Inspector for whichever class(es) you edited.
Verdict: easy, relatively painless – but a poor start. For large projects, or ones where you do re-use between games, it’s creating artificial coupling between codebases, and makes your code harder to maintain going forwards.
GUI changes
Unity’s built-in GUI is fugly. I was looking forward to see how the GUI changes :). Here’s a small but fairly rich Component from a hobby project of mine:
[csharp]
public class PlayingCard : MonoBehaviour
{
public Renderer rendererForFace;
public Text textTitle;
public Image imageCardArt;
public Deck currentDeck;
public CardData data;
}
[/csharp]
The first three properties are standard Unity types. The last two are my game-code. Interestingly, one is a class (a Unity Component/MonoBehaviour), and the other a struct. Here they are:
[csharp]
public class Deck : MonoBehaviour
{
public GameObject blankCardTemplate;
public CardLibrary library;
public List<GameObject> cards;
}
[System.Serializable]
public struct CardData
{
public string GameID;
public string CardName;
public int hpMax, hpCurrent;
}
[/csharp]
Note that EVERYTHING here is either “Unity standard”, or “extends a Unity standard”, or “is Serializable”. This means that it’s all supported by the built-in Unity Inspector.
What happens in the GUI? On the left, the project before adding Advanced Inspector. On the right, same component (auto-refreshed by Unity) after adding:
OMG I can’t edit Transform any more!
Unity’s minimum width for Inspectors is 275 pixels; Advanced inspector breaks for anything less than 400 pixels.
But … it’s not as bad as it looks. To the left of the “X” components, you see a vertical line. This is a non-standard UI image, and it turns out: it’s a draggable divider; you can drag the divider left/right to uncover the (incorrectly) hidden fields.
Ignoring my custom Component for now, let’s see what happens with the built-in Unity ones:
It … sort-of works. Notes:
- It’s a nice feature. Unity’s hard-coded column widths are often annoying.
- It’s not perfect. Moving the divider changes it for ALL components in the inspector. This is bad, because Unity’s built-in Transform needs the divider on the left, but Unity’s built-in other components (e.g. RigidBody) need it on the right.
- If you resize your Inspector pane to 400 pixels or more, you can fit everything. If you’re working on a laptop? Get used to frequently resizing, every few seconds, to see what you’re editing, and then to edit it.
- You need to know the divider is movable. Newcomers to your project will NOT know this. Easy to explain, easy to remember, but it would be better to include the standard “draggable column” icon somewhere on the divider itself.
Where did my struct go?
Unity didn’t always support structs (sigh). But it has for more than a year now.
By default, Advanced Inspector doesn’t display structs. On my own, using the manual, I couldn’t get it to work. I reached out to the developer, and got some help on this.
With current/previous versions, you need to:
- Edit your CLASS THAT HAS A VARIABLE, and enable AI (as normal)
- Mark this class with: “[AdvancedInspector(true,true)]”
- Edit your STRUCT CLASS ITSELF, and specifically enable the struct-handling
- Mark this class with: “[Expandable(InspectDefaultItems = true)]”
I had problems with figuring out the right place to put the “Expandable” (there were no examples in the docs). If you get it wrong, you’ll get an expandable that expands to show … nothing:
However … the next version of AI will simplify this, and use “[AdvancedInspector(true)]” everywhere; no more need for the separate “Expandable” keyword.
Verdict: A little fiddly, especially since Unity renders structs out-of-the-box without this, but it works.
Advanced Mode
A lot of the value of Advanced Inspector comes from the fact it is … Advanced. This is a special mode, so let’s try it out.
NB: Unity has a built-in mode for Inspector, called “Debug”; if you don’t know how to use this already, try that first! It reveals a lot of private info on Components.
Left to right (note: because AI won’t work correctly at less than 400 pixels width, I had to shrink these to fit on the webpage. Click each for a full-size version)
- Unity’s DEBUG mode
- Advanced Inspector’s ADVANCED mode (enable by right-clicking in the Inspector, and select from menu)
- Advanced Inspector’s DEBUG mode (ditto)
Observations:
- AI’s ADVANCED/DEBUG modes made no difference to my custom Component; it has no private properties. I’d hoped they might fix the “not showing the struct” bug, but apparently not.
- Unity’s DEBUG mode contains some weird stuff; this is to expected: you’re exposing the PRIVATE data that Unity felt you had no reason / need / value to see (sometimes it’s useful)
- AI’s ADVANCED mode has some neat features – e.g. they’ve upgraded Transform with one of the most-often-requested features people ask Unity for. You don’t need AI to do this, but it’s a nice bonus feature.
- AI’s DEBUG mode … does NOT include all the data from Unity’s DEBUG mode. I assumed it would be “AI ADVANCED + UNITY DEBUG”, but it’s slightly less than that.
Verdict: I would probably set AI to “Advanced” mode, and leave it always-on. I want features like the World position on transforms!
Lists
Once you enable the plugin on a Component that contains a List, you go from this to this:
Pretty much what you expect. Instead of adding 1 to the “Size” field, you press the button at top of list (should be at bottom, following standard UX – but Unity stuck their Size field at the top, so it’s not such a shock).
The UX is weak (those labels + drag-handles on the left are hard to understand), but so is Unity’s built-in renderer for List!
Verdict: Unity’s private renderer beats this, IMHO. It would be nice to see a slightly better UI/UX here. This is a feature you will be using many times an hour, every day, while working in Unity!
Dictionaries
We’ll add a Dictionary to one of the classes where AI is already enabled; like List, we expect (hope!) it will Just Work.
[csharp]
// add "using System.Collections.Generic;" to file if not there already!
public Dictionary<string,int> testDictionary = new Dictionary<string, int>();
WARNING: there is a deliberate bug in this code; read on for info…
[/csharp]
Result:
Notes:
- This might be a side effect of the missing Serializable; see belowThere’s a bug: it cannot create a new “Dictionary” instance via the Inspector
- Your code MUST call “testDictionary = new …” or AI will fail to edit it
- In practice, this is not a big problem: in order to fix Unity’s broken Serialization of Dictionary, you will HAVE to write that code somewhere in your script anyway
- So … big bug, but very small impact.
- It’s picked up the datatypes (string for the Key, int for the Value) correctly
- If you type in a Key that already exists, the “plus” button is greyed out. Good feature!
- It would be illegal to have the same Key twice
- Although the UI could be much better here – e.g. show a warning + change button colour to orange or red, to make clear why the Key is being refused. Even better: hilight the Key it’s conflicting with (on a big Dictionary, it’ll be hard to find the duplicate)
- The hyphen to the left of each entry is actually a DELETE button, with no confirmation and no Undo
- Again, UI could be much better here
Adam’s stupid mistake: Dictionary is NOT serializable by default
Dictionary is still not fully supported by Unity – of course, this is one of the reasons we wanted AI in the first place!
Unity allows you to manually upgrade each Dictionary to be supported, using some Serialization callbacks, and manually adding the code that ought to be in Unity itself. There’s a blog post that explains how, as well as explaining why it took so long for this support to be added, and what some of the challenges are
Great!
What did I do in the example above?
Oh, yeah. I didn’t bother. So … my dictionary cannot serialize. Serialiaztion in Unity is NOTHING TO DO WITH SAVING TO DISK: it’s much lower-level and more core. It’s most often used in fact when nothing is changing on disk! I’ve seen it run merely because I moved the mouse across the screen.
This is fine, but it means my example above was stupid: As Sampsa points out in the comments, I should have provided a proper serializing Dictionary, and in that case, Undo would probably work correctly.
Verdict: Works great, although the UX/UI is poor. I have written better UI’s for this when making custom datatype editors in Unity and found it well worth the effort. It takes time, but it’s worth it: if you use Dictionary, you use it a lot, and spend a lot of your time in the editor with that GUI.
Undo support
Over the last few months I’ve discovered that some of the recurring bugs in Editor plugins are actually not the authors’ fault: they’re fundamental, critical bugs in Unity itself. I reported one recently that only takes a few seconds to reproduce, on any version of Unity. According to the support folks, it’s been fixed and will appear in a future version Real Soon Now.
Great. But … it leaves me suspicious of Undo support everywhere. (I found another Unity Undo bug last week. Sigh).
Undo seems to work fine with AI, except for the Dictionary (as noted above: this is probably because my Dictionary wasn’t being Serialized; this needs careful retesting, but I think it was probably a false alarm). Works fine with List – you can move things in a list, add to a list … all Undoes fine.
However, there is zero feedback in the GUI to tell you that an Undo has occurred. This is bad because it means you don’t know if the Undo has succeeded. I had to re-name my GameObject’s to unique names so I could confirm that Undo was working.
Verdict: annoying that Dictionary Undo failed. For List Undo, it isn’t AI’s “fault” that there’s no feedback (Unity should be telling you!). But … as noted at the start: with an Inspector replacement, you have to hit a higher-than-normal quality bar; you’re editing people’s sourcecode/data! I would like to see at least a flash, to show that the Undo happened.
Conclusions
GOOD: comes with source-code
It’s reassuring to have this, but … if I’m spending $40 on a product, I absolutely do not have time to be editing the source code to fix bugs. If I have to delve into someone else’s code and: understand it, learn it, plan modifications, modify it, test them, debug … and then re-do it all again each timew a new version comes out … ?
… then it’s cost me too much time, and I’m better off writing my own solution to start with.
GOOD: customized Transform Inspector
It’s a tiny thing, and you can write it yourself quickly and easily. But it’s a really really useful thing. I love it.
GOOD: eye-dropper tool for selecting things
Another minor feature, that worksaround a major Unit UX failure.
When you need to fill a GameObject field in Unity, you have to select the Component, then drag/drop the thing into it WITHOUT SELECTING the thing.
(if you select it, the Inspector vanishes, and is replaced with the Inspector for the thing you just clicked on)
AI gets around this by giving you an eye-dropper to directly select the “thing to go here” from the Inspector itself. Useful, but .. by now, I think most of us have learned automatically to do this via drag/drop.
VERY GOOD: drag/drop reorderable arrays
This is an old plugin, and some of the features (adding/removing stuff from arrays) have been added to core Unity since it was launched. But drag/drop re-ordering is still (amazingly!) missing from Unity.
I suspect we’ll have it in Unity 5, but that’s still some way off.
Again, this is small thing from a UI perspective. And AI’s implementation is very ugly (Unity’s own private-class version is a lot nicer looking). BUT … this code is very very hard to write correctly!
NB: I haven’t fully tested AI’s implementation here. Life is too short; there’s a lot of edge cases you have to check. It worked for a basic case I threw at it.
GOOD: Documentation
It’s not perfect. But it’s better than average, especially in this price range. I’ve seen $100-$200 Unity packages, even very popular ones, with considerably worse documenation! That’s shameful, but sadly true.
With a product like this the situation is constantly changing: every new version of Unity adds/removes bugs and features in Inspectors. I don’t believe any author can keep static PDF’s up to date. I don’t believe they can afford to! Especially not on the low price they’re charign here.
Ultimately, I would prefer to see a FAQ-style docs. Each FAQ tagged with a Unity version number, so you can see at a glance “for MY version of Unity, what’s possible? what works/doesn’t?” etc.
VERY GOOD: Developer support
Browsing the support forum on Unity3D.com, the developer is proactive and prompt in replying to support issues, and fixing them.
You’d expect this for every paid product, but sadly there’s a lot of lazy / cowboy developers selling on the Asset Store, and Unity corp does very little policing of this.
BAD: Defaults to disabled, everywhere
I kind-of understand, but personally I don’t like this. If a plugin is going to “fix” my Inspectors, I’d like it to “Just Do It”. Perhaps have a global setting “default on / default off”. But if I’ve chosen to import the package, that means I want to use it! I’ve already made the decision.
Note that after speaking to the author, this has been changed for the next version. See below for more info
BAD: Editing classes to enable the plugin?
This is a big problem for me, and most of the Unity projects I work on. At the very least, it’s time-consuming; at the worst, it makes the plugin “contagious”: once you use it on project, you’re effectively forced to use it on all projects.
Some examples of the problems I see now, looking at current projects:
- If you have many classes – say: 100 to 1,000 – in your project, … it’s going to take you a LONG time to enable the plugin individually on every one
- You’re hard-coding every class to depend on this Editor plugin. If you stop using this plygin, C# won’t “ignore” the import: it will refuse to compile/run your game.
- You now cannot share your code between different projects, unless you add this plugin to every project.
Note that after speaking to the author, this has been changed for the next version. See below for more info
BAD: requires minimum of 400 pixels width
I’m going to give the author a free ride here: yes, it’s a silly bug, and yes it makes a big negative difference to editing.
HOWEVER … Unity’s engineers made it extremely difficult for us to control width, and adapt to it, when resizing custom Inspectors. Unless you’ve tried it, you would not believe how hard it can be!
The “solution” is for someone to write a new plugin that requires a minimum of Unity v4.6, and uses the new (fixed) GUI API built-in to Unity. But it would be a brave author who does that: currently only 25% of Developers are using Unity 4.6 or later. As a plugin author, you would lose 75% of your revenue immediately!
BAD: Undo support is incomplete
The interface in general for Dictionary is poor, and List isn’t great.
To be honest, I could live with this. I know it would cause some dataloss – stupid mistakes when we’re tired or rushed, human error that wouldn’t have happened with a better UI. But it’s still a big step up from Unity’s refusal to render Dictionary at all, and Unity’s poor editor for List.
Final conclusion: Buy or Don’t Buy?
To be clear: I didn’t use every feature. This plugin is a combination of multiple different, unrelated features and fixes. I’d prefer multiple smaller plugins that each do one thing (even if they depend on one shared backend), but I covered the ones that seemed most exciting to Unity Developers, and the ones that make a big difference to me.
It’s cheap, and there’s good stuff here. Over time, as Unity improves the underlying APIs, my biggest issues here might get fixed. In particular, if the author upgrades it to require a minimum of Unity 4.6, I can see this being a really useful tool.
My initial conclusion was: “but for me, I need structs, and I’m not willing to make every single file dependent on this plugin forever more”. I spoke to the author about this, and suggested a global “default to on / default to off” toggle – and he added it:
Just getting access to Dictionary and reorderable List is a major win, and to do it with no source-code changes is great. It’s possible you’ll hit problems with other 3rd party plugins that try to improve Inspectors – but off the top of my head, the only other ones are like AI, and you’d expect them to be mutually exclusive anyway.
More reviews?
If you have your own assets up on the Unity Asset Store, and want me to review them, send me a voucher. Or get the author(s) to.
I’ll only review assets I can actually use in a real project – the review might have to wait until I have a free weekend to try it out. But if that’s OK with you, send me an email (address at top of page).
PS: how much do you pay for your plugins?
As an aside: when I was considering the earlier version (before I got the info on structs, and before the global on/off toggle), I thought a lot about value/price.
I would have preferred to pay 2x as much, maybe as much a $70 or $80, to get a fully working version that does everything Unity does, and has no (or fewer) code-level dependencies. From what we see on the Unity3d.com forums, it seems most Unity developers would refuse to pay that, on principle.
(The principle being “I’m too poor/cheap/don’t value your work, even though it would take me months to do it myself”). If you want to change this, encourage your fellow Unity devs to pay more for plugins (and, of course, hold plugin authors to a high standard too)
4 replies on “#Unity3D plugin review: Advanced Inspector”
Great review! Personally I wouldn’t go and replace such a fundamental part of Unity.
Support for sortable arrays and dictionary is nice. Some of these features are such that I’d like to have them enabled case by case. Not all arrays need to be sortable. And having this kind of coupling is no-go in my books. When the plugin doesn’t work as expected and you need to remove it after all or not everybody likes it – imagine the situation when you have dozen programmers and hundreds of script files… Auch :(
BTW I think adding support for something that doesn’t serialize is quite problematic – the whole undo system is based on serialization. Protected and non-serializable fields (such as Dictionary) won’t get serialized and will not be included in the undo. I don’t know how to work around it.
Also, what use is the inspector for Dictionary if the contents won’t be stored in the component/prefab/scene?…
Great review, more of these please!
Cheers,
Sampsa
ARGH! That’ll be why that Dictionary didn’t Undo. My bad – I’ve never tried using Undo on things that haven’t been upgraded to Serializable before, it didn’t occur to me that one requires the other. But it makes perfect sense considering how broadly and deeply Unity relies upon its serialization layer.
The developer’s addition of a “Default on/off” switch is a huge feature IMHO. It greatly reduces the dangers of the “what if” scenario you describe. I am like you, though: I would limit myself to using the *passive* features of this plugin (the improvements to inspector, the Dictionary/List etc) … and avoid the *active* ones (using the plugin to give you an artificial enum; using it do UI colouring, etc).
Re: “what use is the inspector for Dictionary..?”
– I only demo’d it this way to get a quick screenshot + interactive demo. I’m not using Dictionary’s on any of my live projects.
In reality I’d be using a properly upgraded Dictionary (with the new Unity ISerializationCallback stuff), and so yes: it would all be auomatically and correctly stored.
I’ll edit the post to explain that better.
Articles like this do nothing but reinforce why I stopped using Unity after the pain of working around all its deficiencies in two major projects.
I ended up dusting off my incredibly rusty C++ skills and going to UE4 instead. Haven’t regretted it, even though I still hate C++.