John Dowson

Ok. Didn't sound like it from your description... Most manuals are written for users, not developers. The developer manuals are part of the SDK. Please at least peruse the Installation and Registration manual, and better before installing. You should also take a look at the User manual, just to have an overview of the functions provided. Then just consult the manuals as and when needed. You issue is a common one and there are already many posts on different ways to solve trim sensitivity. Try searching the forum for various solutions, or post again if you have difficulties. But please consult the provided documentation before posting questions - we provide a lot of documentation to try and reduce the number of support requests, especially for common issues. John

Yes, I moved your post to the FSUIPC7/MSFS support forum. In the Community folder? You should NOT install FSUIPC7 in the Community folder. Only the FSUIPC7 WASM module gets installed into the community folder. Is there...how strange! What is that menu? Nothing to do with FSUIPC7, which is a completely separate application from MSFS and has its own main window and menu bar. Well, as I don't know what that menu is, I suggest that you first read the README.txt and the Installing and Registering FSUIPC7.pdf documents, both included in the zip file that you downloaded. Then take a look at the User guide (which will be installed under your windows Documents folder, in a sub-folder called FSUIPC7). Thanks, bur we always recommend you install and use with the trial license before purchasing (available in a sticky post at the top of this sub-forum)if only using for a specific function. Too late now, but you should be able to sort your issue with FSUIPC7.... John

As Pete has said - but you should really leave a space after the 'lua', i.e. ...as Pete has already commented. John

Yes, doing that would run MSFS as admin which would then run FSUIPC7 as admin. It does sound like permissions issues, and it is strange if this is on a non-C drive. Maybe try moving it to another location/drive to see if you get the same issue. Not a good idea to run FSUIPC if it can't create the logs, as this means that it also can't update your .ini, so no assignments can be saved. I see you are also using Windows 11. Be aware that I haven't tried/tested FSUIPC on windows 11 yet.

You need to start the TrippleUseLia (or, in your case, zelTripleUse.lua) from the [Auto] section of your FSUIPC7.ini - see the Advanced User guide if you don't know how to do this. It will then run when you start a flight and handle the button presses. Looks like you are starting it on a button press, which is not really applicable to this type of lua - it should be running all the time. So please try that first. If you still have issues, can you please show me a full FSUIPC7.log file, not a continuation log, and also attach your FSUIPC7.ini. John

You could try using the attached WASM, which will work with hvars not preceded by 'H:'. Just replace the file in your Community/fsuipc-lvar-module/modules folder: FSUIPC7_WASM.wasm Also replace the layout.json file (in the /fsuipc-lvar-module folder) with the following: layout.json

Yes, thats fine, as the aircraft title is "Cessna Skyhawk G1000 Asobo" and so has 'G1000' in the title, so the jvar file is loaded. The problem is with the G1000.hvar file. You need to add a 'H:' before each hvar name. I will correct this in the next WASM release so this is optional (and the provided hvar files will work as is), but for the time being make sure that each hvar name in your .hvar files are preceded with 'H:'. John

What has this got to do with the Tripleuse.lua? To use that, simply change the joy and btn variables in the script, as well as the control numbers you wish to use for the single, double and long press. And to see what is happening if you have issues, enable lua debug logging (as well as events) and take a look at the log. And so what has this got to do with the TripplrUse.lua? That is for three actions on the same button (hence triple use!). The assignments you posted are compound assignments to button 16 which depend on the state if button 29, and standard assignments to buttons 34 and 38. What isn't working with that? Try logging buttons & keys as well as events to see what is happening. Note that if button 29 is not a switch or sticky button (i.e. it sends a press followed by a release directly) then maybe the button is always unpressed so you only get the one action. If this is the case, you should use a flag condition instead (see P21 of Advanced user guide). But logging should tell you what is happening.

Did you rename the hvar file so that it is loaded with the aircraft you are using? To check, can you see the hvar in the Add-ons->WASM->Activate Hvar... menu item, and if so does it work there? If not, please let me know the aircraft you are using + any mods and I will check here. Ah, ok. I haven't checked with the WT G1000 mod. However, it is strange that it works via calculator code and not using the hvar directly. I will check this tomorrow and get back to you. John

Yes - the simconnect log was only to check if you were reaching the connection limit. From your symptoms, I doubt very much if this is the case, so I wouldn't worry too much about it. Just change the maxClient entries to 128 and leave it at that. If it still crashes (which it will most probably do)m then you need to report to Asobo, as I said: There is really nothing more I/we can do with this, but please report back if you find out what is causing your issue. John

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