Up to date
This page is up to date for Godot 4.2.
If you still find outdated information, please open an issue.
Node¶
Inherits: Object
Inherited By: AnimationMixer, AudioStreamPlayer, CanvasItem, CanvasLayer, EditorFileSystem, EditorPlugin, EditorResourcePreview, HTTPRequest, InstancePlaceholder, MissingNode, MultiplayerSpawner, MultiplayerSynchronizer, NavigationAgent2D, NavigationAgent3D, Node3D, ResourcePreloader, ShaderGlobalsOverride, SkeletonIK3D, Timer, Viewport, WorldEnvironment
Base class for all scene objects.
Description¶
Nodes are Godot's building blocks. They can be assigned as the child of another node, resulting in a tree arrangement. A given node can contain any number of nodes as children with the requirement that all siblings (direct children of a node) should have unique names.
A tree of nodes is called a scene. Scenes can be saved to the disk and then instantiated into other scenes. This allows for very high flexibility in the architecture and data model of Godot projects.
Scene tree: The SceneTree contains the active tree of nodes. When a node is added to the scene tree, it receives the NOTIFICATION_ENTER_TREE notification and its _enter_tree callback is triggered. Child nodes are always added after their parent node, i.e. the _enter_tree callback of a parent node will be triggered before its child's.
Once all nodes have been added in the scene tree, they receive the NOTIFICATION_READY notification and their respective _ready callbacks are triggered. For groups of nodes, the _ready callback is called in reverse order, starting with the children and moving up to the parent nodes.
This means that when adding a node to the scene tree, the following order will be used for the callbacks: _enter_tree of the parent, _enter_tree of the children, _ready of the children and finally _ready of the parent (recursively for the entire scene tree).
Processing: Nodes can override the "process" state, so that they receive a callback on each frame requesting them to process (do something). Normal processing (callback _process, toggled with set_process) happens as fast as possible and is dependent on the frame rate, so the processing time delta (in seconds) is passed as an argument. Physics processing (callback _physics_process, toggled with set_physics_process) happens a fixed number of times per second (60 by default) and is useful for code related to the physics engine.
Nodes can also process input events. When present, the _input function will be called for each input that the program receives. In many cases, this can be overkill (unless used for simple projects), and the _unhandled_input function might be preferred; it is called when the input event was not handled by anyone else (typically, GUI Control nodes), ensuring that the node only receives the events that were meant for it.
To keep track of the scene hierarchy (especially when instancing scenes into other scenes), an "owner" can be set for the node with the owner property. This keeps track of who instantiated what. This is mostly useful when writing editors and tools, though.
Finally, when a node is freed with Object.free or queue_free, it will also free all its children.
Groups: Nodes can be added to as many groups as you want to be easy to manage, you could create groups like "enemies" or "collectables" for example, depending on your game. See add_to_group, is_in_group and remove_from_group. You can then retrieve all nodes in these groups, iterate them and even call methods on groups via the methods on SceneTree.
Networking with nodes: After connecting to a server (or making one, see ENetMultiplayerPeer), it is possible to use the built-in RPC (remote procedure call) system to communicate over the network. By calling rpc with a method name, it will be called locally and in all connected peers (peers = clients and the server that accepts connections). To identify which node receives the RPC call, Godot will use its NodePath (make sure node names are the same on all peers). Also, take a look at the high-level networking tutorial and corresponding demos.
Note: The script property is part of the Object class, not Node. It isn't exposed like most properties but does have a setter and getter (set_script() and get_script()).
Tutorials¶
Properties¶
|
||
|
||
|
||
|
||
|
||
BitField<ProcessThreadMessages> |
||
|
Methods¶
void |
_enter_tree ( ) virtual |
void |
_exit_tree ( ) virtual |
_get_configuration_warnings ( ) virtual const |
|
void |
_input ( InputEvent event ) virtual |
void |
_physics_process ( float delta ) virtual |
void |
|
void |
_ready ( ) virtual |
void |
_shortcut_input ( InputEvent event ) virtual |
void |
_unhandled_input ( InputEvent event ) virtual |
void |
_unhandled_key_input ( InputEvent event ) virtual |
void |
add_child ( Node node, bool force_readable_name=false, InternalMode internal=0 ) |
void |
add_sibling ( Node sibling, bool force_readable_name=false ) |
void |
add_to_group ( StringName group, bool persistent=false ) |
call_deferred_thread_group ( StringName method, ... ) vararg |
|
call_thread_safe ( StringName method, ... ) vararg |
|
can_process ( ) const |
|
create_tween ( ) |
|
find_child ( String pattern, bool recursive=true, bool owned=true ) const |
|
find_children ( String pattern, String type="", bool recursive=true, bool owned=true ) const |
|
find_parent ( String pattern ) const |
|