ipcPARAM Bug -- Maybe?

[ark1320]

I've been having some really strange behavior with a Lau script  in FSUIPC7 that I have used for a long time successfully in FSX and P3D. The script is supposed to call different functions based on ipcPARAM values, but is not  working correctly. So I finally decided to write a tiny ipcPARAM test script to see if I could figure out what is going on. Here's the script which simply reports the ipcPARAM  value if finds.

-- FSUIPCParamTest.Lua  Test if ipcPARAM value is being read correctly
    ipc.writeSTR(0x3380, " ipcPARAM = "..ipcPARAM);             
    ipc.writeSW(0x32FA, 2);
    ipc.sleep (2000)
    return

The relevant portion of the FSUIPC7 ini file looks like this:

485=N96,8,L102:R,0     -{Num0: Press=Lua FSUIPC7ParamTest }-
487=110,8,L102:R,10     -{Num.: Press=Lua FSUIPC7ParamTest }-
488=N97,8,L102:R,1     -{Num1: Press=Lua FSUIPC7ParamTest }-
489=N98,8,L102:R,2     -{Num2: Press=Lua FSUIPC7ParamTest }-
492=N99,8,L102:R,3     -{Num3: Press=Lua FSUIPC7ParamTest }-
493=N100,8,L102:R,4     -{Num4: Press=Lua FSUIPC7ParamTest }-
496=N101,8,L102:R,5     -{Num5: Press=Lua FSUIPC7ParamTest }-
498=N102,8,L102:R,6     -{Num6: Press=Lua FSUIPC7ParamTest }-
500=N103,8,L102:R,7     -{Num7: Press=Lua FSUIPC7ParamTest }-
502=N104,8,L102:R,8     -{Num8: Press=Lua FSUIPC7ParamTest }-
504=N105,8,L102:R,9     -{Num9: Press=Lua FSUIPC7ParamTest }-
 

This script should simply display the numbers 0 to 10 based on pushing the Numpad digits 0 to 9 and the period key. But when I run the script, nothing happens when I push the digit keys or period key on the numpad (which I checked is on), but if I push at the A key, ipcPARAM = 1 is displayed, if I push the B key, ipcPARAM = 2 is displayed, and so on with the I key displaying ipcPARAM = 9.

Note you may have to push a key a few times to 'start' the display, as shown below for when the A key is pushed:

This happens even if I remove all other FSUIPC7 Lua scripts. I know there are major problems with the SimConnect text display functions, but that aside, I don't understand why pushing the letter keys A, B, ....I triggers the script in the first place, but pushing the Numpad digits does nothing? Can SimConnect problems distort the value of ipcPARAM being 'read' by the script?

Thanks for any ideas,

Al 

 

[Pete Dowson]

4 hours ago, ark1320 said:

This happens even if I remove all other FSUIPC7 Lua scripts. I know there are major problems with the SimConnect text display functions, but that aside, I don't understand why pushing the letter keys A, B, ....I triggers the script in the first place, but pushing the Numpad digits does nothing? Can SimConnect problems distort the value of ipcPARAM being 'read' by the script?

Please replace the 

ipc.writeSTR(0x3380, " ipcPARAM = "..ipcPARAM);             
ipc.writeSW(0x32FA, 2);

lines with

ipc.log(" ipcPARAM = "..ipcPARAM)

and test again. We can't really deal with anything attempting to use the really non-working text display facilities.

What is the "return" for at the end? What are you returning from? Is this a partial script? Why the 2 second delay?

Pete

 

[ark1320]

2 hours ago, Pete Dowson said:

What is the "return" for at the end? What are you returning from? Is this a partial script? Why the 2 second delay?

Hi Pete,

I put "return" at the end of scripts -- I gather from your comment I should not do that. The code shown was the complete script -- not a partial script.

I had the 2 sec delay so the display would not immediately disappear before I could see it because the script ended.

The complete FSUIPC7ParamTest.lua script was changed as you asked to this single line: ipc.log(" ipcPARAM = "..ipcPARAM)

I started the sim and then FSUIPC7.exe, and pushed the A, B, C, D, and E keys in order with about a second or so between key strokes. I did not try the Numpad digit keys with this test, but then repeated the test below with those keys. The FSUIPC7.ini file is as I originally posted above. If I open the FSUIPC7 Keys window and push the A, B, C, D, and E keys, no assignments are shown for any of these keys.

Attached are the FSUIPC7.log and FSUIPC7ParamTest.log files. I'll be glad to provide whatever else you need. Thanks for the help.

Al

 

FSUIPC7ParamTest.log FSUIPC7.log

[ark1320]

I repeated the above test this time pushing the Numpad 1, 2, 3, 4 and 5 keys in succession. There was no FSUIPC7ParamTest.log file produced. The FSUIPC7.log is attached. When I checked the FSUIPC7.Key assignment window, the Numpad digits were assigned as shown below for the 1 key.

Al

 

FSUIPC7.log

[Pete Dowson]

9 hours ago, ark1320 said:

I put "return" at the end of scripts -- I gather from your comment I should not do that.

"return" means "exist from the function". But you haven't declared a function. 

The script will end naturally when the last line is passed. your "return" does no harm there, it was just misleading, making it look like the script was partial.

16 hours ago, ark1320 said:

This happens even if I remove all other FSUIPC7 Lua scripts. I know there are major problems with the SimConnect text display functions, but that aside, I don't understand why pushing the letter keys A, B, ....I triggers the script in the first place, but pushing the Numpad digits does nothing?

The FSUIPC log you provide shows multiple key presses repeating very fast, alternating A 1 A 1 A 1 ...before FSUIPC is actually fully initialised ("Starting everything now", line 15093. I suggest you touch nothing until everything is loaded and 'ready to fly'.

Then the sequence is many repeats of B 2, then C 3 and so on. I really don't know how you are making the keyboard inputs look like this.

The problem with keys repeating when you are assigning them to read a Lua file, compile it, run it and terminate it is that it just can't be done at the keyboard repeat rate of typical 15-20 per sec. You MUST check no repeats.  I suspect that quite often the Lua pli=u-in is being killed before it even does anything!

Also, you checked the Log option for separate logging of the Lua results. That spoils the whole point of having the log output -- to show the relationship between you pressing keys and what the plug-in does. Please UNCHECK that separate log option! Then the Lua log lines will go into the main log showing the relationship with the key presses. AND uncheck Lua log/trace options. you don't need that either -- the whole point of adding the ipc.log line was to get a single line each time an ipcPARAM was seen.

Pete

 

 

[ark1320]

2 hours ago, Pete Dowson said:

Then the sequence is many repeats of B 2, then C 3 and so on. I really don't know how you are making the keyboard inputs look like this.

The problem with keys repeating when you are assigning them to read a Lua file, compile it, run it and terminate it is that it just can't be done at the keyboard repeat rate of typical 15-20 per sec. You MUST check no repeats.  I suspect that quite often the Lua pli=u-in is being killed before it even does anything!

I have had No repeats checked all along as you can see from the example Key Presses window above and the FSUIPC7 ini file, but just for the Numpad digit keys. The a, b, c, d, and e keys are not programmed in FSUIPC7 for anything, so no way to check the No repeats box.

Repeated the logging experiment with just Buttons and Keys selected for logging. I hope that is what you want. I pushed the a, b, c, d and e keys in sequence with a few seconds between each. I tried to be 'quick' on and off each key push. I also waited until the plane was sitting on the runway for a short while before inputting any keys.

I will repeat this experiment below but use the Numpad input key sequence 1, 2, 3, 4, and 5 to get a new log file.

Al

 

 

FSUIPC7.log

[ark1320]

Here is the log file for the input sequence 1, 2, 3, 4, 5.

Al

FSUIPC7.log

[John Dowson]

That log file shows nothing, not even any key presses, although you have Button & key logging activated. Are you sure that either MSFS or FSUIPC7 has got the focus during your tests?

Can you also update to the latest FSUIPC7 build, with date 08/09/2020. Thanks.

[John Dowson]

@ark1320 I've just tested the numeric keypad input and it looks like FSUIPC is not receiving the input events for these keys. Not sure yet if this is an MSFS or FSUIPC problem, I'll take a look. In the mean time, I suggest you assign to other keys.

John

[ark1320]

26 minutes ago, John Dowson said:

@ark1320 I've just tested the numeric keypad input and it looks like FSUIPC is not receiving the input events for these keys. Not sure yet if this is an MSFS or FSUIPC problem, I'll take a look. In the mean time, I suggest you assign to other keys.

John

John,

Thanks for checking that -- explains a lot!  Note that FSUIPC7 does see the Numpad key inputs at least when the Key Presses tab is used to program those keys in FSUIPC7.

The other strange thing is that the letter keys a, b, c, d ......i are triggering the one line logging lua script showing ipcPARAM values 1 to 9 respectively even though those keys are NOT programmed in FSUIPC7. The FSUIPC7.ini file is still just:

[Keys]
485=N96,8,L102:R,0     -{Num0: Press=Lua FSUIPC7ParamTest }-
487=N110,8,L102:R,10     -{Num.: Press=Lua FSUIPC7ParamTest }-
488=N97,8,L102:R,1     -{Num1: Press=Lua FSUIPC7ParamTest }-
489=N98,8,L102:R,2     -{Num2: Press=Lua FSUIPC7ParamTest }-
492=N99,8,L102:R,3     -{Num3: Press=Lua FSUIPC7ParamTest }-
493=N100,8,L102:R,4     -{Num4: Press=Lua FSUIPC7ParamTest }-
496=N101,8,L102:R,5     -{Num5: Press=Lua FSUIPC7ParamTest }-
498=N102,8,L102:R,6     -{Num6: Press=Lua FSUIPC7ParamTest }-
500=N103,8,L102:R,7     -{Num7: Press=Lua FSUIPC7ParamTest }-
502=N104,8,L102:R,8     -{Num8: Press=Lua FSUIPC7ParamTest }-
504=N105,8,L102:R,9     -{Num9: Press=Lua FSUIPC7ParamTest }-

Attached is the log file for inputs a,b,c,d,e.

Al

FSUIPC7.log

[John Dowson]

I'm checking this and will get back to you at some point, but it may take a while.

[ark1320]

5 minutes ago, John Dowson said:

I'm checking this and will get back to you at some point, but it may take a while.

John,

Thank you -- very much appreciated!  Note I updated my last post above in case you didn't see the update.

Al

[John Dowson]

1 hour ago, ark1320 said:

Note I updated my last post above in case you didn't see the update.

What update? If you edit a previous post, you need to check the 'show the message has been updated' checkbox and specify the reason in the provided text entry field, otherwise it is not noticed.

 

[ark1320]

 

27 minutes ago, John Dowson said:

What update? If you edit a previous post, you need to check the 'show the message has been updated' checkbox and specify the reason in the provided text entry field, otherwise it is not noticed.

 

Ok, I understand, sorry. All above is correct. Had just wanted to point out  that if I understand the log file correctly the letter keys seem to be triggering the Lua script although not programmed to do so in the FSUIPC7 ini file.

[John Dowson]

4 minutes ago, ark1320 said:

the letter keys seem to be triggering the Lua script although not programmed to do so in the FSUIPC7 ini file

There looks to be a problem with the request for keyboard input which I am currently investigating. The problem seems to be with the mapping from the MSFS defined key input strings and the MS VK codes. Looks like I misunderstood this when I implemented, so I'm checking now and will provide an update once done.

 

[ark1320]

On 9/9/2020 at 7:43 AM, John Dowson said:

There looks to be a problem with the request for keyboard input which I am currently investigating. The problem seems to be with the mapping from the MSFS defined key input strings and the MS VK codes.

I temporarily modified one of my Lua scripts to avoid using the Numpad keys and also a few of the special keys directly above the Numpad, and the script works as expected by correctly calling functions based on the ipcPARAM values associated with particular keys.  So I expect all my other scripts that use ipcPARAM will work once FSUIPC7 is updated. 

Thanks for figuring out the Numpad keys input problem,

Al

[John Dowson]

A new version has been released that contains some changes to how key presses are handled. Unfortunately the numpad 0-9 keys are still not recognised in FSUIPC7 when MSF has the focus - SimConnect is not passing these through to FSUIPC7 although they are requested. I will report this to Asobo.

[ark1320]

13 hours ago, John Dowson said:

A new version has been released that contains some changes to how key presses are handled. Unfortunately the numpad 0-9 keys are still not recognised in FSUIPC7 when MSF has the focus - SimConnect is not passing these through to FSUIPC7 although they are requested. I will report this to Asobo.

I see, thanks for letting Asobo know. Sure hope they fix this soon.

Al

[ark1320]

On 9/14/2020 at 2:26 AM, John Dowson said:

Unfortunately the numpad 0-9 keys are still not recognised in FSUIPC7 when MSF has the focus - SimConnect is not passing these through to FSUIPC7 although they are requested. I will report this to Asobo.

Hi John,

Any response from Asobo on this -- did they at least acknowledge the problem so it can be fixed? 

I was surprised to see that when FSUIPC7 has the focus and the scripts are run using the Numpad to enter values, the G1000 in the sim is in fact updated wrt to Nav and Com frequencies, transponder code, altitude preselect, heading bug and course, even though the sim doesn't have the focus. As before, however, the Numpad entries are still trapped and not getting passed through Simconnect if the sim has the focus.

Al

[John Dowson]

27 minutes ago, ark1320 said:

Any response from Asobo on this -- did they at least acknowledge the problem so it can be fixed? 

No response that I'm aware of, but its difficult to track these things - or at least I have not found a way. I don't seem many responses from Asobo on the forums, and all I get when I raise a zendesk ticket is, eventually, a 'thank you for your feedback message' saying that it has been submitted. Checking the status of these, they all say 'Solved' but I don't think this means anything - they have that status as soon as they are raised! I'm not sure I included the numpad keys in my initial zendesk bug, I'll check and add if not.

34 minutes ago, ark1320 said:

I was surprised to see that when FSUIPC7 has the focus and the scripts are run using the Numpad to enter values, the G1000 in the sim is in fact updated wrt to Nav and Com frequencies, transponder code, altitude preselect, heading bug and course, even though the sim doesn't have the focus. As before, however, the Numpad entries are still trapped and not getting passed through Simconnect if the sim has the focus.

FSUIPC7 is trapping them when it has focus, and acting on them if assigned in FSUIPC7. If not, it forwards the keypresses to the sim. The problem is when the sim has focus -  its not forwarding certain keypresses (including the numpad keys) via SimConnect evn though requested.

John

[John Dowson]

I've just done some more tests and I think this is an FSUIPC issue.There seems to be a discrepancy between the vk codes between MSFS and FSUIPC. I'll investigate more tomorrow and let you know.

[John Dowson]

It seems that MSFS only sends these keys when numlock is off, rather than on. And when numlock is off, FSUIPC sees these keys as Ins (0), End (1), Down (2),  PgDn (3),  Left (4), Clr (5), Right (6),  Home (7), Up (8). PgUp (9).

So, to have these keys working, try with Num-Lock off, and assign in FSUIPC to those keyboard input strings.

EDIT: I also have a non-standard (ie. not windows specific) keyboard. I'll try and dig out another keyboard tomorrow and test with that as well.

[ark1320]

22 minutes ago, John Dowson said:

It seems that MSFS only sends these keys when numlock is off, rather than on. And when numlock is off, FSUIPC sees these keys as Ins (0), End (1), Down (2),  PgDn (3),  Left (4), Clr (5), Right (6),  Home (7), Up (8). PgUp (9).

So, to have these keys working, try with Num-Lock off, and assign in FSUIPC to those keyboard input strings.

EDIT: I also have a non-standard (ie. not windows specific) keyboard. I'll try and dig out another keyboard tomorrow and test with that as well.

Thanks John, sure hope the Numpad problem can be figured out. The non-numerical 'versions' of the numpad keys already are well used in MSFS.

Al

[ark1320]

40 minutes ago, John Dowson said:

I've just done some more tests and I think this is an FSUIPC issue.There seems to be a discrepancy between the vk codes between MSFS and FSUIPC. I'll investigate more tomorrow and let you know.

Thanks -- much appreciated!

Al

[ark1320]

43 minutes ago, John Dowson said:

EDIT: I also have a non-standard (ie. not windows specific) keyboard. I'll try and dig out another keyboard tomorrow and test with that as well.

John,

Attached a little app the shows the keycode when a key is pushed, perhaps it might be of use to you.

Al

KeyCodes3.zip