Add scene-unique nodes to make accessing nodes from code more convenient

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Currently in Godot, finding specific nodes that have different accesses across the project is done the following way:

• Singletons: Put as autoload singletons in the project settings. They are easily accessible as get_node("/root/name") or as a global variable in GDScript.
• Unique Nodes: Put them in a group and access that group, while we could still add an extra setting so you can ensure its the only one in the group ever, its still an easy way to access these nodes.
• Any node in the tree: Accessed by path such as $SomeNode/ChildOfIt/IwantThisOne

This suffices for a lot of cases, but it often happens that developers want to access a specific node in the scene tree, but this node is situated behind layers of containers or other parent nodes, so typing the full path such as:

$VBoxContainer/HBoxContainer/VBoxContainer/Option1/Label1.text = " hello"

Can be very cumbersome and annoying, even with code completion.

What many users do to work around this is to put a unique name to it and use find_node with an autoload to find it:

@onready var label1 : Label = find_node("Label1")

But this is messy. If there are many nodes around, having to create local variables for each makes code difficult to read. Also the solution is just not obvious.

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

The way to solve this is by implementing Scene Unique Nodes.

These nodes would only exist once per scene and you will be able to access them by name by ensuring their name is unique.

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

The idea is like this:

RMB any node and set it as unique:

This node will be, thus, unique in this local scene. It does not mean that any other node can't be named the same, but it ensures that no unique nodes can't be named the same:

Then, accessing it from script would be simply, just type the name:

$@Label1.text = "Hello"
# Same as:
$VBoxContainer/HBoxContainer/Label1.text = "Hello"

And that's it.

So. some questions may arise such as:

Q: What is the difference with find? A: More strict and largely more performant, as access will be instant because this node is unique (no actual searching takes place). Simpler to type and to understand when reading the code.

Q: What if I want to make the parent unique but access a child node? A: $@Label1/Child.say_hello()

Q: What if I want to access it in a sub-scene? A: The idea is that here we want to satisfy the most common case which is searching within a scene, but you can work around this rather easily. If the scene in the example above was a subecene you could do:

$Path/To/SubScene1/@Label1.text = "Hello" # Still works 
# Instead of
$Path/To/SubScene1/VBoxContainer/HBoxContainer/Label1.text = "Hello"

But additionally, you can make the subscene also a scene unique node, so you can do:

$@SubScene1/@Label1.text = "Hello" # Still works 
# Instead of
$Path/To/SubScene1/VBoxContainer/HBoxContainer/Label1.text = "Hello"

Q: What about non GDScript languages? A: get_node (GetNode in C#) will work the same:

GetNode<Label>("@Label1").Text = "Hello";

Thanks @pycbouh and @groud for giving feedback on how to implement this to make this proposal more solid.

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

N/A

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

N/A

[h0lley]

@markdibarry @pchasco unless the node in question is major concept of that class that's being used across several of its methods, personally I consider it bad practice to declare a reference for it in that classes scope (but you do you, going into an argument about this would indeed be off-topic).

you are right though in pointing out that hardcoded paths are hard to maintain... which is why this proposal exists.

[dalexeev]

Your critique of the proposal is much clearer to me now.

Let me illustrate to make it even clearer. Right now you can track the instantiation of scenes using the owner property (but, in my understanding, the owner property is a technical detail, artifact that is unnecessary for ordinary users). In the picture, the gray arrows represent the ownership relationship. Red lines underline nodes that do not have an owner (these are root, autoloads, current scene and runtime nodes).

Theoretically, we can use the ownership relation for such addressing relative to scenes (rather than branches) and make it "logical" at runtime as well.

But this may cause users to ask "why can't I access the node I added at runtime using this syntax?". Or, for example, what should happen if you move/rename a unique node at runtime? Plus it requires marking unique nodes in the editor. Plus it's not exactly the same as owned nodes, but a slightly different thing, closely related to ownership (not all owned nodes are unique, but all unique nodes must be owned, otherwise it would be pointless).

If earlier you could not think about ownership and scenes in the tree, now this information becomes important for debugging and it would be nice to see it in the view of the remote scene tree (for example, to understand why you get null instead of a node in a particular case).

would be shooting yourself in the foot by using the wrong tool for the wrong job

A good tool should try to avoid the possibility of shooting yourself in the foot. I am not saying that this proposal is impossible, but it seems to me that it is not an unequivocal good, that there are certain problems and complications that alternative proposals do not have.

I feel like I've said all I can. So I will keep quiet until new arguments come up. I would be interested to know what @willnationsdev thinks about this proposal (sorry if I bothered you with a mention).

ADD. By "runtime nodes" I mean nodes added by code (using add_child, without setting the owner, which happens 99% of the time, unless we're talking about editor plugins and tools).

[Zireael07]

@dalexeev: Note that children added by code do not have owner set (but your trick does works for solely in-editor work)

[TheDuriel]

I don't support the original proposed solution, but there is a way I can at least bear it's existence:

Enforce uniqueness across the entire scene, always. Instead of needing to mark individual Nodes for having a unique name, simply demand that all nodes must have unique names at all times. (Within the context of the scene.)

That comment aside.:

$VBoxContainer/HBoxContainer/VBoxContainer/Option1/Label1.text = " hello"

This example also is, a little biased. In my own projects this looks like:

$"VBC1/HBC1/VBC1/Option1/Label1.text = " hello" Which is a little cleaner. I also create this path by drag and drop from the scene dock to the script editor, not by typing it out.

However, I would say that: We should encourage users to use export(NodePath) as an alternative of lengthy paths in all cases. NodePath exports convey all of the advantages a user looks for. Path independent, name independent, fast, reliable, less code bulk.

Refer to proposals (ideas) such as

https://github.com/godotengine/godot-proposals/issues/934 and my own idea for improved node exporting here https://github.com/godotengine/godot-proposals/issues/1048

[cybereality]

I don't support forcing unique names by default. As I've stated, I typically use generic names for nodes that are not important, and will never be accessed by code, such as "Shape" for a collision shape or "Sprite" for 2D graphics. I would prefer if I could set which nodes I am interested in, and leave the others alone to have any generic name (or the same name, if I want). However, I agree that enforcing unique names would be a better UX experience.

[TheDuriel]

I don't support forcing unique names by default. As I've stated, I typically use generic names for nodes that are not important, and will never be accessed by code, such as "Shape" for a collision shape or "Sprite" for 2D graphics. I would prefer if I could set which nodes I am interested in, and leave the others alone to have any generic name (or the same name, if I want). However, I agree that enforcing unique names would be a better UX experience.

Enforcing unique node names is as simple as starting node naming with Name>1< instead of Name>nothingatall<

So it would not drastically change how you interact or look at your Scene view. Shape would simply become Shape1.

My issue with needing to mark individual nodes is that; This is now another fiddly submenu you have to remember to use. For proper usability in complex scenes, we would also require another dock or tab in the scene dock, that allows us to see a list of all 'unique' nodes. Or yet another icon to pre/suffix our nodes with. We already have a lot of icons cluttering the dock. (Visibility, script, locked, children locked, grouped, signaled, etc.)

[cybereality]

That's a good point and I understand. The proposal definitely adds more buttons and menus. For example, you set the unique name, but you will also need a button to unset it, to rename it, potentially see some list of unique names, etc. If we just decided to enforce unique names on a per scene level, then all the UI would disappear. And the only addition would be the new at symbol in code, which is easy to understand and not really confusing.

[Mickeon]

I do not agree defaulting to enforcing unique names either. It seems to me that among the things that make a Node unique is the path towards it. $Parent/Child1 and $Parent/Child2 are not the same as $OtherParent/Child1 and $OtherParent/Child2 but chances are they're similar. Having the formers be called "Child3" and "Child4" because across the entire scene there can't be shared names is a bit too much.

[aaronfranke]

@h0lley @nonunknown For the discussion of having a performant alternative to $ or get_node, see this proposal #996

[h0lley]

I don't want to bother with setting up a header of node reference declaration in each of my classes. Why should I have to spend time pointing to a bunch of nodes saying that I want to have a handle on them, when every node already has a handle to begin with?

I also certainly do not want to use export(NodePath) as a general purpose solution to obtaining node references. In most cases, that would be adding options to the inspector that are not meant to be configured. makes no sense to me.

I'll keep using the sufficiently performant $MyNode within methods (including the process functions) - however I do recognize that this means I have to think about adjusting code everytime I amend the node hirarchy. this proposal would alleviate that pain. does someone have a better idea that does not involve adding properties to class scope for each node I want to access?

I still want the ability to export nodes (essentialy syntactic sugar for export(NodePath) + onready get_node_or_null()), but this proposal tackles a separate issue.

[cybereality]

@Mickeon I see your point, but I think making everything unique would promote more clear naming. As my example, I always use "Shape" for collision shapes. But forcing unique names would make me use "PlayerShape" or "RockShape". This is not much of an inconvenience and actually makes the code and tree more readable. I think using "Shape3" or "Shape4" would be worse, but I think having meaningful names like "ChairShape", for example, would be ideal. And this idea would require no changes to the UI and thus the path of least resistance, while still providing the same features that are trying to be solved.

[pchasco]

I don't want to bother with setting up a header of node reference declaration in each of my classes. Why should I have to spend time pointing to a bunch of nodes saying that I want to have a handle on them, when every node already has a handle to begin with?

A path to a node is not a "handle" (or reference). And you don't have to spend time doing this. You only need to do it if you want to reference nodes faster, and move them more conveniently.

I also certainly do not want to use export(NodePath) as a general purpose solution to obtaining node references.

The proposal is also not a general purpose solution to node references. The general purpose solutions already exist - use the node path via a literal or get_node(), or use a NodePath export. The proposal is for an additional, special-purpose solution for specific nodes which are important to your script code.

In most cases, that would be adding options to the inspector that are not meant to be configured. makes no sense to me.

The proposal includes adding additional options to the inspector that need to be configured. You will need to configure a node name, and ensure no other nodes in the scene share that name.

does someone have a better idea that does not involve adding properties to class scope for each node I want to access?

While I do see the convenience of this proposal, I argue that a new solution for this problem is unnecessary, and an additional solution adds more complexity to the editor and engine.

[markdibarry]

NodePath exports convey all of the advantages a user looks for. Path independent, name independent, fast, reliable, less code bulk.

I've mentioned this before, but those are all true except for reliable in my experience. Each time I've needed to make a change or fix a bug in the inherited script, the confused tscn files that use the script wouldn't honor any stored export values (rightfully so, since it can't guarantee their validity), and required 15+ minutes to go through every inherited scene in the game to reassign them. I can't imagine how long it'd take for a large project.

I rarely see any issues with tscn files that make them so corrupted they can't open. More common are ones where the tree order itself is confused (renaming a node in a base scene), but still fairly rare. But almost every other day, I run into a situation where a the export values or assigned resources have been cleared. With resources, you can save them so if the tscn gets confused, you don't lose your work (but you still need to reassign them), but there doesn't exist a backup for export values (nor do I think there should be).

A solution, if not this one, that is more stable than export values, and is less of a pain to update than get_node(), is definitely still desired on my end.

[dalexeev]

New argument: the same script can be attached to several different scenes. If the data about unique nodes is stored in the scene file and not in the script, then this can also be confusing. See #1935 (@willnationsdev, I mentioned you for a reason).

[h0lley]

@pchasco

A path to a node is not a "handle" (or reference).

performance difference between $NodePath and a straight reference is negligible in most all cases, so in that regard its perfectly fine to treat it as reference. it does have the disadvantage of potentially having to adjust multiple places in code when the node hierarchy is changed plus long paths make for poor readability, and so we are looking for a way to improve it.

You only need to do it if you want to reference nodes faster, and move them more conveniently.

this was meant to address people saying that the proposal isn't needed as one can just declare a bunch of references in onready.

The proposal is also not a general purpose solution to node references.

same thing, that was meant to address people that said this proposal isn't needed as one should export(NodePath) instead.

The proposal includes adding additional options to the inspector that need to be configured. You will need to configure a node name, and ensure no other nodes in the scene share that name.

it doesn't add it to the inspector (the panel where properties are being edited), but proposes a new option in the RMB context menu of the scene panel, which is less bloaty, but nonetheless I agree with the people sounding off discontent about that this potentially requiring lots of new UI. Imho, it would be best if it were to be solved as implicitly as possible. like, all nodes having unique identifiers by default or something (no, I am not saying I want to put hashes as identifiers in my code 😅).

[SilencedPerson]

I assumed that the unique shortcuts would work in scene branch only, but after re-reading the OP, that seems not to be the case. That seems horribly messy. So what is the final consensus. I am sorry for asking to be spoonfed this information, but the thread is kind of overwhelming.

[me2beats]

As far as I understand, node shortcuts inside nested scenes will not be visible? i.e

node.tscn:

Node
    Scene # this is a scene (scene.tscn)

scene.tscn:

Scene
    Shortcut

In this case

Node.get_node("Shortcut")

wouldn't work? in such a case, it would reduce the usability imo.

[h0lley]

@me2beats scenes are groups of nodes that make for a coherent concept by themselves, such as an entity in your game. usually the programmer makes an effort to build them as self-contained / modular as possible, i.e. to encapsulate them. with this in mind, there is very rarely if ever a need to obtain references to child nodes from outside the scene, and if there is, then the root node of the scene can serve those references rather than you having to call get_node() on it.

@SilencedPerson I'm pretty sure the shortcuts are meant to be on a per scene level, no? take this line from OP:

This node will be, thus, unique in this local scene.

[Hiiamwilliam]

I like this idea. I also share the feeling that creating a wall of onready var at the beginning of the script makes it unnecessarily busy, especially for User Interface. This proposal could make the scripts more clean and apparently at no performance decrease.

Since the important part is the actual name of the Node, maybe the menu could be more explicit and say Set name as unique. Hopefully we'll be able to select several Nodes and make their names unique (instead of individually making each Node unique).

However, I have a few questions. The proposal said that

It does not mean that any other node can't be named the same, but it ensures that no unique nodes can't be named the same

This means that I could add two Nodes, make one unique, then rename the non-unique Node to have the same name as the unique Node, yes? What happens then if I... "un-unique" the unique Node? Is it going to be a prohibited operation?

I feel like the answer is yes, but if I rename a Node with a unique name, will I have to rename all script references to that Node one by one? And lastly: is this for Godot 4 only?

[aXu-AP]

As a short-hand, I think renaming node to @node should make it unique (to be accessible without context menu).

This means that I could add two Nodes, make one unique, then rename the non-unique Node to have the same name as the unique Node, yes? What happens then if I... "un-unique" the unique Node? Is it going to be a prohibited operation?

Don't quote me on this, but I understood that previous rules would still apply, ie. there can't be siblings with same name, unique or not. Simply the scene can have nodes with same names (with the exception of having 2 similiar "unique" nodes).

[Hiiamwilliam]

@aXu-AP Oh. Yeah, that makes sense haha.

Even if the menu is a bit clunky, I think it's better than renaming because we can hopefully Shift select several Nodes and apply the 'Make unique' operation on all of them (if their names are already unique).

However, after making them unique, I agree it's a good visual clue to add the @ in their names in the Scene Tree.

[cybereality]

Yes, I think allowing typing @NodeName would be a good solution for programmers that don't want to use the menu (but we should still have the right-click menu for more designer oriented developers). That may be all that is needed visually, but a subtle color change could also be helpful.

[aXu-AP]

Yes I definitely agree that menu option should be there, I wasn't suggesting removing that. Having shorthand would simply be convinience, since you are likely to rename the important node anyway.

Having that @ visually there could make this function more accessible for people with colorblindness. Also, even if you use menu for adding @, you will get reminder of what symbol you need to access it (+discoverability if you are lazy to read docs).

[juniperfdel]

This behavior can already be done with an autoload script which takes advantage of get_tree().get_current_scene().find_node/get_node, but having a built-in solution which handles scene changes and node validation with visual cues would be helpful.

[h0lley]

@gregoryfdel I really wouldn't equate or even compare the proposed feature with a global scene tree search. a key aspect of it is that this is per (editor) scene and, well, does not need to do a search.

question: could references to nodes set as unique be implicitly obtained on ready and maintained under the hood (i.e. cached)? this way, $@Nodes would achieve identical performance to straight references without requiring any additional declarations.

[reduz]

I think there is some misunderstanding about the aim of this proposal to be honest.

Improving NodePath export IMO is a bit of a different use case and I can see some users being happier using find_node() so probably we should still add it back.

This proposal mainly aims as directly getting rid of having to use class members for accessing nodes, and to speed up this access so you can use it directly in the code. Using find_node() is really slow, but the @ syntax is extremely fast because its a pointer look up into a hashtable.

So instead of doing

onready var mylabel = find_node("SomeLabel")
..

func something():
   mylabel.set_text(somevalue)

You simply do:

func something():
  $@SomeLabel.set_text(somevalue)

In most cases doing UI, you will use a lot of controls few times, so saving the work of having to create a member variable and keeping track of it is a big time saver as you don't lose focus when you are writing the code that interacts with the control and just want to quickly get access to it.

[cybereality]

You're absolutely right, @reduz, and I think there is a lot of confusion in this thread. I was even against the idea at first, because I didn't fully understand it, but I read through things several times and I think it will be very helpful. The NodePath improvements and restoring find_node() might also be good ideas for another proposal. But I think on this topic is it well thought out and useful.

[Riteo]

@reduz oh I see, so the idea is to improve the experience of code only users? I think I'm starting to understand the reasoning behind this. Perhaps the UX is a little too clunky, or too unflexible, but that was already noted. Just to know, has some static optimization at bytecode compile time been considered, if even possible? I guess that if at most times find_node is done inside a field at ready, that it might be possible to create that hasmap "dynamically" at compile time. The $@ syntax might still be kept, perhaps either by alising to find_nodes[0] or non compiling when it's unable to determine the node position, to avoid running accidentally heavy code without noticing, if performance is such a priority behind the rationale of this proposal.

[h0lley]

@Riteo I don't think "code only users" is a helpful concept. everyone's using Godot's editor GUI.

rather, there's two different patterns of accessing nodes people got used to. let me quote myself from this other proposal:

it seems like there are two camps of us: those who like to declare a lot of node references as onready, and those of us who prefer skipping this and making use of $ instead. personally I belong to the second camp as I dislike having to add a property to class scope for every node I am going to use in code (or even two variables when the reference is derived from an exported NodePath). I am also quite fond of the green syntax highlighting communicating clearly that we are dealing with a node. but this shouldn't be about which one of these two patterns is superior, of course. let's support both, please.

people who are used to declaring an "onready header" of node references in each of their classes see little purpose in this proposal as they wouldn't really be using $ in their methods the first place. however for people who do prefer $ in methods over onready references, this proposal is much more attractive.

[pchasco]

people who are used to declaring an "onready header" of node references in each of their classes see little purpose in this proposal as they wouldn't really be using $ in their methods the first place. however for people who do prefer $ in methods over onready references, this proposal is much more attractive.

I agree that it is probably a net benefit to support both paradigms well. I will probably still be in the first camp, but that may change.

One thing that this does make me think about though, is what is even the utility every node instance having a name? The proposal is sorta just saying "yeah, but I REALLY want this one to have a name." If we only named nodes we cared to reference that way, and others remained anonymous, then this proposal might be moot. I understand that making names optional would most likely break NodePath, but it's just food for thought. HTML is structured as a tree in a similar way to a Godot scene and optional id has been the implementation since the beginning*.

* I actually don't know when the id attribute was introduced, but it's been around for as long as I can remember

[h0lley]

@pchasco you are saying that just as well, all nodes could be unnamed (anonymous) by default (only appear by the name of their class in the scene tree panel), and then we exclusively set names (IDs) for the nodes we want to reference in code. so merely the act of setting a custom name for a node would register them as "scene-unique node" rather than having to do so through an additional context menu option or similar. the complexity of $@NodePath may then not longer be needed either as it could simply be $NodeName (like a #my-id selector in CSS). ultimately that may even render NodePath pretty much obsolete, or at least reduce its application.

did I get that right? if so then I agree; interesting food for thought. beside this being quite the paradigm shift, one more counter-argument comes to mind: there's still some usability in naming nodes you don't necessarily want to use in code so you have an easier time navigating & making sense of your scene, or describing it to others.

[cybereality]

Yes, I have coded a lot of HTML and CSS and many nodes are fine as being anonymous. The difference is that most web developers write only code and do not use an app or visual interface. In the case of Godot, the editor is quite important. So seeing the name of a node, even if it is never referenced in code, is useful just for your own mental organization and finding which thing you want to click on.

[pchasco]

did I get that right? if so then I agree; interesting food for thought. beside this being quite the paradigm shift, one more counter-argument comes to mind: there's still some usability in naming nodes you don't necessarily want to use in code so you have an easier time navigating & making sense of your scene, or describing it to others.

Yes, you have it right. Finding items in the GUI without identifiers is a solved problem; Just open up developer tools in your web browser of choice. Clicking a tag highlights an element, clicking an element highlights a tag.

[Riteo]

@h0lley I didn't actually mean that it only helps people who edit the actual text files. I see two common approaches: accessing the node with find_node, which is done entirely from code, and accessing it from a NodePath, which has to be reassigned each time from the editor. I don't necessarily find the code only approach the best, but just because my approaches aren't the same of somebody else it doesn't mean that we shouldn't improve them. The idea of greatly changing the paradigm of Godot's node system is interesting and surely great food for thought, but go outside of this proposal's scope, and should be looked separately IMO, even in the hypotetical case of this proposal being "less ideal". We must also consider that we're almost near beta and so we should be relatively quick at fixing major usability problems for as many use-cases as reasonably possible.

[dpalais]

It's been said before but I want to add that exporting nodes makes sense if the engine handles it automatically. The script is aware of the Node type only, the editor inspector is aware of the NodePath only and the editor saves the resource data as a NodePath as well. In runtime the engine takes care of reading the NodePath and assigning the actual object in that path to the script variable before _ready is called.

[reduz]

@dpalais @jordo There are two choices on how exporting nodes can work and this entirely depends on the approach we want to take:

• Approach 1: Handle this internally in GDScript, export the property as a NodePath, and during _ready fetch it and converting to a node. This is relatively easy to add, but it only will work on GDScript.
• Approach 2: Handle this as a property hint for an object type. This is much more involved to do because there really is no proper place to run this logic of converting to a node when entering the scene. GDScript can simply add code transparently to the internal ready function, but the Godot object system can't.

If you are happy with the first approach, this is an easy addition, but it will not work for C#, C++ or anything else. Maybe C# can implement it on its own separately by trapping the _ready function, but I don't maintain it so I don't know.The second approach is very difficult and will require a lot of thinking, and it may not be worth it.

[jordo]

I'm still of the opinion that master should accept https://github.com/godotengine/godot/issues/58412 (especially now that master always does a FULL & complete breadth first search to implement find_nodes). And I still believe the introduction of this specific proposal will create more confusion (more ways to do the same thing), and introduce more tech-debt and additional implementation complexity than necessary. The storage location of the @syntax runtime's LUTs and rules as to which table and where to do the lookup in are imo going to introduce on-off bugs and future problems. WRT a lot of developer comments in this thread, a reference / variable (script class-member or stack) will always be faster as it's not a runtime lookup. @ syntax will incur the cost of a hash lookup which will probably get abused as being free, which is not the case.

@reduz For the Approach 1 you mentioned above, this is already achievable with the one-liner gdscript onready var + get_node + explicit object type cast. Approach 1 would just be syntactic sugar for gdscript.

• there really is no proper place to run this logic of converting to a node when entering the scene.

Approach 2 is doable with serializing the property to a backing tuple<NodePath, ObjectTypeCast>. Just implement runtime support for get_node_or_null and casting to the object type for these property types in a pre _ready hook on scene enter.

[reduz]

@jordo I know it sounds simple in theory, but it requires a bit more hacking all over the place imo and I would prefer an approach that is the least invasive as possible.

[cybereality]

This is a support important feature. If the solution is GDScript only, and that will be easier, that seems like a good plan. We can always look into refactoring and adding support for other languages later if people request it. But usually the simpler solution is always the better one.

[dpalais]

@reduz I use C# heavily and hope Godot C# scripts will someday reach the ease of use of exposing non-resources as Unity and Flax engine already do. Right now I do this to keep it simple if the node isn't performance critical:

[Export] public NodePath MyNodePath { get; set }
public Node MyNode { get => GetNode<Node>(MyNodePath); }

To be honest it isn't that much of a problem but a quality of life improvement would be welcome. Maybe the mono module could implement a similar feature with a special attribute like [ExportNode]?

[djmaesen]

im just commenting to give this a thumbs up. i really want to acces nodes without assigning nodepaths first

[akien-mga]

Implemented by https://github.com/godotengine/godot/pull/60298.

[MaaaxiKing]

This is great in total, but what about a separate method get_unique_node(name: String), so that “%” were allowed in Node names? Furthermore, get_node with “%” in the argument could occasionally confuse new users because the Node name does not include it.