Communication of nodes

godot 4.3

Hi,

here is the situation.

In my main scene I have scenes which create numbers (dynamically) and I need to display some of them in a sub window (still part of of the main scene). The sources are created as the game progresses, so this needs to be done by script.

Most of the solutions is clear to me but I do not know what the best way is to transport these information. I have some problems with using node paths and directly calling for the information but I also know signals exist and could be used.

Should I create a signal from each source to the display window? Or can I somehow find a way to call for this information every time I open the window (for example).

As a sub problem. I still struggle in creating node paths. If it is permanent, no problem but what if I only have the name of the node? Is there an elegant way to get from the exact name to a full node path?

Thx in advance for all the help.

One option is to get the main node and call a getter function, e.g.

@onready var main : MyMainClass = get_node("/root/Main")
...
var numbers = main.getNumbers()

I prefer to use the signal, if the numbers are changed for some reasons and geting an event about it.

About your sub problem, you can check all children to get your node, e.g.

func recursiveFindNodeByName(p_name):
	for child in get_children():
		if child.name == p_name:
			return child # Found...  
		if child.get_child_count() > 0:
			var subchild = recursiveFindNodeByName(p_name)
			if subchild != null:
				return subchild
	return null
3 Likes

For this I would use signals definitely. In combination with a SignalManager or SignalBus as some call it to maintain modularity. When your instantiated node generates a number (or changes the number) it can emit a signal, your main scene (or child of) can listen for that signal and update the sub view appropriately.

PS A SignalManager is an autoloaded global script that just contains signals, so you can always connect to them, whether or not the node that emits them exists or not.

2 Likes

Thanks for the replies. I get the ideas.
I’m still very inexperienced with godot and programming and some of the advanced concepts don’t yet “click” with me.

For more context. The status of the information and some interactions need to be dynamically updated. In a sense the sub window is like a remote where you can interact with the child nodes. For this I need to see the status of various variables (which is not so much a problem) but also trigger (correctly) buttons.

Can I do all this with signals instead of directly calling the functions inside the various child nodes?

Yes.

Initially they are set to some standard, so a score is set to 0, an animation is set to idle etc.

The ‘sub window’ or ‘remote control’ has a button pressed, which sends a signal like “open the door”.

The node that controls the doors, listens for the signal, and when it gets the signal it opens the door.

In this scenario the remote has the signal, and emits it when the buttons are pressed.


A node enters the tree, like a ‘magic portal’ that was not there before. You want your sub_window or remote to show a possible interaction based on that appearance, but only act when the ‘enter portal’ button is pressed. In this case the portal emits a signal saying “I am in the scene and can be controlled by the remote” and the remote listens for such signals, and on getting them shows the ‘enter the portal’ button.

When the button is pressed, the remote emits a signal saying "the enter portal button was pressed’. Your portal scene is listening for that signal and responds when it receives that signal.

I hope those two examples helped clarify about how you can use signals for these purposes.

You have number_scenes and a UI that displays them when they are available.
The number scene is the portal, when it enters the tree (instantiated in your game) it signals the UI that it exists and has a number to display.

The UI displays a slot to display this number and sets it to the default (your “I am here” signal can send that default or intial number).

When the number changes, the node that changes the number emits a ‘number changed’ signal, and the UI updates the display.

When the number generating scene goes away (queue freed or just no longer creating numbers) it emits a signal to the ui that the UI no longer needs to display the slot for that number.

Hope that helps. If you need further help with the signals please ask.

2 Likes

Hi, it is me again.

It still bothers me that there is no way (I know) to quickly find a node(path) based on knowing the name of a node. Given how node heavy Godot is, it seems silly to me that this is not part of the base package.

About Signals…

The return signal from the remote gives me trouble because once again I need to know who to connect to tell them that the remote button was pressed. Do I just connect to all sources and use conditions to actually cause the effect (button press) or is there a smoother way to trace back the signal and say connect to that node?

Thx again.

You can use find_node by name, but I would warn you that this is a heavy process and is usually, at least IMHO, a sign that your game structural design has deeper issues. I mean, why do you not know where a node is? It is either in your tree or you instantiated it. It is not like they pop out of anywhere randomly is it?

The return signal does not really have to work that way. For instance your emitter (the thing that appeared in the scene and wants to be on the remote) will send a reference to itself.

signal your_signal_name

your_signal_name.emit(self)

Your remote can just manage these node references and call functions on them directly. For instance, storing them in a dictionary.

var remote_references_dict: Dictionary = {
        button_reference: node_reference,
       # etc
}

I would suggest, rather than employing lots of find_node functions, that you perhaps address your game structural design.

PS I would also suggest to leave this topic now and future questions are reposted as new topics. You will be more likely to get other people inputting to new questions as they are unlikely to tag on the end of long closed ones.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.