Frustrated with organizational options for inspector elements, seeking Guidance/ Suggestion

Unity Engine
1

It’s a Constant battle trying to keep a project clean, but also iterable. Many years into my project and I have not found a clean, and reliable way to organize my exposed variables so that variables are hidden when not needed, and visible when they are.

Here are some things i’ve tried in my workflow, and why they are not optimal:

[HideInInspector]: Ok great, it’s not cluttering my UI any more, but the only way to reveal these variables ever again is to go into code, select the [HideInInspector] bit, and delete it. I would love if these were toggleable to be shown in debug mode, it would be the best of both worlds.

Tidy up my variables within classes: Sometimes I throw my variables into serialized classes so that I get a very easy to create rollout that is collapsible and easily hidden, but this just makes it very hard to reference these variables in code. Also when I shift my existing variables to a new format, I lose all the existing data associated with these variables.

Is there some sort of easy #region setting I don’t know about that would easily allow me to hide my variables in rollouts in the inspector?

I’m not looking to deep dive into learning how to make custom inspectors with code, I’m hoping someone knows some low level trick that’s easy to implement to help with ever expanding variable and information noise that would still allow me to tune these variables when needs be.

My dream solution would be a setting like [SuppressInInspector, 0], where the int would define the level of suppression as a weight. If we set suppression of the editor to -1, it would show all variables that are suppressed, but if set to 1 it would only show variables set to a rank 0 or 1 (defaults to 0). And this value could be easily set somewhere in the Unity UI. It would be so darned nice to be able to expose variables based on importance without constantly shuffling around [HideInInspector]'s everywhere.

Thanks in advance for any thoughts. I’ve been dealing with these issues for a long time and finally figured i’d make a post because you simply don’t know what you don’t know. I checked out this video:

And although it’s exciting to think of the possibilities, it’s a lot more overhead than I’m looking for. I’m seeking an easy means of sometimes showing variables, and sometimes not if I ever need to access them.

2

I like to use [Header("blah blah blah")] to set chunks of variables apart from each other.

I also like to make ScriptableObjects for bigger blobs of stuff, also using HeaderAttribute liberally.

ScriptableObjects also let you have one for type X, one for type Y, etc., and each entry only takes a line in your inspector, and you double click on it (or right-click property) and off you go editing all the details.

Plus I hate making changes to scenes for silly small stuff like this, as it pollutes the source control log. I would rather have my changes recorded in a tiny little text-editable SO instance!

Generally I stay away fro any complex Editor code, unless it REALLY adds a lot of value.

1 Like
3

Never thought of using headers to indent and organize, going to give this a try!

I use scriptable objects a little bit for spawn lists but hadn’t considered using them lately for other things, might have to incorporate them more. The more I think about it, SO’s might be a lot better than the custom classes as I could mix and match them with a lot less internal lists and overhead. Might have to revamp a few systems, think i’ll be able to just paste the classes into the SO and then copy paste the existing values into them so I don’t have to tune the existing systems by hand again.

4

I also like to keep the names related, like:

MySuperClassController ← the MonoBehaviour with a slot for one of these:

MySuperClassConfig ← the ScriptableObject

And yeah, it lets you have a few different ones on hand, like a DEBUG one for instance.

Just make sure you don’t accidentally commit and save the debug one! That’s what good source control discipline is for…

1 Like
5

Mate, just buy Odin Inspector.

6

Not familiar with it, i’ll check it out.

7

Crikey how have you been using Unity this long and not heard of it? It’ll change your life with Unity.

8

I’m relatively new to the coding aspect of things and I just don’t know what I don’t know. The name Odin Inspector rings a bell and I knew it was a quality asset but back when I was more of an artist than designer/ coder it just wasn’t in my realm of things to need to understand.

I realize it’s beating a dead horse to naysay Unity as of late, but they could do a better job of marketing their best tools to their users/ let them know what they’re missing out on. This is an asset I absolutely would have bought, and studios would shell out hundreds of dollars to improve the output of their teams, but they didn’t know they existed or know what they do.

Anyway, better late than never! Thanks for the heads up.

9

I mean you can literally buy Unity Pro + Odin: Optimize Project Workflows with Odin Enterprise | Unity

I don’t think they could highlight an Asset Store product any better than literally selling it alongside your normal Unity license.

Nonetheless Odin’s 100% worth the asking price. It will save you hundreds of hours of work, if not substantially more once you learn how to use it on a deeper level.

10

Amplify Shader and Odin are listed at the bottom of the tools panel of the Asset store.

I wasn’t able to find the Odin link unless I explicitly typed “Odin Inspector” into the search bar. To my eyes Odin was largely invisible, and tossing it into the bottom of the tools section of the store with no visual cue it’s a cut above doesn’t do much to let me know ,“As a Unity user that’s creating massive variables lists in the inspector, Odin will greatly enhance your workflow.”

In recent years I’ve found they don’t upkeep their storefront very well, the “essentials” tab is a waste of prime real estate, there should be a few massive links to Odin, Playmaker, Amplify Shader, and maybe a few others.

There are certain tools that are so good, they build behavior in the user to buy further tools by instilling trust. They go beyond the internals of what Unity offers out of the box and the customer wonders, “What else am I missing out on” and Odin inspector looks to be one of those tools.

Could go down rabbit holes talking about how Unity could have gamified their engine and done neat tricks with their editor to showcase quality products to their users, or simply redesigned their store to better promote the absolute best of the best assets. All in all feels like they’ve mismanaged just about everything these days, which is a shame because the package manager is quite good now. Internally they may be having issues improving the engine, but they also failed in fostering and promoting 3rd party creators to create tools to improve their product as well.

I’m neckbearding out a little hard here and getting off topic blathering. Anyhow thanks for the insights guy, good chance i’ll pick up Odin and i’ll definitely be using headers as visual cues in the future.

Edit: Went ahead and nabbed Oden, after a little bit of research into the functionality, I am VERY excited to spend today organizing variables into differing tabs. This is going to change everything about how I work with my project. No more going in and turning swathes of assets from hidden to exposed again and I haven’t even gotten into the other elements. I’m sure i’ll also find some uses for the easy to use button click functionality to do various things in the future.

I’m so damned impressed by how well they showcase the features, and make it easy to reference and copy the code, while it being usable right in the damned editor right there, I went ahead and saved a workspace with this tab open “Learn Odin”:

Me right now discovering Odin:

1 Like
11

So I just wanted to say, that Odin Inspector pretty much changed my life today.

I didn’t know how much I needed [ShowInInspector] until today. I just accepted that any variables I was getting from logic derived from other variables I would have to debug in roundabout ways.

Not only does it allow for hiding of variables based on whatever Boolean logic you can come up with, you can start using enums to create entire variable list loadouts.

I now have a system where I can choose from several categories in an enum, and if I select abilities, i get a new enum field where I choose which ability I want to edit, and only the variables associated with these abilities show up.

My mind is blown right now how much easier I’ll be able to work with unity moving forward. Tomorrow i’m going to hook into my scriptable game objects when a value is changed and allow myself to instill those changes into the scriptable object by adding the ridiculously easy to add buttons to the inspector.

This is incredibly liberating, but also frustrating at the same time, because it’s been so damned long since we had cool new toys to play with in this engine, i’d almost forgotten what it was like to get a shot in the arm with awesome new features.

Tedious day just experimenting and cleaning things up, but so glad I gave this plugin a go.

My ONLY gripes are it seems to take a bit more finagling than it should to get things to hide when you want them to sometimes, and once you get going setting UI attributes for your variables, it just totally wrecks the bare bones cleanliness you once had as all your variables sorta get indented or made several lines long from all the bracket assignments. A few variable types like bools don’t come with well offset title alignments. The example code could have a few examples at the very top for just very scaled down practicle use cases like getting a row of bools together to save room in the inspector, or some enum hiding logic. These sorts of simple mechanics are far and away more handy to me than a lot of the more fancy stuff detailed in the tutorials.

Yeah i’m really kicking myself right now, I don’t even want to think about how many months of work I lost setting up stupid debug setups when I coulda just gotten this asset and used “showininspector”.

2060×1206 541 KB

12

Now wait until you discover [SerializeReference] and realise you can just make everything property data driven and composed, and don’t need to rely on fragile enums, hiding and showing certain fields based on certain conditions, and piles of conditional logic.

1 Like
13

Odin has something called an “AttributeProcessor” that allows you to add all non-serialization related attributes via code. This could help mitigate one of your gripes about your code becoming less clean and indented.

Written Tutorial: https://odininspector.com/tutorials/using-property-resolvers-and-attribute-processors/using-custom-attribute-processors
Video Tutorial: https://odininspector.com/tutorials/using-property-resolvers-and-attribute-processors/custom-attribute-processors

1 Like
14

It never ceases to amaze me how many rabbit holes there are to go down with this stuff! This looks like it would be really nice if my project was more scaled down and most the assets I were adjusting with oden were smaller chunks of upgrades with a universal organizational type taht could applied elsewhere, but as is I think I’d just end up moving one mess to another place and then I’d have to upkeep both areas at the same time. In another world maybe i’d have the time to deep dive more Odin inspector and really pin down optimized inspector workflows, but i’ve already devoted a decent bit of time to this and i’ve got lots of mouths to feed on this project in terms of what needs doing. Thanks for the link may revisit this in the future!

It wouldn’t be so bad if I could just indent at the end and put the variable underneath the properties, but when I do so, the autoformatter ends up making it several lines long, stacking each one on top of the other:

Not sure if there’s an easy solution for this. I’m trying to avoid pestering random people for insights into workflows online, one because it’s annoying, and two, if I asked questions for everything i’m not sure if there’s a better solution to, i’d never end up working on my project…

Also it’s debatable if offsetting the variable is better at all, as if they’re all stacked on one another, it allows me to very easily edit all the fields at once using alt and dragging vertical sections of the logic and typing in stuff to many variables at once that share the same properties.

At the end of the day I just want to be able to tell my bite attacks how much damage to do, it’s amazing how many tertiary elements are required to make that happen…

15

You can combine multiple attributes into the one set of square braces with commas. And it doesn’t become too hard to read so long as you follow a standardised pattern across your project.

A lot of my serialized fields look like this:

[HorizontalGroup("H1")]
[BoxGroup("H1/V", LabelText = "Values:")]
[SerializeField, LabelWidth(100), GUIColor("@Color.red")]
private float _someFloat;

[BoxGroup("H1/V")]
[SerializeField, LabelWidth(100), GUIColor("@Color.green")]
private float _anotherFloat;

public float SomeFloat => _someFloat;

public float AnotherFloat => _anotherFloat;

Which is to say, one-line per group on top, decorations on bottom. And properties too because most fields should be private/protected not public. The properties can then have a /// <summary> to describe their purpose.

Also, on top of what Schwapo mentioned about attribute processors, it’s worth mentioning composite attributes:
https://www.youtube.com/watch?v=RPvb8BT0Cxc

Though they have some limitations compared attribute processors. That’s where a custom attribute + attribute processor comes in to make the best reusable combination.

But that’s the beauty of Odin. It’s not just a selection of existing solutions, but a huge API to allow you to build tools that suit your workflow. Which is how I came up with tools I use extensively such as my SubclassSelector tool built on-top of Odin: https://github.com/spiney199/Subclass-Selector/

1 Like
16

I’ll be darned, very good to know, thanks!