Keys seen when mapping to presets in UI, but not seen by MSFS

[davidinbasel]

Further to my project to control the GPS using keys and buttons, I am trying to map several keys to GPS actions, using FSUIPC's preset options.  I do this separately for a GNS530 (as optionally installed in the A2A Comanche) and the NXi G1000 (as installed in the Asobo C172SP Cargo), using Profiles. My problem is that while the keys I use are trapped by the UI, and successfully associated with the correct presets in a new .INI file (with one possible exception, see below), after closing MSFS and FSUIPC then starting a new session, keydowns/ups are only received by MSFS for two of the seven keys I had mapped.

I will send a FSUIPC.ini.new file to show the result of the mapping. All looks good (to my eyes) except that the key number used for the Clear key above the numpad is "12" which, according to the Advanced User Guide, is the NumPad 5 key (with NumLock Off). Yet the key label shown in the UI for that key is "Clr" which matches with the graphic on the key face and with what is received by the Keyboard utility in Microsoft PowerToys. The other six keys I am using are registered in the UI and in the resulting .INI file with key labels and numbers that match the Advanced User Guide's list, so apart from the oddball 12/Clear/NumPad 5 confusion it does not seem that my German Apple extended keyboard layout is preventing the proper behaviour of the other keys.

Note that there are no conflicts with MSFS key assignments. None of these key are assigned in MSFS.

The log file I will send separately (logging InputEvents, Extra actions as well as Buttons and Keys) shows the result of the test from around 236110.  At that timestamp a VK=111 is received by MSFS, and at 237688 VK=106 is received. No other key strokes are received, despite me cycling through all seven keys (in the order 127, 128, 129, 130, 12, 111, 106).

As an aside (I presume), the log file reports (at the start of the file) numerous duplicates of present names and some incorrect Calcodes for presets. This is new, and suggests I need to fix something. But none of the presets reported as being duplicated or having incorrect Calcodes are presets that I am trying to use. Anyway, my problem is that keystrokes are not being detected, not that presets are not functioning correctly.

I note that I have seen discussion (around December) of keystrokes not being received by MSFS. Initially it was thought to be related to a startup timing sequencing problem, but the last I saw was that John had discovered another issue with the way different components were communicating. I am presuming that Version 7.5.1, which I am using, has the necessary fix?

Another thought I had is that I may not be setting up profiles correctly. This is my first use of profiles, and the first time I have had problems with keystrokes not being received by MSFS. Any connection?

Grateful for any suggestions.

Thanks hugely, David

Edited Friday at 07:50 AM by davidinbasel
Fixed typo in key number in 4th para

[davidinbasel]

I thought I would post the .INI and .log file separately, as both individually exceed a 3.25kB limit on attached files (even when compressed). But I see that using a followup post does not relax that limit. (Why is the limit so constraining?)  How do I post the files?

Cheers, David

[John Dowson]

3 hours ago, davidinbasel said:

I thought I would post the .INI and .log file separately, as both individually exceed a 3.25kB limit on attached files (even when compressed). But I see that using a followup post does not relax that limit. (Why is the limit so constraining?)  How do I post the files?

Upload limits are set pretty low for new users - your limit will increase the more you post. If they are still to large to attached when compressed, you can send them to me using one of the free file transfer services, e.g. https://filetransfer.io/

3 hours ago, davidinbasel said:

As an aside (I presume), the log file reports (at the start of the file) numerous duplicates of present names and some incorrect Calcodes for presets. This is new, and suggests I need to fix something. But none of the presets reported as being duplicated or having incorrect Calcodes are presets that I am trying to use.

Those are just informational messages for MF presets that contain errors and can safely be ignored. These are logged when the MF events.txt file is loaded, and such messages are only logged when you are logging Extras. The incorrect calc. code ones have been reported to MF, but I am still not sure what to do about the duplicates. I can't have duplicate preset names in FSUIPC as I then can't link the name back to the same calc. code, but MF allow this. Most of those duplicate presets are exactly the same, i.e. same preset name and same calc code. But there are some with the same preset name but different calc code, and are meant for different aircraft. I am not sure what to do about sych presets at the moment, and they are currently just not loaded.

3 hours ago, davidinbasel said:

I note that I have seen discussion (around December) of keystrokes not being received by MSFS. Initially it was thought to be related to a startup timing sequencing problem, but the last I saw was that John had discovered another issue with the way different components were communicating. I am presuming that Version 7.5.1, which I am using, has the necessary fix?

Yes, that is an old issue related to timing that has been fixed. And as some of your key assignments are working, it will not be this issue.

3 hours ago, davidinbasel said:

Another thought I had is that I may not be setting up profiles correctly. This is my first use of profiles, and the first time I have had problems with keystrokes not being received by MSFS. Any connection?

How do you know that keystokes are not being received by MSFS? Does FSUIPC see the key strokes, even if the assignment isn't triggered? With logging for Buttons & Keys set, FSUIPC should receive and log all key presses/releases seen by MSFS (and forwarded to FSUIPC). So test again but with the logging console window open (Log->Open Console) and see if the key presses are registered. If the key assignment is in a profile not attached to the loaded aircraft, the assignment won't be triggered but the key press/release will still be logged.

I will take a look at your ini and logs when you can get them to me and will advise further. Note that you don't need logging for Input Events activated for this - turn that off.

[davidinbasel]

Files are here:  https://limewire.com/d/e6e0bce0-bf92-4d70-820b-ab749829c8df#D6OT5IAAqPohu2d1tDvBy66C2KUACryZcDJP07QjdoQ  The log here now without Input Events.

You'll see towards the end of the log that key presses are registered for 2 of the 7 keys. At 294047 I press VK=106. I then press in sequence 127, 128, 129, 130, 12, 111 and 106 again. Only VK=111 and VK=106 are received by MSFS.  So it's not a case of keys being pressed but assignments not triggered -- the key press is not seen by MSFS, even though it was seen by the FSUIPC UI when creating the mapping. 

(Not surprisingly, the Console shows the same behaviour: pressing keys 111 and 106 creates log entries, as expected, but nothing at all happens when pressing 127, 128, 129, 130 or 12.

By the way, I tried again after removing from .INI all the lines created by the UI for these key presses. Same result, except that this time the log shows key presses for 111 and 106 "but not programmed" with no entries for the other keys.

Thanks for looking into this John

[davidinbasel]

Addendum:  I tried again without any profiles defined in the .ini and with key defined only for one preset (the G1000 presets, as it happens, but that's presumably not relevant).  Same result.  So my concern that I was screwing up the construction of profiles and causing this oddball problem thereby seems unfounded.

[John Dowson]

1 hour ago, davidinbasel said:

Files are here:  https://limewire.com/d/e6e0bce0-bf92-4d70-820b-ab749829c8df#D6OT5IAAqPohu2d1tDvBy66C2KUACryZcDJP07QjdoQ  The log here now without Input Events.

The files don't make sense. The ini file still has logging for InputEvents set, but no input events were logged. And the log contains this:

Quote

    44297 19492 [Buttons] now profile-specific:
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44297 19492    90=PA,0,K0,8
    44312 19492    90=PA,0,K0,8
    44312 19492    90=PA,0,K0,8
    44312 19492    90=PA,0,K0,8
    44312 19492    90=PA,0,K0,8
    44312 19492    90=PA,0,K0,8
    44312 19492    90=PA,0,K0,8
    44328 19492    90=PA,0,K0,8

I am not sure why that is logged as there is no such assignment in your ini, and the actual profile-specific buttons are not logged. Maybe the comment with index 90 is causing issues, although it really shouldn't:

Quote

90=;  MFD FMS knob control via rotary (yoke button 1 seen as B,0 by

I will check this here. But I need to see an ini and log that match first - the log you supplied was NOT generated by the ini you supplied. Please always give me the matching files as they are.

1 hour ago, davidinbasel said:

You'll see towards the end of the log that key presses are registered for 2 of the 7 keys. At 294047 I press VK=106. I then press in sequence 127, 128, 129, 130, 12, 111 and 106 again. Only VK=111 and VK=106 are received by MSFS.  So it's not a case of keys being pressed but assignments not triggered -- the key press is not seen by MSFS, even though it was seen by the FSUIPC UI when creating the mapping. 

FSUIPC receives all key presses/releases from MSFS vis SimConnect. If a keypress is not being logged, it is not being seen by FSUIPC.
There does seem to be an issue with the VK12 key - this is mapped to VK_NUMPAD05 in the code but is commented as the Clr key. I will check this and get back to you.
VK keys 127,128,129 & 130 are the function keys F16-F19. These are mapped and requested, so I am not sure why these aren't being received.

I don't have a keyboard with so many function keys, so cannot test this here. If they are not being received, all I can do is report this to Asobo.
Can you see these key presses logged if pressed on their own, i.e. without pressing VK106 (Numpad * key) first? if not, MSFS is not forwarding these key presses/releases to FSUIPC, and this should be reported to Asobo.  If you do see them, then the VK106 assignment is doing something that prevents the following key presses from being received.

I will test a bit more and get back to you.

[John Dowson]

I have checked VKs 127,128,129, 130 and 12 here, and they all seem to be received ok here. I tested by sending these key presses on a button press, and the release and the button release, and FSUIPC sees these key press/releases when I press the button. But this was in MSFS020 - I see you are using MSFS2024 so I will test again there.

Your VK106 assignment is this:

Quote

14=106,8,PAS1000_MFD_ENT_Push,0     -{Num*: Press=Preset Control }-

I am not sure that preset works in MSFS2024. There are new presets for the G1000 in MSFS2024:

Maybe try Ent-Push preset instead? I don't think these new presets are available in the current events.txt file - use the attached instead: events.txt

I will check this again in MSFS2024 and get back to you.

John

 

[John Dowson]

37 minutes ago, John Dowson said:

But this was in MSFS020 - I see you are using MSFS2024 so I will test again there.

I have checked in MSFS2024 and can confirm that VKs 12, 127-130 and others are no longer being received. This is because the valid input event name strings have changed, for example previously F16 was "F16" but is now "VK_F16".

I will go through the new input string names and update these for MSFS2024. I will provide a new version to test maybe over the weekend but possibly early next week.

John

[John Dowson]

1 hour ago, John Dowson said:

I have checked in MSFS2024 and can confirm that VKs 12, 127-130 and others are no longer being received. This is because the valid input event name strings have changed, for example previously F16 was "F16" but is now "VK_F16".

I will go through the new input string names and update these for MSFS2024. I will provide a new version to test maybe over the weekend but possibly early next week.

I have implemented this now, but function keys F13-F24 are still not being received. I will report this to Asobo. VK12 is being received in this version.

So it looks like you can't use F13-F24 at the moment - try assigning to other keys.

John

FSUIPC7.exe

Reported to Asobo here: https://devsupport.flightsimulator.com/t/cannot-receive-function-keys-f13-f22/13023

Edited Friday at 03:04 PM by John Dowson
Reported to Asobo

[davidinbasel]

Thanks for following that up John. As you suggest I'll use keys that MSFS2024 recognises, until ASOBO restores F13...F19.

As for the odd treatment of line 90 in the [Button.aircraft] sections, I don't see what I've done to have it seen by FSUIPC as a command or instruction, rather than a comment line. (The comment is simply a reminder to myself that B,0 in the following lines references button 1 on the Honeycomb Alpha yoke)

As previously, I really appreciate the rapid responses to my questions!

New .INI and a matching (!) .log file attached ... I've now qualified for 4.88MB of attachments, so no need to fiddle with file sharing platforms 🙂

FSUIPC7.ini FSUIPC7.log

[John Dowson]

6 minutes ago, davidinbasel said:

As for the odd treatment of line 90 in the [Button.aircraft] sections, I don't see what I've done to have it seen by FSUIPC as a command or instruction, rather than a comment line. (The comment is simply a reminder to myself that B,0 in the following lines references button 1 on the Honeycomb Alpha yoke)

I don't understand why that is logged (and so many times!) - I have tested with similar comments here and don't see anything like that logged.
I will check further to see if I can reproduce, but if its not causing any issues (i.e. you profile assignments are working as expected and you can see the assignments in the button assignment panel) then I wouldn't worry about this too much.

John

[John Dowson]

By the way, it looks like you have all your key presses assigned with repeats. Most of those, if not all, should be no repeats. You can change these via the UI, but probably easier to just insert an N in front of the VK number, e,g,

Quote

[Keys.G1000 aircraft]
2=127,8,PAS1000_MFD_MENU_Push,0     -{F16: Press=Preset Control }-
4=128,8,PAS1000_MFD_PROC_Push,0     -{F17: Press=Preset Control }-
6=129,8,PAS1000_MFD_FPL_Push,0     -{F18: Press=Preset Control }-
8=130,8,PAS1000_MFD_FMS_Upper_PUSH,0     -{F19: Press=Preset Control }-
10=12,8,PAS1000_MFD_DIRECTTO,0     -{Clr: Press=Preset Control }-
12=111,8,PAS1000_MFD_CLR,0     -{Num/: Press=Preset Control }-
14=106,8,PAS1000_MFD_ENT_Push,0     -{Num*: Press=Preset Control }-

to

Quote

[Keys.G1000 aircraft]
2=N127,8,PAS1000_MFD_MENU_Push,0     -{F16: Press=Preset Control }-
4=N128,8,PAS1000_MFD_PROC_Push,0     -{F17: Press=Preset Control }-
6=N129,8,PAS1000_MFD_FPL_Push,0     -{F18: Press=Preset Control }-
8=N130,8,PAS1000_MFD_FMS_Upper_PUSH,0     -{F19: Press=Preset Control }-
10=N12,8,PAS1000_MFD_DIRECTTO,0     -{Clr: Press=Preset Control }-
12=N111,8,PAS1000_MFD_CLR,0     -{Num/: Press=Preset Control }-
14=N106,8,PAS1000_MFD_ENT_Push,0     -{Num*: Press=Preset Control }-

Do this for all key assignments that don't need a repeat, and when FSUIPC is not running.

[davidinbasel]

I'll do as you suggest and force the non-repeat. Note however that I didn't specify any repeat in the UI when setting up the ,mapping.

[John Dowson]

30 minutes ago, davidinbasel said:

I didn't specify any repeat in the UI when setting up the ,mapping.

I know - repeat on key assignments is the default. You have to manually check the No repeats! checkbox to disable repeats on key assignments.

This is a legacy issue....I should probably make no repeats the default for key assignments, as it is with buttons.