John Dowson

This could be due to the aircraft title received does not contain the string 'pmdg' and so the additional threads to populate the PMDG-specific offsets are not started. This has been reported before and I have provided a beta version that also checks the folder name for the 'pmdg' string which should solve this issue. So first try the beta version posted here: And if that is not working, show me / attach your FSUIPC7.log file generated when using the B77F. John

If you have issues with presets not loading, please show me both your FSUIPC7.ini and FSUIPC7.log files, the latter with logging for Buttons & Keys activated and showing a button press assignment that is in the profile that should be loaded but is not working.

Just checked and there is an SU3 beta release available, but your log shows that you are using the latest official release which is SU2 - unless they have forgotten to update the version number in the SU3 beta release.

There is no SUU3, as far as I know, and your log file shows that you are using the latest release of MSFS2024, which is SU2: But your log shows that the lua scripts were started: and also terminated: I do not know if any other lua scriptys should have been started as you did not attach your FSUIPC7.ini file. Please show me that, together with your log file, if you think they are not being started. But your log file shows the WASM module is working just fine - you even listed the available lvars. So I do not undertand what your issue is. Why do you think the lua scripts are not being started? John

First, to understand profiles you should read the section User profiles for all control settings, on page 22 of the FSUIPC7 User manual/guide. Profiles are enabled automatically. Having profiles in separate files is generally only used if you have many profiles and these are quite large, as it separates them into different files. You do not have to use this feature when using profiles if you don't want to, but if you have already switched to profiles-in-separate files then thats ok. The changes you made will only be saved in the profile (and in the profile-specific file) if you clicked the profile-specific checkbox (in the assignments panel) when adding the assignment, and when you have added the currently loaded aircraft to a profile (or have created a new profile for the aircraft). Check your FSUIPC7.ini - they will have been added there to the general sections if you did not specify profile-specific. Note that when you create a new profile for an aircraft, or add an aircraft to an existing profile, it is a good idea to shorten the aircraft name (listed under the [Profile.xxx] section of your FSUIPC7.ini file) to a substring that matches all variants of that aircraft. This will prevent issues with the profile not being loaded when you use a new variant. Alternatively, you can set the UseAirLocForProfiles in parameter to Yes to perform matching on the aircraft folder name instead, but if you want to use this then do it now before adding the aircraft name/title to the profile. Again, see that section in the User manual for more details. John

@Claude Decarie I have just seen this post in Paul's .Net dll support forum and have moved it to the main support forum (for FSUIPC4/5/6). Did you manage to successfully create a profile for the C172? It should be straightforward - you just need to create a specific profile for the C172, allow the current axes assignments to be imported and then modify these axis assignments in the profile for throttle, brakes and rudder to use the controls used by the C172. You can then also re-map any buttons/switches you need by making these profile-specific. Please see the section on using profiles in the FSUIPC User guide. If you have any issues or problems, please show me / attach your current FSUIPC6.ini and FSUIPC6.log file (generated when using the C172) and I can take a look. John

Ah yes, thats a good idea - I hadn't notice that you could do this. I have now also changed this, for both the general controls (to 'Keyboard 2020 Transversal' and the Airplanes controls (to 'Keyboard 2020 Planes') and this works well for my assignments. Once changing to use the 2020 keyboard assignments, the ctl+shift+n combination should again be mapped to switch to the fixed camera views. In MSFS2020, these fixed camera views seem to be the same as the instrument views, via the ctrl+n keyboard assignment. And these seem to be the same in MSFS2024 (when using the MSFS2020 keyboard mapping), so I don't understand why these are not working for you in MSFS2024.

Did you manage to find anything for this? Just noticed this post on the MF discord server: with response: But that is for the MSFS2020 version. If those lvars exist in MSFS2024, you could try them. Also, check the aircrafts documentation - look at the section Primary Control Variables which seems to list all the lvars available, e.g.: John

Ok, but what changed? Your upload limit will increase as you post more - it is set very low for new users. However, be aware that there is no check-box next to the AutoSave and GPSOut options - these menu entries should open a separate panel (indicated by the ellipsis (three dots/full-stops, - ...) after the menu item name. Do you not see those panels that configure GPSOut and AutoSave? See the User guide for a full description.

Ok, so you can see the values change in the elevator trim calibration panel? That is interesting, but I wonder what, if any, macro it is using. I would expect it to use PitchTrim, but I can only see PitchTrimMust logged, and only once. I am not sure what that macro should be doing (if provided), so I don't really understand how itis controlling the pitch/elevator trim. Maybe setting LogIPCwrites to Yes in the PFC ini would help. 128 would be the delta adjustment, i.e. it won't move for smaller adjustments. Changing this won't affect the speed of the trim adjustments, just the steps/deltas (i.e. the size of the increment/decrement. But that is the throttle calibration. not the elevator trim calibration. If the elevator trim is being calibrated, one way of slowing down the trim movement is to extend the upper range. So, if this is my elevator trim calibration: ElevatorTrim=-16383,0,0,16254/16 I would extend the upper range by increasing the upper threshold, e.g ElevatorTrim=-16383,0,0,20254/16 (or extend in both directions, and maybe add a null-zone for zero trim, i.e. ElevatorTrim=-20383,-512,512,20254/16 ) However, the problem with doing this is that you would lose the full range, and it won't be possible to get to full trim (as you axis would need to send a value of 20254 to do this in the example above). Does the TrimRange setting have much affect? I see this is now set very high (1023), whereas before you had it set very low (16).

I cannot see how this can happen as its the same version of FSUIPC for both MSFS2020 and MSFS2024. Are you using the same installation for MSFS2020 and MSFS2024, or separate installations? If you are using the same installation, then the same GPSOut settings will be used for each version. i.e. it it is enabled for MSFS2020, it will be enabled in MSFS2024. The autosave sections are distinct for MSFS2020 and MSFS2024, so you can have different settings in each simulator, with the MSFS2020 settings saved under [AutoSave], and the MSFS2024 settings saved under [AutoSave24]. Do you have an [AutoSave24] section the FSUIPC7.ini file used for MSFS2024? Note that FSUIPC7 must be connected to MSFS so that it knows the version being used before the AutoSave settings can be adjusted. I do not understand why you cannot tick the options though. What do you mean by " no hock shown in front of these Options"? Do you mean no check-box? Could you show me a screenshot of this please, and also include/attach your FSUIPC7.ini and FSUIPC7.log files.

Your installation log indicates that an steam version of MSFS2024 was detected: The installer would have therefore created the EXE.xml in the location used by Steam, not the MS Store version. It will probably also have installed the WASM in the wrong Community folder. To resolve this, you should remove (or rename) the steam UserCfg.opt file (which determines a steam install) from the following location:: C:\Users\Andy\AppData\Roaming\Microsoft Flight Simulator 2024\UserCfg.opt Then re-install and your MS Store version of MSFS2024 should be detected and the EXE.xml created in the correct place. John

I didn't know that could be disabled...! Can you re-enable it and test again then?

In steam, you can verify the integrity of the game files of the MSFS2024 installation. Can you do this with the MS Store version? If so, try that.

Sorry but I have no idea why MSFS2024 is not starting the WASM. Are all your other WASMS being loaded? Did you reboot? Try temporarily moving everything out of your MSFS2024 Community folder except for the FSUIPC WASM module - does it then load/start? You can try reporting this on the Asobo forums as there is nothing I can do or advise if MSFS2024 is not starting the WASM.