John Dowson

The *_EXT (and *_EXT1) controls cannot be calibrated, but they can be scaled (and reversed). See the section Additional parameters to scale input axis values on page 41 of the Advanced User guide. However you cannot set custom start/end values, only scale, but you should be able to scale to get something useable if not perfect... John

The *_EXT (and *_EXT1) controls cannot be calibrated, but they can be scaled (and reversed). See the section Additional parameters to scale input axis values on page 41 of the Advanced User guide.

Not quite - the previous log file is renamed to FSIOPC7_prev.log, so you always have the log file of the current and previous run if FSUIPC7. There are two know issues that can cause this. One is for Windows 11, when FSUIPC7 thinks that MSFS is no longer available and so exits, although it is still running. There is a new ini parameter for this issue, and this is now set automatically when FSUIPC detects you are running Windows 11. The second is related to a long standing issue with SimConnect. and can occur when simconnect runs out of client connections. This issue us quite rare and difficult to diagnose correctly (you need SimConnect logging), but if you think this could be an issue then just increase the maximum number of available client connections in your SimConnect.xml file. But you really need to show me your FSUIPC7.log file before anything else. And if MSFS is crashing, that should be reported to MSFS - FSUIPC7 is not the cause of this and I cannot investigate MSFS crashes. Check the windows Event log if you get a CTD.

What do you mean by this? If you open the axes or button assignments panels and move an axis or press a button, do you not see that recognised? Your ini file shows 5 devices were recognised and should be available for assignment: If you cannot see these devices in the assignments panels, please show me your FSUIPC7.log file. John

No - I just checked this an it is certainly v7.3.7. I don't understand how you can see 7.2.1... John

I am confused now - you did have the WASM enabled! The Add-ons->WASM menu items (such as Execute Calculator Code or Set Lvar) are not available unless the WAPI is enabled. Not without seeing your files again, with appropriate logging activated. Set FSUIPC7 logging for Buttons & Keys as well as Events, load your aircraft and press the assigned key. Note that the left/tight alt key modifiers are specific - i.e. your assignment is using the left alt key, not the right one. What events or presets are you using for this? If there are no specific on/off events (or presets) provided (I am pretty sure there are for Parking Brakes!), you can use the toggle event but with an offset condition in an offset that is holding the current state of the function you are trying to toggle. I am finishing now for the weekend. Provide more information (and possibly your FSUIPC7.log and .ini files again), and i can look into this further on Monday. Have a good weekend, John

No, I don't, sorry. Logging will show you the pause state changes, but not what is sending these. If its coming from FSUIPC, additional logging (and/or checking the FSUIPC7.ini file and maybe luas or macros - for registered versions). If its coming from an FSUIPC 3rd-party client, IPC Write logging should show this (although that can be difficult to interpret).

You can activate logging for Events in FSUIPC7, then take a look at the FSUIPC7.log. You can also log offset 0x0264 (as U16 in hex) which will log the 3 distinct pause states as: 0x1 -pause set 0x2 - pause on/off 0x4 - esc pause Note that MSFS can also be in multiple pause states at the same time. Btw, you posted in the main DSUIPC support forum. I will move your post to the FSUIPC7/MSFS sub-forum. John

That is not an error - it is an informational message [INFO]. Yes, this is normal. The default FSUIPC_WASM.ini is always located under your Community\fsuipc-lvar-module folder. This is the one installed by the FSUIPC7 installer when you install the WASM module. If you change that file, your changes will be overwritten the next time you re-install or update FSUIPC7. To prevent your changes from being lost, the WASM will also read an ini file from your WASM persistent storage area - this does not exist by default, you need to create (or better, copy) this file yourself. Please see the section WASM module ini file and parameters in the Advanced User guide (page 48). Can you try with another aircraft, so we can see if this is a general issue if specific to the C172. Maybe also set the logging lever in the WASM (and maybe also the WAPI, later) to Trace and resend the log file. It looks like the FSUIPC WASM module has crashed for some reason (or at least, its not available) as it doesn't seem to respond to any requests. I am busy this weekend - I will come back to this on Monday. John

Why do you think this related to FSUIPC? And what version are you using (if any)? You should try asking about this on the GSX support forum. I do not use or know about GSX... John

FSUIPC auto-save just calls the MSFS/P3D SimConnect SDK function to save/load flights (although you can also save/reload the FSUIPC data). If aircraft panel state needs to be saved, then the FS should also save this data. However, this is a mute point at the moment - the MSFS SDK function is still not working correctly (and documented as such). Hopefully this will be addressed in one of the coming MSFS updates...hopefully the one planned for the 23rd. The next SDK update should have quite a few improvements (looking at the development road map), but unfortunately I haven't see anything relating to the save/load flight functions., or many specific details on the SimConnect SDK... John

No problem. and I understand the language issue. This was just confusing me and wanted to clarify. Your issue is very strange, and I can't understand why your system can be behaving in this manner, except for an underlying installation issue in MSFS (or maybe windows). You could also try re-installing the latest VC++ redistributables, as I have seen strange problems sometimes with these not being correct. Uninstall any of the 2015, 2017, 2019 & 2022 VC++ redistributables from the Windows App management panel (any/all that are installed), and then install the latest combined redistributable packages (both the x86 and x64 versions recommended, although FSUIPC7 only requires the x64 version) from here: https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist I am not sure this will help, but worth a try (before verifying integrity!). John

This is the WAPI API, used for developing FSUIPC WASM clients in C. You don't need this, unless you are writing your own FSUIPC WASM client... But why are toy using this? Unless you are a developer, everything you need coms with the DSUIPC7 installer. That package (without the version number in the file name) us also included in the FSUIPC7 SDK folder (called FSUIPC0WASM.zip). Thar separate downloadable FSUIPC WASM package is intended for developers that don't use FSUIPC7. That is a fault in MSFS, which can be causing issues, but I do not know if this is related. Please check the event viewer when MSFS CTDs to see if anything is reported. I have still no idea what is causing your issue, and I don't understand how it can sometimes work and sometimes not. It may be a problem somewhere in either your MSFS or windows installation (most probably the former). Maybe worth checking the integrity of your MSFS steam installation 9available from the steam app). Be aware though that this can cause a complete re-download of the FS. John

The logs you posted are very strange and don't seem to match...the WASM log file shows the following calculator code was received and executed but before lvar scan took place: There are no presets/calculator code requests seen by the WASM after the lvarscandelay was passed and the config data set. Your FSUIPC7.log file doesn't show that calculator code being sent in that order. In fact, the log file doesn't start until 10minutes AFTER those log entries: (assuming the two hours difference is due to one log using local time and the other GMT/Zulu time). So it looks to me that these log files were not generated at the same time....could that be? Either way, I remain confused with this... I also seems that you had this working at one point for a short period but then stopped: I really don't understand this at all.... I have also asked some questions that you have not answered - can you please respond to all my questions so that we can get to the bottom of this: Are you, by any chance, using the latest MSFS beta? Could you explain this? There is no FSUIPC_WAPI folder... Are you using any other software other than MSFS and FSUIPC7? If so, what? Maybe try without that... What do you have in your MSFS Community folder (apart from the FSUIPC WASM folder fsuipc-lvar-module)? Can you also check your Windows Event log (using Event Viewer) to see if any events for MSFS or FSUIPC are reported. Thanks, John

It certainly shouldn't do that! I have not noticed this behavior, but I don't use FSX that often (only for support issues). Thanks for reporting back, John

But this would mean that AFC_Bridge would not run... For auto-start issues, please see the following FAQ entry: John

This helps me. And now it works like a charm. 👍 Thank you! And thanks for reporting back - happy flying! John

No - the default (without the parameter specified) is 5 seconds. This is the number of seconds the WASM waits after the aircraft is loaded and ready-to-fly before it scans for lvars. Once this lvar scan is complete, config data containing the lvar/hvar names is passed to FSUIPC7, and the WAPI is then useable (and the WASM menu items are enabled for use). I don't understand this - setting to 120 means that the lvars/havrs aren't available until after two minutes after the aircraft is ready. So, what do you mean by work in this context? I will take a look at the log files a bit later to see if I can see anything... John

Sorry, I don't understand this question...what is the FSUIPC_WAPI folder (and where is this located)? That isn't part of FSUIPC - the WAPI is an API that FSUIPC uses (as well as maybe other 3rd party clients). But I thought that was always ok (i.e. options available) - you were using that to execute calculator code (which wasn't working)...I'm confused even more now... John

Where is that FSUIPC_WASM.ini file located? It should be in the same folder as the FSUIPC_WASM.log file, but that log file has this: So only the ini file from Community\fsuipc-lvar-module was loaded. The ini you attached has LogLevel=Debug but there are no Debug level logging statements in your FSUIPC_WASM.log file. So something is certainly wrong somewhere. Note that your previous WASM log files did have Debug level logging enabled, so something must have changed. Can you please make sure that there is an FSUIPC_WASM.ini file in your WASM persistent storage area - check the Advanced User manual (WASM section) to determine where this is (it depends on your install type, Steam or MS Store). Can you also show me your InstallFSUIPC7.log file. Also, once you have debug level logging in the WASM properly activated, add the following line to your FSUIPC_WASM.ini: LvarScanDelay=45 Then try again and resend me the same files. I find it hard to believe that only 126 lvars were found for the C172 - when I load this aircraft (with the G1000) I get 1779 lvars... Also, please confirm that you are not using the latest MSFS beta...this is not supported.... John

But I don't think there ever was a problem...with FSUIPC7 at least. The desktop MSFS icon that FSUIPC installs DOES NOT START FSUIPC7, it only starts MSFS (that is why it is labeled that way!). It is MSFS that starts FSUIPC7. This is why I was continually asking you to try and just run the FSUIPC7.exe... As I said, the desktop icon only runs MSFS, not FSUIPC7. Are you saying that the desktop icon doe not start MSFS, or that using that icon starts MSFS but FSUIPC7 is not started? If the latter, then your problem is with FSUIPC7 not auto-starting, NOT that it is 'loading and crashing', as your topic title indicates. For this issue, PLEASE see the following FAQ entry: I understand that it may not be obvious to you what the issue was, but if you had answered my questions and followed my instructions we could have resolved this issue a lot quicker. Maybe also take a look at the provided documentation, especially the README.txt, the Installation and Registration guide and the User guide. John

Ok, then it is the flaps config that must be causing this issue,,, How did you check this? You cannot rely on just the visuals to check this....it is quite possible that the visuals don't confirm to the actual flight model, which is why we need logging. The log file you attached doesn't contain any offset monitoring lines, even though the ini file shows you have added the offset monitoring that I suggested. I would expect each offset value to be logged at least once, with an initial value of 0. I see you have also assigned flaps to 'Send to FS as Normal axis' but have also calibrated. This has been known to cause issues with PMDG aircraft. Can you try two things: 1. Change your Flaps assignment to 'Direct to FSUIPC calibration' and see if that helps. 2. Use the flaps assignment as-is (i.e. 'Send to FS as normal axis'), but remove the calibration, i.e. remove the following lines from your FSUIPC7.ini: The next time this issue occurs, could you also perform and Add-ons->WASM->List Lvars before you exit FSUIPC7, and then again after you restart. I can then check the values of the *flaps* lvars. John

Me neither, it is very strange... Could you try re-installing FSUIPC7 in a different location. Create an FSUIPC7 folder on your Desktop, and then re-run the FSUIPC7 installer and change the installation location to the Desktop folder. You can skip registration and copy your FSUIPC7.key file from the old location to the new location. Also, if running any antivirus/malware software (other than Windows Defender) then try temporarily disabling that to see if that is interfering somehow.

Maybe take a look at the WevSocketServer interface - see http://fsuipcwebsockets.paulhenty.com/ John

If the Add-ons->WASM menu contains a Disable menu item, the WAPI is enabled, and if it contains an Enable menu item, it isn't. You only need to Enable once. If the other items in that menu are disabled, it means that the config data (lvar and hvar lists) has not yet been received from the WASM. Once the config data gas been received, the remaining WASM menu items are enabled - and also lua autos will then be started 9i.e. lua autos are started only once the WASM/WAPI config data has been received if the WASM/WAPI is enabled. Nothing should prevent the WAPI from loading, although it can take a while for the config data to be received, depending on the value of the WASM ini parameter LvarScanDelay. And sone WAPI messages should always be seen in the log, when the WASM is enabled: Everything should be ready once that message in bold has been logged. This will only happen once an aircraft is loaded and ready-to-fly, and not if/when in the MSFS menu system. Any issues, then you should activate Debug logging, initially in the WAPI by adding the following line to the [WAPI] section of your FSUIPC7.ini file: LogLevel=Debug With this added, additional messages such as the following will be logged once the WAPI config data gas been received: Debug level logging can also be set for the WASM (see Advanced User guide for details on how to do this), and you can/should also check the FSUIPC_WASM.log file. This is how it should look if functioning correctly (and with Debug level logging set) - lines in bold indicate when everything is ready: John