Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Benachrichtigungen in Godot

Jedes Objekt in Godot implementiert eine Methode _notification. Ihr Zweck ist es, dem Objekt die Möglichkeit zu geben, auf eine Vielzahl von Callbacks auf Engine-Ebene zu reagieren, die sich auf das Objekt beziehen können. Wenn die Engine zum Beispiel einem CanvasItem sagt, dass es "zeichnen" soll, wird es _notification(NOTIFICATION_DRAW) aufrufen.

Einige dieser Benachrichtigungen, wie z.B. Zeichnen, sind nützlich um sie in Skripten zu überschreiben. Godot hat viele von ihnen mit speziellen Funktionen ausstattet:

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

Was die Benutzer vielleicht nicht wissen, ist, dass es auch Benachrichtigungen für andere Typen als nur für Node gibt, zum Beispiel:

Und viele der Callbacks, die in Nodes existieren, haben keine dedizierten Methoden, sind aber dennoch sehr nützlich.

Auf all diese benutzerdefinierten Benachrichtigungen kann man über die universelle Methode _notification() zugreifen.

Bemerkung

Methoden in der Dokumentation, die als "virtuell" gekennzeichnet sind, sollen auch von Skripten überschrieben werden.

Ein klassisches Beispiel ist die Methode _init in Object. Obwohl sie keine NOTIFICATION_*-Entsprechung hat, ruft die Engine die Methode trotzdem auf. Die meisten Sprachen (außer C#) verwenden sie als Konstruktor.

In welcher Situation sollte man also jede dieser Benachrichtigungen oder virtuellen Funktionen verwenden?

_process, _physics_process und *_input

Verwenden Sie _process(), wenn Sie eine von der Framerate abhängige Deltazeit zwischen den Frames benötigen. Wenn Code, der Objektdaten aktualisiert, so oft wie möglich aktualisiert werden muss, ist dies der richtige Ort. Wiederkehrende Logikprüfungen und Daten-Caching werden oft hier ausgeführt, aber es hängt davon ab, wie oft man die Auswertungen aktualisieren muss. Wenn sie nicht in jedem Frame ausgeführt werden müssen, bietet die Implementierung einer Timer-Timeout-Schleife eine weitere 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")
    )

Verwenden Sie _physics_process(), wenn Sie eine von der Framerate unabhängige Delta-Zeit zwischen den Frames benötigen. Wenn Ihr Code konsistente Aktualisierungen über die Zeit benötigt, unabhängig davon, wie schnell oder langsam die Zeit voranschreitet, ist dies der richtige Ort. Wiederkehrende kinematische und objekttransformierende Operationen sollten hier ausgeführt werden.

Dies ist zwar möglich, aber um die beste Performance zu erzielen, sollte man es vermeiden, während dieser Callbacks Eingabeprüfungen durchzuführen. _process() und _physics_process() werden bei jeder Gelegenheit ausgelöst (sie "ruhen" normalerweise nicht). Im Gegensatz dazu werden *_input()-Callbacks nur in Frames ausgelöst, in denen die Engine die Eingabe tatsächlich erkannt hat.

In den Eingabe-Callbacks kann man genauso nach Eingabeaktionen suchen. Wenn man die Deltazeit verwenden möchte, kann man sie bei Bedarf aus den entsprechenden Deltazeit-Methoden abrufen.

# 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. Initialisierung vs. Exportieren

Wenn das Skript seinen eigenen Node-Unterbaum initialisiert, ohne eine Szene, sollte dieser Code in _init() ausgeführt werden. Weitere Propertys oder SceneTree-unabhängige Initialisierungen sollten ebenfalls hier ausgeführt werden.

Bemerkung

Das C#-Äquivalent zu GDScript's _init() Methode ist der Konstruktor.

_init() wird vor _enter_tree() oder _ready() ausgeführt, aber nachdem ein Skript seine Propertys erzeugt und initialisiert hat. Wenn eine Szene instanziiert wird, werden die Property-Werte gemäß der folgenden Reihenfolge eingerichtet:

  1. Initiale Wertzuweisung: Der Property wird ihr Initialisierungswert zugewiesen, oder ihr Defaultwert, wenn keiner angegeben ist. Wenn ein Setter vorhanden ist, wird er nicht verwendet.

  2. ``_init()``-Zuweisung: Der Wert der Property wird durch jegliche Zuweisungen ersetzt, die in _init() gemacht wurden, wodurch der Setter ausgelöst wird.

  3. Exportierte Wertzuweisung: Der Wert einer exportierten Property wird wiederum durch einen im Inspektor festgelegten Wert ersetzt, wodurch der Setter ausgelöst wird.

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

Daher kann die Instanziierung eines Skripts im Vergleich zu einer Szene sowohl die Initialisierung als auch die Anzahl der Aufrufe des Setters durch die Engine beeinflussen.

_ready vs. _enter_tree vs. NOTIFICATION_PARENTED

Wenn Godot eine Szene instanziiert, die mit der ersten ausgeführten Szene verbunden ist, instanziiert es Nodes entlang des Baumes (durch _init()-Aufrufe) und baut den Baum von seiner Wurzel abwärts auf. Dies führt dazu, daß _enter_tree()-Aufrufe kaskadenartig den Baum hinunterlaufen. Sobald der Baum vollständig ist, rufen die Nodes der Blätter _ready auf. Ein Node ruft diese Methode auf, sobald alle untergeordneten Nodes ihre Aufrufe beendet haben. Dies führt dann zu einer umgekehrten Kaskade zurück zur Wurzel des Baumes.

Wenn ein Skript oder eine eigenständige Szene instanziiert wird, werden die Nodes bei der Erstellung nicht zum SceneTree hinzugefügt, so dass keine _enter_tree()-Callbacks ausgelöst werden. Stattdessen erfolgt nur der _init()-Aufruf. Wenn die Szene zum SceneTree hinzugefügt wird, erfolgen die _enter_tree() und _ready() Aufrufe.

Wenn man ein Verhalten auslösen muss, sobald ein Node Parent eines anderen wird, unabhängig davon, ob dies als Teil der Haupt-/aktiven Szene auftritt oder nicht, kann man die PARENTED-Benachrichtigung verwenden. Hier ist beispielsweise ein Snippet, das die Methode eines Nodes mit einem benutzerdefinierten Signal auf dem Parent-Node verbindet, ohne dass dies fehlschlägt. Nützlich für datenzentrierte Nodes, die man zur Laufzeit erstellen kann.

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