John Dowson

You can use the MF WASM if you want to use those events, but the events are translated by the MF WASM and to calculator code which can simply activate lvars/hvars/etc, although some of the code is more complex. You can see what calculator code each MF event uses using the preset app list here: https://hubhop.mobiflight.com/#/list Check what the MF presets use. Did you try with the G1000.hvar file (included in the HvarFiles subfolder)? This was created quite a while ago now and may be out of date, I'll review those hvar files when I get a chance. The hvars may also be different if using a mod for the G1000 (e.g. the WorkingTitle G1000 mod). What aircraft and/or mod are you using?

👍

Ok, that is interesting. Are you using the latest version of FSUIPC7, v6.2.10? If not, please download and install that version and try again. Only if you are using it, i.e. are using hvars/lvars or calculator code in FSUIPC7 (or in any other FSUIPC WASM clients). This is the first I have heard of an issue with the FSUIPC WASM module. If you have an FSUIPC_WASM.log file (from when MSFS hung), can you please show me that (it will be under the folder AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module (for Steam installs, and think its similar in MSFS store installs, but check the Advanced User guide if you can't find it). There could be an issue if one of the other items in your Community folder is using the same event IDs as the FSUIPC WASM. If this is the case, you can change the event ids used in FSUIPC/FSUIPC WASM 0 by using ini parameters for both the WASM and the WAPI (which is embedded into FSUIPC7). Details are in the Advanced user guide.

That sounds very strange....Do you have the FSUIPC WASM module installed in your MSFS Community folder? If so, first try moving that out of the Community folder. If you still have issues, re-install FSUIPC7 but without the Auto-start component, and try starting FSUIPC7 manually either before or after you start MSFS to see if that works. Let me know and we can go from there. Do you have anything else installed in your MSFS Community folder?

The installer determined that you have a steam install as you still have a steam UserCfg.opt file. Please do the following: - uninstall FSUIPC7 completely using the uninstaller created - remove (or rename) the following file: $APPDATA\Microsoft Flight Simulator\UserCfg.opt (where $APPDATA is your user AppData folder) - re-install FSUIPC7 John

Reply posted in this thread:

The MF WASM module will not give you access to more variables. It will provide additional 'controls/events' (or what MF now call 'presets') what act upon existing variables (A, K, H, L). Not sure about your actual issue - I'll leave that to Paul.

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