A few newbish question about _process and _input. Can it cause a race condition?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By fagnerln

Maybe I’m misunderstanding something, looks like process is executed every frame and input immediately.

What happens if the input is detected in mid frame? It will be executed instantly or it will be queued to the next _process?

Why some people checks the input on the _process instead of using the _input function?

About the _input , I noticed that some people uses, for example, Input.is_action_pressed and looks like the correct is to use event instead. What is the difference? Why people should use event?

:bust_in_silhouette: Reply From: Lopy

Input events do not stop the execution of your _process. They are logged and played back as soon a possible.

When you press a key, like escape, Godot generates an Event for it and propagates it through the tree to see if some Node is interested by it. It will call _input, _unhandled_input, _gui_input, etc, based on event propagation rules. (A second one is generated on key release, they are distinguished with the pressed property).

This is great to detect when to open or close a menu, but does not work well to make a player move forward. You would need to repeatedly press the key to generate constant inputs, or record presses and releases yourself. This is why player movement and similar are generally handled using Input.is_action_pressed and similar.

For player movement in particular, consider using Input.get_action_strength, to take advantage of controller joysticks (it does not change anything for key Events).

Edit: _input and _process are both on the same idle/main thread. In your example, processing of the Event would happen afterwards (possibly on the same tick, maybe the next, or even on the next but after _process).
I am fairly certain however that physics related operations and the associated _physics_process may or may not run on a separate thread, depending on configuration. The same happens if you manage to run code in the rendering thread (by connecting to Server signals).

Thanks for your answer, it’s now clear about the Input. vs event..

But about the first paragraph:

Input events do not stop the execution of your _process. They are
logged and played back as soon a possible.

I know that it don’t stop the _process, this is clear. My question is if it runs in parallel. For example: A chess board with a pawn on middle of line 5.

-The process run every line looking every tile to find a pawn.
-It finished the scan of line 4, which have no pawns, and start scanning the line 5.
-in that exactly millisecond the input makes the pawn move to line 4.

So what happens?
A) The input is executed immediately and the scan will finish the board without find any pawn.
B)The input will be queued and executed before the next process, so making the scan finding it on line 4.

fagnerln | 2021-04-18 00:45