John Dowson

You can always download and use the latest events.txt file from MobiFlight. That's ok in this instance, but usually better to use the myevents.txt file to add your own presets, as the events.txt file will get overwritten on the next FSUIPC7 update. Do you have the WASM module enabled (Add-ons->WASM->Enable) - if not, do that - you only need to do this once (you will need to disconnect/reconnect to MSFS when you do this). To test presets, you can use the Add-ons->WASM->Execute Calculator Code... menu option. Try that - if it doesn't work, then the preset is invalid and I can't reallu help you with that (try the MobiFlight Discord channel, or support for the aircraft). Ifthat is working, then there is something wrong with your assignments. Try activating logging for Buttons & keys and Events, open the logging console and see what is happening when you press the assigned button. You can attach your FSUIPC7.log and FUIPC7.ini files here if you require further help. John

Note there is also a user contribution to get keyboard input via lua for FSUIPC7 / MSFS - see No keys should go through to the sim if the sim does not have the focus - you should give (or acquire) the focus to your input window to prevent this. And I can't understand how some keys assigned in FSUIPC can go through, others not...could you please elaborate and perhaps provide an example. Anyway, I presume you are using the event.key lua function to get keyboard input, no? If so, then if you look at the documentation for this function you will see the following: I am not sure how relevant this ini parameter is now (as FSUIPC7 receives keyboard input from the FS when the FS has the focus), but you could try that. Otherwise, please show me your lua script and provide more details and I will take a look. John

No, you don't need WideFS6 and that is also no longer available for purchase (a free license is available, as with FSUIPC3). However, if you need a 32-bit WideClient, you can get that from the WideFS6 package/download. But I am now confused...I thought your connection problem was with FSUIPC4/FSX, not FSUIPC7/MSFS2020... Please check the files yourself before sending them to me. For example, have you configured the server name or IP address for WideClient? If you had this working for FSUIPC3/FS2004 and WideFS6, the configuration / set-up should be the same/similar for FSUIPC4 and FSUIPC7... You should also check the WideFS documentation first for connection issues and solutions, although this is only available in English I'm afraid. Note that FSUIPC7 can also be used on a client computer - details on this are in the Advanced User guide (appendix 4), which can be used instead of WideClient (on a 64-but machine). John Regards, John

You posted in the .Net client dll sub-forum - I have moved your post to the main support forum. The WideFS version for FS2004/FSUIPC3 was WideFS6. You need WideFS7 for FSUIPC4, which requires its own license. However, if it shows up as registered, I guess you are using WideFS7, no? Note that if running WideClient on a 32-bit computer, you will still need to use the 32-bit WideClient from WideFS6 on your client machine. What do you mean by 'cannot connect to Flight Simulator'? WideClient connects to WideServer (built into FSUIPC4), not to the Flight Simulator. It is FSUIPC4 that connects to the Flight Simulator. If WideClient cannot connect to WideServer/FSUIPC4, then you may need to configure the server name or address in your WideClient.ini file. Check the documentation for details. If you have any further issues, please show me your WideServer.log, FSUIPC4.log and FSUIPC4.ini files from your server/FS computer, and your WideClient.log and WideClient.ini files from your client computer. John

top-left of the calibration page... Ah, ok...

But you don't need hvar files to use presets - just the events.txt file installed (by default) in your FSUIPC7 installation folder. You only need (FSUIPC) hvar files for direct access to hvars (via lua or macros) - they don't need to be made known to FSUIPC is activating them via calculator code, such as used by presets. That is fine but it is more usual to send the control on a press ('P') rather than a release ('U'). Having small increments can also be a pain when you have to change the amount by a large number, which is why its usually to also assign buttons to the fast controls. If using a 2-button rotary (ie. one button in each direction), then there is a lua script you can use to convert this to 2 virtual buttons in each direction, where one is used for slow (1) increments), and the fast button for larger (10 or more) increments. John

First, you have PropPitch1 assigned to two axes: This invariably causes issues due to different/conflicting values being sent by each axis. Also, this is incorrect: Hence the error in your log file: This (most probably) should be: Please see the Advanced User guide for details on the format and size designators you should be using. And always check your log file if/when adding lvars to offsets to check that it is being added as expected. Apart from that, the log shows the PropPitch axis behaving as expected. It would be useful to see the second log, but I think your issue could be that you are calibrating with a reverse zone - if there is no reverse zone, you need to check the No reverse Zone checkbox in the Prop Pitch calibration panel - try that. John

👍 Thanks for reporting back.

The [Auto] section is used to start/run the lua. This is used for luas that are not ran activated on a button press, but use one of the lua event.* functions to wait for an event. The Rotaries.lua uses the event.timer function to poll for the button states. Of course, you don't have to auto-start the lua if you don't want to, but it needs to be started somehow so that it can poll for the state of your rotary buttons. You usually do this from the [Auto] profile-specific [Auto.xxx] section, but you can always start it on a button or key press, but it makes more sense to have this script auto-loaded. John

👍

You should not manually change that section - it is automatically managed by FSUIPC by scanning for lua files in your installation folder. What works? Then add/create one! What is your lua file called - isn't it Rotaries.lua? If so, then it is not in your FSUIPC7 installation folder. If you called this file currheading.lua (which you shouldn't, as it controls/changes the rotary, not what you have assigned the rotary to do) then it should automatically appear under your [LuaFiles] section, and you should not need to add this manually... John

You are using v7.3.4 - please update to the latest version, v7.3.6, and try again. There was a fix in that version that could cause a crash (timing issue related to WASM use). If you still get a crash with this version, please also attach your FSUIPC7.log (zip it if too big to attach as-is) as well as the crash event information. Thanks, John

Well, it won't as it is an ini parameter for the FSUIPC WASM module, not for FSUIPC itself, i.e. it goes in the FSUIPC_WASM.ini file, not the FSUIPC7.ini file. Please read the documentation as suggested, the WASM section in the Advanced User guide. The ini parameters and file locations are explained there. John

Do you have the FSUIPC WASM module enabled (Add-ons->WASM->Enable)? If not, do that (you only need to do this once) and then disconnect and reconnect to MSFS. Otherwise, please show me your FSUIPC7.ini and FSUIPC7.log files, the latter generated with logging for Buttons & Keys as well as Events activated. That preset just activates a hvar - you can also check this is working by using the Add-ons->WASM->Execute Calculator Code... menu item, entering the text: (>H:H145_SDK_ECP_MAIN_1_FLIGHT) If that doesn't work, then the preset is not correct....You can use that menu option to check the preset code is working and should be the first test to check a preset. If its working using that, then it is a problem with your assignments. John

You have to edit the Rotaries.lua to specify the correct device/joystick id and also the button numbers that your rotary uses. You also have to have the lua auto-started by adding it to the [Auto] section of your FSUIPC7.ini file (see the section Automatic running of Macros or Lua plugins in the Advanced User guide). Once the lua is configured and running, you can then assign to the virtual buttons you see in the Buttons assignment panel when you turn your rotary. If you see the original button numbers instead of the virtual ones, you can use the IgnoreThese ini parameter (in your [Buttons] or profile-specific [Buttons.xxx] section) - again, see the Advanced User guide for details). John

Can you show me your FSUIPC7.ini and FSUIPC7.log files please. For the log file, activate Axes control logging, load your aircraft and move your assigned propeller axis through its full range, then exit FSUIPC before attaching (zip it if its too big to attach). A 2nd log file would also be useful, also with Axes logging activated, but this time use the cockpit UI controls to move the propeller levers through their full range. John

But what exactly is your issue? I presume @sehadi's problem was his assignments, as I indicated, but as he has not responded I cannot be certain. [Also, use the '@' notation if you want to direct your message at a specific person!] Maybe you can explain you issue and show me your FSUIPC7.log file with appropriate logging activated (Buttons & Switches and Events) where you load the aircraft and press your assigned buttons. You should also remove your general button assignments to the Fenix A320 presets - no point in having those as they will/should only work with the Fenix. Also maybe change the name of the aircraft in your profile to catch more variants, i.e. change to John

You posted in the FAQ sub-forum where it states NOT for support requests. I have moved your post to the FSUIPC7 / MSFS2020 syb-forum. No - this information is not available via the SimConnect SDK (or any other SDK) as far as I am aware. John

Yes, I think it was. Thanks for the feedback. John

Hi Andi, Lvars are automatically loaded in the WASM when an aircraft is ready to fly, and are passed to FSUIPC. What I suspect is happening is that some of the lvars you are using are not available when the lvar scan is performed by the WASM. Many lvars for complex aircraft/airliners are created some time after the aircraft is actually loaded/. When you list lvars, an automatic rescan/reload is performed, and so further lvars are discovered. What you need to to is to adjust the LvarScanDelay WASM ini parameter - see the Advanced User manual for details. This defaults to 5 seconds, but for complex airliners this needs to be increased to 45 - 60 seconds. Note that no lvars will be available until this time limit is passed. John

Yes, please try that first, before putting the blame on FSUIPC... If you have issues loading your Community add-ons with an MSFS update then you should clear your community folder (and MSFS cache) and then add then back one-by-one to see which is the culprit... John

Its ok here. What else do you have in your Community folder? What aircraft are you using? Are you using the latest version (7.3.6)?

The Wnd library knows nothing about displays - it just uses the virtual desktop coordinates which are translated to your displays by windows, and the HOME display will determine the origin of the virtual desktop coordinates. The coordinates are stored in the [ExtWindow] section of your FSUIPC7.ini. You can move the window between displays (i.e. change its coordinates) by giving it the focus and then using shift + arrow keys. The new position will be saved and use the next time. So you can reposition if you change your HOME display. John

You can assign to the axis control Anti Ice Gradual Set Eng1. You can see this is when you activate logging for Axis Controls, open the logging console and move the carb ice lever in the cockpit UI.

It is available and valid until 29th June. You may not have seen it as a new member awaiting approval - try now. John