John Dowson

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

I am confused...are you running FSUIPC or MSFS? The windows events you are showing ,e say that you cannot launch MSFS, not FSUIPC7. What splash screen are you seeing - the MSFS one (displayed from the MSFS icon or MSFS.bat file) or the FSUIPC7 splash screen (displayed when FSUIPC7 starts)? Have you tried just running FSUIPC7, by double-clicking the FSUIPC7.exe (NOT using the MSFS desktop icon or MSFS.bat file)? Can you run MSFS (without FSUIPC7), i.e. from MS Store the Microsoft Flight Simulator icon or start menu item? John

Yes, lots of stuff... As a test, just to see if this issue is being caused by an add-on, could you temporarily remove (e.g. move up one folder) everything from your Community folder except for the fsuipc-lvar-module and see if that works and we can go from there.... John

As I said, all that listing the lvars would do is a rescan. Increase your LvarScanDelay parameter, and you won't need to do this. Just because the WAPI is enabled, it doesn't mean that lvars/hvars are available. This occurs LvarScanDelay seconds AFTER the aircraft has loaded. But again, there is no difference between 7.3.6 and 7.3.7 in these matters. 7.3.6 is no longer supported. I cannot help you if using that version - the first thing I will ask you to do is update to the latest and ONLY supported version (Betas excluded). And please do not post images or videos (unless specifically asked). They are useless to me - I need to see your .log and .ini files, the former with appropriate logging enabled. BUT as your issue is with an MSFS CTD, I cannot help with this, as I have said, so I am closing/locking this topic. If you are having issues with 7.3.7, please raise a new topic (preferably after understanding and following the hints I have given here). John

I don't know what this means....as I said there is no change between the versions for this. How were you doing this in 7.3.6, and why isn't that possible in 7.3.7? Note also that the only change that listing the lvars (from the Add-ons->WASM->List Lvars menu option) does (apart from listing the lvars) is to perform a rescan for lvars (and hvars). This shouldn't be needed if your LvarScanDelay WASM ini parameter is high enough. Try changing that from the recommended (in the readme you attached) 45 seconds to 60 seconds. John Later: and the readme doesn't say you need to list lvars, just wait until that option is available. That just means that the lvars have been loaded and are available for use...

If you mean from me, then no. I only provide and support the C API of the FSUIPC SDK. All other APIs are provided (and hopefully supported) by other 3rd party developers. There have been various support requests over the years on using FSUIPC with NodeJS, so maybe check the forums to see what (if anything) is available. It is only me supporting all versions of FSUIPC (for FSX,P3Dv4/5, MSFS) and WideFS7, as well as various drivers and other tools. I just don't have time for anything else, sorry. John

There should be no changes between 7.3.6 and 7.3.7 that should affect your CPFlight MCU-CDU...

Also show me your FSUIPC7.ini when you show me this log... Note it is also not possible to send presets on entering/leaving axis ranges at the moment, so do not use that. I will correct this in the next beta release. If you still get issues, maybe worth temporarily removing the spoiler and flap assignments and calibration, to see if that makes any difference... John

Yes, the WASM is not picking up the calculator code from the CDA, although the FSUIPC7.log shows the WAPI is connected, and the lvar/hvar data has been received. Do you know if you are running any other WAPI clients? What else do you have installed in your MSFS' Community folder? There are a few other things to try... 1. Try setting an lvar value using the Add-ons->WASM->Set Lvar... menu item. Doesn't really matter which one, but maybe try with L:XMLVAR_YokeHidden1 or L:XMLVAR_YokeHidden2 ones, as changing these from 1->0 and 0->1 should show/hide the yokes, so you can see the affect without having to check the logs. Perform a Add-ons->WASM->List Lvars first, as this will also rescan for lvars (as your LvarScanDelay parameter is probably set to the default of 5 seconds). 2. Try the Add-ons->WASM->Execute Calculator Code function again (or buttons assigned to presets), but using the latest FSUIPC7 beta. There is a fix in this version that can prevent issues when using multiple WASM clients. This beta is available here: John

Did you try executing any calculator code when producing those logs? If so, nothing was received by the WASM. I don't know what can be preventing this, but your FSUIPC7.log shows that you are using LINDA. This could be interfering - can you disable LINDA for the time being and re-test (e.g. just temporarily rename your ipcReady.lua file to ipcReady.lua.unused). You can also assign a button or key to the AS1000 MFD range inc/dec presets and try them, with logging for Buttons & Keys as well as Events activated. Do this and show me those files again, as well as your FSUIPC7.ini file. John

Executing calculator code does just that - it executes the calculator code you enter. If you assign a button to a preset, then pressing that button would execute the calculator code of that preset exactly the same as done using the Execute Calculator Code window. This doesn't make it easier, just confirms that it isn't working for you, as you said. I do believe you! But it is working, and we need to determine why it isn't for you. I need to see your log files, with appropriate logging activated. Can you therefore please activate Debug level logging for the WAPI, by adding the following line to your FSUIPC7.ini file under the [WAPI] section (when FSUIPC7 is not running)): LogLevel=Debug Also activate Debug level logging in the WASM by adding/changing the following line in your FSUIPC_WASM.ini file (see the Advanced User guide for the locations/details)): LogLevel=Debug Then run MSFS/FSUIPC7 and try executing that calculator code again. Then exit and show me your FSUIPC7.log and FSUIPC_WASM.log files - attach the complete files please. If the calculator code is being sent correctly, then you should see the following logged in the WASM: John

Are you using the default KAP140 or the mod (see https://github.com/FS2020-USER-TESTER/KAP140-MOD-PACKAGE/releases)? Not 100% sure what you mean by this (as there is no VS mode button on the KAP140!), but from the mod README.txt (which I have attached): Also see the available presets (15) for the KAP140 (from https://hubhop.mobiflight.com/presets/😞 John README.md

Offset 0x3E00 holds the path to the 'flight simulator installation', which is taken to be the folder in which you opted yo install MSFS, and is taken from the InstalledPackagesPath variable of the MSFS' UserCfg.opt file (which, for steam installs, will be under %APPDATA%\Roaming\Microsoft Flight Simulator). This is where your MSFS' Community and Official folders will be located. I don't think the location of the sim's exe would be useful, especially in MS Store installations which seems to use a complicated series of links (and protection). Can you think of a reason why this would be useful? But that is not the location of the sim's executable! For steam, that would be under your steam installation folder, under steamapps\common\MicrosoftFlightSimulator. The C:\Users\xxxxxx\AppData\Roaming\Microsoft Flight Simulator folder (for steam) is the 'save flights' folder (amongst other things...) and can be found in offset 0x1000. Cheers, John

See John