In response to Ter13
I can always test it over a network on my end, as I mentioned to him. It wouldn't have nearly as much potential lag, but if a network is required then it should still tend to show up.
In response to Tens of DU
Tens of DU wrote:
Lummox the bug where input/alert causes KeyUp events to be lost happens even with "set instant=1"

That makes sense, since such a problem would occur at a higher level. Oddly though, we already have code in multiple places that forces a key-up if one hasn't fired already, so the trick must be something like the wrong macro set triggering (as was the case before). The issue is probably very skin-dependent, and that's part of the reason why I need a project with source to test it in.
Lummox JR resolved issue with message:
Non-repeat macros were sometimes being culled from the client-side command queue if too many stacked up at once, which is behavior that should only be expected of repeat keys and mouse commands.
In response to Lummox JR
Is this the fix for Alerts/Inputs?
No, it's for the key-down event sometimes getting lost. The alert/input issue was not what you reported in the initial post, and as I was never given a demo for it, I was unable to reproduce it.
Make your own Demo. Steps have already been explained many times you don't need anything but yourself and a simple Alert and Input verb.
As I explained already, the alert/input thing does not happen for me in a test project. Therefore there must be something about a particular skin, or the way the commands are setup, that makes it more likely. The alert/input issue is something I tested, and fixed, in the past for simple cases and it does not happen to me now. Even Ter said he can't reliably reproduce it. So if you have a project that does reproduce it reliably, I need to work with it myself.

I've tried reproducing this on my own and cannot.
There will be no more Demos because you don't listen, and always come with Can't reproduce maybe sometimes you should listen and do as the Player that has experinced the issue. After you've experinced it aswell ask for a Demo not before.

Until then no demo.
There will be no more Demos because you don't listen, and always come with Can't reproduce maybe sometimes you should listen and do as the Player that has experinced the issue. After you've experinced it aswell ask for a Demo not before.

=(

Not cool.
Zasif, I tried to explain this as clearly as I could. A live test does very, very little to help me. Even if I can see it in action live, I'm going to need to be able to reproduce it consistently while making changes to the code, retesting, making more changes, etc. Debugging is a lengthy process and it's a hundred times more difficult with a project I can't compile myself.

What is the point of withholding a demo until after I've logged into a live test? All a live test does is prove that the problem happens, but I already believe you that it does. Your credibility is not in question. I wholeheartedly, completely believe you that the problem exists, and I'm entirely eager to fix it. But I need to see it in an environment I control so that I can get to the bottom of why it's happening, and a live test doesn't accomplish that. I'd still have to download and compile the demo myself and try to reproduce it on my end before I could get to work fixing it.
I've paged you.
Well, I have good news and bad news. The good news is I downloaded your demo and started working with it. Since there were no instructions, I figure your intent was for me to hold down a movement key or two (WASD or arrows) and then click the Bla verb to pop open an input() box. Obviously this was only doable for the WASD keys, so I used those.

The bad news is I couldn't reproduce it. But it was still worth sending me the demo. Even if I couldn't reproduce it in the live test, it's possible that on another run I might have. Every time I clicked on Bla, all movement stopped in short order. And this was on version 509.1318, where the issue reported in this thread hadn't been fixed yet, so I might have expected that, due to the broken MoveKeys implementation, that might possibly cloud the situation. (With the lower tick_lag in your demo, I'm not sure how likely that was; higher framerates make that issue harder to reproduce.)

Having access to your demo was a good thing overall, because I was able to try several variations. I tried binding the Q key to the Bla command for instance, to see if keeping the input all-keyboard might have any impact. I changed your world.fps and the TICK_LAG macro to switch it to the default 10 FPS in hopes of at least pulling in this issue's bug and seeing if it had any impact on the situation. (That was a strong possibility, and I actually wouldn't even rule it out. The bug I fixed actually did impact key-ups.) Unfortunately as you know, the bug from this thread was also fairly intermittent and hard to catch, especially when it came to key-up commands, so it's possible that it's slipping through my testing simply because the key-up miss is so darn rare.

I also tried several different approaches as far as hosting. I tried Dream Seeker directly, then tried Dream Daemon with a local connection, and then I also tried Dream Daemon with a non-local connection to try inducing a small amount of network lag, since you mentioned that was relevant.

Based on my testing, and in particular noting that the MoveKey loop is not fixed with the required "set instant=1" command, I have a strong suspicion that the input/alert issue you're seeing may be fallout from this very same issue of "lost" key-down/key-up commands. Which is to say, it's entirely possible that once 509.1319 is released, you'll see the input/alert problem disappear even though it couldn't be directly targeted for a fix.

So even though the demo didn't show me the problem in action, it was definitely worth the effort to send it my way. That allowed me to see not only what code was in play, but to try out variations that I couldn't have tried in a single live test; it was important that I could recompile it and try a few different things. If 509.1319 does not fix the issue, let's revisit this test and see if we can hammer out some details on how to make it occur more often (e.g., what actions might make it more likely to show up, like holding keys down or spamming up/down, etc.; I tried everything I could think of, but maybe you're doing something that didn't occur to me).
The Ping lag must be over 150 if you can get to 150-300 it would be even better for testing, the key to make this bug happen is have bad connection the less laggy you are the less likely it will happen, for example running it in DreamSeeker alone its 100% Sure that won't happen because there is almost to none Delay whatsoever.

The way of testing, The moment you press a movement Key quikcly or almost instantly presss the Macroed Bla. Do this several times until the bug occurys.
The Idea is to quickly switch focus from the Map to the Alert/Input window, that way The Key that has been pressed thinks its still pressed, this will result in you running the direction you''ve pressed like an Auto-Run feature(Talk about an unwanted feature, Rekt 2016) that can't be stopped unless you relog.
Okay, thanks. Those are good clues. I still think there's a good likelihood that this has been addressed by the other fix, but we'll find out. I'm releasing 509.1319 now.

150-300 ms lag is actually kind of hard to get a lot of the time, but I'll see. One of the weird things is, with this being a keyboard issue it doesn't make much sense that lag would factor in at all.
In response to Lummox JR
Ohh but Lag plays a very big factor in this because the lag delay is the Judge on when the Alert/Input Window pops up and when the Movement starts or stops.
In response to Zasif
Right, but the key getting lost is most likely strictly client-side.

But given what you said, I wonder if the lag can be simulated by sleeping the alert/input proc for a short time before sending it. That's one thing I didn't think to test. But let's see how this new update pans out, and if that doesn't fix it then I can try again in 1319.
Ohh but Lag plays a very big factor in this because the lag delay is the Judge on when the Alert/Input Window pops up and when the Movement starts or stops.

Jumping in here for a minute. Keyboard input is handled fully on the client. Meaning the latency may not be related except that it's exposing another wholly unrelated issue where the client is somehow dropping a client-side notification that the key state has changed, and then not generating a key-up message that the server needs to interpret the current movement state.
Does the server also need to be updated for this fix or only the players themselfs is fine?

EDIT: Still happens, but didnt do a Server update. Just myself as client.

EDIT 2: Server update, same result still happenig.

EDIT 3: Made en video(Need VLC Player to play it) https://dl.dropboxusercontent.com/u/63471110/ BuggerInAction.rar
Lummo I've paged you again.
You mean it's happening in 509.1319?
Page: 1 2 3 4