Up to date

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

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

Every Object in Godot implements a _notification method. Its purpose is to allow the Object to respond to a variety of engine-level callbacks that may relate to it. For example, if the engine tells a CanvasItem to "draw", it will call _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: обратный вызов, который срабатывает до того, как движок удалит Object, т.е. 'деструктор'.

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

  • Node::NOTIFICATION_PARENTED: обратный вызов, который срабатывает при добавлении дочернего узла к другому узлу.

  • Node::NOTIFICATION_UNPARENTED: обратный вызов, который срабатывает в любой момент, когда удаляется дочерний узел из другого узла.

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

Примечание

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

A classic example is the _init method in Object. While it has no NOTIFICATION_* equivalent, the engine still calls the method. Most languages (except C#) rely on it as a constructor.

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

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

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

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

Используйте _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())

_init против initialization против export

If the script initializes its own node subtree, without a scene, that code should execute in _init(). Other property or SceneTree-independent initializations should also run here.

Примечание

The C# equivalent to GDScript's _init() method is the constructor.

_init() triggers before _enter_tree() or _ready(), but after a script creates and initializes its properties. When instantiating a scene, property values will set up according to the following sequence:

  1. Initial value assignment: the property is assigned its initialization value, or its default value if one is not specified. If a setter exists, it is not used.

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

  3. Exported value assignment: an exported property's value is again replaced by any value set in the Inspector, triggering the 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 someone sets test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".

As a result, instantiating a script versus a scene may affect both the initialization and the number of times the engine calls the setter.

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

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

When instantiating a script or a standalone scene, nodes are not added to the SceneTree upon creation, so no _enter_tree() callbacks trigger. Instead, only the _init() call occurs. When the scene is added to the SceneTree, the _enter_tree() and _ready() calls occur.

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

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