Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice

Please add a renamer feature to components!

Discussion in 'General Discussion' started by HelloJinxie, Nov 7, 2019.

  1. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,128
    Thank you for dramatically misinterpreting what I said in an attempt to look smart. Unfortunately, all you've accomplished is looking foolish because you did such a poor job of it.
     
  2. Stardog

    Stardog

    Joined:
    Jun 28, 2010
    Posts:
    1,912
    Something like this:
    Untitled-1.png

    Most useful for colliders.
     
    Socrates and BIGTIMEMASTER like this.
  3. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    5,181
    Yeah that is what I was talking about too. In my case, I wanted it for script components.

    I would want the custom name to come first, though. This way if you got everything collapsed the generic name is what would get trimmed out first.

    If this is a real easy thing to implement and has wide range of useful application, seems like no brainer to implement into editor.

    Some people are saying it will break references, but it should be like that. It's only an organizational tool. Makes lists of components easier too read.

    More for designers than coders. The guy working in viewport to build levels.
     
  4. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,768
    Feels like unnecessary over complication.
    What is the point of GameObject name then?
     
    steve-thud likes this.
  5. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    But which one would you use with GetComponent?
     
  6. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Because the very next question after this feature is implemented is going to be "I have two colliders on my GameObject. One is labelled HumanCharacterController, the other is labelled EnemyAgroRange. How do I distinguish between them in OnCollisionEnter?"

    The last thing Unity needs is another opportunity for text based programming.
     
  7. Stardog

    Stardog

    Joined:
    Jun 28, 2010
    Posts:
    1,912
    The answer is simply reference them in the inspector with a public field.

    Maybe a visual scripting system for MonoBehaviours would help them... but they abandoned that, didn't they.
     
  8. kburkhart84

    kburkhart84

    Joined:
    Apr 28, 2012
    Posts:
    910
    I won't disagree that there are plenty of ways to handle it currently...I just happen to agree that at the least in the specific case of colliders it could be handy to have a way to easily name them...like in a fighting game. Instead of doing a workaround, like having child objects, or adding yet another component(even if it is just a text label, which is just another workaround), you could have a label right on the collider inspector itself, and easily be able to identify which collider is the arm, the leg, etc... You also then wouldn't have to worry about ordering the text label components in the inspector as they wouldn't be separate from the colliders.

    That said, I'm sure there are other use cases. But yeah, there are plenty of workarounds, so I wouldn't suggest Unity rush to get it in there, rather just have it under consideration.
     
  9. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,619
    A GameObject can have many components in it. Sometimes it can have multiple of the same component. Knowing only the GameObject name and a Component type isn't enough to identify things in all cases.

    With my example from earlier, it's common to have multiple AudioSources on something. Right now, when there's an AudioSource reference in another object, it shows the GameObject name and the component type only, so there's no way to know which of the AudioSources the reference goes to.

    As others have pointed out, it's also common with colliders. Eg: do I have my trigger or my hull in this reference?

    So the GameObject name is a label for the aggregate object, eg: this is an Enemy_Robot or whatever. The component name is to identify a specific component within that, eg: HeadTrigger as compared to CharacterCollider. Both the GameObject name and an optional Component name have distinct purposes.
     
  10. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,011
    The way I see it, the ability to add a note to a component is not at all for identification in code, but the user understanding context. You can easily create some codified gameobject name or tag for ID purposes, but that doesn't help when you are working in the inspector and you need to quickly orient yourself and understand perhaps how a component relates do a bigger aspect of design.

    So I don't necessarily think it should be accessible in code, it's more of an editor usability feature.

    I do understand @angrypenguin your example that a separate name would help, although perhaps properly named inspector properties could take care of that.
     
  11. HelloJinxie

    HelloJinxie

    Joined:
    Nov 7, 2019
    Posts:
    20
    This is mainly what I want it to effect. Only for visual and organizational purposes.
    upload_2019-11-12_14-30-55.png
    Capture.PNG
     
  12. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,619
    How so? Naming an inspector property effects the field the reference is in, not the representation of the component being referenced.

    Right now the only way to differentiate between components such as in my example is to break them up over multiple GameObjects, and give those GameObjects different names.
     
    MadeFromPolygons likes this.
  13. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,768
    Just a thought ...

    While I understand is none ideal, following is probably the easiest safest approach atm.
    Just adding script as component, without worrying about 3rd parties libraries, or upgrading to new Unity version.

    upload_2019-11-12_4-58-47.png
     
  14. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,011
    Ah yeah you're right, you can't have the inspector for a component open and then select a specific component from a different gameobject to drag into a reference. That's definitely a weak point.
     
  15. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,619
    You can open two inspectors then drag over just the one you want. Fiddly, but doable. But when you've done that, all you see in the inspector is "GameObjectName (Type)". If there are multiple components of the same type there is no indication of which one is being referenced.
     
    SparrowGS and Billy4184 like this.
  16. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,974
    What? No, forcing people to use the inspector is in no way a fix to the problem.

    Very very little (if anything?) in unity can only be done via the inspector, and there are good reasons for that. That would create a horrible workflow for anybody working in the professional sphere, where touching the inspector is done as little as possible.
     
    Socrates likes this.
  17. Stardog

    Stardog

    Joined:
    Jun 28, 2010
    Posts:
    1,912
    The funny part is that my propsed solution doesn't even work.

    Right now, there is actually no way to distinguish, even in code. You would actually need to reference, or loop using GetComponents, with an actual local OnCollisonEnter event (which doesn't exist). Unity only call the magic event, so you wouldn't know which collider hit, unless you measured it using the collision points or something.

    I don't know why they don't provide this:
    Code (csharp):
    1. BoxCollider collider1;
    2. BoxCollider collider2;
    3.  
    4. void Awake()
    5. {
    6.     collider1.OnCollisionEnter += collision => Debug.Log("Collider 1 hit");
    7.     collider2.OnCollisionEnter += collision => Debug.Log("Collider 2 hit");
    8. }
     
  18. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,974
    I agree that would be incredibly useful, instead of using crap like CompareTag or similar.
     
  19. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Seriously, you need to try having two inspector windows open. The possibilities will blow your mind. You can lock one to the component you are editing. Then you can use the other to grab all your specific references. I do it all the time, its one of the cooler features of the inspector.

    I've yet to have a case to do three inspector windows open, but I'm sure it will be epic.
     
    SparrowGS and Antypodish like this.
  20. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,619
    Usually it's better to have a custom editor at that point.

    On the note of Inspector improvements, it'd be great if you could set Inspectors to only show Assets or only show Scene objects. That way I could, for instance, click through Audio Clips to attach to my Audio Source without losing my selection of the Audio Source, and also without having to manually juggle two Inspectors.
     
    Kiwasi likes this.
  21. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,768
    I had once or twice. But most cases two are all I need.
    However, multiple inspectors are good for monitoring specific values.
    Or even considering multiple project tabs, with lock on.

    Btw., for anyone who is not aware of the lock.
    upload_2019-11-13_4-19-1.png
     
    Last edited: Nov 13, 2019
    Kiwasi likes this.
  22. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,011
    Its written in the ancient scripts that three inspector windows will trigger some kind of singularity that collapses all of reality into a AAA game!

    Multiple inspectors seems awkward to me though, also I've yet to test but I'm guessing you can't really tell straight away which reference it is you're looking at after the fact.
     
  23. steve-thud

    steve-thud

    Joined:
    Jul 18, 2019
    Posts:
    9
    Two things are being spoken about here:
    1. Renaming components (whether actually renaming them or just "nicknaming" them)
    2. Writing notes in a dedicated text box on a component in the inspector.

    My thoughts on renaming components: Multiple duplicate components on a single transform sounds to me like it would be a nightmare to work with. Personally I would hate to have a feature added that added an extra layer of wait-is-this-a-standard-component-or-a-custom-one. It would make jumping into pre-existing projects that extra bit difficult. To get the same functionality you can just break components up into child gameobjects! :)

    My thoughts on note text boxes: This sounds like it would add a lot of clutter to *every* component in Unity. I wouldn't be using them myself, and I'd have to have the ability to switch them off in my inspector. And once I've switched them off, does that then mean that I'm seeing different information in the inspector than my team mates are if they have them switched on?

    It sounds like the solution here is proper project documentation. Because how useful is a description box on a component if that component is buried in a terribly organised hierarchy of gameobjects? You still have to have an understanding of what objects are performing what tasks, just to be able to find the description box that tells you what the object's components are doing. With documentation for your project, you only have to read through relevant information that is designed for and exists entirely as text. Mixing documentation and a working game project together doesn't sound like a good idea to me!

    It's an interesting idea and I see the need behind wanting a description box for components, but it would have a lot of negative side effects for a large number of users, especially those working in teams. I would suggest looking more into using documentation as a clean and concise way of noting down how your project works for both yourself and potential collaborators.
     
    Kiwasi, Socrates and MadeFromPolygons like this.
  24. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,619
    Respectfully, it is not "the same functionality". For starters it requires more GameObjects, which can have a performance hit.

    This is a variation on "some people might use it incorrectly, so nobody should have it". You're absolutely correct that people should have proper project documentation anyway. Assuming that they have that, then also being able to attach notes within the editor - just like we can in our code, in our task management systems, and in many other places - could be useful.
     
  25. SisusCo

    SisusCo

    Joined:
    Jan 29, 2019
    Posts:
    1,317
    Don't want to side-track the discussion more, but I have to say that Power Inspector has solutions for many of the off-topic problems discussed here: cross-GameObject drag-n-drop, separate inspectors for hierarchy and asset views and better multi-inspector workflow.

    Now back to the main topic at hand...

    I think that being able to change the "name" of components is a very interesting idea. I remember that back in the day when I first started using Unity, I found it unintuitive that on the code side Component.name returned the same thing as GameObject.name. Even when coding it might be useful if you could easily print to the log more descriptive names for general-purpose component like "TweenTarget", "SetActive", "SendMessage" or indeed "BoxCollider".

    On the inspector side, being able to change the label displayed on component also seems like a very apt solution to some real problems. It has some big pros:
    1. You can see the display name of a component even if it is folded. This would probably not be true for a description box based solution (or if it was it could be irritating).
    2. Possible performance improvements when you have less of a need to split your units into multiple GameObjects.
    3. Possibility of reduced mental fatigue when you can more easily figure out what components do.
    4. Potential for improved searchability.
    Perhaps the biggest problem I see with it is the possibility of user-confusion, with beginners trying to use GetComponent in code with the component's display name.

    Visually separating the display name from the component type name in a clear way might help alleviate this a lot. Things like using a different font, text color, font size and/or adding parentheses around the display name could help.


    I can understand how some people are hesitant about this feature, since it could also be used to introduce more confusion if misused. If your inspector window isn't very wide, the display name can easily push the component type name off-screen. For MonoBehaviour type components that don't have custom icons, it might become difficult to know what they are if a bad display name is picked. E.g. "Set Player Active" would make it more clear what a SetActive component does. But if you happen to have co-workers that are really bad at naming things, I could imagine this feature being misused a lot :eek: But in that situation you're probably screwed anyways, so... :D

    Also, if the component type name was shown when the component header was mouseovered, it could help a lot with this issue. It would still slow you down, but not that much. Or maybe even something like being able to hold down a keyboard modifier key to temporarily switch all component headers to display the actual component types.


    As for the description box idea, I don't think it would be a good idea to allow users to hit some toggle in preferences to hide all description boxes globally. That could easily lead to critical information being missed. However, if every description box could be individually minimized once you've already seen it some many times you know it by heart, that could be interesting (ideally the description box would always automatically expand again if the description was changed).
     
  26. SisusCo

    SisusCo

    Joined:
    Jan 29, 2019
    Posts:
    1,317
    By the way, with the MeshFilter the inspector display name already differs from the type name!

    mesh filter 1.png mesh filter 2.png

    I actually think the ability to customize the display name in code based on the data of a component could be even more useful than being able to change it manually in the inspector. But both would be useful in different scenarios.

    Being able to do something like this would be cool:

    Code (CSharp):
    1.  
    2. public class SetActive : MonoBehaviour, ICustomDisplayName
    3. {
    4.     public GameObject target;
    5.    
    6.     /// <inheritdoc cref="ICustomDisplayName.DisplayName" />
    7.     public string DisplayName()
    8.     {
    9.         if(target == null)
    10.         {
    11.             return "Set Active";
    12.         }
    13.         return string.Format("Set {0} Active", target.name);
    14.     }
    15.     ...
     
    Ryiah and angrypenguin like this.
  27. CorWilson

    CorWilson

    Joined:
    Oct 3, 2012
    Posts:
    95
    Seconding this feature. I'm actually surprised this isn't even a thing with how easy it is to just add multiple components of the same type. What really bugs me about it is that you can have several uncollapsed components of the same name and you have to check through each until you find the one you want. I do have a "tag" string variable for each, but being able to just instantly eyeball the component label will be the best thing ever.
     
  28. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,768
    Not the ideal solution, but you can add text comment filed, just above each of your component, and describe there, what you need about specific components.
     
  29. toddwong

    toddwong

    Joined:
    Aug 29, 2017
    Posts:
    10
    If you have 2 box colliders and one script component on a gameobject, and you make 2 public field in you script component to reference the 2 colliders, it will be hard to distinguish which collider is which. The good thing to have a alias or subtitle of components is that when it is referenced, inspector can display this alias or subtile in the referencing field.

    Of course this is not crucial, it won't affect any runtime behavior anyway. But a very useful tip for human eyes and brains.
     
    SisusCo likes this.
  30. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,856
    I have had issues where I needed several colliders and triggers per object. As children you have to write scripts to pass the OnTrigger and OnCollision callback results. If one could query the Inspector order of components from top Transform[0] it may be a non-messy way to identify any component on the GO.
     
    MadeFromPolygons likes this.
  31. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,974
    Or a way to identify colliders and triggers by some sort of tag/key (independent of the built in tag system, something specific for colliders), as the use case you describe of a composite of colliders is really common but as of yet difficult to work with for reasons you describe
     
  32. SisusCo

    SisusCo

    Joined:
    Jan 29, 2019
    Posts:
    1,317
    DIY FTW
    renameable components.png
     
    angrypenguin likes this.
  33. SisusCo

    SisusCo

    Joined:
    Jan 29, 2019
    Posts:
    1,317
    Alrighty, renaming components in Unity is now a thing you can do, using my new asset Component Names.

    Component-Names.gif

    I hope some of you guys in here find this useful!
     
    Last edited: Feb 10, 2022
    toddwong, ippdev and stain2319 like this.