Because of this, some nodes cannot provide complete functionality unless complemented by other nodes attached to them. A classic example is the RigidBody3D node, which cannot function without being complemented by a CollisionShape3D that defines its physical shape.
Godot offers an alert system to notify you when a node depends on another to function properly. You’ve probably seen it many times: a yellow warning triangle that displays an explanation when you hover your mouse over it.
 |
| Warning message indicating a missing child node |
When developing scenes in Godot, they become nodes within others. If you take good design principles seriously and separate responsibilities, sooner or later, you’ll find yourself designing nodes that depend on other nodes for customization.
At that point, you might wonder if you, too, can emit alerts if one of your nodes lacks a complementary node. The answer is yes, you can, and I’m going to show you how.
For example, let’s assume we have a node named MovingAgent. Its implementation doesn’t matter, but for illustration, let’s suppose this node defines the movement characteristics (speed, acceleration, braking, etc.) of an agent. To define how we want the agent to move, we aim to implement nodes with different movement algorithms (e.g., straight line, zigzag, reverse). These nodes have diverse implementations but adhere to the ISteeringBehavior interface, offering a set of common methods that can be called from MovingAgent. Thus, the agent’s movement will depend on the ISteeringBehavior-compliant node attached to MovingAgent.
In this case, we’d want to alert the user of the MovingAgent node if it’s used without an ISteeringBehavior node attached to it.
To trigger this dependency alert, all base nodes in Godot provide the _GetConfigurationWarnings() method. To have our node issue warnings, we simply need to implement this method. For MovingAgent, this could look like the following implementation:
 |
| Implementation of _GetConfigurationWarnings() |
The method is expected to return an array with all detected error messages (line 148). If Godot detects that the method returns an empty array, it interprets that everything is correct and won’t display the warning icon.
As you can see, the first thing the method does is check whether the MovingAgent node has a child node implementing ISteeringBehavior (line 149). If no such child is found (line 154), an error message is generated (line 156).
There’s no reason to limit ourselves to checking for just one type of node. We can search for multiple nodes, check their configurations, and generate multiple error messages, as long as we store the generated error messages in an array to return as the method’s result.
In this example, I store the error messages in a list (line 152) and convert it into an array before the method ends (line 159).
_GetConfigurationWarnings() runs in the following situations:
- When a new script is attached to the node.
- When a scene containing the node is opened.
- When a property is changed in the node’s inspector.
- When the script attached to the node is updated.
- When a new node is attached to the one containing the script.
Therefore, you can expect the script to refresh the warning, displaying or removing the alert, in any of these scenarios.
And that’s it—there’s no more mystery to it... or maybe there is. Observant readers may have noticed that in line 150, I searched for a child node solely by type. Developers familiar with Unity are accustomed to searching for components by type because this engine provides a native method for it (GetComponent<>). However, Godot doesn’t offer a native method to search by type. The native FindChild implementations search for nodes by name, not by type. This was inconvenient for me because I wanted to attach nodes with different names (indicative of functionality) to MovingAgent, as long as they adhered to the ISteeringBehavior interface. So, lacking a native method, I implemented one via an extension method:
 |
| Extension method for searching child nodes by type |
The extension method iterates through all child nodes (line 20) and checks if they are of the type passed as a parameter (line 22).
If it locates a node of the desired type, it returns it and ends the method (line 24). Otherwise, it can continue searching recursively in the children’s children (line 28) if requested via parameters (line 26).
Thanks to this extension method, any instance of a Godot class inheriting from Node (is there any that doesn’t?) will offer the ability to search by type, as seen in line 150 of _GetConfigurationWarnings().
In your case, it might suffice to search child nodes by name. If not, the extension method solution for type-based searches might suit you better. This is the only complexity I see in this alert system, which is otherwise extremely easy to use.
 |
| Resulting alert from our implementation |
