summaryrefslogtreecommitdiff
path: root/doc/classes/Node.xml
diff options
context:
space:
mode:
authorKelly Thomas <kelly.thomas@hotmail.com.au>2018-10-06 04:20:16 +0800
committerKelly Thomas <kelly.thomas@hotmail.com.au>2018-10-06 04:20:16 +0800
commitb1ab7b4acf9a1faa880588781c84f34d09dde859 (patch)
tree70312c497c16ef02ebd07b38a5109dba0b1bbe49 /doc/classes/Node.xml
parent8068d0217a5e74c25f83fe93fa6e077b8d0b3bf5 (diff)
[Docs] Fix some broken links
Diffstat (limited to 'doc/classes/Node.xml')
-rw-r--r--doc/classes/Node.xml2
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/classes/Node.xml b/doc/classes/Node.xml
index dc754b4628..a33ee5c363 100644
--- a/doc/classes/Node.xml
+++ b/doc/classes/Node.xml
@@ -12,7 +12,7 @@
[b]Processing:[/b] Nodes can override the "process" state, so that they receive a callback on each frame requesting them to process (do something). Normal processing (callback [method _process], toggled with [method set_process]) happens as fast as possible and is dependent on the frame rate, so the processing time [i]delta[/i] is passed as an argument. Physics processing (callback [method _physics_process], toggled with [method 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 [method _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 [method _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 [method set_owner]. This keeps track of who instanced what. This is mostly useful when writing editors and tools, though.
- Finally, when a node is freed with [method free] or [method queue_free], it will also free all its children.
+ Finally, when a node is freed with [method Object.free] or [method queue_free], it will also free all its children.
[b]Groups:[/b] 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 [method add_to_group], [method is_in_group] and [method 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].
[b]Networking with nodes:[/b] After connecting to a server (or making one, see [NetworkedMultiplayerENet]) it is possible to use the built-in RPC (remote procedure call) system to communicate over the network. By calling [method 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.
</description>