Is there a solution for this in newer Unity versions? Or is Unity working on something to address this? even a work-around like changing the title of a component?
I’ve made a reactive event-driven system on top of Unity for everything from the FSM to meta elements and I am getting to the point differentiating components of same type is central to my code-base. This approach has saved me tons of code and time (no class is over 120 lines in over 10k lines of code), but it’s become very hard to tell which components are which on game objects. Pictures speak louder than words so let me show some of my game objects which I think speak for themselves:
Alternatives such as child game objects would not work, I can have dozens of these components on a single game object. Scriptable objects are also not valid here as some of these components rely on the game object transform and other components.
I am thinking someone must have ran into this problem before, any insight into this would really help.
Thanks for the responses guys, appreciate the quick input.
The biggest thing I’m looking to gain from this is to identify and tell the difference preferably at design time on referenced game components from same GO.
@AnimalMan , so I thought about your suggestion and I’m thinking if I can add a property to the component which shows its index in the GO and then also add a property of the index to the referencing component which uses the first component and the indexes are the same, that would greatly help. Of course, if @PraetorBlue is right about “order is not guaranteed”, it won’t help.
@PraetorBlue I’ve been using drag and drop and it’s been working fine for assignment, in fact my Unity set up consists of two inspector windows side-by-side, but I still need to know when which component is being referenced (please see last screenshot above), that is my main issue now.
edit
Upon thinking about suggestion above, the index can be an arbitrary value I can add to each game component which should be accessible from referencing game components and shown in its game component window. This is a roundabout way of doing it, but should work fine mostly. I’d still prefer some way to modify the title of the game component, that would be great if we could do that.
Another common solution is to create 1 child for each instance of the script. Often you already have these children, created for other purposes – for different layers, or to separate colliders or triggers; or so you don’t need to give scripts a link to what they effect, since it’s always “the child gameObject I’m attached to”.
Writing a little bit of code to build all of the needed connections on game start seems very cool, and sometimes it’s the only way to make something work; but it’s also more complex and more error-prone if there’s a simpler way.
There’s also GetInstanceId - each object and component already carries a unique ID with it. You don’t necessarily have to make/add your own indexing system.
You can even see this in Inspector by clicking the 3-dots icon and selecting the Debug state.
I had this exact same issue in my project. A previous dev wrote all these node components and used them everywhere. It made it difficult when one node would reference another node of a certain type on a game object and that gameobject had 2+ Nodes of that type on it, making it impossible to figure out which one it was referencing.
My suggestions.
Have all the nodes listed in the FSM component itself and drawn.
Make a proper Node-base Graph to hold your actions (a lot of work, but by far to most effective solution)
You could still use ScriptableObjects. just that when the FSM needs to run one of the actions it passes a reference of itself to the Action. If that action would need to access a Component or a Transform it can grab it via the FSM reference. Its not that much different from how you would extend from Unity’s StateMachineBehaviour class
