Notificaciones en Godot¶

Cada Object en Godot implementa un método _notification. Su propósito es permitir que Object responda a una variedad de callbacks a nivel de motor que puedan estar relacionados. Por ejemplo, si el motor le debe decir a un CanvasItem que tiene que "dibujar", este llamará a _notification(NOTIFICATION_DRAW).

Algunas de estas notificaciones, como draw, son útiles para anular en scripts. Incluso Godot expone muchos de estos con funciones dedicadas:

_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

Lo que los usuarios pueden no entender es que las notificaciones existen para otros tipos distintos a Node únicamente:

Object::NOTIFICATION_POSTINITIALIZE: un callback que se disparará durante la inicialización, no es accesible a scripts.
Object::NOTIFICATION_PREDELETE: un callback que se dispara antes de que el motor borre un Object, como el caso de un 'destructor'.
MainLoop::NOTIFICATION_WM_MOUSE_ENTER: un callback que se dispara cuando el ratón entra en la ventana que muestra el contenido del juego en el sistema operativo.

Y muchos de los callbacks que existen en Nodes no tienen ningún método dedicado, pero son igualmente útiles.

Node::NOTIFICATION_PARENTED: un callback que se dispara en el momento en que se agrega un hijo a un nodo.
Node::NOTIFICATION_UNPARENTED: un callback que se dispara cuando se remueve un hijo de un nodo.
Popup::NOTIFICATION_POST_POPUP: un callback que se dispara después de que un nodo Popup completa cualquier método popup*. Este es diferente de la señal about_to_show que se emite antes de su aparición.

Se puede acceder a todas estas notificaciones personalizadas desde el método universal _notification.

Nota

Los métodos en la documentación etiquetados como "virtuales" también están destinados a ser sobrescritos por scripts.

Un ejemplo clásico es el método _init en Object. Este no posee un equivalente NOTIFICATION_*, pero el motor llamará igual al método. La mayoría de los lenguajes (excepto C#) dependen de este como constructor.

Entonces, en qué situaciones se deben usar cada una de esas notificaciones o funciones virtuales?

_process vs. _physics_process vs. *_input¶

Utiliza _process cuando necesitas un delta tiempo dependiente del framerate entre cada frame. Si el código que actualiza los datos de un objeto necesita actualizarlo todas las veces que sea posible, este es el lugar ideal. Lógica recurrente que revisa y cachea datos a menudo se suele ejecutar aquí, pero depende de la velocidad en que se necesitan actualizar cosas, si no se necesita ejecutar en cada frame, se puede implementar un bucle Timer-yield-timeout como otra opción.

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

Utiliza _physics_process cuando necesites un tiempo delta independiente de la velocidad de cuadros entre fotogramas. Si el código necesita actualizaciones constantes a lo largo del tiempo, independientemente de lo rápido o lento que avance el tiempo, este es el lugar indicado. Las operaciones cinemáticas recurrentes y de transformación de objetos deben ejecutarse aquí.

Mientras sea posible, para obtener el mejor desempeño, se debe evitar realizar chequeos de entrada durante callbacks. _process y _physics_process se dispararán en cada oportunidad (no "duermen" por defecto). En contraste, el callback *_input disparará sólamente en los frames que el motor ha detectado realmente una entrada.

Se pueden revisar igualmente acciones de entrada dentro de los callback input. Si se quiere usar el delta tiempo, se puede tomar de los métodos relacionados al delta tiempo.

# 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 versus inicialización versus export¶

Si los scripts inicializan su propia sub estructura de árbol de nodos, sin una escena, el código se ejecutará aquí. Otras propiedades del inicializaciones independientes del árbol de escenas deberán realizarse aquí también. Esto sucede antes de _ready o _enter_tree, pero después de que el script crea e inicializa sus propiedades.

Los scripts tienen tres tipos de asignación de propiedades que pueden suceder durante la instanciación:

# "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";
    }
}

Cuando se instancia una escena, los valores de las propiedades se asignarán de acuerdo a la siguiente secuencia:

Valor de asignación inicial: la instanciación asignará el valor de inicialización o el valor inicial asignado. Las asignaciones iniciales tienen prioridad por sobre los valores de inicialización.
Valores de asignación exportados: Si se instancia desde una escena en lugar de por script, Godot asignará el valor exportado para reemplazar el valor inicial definido en el script.

Como resultado, instanciar un script versus una escena afectará tanto a la inicialización como el número de veces que el motor llamará al setter.

_ready vs. _enter_tree vs. NOTIFICATION_PARENTED¶

Cuando se instancia una escena conectada a la primer escena ejecutada, Godot instanciará nodos en el árbol (haciendo llamadas a _init) y construirá el árbol hacia abajo desde la raíz. Esto causa llamadas _enter_tree en cascada hacia abajo. Una vez que el árbol esté completo, los nodos hoja llaman a _ready. Un nodo llamará a este método una vez que todos los nodos hijos han finalizado su ejecución. Esto causa una cascada en reversa, hacia arriba hasta la raíz del árbol.

Cuando se instancia un script o una escena independiente, los nodos no son agregados al Árbol de Escenas en su creación, por lo que no se activan los callbacks _enter_tree. En cambio, sólo se produce la llamada _init. Cuando la escena se agrega al Árbol de Escenas, ocurren las llamadas _enter_tree y luego _ready.

Si se necesita disparar un comportamiento que suceda cuando los nodos son asignados como hijos a otros, sin importar si ocurre como parte de una escena principal o activa, se puede utilizar la notificación PARENTED. Por ejemplo, aquí hay un fragmento de código que conecta un método de una señal personalizada al nodo padre sin fallar. Esto es útil en nodos centrados en datos que se pueden querer crear en tiempo de ejecución.

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