John Dowson

I have now updated to Windows 11 and, as suspected, I cannot reproduce the issue. The issue is that the Windows API call FindWindowEx cannot see the MSFS main window, and therefore thinks that MSFS has exited or crashed, and so disconnects. If anyone is experiencing this issue AFTER re-installing the VC++ 2015, 2017 and 2019 combined package (make sure to uninstall the individual packages first!) [instructions in the README.txt] then please report here, and specify if you have a windows 11 clean install or have done an in-place upgrade. Also, please let me know the hardware/processor you are using, to try and determine what, if anything, is common in the hardware of folks experiencing this issue. There is not much else I can do about this issue at the moment. I will add an additional ini parameter to allow this feature (i.e. the check on MSFS availability) to be disabled. With this, FSUIPC should still close/exit with MSFS when MSFS exits normally, but you will probably need to manually close FSUIPC7 if MSFS CTDs. However, there could also be other issues that occur when the FindWindowEx call fails, so this may not be a work-around. Anyway, I'll post a version with this additional ini parameter here in this thread, in a day or two. John P.S. Please also make sure that you are running MSFS and FSUIPC7 at the same permissions level...

Yes, I see you have quite a few responses there....but still no satisfactory solution.... Unfortunately I have nothing further to add to the responses you have received there. Not having this throttle, I cannot really advise any further than the responses you have already received. There is this oldish post, but also no clean solution by the looks of it: https://forums.flightsimulator.com/t/is-it-possible-to-set-the-hotas-warthog-to-thrust-reverse/385899 As you only have this issue with the FBW A320, I would have thought that it should be the FBW team looking into this. Cheers, John

hvars are only known to FSUIPC7 if you make them available via a *.hvar file, where the name of the file is a substring match to the aircraft name. Please see the Advanced User guide for details. The destination airport ID should be available if you have a flight plan active in the GPS at offset 0x6137, but no other details (height, etc) are available, and there is no way to get the departure airport as far as I am aware, sorry. John

Just the WAPI / client side libraries. No change in the WASM - still at 0.5.5. John

The problem was in the WAPI. This has been corrected and updated to version 0.5.5 (the same as the WASM). Please download this version and try with that. John

Hi Paul, Turned out to be due to not resetting the data definition Ids when starting (or stopping) the simconnect connection, and so it was continually waiting for the client config data on a definition Id that didn't exist. This has been corrected now on WAPI v0.5.5 - all repos updated, and I have updated the zip package to 0.5.5a (now containing WASM 0.5.5 and WAPI 0.5.5, as well as the updated WASMClient). Regards, John

That should be possible (i.e. to add them to offsets). This will be for FSUIPC6 and FSUIPC7. I have a few issues I need to sort out first (Windows 11, SU6 update for MSFS, etc), so will take a while before I can look into this. I will let you know, but hopefully I'll get time towards the end of the week (Thursday or Friday), and if not, then next week. John

Ok, thanks for the update.

No, nothing there thar looks useful. Did you try the Avionics Master 1/2 Set controls? Maybe worth a try. And I presume that you are giving the correct argument (0 for off, 1 for on) with the ....Set controls... You could try writing to the offsets (0x2E80 or 0x3103), but I think these use the Avionics Master Set control, so if that isn't working, I doubt very much if updating the offset will work either. Sorry, but I think you need to contact support for the a/c in question - is it from SimWorksStudios? Under 'known issues', it does say 'As the aircraft uses default simulator functions for its electrical systems, we are currently limited by its capabilities', which suggests that it is using the default avionics supplied by MSFS, which is working - at least in many other aircraft (although I haven't checked this since the latest SU6 update, but I presume still woeking...). Sorry I can't be of more help. John

If the standard controls don't work, and you can't see any events logged when you toggle the avionics in the UI, then try listing the available lvars to see if any are appropriate. Use the Add-ons -> WASM -> List Lvars menu option. If there are no lvars, you could try looking for hvars, but that is quite complex and involves inspecting the aircraft code using the dec mode facilities. Unfortunately I do not have this add-on and so cannot look into this for you. John

Ok, thanks. Let me know how it goes and send me the logs when you have issues. Thanks, John

Hi Paul, Ok, I'll take a look, but tomorrow. I have a suspicion that this is due to the config data being the same, therefore the config data client area update isn't triggering the callback in the client. If that's the case, should be easy to fix....but I wonder why this issue hasn't arisen before. Anyway, I'll take a look, hopefully tomorrow, and get back to you. John

There seem to be two issues here: 1. the lua thread crashing 2. the crashed thread hanging FSUIPC I will look into item 2, however it would be good to know why the lua thread is crashing and try to prevent this. Could you activate lua debug logging, and produce a log file where you get the lua crash. It could be quite large, so you may need to zip it up. It is most probably an issue with the com library that is causing the issue. You could register and use an event.terminate function to explicitly close the com connection, which may help. See the lua library document for details. I notice that your script is also using the ipc.display function. Are you having any success with this? The simconnect API function that this relies on (SimConnect_Text) has been partially broken since the initial release of MSFS, and it was completely broken in the SU5 update and is still documented as 'not currently available for use' in the latest SU6 update. Due to this, we recommend switching to using the lua wnd library instead. However, I don't think this jas anything to do with the crash you are experiencing. John

What do you mean by this? FSUIPC does not scan scenery files to extract gate and parking positions. However, these can be extracted from the files produced by the MakeRunways program - see the Useful additional programs section. For gate information assigned to AI aircraft, this should be available in the TCAS DATA2 offset area at 0xD040. However, this offset area has not yet been checked/verified and may not be available, best to check. John

If FSUIPC7 is auto-started, that option is enabled by default and cannot be disabled. Are you starting FSUIPC7 manually then? For other users that reported this issue, FSUIPC7 keeps running but cannot be used as its continually trying to re-connect. Can you show me your FSUIPC7.log file please. John

Well, still not available to me. I've joined the Insider program to get access and was planning to update this weekend. It doesn't "die". It exits as the periodic check, which runs every 500ms, cannot fin MSFS, so it thinks MSFS has closed/crashed and so exits. This is due to a standard windows call not being able to find the MSFS main window. I have no idea why this is failing. Some folks have had success with re-installing the VC++ combined redistributables for 2015, 2017 & 2019. Others say that this has improved things but till have issues. If you haven't re-installed (uninstall first) those, please try that. Well, many people use FSUIPC, and Pilot2ATC, without these issues. If you have such issues, you should raise a support request. Have patience and wait until I have upgraded and see if I can reproduce the issue. John

Not exactly, but I'm sure they are available for the radio panels. lvaes are simulatoe 'local variables', and hvars 'html variables'. They give further information and allow for more advanced controls than the standard controls/events or standard simvars (those held in FSUIPC offsets). lvars are also available in FSX/P3D, but mainly used for more advanced functionality not available via other means (and more reliable than mouse-macros). hvars are new to MSFS2020, and are variables for UI elements that you can 'activate', which replaces mouse-macro functionality available in previous versions of FSUIPC. Please see the Advanced user guide on how to use lvars/hvars with FSUIPC. Note that the FSUIPC only explains how to access/use these type of simulator variables, for general information on what they are, try the Asobo/P3D forums or google. But if you don't know what they are and don't use them, you don't need the FSUIPC WASM module (or anything else) in your Community folder to use FSUIPC. John

Please try with the trial license available here: As with all versions of FSUIPC, it just calls the simconnect API functions to load/save a flight. In addition, as with other versions of FSUIPC, it can also save and reload the FSUIPC offset data, which can be useful for some aircraft. There have been various issues with the simconnect load/save flight functions - I think these are now fully functional but haven't checked since the latest SU6 update. Best to just use the trial license and try for yourself - and please report back. Cheers, John

Glad its working - and thanks very much for your kind words. John

Did you install the MobiFlight WASM module? I thought the FBW custom events were handled by the FBW A320 itself, but if they are not working you may need the MF WASM module installed. Maybe check/ask on the FBW discord channel. You certainly need the MF WASM module to use the MF presets (see https://hubhop.mobiflight.com/#/list), so maybe install that anyway if you want to use the custom events. Also, are you using the FBW dev version? Not sure what presets are available in the stable. John

Yes, it will work, but you will have no access to lvars or hvars. The FSUIPC WASM module, that can be optionally installed into the Community folder, provides access to these. If you dont use lvars or hvars, you don't need to install it. John

Hmm, thats strange...but glad its now working. John

Hi Martin, I'm not sure... I know the FBW A320 has its own throttle config and calibration (through the flypad, and/or via a ThrottleConfiguration.ini file, although I haven't looked at this for quite a while. I am away tomorrow and back at work on Monday, so I'll take a look at this next week and get back to you. In the mean time, maybe/hopefully some other Warthog owners / FBW flyers can assist... John

Could you also show me the JS145.lua file please. Note I am on holiday tomorrow so it will be a few days before I can look into this. John

There are no assignments to any button to turn off the autopilot - unless you are doing this assigned to a keypress. If that is the case, then please let me know which assignment? Could it be that your device ids have changed? Looking at your ini axis assignments, you have aileron and elevator axis assigned to device A, which is your throttle, and throttle to device C, which is your Yoke (B is rudder), so try switching those devices by changing your [Joynames] section to: Let me know how it goes with that change, and any issues please show me your updated .log and .ini files. Note that this will invalidate any assignments recently made to thos devices, so you may wish to remove or update them manually (by changing the joy letters used in the assignments). John