John Dowson

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.

Ah, sorry - didn't notice that was from another user.

So the WASM is being registered but not mounted and initialized. I have no idea why this is. It must have ran at some point as you said: So something must have changed. Try re-installing FSUIPC7 (and the WASM).

Then it isn't running. I have no idea why this is. Check the logging console (Debug-Console) and search for fsuipc and see what messages you see.

I have looked into this further and it looks like the default keys to change the views have changed. By default: - quickview left/right are now on shift + h/f and no default for up/down (MSFS2020 uses LCtrl + Up/Down/Left/Right) - look on shift + k/l/j/i (MSFS2020 uses LShift + Up/Down/Left/Right) - translate on shift + s/w/a/d (MSFS2020 uses Up/Down/Left/Right) So, to use the same keys as MSFS2020, you would need to map the keyboard controls to use the same keys as MSFS2020. Alternatively, you would need a separate installation for MSFS2024 and map the hat buttons to the default keys to control the views in MSFS2024. Using the view controls directly still doesn't work.

View control has always been difficult in MSFS2020/2024 as the default view controls don't seem to work. I have my hat switches assigned to the default keystrokes to control the view (pan, eyepont and quick-view) which works ok in MSFS2020, but in MSFS2024 they only seem to control the panning and not the eyepoint or quick view controls. No idea why. I will look into this further in MSFS2024 when I get a chance. John

This image shows the WASM running (note status is READY)::

You have to enable devmode in MSFS in the Advanced options, then use the Debug->Display WASM debug window, then select the FSUIPC WASM lvar module and then look in the Module section tab. That is because FSUIPC isn't receiving anything from the WASM. You said that your lua scripts were started earlier, so this means the WASM was running and working at some point. I have no idea why it is no longer working. Try rebooting and try again.

As I said, your previous screenshot showed those files...if the log file is not now being created, then the WASM isn't running. Check in MSFS if the WASM is actually running.

As I said, your previous screenshots showed the log files. You are looking in the wrong place - for MS store installs in MSFS2024, it should be under AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\WASM\MSFS2020\fsuipc-lvarmodule\work as I said....please see the documentation that I previously referenced... Yes, of course. But I have steam installations, not MS Store.

I can't tell anything by looking at your files as I have no idea when you tried to operate the trim/ When you operate the elevator trim, what macro name do you see logged in the PFChid64.log file? What controls do you see logged in the FSUIPC6.log file? Note that you need to activate logging for Events (non-axis controls), which it looks like you haven't done. Also, open the logging console and you will be able to see what is logged when you activate the trim. That is the calibration used when the elevator trim is assigned to an axis in FSUIPC and is probably not used. Those values look very strange anyway (and the format is wrong) so I would remove that. You would normally calibrate the elevator trim on page 6 of the calibration screens and not modify the ini entry directly. But this only applies to the elevator trim axis. Does your device have a trim wheel or buttons/a rocker? If a wheel, does this use buttons or is it an axis?

There must be - that location was for steam installs - for MS Store installs it should be under: AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\WASM\MSFS2020\fsuipc-lvarmodule\work In fact, your screenshots show you have one in that location. Screenshot (2077).png shows the log file for MSFS2024. and Screenshot (2076).png shows the log files for both 2020 and 2024. There won't be an FSUIPC_WASM.ini file there by default - you have to copy this across from the Community folder. See the section WASM module ini file and parameters on page 51 of the Advanced User guide for details on file locations. You can also set Debug level logging there. Note that that file gets overwritten when you re-install/update, which is why it is better to change the one under your AppData folder, which also takes precedence (when provided). Ok, then no need to send/show me the WASM log file then. Keep Debug level logging activated, and the next time they don't start show me the WASM log file. John