Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When changing the type of a Node in the scene tree, change its name to the new type's default name if it currently possesses the old type's default name #7054

Closed
kolunmi opened this issue Jun 10, 2023 · 5 comments

Comments

@kolunmi
Copy link

kolunmi commented Jun 10, 2023

Describe the project you are working on

A game in godot

Describe the problem or limitation you are having in your project

Hello! Currently when changing a node's type, it always keeps its old name. This is more of an annoyance than a limitation. For example, a demonstration of the existing behavior:

Screenshot from 2023-06-09 21-25-11
Screenshot from 2023-06-09 21-25-39
Screenshot from 2023-06-09 21-25-59

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This feature would alter the name if the requirements are met.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

In psuedo-code:

fn _on_editor_request_change_node_type(Node node, Type type) {
   if (node.name == get_type(node).default_name) {
      node.name = type.default_name;
   }

   // change the type...
}

If this enhancement will not be used often, can it be worked around with a few lines of script?

no

Is there a reason why this should be core and not an add-on in the asset library?

I don't believe this could be addressed in an add-on. Thank you for reading!

@AThousandShips
Copy link
Member

My question is how relevant this is as the number of times you'd use the default names in actual projects should be rare, I'd actively recommend against using them and instead use descriptive names for most things (except for a few things like cameras, some navigation nodes, environments, and animation nodes), and then the likelihood you'll need to change type is also low, unless you make a mistake

Also how would this work with numbered nodes?

The complexity here would be relatively high, if we want to actually deal with more than just the literal name without any numbers or suffixes, so I feel it's a high bar to justify this functionality, especially when the only argument given is annoyance

@KoBeWi
Copy link
Member

KoBeWi commented Jun 10, 2023

You can rename the node to empty name, which will make it use default one automatically.

@kolunmi
Copy link
Author

kolunmi commented Jun 10, 2023

My question is how relevant this is as the number of times you'd use the default names in actual projects should be rare, I'd actively recommend against using them and instead use descriptive names for most things (except for a few things like cameras, some navigation nodes, environments, and animation nodes), and then the likelihood you'll need to change type is also low, unless you make a mistake

Hi! Forgive me, but I don't see how this is a valid argument against the tweak, if I'm understanding you correctly. Just because this feature "should" be encountered infrequently doesn't mean godot can't or shouldn't offer a polished experience.

Also how would this work with numbered nodes?

Think about it as though we are subtracting the old node and then adding one of the new type; the result would be the same. So if we have:

root
   Node2D
   Node2D2
   Control
   Control2

and want to change the node of index 3 to a Node2D, we would end up with:

root
   Node2D
   Node2D2
   Control
   Node2D3

The complexity here would be relatively high

Would it be? I'm not super familiar with godot's internals, but it seems we already have the ability to recognize when a name has a number suffix when adding new nodes.

I appreciate your response, @AThousandShips

@Calinou
Copy link
Member

Calinou commented Jun 10, 2023

@AThousandShips
Copy link
Member

AThousandShips commented Jun 10, 2023

I meant complexity in relation to usefulness or necessity, if it's just because you find it annoying the bar for how simple it has to be is pretty low, I couldn't see any other arguments than that from your proposal

But add your support to the proposal this is a duplicate of

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants