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.

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 aparte de Node, por ejemplo:

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

El método universal _notification() proporciona acceso a todas estas notificaciones personalizadas.

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.

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

Si los scripts inicializan su propia sub estructura de árbol de nodos, sin una escena, el código debería ejecutarse en _init(). Otras propiedades del inicializaciones independientes del árbol de escenas deberán realizarse aquí también.

Nota

El equivalente en C# al método _init() de GDScript es el constructor.

_init() se dispara antes de _enter_tree() o _ready(). pero después de que un script crea e inicializa sus propiedades. Cuando se instancia una escena, los valores de las propiedades se asignarán de acuerdo a la siguiente secuencia:

  1. Valor de asignación inicial: la propiedad tendr{a asignado su valor de inicialización o su valor por defecto si no es especificado. Si existe un setter, este no será usado.

  2. _init() assignment: the property's value is replaced by any assignments made in _init(), triggering the setter.

  3. Asignación de valores eportados: un valor exportado de una propiedad es reemplazado de nuevo por el valor asignado en el Inspector, disparando el 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 you set test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".

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

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