John Dowson

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

What is sending those rotor brake commands? What else do you have running? Can you show me your FSUIPC7.ini file please, as well as attach your complete log (you can zip it if large). When you relaunch FSUIPC, the rotor brake control with parameter 99003 is just a mouse-move (3) for this control: #define EVT_ISFD_ATT_RST (THIRD_PARTY_EVENT_ID_MIN + 990) // When you have your issue, many different controls are being sent, most with a mouse move (3) command but also a click (1) and release (4): You need to determine what is sending those commands. FSUIPC does not send anything unless asked, so I am not sure where those are coming from at the moment. John

Yes, looking at the code, that would seem to be needed. All the controls are sent on the first button push, even if there is a double push, so the second push is triggering the single push action when it should be ignored. In fact, without that additional line, the ignorepress variable is never set to true! I am not sure why this hasn't been picked-up before, but I will update the example script. Thanks for reporting back, John

Those presets (and executing the calculator code directly) seem to work ok here - the MFD ones control the range on the right-hand screen and the PFD ones control the range on the left screen.

I don't need to see a pic (which you didn't attach anyway!) but your FSUIPC7.log file. But what CTD'ed - FSUIPC7 or MSFS? If you check the FSUIPC7.log file first, you will probably see that FSUIPC7 exited as MSFS was no longer available (and maybe preceded by a couple of simconnect dispatch errors). If it is MSFS crashing, then check the Asobo or PMDG support forums. Also check the windows event viewer for information - you may see a fault report for FSUIPC there, but this will be after a crash report for MSFS.

Use the lua plugin logging facility - that should tell you what is happening, and maybe also log Events... John

No! Sorry, you need to use the Add-ons->WASM->Execute Calculator Code.. option, and enter (>H:AS1000_MFD_RANGE_INC) to increase the range and (>H:AS1000_MFD_RANGE_DEC) to decrease the range. The Activate Hvar menu item is for hvars known to FSUIPC only (via *.hvar files). Sorry about that - I will correct my previous post... You don't need that - that is just a test client and everything that does you can do from the Add-ons->WASM menu. As I said, I will take a look, probably tomorrow... John

It is the debug log that will show you what is happening.... John

If assigning to FSUIPC's Throttle axis, you dont need to map to 4 throttles or use the individual throttle calibration page. You only need to calibrate that control on the first calibration page. So, remove the mapping and individual throttle calibration, and try just calibrating on the first page. Also, maybe check the calibration of the throttle in windows controllers. And make sure that you have not installed the saitek/logitek drivers or software - if so, uninstall and let windows install the default drivers. If you continue to get issues when assigning 'Direct to FSUIPC Calibration', try with 'Send to FS as normal axis instead'. This will have various throttle axis controls - the "AXIS_THROTTLE_SET" controls go from idle to max only (idle at -16384, max at +16384), and the older FS98 controls (THROTTLEn_SET) provide a reverse range (for those the numerical throttle position for IDLE is always 0, max is 16384, and reverse is negative -- the max reverse depending on the AIRCRAFT.CFG parameter for reverse thrust percentage -- for example 25% would be -4096 (25% of -16384). FSUIPC calibrates to -4096 but auto-scales this according to the specific aircraft). You also have the throttle mapped to 3 distinct axes on two different controllers: You should only assign one axis - have multiple assignments to an axis can confuse things. Your ini also showed now controllers/devices were connected, which is rather strange: John

How have you confirmed this? Is it running from an [Auto] ot profile-specific [Auto.xxx] section? If the script is running and working correctly, that control must always be sent (when uncommented) as it is not within a function definition. If that is not being calles, then neither is the event.button(joy, btn, 1, "buttonpress") call. Could you please activate debugging for Buttons & Keys and Lua Plugins, generate a log file where you load your aircraft and start the lua and then press the assigned button (joystick Y, button 0), and then exit. Then attach (not copy) your FSUIPC7.log, FSUIPC7.ini and lua script. John