John Dowson

If, When you get the CTD, check the log file and count the number of connections obtained (lines containing 'Open: Version=' and see if it reaches 64. May as well - it won't do any harm.

Ok. I forgot to change the ids to the new numbers, but if you just manually remove the warning lines in your ini, just to tidy-up, you should be ok - delete these: John

Please try the attached - any issues, re-attach the updated ini and the new log: FSUIPC6.ini

If you attach your original .ini, your latest .ini and .log I will take a look and update them for you. John

Well, an external tool (exe not dll) should not be able to cause a CTD in MSFS, and if it does then there is certainly an issue with SimConnect (server side). Your log shows that SimConnect failed and MSFS CTD'ed after over 3 hours. There is a known issue with SimConnect in that it fails to respond when the maximum number of connections has been reached, but this doesn't usually cause a CTD in MSFS. You could try logging SimConnect to see if the connection limit has been reached (details in the FAQ section I believe), or maybe just increase the maxClients parameter in your SimConnect.cfg to 128 and test with that. It may not help, but it a simple change to make so you may as well try it. You should also raise a CTD bug report with Asobo, giving the windows event details + a crash dump, if there is one available.

It should be available, unless you already have multiple assignments to the button already set-up, in which case you can only change via editing the ini. John

First, you posted in the ,Net dll client sub-forum which is not related to your issue. I have moved your post to the FSUIPC7 / MSFS sub-forum, where it belongs. Please take care to post in the correct forum for support in the future. Have you read the installation and registration document, and the provided README.txt? Have you tried manually starting FSUIPC7? If not, please do that before posting again. Also try searching for similar posts - there are also many other posts with a similar issue where you can find the possible cause and solutions. Sorry, but I do get kinda tired responding to the same questions again and again.... If you still have issues after that, as a minimum please show me your InstallFSUIPC7.log file. John

Which FS are you using? If using FSUIPC7. see the offset status spreadsheet - this has the name of the simvar held in each offset, when applicable. I've also attached it. If using other versions of FSUIPC, you can still use this to see which simvar is used, but first check the offset status document for the version of FSUIPC you are using to see if available. I thought the standard bravo software to control the bravo lights was via the AFC_Bridge from Aerosoft. There are also a couple of solutions posted in the User Contributions section, although I am not sure of the current status. See the following: Accessing simvars via offsets was the main original purpose of FSUIPC and this method of reading/writing simvars has been around since FSUIPC was originally conceived. The lvar support came later. The size of the offset is specified in the document and it should also be possible to determine the type, either from the description or by simply logging the values first. John

'A' variables are standard simvars and can only be read via offsets. John

Please see And please see the provided documentation, the Installation and Registration guide as well as the README.txt. You need to install the VC++ redistributables. Instructions and download link are in the README.txt. John

Yes, as the newly created window will grab the focus (temporarily I think, but not sure without checking). No, I'm sorry but this is not possible. You need to redesign your script to keep the window open and update on relevant events. According to the documentation, that should be possible, and yes, you can use any variable name - its the value of the variable that matters. Have you tried logging the handle when you create/set it, and again when you retrieve it, to make sure it has the same value? I haven't tried updating a wnd window created in one lua thread from another - if you can't get this to work then let me know and I will take a look. Just to clear the reference. It doesn't make much difference in that script, as the event is cancelled anyway so the script will exit and the thread will be killed, but its generally good practice to clear the reference to any handle once the handle has been closed. John

No, not the registry, but the last line in the UserCfg.Opt file, found within the MSFS setup. For example, in my case the last line reads: InstalledPackagesPath "C:\Users\Pete\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages" That's what MakeRwys looks for to get the path. It is normally set when you install MSFS according to the location you choose at the time. I expect you could edit that to point to the link instead, but I've never tried it. Yes, this is what you should try. Create the link as a 'junction' and then update your UserCfg.opt to use this instead of the original full path. John

Hi Thierry, your log shows that MSFS crashed and FSUIPC7 then exited: The TransmitClientEvent errors are logged as MSFS is no longer available but the process that monitors this only checks every second and so you get a few of these logged before it detects MSFS has gone. If you check your event log again, you should see an MSFS crash event before the FSUIPC failure. As this is an MSFS issue, you should check the Asobo forums for CTDs related to SU6 and maybe also raise a ticket with Asobo. John

Can you please show me your FSUIPC7.log and FSUIPC7.ini - always needed (especially the log) if you have issues. John

Sorry about that - not sure what happened. I have let SimMarket know and they should send you a registration key, otherwise I will PM you one later. John

I'm not too sure either as I've never had a call to use them. John knows about them, so I'll ask if he can h To create links, the easiest method is to install the Link Shell extension, which will enable you to create links using windows Explorer. See https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html John

@Knox1423 Thanks for the update.

Check the log file and you will most probably find that it is MSFS that is crashing an FSUIPC7 is exiting normally due to MSFS no longer being detected. Also check the windows event viewer, and you will almost certainly see a crash event relating to MSFS. If this is the case, there is nothing I can do about this and you need to check the Asobo forums and/or raise a CTD bug report with them, including any relevant information (event viewer report + any crash dump files). John

a CTD with FSUIPC7 or MSFS? Please make sure that you are using the latest version of FSUIPC7, v7.2.10, and show me your FSUIPC7.log file after the crash. Also check the windows event viewer from crash/error reports. John

There are currently some known problems with altitude hold in MSFS since the SU5 update- see https://forums.flightsimulator.com/t/altimeter-problems-altitude-hold-and-atc-altitude/433209 https://forums.flightsimulator.com/t/help-with-incorrect-high-altitude-altimeter-setting/429439/4 This has been reported several times, e.g. see John

Necesita instalar los redistribuibles de VC ++ desde: https://support.microsoft.com/en-in/help/2977003/the-latest-supported-visual-c-downloads Primero desinstale si ya está instalado (del 2015, 2017 & 2019), luego instale las versiones x86 y x64. Consulte la documentación. He validado sus dos claves y están bien.

Do you mean 0xc0000022? If so, please see Try installing (or uninstalling then re-installing) the VC++ redistibutables, as explained on the provided README.txt: John

Did you read the section Invalid Key Problems from the Installing and Registering FSUIPC7.pdf and follow the advise there? If not, please do that, otherwise please let me know your order number and I will check your details here. John

Ah, ok - that makes sense. It doesn't surprise me that a SimConnect.cfg configured for P3D causes issues with MSFS. Thanks for the update. John

A couple of more things about your ini: - you are using the lua scripts for the Alpha/Bravo buttons > 32. You no longer need these as FSUIPC now supports up to 128 buttons natively, so these can be removed - you have assigned your hat to the PAN controls - do these now work? I haven't checked in a while, but previously the PAN controls were not working via SimConnect/FSUIPC. To assign the hat to control panning, you can assign to the keys assigned in MSFS to control the views. John