John Dowson

Yes, thats the easiest way. Best to do this without FSUIPC running. That will only remove axis assignments for the currently loaded aircraft, so will only affect one profile (the one currently loaded). Yes, but the axis/button assignments are not updated then - they are updated when you close the FSUIPC window (click 'Ok').

First, you posted in the FAQ sub-form, where it states NOT for support requests. I have moved your post for you. Could you attach you FSUIPC6.ini please so that I can see your assignments. Also, activate logging for Axes Controls, and generate a short(ish) log with your a/c loaded and move your assigned elevator axis through its full range, and also move the axis assigned to the tiller through its full range. Close down P3D and attach the FSUIPC6.log file generated. Thanks. Also, which version of ProSim are you using? I don't use ProSim but Pete does, so he may be able to assist further if you let us known the ProSim version.

Only lvars can be accessed via offsets. I wasn't planning on adding hvars to offsets - there is no point really as they don't have a value (so could only be used for activating). I am planning to add an FSUIPC control to activate hvars, which would allow you to assign hvar activation to buttons and switches. But, for the time being, you will have to use either a macro file or lua to achieve this.

It hasn't been fixed yet. There are still issues with basic text display, let alone menus. The SimConnect_Text function is currently documented as: The SimConnect_Text function is not currently available for use. !

I don't think so if its a know issue with the switch. If there is a control (or controls) that is sent with a parameter that you can use to differentiate the OFF position, you could write a lua script to intercept this control (using event.control) and then maintain your own user offset with the correct value, and configure MobiFlight to use this offset instead.

I don't see much point in this, sorry. Yes, I think so. And I don't see this as an issue.

The FSUIPC WebSocket server provides a websocket interface to the FSUIPC offsets. You can't, as far as I am aware, retrieve anything else.

Btw, also check that you have controllers disabled in FSX....

Hmm, strange. Can you show me your latest FSUIPC4.ini and FAUIPC4.log files please.

FSUIPC populates these offsets with the data received from the PMDG SDK. If the value is not correct, you need to raise a support request with PMDG. However, before you do this, best to verify what these offsets actually hold via FSUIPC (not MobiFlight). To do this, use the offset logging facility for offsets 6430 and 6431, both as U8, and check what is logged for the different button positions. Also maybe log offsets 6436 and 6437.

To list the lvars, make sure you have the FSUIPC WASM module enabled, then just use the Add-ons -> WASM -> List Lvars... menu option to see all lvars and their values. Note that more lvars are available the longer the aircraft is loaded - you can issue a Reload command (again, from the WASM menu) to rescan and reload all lvars. [NB. There is also an ini parameter to the WASM called LvarScanDelay which you can increase to delay the lvar scanning - see the Advanced user manual for details on this). For the description of the lvars, you need to check the documentation for the a/c you are using.... However, there doesn't seem to be much of this available, especially for the stock aircraft. However, its usually pretty obvious what they are from the name. Note also that not all lvars are writeable - some are read-only. There is no way (that I know of) to determine if an lvar is updatable - you just have to try. I will also be releasing FSUIPC7 v7.2.0 later today (this has been available as a beta release for a while now). This has an additional facility to populate free user offsets with lvars for both read and write (where applicable). You may want to download and use this, once I've released. John

You could disconnect your device and just remove the registry entries for that device anyway, reboot and re-connect to get them added again. Take a backup of your registry first, and then save the following text in a .reg file (e.g. removeVPCStick.reg) and then execute by double-clicking: Windows Registry Editor Version 5.00 [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_3344&PID_4130] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_3344&PID_4130] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_3344&PID_4130] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_3344&PID_4130] As I said, I'm not sure if this is the issue or will help, but worth a try. Otherwise, just continue to use device 1, thats not really an issue.

Not unless provided by the aircraft, i.e. this data is available for the PMDG airliners via the PMDG SDK (for FSX and P3D). There is no provision in the SimConnect API for such data, so I don't think this info is currently available for any MSFS a/c.

No problem, updated again!

Ah, ok. I don't know why this is and cannot really look into it as I don't have such a device. Could it be that it has multiple registry entries (just a thought)? Anyway, if it works with device 1, just use that.

I think the second argument to the com.readfeature call should be the report number, so try gt, n = com.readfeature(dev, Report) Maybe also try setting Report to 1 (which is the default), rather than 0, in your init section (of 0 does not work). I'm not sure why this should be if you only have one of those devices....

If you are using the FBW mod, you can use the lvars: A32NX_RMP_L_SELECTED_MODE A32NX_RMP_R_SELECTED_MODE which hold 1,2 or 3 for the left/right RPM, where 1 indicates VHF1, etc. For the stock A320Neo, you can use the following lvars: XMLVAR_RMP_L_CURRENT_BUTTON_IN_GROUP_FREQ XMLVAR_RMP_R_CURRENT_BUTTON_IN_GROUP_FREQ which also hold 1,2 or 3 for the left/right RPM, where 1 indicates VHF1, etc.

Updated!

Yes - you could restrict to just remove the rudder by using the Pid (Product Id) as well, but if you no longer have the yoke there is no problem removing that as well (i.e. just using the Vid to remove all products from that vendor). Make sure that the pedals are disconnected when you edit the registry, and best to reboot afterwards before reconnecting. Not at all!

Just make sure you back up your registry first - just in case....!

Yes, it should be the same. It only mentions windows up to 8 as that post was written in 2014, before windows 10 was released. I should update it....

No, it is not normal but has been reported before. When this occurs, the FSUIPC WASM module cannot be installed as the installer cannot determine the location of your MSFS Community folder. Did you run MSFS at least once before attempting to install FSUIPC7? If not, uninstall FSUIPC7, run MSFS, stop MSFS and then install again. If you get the same issue, check the location of the file to see if it is correct (can you see the UserCfg.opt file at that location?) and of so open the file in an editor to see if you can read it ok. If you get the same problem, please show me your InstallFSUIPC7.log file, and let me know what MSFS version you have (steam, MS Store or boxed).

Did you select to install the desktop icon, checked by default, at the end of the installation process? If so, I cannot see how it cannot be installed...could it have been quarantined by windows defender or some other anti-virus software? Is the MSFS.bat file created? There is no harm whatsoever in re-installing every time. And this needs to be done for various reasons (i.e. keeping documentation up-to-date, and now, more importantly, making sure the FSUIPC WASM module version is compatible with the FSUIPC7 version. As I said, I only provide stand-alone executables for beta releases for test purposes.

I will check this. I am planning on moving these gauge events to simconnect events at some point - been meaning to do this for a while but just not found the time yet. Thanks for your report.

You shouldn't have done that unless you are planning on using it! Can you reproduce the OP's problem? I've taken a quick look but it seems ok here. But I'm also running v7.2.0 with WASM 0.5.1. Thats why I would like to release these ASAP (tomorrow) to see if that makes a difference. Also the latest update to the CRJ implements throttle control via its own simconnect connection, so I'd like to investigate how throttle assignment works for this a/c. May be issues with priority levels if assigned and calibrated in FSUIPC (as with PMDG a/c), but not sure....