John Dowson

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: 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: 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. 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.

You can set a different ButtonRepeat value in profiles, so id you want to use a different value, set-up a separate profile for the aircraft and specify it there. Then this would indicate that the control being used is triggering a press and release, so you should not use that control on repeat. Why do you think this needs to be on repeat? If you want the VC button held in when you press the button, and released when you release the button, you will need to check the aircrfat to see if it has any controls to support that, and assign the press to thebutton press and the release to the button release (and no repeats!). What aircraft/function is giving this issue? If you can attach your FSUIPC7.ini I can take a look. John

It really isn't that complicated. You can also use ling to determine the (custom) control/event to be used for any butoon/switch/knob. Set logging for Events and open the logging console, and see what event is logged when you operate the switch in the UI/VC. For PMDG aircraft, this will use a lot of ROTOR_BRAKE controls with the parameter indicating the function and operation. The use of the ROTOR BRAKE control for PMDG aircraft is described in this FAQ entry:

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/ 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. 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. 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.

Ok, that is interesting - so the Community folder is in the same location? Then this would imply that the issues were caused due to some access/UAC permissions on the original folder. Did you create the original folder or MSFS? Anyway, glad this is now fixed. Cheers, John

As I said, I didn't think that would help, but you should try moving the Community folder of your MSFS2020 installation. FSUIPC7 is working fine in both MSFS2020 and MSFS2024, it is the WASM in MSFS2020 that is causing the issues. Therefore relocating this to a different folder may help. Yes, move the Community folder in MSFS2020. You should uninstall FSUIPC7 before doing this and re-install afterwards. Try using D:\MSFS2020\Community first, and if you still get issues try C:\MSFS2020\Community (or any folder outside of a windows folder).

Note that the axis and button assignments dialogs work differently when it comes to profiles. When an airraft is using a profile for axes, the profile will always be shown in the axes assignment dialog box and the profile-specific checkbox is checked. For button assignments, you have to manually check the profile-specific checkbox to see the profile-specific assignments, as the general button assignments also apply unless overwritten. If you think the profile-specific button assignments are not working, please also attach a log showing this, with logging for Buttons & Switches activated. You should also update your profile-specific aircraft names to use substrings to catch more variants. So, for example, change: to and to

It is under the Assignments menu. If you do not see that menu, you are running an unregistered version. If you have a license, you need to register it at the end of the installation process, If you don't have a license but would like to try the registered facilities, there is a trial license available in a post at the top of this forum. There is no 'specific name; for the PMDG 737 series. What you probably saw was the the name of a profile that someone was using for their PMDG 737 assignments.. For assignments to PMDG buttons and switches, see the FAQ section on how to use the PMDG custom controls:

There are no issues in your installation log. However, I do find this strange: You have moved the MSFS2020 Community folder, and have moved it under your User folder but on your D drive. I don't understand how you can have two User folders. Maybe try moving the Community folder back to its default location, or at least move it out of your User folder (e.g. D:\Community). Also, FSUIPC7 is installed under a Program Files folder on your D drive. I am not sure if this is a windows designated Program Files folder, or just a folder you created with the same name. It is always better to not install FSUIPC7 in any windows-designated folders as this can cause issues. However, as it seems to be working ok for MSFS2024, you can probably leave this and just try moving the Community folder. Better to uninstall FSUIPC7 before doing this and re-install again afterwards. John

Then that would indicate that the WASM had crashed. However, this is not the known issue in the WASM as it did not occur when scanning for lvars. And in the last set of logs you attached, no button presses (that have assignments) were detected. But that doesn't make sense. Your log file shows that the WASM was detected and the WAPI enabled: However, it does look like the lvars were received but not the initial lvar values, which maybe why the WASM menu is not active, but it should certainly be there. So it does look like you may be getting a WASM crash, but I have no idea what could be causing this. You could try setting Trace level logging on the WASM. This will generate a huge FSUIPC_WASN.log file. That is very strange - there should be no access issues to the community folder.... Have you moved the Community folder from its default location? Is the path correctly specified in your UserCfg.opt file (InstalledPackagesPath)? That is very suspicious and could be causing these strange issues. The WASM module should be installed in MSFS2020 by the installer. If it is not installing correctly, please show me your InstallFSUIPC7.log file. But your initial issue was that the WASM module wasn't installed, and I thought you had corrected this. You have also attached WASM log files, so I don't understand why you think this is no longer installed or running,,, It is hard for me to make any sense of all this. Maybe you should uninstall and re-install MSFS2020. Uninstall FSUIPC7 for MSFS2020 first, and re-install again after you have re-installed MSFS and ran it at least once.

But why did you delete this file? The installer is detecting a UserCfg.opt file in the default location for a steam install, here: that is why it thinks you have a steam install. Delete or rename that file.

With the rest of the FSUIPC documentation, installed under your Documents folder in a folder named FSUIPC7. There should also be a link to this folder under your FSUIPC7 installation folder.

These are the support forums for FSUIPC. For Feel There support, see https://feelthere.com/contact-us-support/ John

Check to see if the WASM is crashing - see

Yes - read this FAQ entry:

@hammertime And?

@Brian McCrary Can you please test that version and respond otherwise I will reverse these changes. John

Please show me / attach your InstallFSUIPC7.log file...

Can you please show me / attach your InstallFSUIPC7.log file. Where did you delete this from, i.e. which folder? Did you ever have a steam install of MSFS2020 or MSFS2024?

...for the C172 in MSFS2024, there are these presets available: These are new presets and are not present in the current events.txt file - download the attached and copy to your FSUIPC7 installation folder. events.txt John

Which C172? The following presets exist for the classic: and for the standard version: They are for MSFS2020 but should also work in MSFS2024 - have you tried them?

Is an UninstallFSUIPC7.log file generated? If so, please attach it here. Can you also attach the EXE.xml file for MSFS2024. Could you also please attach a screenshot of when it hangs. That also indicates an issue in your EXE,xml. See

Why not just copy the FSUIPC7.ini file (as well as the FSUIPC7.key file) to the new PC? The GUIDs of your devices / controllers may change, and if so you will need to edit the [JoyNames] section to map the new GUIDs to the existing device letters. If you copy the files to your new PC, run FSUIPC7 once then exit, and attach your FSUIPC7.ini file here, I can advise of any changes needed. John

This indicates that the aircraft you have loaded is already a match for the FSR500 profile. if you want to remove the aircraft from that profile and create a new one, then you need to manually edit your FSUIPC7.ini file and remove the aircraft (substring) from the [Profile.FSR500] section. Better to exit FSUIPC7 before doing this.

You will have separate WASM installations for each version. Debug level logging was active in the WASM log you attached. If you want assistance, can you PLEASE answer my questions. I cannot help you if you do not answer my questions or follow my advice. You are giving me no information that I can work with at the moment. Did you attach that FSUIPC_WASM log file AFTER exiting MSFS, or was MSFS still running? Please answer this question, it is VERY important to my understanding of this issue. But why? And no, it sheds no light whatsoever. PLEASE follow my instructions. I need to see short log files showing your issue, not huge log files that time to go through looking for errors. Did you actually have any issues during that flight, and if so, what were they? I see no button presses logged, and no presets called. Just load an aircraft, test a few of your assignments, then exit. You do NOT need to complete a flight, you don't even need to take off... Did you try what I suggested? You need to test with the logging window open and see what is logged when you press a button. And remove excessive logging by using the DontLogThese ini parameter.