Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Notifications Godot

Chaque objet dans Godot implémente une méthode _notification. Son but est de permettre à l'objet de répondre à une variété de rappels au niveau moteur qui peuvent s'y rapporter. Par exemple, si le moteur indique à un CanvasItem de "draw", il appellera _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

Ce que les utilisateurs peuvent ne pas comprendre, c'est que les notifications existent pour des types autres que seulement Node, par exemple :

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.

The universal _notification() method provides access to all these custom notifications.

Note

Les méthodes de la documentation étiquetées comme "virtuelles" sont également destinées à être substituée par des scripts.

Un exemple classique est la méthode _init dans Object. Bien qu'il n'ait pas d'équivalent NOTIFICATION_*, le moteur appelle toujours la méthode. La plupart des langages (à l'exception du C#) s'en servent comme constructeur.

So, when should you use each of these notifications or virtual functions?

_process vs. _physics_process vs. *_input

Use _process() when you need 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 how often the evaluations need 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 you need 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, you 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.

You can check for input actions within the input callbacks just the same. If you want to use delta time, you 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())

_init vs. initialization vs. export

Si le script initialise son propre sous-arbre de nœuds, sans scène, ce code devrait s'exécuter dans _init(). D'autres propriétés ou initialisation indépendantes de l'arbre de SceneTree devraient également être exécutées ici.

Note

L'équivalent C# au _init() de GDScript est le constructeur.

_init() se déclenche avant _enter_tree() ou ready(), mais après qu'un script crée et initialise ses proprietés. Lors de l'instanciation d'une scène, les valeurs des propriétés seront définies selon la séquence suivante :

  1. Assignation initiale de valeur : la propriété est attribuée à la valeur d'initialisation ou la valeur par défaut si aucune n'est spécifiée. Si un setter existe, il n'est pas utilisé.

  2. Affectation _init() : la valeur de la propriété est remplacée par n'importe quel affectation faite dans _init(), déclenchant le setter.

  3. Affectation de valeur exporté: une valeur de propriété exporté est de nouveau remplacé par n'importe quel valeur définie dans l'Inspecteur, déclenchant le donneur.

# 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 you set test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".

Par conséquent, l'instanciation d'un script par rapport à une scène peut affecter à la fois l'initialisation et le nombre de fois que le moteur appelle le setter.

_ready vs. _enter_tree vs. NOTIFICATION_PARENTED

Lors de l'instanciation d'une scène connectée à la première scène exécutée, Godot instancie les nœuds en bas de l'arbre (en faisant des appels _init()) et construit l'arbre en partant de la racine. Ceci provoque la cascade des appels _enter_tree() vers le bas de l'arbre. Une fois l'arbre terminé, les nœuds feuilles appellent _ready. Un nœud appellera cette méthode une fois que tous les nœuds enfants auront fini d'appeler les leurs. Ceci provoque alors une cascade inverse remontant jusqu'à la racine de l'arbre.

Lors de l'instanciation d'un script ou d'une scène autonome, les nœuds ne sont pas ajoutés au SceneTree lors de la création, donc aucun callback _enter_tree ne se déclenche. A la place, seul l'appel _init() se produit. Lorsque la scène est ajoutée au SceneTree, les appels _enter_tree() et _ready() se produisent.

If you need to trigger behavior that occurs as nodes parent to another, regardless of whether it occurs as part of the main/active scene or not, you can use the PARENTED notification. For example, here is a snippet that connects a node's method to a custom signal on the parent node without failing. Useful on data-centric nodes potentially created at runtime.

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!")