Please add a renamer feature to components!

I'd really like a feature to give nickname/short comments to things like collision boxes. I have many in my scene due to fighting game hitboxes and name wise, they are all identical.

EDIT: What I am meaning is a "tag" that helps with organization in the viewport. Like if one sprite has many things of the same (not scripts) like collision boxes. It would be nice to call it "Hitbox_01" or "Hurtbox_03" instead of "CollisionBox2D" and "CollisionBox2D". I don't care much for the names inside scripts. Just want it for the viewport.

 

If you're referencing scene view, you can add component with logic on those collision boxes of yours like so:

Code (CSharp):

1. [SerializeField]
2. private string _comment = "CommentText";
3.  
4. #if UNITY_EDITOR
5. private void OnDrawGizmos()
6. {
7.      UnityEditor.Handles.Label(transform.position, _comment);
8. }
9. #endif
10.  

 

...why don't you just name the gameobject? Or use the tag system?

 

There's also this:


Name the object accordingly, and select an icon, it will display a name in the scene view.

Yeah, I've completely overthinked this.

 

Well a component is just a monobehaviour script, which you can rename. As for naming the object, you can use an icon like @xVergilx mentions or use tag and gameobject name as @Murgilod mentions. This isnt a problem as much as it is a case of you not understanding how to use the hierarchy and inspector tools

 

As artist who has dealt with this issue, an inbuilt solution would be ideal. Something simple like f2 to rename component, lime anything else.

Color code tag is nice too.


In my case, it was long chains of triggers. We eventually made another trigger component with text and color display, but this is only like a folder divider, not the best solution.

Point is, I believe using trigger components is very common way to build things happening in game, no? Therefore user friendliness on the components we use to make triggers seems a good order.

 

Im confused, why couldnt you use the icon tag method shown above? That makes the object display with a text name in the scene, or is that not what your talking about?

edit: @BIGTIMEMASTER https://docs.unity3d.com/Manual/AssigningIcons.html

 

Not gameobjects, components on a single game object.

So you have empty game object in scene with a trigger collider. On it, you'll have.like twenty scripts:
On player enter,
On enemy enter,
Delay next trigger
Reward gold,
Damage player,
Etc etc

The issue is each of these script components has same generic monoscript behavior title. So if you essentially have a robust scripted event, it becomes tedious to edit them. Any workflow solution involves a programmer making tools, as far as I know. If unity allowed standard renaming, it would read clean like above.

 

Why not have one script with an array of named modules/behaviours?
I hate spamming MBs like this.

 

@SparrowsNest

I dunno I am artist. This is how tools were set up on a project before, and what I mentioned above is my idea on what I expect would solve problem and make engine more accessible to non-coders.

 

It is *a lot* more work to do it this way. To make process smooth, I think you need to also do a ton of editor scripting in order to set up all the parameters for a given sequence.

At a certain point it makes sense to make it more elaborate, and I think that @BIGTIMEMASTER's example might have hit that point late in production, but I donno man.

Setting up a modular trigger sequence so that level designer can create complex sequences without spending weeks on it, I tend to think monobehaviour spam is probably the best option.

A trigger sequence would be like:

On Player Enter
- Show Dialog (name)
- Add player gold (amount)
- Spawn enemy (unit type)
- Focus camera on enemy
- Delay (2 seconds)
- Focus camera back on player

How would you set up something like this without spending huge amounts of time in editor scripting without monobehaviour spam?

 

Adding on to what everyone else has said you can change the appearance of Unity's collision boxes too by writing a script that overrides the OnDrawGizmo() and OnDrawGizmoSelected() methods.

https://docs.unity3d.com/ScriptReference/Gizmos.html
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnDrawGizmos.html
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnDrawGizmosSelected.html

 

OnDrawGizmoSelected is awesome, it lets you do a ton of stuff without having to add separate editor components. Really really useful.

 

What might be really useful is a certain type of object that houses a string of scripts. Like a box that you can put scripts inside of and they run as normal, but difference is if you double click and open this special box, you get a node graph where you can easily view and rearrange your scripts.

Basically a node graph for scripts that can be contained as a single component. Would be easy mode for level designers but also aid programmers in allowing them to visually map out things as well.

Then if you can unique name each box you got powerful system for visual organization. A component named (enemy explodes on contact) and inside you got graph with supporting scripts in whatever order you need.

I believe the common ways programmer is organizing scripts is like this already. You have a manager script that many smaller scripts get referenced from. This is same idea, just condensed into a visual tool, and like OP is saying if you can unique name it that makes really.tidy and readable project.

 

What i meant was like, renaming this "Box Collider 2D". Cause i have a lot on my character and its hard to keep track.

 

Place them on a separate objects as a children. Name them however you like and add an icon to it.
You'll get a scene view gizmo with that name if you need one.

 

Unless something has changed, you would also have to add a script to make the child object detect the trigger event and then possibly send that to the parent. It is really not a great solution, more like a workaround as I see it. It works fine if you simply need multiple rigidbody colliders on a single object, as those colliders should work with the physics engine, but once you need code to directly respond, like with a fighting game where different things happen depending on the trigger that is hit, it isn't as shiny anymore.

 

There are a billion better ways to handle that than renaming components themselves, which would lead to just as many, if not more, tracking issues.

 

Try making a script inherting from the collider and add a string to it so you can name it.

Does that work? Never tried it but i'm planning on doing something like this only for rigidbodies.

 

I believe both Collider and Rigidbody are sealed, which means you can't inherit from them.

You could simply put an additional component next to the collider which has the name. Or as people have previously suggested, just name the GameObject the collider is on.

 

I agree with this.Which is the main reason for creating this.
I don't really want anything that affects code, just the name for it in the viewport (and in the dropdown for public variables) appear changed would be nice.

 

Its one script with two or three lines of code. Hardly a big deal.

 

So it isn't a big deal, and indeed it works pretty well...but the point is still valid. I think a simple way to label colliders would be nice, but doesn't have to be something complicated like the name itself, maybe some kind of optional label around it.

 

You already have layers, tags and names. How many more labels do you need?

 

To add to this: if this is a recurring issue for you and you implement your own solution, it's not like the code just magically breaks between projects. I have plenty of edge case issues I solve with my own solutions that I just integrate into new projects and that's exactly what this is.

 

I suppose it's here I mutter things about how visual scripting sorts out these issues for people who will not code.

 

This is necessary. The inspector is often used as a pseudo visual scripting interface (if the scripts and their properties are designed accordingly). Small modular scripts often end up with extremely diluted names, given that they can be used in a lot of different ways. Having the ability to write a note in the inspector of a script to help trace the particular context in which it is being used would be ideal.

 

I do like how UE4 has a good visual scripting language. I used it for 5 years!

 

@Billy4184 Like adding script with simply public text field? You can do it now and drag it on position you like in inspector of GameObject. Plus you can have multiple such attachments. And modify to your liking.

 

In this case, it seems like a very standard thing and making it part of the inspector system just makes sense to me. Almost everything is possible with hacking in different ways, but since Unity are in the business of designing interfaces for making games, I think it's worth adding this in there.

 

What about an editor script?

 

And you can always create an empty MonoBehaviour and treat it as if it were an identifier.

 

I think this thread has kinda shown it isn't a very standard thing and that it varies enough by use case that it's best to use a custom solution, similar to things like object pooling.

 

I would bet that most of the nos are from programmers. This issue doesn't really bother me personally, but it has occurred to me when designing my asset store kit in an ultra-modular way - for example I have a set of small, very flexible and modular scripts for building all sorts of tools and weapons, and this feature would help customers, especially beginners, organize them. I also can't think of a good reason why it wouldn't be useful, especially for people who heavily rely on the inspector.

Also, going by previous similar threads, there are those who seem to think that Unity are in the business of providing an empty visual studio project and perhaps a bit of encouragement when in fact everything they do is facilitating rather than enabling things to happen. If this seems like it would make things easier, it gets my vote.

 

Haaaaaaaaaave you met prefab names?

 

It's really all about making notes on a component imo. I imagine it would be most useful for adding lots of small components to one object and clarifying context. But making a note on a component, to me just seems useful for a lot of things. If you're operating in the editor and not the code, there's very limited options for making notes.

Like the tag system for example, it's not too hard to add yourself but would just make things easier if it was already there.

 

Scripting section of the forum, most people repling to posts here are programmers regardless.

 

More ways to organize the better. And less all the other people on team have to bug programmer to make a tool the more time everybody can spend thinking about game design.

Also, even if your organization is in code and your brain, is less mental taxation if you can offload some of it with big easy color coded and direct in editor solution.

Anything that decreases mental load you got to pack and unpack to get into your work, the better.

 

Im still confused as to why you cant just rename the script, which renames the component.....

There is literally no difference in the behaviour:

What you propose: select some sort of option "rename compoennt", type in name, apply name, component updates name

What currently happens: rename script, type in name, apply, component updates its name

The only difference is one adds yet another thing to the list of things to make for unity developers, when really this is what editor tooling exists for.

If renaming a script is too much work for you, make an editor extension to handle it. But seriously, this feature request would be adding bloat if I ever saw it.

 

Because that will rename it on every object, where one of the strengths of component oriented design is that you can reuse bits of code in different places. For instance, one AudioSource might play GUI effects while another plays an ambient music loop...

I think being able to optionally specify a name for a component would be handy... and I'm a programmer. The number of times I've had, say, 3 AudioSources on one GameObject and needed to check if a reference is pointing to the right one is significant enough that built-in support would be nice. I would use it rarely, but I would use it.

I also would like to see an out-of-the-box "Note" component that's automatically excluded from builds and such. Yeah, I could do it myself... and so could every asset author... so there's no way to standardise it. A benefit to having it first-party is that everyone could just write notes, and then Unity could do stuff like provide built-in search functionality that works for all projects and assets. Also, being first-party means that it could be more than just a text field. You could have nice-to-haves like formatting and linking and everyone gets it with only one person having had to do the busy-work involved.

 

Right I get you now, I agree that a note component would be useful.

We have an editor extension that actually overlays info like that in our inspectors, but it is cumbersome because everything has to have a custom inspector to use it. I agree having something in built would be a dream

 

I have a notes system on the store that's pretty much what you guys are saying here. I've been using it for a couple of years on all my projects.

https://assetstore.unity.com/packages/tools/gui/uninotes-112824

 

I was going to vote no, because I though you meant it should rewrite the script too to rename it, but if it's just a label, then I don't see why it shouldn't be allowed.

 

Because anyone working in a capacity for this to be meaningful can easily implement it themselves while for everyone else it would just add to "okay but what's a tag, what's a layer, and what's a name and why can I search for all these things?"

At a certain point, you are either adding more confusion to an already pretty daunting workflow for beginners while implementing a feature that any experienced developer will have no trouble implementing.

 

Not saying anything good or bad about this specific asset, however this TYPE of asset is exactly what I was going to suggest as a potential solution to the OP's issue. Probably not quite as nice as having it built into Unity simply because there is always a bit of friction when you add assets, but certainly well worth it for project organization. I am glad such assets are available.

There is also the catch I run into: I actually own a note taking asset from the Unity Asset Store. Since I do only small hobby projects as far as game development, I never remember to add that package to any of my projects until it is past the point where I would want to go back and 'refactor' everything to include it. I am, however, obsessively organized in general, so if this was built into Unity by default, I'd be using it on everything, the same way I do tags and layers and good naming conventions.

 

Chances are if it were added it would be in the package manager meaning you'd be back to square one.

 

You're right, renaming something is incredibly advanced. What a stretch.

 

Renaming of built in components will make reading other people's code a complete nightmare.

 

It's already been mentioned that it can be a label in parenthesis after the official name.

 

I think people are each talking about slightly different things here. Screenshots would help.