Diverse Visual Selector Attribute

Issue #587 new
V created an issue

So, i have ran into some issues when creating more complex systems. And one part of that is that i want to customize the selection of an integer/enum.

The use case is like this:
I have an enum filled with UniqueIDs, they represent an item visual. When designing an item, i would like to assign this enum in a meaningful way. But the best i can do is write a custom ValueDropdown. But that does not help in knowing what visual i am selecting.

The above case happens, if you are loosely coupling information/data inside Unity. Which often happens for bigger games if you don’t want your item data class, to also auto load all the attached images and meshes. But you do want to request those at runtime.

The proposed solution:

Add a customizable attribute, that in code works like ValueDropdown. As in, linking your integer/enum to a string representation in UI. But instead of that string representation, it would allow you to populate an asset list, as AssetList attribute does.
In my eyes it would look like this:

[CustomAssetSelect(“@CreateItemVisualList()“)]
public int myItemVisual

private AssetListData[] CreateItemVisualList()
{
//CUSTOMLY FILL THE DATA CLASS array or list
//sprite/texture + name for each asset, and the integer result on selection.
}

This would then draw your integer in the inspector, effectively as a default Sprite selector but with the item name added (and maybe the enum/int value for sanity sake?). And instead of a sprit, show the currently selected sprite of this list i defined in the CreateItemVisualList().
Upon trying to edit it, it would pop up a custom selector screen, but populated with this same data, defined in the method above.

Conclusion:

Using the above would allow for heavy customization, not only in the context given. You could basically visually represent anything you like, instead of having it as one giant dropdown box with text/search only (that also does not accept markup for color coding entries, i noticed).
I can also foresee this method being cripplingly harsh on the inspector if done wrong. Depending on how often that list is rebuild by odin internally.

Let me know what you think, and if this is worth the effort or not.

Comments (0)

  1. Log in to comment