John Dowson

This issue is very puzzling - FSUIPC behaves the same no matter when it i started. I have also taken a look at the 310 and cannot duplicate this behavior. The log file you attached shows that nothing was seen or sent by FSUIPC during the session, which only lasted just over a minute and a half. I see you are using an ipcReady.lua - what does this contain? Maybe you could show me that. That will be the only thing that is ran, but this also should run when FUIPC is already running when you load an aircraft, or if you start FSUIPC7 with an aircraft already loaded and ready-to-fly. Maybe you could take a short video showing this issue, and how it starts/stops when FSUIPC is ran/exited. Thanks, John Later: are you using the Airbus A310-300 Enhanced add-on?

What version of FSX is this? The latest version of FSX-SE should be 10.0.62615.0 (excluding the latest beta) - can you see if you need to update (but not to the beta!)? You need SimCommect for version 10.0.62607.0 - did you install that one (successfully)? This does look like a simconnect issue. After you have checked if there is an FSX-SE update, can you try re-installing FSUIPC4 and try again. If you get the same issue, please show me the InstallFSUIPC4.log file. John

Did you see anything registered in the Axis assignment page? Sometimes another axis may be detected first - if this happens, just click the Ignore Axis button and try again. If the rudder movement is detected in the calibration page, then it must be assigned somewhere, and if its not assigned in MSFS then it must be assigned in FSUIPC. I need to see a log file showing your issue, and with logging for Axes Controls activated. So, can you please start MSFS/FSUIPC7, load an aircraft and then activate logging for Axes Controls, move your rudder axis through its full range, then exit FSUIPC7 before attaching your FSUIPC7.log and FSUIPC7.ini files. John

The better/easier way to do this in MSFS is to use preset controls. For example. to move the Transponder Mode Selector to the TA/RA position you can assign to the preset PMDG B737 TCAS MODE TA RA. Please see the MF HubHob site (https://hubhop.mobiflight.com/presets/) for a list of available presets. and also the section on using presets in the Advanced User guide (WASM section). These are the available presets for the PMDG TCAS, all of which should be available through FSIOPC7: Offset 0x6596 is a 2-byte offset for LTS_LandingLtFixedSw, so offset 0x6596 will be 1-byte containing the state of the left light, and 0x6597 is 1 byte for that of the right light. You can read it as two bytes, as you seem to be doing, and doing that will give the values you show, For the lights option position switch, you could try reading offset 0x65A0 which is LTS_PositionSw, and has values 0: STEADY 1: OFF 2: STROBE & STEADY Otherwise, I would ask about this on the PMDG support forums. If you do post there, best just to mention the SDK variable names rather than FSUIPC offsets, and refer to the SDK rather than FSUIPC - otherwise they will just refer you back here! John

Can you please attach your FSUIPC7.ini and FSUIPC7.log files, the latter showing this issue (i.e. attached once you have shutdown MSFS and FSUIPC7 still running. I don't know...very strange... Are you running MSFS/FSUIPC7 with standard privileges or with Admin privileges? John

The FSUIPC7 documentation is installed with FSUIPC7, into your Windows Documents folder. There should also be a link to that folder under your FSUIPC7 installation folder. Note that the documentation for presets is in the Advanced User guide, under the WASM section. You don't need to do anything with the code (calculator code). You just assign as normal, but using the checkbox Select for Preset and not Select for FS control. Presets are a mechanism to send calculator code to the FS, and those provided are from the community effort, led by MobiFlight, and available from their HubHop server - see https://hubhop.mobiflight.com/presets/. Please see the Advanced User guide for details on using presets. John

Don't worry - it will (probably) take me a few days before I get a chance to look at this in detail anyway... John

No such version - the latest (and only supported) version is 7.3.15 (maybe a typo?). Auto-connect and auto-start are two distinct things... Auto-start is enabled when you install FSUIPC7, if you opt to install this component - it is installed by default and will only not be installed/enabled if you uncheck the auto-start box during installation. There are many support requests on auto-start, and I have summerized all possible causes and solutions in the following FAQ entry, so please refer to this: Please also see the README.txt file (included in the FSUIPC7 zip file you downloaded), which contains the following: John

Good news! I really wouldn't worry about that - it is only a warning. I also get these for a couple of my devices - it is not an issue. You could try the same procedure using the VID and PID for that device, but it is quite possible they will be added again when you re-connect. John

No, it will remove them - note the minus sign (-) in front of the entry. Double-click on the filename (in Windows Explorer) to run it.

Yes, probably either a registry or driver issue I would suspect... It will be an issue with the device, not FSUIPC. FSUIPC only stores version and installation location data in the registry, and this is removed when you run the uninstaller. You could try cleaning the registry of the device entries. Unplug the device, and uninstall any drivers (if you have manually installed any drivers. Then run the windows registry editor and first take a back-up of your registry and then exit. Then create a text file with extension .reg (e.g. removeZapBox.reg) with the following content: Windows Registry Editor Version 5.00 [-HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_0483&PID_4444] [-HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_0483&PID_4444] [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_0483&PID_4444] [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_0483&PID_4444] That should remove most entries, but you may also want to run regedit again after doing this and search for any entries with vendor/VID of 0483 and a product/PID of 4444 and remove them. Once done, reboot you machine and then re-connect the device, and let Windows install default drivers and then try again. John

You can assign an axis to multiple controls in FSUIPC. However, it is not possible to assign to "Translate Drone Forward" as this event is not exposed by the SDK, and so not available in FSUIPC for assignments. If there is a K event available, it may be possible to create an assign to a preset for this, but I'm not sure without investigating. I can take a look at this tomorrow 9or Monday), but for the time being it may be easier just to assign your Elevator in FSUIPC and assign to "Translate Drone Forward" in MSFS. John

Please activate logging for Events, load the A310 and reproduce your issue, then exit FSUIPC7 and show me/attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. I will also check this here.... John

This is a technical issue in the way that I have implemented the passing of lvar/hvar names from the FSUIPC WASM module to FSUIPC (using the WAPI - the WASM Application Programming Interface). This is really quite technical... all lvar names are passed across in Client Data Areas (CDAs), which have a maximum size of 8K. Therefore, the maximum number of lvar names that can be sent in this area depends on the size (number of characters) in the lvar name. And the number of lvars handled depends on the number of these CDAs that I enable. The 2nd restriction is on how the lvar values are passed. All lvar values are passed in each update (whatever that is designed to be). therefore there needs to be enough space for the value CDA's to hold the data for the number of lvars available. These things are changeable up to a point.... Currently, these are the sixes defined for the WASM/WAPI interface: #define MAX_VAR_NAME_SIZE 56 // Max size of a CDA is 8k. So Max no lvars per CDK is 8192/(this valuw) = 146 #define MAX_CDA_NAME_SIZE 64 #define MAX_NO_VALUE_CDAS 3 // Allows for 3*1024 lvars #define MAX_NO_LVAR_CDAS 21 // 21 is max and allows for 3066 lvars - the max allowed for the 3 value areas (8k/8) is 3072 #define MAX_NO_HVAR_CDAS 4 // We can have more of these if needed So, the maximum size I allow for an lvar name is 56 characters, As each CDA is 8k, this means I can pass (8*1024)/56 = 146 lvar names in each CDA. I am currently allowing 21 lvar name CDAs, which allows for 21*146 = 3066 lvars. The number of CDAs for the values of these lvars is then sized accordingly, so each lvar CDA can support 1024 lvars (8k per CDA, 8bytes per value). and so 3 lvar value CDAs are needed to support 3066 lvars (although they can support i[ to 3*1024v = 3072 lvars if needed). The way this was implemented was done after trialing various different mechanisms, including using one CDA to pass lvar names repeatedly, and another to pass values. However, there are various issues with this as you have to consider multiple clients connecting at different times, and the data must be consistent with all clients, regardless of the time they connect, and also regardless of other clients using the WASM facilities (the WASM provides an API and can be used by many clients at the same time). If you need further information on this, the WAPI is open source (available on GitHub) and you are welcome to take a look and suggest any improvements. John

It doesn't - there is no version of ActiveSky that supports MSFS. I do not know or understand how AS interacts with ProSim, as the OP is using it - but then I don't know much about ProSim anyway! I believe there is a version of REX available for MSFS, so weather control is possible. Not sure if there is an AS version under development for MSFS or not at the moment - seem to be a lot of contracting posts on this, and most quite old now. Not sure what you are referring to here - I see no thread the OP referenced... John

MSFS added radar/map capabilities in a recent update (SU9 or SU10 I think). These facilities are only available to WASM modules via the MapView API - see https://docs.flightsimulator.com/flighting/html/Programming_Tools/WASM/MapView_API/MapView_API.htm. Therefore it is quite possible for aircraft (and other WASM modules) to use this API to generate various map types. At some point, when time permits, I will look into this to see if I can make something available via the FSUIPC WASM module to support map file generation - and independently of Active Sky. John

No problem. To clarify what the issue was, the TBM930 has issues with the throttle when controlled externally via the SDK/SimConnect. The throttle does work, but the throttle animation in the VC does not work. When you assign the throttle un MSFS, there is no such issue. However, if you still have the throttle calibrated in FSUIPC (but assigned in MSFS), FSUIPC will take the throttle input from MSFS and mask it (i.e. not let the sim act upon the event) and then re-sends the calibrated value, thus the input for the throttle is still going via the SDK/Simconnect, and the animation will again be broken. Cheers, John

You have the throttle calibrated in FSUIPC: Throttle=-16384,16383/8 Throttle1=-16384,-16384,-16384,16383/8 Even when assigned in MSFS, FSUIPC will still calibrate if you have that enabled. Try deleting those lines from your FSUIPC7.ini file (when FSUIPC7 is not running) - under [JoystickCalibration], and try again. Can you also try with a different aircraft. There are known issues with the throttle visuals in the TBM930 - there are several reports on this already. If you still get issues, can you activate logging for Axes Controls, load an aircraft and move the throttle through its full range and then exit, and show me both those files again. John

No, not at the moment. I didn't know Active Sky was available for MSFS....! I will take a look at some point and see if it is possible to re-enable this functionality in FSUIPC7, although I am not sure when I will have time for this at the moment so it may take a while. John

Hi @BrianT, I am having some strange issues moving the project to GitHub. It may be easier if I just add you to the Azure project for the time being. Could you let me know your Microsoft user name and email and I will try and add you. Thanks, John

Thanks for this. Note that there are also several presets available to control the fuel cutoff levers in the PMDG 737: PMDG_B737_ENGINE_START_LEFT_LEVER_CUTOFF - maps to 68802 (>K:ROTOR_BRAKE) PMDG_B737_ENGINE_START_LEFT_LEVER_IDLE - maps to 68801 (>K:ROTOR_BRAKE) PMDG_B737_ENGINE_START_RIGHT_LEVER_CUTOFF - maps to 68902 (>K:ROTOR_BRAKE) PMDG_B737_ENGINE_START_RIGHT_LEVER_IDLE - maps to 68901 (>K:ROTOR_BRAKE) as well as the following which check the position of the lever before sending the control (which helps in keeping the levers in sync with the VC): PMDG_B737-7_FUEL_CUT_OFF_LEVER1_DN - maps to (L:switch_688_73X) 0 == if{ 68801 (>K:ROTOR_BRAKE) } PMDG_B737-7_FUEL_CUT_OFF_LEVER1_UP - maps to (L:switch_688_73X) 100 == if{ 68801 (>K:ROTOR_BRAKE) } PMDG_B737-7_FUEL_CUT_OFF_LEVER2_DN - maps to (L:switch_689_73X) 0 == if{ 68901 (>K:ROTOR_BRAKE) } PMDG_B737-7_FUEL_CUT_OFF_LEVER2_UP - maps to (L:switch_689_73X) 100 == if{ 68901 (>K:ROTOR_BRAKE) } Also, with the PMDG 737 you can use the Rotor Brake control, but that has certain restrictions as the single parameter represents the button/switch as well as the mouse operation to control that switch. Rather than using the Rotor Brake control, you can use a custom control number instead. See the following FAQ entry on using custom controls for PMDG aircraft (also valid for FSX and P3D): Also, this FAQ entry shows how to calculate Rotor Brake control parameters from the PMDG 737 SDK for general use (although the custom control method us more complete): John

Sorry, been rather busy today, I will get on this case tomorrow... John

Please attach your FSUIPC7.ini and FSUIPC7.log files - the latter when you have an aircraft loaded that is not the Fenix A320 and when you suspect that the profile for that aircraft is being used. Also, I suggest you read the User guide section on profiles, and how it matches the aircraft name to the profile based upon substring matching (which is the default matching strategy). John

If you assign to the FSUIPC Steering Tiller axis (i,e, with 'Send direct to FSUIPC calibration') then blending between the rudder and steering tiller is performed, and the amount of blending controlled by ini parameters MaxSteerSpeed and RudderBlendLowest - see the inset box in page 30 of the FSUIPC7 User guide for details, and the Advanced User guide for a description in how those parameters are working. If you don't want any blending, assign with 'Send to FS as Normal Axis', and maybe use Axis Steering Set rather than Steering Set (you can try both to see which works). John

There are a few scripts already available - see: I haven't looked at this for a long time and am not sure what the best script to use i at the moment. If you try them, please report back and I'll clear up the FAQ section to make it clear what script and maybe the differences between the script. There is also the AFC_Bridge app (community add-on) provided by Aerosoft, available here: https://flightsim.to/file/5514/honeycomb-bravo-more-working-lights John