John Dowson

Sorry, but I cannot understand what you are trying to say...(google translate?). Gate information is part of the (airport) scenery files. FSUIPC doesn't do anything with these. However, as I said, we provide an additional program called MakeRunwys, which extracts runway (and gate) information and provides text files so that these can be read by other programs. Why don't yo take a look at that. Otherwise, I am really not sure what you are asking. Maybe you could explain by an example? John

Sorry, but I have no idea what 'Flight Multi Panel is, or how connecting a phone to your PC has anything to do with this (my phone always connects to my PC automatically, without issues). If you are having problems with FSUIPC7, just please state what they are. If it is running, I need, as a minimum, to see your FSUIPC7.log file. If it is not running automatically, show me your InstallFSUIPC7.log file, and try to start it manually - it that doesn't work, show me the error (and check the README.txt - maybe you need to reinstall the VC++ redistributables...) John

Ok, thanks for reporting back. I would really like to understand the underlying issue though. I will post on StackOverflow to see if any others are having this issue or know the cause. John

And also maybe try this version, where the lua is killed as soon as the 'Sim stopped' message is received: FSUIPC7.exe

Could you also try the following version - only some extra logging added and I've added some extra code to exit the crashed lua thread to see if this will prevent FSUIPC from hanging: FSUIPC7.exe

Could you try the following version please, which has some additional logging added. The lua will still crash, hopefully/maybe FSUIPC will continue (but probably not!) but some ectra logging should be avaiable - please show me your full FSUIPC7.log. You inly need to show me your lua & ini scripts again if they change. Thanks, John PS. You can turn off lua debug logging for the time being - I will advise if/when it needs to be activated again

The best place to determine what to use for such functions is the MobiFlight preset list at https://hubhop.mobiflight.com/. So, for the TBM930 generator, you need the following calculator code (from https://hubhop.mobiflight.com/#/presetview/950b5ca5-43eb-493b-92fc-f4bcff4572c3 😞 To set the master AP to trim only (https://hubhop.mobiflight.com/#/presetview/0742d4d1-0f5e-4495-8c8d-f2d873166b37 Not sure about this one, but try the available hvars (there is a G3000.havr file included in under your HvarFiles folder - to use the hvars, you need to copy this file to either the FSUIPC WASM folder or the MSFS working folder for WASMs, and rename to have a substring match on your aircraft - see the Advanced User manual for details). Once you have installed the *.hvar file, the follwoing hvars should be available for you to try: John

Ok, now I understand. However, what threw me i that in your FSUIPC7.ini you have: UseProfiles=Yes and not UseProfiles=Files So your main FSUIPC7.ini is not configured to use profiles as separate files. So I am confused to how your JS145.ini is being used, and thus how the JS145.lua is being started. John

No, this was added to FSUIPC7 only. I can look into adding for FSUIPC6 if needed. I can post a version for you here to check once done. John

Ok, thats good to know. Presume that is with using the new ini parameter set. It is very strange that this fix/hack is needed though. I don't understand why that windows API call is not working on some Windows 11 systems. It must be due to some windows system libraries somewhere, but if its not the VC++ redistributables I don't know where the issue could be. John

Btw, how are you starting this lua? There is no [Auto] section (or [Auto.xxx] sections), and no ipcInit.lua or ipcReady.lua. In fact, you have various profiles set-up, but nothing that uses them (i.e. no profile sections for axes, buttons, keys, calibration, autos,...).

Yes - it doesn't matter when you start the logging, but the complete log is needed, Also, can you show me your GetComPorts.lua script, as this is ran from within your JS145.ini script. Any reason why this is in a separate script rather than a function? Does that script keep running once it has set the ComPortsLoaded variable? If not, maybe try to remove that call and load the com ports from within the JS145.lua script itself (which now has a .ini extension in the last one poted....?!!!). This would at least tell us if its a dangling thread from that call that is preventing the JS145 thread from terminating. John

Could you also show me your FSUIPC7.ini file please. Also, next time you post a log, could you please post the complete log file and not start a new one. It may be quite large, but should zip up ok. Could you also confirm that this only happens when going back into the MSFS main mene (i.e. when ending a flight). And does it now always occur when you end a flight? From an earlier log you posted: This shows that the first time you stopped a flight, the lua file was killed/terminated ok, but the 2nd time it has the lua crash. I will see if I can add some further logging to track down the issue, and why there is such a delay (>5s) between the 'Sim stopped' and the lua threads being terminated. John

For those experiencing this issue, please try the attached version. in this version, you can disable the MSFS window monitor so that FSUIPC7 will not automatically disconnect from the FS when it cannot find the MSFS main window, by adding the following line to the [General] section of your FSUIPC7.ini file: DisableMSFSMonitor=Yes Please report back if this helps or produces other issues. FSUIPC7.exe John

Oh, and make sure that you are using the latest version of FSUIPC7, v7.2.11. John

Try right-clicking and selecting 'Save as...'. John

Do you mean the SU6 update (the latest one)? Strange - I thought you said it was still working for other aircraft.... If its now working now in any aircraft, maybe start bt looking at getting this working again in a simpler/stock aircraft. Sure, please show me your ini file. Also, activate logging for Events and Axis controls, and produce a short log where you load an aircraft and try to apply reverse thrust. Regards, John

Try activating lua debug logging, as well as monitoring the offsets as mentioned in step 10. If you keep the console window open while you activate the assigned button, you should be able to see what is going on. You can attach your FSUIPC7.log file (complete) and FSUIPC7.ini file here and I can take a look. John

It should already be there - why don't you take a look at a saved flight file? There are also [Departure] and [Arrival] sections. I'm nor sure how this helps though... John

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