Remove (Clone) append to Instantiated Object names

Unity Engine
1

Currently, when you Instantiate and Object (Prefabs etc) into the scene you are given an object with (Clone) appended to its name. Why is this still the case? Is there any interest in dropping this or making it optional?

Currently, you can see if an Object is an instance by using .GetInstanceID() and checking if it is a negative number. This is a significantly better way of checking the status of the object as clone vs original and is done in a way that cant be broken by renaming.

As it stands some user code will do obj.name.Replace(“(Clone)”, “”) to remove this and clean up the hierarchy. The issue is that doing so creates inconsistency as it is now possible that only some objects have the suffix.

Overall it is just a hassle to work around and brings limited benefit to the UX of GameObjects; if anything I think its a sharp edge that many devs end up hitting. Ideally, if it were removed the experience would be more consistent as you wouldn’t have Unity silently changing object names.

2 Likes
2

I guess this is a feature request and not an help request, since you already provide the solution in the latter part of your post. Good luck anyhow!

1 Like
3

What I’ve posted with obj.name.Replace(“(Clone)”, “”) is a way to remove it from the name but the overhead of doing so is actually pretty significant, .name is a very slow call.

Is there a better board for feature requests?

4

Unity appending (Clone) to the instance name is definitely annoying, I agree. However, using Replace(“(Clone)”, “”) will result in the code doing far more work than is necessary (and will potentially mess up the original name if it just so happened to contain (Clone) already). Simply set the new object’s name to that of the original:

var clone  = Instantiate(source);
clone.name = source.name;
9 Likes
5

Y̶e̶a̶h̶ ̶b̶u̶t̶ ̶n̶o̶w̶ ̶y̶o̶u̶ ̶c̶a̶l̶l̶ ̶.̶n̶a̶m̶e̶ ̶g̶e̶t̶ ̶t̶w̶i̶c̶e̶ ̶a̶n̶d̶ ̶s̶e̶t̶ ̶o̶n̶c̶e̶ ̶r̶a̶t̶h̶e̶r̶ ̶t̶h̶a̶n̶ ̶j̶u̶s̶t̶ ̶o̶n̶c̶e̶ ̶e̶a̶c̶h̶ ̶s̶o̶ ̶i̶f̶ ̶y̶o̶u̶ ̶h̶a̶v̶e̶ ̶n̶a̶m̶i̶n̶g̶ ̶c̶o̶n̶v̶e̶n̶t̶i̶o̶n̶s̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶r̶e̶l̶y̶ ̶o̶n̶ ̶t̶h̶e̶n̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶s̶a̶v̶e̶ ̶t̶h̶e̶ ̶.̶n̶a̶m̶e̶ ̶g̶e̶t̶

I’m wrong here, it is actually better to do it that way

6

This seems like undocumented behavior that is liable to break with any new release of Unity. Regardless, the (clone) thing is more of an editor UI feature than a way to check if something is a clone in code. I don’t think that’s really a common use case anyway.

1 Like
7

I can’t recall ever needing any of this. If you instantiate from prefab, you already know any object in the scene isn’t the original prefab. Needing to remove “Clone” from the name sounds like obsessive compulsive behavior. My opinion.

1 Like
8

Yep. Even if you’re Instantiating an object that already exists in the scene (not something I’ve ever really done either), the best way to check if something is a clone or the original is to just keep a reference to the original around to compare an object with.

2 Likes
9

If you are only doing this so your subsequent GameObject.Find() calls succeed, your concern about .name being slow also applies there.

You can’t simultaneously assert that .name is a slow call and yet be using it in any way to later find the object!!

Just keep a reference to what you clone. It’s only professional.

10

clone.name = source.name; is the same amount of get/set calls as clone.name = clone.name.Replace(“(Clone)”, “”);, but the latter also has a Replace operation.

1 Like
11

You’re making assumptions about why I care about the name of the object, there is not one reference to GameObject.Find() in our code base

12

I’m actually talking about instantiating prefabs, not duplicating objects. (Clone) is added when instantiating prefab objects from disk into the scene, be it a character, environment piece, VFX etc.

13

The main use is that sometimes it’s simpler to have a one-off search of a simple hierarchy based on either a name or name fragment than it is to create a marker object for this one case

14

But the name is a string. I stand by my earlier comment that you should simply use a reference to the template GameObject as a simple no-frills, highly efficiency key for your object pools.

1 Like
15

This doesn’t make sense. Let me translate it for you.

“I am using strings from the GameObject name for Object Pooling so that I do not need to use strings to reference the correct pool.”

Strings is strings baby. Use them at your own peril when you could just keep a reference instead.

16

I thought I’d throw in a good case for why you’d want those “(Clone)” concatenations to be removed. You may want to display a string to the user: The name of the object that killed you (as seen in Rust), or an in-game inspector for a sandbox (our case). The (Clone)s kind of muddy that.

17

In production code you would NEVER want to tie user-presented data to internal Prefab or asset naming.

Sure, it’s great for gamejams and quick test standups, but beyond that it fails to scale.

For instance, what are you going to do to localize it to other languages?

What if your artist starts doing experiments and now your trees are called Tree001.WithBiggerBRANChES and now your user sees that?

Instead just make another “DescribeMe” script with a string field that is the .Description or .HumanReadableName

Anything else is just lazy and fails to scale.

4 Likes
18

Sure, but it is good enough for now, effectively deals with 90% of the cases, and works as a fallback if a properly assigned name isn’t available. Lazy is good; expand scope as needed. :slight_smile:

19

The auto suffix is really annoying and breaks my naming conventions,
they should add a Checkbox to “Project Settings” to disable this behaviour.

6 Likes