Discussion to beautify the inspector

Good eve.

I know about using [Header(" Stuff ")] to insert a title above some public variables. But what else can I do?

 

Real talk... Odin. Seriously, there are very few assets I recommend. I'd never start another project without this one.

On a slightly more direct note: Space, Header, and Tooltip are ones I use in basically every monobehaviour. After that it's usually custom property drawers and finally custom inspectors if I really need something specific. Though Odin has saved me from having to do that last one for a very long time now.

 

What about if I wanted a couple of variables attached to a drop down header is that custom or is that built in?

 

If you want something free check out NaughtyAttributes https://dbrizov.github.io/na-docs/

 

Hey don't worry guys

https://docs.unity3d.com/ScriptReference/PropertyDrawer.html

I found something I think it was what I want

 

There is nothing like that built in but both Odin and that github link PraetorBlue provided can do this.

 

I know I looked at the odin docs pretty huge stuff. Thanks guys its just not that important because I'm not selling the inspector or anything. Just wondered maybe there's something simple like header to collapse them but I see this have to draw them into a box. Makes sense but honestly it's just so not important I can't be bothered. So il live with the headers and start flushing variables to private to keep the thing neat.

 

Let me explain the deal here.

Last two days i programmed a really nice chess I programmed chess a few times but this time I'm going for the really good AI setup because I anticipate the math will be fun. So anyway I carry alot of data for each piece in a script. They are as you say polyamorous poly you know what I mean polygonal scripted. In other words, they are all one object that is told to respect different rules to which define it into a chess piece. And until I load the data they respect from outside source I've written some prototypes in public inspector. So the inspector can make prefabs or use obj refererence from my scene. and so looking at the inspector like this can get quite long as I had added a lot of movement options. Variablised rules like en passant . So I seperate some of the var that apply to these rule groups with headers.

But so I see now that to get it a tad more neat is not as simple as slapping a header

 

Well again, that link posted has a property drawer that does exactly what you describe. Here's a link to an example. Literally all it will take is to install the package and then use the [BoxGroup] or [FoldOut] attributes. It shouldn't take more than a couple of minutes to get it working and it will well be worth it

https://dbrizov.github.io/na-docs/attributes/meta_attributes/box_group.html

https://dbrizov.github.io/na-docs/attributes/meta_attributes/foldout.html

 

I could remove it for retail? Or will it leave something

It's scary stuff for me I'm not sure

 

Attributes are very lightweight and generally aren't going to have any performance impact unless you specifically use reflection to pull the data out at runtime. So for all practical purposes they will only have any effect in the editor.

 

Actually i just realized you were probably referring to the library itself. I wouldn't worry about removing it at build-time. There is really no point. The library is covered under MIT license and as I said above the performance impact is beyond negligible.

 

If you use classes, their variables are foldable in the Inspector.

 

Attributes are just meta data, so they are a tiny bit of extra data attached to a type (not instances). Most smart devs using attributes for editor stuff will also decorate them with

[System.Diagnostics.Conditional("UNITY_EDITOR")]

- like Odin does - so they get stripped from a build anyway.

Naughty Attributes is useful for simple inspector stuff. If you need heavily involved custom editor work - and lets be real, every project does - then save yourself the hassle and invest in Odin Inspector.

 

Il consider it for some time.
It's actually unusual for me to use the inspector. Usually this type of data i have brought in from elsewhere and populate the objects. So if I wanted to modify a variable id just open the file for it and change it rather than save to scene meta , as for expanding data which has no foreseeable limit while the games content grows i think it's safer to store data that way for organisation. While keeping it in unity I felt to be fragile in the past. Possible for scene corruptions who knows what. So although I ask I will probably just start loading my content and making the variable changes outside the editor import at runtime and keep the editor for internals dev stuff and bug testing. So that would put the bulk of stuff out of the way. Same as such using game object find can help keep stuff out of public specification. Especially if it's just map objects or scene starting objects.

 

If you want data that doesn't belong to a scene, that's what scriptable objects are for.

 

I recommend getting over that fear as soon as possible because attributes are very normal in C#, and if you think using one or two in a script is bad just wait till you see the examples for Unity made to show off DOTS ECS.

Spoiler: Boids

Code (CSharp):

1. [BurstCompile]
2. partial struct InitialPerBoidJob : IJobEntity
3. {
4.     [ReadOnly] public NativeArray<int> ChunkBaseEntityIndices;
5.     [NativeDisableParallelForRestriction] public NativeArray<float3> CellAlignment;
6.     [NativeDisableParallelForRestriction] public NativeArray<float3> CellSeparation;
7.     public NativeParallelMultiHashMap<int, int>.ParallelWriter ParallelHashMap;
8.     public float InverseBoidCellRadius;
9.     void Execute([ChunkIndexInQuery] int chunkIndexInQuery, [EntityIndexInChunk] int entityIndexInChunk, in LocalToWorld localToWorld)
10.     {
11.         int entityIndexInQuery = ChunkBaseEntityIndices[chunkIndexInQuery] + entityIndexInChunk;
12.         CellAlignment[entityIndexInQuery] = localToWorld.Forward;
13.         CellSeparation[entityIndexInQuery] = localToWorld.Position;
14.         // Populates a hash map, where each bucket contains the indices of all Boids whose positions quantize
15.         // to the same value for a given cell radius so that the information can be randomly accessed by
16.         // the `MergeCells` and `Steer` jobs.
17.         // This is useful in terms of the algorithm because it limits the number of comparisons that will
18.         // actually occur between the different boids. Instead of for each boid, searching through all
19.         // boids for those within a certain radius, this limits those by the hash-to-bucket simplification.
20.         var hash = (int)math.hash(new int3(math.floor(localToWorld.Position * InverseBoidCellRadius)));
21.         ParallelHashMap.Add(hash, entityIndexInQuery);
22.     }
23. }

 

So the variables will be stored in memory for quick access at an organized location that is not random? I have no idea what burst or the goal of it yet we define the struct as something we burst compile. Must be quick access in some sector. Is it really that simple? Looks quick to make use of for me basing from the example there.

 

I wouldn't pay too much attention to the purpose of the code. I'm just pointing out that attribute usage is common.