John Dowson

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.

All issues with registration are either due to: - not entering the correct details - not having the correct VC++ redistributables installed - anti-virus software blocking the validation - using unicode rather than ascII - trying to use a key for a different version of FSUIPC If you have checked all those (and make sure that you have downloaded and installed the latest VC++ redistributables) and still have issues, please let me know your order number and I will check it here. Do NOT post your key details. John

Please set Debug level logging in the WASM via the FSUIPC_WASM.ini file. Was the FSUIPC_WASM.log file attached when MSFS was still running? If not, the WASM has crashed, but I expect that MSFS was still running... Your log file shows a few presets were triggered and sent to the WASM: But I don't understand these log messages: Not sure why those are logged as that message is only logged when the button assignment panel is open. They are all buttons (3,5,32,34,36,38) on your throttle (1) that have no assignments. Was the assignments window open here? You need to set Debug level logging in the WASM. then test again - keep the logging console window open (Log->Open Console) and add the DontLogThese ini parameter to your [Profile.FENIX A320] section, i.e. and for your [Profile.B737 PMDG] profile: This will prevent excessive logging of those events that are continually seen and filling the log. Then test a few buttons that you have assigned to presets (with the logging console window open), check the button is triggered and the calc. code sent in the FSUIPC7.log file, and if the calc. code was received and applied in the FSUIPC_WASM.log file.

Please see the Installation and Registration guide, section Invalid Key Problems (or the README.txt).

There is an error on the first line of your FSUIPC7.ini fille: Remove those characters - in fact, remove the whole section as the [General] section has been added again further down. Ot correct that and remove the 2nd [General] section - your choice but there should only be one. And those log messages indicate that the button assignment panel was open when you tested, Button logging should look like the following: Button assignments are not triggered when the assignment panel is open, So please correct your ini, set logging for Buttons & Keys and WAPI->Debug and try again, and attach the files again if you still get issues. Also, try testing with the logging console window open (Log->Open Console) and you should see the lines logged in real-time. John

To diagnose issues with presets not working, I need to see 3 files from the same session: - your FSUIPC7.ini file. This shows me the assignments and profiles. Always attach after FSUIPC7 has exited. - your FSUIPC7.log file, with logging for Buttons & Switches, Events and WAPI->Debug level logging activated. This shows me the buttons/keys pressed, any assignments triggered and any calc. code sent to the WASM., Always attach after FSUIPC7 has exited. - your FSUIPC_WASM.log file, with Debug level logging activated. This shows me if the calc. cide has been received by the WASM and applied to the aircraft. Always attach after MSFS has exited. You only attached a log file. This just shows several button presses triggering the PMDG_B737-7_LIGHTS_RUNWAY_BOTH_ON and PMDG_B737-7_LIGHTS_RUNWAY_BOTH_OFF presets: You need to check the FSUIPC_WASM.log to see if they are being applied. If they are being applied, and those presets are working, then the runway lights should have flashed on then off 3 times. Not sure why you are getting a button release before a press. I presume that his is either a switch or sticky button, and it was already in the on/pressed state when FSUIPC7 was started.

No - why would you want to do that? I am pretty sure that is not in the correct format. As I said, there are already offsets allocated to PM. Forget about the myOffsets.txt file. What is your actual issue? If the problem is with your CPFlight device, check this support forum for similar issues. John

Do you know what the myOffsets.txt file is used for? This is NOT installed by the FSUIPC, and is only present when created or installed by the user. If its not there, you are not using one. This file is for a user to add simvars to free/spare FSUIPC offsets. Not sure what you mean by this. The Project Magenta offset areas are: 0x04E0 - 0x0537 0x5400 - 0x5FFF What offsets hold is defined in the Offset Status document. John

Can you try setting DirectAxesToCalibs=Yes to see if that helps. Otherwise please try the attached version, where I have switched to using the KEY_AXIS_ELEV_TRIM_SET control when writing to offset 0x0BC0 instead of KEY_ELEVATOR_TRIM_SET, as well as also allowing the KEY_ELEVATOR_TRIM_SET control to be calibrated. If neither of those works then I'm afraid it won't be possible to calibrate the elevator trim for your device. FSUIPC7.exe