Rework input actions to be reliable

[KoBeWi]

#80859 introduced surprisingly many regressions (I mean, who would've thought that press and release count for an action don't necessarily match...). This PR reworks the input actions again. This time pressed is a bitmask. When an event is pressed, it sets a bit in the pressed integer, release resets it. Pressed state is still determined by pressed being greater than 0, but since every event corresponds to a bit being either 0 or 1, there is no way to "overpress" or "overrelease" the event.

Action strengths broke again after the rework, so I reworked that too. Since I am using event index anyway, I decided to just keep a vector of all event strengths. Now the action strength is the max value of all event's strengths. It makes action strength more reliable than ever.

Some considerations:

• since the pressed state is stored using bitwise operations, the event count per action is now effectively limited to 32. We should probably enforce that somehow
• Input.press_action() will press the action, but then it can be released by any event. Input.release_action() releases all events. This is actually how it was before the previous rework

Fixes all input action regressions, probably.
I tested with some projects on Windows and it appears to be working correctly overall.

Bugsquad edit:

• Fixes X11: is_action_pressed returns incorrect value when key was pressed during scene loading #82262 (Rework input actions to be reliable #84685 (comment))
• Fixes [Chrome] Input actions get stuck in the pressed state on web builds #82732 (Rework input actions to be reliable #84685 (comment))

[Calinou]

Tested locally (rebased on top of master 2b987d1), it works as expected.

Testing project: test_analog_and_digital_input_2.zip

Using Windows 11 22H2 and wired DualSense.

At long last, simultaneous keyboard and gamepad input finally work in tandem! 🙂

godot.windows.editor.x86_64_ESzyyYuRCB.mp4

Compare this with the video in #81170 (comment) where it didn't work correctly.

I'll do testing on more platforms to confirm.

[KoBeWi]

Ok I fixed the action_press/release() methods. Not sure what to do about event limit (maybe it's not a concern?), other than that it should be good now.

[akien-mga]

Did some initial testing of this PR on Linux (Mageia 9, KDE/X11), it seems to work well.

I confirm that it fixes those two regressions:

• X11: is_action_pressed returns incorrect value when key was pressed during scene loading #82262
• [Chrome] Input actions get stuck in the pressed state on web builds #82732

I've only tested with keyboard events so far. Some testing with keyboard, mouse, and controller in a more complex project would be important.

[akien-mga]

The timing is tricky as we're so close to release candidate, but this solves release blockers for 4.2 and we don't necessarily have safer alternatives.

So let's merge and test it thoroughly in the next beta to make sure it solves the problems without further regression.

[Calinou]

I've also tested a Web export of this PR on Firefox 119 and Chromium 118 on Linux with a wired DualSense and it works as expected. I haven't tested Android yet (need to connect a hardware keyboard for this).

[akien-mga]

Thanks!

[Toxe]

Funny, just two days ago I made a test project with 4.2-beta5 to track this issue down and I noticed that this was a) very easy to reproduce and b) happens only in Chromium browsers and I wanted to report this issue today (or check if someone else already has).

https://godotforums.org/d/37491-does-anyone-else-get-this-html-input-bug

And today 4.2-beta6 got released which fixes this. I should have waited two more days. ;-)

But yeah, I can confirm that this an issue with HTML exports on Chromium and that I still get these unnecessary input events. But my initial issue with "sticky" input keys is now fixed.

[slumberface]

Copying this from #86272

I think testing for this should include both axis, because there seems to be an issue right now where if a dual sense is plugged in, then pressing the y axis on keyboard will give you small erroneous values on the x axis. The method displayed might not be the proper way to poll for values, but perhaps it's relevant for this discussion:

It's also worth noting that this problem persists even when the controller is then unplugged while playing the scene. The controller has to be unplugged before the scene is played for no fuzz on the axis.

This also doesn't just happen using the default ui inputs. Even after creating custom inputs which have a deadzone of (0.5), this fuzzing on x axis while pressing the y axis occurs. Starting to wonder if this is specifically a problem with Input.get_vector

EDIT: This polling works correctly, no fuzzing. Maybe a problem with Input.get_vector in particular ( the 5th parameter for custom deadzone doesn't help)

[teddybear082]

Would these issues addressed in this PR also include Input.parse_input_event() not working properly when the input event passed is an Action event and the game is using gamepad input? I’m trying to debug something right now where it doesn’t seem like this is triggering actions even though the same code when sending Joypad Button events work and not sure if I’m doing something wrong in my code or it might be connected with these input action issues.

[KoBeWi]

No, that has separate fix: #86010