adrem Posted April 24, 2020 Report Posted April 24, 2020 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")
Pete Dowson Posted April 24, 2020 Report Posted April 24, 2020 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
adrem Posted April 24, 2020 Author Report Posted April 24, 2020 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.
Pete Dowson Posted April 24, 2020 Report Posted April 24, 2020 Thanks. Yes, I can repeat this. I'll discuss with John (who's now the FSUIPC developer) about a way of fixing this. We can't promise when a fix will be forthcoming though. Pete 1
John Dowson Posted April 24, 2020 Report Posted April 24, 2020 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
adrem Posted April 24, 2020 Author Report Posted April 24, 2020 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)
Pete Dowson Posted April 24, 2020 Report Posted April 24, 2020 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
adrem Posted April 24, 2020 Author Report Posted April 24, 2020 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
Pete Dowson Posted April 24, 2020 Report Posted April 24, 2020 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
adrem Posted April 25, 2020 Author Report Posted April 25, 2020 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.
Pete Dowson Posted April 25, 2020 Report Posted April 25, 2020 4 hours ago, adrem said: By the way, I've upgraded to FSUIPC6 - in case there will be another dll to test. That's good, though actually I think John decided to update FSUIPC5 as well! 😉 Pete
John Dowson Posted April 28, 2020 Report Posted April 28, 2020 Hi, could you try the following please: FSUIPC6.dllFSUIPC5.dll Thanks, John
adrem Posted April 28, 2020 Author Report Posted April 28, 2020 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.
Pete Dowson Posted April 28, 2020 Report Posted April 28, 2020 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
adrem Posted April 28, 2020 Author Report Posted April 28, 2020 It's not a big problem anyway, no worries, and thanks for your efforts 🙂
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now