Key [] Pressed gets stuck here and there

[elvagor]

I'm trying to move a sprite around the screen with WASD key presses. My code is like this:

Then I process the dirs list later on in the code.

The problem is, sometimes the block gets stuck reading its key as continuously pressed, even though it is not, so the sprite starts going on forever in the related direction. Pressing the other keys moves the sprite also in the pertinent direction, but it doesn't solve the issue. Only way out of this situation is physically pressing and releasing the "stuck" key: after that, the block starts providing a correct result again.

I tried to remove the dirs list and immediately process the input, but the issue is still there. I also tried to use the hat block, again the issue persists.

Is this due to Snap!, to the browser (Chrome), to the OS (Windows 10) or to what else? Is there a way to avoid this effect?

Thanks!

[ego-lay_atman-bay]

I've had this issue before, but it only rarely happens. I'm pretty sure it has to do with the keyboard.

[dardoro]

Maybe a hardware issue with low N-Key-Rollover

How do I remove the limit on PC keyboard button presses?

[bh]

Your picture didn't show the rest of the script, so I'm only guessing:

You think you didn't hold the key down for a long time, but that's because you're not a computer. What seems like a short time to a human being is long enough for a computer to sense the key down thousands, maybe millions, of times.

The usual technique to avoid this problem is

but if you do that, you can't put the four IF blocks one after another in the same script; you have to run them in parallel, if you want to be able to handle simultaneous presses.

[elvagor]

Thank you all for your contribution.

ego-lay_atman-bay, I'm not able to reproduce the issue at will on my laptop keybord, yet it happens quite often by playing around with keys long enough.

@bh, I think you might be missing my point: I want the sprite to move say to the left as long as the player is keeping key A pressed down. So the script can't wait until A is released, hence what you're proposing doesn't apply to my case.

@dardoro, this could possibly play a role in my issue, but I think it is not the root cause. I made this short script to test my two keyboards, and indeed the Lenovo laptop one is missing several keypresses when I press multiple keys at the same time; I'd say that is more ore less a 2KRO. Also my Logitech desktop keyboard miss some keys, but it seems to be quite consistently a 4KRO. Varying the set of active keys produces different results, likely due to the underlying keyboard circuitry.

Testing WASD: all keys read correctly

Testing ZDT7P: the 7 key is lost in some combinations (rows 4 to 6)

Ghost key "A" in action: it can't be seen from the screenshot, of course, but the is reporting A continuously pressed even if it is not (see the log), and the sprite keeps moving to the left.

However, please note that I cannot relate my issue (a key is read as pressed even if it is not) to a specific combination of pressed keys, so I'm not totally sure that this is the root cause, since the "ghost" key is read as pressed only in Snap!. If I select the browser address bar, for instance, the ghost key doesn't propagate there, while in Snap! it survives also to pausing the script and resuming it.

Do you feel sure enough to exclude there could be something amiss in Snap! itself?

EDIT: I've found the following website that helps in testing a keyboard for KRO limit. As much as I'm trying to cause the stuck key issue there by pressing WASD combinations on my laptop keyboard, it doesn't happen.
http://random.xem.us/rollover.html

EDIT 2: I've ported the same script from Snap! to Scratch: on Scratch the stuck key issue does not happen, even though I'm using the same laptop.

Thanks!

[ego-lay_atman-bay]

@elvagor

the script can't wait until A is released, hence what you're proposing doesn't apply to my case.

then use repeat until

[dardoro]

Keys can stick this way when pressed with Ctrl. There were threads about this and test project to circumvent this misfeature.

[elvagor]

@dardoro: Ctrl is not involved in the issue, it is not used by the player. Definitely the issue happens on Snap! (not on Scratch) with a keyboard with a low KRO (doesn't happen with my other keyboard, no matter how long I try). Both factors should be there for the issue to happen.

@ego-lay_atman-bay: not sure what you do mean. The script works fine as it is, as proved by reproducing it in Scratch. Besides, even if I should rewrite it using repeat-until, there is no guarantee that the issue does not come up exactly in the same way.

Thanks!