Project unique nodes?

[me2beats]

There is new feature - scene unique nodes.
You can make a node in the scene accessible by name.
This is handy but what about more global thing:
project unique nodes?

project.godot could store the data about these nodes.

Currently you can use singletons instead.
you can create a singleton with a var like my_global_node
then in the script of the "global" node you you type like

func _enter_tree():
    Global.my_global_node = self

but as you can see this is not so handy.

[Mickeon]

Seems like the "current" approach is completely fine. Tell me, how would you identify, even across multiple instances of the same exact scene, project-unique nodes?

You may also find that thinking with global Node references is prone to tie code like shoelaces and that becomes really tricky to manage as your project increases in scope.

[rainlizard]

Currently you can use singletons instead.

Yes, the closest I've come to implementing global node references is storing all nodes in a dictionary in a singleton. I just accept the fact that nodes with the same name will overwrite each other in the dictionary (it's fine if they overwrite each other - I only need to make sure my nodes have unique names if I actually want to reference them).

On your main scene root node:

func _enter_tree():
	Nodelist.start()

func _ready():
	Nodelist.done()

_enter_tree() occurs before _ready(), in which we use godot's node_added signal to get all node references before any nodes scripts are run.

Nodelist singleton looks like this:

extends Node
var list = {}

func start(): # Called by Main root scene
	get_tree().connect("node_added", self, "node_added")

func node_added(nodeID):
	if nodeID.owner != null:
		list['o'+nodeID.name] = nodeID

func done():
	get_tree().disconnect("node_added", self, "node_added")

I prefix all my node references with lowercase letter 'o' so that I know what they are and they don't conflict with any node's existing variables. But the prefix is up to you.

Then at the top of each node I write onready lines like so:

onready var oField = Nodelist.list["oField"]
onready var oGenerateTerrain = Nodelist.list["oGenerateTerrain"]
onready var oPlayer = Nodelist.list["oPlayer"]

So you might think this is no different to writing onready NodePaths, however there's some big advantages here:

• I write these lines almost instantly using my macros addon https://github.com/rainlizard/GDScriptMacros
• I don't need to write annoying NodePaths anymore or sure they're correct. That crap is tedious when the NodePaths get longer and longer in a complex project.
• When moving nodes around I don't need to rename the NodePaths to be correct. I know this is a feature of exporting NodePaths, but exporting NodePaths has other downsides.
• I can reference from inside dynamically instanced objects much easier, because the NodePath doesn't need to take into consideration its position in the node tree. For example: if you spawn a bunch of enemies as children of multiple different scenes, and the enemy wants to reference the player, the line doesn't need to look like $"../../blah" and $"../../../blah", the Nodelist line is going to look the same regardless of where in the tree the enemy is. Also dealing with "../../" is difficult too.

Tell me, how would you identify, even across multiple instances of the same exact scene, project-unique nodes?

If you're speaking of "multiple instances" then that should be considered outside the scope of this feature. I accept that there's no good way to uniquely track multiple copies. No, this is about having one individual node that does its own thing, no copies.
So perhaps my real issue is that Godot's singleton feature is not good at all. Maybe singletons shouldn't necessarily need to be autoloaded and nodes could be set as singletons.

You may also find that thinking with global Node references is prone to tie code like shoelaces and that becomes really tricky to manage as your project increases in scope.

GameMaker allows you to reference any object from any other object at all times, they have plenty more prominent games than Godot. This is due to little conveniences that GM provides that Godot doesn't. I don't like you guys trying to protect devs from themselves.

[fire-forge]

I don't see much of a difference between this and the AutoLoad (singleton) feature that we already have.

[dalexeev]

Scene unique nodes are associated with the owner property, that is, they have some locality and refer to instances of scenes.

Global names are hard to track down as they refer to the whole project (many individual scenes). It is not clear what to do with several different instances that have the same global name. And in general, global variables make code more difficult to understand, unpredictable, and prone to errors.

Global names have already been discussed several times:

#2812
#3056
dalexeev/godot-global-node-ids-plugin

See also singletons and the find_child and find_children methods.

[SilencedPerson]

I usually make a custom resource where I store the node references and preload it whenever I need it.
I do same with Signals.