John Dowson

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

Ok. No idea why these aren't recognised, but at least you have an alternative solution.

👍

I will now handle this... I have managed to clone the project and build it. You need VS2017. Tomorrow I will transfer it to my GitHub account and give you access there. I'll post the new URL when done. John

I am sorry but I do not understand what you are trying to say here... Your log is far too large for me to go through....why do you have Axes Controls logged? I just need to see what, if anything, is logged when you close the fsuipc window. Can you open the logging console (Log -> Open Console) and watch that to see what is logged when you close the window, and paste those log messages. Also, does this happen only with the button assignments window? What about the axes or key assignments window? Does it also happen when you click cancel, or only when you click ok?And why do you need to be opening this window all the time? FSUIPC doesn't send anything the the FS when you open close fsuioc window, so I really have no idea what is going on on your system.

If it is working, what is the problem? You can add the server name or ip address if you like, but make sure you are using the correct parameter - ServerName if using the name, ServerIPAddr if using the address. John

Not necessarily...but you can always assign a button to a key press that is assigned in MSFS. You usually only use this technique for internal events that are either not working when sent from an external application (such as these), or for events that are not exposed by the SDK for use by external applications.

Simple update - see attached (untested!). Glad this is working for you! Regards, John spitfireBrake.lua

I know what SIOC is, of course, but never used it and don't know what ' the SIOC Connection to FSUIPC' is. ok, thanks for the update. John

As I said, please provide your FSUIPC7.log file with the suggested logging activated and showing your issue, together with your FSUIPC7.ini. i.e. activate logging for Buttons & Keys as well as Events, reproduce your issue, exit FSUIPC7 and then attach your FSUIPC7.log and FSUIPC7.ini files. John

Did you also login with your Microsoft account? I have just checked, and the repo is still private. If you let us know your microsoft user account name, @Pete Dowson can either add you to the project, or make the repo public (it is up to him!). John

First, your WideClient is out-of-date (7.146) - please update to the latest version, 7.155. Your WideClient.ini has this: That is NOT the server name - should be: ServerName=DESKTOP-OVELNI8 or use ServerIPAddr=169.254.207.245 Try using the name first, and if that doesn't work switch to using the address. Also, please check your firewall settings (or disable all firewalls, client server and router, to test) - you may have added an exception for P3D and need to add one for MSFS. John

And the logs after quitting FSUIPC7? I need to see all 4 files together from the same session.