Up to date
This page is up to date for Godot 4.1
.
If you still find outdated information, please open an issue.
Godot notifications¶
Every Object in Godot implements a
_notification method. Its purpose is to
allow the Object to respond to a variety of engine-level callbacks that may
relate to it. For example, if the engine tells a
CanvasItem to "draw", it will call
_notification(NOTIFICATION_DRAW)
.
Some of these notifications, like draw, are useful to override in scripts. So much so that Godot exposes many of them with dedicated functions:
_ready()
:NOTIFICATION_READY
_enter_tree()
:NOTIFICATION_ENTER_TREE
_exit_tree()
:NOTIFICATION_EXIT_TREE
_process(delta)
:NOTIFICATION_PROCESS
_physics_process(delta)
:NOTIFICATION_PHYSICS_PROCESS
_draw()
:NOTIFICATION_DRAW
What users might not realize is that notifications exist for types other than Node alone, for example:
Object::NOTIFICATION_POSTINITIALIZE: a callback that triggers during object initialization. Not accessible to scripts.
Object::NOTIFICATION_PREDELETE: a callback that triggers before the engine deletes an Object, i.e. a "destructor".
And many of the callbacks that do exist in Nodes don't have any dedicated methods, but are still quite useful.
Node::NOTIFICATION_PARENTED: a callback that triggers anytime one adds a child node to another node.
Node::NOTIFICATION_UNPARENTED: a callback that triggers anytime one removes a child node from another node.
One can access all these custom notifications from the universal
_notification()
method.
Note
Methods in the documentation labeled as "virtual" are also intended to be overridden by scripts.
A classic example is the
_init method in Object. While it has no
NOTIFICATION_*
equivalent, the engine still calls the method. Most languages
(except C#) rely on it as a constructor.
So, in which situation should one use each of these notifications or virtual functions?
_process vs. _physics_process vs. *_input¶
Use _process()
when one needs a framerate-dependent delta time between
frames. If code that updates object data needs to update as often as
possible, this is the right place. Recurring logic checks and data caching
often execute here, but it comes down to the frequency at which one needs
the evaluations to update. If they don't need to execute every frame, then
implementing a Timer-timeout loop is another option.
# Allows for recurring operations that don't trigger script logic
# every frame (or even every fixed frame).
func _ready():
var timer = Timer.new()
timer.autostart = true
timer.wait_time = 0.5
add_child(timer)
timer.timeout.connect(func():
print("This block runs every 0.5 seconds")
)
Use _physics_process()
when one needs a framerate-independent delta time
between frames. If code needs consistent updates over time, regardless
of how fast or slow time advances, this is the right place.
Recurring kinematic and object transform operations should execute here.
While it is possible, to achieve the best performance, one should avoid
making input checks during these callbacks. _process()
and
_physics_process()
will trigger at every opportunity (they do not "rest" by
default). In contrast, *_input()
callbacks will trigger only on frames in
which the engine has actually detected the input.
One can check for input actions within the input callbacks just the same. If one wants to use delta time, one can fetch it from the related delta time methods as needed.
# Called every frame, even when the engine detects no input.
func _process(delta):
if Input.is_action_just_pressed("ui_select"):
print(delta)
# Called during every input event.
func _unhandled_input(event):
match event.get_class():
"InputEventKey":
if Input.is_action_just_pressed("ui_accept"):
print(get_process_delta_time())
using Godot;
public partial class MyNode : Node
{
// Called every frame, even when the engine detects no input.