John Dowson

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

Yes, you have to install and enable the WASM module - which you seem to have done. Are you using the default G1000 or the one from Working Title? Your assignments look ok, so I am not sure why it isn't working. I will take a look and get back to you, but as the range presets just activate a hvar, could you try setting these manually to see if that works. Use the menu option Add-ons->WASM->Execute Calculator Code... and enter (>H:AS1000_MFD_RANGE_INC) to increase the range and (>H:AS1000_MFD_RANGE_DEC) to decrease the range, and let me know if those have any affect. John

What window? Did you see a splash screen? Did you see any pop-up error message? If not, try opening a command prompt window and start FSUIPC7 from the command line, and see if that gives an error message. Every issue I have previously seen for FSUIPC7 not starting is due to the correct VC++ redisitributables not being installed. Did you install the combined Visual Studio 2015, 2017, 2019, and 2022 redistributable packages for both x64 and x86, and also manually uninstall any individual or combined VC++ redistibutables from those years if already installed before you installed the latest packages? If not, please do that. Also please check the event viewer - of it is not starting, it must have crashed and there must be evidence of this somewhere... And are you sure FSUIPC7 isn't tunning - when you start FSUIPC7, it should show a splash screen for a few seconds and then it will be iconised to your system tray, from where it can be opened. You can also use Alt+F which is the default hot key to open the FSUI{C7 main window. John

First, try using the latest beta release which has the additional PMDG 737 offsets enabled (in case you need to use them), available here: The presets in that version are available via a new checkbox - most (but not all) presets start with PMDG* so they should be easy to identify, otherwise you can use the search interface provided by the MobiFlight HubHob site: https://hubhop.mobiflight.com/presets/ There is also a FAQ entry on how to use the PMDG custom controls, which use the Rotor Brake control, although most of these should be available via presets which are easy to assign: Note the SDK for the PMDG 737 has still not been published, but for the time being you van use the P3D NG3 header file, which i have attached. John PMDG_NG3_SDK.h

Check the available presets for the G1000 - they will be listed as 'Preset:AS1000...' (in the current release), or you can use the HubHob site https://hubhop.mobiflight.com/presets/ which you can use to find a preset. There is also an event file for the MobiFlight G1000 events provided in a sub-folder called EventFiles, but these days it is easier to use presets.