Potential bug: Using directional input map results in ignored inputs when you press multiple buttons at a time and release one of them

[Ecsodikas]

I am using the exact same directional input mappings from https://shirakumo.github.io/trial/start.html. They work fine on a game pad but for example when you press D you get the correct (VEC4 1.0 0.0 0.0 0.0) if you press A while still holding down D you get the expected (VEC4 -1.0 0.0 0.0 0.0) but when you release D now, you get (VEC4 -0.0 0.0 0.0 0.0) which stops movement entirely. This is especially bad when you need fast movement so you have to press WASD in fast succession and the input gets eaten a lot. Is this a bug in the directional-action implementation or am I doing something wrong and it is a layer 8 problem?

[Shinmera]

It's a bug.

[Shinmera]

Though the intended behaviour is also not entirely clear. In the case where two opposing keys are held, what should happen? Should they cancel each other out, or should the last one held win out? In the latter case, why shouldn't the first released win out as well?

[3b]

As a player, my first expectation is that if I'm holding down a single direction input, I should be moving in that direction, even if other inputs have been active since it was pressed. I'd expect opposing keys to result in no movement, and releasing either to cause movement in the direction of the remaining pressed key. For example with wasd setup, pressing a then s then d then releasing a then s then d would be a=left, as=down-left, asd=d=down, sd=down-right, d=right, then back to nothing.

So I disagree with the original that you should start moving left as soon as a is pressed while holding d, but agree that you should be moving left if a is still held down after d is released.

Checking some actual games, I found games that did each (opposites = no movement, or opposites = most recently pressed), but in both cases when the extra keys are released the first pressed key continues to cause movement. I didn't notice any problems with the controls of either while playing them, so it doesn't seem to be too important what happens while 2 keys are pressed, as long as the last remaining key continues to cause movement.

As a developer, I'd add that pressing 2 inputs bound to same direction should not increase speed. Player me says that releasing one of them should continue moving though.

In neither perspective do I have an opinion as to what 2 inputs in one direction and 1 in opposing direction should do, though I probably lean towards "no movement", as long as the "last button held down causes movement" part is still in effect.

tl;dr: press a = -1 press d while holding a = 1 or 0 release d while holding a (regardless of which was pressed first) = -1 release a while holding d (regardless of which was pressed first) = 1 press left while holding a = -1 (not -2)

[Ecsodikas]

[...] so it doesn't seem to be too important what happens while 2 keys are pressed, as long as the last remaining key continues to cause movement.

Is the most important part. Having no detection of an pressed key is the core problem here.

press a = -1
press d while holding a = 1 or 0
release d while holding a (regardless of which was pressed first) = -1
release a while holding d (regardless of which was pressed first) = 1
press left while holding a = -1 (not -2)

Summarises it perfectly imo.

[Shinmera]

The issue with the current implementation in this regard is that digital mappings aren't aware of each other, so when a button is released, the system has no way of knowing how to check whether any related "counter buttons" are still held down to reset to their value.

An additional complication is that Trial technically allows you to map the same direction to different magnitudes for different buttons, so the behaviour in that case is even less clear.

[Shinmera]

Please see b0f57000 for some of the issues with the current approach.