Jump to content
The simFlight Network Forums

event.key


Recommended Posts

Hi,

I'm having the following issue: if I setup a key bind with a 'shifts' modifier, my callback is never called when the keys are released. I'm using FSUIPC 5.154.

function testBind(keycode, shifts, downup)
  -- always prints all three
  print(downup == 1 and "initial press (A)"
        or downup == 3 and "repeated press (A)"
        or downup == 0 and "release (A)")
end

function testBindWithShifts(keycode, shifts, downup)
  -- doesn't print 'release'!
  print(downup == 1 and "initial press (CTRL+A)"
        or downup == 3 and "repeated press (CTRL+A)"
        or downup == 0 and "release (CTRL+A)" or "huh")
end

event.key(string.byte("A"), 8, 7, "testBind")
event.key(string.byte("A"), 2, 7, "testBindWithShifts")

 

Link to comment
Share on other sites

8 minutes ago, adrem said:

I'm having the following issue: if I setup a key bind with a 'shifts' modifier, my callback is never called when the keys are released, unless I create another bind for the same key without modifiers. I'm using FSUIPC 5.154.

Hmm. This is probably because Windows notifies us of the main key release separately. In which order do you release the two keys? That might make the difference.

I can do some experiments here and see if we can handle this either way, but it would be handy to know whether the results are different before we delve into it.

Interestingly no one has come up with this before -- the code isn't exactly recent! 😉

BTW the current version of FSUIPC5 is 5.155, and that's really being replaced by FSUIPC6 in terms of development.

Pete

 

Link to comment
Share on other sites

6 minutes ago, Pete Dowson said:

In which order do you release the two keys? That might make the difference.

I just tried both ways and it didn't work most of the time either way, but actually it does very rarely print 'release' when I first release the 'A' key.

Link to comment
Share on other sites

2 hours ago, John Dowson said:

Hi,

could you please try the following dll: FSUIPC5.DLL

I've tested with your script and the release is printed with the shift.

Cheers,

John

It does work, however it calls both callbacks when the bind is released.
   160338 LUA.0: initial press (CTRL+A)
   160837 LUA.0: repeated press (CTRL+A)
   160868 LUA.0: repeated press (CTRL+A)
   160915 LUA.0: repeated press (CTRL+A)
   160930 LUA.0: repeated press (CTRL+A)
   160946 LUA.0: release (A)
   160946 LUA.0: release (CTRL+A)
   164363 LUA.0: initial press (A)
   164846 LUA.0: repeated press (A)
   164893 LUA.0: repeated press (A)
   164924 LUA.0: repeated press (A)
   164940 LUA.0: repeated press (A)
   164955 LUA.0: release (A)
   164955 LUA.0: release (CTRL+A)

Link to comment
Share on other sites

1 hour ago, adrem said:

It does work, however it calls both callbacks when the bind is released.

Yes, it will do, because both apply. There's really no way around that. You asked for an event to be triggered when A was released. Well it was. At that time, the Ctrl doesn't figure.

Pete

 

Link to comment
Share on other sites

I'm not sure if that makes sense - your regular key binding facility certainly doesn't work that way.


I've made the following assignments to test:
11=65,8,66601,0,66601,1     -{A: Press=ADD_FUEL_QUANTITY, Release=ADD_FUEL_QUANTITY }-
13=65,10,66601,2,66601,3     -{ctl+A: Press=ADD_FUEL_QUANTITY, Release=ADD_FUEL_QUANTITY }-

As you can see in the log, it only sent param 1 when I released the plain key and it only sent param 3 when I released CTRL+A:


    82884 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=0
    82884 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    82884 .. This key is programmed in FSUIPC5 'Keys' options
    83383 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83383 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83383 .. This key is programmed in FSUIPC5 'Keys' options
    83430 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83430 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83430 .. This key is programmed in FSUIPC5 'Keys' options
    83461 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83461 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83461 .. This key is programmed in FSUIPC5 'Keys' options
    83492 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83492 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83492 .. This key is programmed in FSUIPC5 'Keys' options
    83523 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83523 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83523 .. This key is programmed in FSUIPC5 'Keys' options
    83554 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83554 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83554 .. This key is programmed in FSUIPC5 'Keys' options
    83586 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83586 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83586 .. This key is programmed in FSUIPC5 'Keys' options
    83617 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83617 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83617 .. This key is programmed in FSUIPC5 'Keys' options
    83648 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83648 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83648 .. This key is programmed in FSUIPC5 'Keys' options
    83695 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=0
    83695 FS Control Sent: Ctrl=66601, Param=0 ADD_FUEL_QUANTITY
    83695 .. This key is programmed in FSUIPC5 'Keys' options
    83695 KEYUP: VK=65, Waiting=0
    83695 FS Control Sent: Ctrl=66601, Param=1 ADD_FUEL_QUANTITY
    83695 .. This key is programmed in FSUIPC5 'Keys' options
    86955 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2
    86955 .. Key not programmed -- passed on to FS
    87454 KEYDOWN: VK=17, Waiting=0, Repeat=Y, Shifts=2
    87454 .. Key not programmed -- passed on to FS
    87470 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=2
    87470 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    87470 .. This key is programmed in FSUIPC5 'Keys' options
    87969 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    87969 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    87969 .. This key is programmed in FSUIPC5 'Keys' options
    88016 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    88016 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    88016 .. This key is programmed in FSUIPC5 'Keys' options
    88047 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    88047 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    88047 .. This key is programmed in FSUIPC5 'Keys' options
    88078 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    88078 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    88078 .. This key is programmed in FSUIPC5 'Keys' options
    88110 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    88110 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    88110 .. This key is programmed in FSUIPC5 'Keys' options
    88141 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    88141 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    88141 .. This key is programmed in FSUIPC5 'Keys' options
    88172 KEYDOWN: VK=65, Waiting=0, Repeat=Y, Shifts=2
    88172 FS Control Sent: Ctrl=66601, Param=2 ADD_FUEL_QUANTITY
    88172 .. This key is programmed in FSUIPC5 'Keys' options
    88203 KEYUP: VK=65, Waiting=0
    88203 FS Control Sent: Ctrl=66601, Param=3 ADD_FUEL_QUANTITY
    88203 .. This key is programmed in FSUIPC5 'Keys' options
    88375 KEYUP: VK=17, Waiting=0

Link to comment
Share on other sites

13 minutes ago, adrem said:

I'm not sure if that makes sense - your regular key binding facility certainly doesn't work that way.


I've made the following assignments to test:
11=65,8,66601,0,66601,1     -{A: Press=ADD_FUEL_QUANTITY, Release=ADD_FUEL_QUANTITY }-
13=65,10,66601,2,66601,3     -{ctl+A: Press=ADD_FUEL_QUANTITY, Release=ADD_FUEL_QUANTITY }-

As you can see in the log, it only sent param 1 when I released the plain key and it only sent param 3 when I released CTRL+A:

Hmm. Interesting. I'll have to look to see how that was done. Tomorrow though, it is late here.

I think it probably relates to the fact that the Key Down also generates an event. Might be interesting for you to test those two assignment lines with actions only on the Key Up. If not, I'll try that tomorrow. We should be able to make the Lua events behave in the same way.

Currently the "downup" parameters says "either of up or down" whereas the control assignments are distinct. There's no equivakence. So another check is what happens with separate "up" only events.

Pete

 

Link to comment
Share on other sites

20 hours ago, Pete Dowson said:

think it probably relates to the fact that the Key Down also generates an event. Might be interesting for you to test those two assignment lines with actions only on the Key Up.

I wanted to try right now, but the control drop-down for Key Up is greyed out if you haven't selected a control for Key Down.

By the way, I've upgraded to FSUIPC6 - in case there will be another dll to test.

Link to comment
Share on other sites

I tried FSUIPC6.dll and it's working as expected with one minor exception: if I release CTRL first, then the plain key callback is called after I subsequently release A. I don't know if it's feasible for you to make it that the CTRL+A callback is called when you release either one of the keys or both, so feel free to ignore this.

Link to comment
Share on other sites

57 minutes ago, adrem said:

if I release CTRL first, then the plain key callback is called after I subsequently release A.

That is perfectly right and proper. You asked for an event to be called is FSUIPC sees 'A' released. And it does. 

59 minutes ago, adrem said:

I don't know if it's feasible for you to make it that the CTRL+A callback is called when you release either one of the keys or both

No. Once the shift keys are released there's no way of knowing.

BTW your original problems would probably have been resolved much more easily by using different events for each case. the problem with asking for "Press, Repeat or Release" is simple that, as documented, events aren't queued. if your plug-in isn't ready to receive one when another occurs, you don't get the first.

Exceptions were made just for buttons and keys so that you didn't get into a state where a button or key looked "stuck". A mistake was made in the code (by me of course) in simply incrementing the number of occurrences.  At the time the plug-in code is ready to be re-entered with the event, things like the shift codes may be different. The Lua plug-in system isn't running in real time -- the threads operate in their own time (and space).  This is very unlike the key assignments to controls, to which you compared it. That operation IS is real time, and all in the main sim thread.

Today I compared the offering for event.key to what is documented for event.button. If you refer to that in the Lua Library document you will see there's a Note (*) reference, and the Note occurs at the end of the event library section. If you read that and think about it in terms of keys too, then maybe it will be clear.

For us the fact that you were trying to collect events of key press repeats as well really complicated things. In the solution we arrived at you will only get repeats if the plug-in is fast enough to process things as they happen -- unlike release which will be saved so that the key doesn't look 'stuck'.

It did take John and I quite a bit of head scratching to arrive at what we think is a good solution.  I don't think we can improve upon it.

BTW, personally I find it quite unnatural to release shift, control or alt first, when using them in conjunction with a main key. You need to press them first, to ensure they count when the main key is seen, and release them after. It's seems natural and correct in any case, don't you think?

Pete

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.