ID:2162810
 
BYOND Version:510
Operating System:Windows 10 Home
Web Browser:Chrome 31.0.1650.59
Applies to:Dream Seeker
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Old bug I think, has done this for years to me, and Clusterfack posted something about it and I had happened to make a project the following night that could reproduce it.

Hold any of the movement keys [AWSD] and fire keys [UP,LEFT,RIGHT,DOWN]

and move around or click menu at the top while moving or press ALT while holding the keys.


https://www.sendspace.com/file/e5ih6z
Bump
I tried the things you listed, but I was not able to reproduce any problem with up macros. This is in 511, though. Can you try in 511 to confirm this is still an issue there? And if so, can you give me some specific action combos that cause the problem?

I tried:

- Using movement and fire keys at the same time
- Using movement keys and clicking the menu (keydowns weren't caught while the menu was open, but keyups still worked)
- Holding Alt while pressing movement keys

None of those caused any issues for me.
Lummox JR changed status to 'Unverified'
Tested in 511 and it is still happening.

Press left-alt fast while pressing w and s repeatedly, it takes randomly between 3 to 10 seconds to happen but a windows event sound plays when it does.
This sounds actually like your keyboard is simply dropping the events due to overload. Your keyboard may have simply overloaded to the point where the driver still thinks a key is being pressed.

DS should always detect when a held key has been released, if the system knows it has been released. On the tick, it scans the current state of all keys it knows are down. If the state is messed up at a driver or hardware level, however, the system may honestly think a key is still down that isn't.
One problem I have encountered that is related to this, is that I recently implemented a move loop system that people here describe fairly often, and it always successfully stops the player whenever a window is opened with browse() or such and focus is lost.

However when a Byond input window pops open, it doesn't detect the key as being released and keeps the player moving in that same direction until they hit the key again and release it.
In response to Clusterfack
Another user has reported the same thing, but he was never able to produce a demo project that showed it. He had a demo, but the problem never surfaced in it. I tried anything I could think of to force it.

But the same still applies: DS actively scans the state of held keys, so it should always release. It also keeps track of which window was marked for each held key, so it can use the right macro set.
I reported this 1-2 years ago too. Still happens. Anytime a alert() or input() menu pops up in my game while the player is busy moving, they will be stuck moving in that direction despite not holding any direction key anymore.
#MakeBYONDGreatAgain
Maybe you can come up with a demo that shows the input/alert issue where the last one didn't.
I've tried quite a few things using inputs and alert to try and cause a issue. Didn't cause any problems.

The demo I posted every direction key is tied with a verb that increments a direction variable by the direction's value so North-Down + East-Down would make direction += 1 and direction += 4 but sometimes it seems that macro-ups aren't being called as eventually the direction variable will equal something other than 0 with no keys pressed.
Adding and subtracting is your problem, then. What you need to do is look for the actual command getting through. If an extra keydown got through for any reason, that would throw off your calculations and cause a problem. This is not the correct way to handle keydown/keyup for that exact reason.
In response to Lummox JR
I mentioned that to him before, but there's still the problem of it being possible in any case for, say, two key-down events or two key-up events to happen in a row for the same key. While it's still probably best to program defensively to avoid potential problems from someone else's code, it's still worth reporting. Just because there's a workaround doesn't mean the bug isn't relevant. (and on the other hand, just because it's reported, doesn't mean it's a priority)

I was able to reproduce this pretty consistently by mashing Alt and a key with specific timing, or, similarly, spam clicking on a menu while mashing the key.
In response to Kaiochao
Even Windows doesn't guarantee that two keydowns won't happen for the same key. A counter is simply not the correct way to handle them.

Can you give me a more concrete example of the mashing and timing you're talking about? I tried playing around with the keys and the menu and couldn't get anything to happen.
Although I'm pretty sure I've seen it happen without Alt or menus being involved, I've been able to reproduce a case where two key-up events happen with no key-down in between:
mob
Login()
winset(src, "blah", "parent=macro; name=z; command=blah")
winset(src, "bloo", "parent=macro; name=z+up; command=bloo")
winset(src, "reset", "parent=macro; name=x; command=reset")

var blah = 0

verb
blah() src << "BLAH [++blah]"
bloo() src << "BLOO [--blah]"
reset() src << "RESET [blah = 0]"

Ideally, the "blah" variable should never be shown to be negative (or greater than 1) because when Z is pressed, ++blah is 1, and when Z is released, --blah is 0. However, I've been able to get blah to continuously decrease by following this sequence:
(This needs to happen pretty quickly)
1. Press and release ("tap") Alt.
2. Press and hold Z.
3. Double-tap Alt.
4. Release Z.
Of course, this pattern is very unlikely to ever occur. It's not the only way to do it, but I haven't been able to reliably reproduce an issue any other way.
I have very little interest in trying to hunt down repeated keydowns/keyups. I can imagine too many ways for those scenarios to keep recurring no matter what I do to hunt them down. The real question is, do keys actually get stuck so that the keyup never happens? If not, I consider this pretty much a non-issue.