Уведомления Godot¶

Каждый объект в Godot реализует метод _notification. Его цель - позволить объекту реагировать на различные обратные вызовы на уровне движка, которые могут иметь к нему отношение. Например, если движок сообщает CanvasItem "draw" (рисовать), он вызовет _notification(NOTIFICATION_DRAW).

Некоторые из этих уведомлений, например рисование (draw), полезно переопределить в скриптах. Настолько, что Godot предоставляет многим из них специальные функции:

_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

Пользователи могут не осознавать, что уведомления существуют не только для Node (узлов), но и для других типов:

Объект::NOTIFICATION_POSTINITIALIZE: обратный вызов, который срабатывает при инициализации объекта. Не доступно для скриптов.
Object::NOTIFICATION_PREDELETE: обратный вызов, который срабатывает до того, как движок удалит Объект, т.е. 'деструктор'.
MainLoop::NOTIFICATION_WM_MOUSE_ENTER: обратный вызов, который срабатывает, когда мышь входит в окно операционной системы, отображающее игровой контент.

И многие обратные вызовы, которые действительно существуют в Nodes (узлах), не имеют специальных методов, но по-прежнему весьма полезны.

Node::NOTIFICATION_PARENTED: обратный вызов, который срабатывает при добавлении дочернего узла к другому узлу.
Node::NOTIFICATION_UNPARENTED: обратный вызов, который срабатывает в любой момент, когда удаляется дочерний узел из другого узла.
Popup::NOTIFICATION_POST_POPUP: обратный вызов, который срабатывает после того, как узел Popup завершает любой метод popup*. Обратите внимание на отличие от его сигнала about_to_show, который срабатывает перед его появлением.

Доступ ко всем этим настраиваемым уведомлениям можно получить с помощью универсального метода _notification.

Примечание

Методы в документации, помеченные как "виртуальные" (virtual), также должны быть переопределены скриптами.

Классическим примером является метод _init в Object. Хотя у него нет эквивалента NOTIFICATION_*, движок по-прежнему вызывает метод. Большинство языков (кроме C#) полагаются на него, как на конструктор.

Так в какой же ситуации следует использовать каждое из этих уведомлений или виртуальные функции?

"_process" против "_physics_process" против "*_input"¶

Используйте _process, когда вам нужна разница между кадрами, зависящая от частоты кадров. Если код, обновляющий данные объекта, должен обновляться как можно чаще, это правильное место. Здесь часто выполняются повторяющиеся логические проверки и кэширование данных, но все сводится к частоте, с которой нужно обновлять оценки. Если им не нужно выполнять каждый кадр, то другой вариант - реализация цикла Timer-yield-timeout.

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

Используйте _physics_process, когда вам нужна разница во времени между кадрами, не зависящая от частоты кадров. Если код требует постоянных обновлений с течением времени, независимо от того, насколько быстро или медленно идёт время, это правильное место. Здесь должны выполняться повторяющиеся кинематические операции и операции преобразования объектов.

Хотя это возможно, для достижения наилучшей производительности следует избегать проверки ввода во время этих обратных вызовов. _process и _physics_process будут запускаться при каждой возможности (по умолчанию они "не отдыхают"»). Напротив, обратные вызовы *_input будут запускаться только в тех кадрах, в которых движок фактически обнаружил ввод.

Точно так же можно проверить действия ввода в обратных вызовах ввода. Если кто-то хочет использовать дельта-время, его можно при необходимости получить из связанных методов дельта-времени.

# 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 против initialization против export¶

Если скрипт инициализирует собственное поддерево узла без сцены, этот код должен выполняться здесь. Здесь также должны выполняться другие свойства или независимые от SceneTree инициализации. Это срабатывает до _ready или _enter_tree, но после того, как скрипт создаст и инициализирует свои свойства.

Скрипты имеют три типа присвоения свойств, которые могут происходить во время создания экземпляра:

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

При создании экземпляра сцены, значения свойств будут установлены в следующей последовательности:

Присвоение начального значения: при создании экземпляра будет назначено либо значение инициализации, либо значение присваивания инициализации. Инициализация присваивания имеет приоритет над инициализацией значений.
Присвоение экспортируемого значения: При создании экземпляра из сцены, а не из скрипта, Godot назначит экспортируемое значение для замены начального значения, определённого в сценарии.

В результате создание экземпляра сценария вместо сцены повлияет как на инициализацию, так и на количество вызовов установщика механизмом.

_ready против _enter_tree против NOTIFICATION_PARENTED¶

При создании экземпляра сцены, связанной с первой выполненной сценой, Godot будет создавать экземпляры узлов вниз по дереву (выполняя вызовы _init) и строить дерево, идущее вниз от корня. Это вызывает каскадирование вызовов _enter_tree по дереву. Когда дерево готово, листовые узлы вызывают _ready. Узел вызовет этот метод, как только все дочерние узлы закончат свои вызовы. Затем это вызывает обратный каскад, возвращающийся к корню дерева.

При создании скрипта или автономной сцены узлы не добавляются в SceneTree при создании, поэтому обратные вызовы _enter_tree не запускаются. Вместо этого выполняются только вызовы _init и последующие вызовы _ready.

Если нужно инициировать поведение, которое возникает в качестве родительских узлов для другого, независимо от того, происходит ли оно как часть основной / активной сцены или нет, можно использовать уведомление PARENTED. Например, вот фрагмент, который без сбоев соединяет метод узла с настраиваемым сигналом на родительском узле. Полезно для узлов, ориентированных на данные, которые можно создать во время выполнения.

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