John Dowson

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

I just tried MSFS2024 here and it seems ok, so I will need to see your FSUIPC_WASM.log for MSFS2024. Should be located under: AppData\Roaming\Microsoft Flight Simulator 2024\WASM\MSFS2020\fsuipc-lvar-module\work You can set Debug level logging in the FSUIPC_WASM.ini file in the same location. John

This may be related to the recent SU2 update of MSFS2024. I will check this here....

Your log shows that the lua scripts were not started because the lvar/hvar list was not received from the WASM. I am not sure why this happened and will need to see your FSUIPC_WASM.log file, generated with Debug level logging activated in the WASM. This could be due to either the WASM crashing, or a change in the camera (or other) events that prevent the WASM for scanning and sending the lvars. Can you activate Debug level logging in the WASM (via the FSUIPC_WASM.ini file) and also show me that file for MSFS2024. I will also check this here tomorrow. Your logs also show some reconnection attempts at start-up for both MSFS2020 and MSFS2024. This is because your ini parameter DetectToConnectDelayAuto is set to low (at 30 seconds). You should change this value to 90. John

Note also that there were no profile-specific button assignments in your FSUIPC6.ini, and the general assignments only contain one button assigned to Pan Down. Controllers are also set to On in P3D, so you seem to have almost all of your assignments in P3D, not in FSUIPC. If you send / post any further logs, please disable logging for Events (non-axis controls) and Axis controls and set logging for Buttons & Keys instead. John

You have asked this before. I have no idea - just use one that works. This has never been an issue for anyone else in 15 years of support. Paste in plain text and then format.

17 is the parameter you would use when using the lua script as-is and assigning to 'LuaSet F1MustangSwCtl'. 32 is the parameter you would use when assigning to Throttle4 set. When using the lua script and assigning to 'LuaSet F1MustangSwCtl' with a parameter of 17, the lua script then sends Throttle4 Set with a parameter of 32. You need to understand how these things work. But I see no assignments to the control to list the lvars, and all your assignments to Throttle4 Set are using a parameter of 0: How are you listing the lvars when you have no assignments to do so? Note also that it could be that the lvars are created by the lua script for use in that script. But the lvars would still be listed when the script is running and you list them. Your log file shows that the lua script 'F1MustangSwCtl IS running. So, to control the master warning switch, just assign to 'LuaSet F1MustangSwCtl' with a parameter of 17, as I keep saying. Why don't you try this? And you do not need to the other lua script 'F1MustangAPCtl.lua' unless you have a GoFlight RP48 and want to control the leds. Note also that you are using an old and unsupported version of FSUIPC6. Only the latest version is supported - please update to 6.2.2 John

In the FSUIPC log file (i.e. FSUIPC6.log for FSUIPC6), exactly as it says in the documentation. Did you assign a button or keypress to the "List local panel variables" control, and then press that button/key to list the lvars? If there are no lvars, you should still see the aircraft name logged - do you see this in the log when you activate that assigned control? If not, you are doing something wrong. I have asked to see your files so that I can help you but you still have not showed me anything...I really can't help that much if I cannot see your files as these show me what you are doing. And I do not see this as not user friendly - looks pretty simple and straightforward to me, and would be to any native english speakers. If its a language issue, there is not much I can do about that. There is a french translation available for an older version of this document (for FSUIPC4) but still mostly valid. If the name is the same and the custom controls (using the Throttle4 Set control) are the same, I suspect that the lvars are also the same and those scripts should work if/when configured correctly. And no need to attach files that I provide - I (obviously) already have them. You could always use the lua scripts as provided. As I say, they should work if configured correctly. You need to read & understand the comments in the lua script to use this script. For example, If the script was running correctly, to control the master warning switch you would assign to "LuaSet F1MustangSwCtl" with a parameter of 17 on the press only. John

That really shouldn't be the case...running via a shortcut should run exactly the same as running the exe directly from the installation folder - at least it always worked that way. Just tested with FSUIPC7 and it still works that way (i.e. it picks up the ini in the exe folder location, and logs to the logfile in the exe folder location). I can check with WideClinet at some point, but can you try again. Once you have a connection with WideClient (starting it from the installation folder), exit and re-start if via the shortcut - does it not still connect?

How many throttle levers do you have? If you have 4 axes, you can assign to Throttle1, Throttle2, Throttle3 & Throttle4 (and calibrate). If you have two axes, you can assign to throttle1 and throttle2, and in the calibration page 3, calibrate both and check the Map 1-<12, 2->34 checkbox on the throttle4 panel. If you only have one axis, assign to Throttle and on page 1 of the calibration check the Map to 4 throttles checkbox.

It can happen if windows assigns the same ID to multiple devices, and also if/when the GUID of a device changes. Usually when this happens you can remove the current registry entries and let windows re-assign new ones, then change the id-to-letter mapping in the FSUIPC7.ini file (if needed). You can sometimes also use JoyId tools to just change the id mapping in the registry. I don't understand why the same id is assigned when adding a new device though, and FSUIPC also uses the GUID to determine which entry matches, so I am not sure what happened in your case without seeing your log and ini files.

👍 Thanks for the update. John

This has previously been reported and is corrected in a the latest beta release available here: John

Do you mean the strange flicker? I have no idea what could be causing that. Please check that the throttle lever is not assigned or calibrated in MSFS. You can also generate a log file with logging for Axes Controls set, and show me/attach that together with your FSUIPC7.ini file. Just load the aircraft, set logging for Axes Controls, move the throttle through its full range and back again and then close/exit FSUPC7 before attaching the files. John P.S. I have moved your post to the FSUIPC7 support sub-forum - please use this forum for all questions/issues with FSUIPC7.

First lets clarify some terminology. A macro is just a collection of commands, executed in order, contained in a macro file, i.e .a file ending *.mcro. Macros can be called/executed by assigning to a button or key press/release, when entering/leaving an axis range, or by the lua command ipc.macro. A lua script or plugin is a script in the lua programming language, contained in a *.lua file, that can be ran either automatically, on a button or key press/release, or started by another lua script. There are two way sof doing this. The lua script can monitor for the same event that starts the macro, so that when the macro is called the lua script also receives the event. e.g. if the macro is started on a button press, the lua script can wait for an event on the same button press using event.button. Alternatively, the macro could perform an action that can be picked up by the lua script, such as setting a flag or writing to an offset. This doesn't make sense, FSUIPC runs until it exists - it makes no sense to 'execute fsuipc in a loop'. And a macro is just a sequence of commands with no control - it will execute until the end once started (ther is no conditional logic in a macro). If you mean that you want a lua to loop in a lua script until a condition is met, then use a while loop, e.g. while(not B1) do ... end See https://www.tutorialspoint.com/lua/lua_while_loop.htm.

Which flight simulator/version of FSUIPC are you using, and which aircraft? Please always specify this information when asking for assistance, as assignments can be different for different simulators and aircraft. You can try setting logging for Events, open the logging console window and see if anything is logged when you click the buttons in the Virtual Cockpit (using the mouse), and if anything is logged then assign to that.

No there won't be. But I am surprised that is solving your issue, as the documentation states: So you should need a larger value to make it less sensitive, not a smaller value. If the trim wheel is using a macro, you could provide your own to override the default behavior, as for any other buttons/switches that don't work, or need to be made aircraft specific in their assignments. You also need to read up on how macros work in the FSUIPC7 Advanced User guide (page 36). You can log the macro name used for each button/switch by setting LogMacroNames=Yes in the [Debug] section of your PFChid.ini file. You can then create a macro with the logged name in the PFC.mcro file and this will then override the default behavior of the button/switch that uses that macro name. John

As I said, you need to use logging to see what is being sent, and also operate in the VC to see what should be sent, then update the assignment accordingly. Not sure what this means....You won't see the buttons/switches in the assignment panel - I don't think it works like that for your device. The switches trigger a macro. There are default macros for most switches/buttons, but these may not work for many aircraft in MSFS2020/MSFS2024. That is why you can override the default macro and provide your own. This is all described in the PFChid User guide documentation - did you read that? Yes - they will be using the default/inbuilt macros. Please read the documentation provided with the PFChid64 driver dll.