Godot: Renaming a node should force the name

[SolarLune]

Hello. Currently, if you add a node of a given name to be a sibling of another node of the same name, it'll rename one of the nodes. Here's a basic example:

• Root
  
  
  
  • Player
  
  

Add another "Player" node:

• Root
  
  
  
  • Player
  
  
  • @ Player @ 2 (This one got renamed)
  
  

When this happens, the occupied name is occupied, and you can't rename any other node to that name without changing that Node's name first. However, I think that if you try to set a node's name to something and another node by that name exists, it should force the name you set and rename the other node, like so:

• Root
  
  
  
  • Player
  
  
  • @ Player @ 2
  
  

Set the second Player name to "Player", and then Godot will then silently do this:

• Root
  
  
  
  • @ Player @ 2 (or 3, or whatever)
  
  
  • Player
  
  

Basically, Blender-style renaming. This keeps you from having to rename the other node first before renaming your desired node to keep its desired name.

As a side-note, it doesn't really make sense for Godot to rename nodes using @ symbols when doing so in the editor just appends another number onto the end of the name.

[vnen]

The @ symbol is to guarantee the name is unique without having to check, since you can't add this character manually in a node name.

I'm against this because it creates unexpected behavior. Maybe in editor might be okay, because you can see the other node is renaming. But in the script this will make me wary of renaming nodes, because if I'm not sure the name is unique I may end up picking the wrong node in an unrelated piece of code.

[SolarLune]

The @ symbol is to guarantee the name is unique without having to check, since you can't add this character manually in a node name.

Oh, huh, interesting. Thanks. This opens up more problems, though, because it's never stated in the documentation that you can't use "@" in node names even though you can refer to nodes with "@" in their name. Also, I'm not sure why there's multiple @ signs instead of just one.

But in the script this will make me wary of renaming nodes, because if I'm not sure the name is unique I may end up picking the wrong node in an unrelated piece of code.

I don't quite understand this situation. I can't quite visualize a situation where you want to rename a node in one script, but want to select the other, non-renamed node in another. Can you elaborate or give an example?

The problem I have is that renaming will silently fail if there's another node with a given name that exists. I think the fact that the developer is manually renaming a node means it should have implicit precedence over another with the same name, and so should be renamed.

[vnen]

The problem I have is that renaming will silently fail if there's another node with a given name that exists.

I think this is a problem. I don't think that renaming the other node is a solution. In fact, even this behavior can bite you in the back because if there's some order change in some function calls you might get the wrong node by mistake.

There should just be some sort of warning that your node name is duplicated, not take an active action by changing something else.

Also, I don't really see the use for adding multiple nodes to the same tree level and use the same name. I find it problematic to rely on the node name in this situation.

[SolarLune]

In fact, even this behavior can bite you in the back because if there's some order change in some function calls you might get the wrong node by mistake.

I still don't understand how someone could "get the wrong node" when they explicitly set the name for one node to the desired name, and, consequently, change the name of the unwanted node. That seems like more of a design issue for their application if they "get the wrong node".

There should just be some sort of warning that your node name is duplicated, not take an active action by changing something else.

I suppose I can agree that silently changing another node's name to compensate isn't a great solution, but it seems better than the current one.

Also, I don't really see the use for adding multiple nodes to the same tree level and use the same name. I find it problematic to rely on the node name in this situation.

They shouldn't use the same name, of course. My current use case is moving a player from one "scene" (parent node) to another, which already contains a player object (which I'm queueing to be freed).

[akien-mga]

I'm also against this, renaming a node should never impact the name of another node. As mentioned by @vnen, this can lead to very tricky situations where you try to access the node with the old name and end up getting the new node, or vice versa, depending on what code gets executed at what time.

The editor does the same automatically when different scenes with the same name are instanced as siblings. As such, it's not a bug and should not be signaled by a warning.

On the other hand, we could expose a special set_name for scripting that would actually do the check and trigger and error if the name is already in use.

[reduz]

Agreed, its a bad idea. Would cause hard to debug scenarios.

On Feb 13, 2018 14:57, "Rémi Verschelde" [e-mail] wrote:

I'm also against this, renaming a node should never impact the name of
another node. As mentioned by @vnen https://github.com/vnen, this can
lead to very tricky situations where you try to access the node with the
old name and end up getting the new node, or vice versa, depending on what
code gets executed at what time.

The editor does the same automatically when different scenes with the same
name are instanced as siblings. As such, it's not a bug and should not be
signaled by a warning.

On the other hand, we could expose a special set_name for scripting that
would actually do the check and trigger and error if the name is already in
use.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/16355#issuecomment-365291373,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z27ro-Pvlkf_RORnxQQRBfqKO1JpKks5tUaLygaJpZM4R4OEd
.

[vnen]

IMO referring to a node by name is mostly for nodes added in the editor during development. Referring to the name of instanced nodes is not really that reliable (especially if you are adding and removing siblings).

For what I understand about the use case, it's easier to rename the old node, queue_free it, then add the new node with the same name that's now available. You could also store a reference to the name instead of hardcoding it so you can always have the correct name.