I understood that the syntax func _ready() or func _process(delta) are prefabricated functions where their contents are executed in different temporalities, one when the node is ready - apply that, and the other while the game is not closed apply this as many times as possible.

So I misunderstand the func _input paradigm. While parsing a typed key can be done independently of this instruction container. So if you have something to satisfy my curiosity 🙂 I read you

  • Pixophir replied to this.
  • Hazlar

    From
    https://docs.godotengine.org/en/latest/tutorials/best_practices/godot_notifications.html?highlight=_input

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

    So, if there is complex stuff to do on mouse click like casting rays to points an screen and calculating their position in the world geometry, probably draw something as a reaction and play a sound, one wants a callback that only triggers if there's work to do.

    It also doesn't clutter _*process() with too much branching and functionality.

    Hazlar

    From
    https://docs.godotengine.org/en/latest/tutorials/best_practices/godot_notifications.html?highlight=_input

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

    So, if there is complex stuff to do on mouse click like casting rays to points an screen and calculating their position in the world geometry, probably draw something as a reaction and play a sound, one wants a callback that only triggers if there's work to do.

    It also doesn't clutter _*process() with too much branching and functionality.