0 votes

Hi, according to that diagram, when Input singleton receives an input? It checks in the fly, in place of a call? As _input(), later? I have problems with game vs. UI issue. In game (mainly in singletons) i'm using some Input's and UI uses mix of signals, Input, _input(), an _input_event() (yep, that's messy...).
I have that arch.:

- singleton
- singleton
- root
-- stuff
-- CanvasLayer
--- UI
-- camera
in Engine by (186 points)
edited by

1 Answer

+1 vote
Best answer

AFAIK, using the Input singleton directly checks something globally, regardless of which UI is on top of the game or whatever thing has focus. So in a sense you decide when to check them at any time. In many engines this is the source of problems when UI and game are mixed, leading to isUIOpen booleans, which can get messy real quick IMO.

In contrast to that, _input callbacks mitigate this issue because they are called when the engine decides it's your turn to handle them, as they happen. These are checked for focus so if some UI has focus on top of the game, the game won't receive _input events. Remember Input disregards this because of what I said above.

More info about the order in which this happens: http://docs.godotengine.org/en/stable/learning/features/inputs/inputevent.html

by (27,831 points)
selected by

Ok, so as I understund Input singleton works independently of InputEvent flow. Is there any reason to use them other than prototyping? So that wroks as:
- _input() should be used for global input actions (like keys, Esc, etc.),
- _input_event() for UI,
- _unhandled_input() game checks ?
Last question, are inputs handled in order of children - "from up to down"?
Btw. thanks for the answer.

Input is handy for prototyping because it's easy to use compared to an event-driven approach. However callbacks are better otherwise, but a bit harder to work with, so you probably can' t eliminate the use of Input because sometimes it's just way simpler (but keep the UI in mind).

I have no idea in which order they are sent, and I usually write my code so that it doesn't care about it, so that it doesn't magically breaks just because a node was moved.

Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to webmaster@godotengine.org with your username.