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.

Notifiche di Godot

Ogni oggetto in Godot implementa un metodo _notification. Il suo scopo è consentire all'oggetto di rispondere a una varietà di callback a livello di motore che potrebbero riguardarlo. Ad esempio, se il motore indica a un CanvasItem di "disegnare", chiamerà _notification(NOTIFICATION_DRAW).

Alcune di queste notifiche, come "draw", sono utili da sovrascrivere negli script. Tanto che Godot ne espone molte con funzioni dedicate:

  • _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

Ciò che gli utenti potrebbero non intuire è che le notifiche esistono anche per i tipi diversi da Node, ad esempio:

E inoltre molti dei callback che esistono nei nodi non hanno metodi dedicati, ma sono comunque molto utili.

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

Nota

Anche i metodi nella documentazione etichettati come "virtuali" sono concepiti per essere sovrascritti dagli script.

Un esempio classico è il metodo _init in Object. Sebbene non abbia una NOTIFICATION_* equivalente, il motore lo chiama comunque. La maggior parte dei linguaggi (tranne C#) lo usano come costruttore.

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 inizializzazione vs esportazione

Se lo script inizializza il proprio sotto-albero di nodi, senza una scena, il codice si dovrebbe eseguire in _init(). Anche altre inizializzazioni indipendenti dallo SceneTree o da proprietà si dovrebbero eseguire qui.

Nota

L'equivalente in C# al metodo _init() di GDScript è il costruttore.

_init() viene attivato prima di _enter_tree() o _ready(), ma dopo che uno script ha creato e inizializzato le sue proprietà. Quando si istanzia una scena, i valori delle proprietà vengono assegnati secondo la seguente sequenza:

  1. Assegnazione del valore iniziale: alla proprietà viene assegnato il suo valore di inizializzazione, oppure il suo valore predefinito se non ne è specificato uno. Se esiste un setter, non viene utilizzato.

  2. Assegnazione in _init(): il valore della proprietà viene sostituito da qualsiasi assegnazione effettuata in _init(), attivando il setter.

  3. Assegnazione del valore esportato: il valore di una proprietà esportata viene nuovamente sostituito da qualsiasi valore impostato nell'Ispettore, attivando il 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!".

Come risultato, l'istanziazione di uno script anziché di una scena può influire sia sull'inizializzazione, sia sul numero di volte in cui il motore chiama il setter.

_ready vs _enter_tree vs NOTIFICATION_PARENTED

Quando viene istanziata una scena connessa alla prima scena eseguita, Godot istanzia i nodi lungo l'albero (effettuando chiamate a _init()) e costruisce l'albero verso il basso, partendo dalla radice. Ciò assicura che le chiamate a _enter_tree() vengano eseguite a cascata lungo l'albero. Una volta completato l'albero, i nodi foglia chiamano _ready. Un nodo chiamerà questo metodo una volta che tutti i nodi figlio avranno finito di chiamare il proprio. Ciò provocherà quindi una cascata inversa che risale fino alla radice dell'albero.

Quando viene istanziato uno script o una scena autonoma, i nodi non vengono aggiunti allo SceneTree al momento della creazione, quindi non vengono attivati i callback _enter_tree(). Viene invece eseguita solo la chiamata a _init(). Quando la scena viene aggiunta allo SceneTree, vengono eseguite le chiamate _enter_tree() e _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!")