John Dowson

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

Ok. Btw, I noticed that you are still using v7.3.6. The latest (and only supported version) is 7.3.7, so please update. There is also a beta version currently available for 7.3.8 with the additional PMDG offsets enabled here (this will hopefully be released in the next few days): John

👍

That log shows that FSUIPC7 exited normally as MSFS was no longer available: So it looked like MSFS crashed and so FSUIPC7 exited. Check the windows Event viewer - you should see a crash report for MSFS there (maybe followed by a fault/exception for FSUIPC7). I cannot help with MSFS CTD's - try the Asobo or PMDG forums. John

Well, arming does no harm but climbing will certainly be affected of the spoilers are actually deployed... It is difficult to determine what is happening when there are so many Rotor Brake/custom controls being sent... If VS is the issue, maybe the spoilers or flaps could be an issue. Could you remove all current logging, and do another test where you just log the spoiler and flap positions, and see if those change when you restart FSUIPC7 (they shouldn't!). Try logging the following four offsets, all as U32: 0BE0, 0BE4, 0BD4, 0BD8. Later: I'll see if I can reproduce this issue tomorrow...

Ok, I have looked into this further and I think everything is working as expected. Your issue is that the drive (or folder) you are using is not shared. UNC paths are only used (in various places/offsets) if the location of the file or folder is shared - otherwise it cannot be accessed from an external computer anyway. So, to get the UNC path, try sharing the folder or drive (right-click in Explorer, select Give access to and go from there...). To see and map share names, FSUIPC reads the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares Regards, John

No need for this - I can see there is a problem. I will look into this and get back to you. John

As Paul suggests, check that you have enabled SDK broadcasts in the 737_Options.ini file. If that is the case, I am not sure why the offset isn't populated correctly, but it may be because the offsets have changed and the PMDG SDK still hasn't been updated to reflect this. Note the SDK still hasn't been published and the last confirmation I got from PMDG was for release 3.0.25, so I have had no updates on any changes since that version (current version is 3.0.31. John

Hi Bob, there is currently an issue in the released version in that the WideFS enabled state is currently not remembered correctly. This could be affecting the full UNC path from being reported. Could you therefore check with the latest beta, available here: If you still get the same issue with that version could you attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. Cheers, John

It shouldn't make any difference to the functionality of FSUIPC if you auto-start FSUIPC or start it manually, or if you start FSUIPC7 before or after MSFS. John

Both if those log files show that FSUIPC was quit manually. You need to look at/show me the log file generated when you get a CTD. And you have still not confirmed if this was an MSFS CTD (when FSUIPC would also exit) or an FSUIPC CTD (when MSFS would still be running). Your prev log (i.e. the one generated in the penultimate run of FSUIPC7) does show some errors: These are due to using presets before the WASM interface is activated. John

I see you also have lots of other logging activated....just log events and buttons & keys - turn the other logging options off. That should reduce the log file size. You can also provide a second log with Axes controls logged as well as Buttons & Keys (nothing else). John

You could try activating logging for Buttons & Keys as well, which would tell you if any of those control are being sent from a button press/release. Other than that, there are two things that stand-out in your ini file: 1. One of your controllers was not connected: ? 2. You have some controls being sent when your spoiler axes enters/leaves two distinct ranges: Can you check (using the UI axes assignment window) what these presets are that you have assigned to please and let me know? This actually shows an issue - the control numbers are being used here, where the preset name should really be used (as in your button assignments) as the actual control numbers for presets can change when the events.txt file is updated. Therefore please check that they are still assigned to the correct controls/presets. I will look into this. As for the log file, you could try emailing me the zipped log to jldowson@gmail.com Can you also check if you have any assignments in MSFS, or are you using an empty profile in MSFS for your controllers? John