Lua event.key - numpad enter - keyboard bug or lua bug?

[spokes2112]

Pete,

 

 Just noticed something when trying to use the numpad enter key using event.key in lua. IIRC there was something about this in the forum but through searches couldn't find it.

 

This works just fine for repeats -

event.key(135, 8, 5, "KeyStroke")

For a single shot, this works only 1 time when lua is first loaded and the enter key is used. It doesn't "listen" for it afterwards.

Unless.... The enter key is pressed and held logging repeating keypresses. Then, it will work just 1 time afterwards until repeated.  (a repeating keypress as a "listener" reset)  All other keys on numpad work just fine.

 

Single shot use, the one that doesn't seem to work properly -

event.key(135, 8, 1, "KeyStroke")

Strange thing though. When logging keys for the numpad enter key this is it's output for a single click / release.  KEYDOWN & KEYUP don't match. HMMM????

  3056715 KEYDOWN: VK=135, Waiting=0, Repeat=N, Shifts=0  3056715 .. Key not programmed -- passed on to FS  3056902 KEYUP: VK=13, Waiting=0

Through the FSUIPC interface it picks up the keydown, not keyup, but keeps on listening.

[Keys]21=135,8,L8:T,0,L8:K,0  9333696 KEYDOWN: VK=135, Waiting=0, Repeat=N, Shifts=0  9333696 LUA.4: "KeyTune.lua": Flag 0 toggled  9333696 .. This key is programmed in FSUIPC4 'Keys' options  9333696 LUA.4: Lua Flag event: calling "KeyStroke" in "G:\FSX\Modules\KeyTune.lua"  9333696 LUA.4: G:\FSX\Modules\KeyTune.lua:9  9333712 LUA.4: G:\FSX\Modules\KeyTune.lua:10  9333712 LUA.4: G:\FSX\Modules\KeyTune.lua:11  9333712 LUA.4: G:\FSX\Modules\KeyTune.lua:12  9333743 LUA.4: G:\FSX\Modules\KeyTune.lua:14  9333758 LUA.4: Waiting for an event in "G:\FSX\Modules\KeyTune.lua"  9333852 KEYUP: VK=13, Waiting=0No lua kill afterwards but it keeps listening for downpress.

Just wondering..  

Could go another route but was really hoping on using event.key

 

v4.947d on FSX accel boxed.

[Pete Dowson]

 Just noticed something when trying to use the numpad enter key using event.key in lua. IIRC there was something about this in the forum but through searches couldn't find it.

 

FSUIPC doesn't know one key from another, it is only getting ad matching the Keycodes. They are just numbers provided in the WM_KEYDOWN and WM_KEYUP Windows messages. If it isn't working for one specific keypress then either it isn't working for any, or something else is happening to the missing ones before fSUIPC sees it.

 

When you say "single shot", what exactly do you mean? How is the Lua plug-in being loaded?  I hope this isn't typical of wat you are doing with plug-ins:

 

[Keys]

21=135,8,L8:T,0,L8:K,0

 

 

 

Killing plug-ins is a rather desperate measure -- better to signal to it that it should terminate. Killing meaning terminating the thread in pretty much random places with possibly unpredictable results. I do my best to tidy everything up, but it's still something to be avoided when there's another way.

 

Anyway, if you tell me a little more about how you are starting it, and whether you picked out the Enter key specifically and haven't tested any others, I can try the same things here and see what is going on.

 

Pete

[spokes2112]

Pete,

 

 single shot = single press / release

 

[Keys]

21=135,8,L8:T,0,L8:K,0 

 

That was just a test to see if buttons via FSUIPC acknowledged the keyup - which it doesn't. FSUIPC still captures the key down event while in lua, event.key captures the key down event only once. As mentioned above -  Must use a repeating keypress as an event.key "reset" for only the numpad enter key. 

 

I am starting the lua via down arrow for now during testing ( 25=40,8,L8:R,0 ) , once completed it will be started via [Auto].

 

Here's the exact code I was using just to see if this style of code worked (beeps on event) -

sound.path("C:/Windows/Media")function KeyStroke(keycode, shifts, downup)			sound.play("Windows Default", 0, 100, -1)end-- NUMPAD ASSIGN ARRAY & EVENT LISTENERSlocal keyassign = { }for i = 1, 15 do	keyassign[i] = i + 95endfor i = 1, 15 do		event.key(keyassign[i], 8, 1, "KeyStroke")endevent.key(135, 8, 1, "KeyStroke")

No worries though Pete. I went the different route using event.flag(s) via [Keys] and is working nicely. Just think this is a bug of some sorts. Whether or not it is significant is up to someone who wants to use it. 

 

Thanks for everything,

Shuttin 'er down.. Having fun but it's 5 am & the eyes are on fire... :wacko:  

[Pete Dowson]

Thanks for the extra information.

 

I found out what is happening. Actually, part of it was obvious from your earlier Log:

 

9333696 KEYDOWN: VK=135, Waiting=0, Repeat=N, Shifts=0

....
9333852 KEYUP: VK=13, Waiting=0

 

The key code is logged as 135 for KEYDOWN but 13 for KEYUP.

 

Checking my code I see that the code 135 is actually manufactured by FSUIPC when it sees a Keycode of 13 (=ENTER or RETURN) and the flag indicating "extended key" is set in the data from Windows. It appears that's the only way of distinguishing between the two enter/return keys.

 

The bug is that this is not happening on the KEYUP -- it was left as keycode 13. This meant the Lua interpreter was left thinking the ENTER key was still pressed (not seeing the KEYUP for that keycode) and so wouldn't trigger again unless you had Repeats requested. And of course KEYUP events for code 135 never occurred.

 

It'll be fixed in 4.947e, later today. Thanks for the report!

 

Pete

[spokes2112]

Works a charm in 4.947e. :) 

 

Thanks for the excellent support! Much appreciated.

 

Have a great day!