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 les types autres que seulement Node :

Object::NOTIFICATION_POSTINITIALIZE : un callback qui se déclenche pendant l'initialisation de l'objet. Non accessible aux scripts.
Object::NOTIFICATION_PREDELETE : un callback qui se déclenche avant que le moteur ne supprime un Objet, c'est-à-dire un 'destructeur'.
MainLoop::NOTIFICATION_WM_MOUSE_ENTER : un callback qui se déclenche lorsque la souris entre dans la fenêtre du système d'exploitation qui affiche le contenu du jeu.

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.
Popup::NOTIFICATION_POST_POPUP : un callback qui se déclenche après qu'un nœud Popup ait complété une méthode popup*. Notez la différence par rapport à son signal about_to_show qui déclenche avant son apparition.

On peut accéder à toutes ces notifications personnalisées à partir de la méthode universelle _notification.

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.

Alors, dans quelle situation faut-il utiliser chacune de ces notifications ou fonctions virtuelles ?

_process vs. _physics_process vs. *_input¶

Utilisez _process lorsqu'on a besoin d'un temps delta dépendant du temps entre les images. Si le code qui met à jour les données objet doit être mis à jour aussi souvent que possible, c'est le bon endroit. Les vérifications logiques récurrentes et la mise en cache des données s'exécutent souvent ici, mais cela dépend de la fréquence à laquelle on a besoin de les mettre à jour. S'ils n'ont pas besoin d'exécuter à toutes les images, l'implémentation d'une boucle Timer-Yield-timeout est une autre option.

# Infinitely loop, but only execute whenever the Timer fires.
# Allows for recurring operations that don't trigger script logic
# every frame (or even every fixed frame).
while true:
    my_method()
    $Timer.start()
    yield($Timer, "timeout")

Utilisez _physics_process quand vous avez besoin d'un temps delta indépendant du temps entre les images. Si le code a besoin de mises à jour cohérentes au fil du temps, quelle que soit la vitesse ou la lenteur de l'avancement du temps, c'est le bon endroit. Les opérations récurrentes de cinématique et de transformation d'objets doivent être exécutées ici.

Bien que cela soit possible, pour d'obtenir les meilleures performances, il faut éviter d'effectuer des contrôles d'entrée pendant ces rappels. _process` et _physics_process se déclenchent à chaque occasion (ils ne se "reposent" pas par défaut). En revanche, les rappels *_input ne se déclenchent que sur les trames dans lesquelles le moteur a effectivement détecté l'entrée.

On peut tout de même vérifier les actions d'entrée dans les rappels d'entrée. Si l'on veut utiliser le temps delta, on peut le récupérer à partir des méthodes de temps delta correspondantes si nécessaire.

# 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())

public class MyNode : Node
{

    // Called every frame, even when the engine detects no input.
    public void _Process(float 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 keyEvent:
                if (Input.IsActionJustPressed("ui_accept"))
                    GD.Print(GetProcessDeltaTime());
                break;
            default:
                break;
        }
    }

}

_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 ici. D'autres propriétés ou initialisation indépendantes de l'arbre de SceneTree doivent également être exécutées ici. Cela se déclenche avant _ready ou _enter_tree, mais après qu'un script crée et initialise ses propriétés.

Les scripts ont trois types d'assignations de propriétés qui peuvent se produire pendant l'instanciation :

# "one" is an "initialized value". These DO NOT trigger the setter.
# If someone set the value as "two" from the Inspector, this would be an
# "exported value". These DO trigger the setter.
export(String) var test = "one" setget set_test

func _init():
    # "three" is an "init assignment value".
    # These DO NOT trigger the setter, but...
    test = "three"
    # These DO trigger the setter. Note the `self` prefix.
    self.test = "three"

func set_test(value):
    test = value
    print("Setting: ", test)

public class MyNode : Node
{
    private string _test = "one";

    // Changing the value from the inspector does trigger the setter in C#.
    [Export]
    public string Test
    {
        get { return _test; }
        set
        {
            _test = value;
            GD.Print("Setting: " + _test);
        }
    }

    public MyNode()
    {
        // Triggers the setter as well
        Test = "three";
    }
}

Lors de l'instanciation d'une scène, les valeurs des propriétés seront définies selon la séquence suivante :

Première assignation de valeur : l’instanciation assignera la valeur d’initialisation ou la valeur d'affectation init. Les affectations Init ont priorité sur les valeurs d’initialisation.
Assignation de valeur exportée : Si l'instanciation se fait à partir d'une scène plutôt que d'un script, Godot assignera la valeur exportée pour remplacer la valeur initiale définie dans le script.

Par conséquent, l'instanciation d'un script par rapport à une scène affectera à 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.

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.has_user_signal("interacted_with")

func _notification(what):
    match what:
        NOTIFICATION_PARENTED:
            parent_cache = get_parent()
            if connection_check():
                parent_cache.connect("interacted_with", self, "_on_parent_interacted_with")
        NOTIFICATION_UNPARENTED:
            if connection_check():
                parent_cache.disconnect("interacted_with", self, "_on_parent_interacted_with")

func _on_parent_interacted_with():
    print("I'm reacting to my parent's interaction!")

public class MyNode : Node
{
    public Node ParentCache = null;

    public void ConnectionCheck()
    {
        return ParentCache.HasUserSignal("InteractedWith");
    }

    public void _Notification(int what)
    {
        switch (what)
        {
            case NOTIFICATION_PARENTED:
                ParentCache = GetParent();
                if (ConnectionCheck())
                    ParentCache.Connect("InteractedWith", this, "OnParentInteractedWith");
                break;
            case NOTIFICATION_UNPARENTED:
                if (ConnectionCheck())
                    ParentCache.Disconnect("InteractedWith", this, "OnParentInteractedWith");
                break;
        }
    }

    public void OnParentInteractedWith()
    {
        GD.Print("I'm reacting to my parent's interaction!");
    }
}