Guarding against missing key events
by Joel Baxter · in Torque Game Engine · 01/13/2002 (6:21 pm) · 6 replies
I noticed that the trigger functions in the TGE example scripts look like this:
They used to look like that in Tribes 2 as well. But because some people would experience triggers getting stuck in the on or off position, they changed those functions to look like this:
This uses the val parameter, which indicates key-down or key-up, to make sure that the trigger variable is put into in the appropriate state of odd-ness or even-ness.
I presume that the problem this was fixing, is that sometimes a key-down or key-up event would "go missing", and so the function would get called with two of the same types of events in a row. In the original form of the function, that would mess up the trigger variable and cause its functionality to "stick".
So, what I'm curious about is, why does TGE use the original-style trigger functions in its example scripts? Has something been fixed in the engine so that key events don't go missing anymore?
function jump(%val)
{
$mvTriggerCount2++;
}They used to look like that in Tribes 2 as well. But because some people would experience triggers getting stuck in the on or off position, they changed those functions to look like this:
function jump(%val)
{
$mvTriggerCount2 += $mvTriggerCount2 & 1 == %val ? 2 : 1;
}This uses the val parameter, which indicates key-down or key-up, to make sure that the trigger variable is put into in the appropriate state of odd-ness or even-ness.
I presume that the problem this was fixing, is that sometimes a key-down or key-up event would "go missing", and so the function would get called with two of the same types of events in a row. In the original form of the function, that would mess up the trigger variable and cause its functionality to "stick".
So, what I'm curious about is, why does TGE use the original-style trigger functions in its example scripts? Has something been fixed in the engine so that key events don't go missing anymore?
#2
In the case of tying the key states to the mv states, the solution seems pretty good, though I'm not sure I like having it script code. But since that's where the keys are converted into move states... there may not be any other choice.
01/18/2002 (10:55 pm)
I don't know of any fix to the engine to try and correct missing up/down keys. If the OS fails to report key up values, that could be hard (if not impossible) to correct in the engine.In the case of tying the key states to the mv states, the solution seems pretty good, though I'm not sure I like having it script code. But since that's where the keys are converted into move states... there may not be any other choice.
#3
I imagine that probably isn't the exact situation that the T2 scripts change was meant to guard against. :-) But, I guess the event-dropping can indeed happen. Must be something having to do with a key event not being delivered to the app within a certain time, for whatever reason, and then expiring.
02/11/2002 (3:43 pm)
Heh, yesterday I ran across one situation where the "stickiness" can happen... I had a breakpoint that activated while I had my firing key down, and then when I came back to the game my weapon was stuck firing.I imagine that probably isn't the exact situation that the T2 scripts change was meant to guard against. :-) But, I guess the event-dropping can indeed happen. Must be something having to do with a key event not being delivered to the app within a certain time, for whatever reason, and then expiring.
#4
A lot of Windows programs have the sticky key problems. Most often pressing, and then releasing, the key will clear the stickyness.
Which key? Well, 90% of the time (more than that in my experience) it is control, alt, or shift, and you miss the key because someone presses Alt-tab to switch away.
In my experience, the key up message is unreliable when alt tab, alt escape or similar functions are involved.
-- update:
Additionally, if you use direct input to poll the keyboard, you are "supposed" to be able to verify the current key state; in this event, in response to an "on focus," you can ask the keyboard what keys are still pressed. Windows is, generally, seeing the key down/key up events from the keyboard itself, it's just a matter that while focus was shifting, it sent the release messages to the wrong window.
Anything that shifts focus (break points, pop ups, etc.) can cause the problem if the other entity isn't owned by your program. At least, that's what I've seen previously.
What I've done previously is pushed the DI keyboard state into a temporary array on lost focus, and then polled a new state after got focus, and compared the two. I manually fired key up events any time the states did not match.
This could be done inside the engine, assuming direct input's copy of the keyboard state is accurate. It "should" be, or at least there is no conceivable reason why it should not be.
Dave
02/11/2002 (7:29 pm)
Just as a note,A lot of Windows programs have the sticky key problems. Most often pressing, and then releasing, the key will clear the stickyness.
Which key? Well, 90% of the time (more than that in my experience) it is control, alt, or shift, and you miss the key because someone presses Alt-tab to switch away.
In my experience, the key up message is unreliable when alt tab, alt escape or similar functions are involved.
-- update:
Additionally, if you use direct input to poll the keyboard, you are "supposed" to be able to verify the current key state; in this event, in response to an "on focus," you can ask the keyboard what keys are still pressed. Windows is, generally, seeing the key down/key up events from the keyboard itself, it's just a matter that while focus was shifting, it sent the release messages to the wrong window.
Anything that shifts focus (break points, pop ups, etc.) can cause the problem if the other entity isn't owned by your program. At least, that's what I've seen previously.
What I've done previously is pushed the DI keyboard state into a temporary array on lost focus, and then polled a new state after got focus, and compared the two. I manually fired key up events any time the states did not match.
This could be done inside the engine, assuming direct input's copy of the keyboard state is accurate. It "should" be, or at least there is no conceivable reason why it should not be.
Dave
#5
everytime I F11 to enter editor and add an object
when I come out I am jumping uncontrollably (only in linux)
tho it did happen in windows .. just not everytime
once adding this it doesnt happen at all
02/12/2002 (6:17 pm)
I notice it was important to add this fix for me as everytime I F11 to enter editor and add an object
when I come out I am jumping uncontrollably (only in linux)
tho it did happen in windows .. just not everytime
once adding this it doesnt happen at all
#6
05/09/2005 (5:40 pm)
I had this happening to me as well. I thought there was something wrong with my code logic. I have a custom jump where the player only jumps after the jump is "charged up" but everytime I would try it he would just keep jumping and jumping and jumping. Will that line above correct that? I am pretty familiar with C++ but I am not sure how to read that. The ? and & always get me mixed up. :-/ 
Torque 3D Owner Joel Baxter