Input.action_just_pressed and Input.action_just_released doesnt work in _physics_process on Android

[ShadowwDev]

Godot version

4.0.beta1

System information

Vulkan Android

Issue description

on Android with TouchScreenButton node, input_action_just_pressed and Input.action_just_released doesnt work in _physics_process function but it does work with _process function however.

This works on godot 3.5 so im guessing its a bug on godot 4 beta 1

Steps to reproduce

heres an example project with the details:
https://github.com/ShadowwDev/Godot4Beta1-InputBugTest

Minimal reproduction project

Project download
InputBugAndroid.zip

[aea0ccf9]

I can confirm this on 4.0.beta2.

[dannygaray60]

I was developing a project with Godot4 beta10 and ran into that same problem. When calling Input.is_action_just_pressed... on android it does not work if it is inside physics_process, it only works inside _process.

[visionm45]

Confirmed bug in Godot 4.0

[ivandortulov]

This is still happening. Wish that it is fixed soon. The _process(delta) workaround does work.

[Calinou]

On 4.0.2, this works on desktop when enabling Emulate Touch From Mouse in the advanced Project Settings, so the issue is Android-specific (or Android/iOS).

Can you reproduce this in any of the 4.0 alphas to determine when the regression started? I wonder if this was already present in 4.0.alpha1 or not, specifically.

[ehsanonline]

I'm using v4.0.1.stable.official [cacf49999] and Input.is_action_just_pressed and Input.is_action_just_released aren't working on android. I use them for jumping.

[visionm45]

try 4.0.2

[erniel]

try 4.0.2

Still not working on android

[erniel]

Confirmed bug in Godot 4.1

[idbrii]

Is this issue because is_action_just_pressed checks if the input was pressed on this frame where each frame is a call to _process and not _physics_process? Maybe on Android, the framerate you're getting means that _physics_process isn't called frequently enough to hit the right frames when the input was changed (but on PC the framerate works out)?

[Alex2782]

On 4.0.2, this works on desktop when enabling Emulate Touch From Mouse in the advanced Project Settings, so the issue is Android-specific (or Android/iOS).

Is the emulation started here? input.cpp#L502
TouchScreenButton events on Android here input.cpp#L858

I think because TouchScreenButton is a graphical element, the functions are only triggered after _physics_process.
Workaround: #83301 = get_physics_frames() + 1

I was going to compare it to a normal Button, but there is no action property. Docs
If it should be solved like with the TouchScreenButton, then you could probably reproduce the problem in the desktop version.

[lawnjelly]

Sorry I must have missed this bug report.

It may be a regression from my PR #77055 .

EDIT: No it can't be, as my PR was from June 2023, and this report is from last year! 😁
However, there is a possibility my PR may have made this bug more likely to show up.

As @Alex2782 says, this is likely happening because the tick stored for the action is being stored after the physics_process. Their PR (#83301) to increase the physics tick registered for the press would likely "fix" the issue, but isn't ideal because it introduces a tick of delay to input, I'll put a note on that PR.

The actual problem makes total logical sense if you think about it. Every physics tick you have an opportunity to process presses that come in that tick. If the press comes in after the _physics_process, then it can be missed. This isn't occurring on most platforms as they process input synchronously before a tick, but on Android it can occur after (by random chance).

I think this should be pretty easy to fix properly, I'll do a PR. 👍

[synalice]

Indeed, moving some of the Input code into the _process function fixed this issue for me. Thx ❤️
It really needs to be more clear what is going wrong. Something like debug warnings, idk.

[lawnjelly]

Indeed, moving some of the Input code into the _process function fixed this issue for me. Thx ❤️
It really needs to be more clear what is going wrong. Something like debug warnings, idk.

The fault is not your side, it's an engine bug. There is PR to fix it, it just needs to be reviewed and merged. There's no point making a PR for warnings, as it is just as simple to fix it.

In some cases putting input code in the _process() can be used to mostly workaround it in the meantime (although even that appears to be susceptible, to a lesser extent).

[synalice]

Then what's the point of using `_process` at all? Isn't everything better off being inside of a `_physics_process`?

…

On Thu, Oct 19, 2023, 09:51 lawnjelly ***@***.***> wrote: Indeed, moving some of the Input code into the _process function fixed this issue for me. Thx ❤️ It really needs to be more clear what is going wrong. Something like debug warnings, idk. The fault is not your side, it's an engine bug. There is PR to fix it, it just needs to be reviewed and merged. There's no point making a PR for warnings, as it is just as simple to fix it. In some cases putting input code in the _process() can be used to mostly workaround it in the meantime (although even that appears to be susceptible, to a lesser extent). — Reply to this email directly, view it on GitHub <#66318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOWMWNDMO57ZTMJM5MTAFZ3YADEXPAVCNFSM6AAAAAAQUJBIGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZQGE3TCNBUGI> . You are receiving this because you commented.Message ID: ***@***.***>