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.

Checking the stable version of the documentation...

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:

Object::NOTIFICATION_POSTINITIALIZE: Ein Callback, das während der Objektinitialisierung ausgelöst wird. Für Skripte nicht zugänglich.
Object::NOTIFICATION_PREDELETE: Ein Callback, das ausgelöst wird, bevor die Engine ein Objekt löscht, d.h. ein "Destruktor".

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

Node::NOTIFICATION_PARENTED: a callback that triggers anytime you add a child node to another node.
Node::NOTIFICATION_UNPARENTED: a callback that triggers anytime you remove a child node from another node.

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

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.

So, when should you use each of these notifications or virtual functions?

_process, _physics_process und *_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")
    )

using Godot;

public partial class MyNode : Node
{
    // Allows for recurring operations that don't trigger script logic
    // every frame (or even every fixed frame).
    public override void _Ready()
    {
        var timer = new Timer();
        timer.Autostart = true;
        timer.WaitTime = 0.5;
        AddChild(timer);
        timer.Timeout += () => GD.Print("This block runs every 0.5 seconds");
    }
}

using namespace godot;

class MyNode : public Node {
    GDCLASS(MyNode, Node)

public:
    // Allows for recurring operations that don't trigger script logic
    // every frame (or even every fixed frame).
    virtual void _ready() override {
        Timer *timer = memnew(Timer);
        timer->set_autostart(true);
        timer->set_wait_time(0.5);
        add_child(timer);
        timer->connect("timeout", callable_mp(this, &MyNode::run));
    }

    void run() {
        UtilityFunctions::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())

using Godot;

public partial class MyNode : Node
{

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

}

using namespace godot;

class MyNode : public Node {
    GDCLASS(MyNode, Node)

public:
    // Called every frame, even when the engine detects no input.
    virtual void _process(double p_delta) override {
        if (Input::get_singleton->is_action_just_pressed("ui_select")) {
            UtilityFunctions::print(p_delta);
        }
    }

    // Called during every input event. Equally true for _input().
    virtual void _unhandled_input(const Ref<InputEvent> &p_event) override {
        Ref<InputEventKey> key_event = event;
        if (key_event.is_valid() && Input::get_singleton->is_action_just_pressed("ui_accept")) {
            UtilityFunctions::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:

Initiale Wertzuweisung: Der Property wird ihr Initialisierungswert zugewiesen, oder ihr Defaultwert, wenn keiner angegeben ist. Wenn ein Setter vorhanden ist, wird er nicht verwendet.
_init() assignment: the property's value is replaced by any assignments made in _init(), triggering the setter.
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 you set test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".

using Godot;

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

    [Export]
    public string Test
    {
        get { return _test; }
        set { _test = $"{value}!"; }
    }

    public MyNode()
    {
        // Triggers the setter, changing _test's value from "one" to "two!".
        Test = "two";
    }

    // If you set Test to "three" in the Inspector, it would trigger
    // the setter, changing _test's value from "two!" to "three!".
}

using namespace godot;

class MyNode : public Node {
    GDCLASS(MyNode, Node)

    String test = "one";

protected:
    static void _bind_methods() {
        ClassDB::bind_method(D_METHOD("get_test"), &MyNode::get_test);
        ClassDB::bind_method(D_METHOD("set_test", "test"), &MyNode::set_test);
        ADD_PROPERTY(PropertyInfo(Variant::STRING, "test"), "set_test", "get_test");
    }

public:
    String get_test() { return test; }
    void set_test(String p_test) { test = p_test + "!"; }

    MyNode() {
        // Triggers the setter, changing _test's value from "one" to "two!".
        set_test("two");
    }

    // If you set test to "three" in 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.

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

using Godot;

public partial class MyNode : Node
{
    private Node _parentCache;

    public bool ConnectionCheck()
    {
        return _parentCache.HasUserSignal("InteractedWith");
    }

    public override void _Notification(int what)
    {
        switch ((long)what)
        {
            case NotificationParented:
                _parentCache = GetParent();
                if (ConnectionCheck())
                {
                    _parentCache.Connect("InteractedWith", Callable.From(OnParentInteractedWith));
                }
                break;
            case NotificationUnparented:
                if (ConnectionCheck())
                {
                    _parentCache.Disconnect("InteractedWith", Callable.From(OnParentInteractedWith));
                }
                break;
        }
    }

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

using namespace godot;

class MyNode : public Node {
    GDCLASS(MyNode, Node)

    Node *parent_cache = nullptr;

    void on_parent_interacted_with() {
        UtilityFunctions::print("I'm reacting to my parent's interaction!");
    }

public:
    void connection_check() {
        return parent_cache->has_user_signal("interacted_with");
    }

    void _notification(int p_what) {
        switch (p_what) {
            case NOTIFICATION_PARENTED:
                parent_cache = get_parent();
                if (connection_check()) {
                    parent_cache->connect("interacted_with", callable_mp(this, &MyNode::on_parent_interacted_with));
                }
                break;
            case NOTIFICATION_UNPARENTED:
                if (connection_check()) {
                    parent_cache->disconnect("interacted_with", callable_mp(this, &MyNode::on_parent_interacted_with));
                }
                break;
        }
    }
};