Up to date
This page is up to date for Godot 4.2
.
If you still find outdated information, please open an issue.
Notifications Godot¶
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)
.
Certaines de ces notifications, comme draw, sont utiles pour remplacer les scripts. A tel point que Godot expose beaucoup d'entre eux avec des fonctions dédiées :
_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 : un callback qui se déclenche pendant l'initialisation de l'objet. Non accessible aux scripts.
Object::NOTIFICATION_PREDELETE: a callback that triggers before the engine deletes an Object, i.e. a "destructor".
Et beaucoup de rappels qui existent dans les Nœuds n'ont pas de méthodes dédiées, mais sont quand même très utiles.
Node::NOTIFICATION_PARENTED : un callback qui déclenche chaque fois qu'un nœud enfant est ajouté à un autre nœud.
Node::NOTIFICATION_UNPARENTED : un callback qui déclenche chaque fois qu'un nœud enfant est supprimé d'un autre nœud.
One can access all these custom notifications from the universal
_notification()
method.
Note
Les méthodes de la documentation étiquetées comme "virtuelles" sont également destinées à être substituée par des 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.
Alors, dans quelle situation faut-il utiliser chacune de ces notifications ou fonctions virtuelles ?
_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")
)
using Godot;
public partial class MyNode : Node
{
// Allows for recurring operations that don't trigger script logic
// every frame (or even every fixed frame).
public override void _Ready()
{
var timer = new Timer();
timer.Autostart = true;
timer.WaitTime = 0.5;
AddChild(timer);
timer.Timeout += () => GD.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.
public void _Process(double delta)
{
if (Input.IsActionJustPressed("ui_select"))
GD.Print(delta);
}
// Called during every input event. Equally true for _input().
public void _UnhandledInput(InputEvent @event)
{
switch (@event)
{
case InputEventKey:
if (Input.IsActionJustPressed("ui_accept"))
GD.Print(GetProcessDeltaTime());
break;
}
}
}
_init vs. initialization vs. export¶
If the script initializes its own node subtree, without a scene,
that code should execute in _init()
. Other property or SceneTree-independent
initializations should also run here.
Note
The C# equivalent to GDScript's _init()
method is the constructor.
_init()
triggers before _enter_tree()
or _ready()
, but after a script
creates and initializes its properties. When instantiating a scene, property
values will set up according to the following sequence:
Initial value assignment: the property is assigned its initialization value, or its default value if one is not specified. If a setter exists, it is not used.
``_init()`` assignment: the property's value is replaced by any assignments made in
_init()
, triggering the setter.Exported value assignment: an exported property's value is again replaced by any value set in the Inspector, triggering the setter.
# test is initialized to "one", without triggering the setter.
@export var test: String = "one":
set(value):
test = value + "!"
func _init():
# Triggers the setter, changing test's value from "one" to "two!".
test = "two"
# If someone sets test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".
using Godot;
public partial class MyNode : Node
{
private string _test = "one";
[Export]
public string Test
{
get { return _test; }
set { _test = $"{value}!"; }
}
public MyNode()
{
// Triggers the setter, changing _test's value from "one" to "two!".
Test = "two";
}
// If someone sets Test to "three" in the Inspector, it would trigger
// the setter, changing _test's value from "two!" to "three!".
}
As a result, instantiating a script versus a scene may affect both the initialization and the number of times the engine calls the setter.
_ready vs. _enter_tree vs. NOTIFICATION_PARENTED¶
When instantiating a scene connected to the first executed scene, Godot will
instantiate nodes down the tree (making _init()
calls) and build the tree
going downwards from the root. This causes _enter_tree()
calls to cascade
down the tree. Once the tree is complete, leaf nodes call _ready
. A node
will call this method once all child nodes have finished calling theirs. This
then causes a reverse cascade going up back to the tree's root.
When instantiating a script or a standalone scene, nodes are not
added to the SceneTree upon creation, so no _enter_tree()
callbacks
trigger. Instead, only the _init()
call occurs. When the scene is added
to the SceneTree, the _enter_tree()
and _ready()
calls occur.
Si l'on a besoin de déclencher un comportement qui se produit lorsque un nœud devient parent d'un autre, qu'il se produise dans le cadre de la scène principale/active ou non, on peut utiliser la notification PARENTED. Par exemple, voici un extrait qui connecte la méthode d'un nœud à un signal personnalisé sur le nœud parent sans échouer. Utile sur les nœuds centrés sur les données que l'on peut créer lors de l'exécution.
extends Node
var parent_cache
func connection_check():
return parent_cache.has_user_signal("interacted_with")
func _notification(what):
match what:
NOTIFICATION_PARENTED:
parent_cache = get_parent()
if connection_check():
parent_cache.interacted_with.connect(_on_parent_interacted_with)
NOTIFICATION_UNPARENTED:
if connection_check():
parent_cache.interacted_with.disconnect(_on_parent_interacted_with)
func _on_parent_interacted_with():
print("I'm reacting to my parent's interaction!")
using Godot;
public partial class MyNode : Node
{
private Node _parentCache;
public void ConnectionCheck()
{
return _parentCache.HasUserSignal("InteractedWith");
}
public void _Notification(int what)
{
switch (what)
{
case NotificationParented:
_parentCache = GetParent();
if (ConnectionCheck())
{
_parentCache.Connect("InteractedWith", Callable.From(OnParentInteractedWith));
}
break;
case NotificationUnparented:
if (ConnectionCheck())
{
_parentCache.Disconnect("InteractedWith", Callable.From(OnParentInteractedWith));
}
break;
}
}
private void OnParentInteractedWith()
{
GD.Print("I'm reacting to my parent's interaction!");
}
}