When Input singleton works?

Question

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

Answer 1

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

Comments

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.