Strange key-press-timing problem with a 2nd keyboard

After setting up my new POS keyboard last night and trying to go for a fly tonight I struck this problem after a very frustrating night with customer support for the keyboard I found this thread and have been able to get it working so just stopping by to say thanks for your code Tom

:thumbup: Does anyone know if this is a bug, or rather a feature? Like, for safety reason?

After setting up my new POS keyboard last night and trying to go for a fly tonight I struck this problem after a very frustrating night with customer support for the keyboard I found this thread and have been able to get it working so just stopping by to say thanks for your code Tom

You are very welcome.

:thumbup: Does anyone know if this is a bug, or rather a feature? Like, for safety reason?

I'm sure it's nothing of those. It seems it is just a timing problem within the code. E.g the DDI buttons of the Viper showed that issue and that was the reason for me to find a solution for it. And after the last stable update they work good enough, like those of the Hornet. But that was not mentioned in the patch notes. I assume ED is not even aware of this timing issue because it is still there e.g. for that little data control switch (stick) on the ICP (UFC) of the Viper.

I hope they'll fix this for all inputs some day.

This also happens with virtual input. In my case, I bind my landing gear to a lever switch (axis that activates vjoy virtual Dx buttons depending on up or down positions) and the landing gear will not move unless the press duration is set for 2-3 sec. Not sure if this is specific to joystick gremlin which I use. Interestingly, using keyboard mapping rather than virtual button works perfectly.

This also happens with virtual input. In my case, I bind my landing gear to a lever switch (axis that activates vjoy virtual Dx buttons depending on up or down positions) and the landing gear will not move unless the press duration is set for 2-3 sec. Not sure if this is specific to joystick gremlin which I use. Interestingly, using keyboard mapping rather than virtual button works perfectly.

Thanks for sharing this. The more of us have this issue the better the chances that ED will look into it. (I'm not complaining bc it is not a game breaker, but it is odd.)

In my case my driver-less 2nd keyboard is originally a "cash register" and has no timing options/settings.

In the DCS control settings it some times lasts 2 to 10s of pressing and holding the keys (when there are key combinations with modifiers like shift, alt or ctrl) till all keys are recognized, but after that I just press normally (short) to see the bound function correctly and immediately.

In the game most functions are executed correctly but some buttons (like the DDI's or MPCD) do not show the animation of being pressed and released for those working functions. But at least they work now.

I thought about contacting the manufacturer of my "cash register" but then I found Auto Hot Key and that was the faster solution.

Hi guys.

Have a problem that looks like this.

I have a separete wireless keypad that i use as some kind of UFC for my hornet, i had set the option button 4 from UFC to Tab key, all were working great but looks like with the last update everithing work like always except the Tab key.

Like you, button works flawlessly in controls menu but no on game, with AHK i have tried this:

newTiming:=85

 

tab::

send {tab down}

sleep, newTiming

send {tab up}

return

But didnt work, anyone can help me? thanks.

FYI Tom in terms of the question you asked about autohotey sending the original key and the modified key heres a thread i wrote in 2011 that talks about how HIDMacro was doing the same and that ED is grabbing the input at too low a level to actually see it. I suspect its the same problem. Still your Autohotkey solution saved a very expensive POS keyboard from going to waste for me.

Hi guys.

 

Have a problem that looks like this.

 

I have a separete wireless keypad that i use as some kind of UFC for my hornet, i had set the option button 4 from UFC to Tab key, all were working great but looks like with the last update everithing work like always except the Tab key.

 

Like you, button works flawlessly in controls menu but no on game, with AHK i have tried this:

 

 

 

But didnt work, anyone can help me? thanks.

I'm a bit out of this bc it has been working great, but I see a small thing. Have you tried to add {Blind} like this:

newTiming:=85

tab::

send {Blind}{tab down}

sleep, newTiming

send {Blind}{tab up}

return

And make sure you don't have the line

SendMode Input

in your code.

I'm a bit out of this bc it has been working great, but I see a small thing. Have you tried to add {Blind} like this:

 

newTiming:=85

tab::

send {Blind}{tab down}

sleep, newTiming

send {Blind}{tab up}

return

 

 

And make sure you don't have the line

SendMode Input

in your code.

Thanks for your response.

Already tried and didn´t work, the only lines of code in the script are the ones in the quote i posted, nothing more.

Have to say that this is not an isolated bug on the wireless keyboard, regular keyboard (Logitech G19) didnt work either.

Thanks for your response.

 

Already tried and didn´t work, the only lines of code in the script are the ones in the quote i posted, nothing more.

 

Have to say that this is not an isolated bug on the wireless keyboard, regular keyboard (Logitech G19) didnt work either.

Try :

newTiming := 85

$Tab::
send {tab down}
sleep, newTiming
send {tab up}
KeyWait Tab ; This is to avoid autorepeat.
return

Edit : If it work, then I rather advise you to use this technique, which does the same thing, prevent autorepeat, but doesn't use keywait which is problematic when use press multiple key at the same time.

Tab_pressed := 0

newTiming := 85

$Tab::
{
If (Tab_pressed)
	Return
Tab_pressed := 1
Send {tab down}
Sleep newTiming
Send {tab up}
Return
}

$Tab Up::
{
Tab_pressed := 0
Return
}

Try :

 

newTiming := 85

$Tab::
send {tab down}
sleep, newTiming
send {tab up}
KeyWait Tab ; This is to avoid autorepeat.
return

 

Edit : If it work, then I rather advise you to use this technique, which does the same thing, prevent autorepeat, but doesn't use keywait which is problematic when use press multiple key at the same time.

 

Tab_pressed := 0

newTiming := 85

$Tab::
{
If (Tab_pressed)
	Return
Tab_pressed := 1
Send {tab down}
Sleep newTiming
Send {tab up}
Return
}

$Tab Up::
{
Tab_pressed := 0
Return
}

Thanks for the help, but didnt work :(

If helps, sometimes with the Hornet or Tomcat in controls menu the UFC 4 button appear as red, but can fix it removing the bind and binding it again.

Man, its frustrating, not a break deal but i dont know why it works before and not now, i bind bloq num and works, i bind tab and dont work...

Fixed, Tab was binded to multiplayer chat on UI layer, before it was working, after the patch no, unbinded from UI layer and it works flawlesly.

Thanks.