Leaderboard

A brief note to thank your and Pete for your wonderful FSUIPC product. I've been using it for about 20 years and have found it superior for controlling my aged CH products. They are still working in spite of their aging POTS while FSUIPC irons out the bumps and jerks of the old systems. Keep up the good work! Jim Driskell

This really shouldn't happen... I have realized that I made a mistake with the 7.4.18 release...I have been testing the SDK for MSFS2024 and accidentally built the final release of 7.4.18 with the SDK from this version, instead of the version for MSFS2020. Sorry about that - I have corrected this now and have updated the installers with this correct build. Could you therefore please re-download and try again. if you get the same issue, please show me / attach your FSUIPC7.log file. Note that I have kept the version number the same, at 7.4.18, but the build date has been updated to 3rd November, so please check thar you are using this version (you may need to clear your browser cache to download this version. I have also attached this version below, but you should really re-install as the WASM has also been rebuilt. You can prevent this by setting the following ini parameter under the [General] section of your FSUIPC7.ini file: OpenOnStart=Never John

Hello Aurel42, You can add the Lvars to myevents.txt and set a Parameter to convert them: If you don't have a myevents.txt in your fsuipc folder, simply create one, then paste in: // Blacksquare Duke Mixture BS_Mixture_1#$Param 327.680 / 50 + (>L:BKSQ_MixtureLeverPosition_1) BS_Mixture_2#$Param 327.680 / 50 + (>L:BKSQ_MixtureLeverPosition_2) This will work for an Axis like the Honeycomb brave which has a range of -16384 to +16384. Then assign your Axis by selecting Send Preset to FS and select the Mixture. If your Axis is inverted, you can inverse them by adding ,*-1 to the Axis in your Duke Profile f.e. 3=LU,256,F,PBS_Mixture_1,0,0,0,*-1 -{ TO SIM: Preset Control }- Btw, the Lvar range is 0-100 for the Mixture. Hope this helps and have fun with the Duke. Andre

Hello Fabio, At first, I had a similar problem mapping my yoke and rudder controls to SWS PC12 aileron & rudder axes. I found out thru their Discord channel they use the Lvars: L:ARI_AileronInput and L:ARI_RudderInput to control these axes. I use FSUIPC7: Axis > "Send to Offset" to map each control (ie yoke and rudder pedal) and use a lua event-driven program to read the offsets and then write to the Lvars. Please note that their Lvars range is from -100 to +100, so you may need to rescale your control values to match. I've attached my lua file for your review, I hope this helps. Gary PS: To John and Pete, thanks for a great program. Pc12Axes.lua

I have only seen one log file for this issue, but that log file indicates that the call to open the simconnect connection is not returning/completing in the required time-limit (5 seconds), and so it is continually re-connecting to try and obtain a connection. Can those experiencing this issue please try the attached version, and add the following to the [General] section of your FSUIPC7.ini file: DetectToConnectDelayAuto=300 InitialStallTime=30 If you still see lots of messages in the log like this one: then increase the DetectToConnectDelayAuto parameter until these disappear. Please show me/attach log files if this works or not. @GNeild Thanks for the log file - please try the attached and use the following (i.e. add to the [General] section of your FSUIPC7.ini file): DetectToConnectDelayAuto=190 InitialStallTime=10 John FSUIPC7.exe

The ! symbol is the logical not operator so !TRUE is FALSE, and !FALSE is TRUE (or, in RPN, TRUE! is FALSE, and FALSE! is TRUE. So the expression (L:someLvar, bool) ! (>L:someLvar, bool) flips/toggles the value of the lvar, i.e. changes it from TRUE to FALSE or from FALSE to TRUE. John Also explained here: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm

Well then that needs to be looked into and fixed. Is the 'Exit with FS' active/checked? If so, and FSUIPC7 is not exiting cleanly when MSFS exits, can you please show the FSUIPC7.log file.

Hello again, that works very well Thank you very much !! Can be closed. Matthias

I've tried this here using the Key_Press_and_Hold control. It may not do what you're expecting. It doesn't repeat the key until you call the release command. So you don't get the action repeating. You can try it for yourself and see if it does what you're expecting... Just paste this into your code and call. sendKeyHoldToFS - holds the key for the specified HoldTime (in milliseconds) then releases it. sendKeyDownToFS - presses the key down but does not release it. snedKeyUpToFS - releases the key. private void sendKeyHoldToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); // Wait Thread.Sleep(HoldTime); // send the key up SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } private void sendKeyDownToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); } private void sendKeyUpToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } Paul

This one works, John! Matt

And a Happy New year to you as well! John

Hello John, And to confirm above : "my traffic" on ND has also returned with fsuipc 7.5.x ! Thanks for the help. Have a good Christmas and a happy New Year, Regards, Marinus Bergsma.

You should use FSUIPC's logging facilities to work out what is happening. Set logging for Buttons & keys, open the logging console and see what is logged when you press the buttons - this should tell you what is happening. But if button 0 is already pressed when you press button 1, line 34 will NOT be triggered as that assignment is on button 0. Assignments are only triggered when the main/assigned button is pressed/released, not when the compound condition is changed. So, assignment 34 should be on button 1 with the compound condition on button 0 being pressed, i.e. 34=CR(+0,0)0,1,K190,8 -{Key press: .>key}-

Would have been helpful, can't replicate that: - Created a Simple Button Action (Control, 65798, no Toggle) on 0.7.12 - Installed 0.8.4 - Checked Action: Toggle still disabled So for the Moment I can just assume you had actually set a Toggle Switch unintentionally. And that a Setup of Toggle Switch enabled +no Alternate Command+ no Monitor Address + no Monitor Value/Comparison just behaved differently with a on pre-0.8.0 Versions 🤔

Hi Paul, My app is for airline pilots so I am aways using complex aircraft at complex airports. MSFS2024 is still rather flakey so I think I will hold off on further testing until things stabilize more. Thanks for your assistance. Rob

While people in the MSFS forum are complaining about having to spend all that time setting up their controllers, once I got MSFS2024 running, I fired up CLS2Sim (for the Brunner yoke) and FSUIPC, acknowledged the "CrashIO" dialog (haven't seen that for a while), disabled the default layouts MSFS had picked for the devices it recognized, and went flying. I'm sure I'll find problems in time, but having working controls within a minute, that was, for me, the highlight of this launch day. ❤️ FSUIPC ❤️

I haven't got time now to do a proper beta release, will do this tomorrow. but for now can you try the attached version, which is 7.5.0a. This is for both MSFS2020 and MSFS2024. I wo; release this in the Announcements sub-forum tomorrow. John

Thanks for the feedback! You had a better experience than me... Managed to install and ran it for the first time to download the remaining files. I then quit to install the FSUIPC WASM module, but after that I couldn't use it due, I think, to server issues. On the first restart it got stuck at 97% loading, the 2nd time at 0% loading, and then i was permanently in a log-in queue...I gave up after several hours... Seems to load ok today though. To use lvars/hvars/presets/etc, you can copy the FSUIPC WASM module (folder fsuipc-lvar-module) from your MSFS2020 Community folder to your MSFS2024 Community folder. I will be releasing a beta version of FSUIPC7 later today (hopefully!) with better compatibility with MSFS2024, and will also update and release the installer in the coming days. John

The new ATIasHold program with a Image Gallery is here: https://www.intrasystem.it/ATIas/ATIasHold.html Raimund .

That is the install location for FSUIPC5 and earlier versions. From FSUIPC6 and onwards, you must select/choose the installation location - if you don't, a default location will be used - maybe now C:\FSUIPC6 but in earlier versions it was under the P3D add-ons folder, under Documents. John

I experienced the exactly same problem when I had a new programmable keyboard that has rotary encoder, where inputs were very unreliable probably due to the too short interval between keydown and keyup events. After I added " UseKeyboardHook=Yes" to the ini file, FSUIPC works like a charm to capture the encoder input. Thanks!

@Gabe_62 & @Ray Proudfoot: someone has RC4 working (more-or-less!) with MSFS, using ShowText for the menus. See the following post:

Many thanks John, I'll pass details to the other (P3D) user who was having problems.

Sorry, I should have been clearer - would you be able to put the same 'ground altitude' fix into FSUIPC6?

Sorry, yes, of course. As you can see I'm pretty rusty. If/when I get Sky Demon working using WideClient, I will update this post with details.

Thank you again, Paul, I know nothing about programming and your help has really been a lifesaver. I've been at it for quite a long time, 3 or 4 weeks, and now it's working. Here is my code which works and is surely improvable, but it has the merit of functioning. // Accès aux données des réservoirs PayloadServices = FSUIPCConnection.PayloadServices //**************************** Mise à jour des données****************************** FSUIPCConnection.PayloadServices:RefreshData() oFuelTanks est un FsFuelTanksCollection oFuelTanks <- FSUIPCConnection.PayloadServices:FuelTanks SI oFuelTanks = Null ALORS Erreur("Impossible d'accéder aux données des réservoirs") RETOUR FIN //***************** Vérification de la taille de la collection***************** nTaille est un entier = oFuelTanks:Count SI nTaille = 0 ALORS Erreur("La collection de réservoirs est vide") //RETOUR FIN nPourcentageCentral est un entier sur 4 octets nPourcentageGauche est un entier sur 4 octets nPourcentageDroit est un entier sur 4 octets nPourcentageCentral = oFuelTanks:get_Item(FSFuelTanks::Centre_Main):get_LevelPercentage() nPourcentageGauche = oFuelTanks:get_Item(FSFuelTanks::Left_Main):get_LevelPercentage() nPourcentageDroit = oFuelTanks:get_Item(FSFuelTanks::Right_Main):get_LevelPercentage() Info("Pourcentage de carburant dans le réservoir central : " + nPourcentageCentral + "%") Info("Pourcentage de carburant dans le réservoir gauche : " + nPourcentageGauche + "%") Info("Pourcentage de carburant dans le réservoir droit : " + nPourcentageDroit + "%")

No - that is just used for additional/extra logging and should only be added when instructed for investigation of support issues. If that is in the ini file, it can/should be removed, but otherwise just to go to FSUIPC's logging tab and make sure everything is unchecked, and that the Debugging Data field is empty (i.e. is 0 or x0). Further logging can also be performed when the TestOptions ini parameter is used, so if that has been added, that should also be removed.

Read that link on RPN! $Param 16384 + : adds 16384 to the axis input value ($Param) to give a value between 0 and 32768 327.68 / : divides the result by 327.68 to give a value between 0 and 100 near 0 max 100 min: I think near just converrs the result to an integer, and the rest ensures the value is between 0 and 100 (>L:BKSQ_MixtureLeverPosition_1) : sends the result to set the name lvar' value So up is one button, (as seen by FSUIPC), and down another? You can do this in 2 ways: 1. Create one preset: BKSQ_Duke_CowlFlapSwitch_L#$Param (>L:var_cowlFlapSwitch_L) Then assign the press on your up button to that preset with a parameter of 1 and also assign to it with a parameter of 0 for the release, and your down button with a parameter of 2 on press and also a parameter of 0 for release. This is what I mean by 'you give the parameter value in the assignment' 2. Create 3 distinct presets: BKSQ_Duke_CowlFlapSwitch_Up_L#1 (>L:var_cowlFlapSwitch_L) BKSQ_Duke_CowlFlapSwitch_Down_L#2 (>L:var_cowlFlapSwitch_L) BKSQ_Duke_CowlFlapSwitch_Off_L#0 (>L:var_cowlFlapSwitch_L) and assign to those in a similar manner. This is what I mean when I say 'Alternatively, you can hard-code the value into the preset and just use that'.

Yes, you don't want to use the HSI BEARING variable to sync the heading bug. The SDK shows this:

I don't have the GFC500 AP, but the below works with the Flysimware Lear35, and with the C414 which has a Garmin 605 AP. A user defined preset: SYNC_HDG_BUG_TO_CURRENT_HDG#(A:PLANE HEADING DEGREES MAGNETIC, degrees) (>K:HEADING_BUG_SET) or basically the same thing as a one line Lua script called SyncHeadingBug.lua ipc.execCalcCode(" (A:PLANE HEADING DEGREES MAGNETIC, degrees) (>K:HEADING_BUG_SET) ") Al

There is not much documentation on that control as its very straightforward - it just updates the ipcParam lua variable in the script referenced, which will trigger an event,param function, and it can also be passed to a script as a parameter when it is started (to set the initial value of ipcParam). The documentation is in the Lua Plugins document: John

I have no experience with the Longitude, but it seems from the log file entry for the VC button that works you need two parameters both equal to 1 to turn the ext power on. The USB key function that doesn't work seems to be using parameter values of 0 and 1 (which I think is the reason for the two entries), which turns the ext power off. The SDK shows this: So, for example I found: ipc.execCalcCode(" 1 1 (>K:2:SET_EXTERNAL_POWER) ") will turn the external power on, and ipc.execCalcCode(" 0 1 (>K:2:SET_EXTERNAL_POWER) ") will turn the external power off, where the red 1 is the circuit index value (based on the systems.cfg file entry) and the green 1 and 0 are the On & Off data values. However, I subsequently noticed there is an existing FSUIPC7 Preset called LONGITUDE TOGGLE EXTERNAL POWER SWITCH -- why not just assign a key to that (with no repeats)? Also, be aware that not all sim parking places/gates have external power available. Al

No they were not - you pasted images. Please attach the following files (not paste images or contents): From your server PC: FSUIPC7.log, FSUIPC7.ini, WideServer.log From your client PC: WidweClient.log, WideClient.ini Did anything change? Please check the following: - firewalls: maybe temoprarily disable all firewalls (client and server PCs, routers) to see if its a firewall issue - check your WorkGroup names, both PCs must be in the same WorkGroup You can also try adding the ServerName and Protocol ini parameters to your WideClient.ini file. Please see the Configure your Network section of the WideFS User Guide. And see the trouble-shooting notes in the WideFS Technical guide. Also a good idea to reboot both PCs if you haven't done that already. John

But you haven't checked the profile-specific check-box in the calibration tab. Do that to make your calibration specific to the Turbine Duke profile. Once this is done, you will still have the duke calibration in your general profile - you probably want to remove this. But you have! The image you posted shows you have at least configured the throttle axis in FSUIPC, and the assigned is in your Turbine Duke profile.

Thank you very much for the detailed explanation, I look forward to the software update!

I am currently looking into adding/re-activating the PMDG 777 specific offsets. They will be available in the next release of FSUIPC7, which I am currently planning on releasing towards the end of the week. John

I have the PMDG 777 now so it will be easier for me to advise on how to assign for this aircraft now. I have also noticed that some presets (130) have now been added to HubHop for the PMDG 737 now, so those not comfortable using custom controls can check to see if a preset is available. I have attached the latest events.txt file (from MobiFlight) below - use this to replace the one in your FSUIPC7 installation folder, and restart FSUIPC7 if running. I will now look into adding / enabling the additional PMDG 777 specific FSUIPC offsets. John events.txt

I have used the same configuration as PMDG 737 for all axis and reassigned the buttons using custom controls, no update required.

I can look into making these offsets writeable, but not sure when I will have time to look into this at the moment. For the time being, why not just use the provided FS controls: I can look into triggering those controls when the offset is written but it will be a week or two before I get time to look at this - I will update this thread once I have taken a look. John

Not offhand. There is a preset for altitude intervention: AUTOPILOT_PUSH_ALTITUDE_INTERVENTION This uses the hvar H:AS01B_FMC_1_AP_ALT_INTERVENTION You could test to see if there is a similar hvar for the speed intervention. Try executing the calculator code (Add-ons->WASM->Execute Calculator Code) (>H:AS01B_FMC_1_AP_SPD_INTERVENTION) and maybe also try: (>H:AS01B_FMC_1_AP_SPEED_INTERVENTION) to see if any of those work. If so, you can define your own preset. Otherwise, you can try inspecting the behavior of the button using the MSFS development tools - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ Also you can try logging Input Events (Log -> Input Events), press the Speed Intv button and see if anything is logged, and if so use that. I can take a deeper look at some point, but probably not for at least a few days. John

Yes, that used to be the best way to assign. However, as many aircraft in MSFS, especially add-ons, use lvars, hvars, input events or a combination of all three via calc code/presets, and all of these are aircraft specific, you will probably find that you need a specific profile for many aircraft. It is still useful to initially start with profiles as you say, but if you find you need to use an aircraft-specific control for one function, you can then create a specific profile for that aircraft. John

I just figured it out from the previous thread about the 530. I defined a pfc.mcro file: [Macros] 1=GoAround+=CPAUTO_THROTTLE_TO_GA,1 -{Preset Control}- Thank you, Logan

Thanks for looking in to this. I will report this issue to PMDG support.

Ok, thanks for checking. I will provide full details later today, but auto-tuning will only kick in if the default value of the DetectToConnectDelayAuto ini parameter hasn't been changed, or if it is forced. To test the auto-tuning, just remove the DetectToConnectDelayAuto parameter from your ini. If auto-tuning increases the DetectToConnectDelayAuto parameter, it will not run again. If it decreases this parameter, it will run again on the next auto-start unless the parameter has been decreased to 30 (minimum value for this parameter). I also noticed a minor issue in the above attachment - this has been corrected and the attachment replaced (no change in version number though). So please download this again if you want to try the auto-tuning. John

This log file shows that you are using a very old (and unsupported) version of FSUIPC7 (7.4.5). Please update to the latest and only supported version, 7.4.11. And please configure the DetectToConnectDelayAuto ini parameter as explained here now several times (I will also create a FAQ topic on how to do this). You should set the DetectToConnectDelayAuto ii parameter to an appropriate value for your system. You shouldn't need to set/change the InitialStallTime - this has now been set to a minimum of 15 (seconds) when FSUIPC7 is auto-started, which should be plenty of time if the DetectToConnectDelayAuto parameter is configured correctly, but you can also adjust/increase this if your log indicates that FSUIPC7 is re-connecting a few times during start-up. John

Thank you John, i can confirm that the added lines and the new .exe has fixed the problem for me (and hopefully for others) tested with Flbywire and PMDG 737 both on the pan using ready to fly and on the runway that always give me a ready to fly aircraft. Thank you for your prompt reply and fix. Regards, Guy.

Please read this thread, try the updated version posted above and tune the ini parameters mentioned above. This issue seems to be due to the slow start-up process of MSFS. The defaults are tuned for systems that take around a minute between starting MSFS and it getting to the main menu state, If you have a lot of add-ons and your system takes longer than this then increase the DetectToConnectDelayAuto parameter as well as the InitialStallTime parameter.

No idea, sorry. I haven't looked at this since our last discussions, but I don't think there is much I can do about this. I will take another look when time permits. John

Hi fellow pilots, I just would like to share with you my solution for working and independent reverse thrust control for Fenix A320 for MSFS using FSUIPC. I have been strugling with this for a long time. I couldn't find any solution that I would like. Migrating the settings that worked in MSFS config did not work using FSUIPC and even that (using sort of official steps from Fenix) was not separate control for each engine reverse thrust. And MSFS cannot switch profiles separately and it drove me crazy to have to switch controls profile in MSFS just for this single bird, when I have almost everything else configured using FSUIPC (call me old school if you want :)) But, back to the solution. I spend some time hunting events and axes to find out, that the Fenix does not respond to them. So, Lvars should do it, right? And they do. Bt which ones? After some other time, I found the right ones: A_FC_THROTTLE_LEFT_INPUT A_FC_THROTTLE_RIGHT_INPUT I guess I don't have to specify which one drives which throttle lever 🙂 Each of them, can have floating point value in the range 0.0 to 5.0, where each integer corresponds to one detent position of the lever: 0.0 – Full reverse thrust 1.0 – Idle reverse thrust 2.0 – Idle thrust 3.0 – CLB detent 4.0 – Flex MCT 5.0 – TOGA detent so, 0.5 for example equals half reverse thrust… I don’t have “axis” control for reverse thrust, I am using the Bravo throttle quadrant and here is how I set it up. Actually, some prerequisites first. I created the following macro to work with the mentiond Lvars using FSUIPC: FNXA320.mcr: [Macros] 1=L:A_FC_THROTTLE_LEFT_INPUT=Set 2=L:A_FC_THROTTLE_RIGHT_INPUT=Set 3=L:A_FC_THROTTLE_LEFT_INPUT=Inc 4=L:A_FC_THROTTLE_LEFT_INPUT=Dec 5=L:A_FC_THROTTLE_RIGHT_INPUT=Inc 6=L:A_FC_THROTTLE_RIGHT_INPUT=Dec Than, there are two butons on the throttle axis with Bravo throttle quadrant (if using the airline handle). One is the button that is triggered when pulling the lever all the way down to the detent. To continue with concrete example, for me, this button is number 25 on K joystick (K is letter for my Bravo Throttle Quadrant). What I've setup using FSUIPC, is this: Set the value of A_FC_THROTTLE_LEFT_INPUT to 1.0 when the buttons is pressed – thus IDLE REVERSE when I pull the left TQ lever to the down detent. Set the value of A_FC_THROTTLE_LEFT_INPUT to 2.0 when the buttons is relased – thus IDLE thrust when I move the left TQ lever outside the down detent. You can see that on the following picture from FSUIPC: The second buttons is the one that is activated when flipping the small lever on the “Bravo airliner lever extension”. I am sure you know what I mean. This one is little more complex, as it should change from idle reverse thrust to max reverse thrust, but I only wanted it to do so when the lever is physically in the down detent, so I cannot engage reverse thrust accidentally when I don’t want to. Ok, it is not that much of issue, if you ever tried compound button definitions within FSUIPC – you have to go to the ini file for that. The button which triggers these actions for me is number 9 (for left TQ lever) and this is how it is programmed: 332=CP(+K,25)K,9,CM4:4,0 -{Macro FNXA320: L:A_FC_THROTTLE_LEFT_INPUT dec}- 334=CU(+K,25)K,9,CM4:3,1 -{Macro FNXA320: L:A_FC_THROTTLE_LEFT_INPUT inc}- The above are lines from my FenixA320.ini profile file. They are compound button definitions. The first one says to decrease the value of A_FC_THROTTLE_LEFT_INPUT when button 9 and 25 are both pressed. Thus, when the left TQ lever is in down detent (button 25 is pressed) and when buttons for reverse thrust on left TQ (button 9) is pressed. The value will be decremented to the max value of 0 – the last parameter. Because in previous setup the value of A_FC_THROTTLE_LEFT_INPUT was set to 1.0 (by press of button 25), its value will actually decrement just by 1 from 1 to 0. But that means a command from idle reverse thrust to max reverse thrust. The change will not happen immediately, but within a couple of seconds (like about 2 literally :)). You could probably use the macro command to set the value instead of decrement, but I tested it first like that and it worked, so… The other line is the other way around for decreasing from maximum reverse thrust to idle reverse thrust. That is,when button 9 is released while button 25 is still being pressed. What happens is that the value of A_FC_THROTTLE_LEFT_INPUT will be incremented to the max of 1.0 – from non-idle reverse thrust to idle reverse thrust. Even here we could probably use just “set” value. If you move the lever from down detent with button 9 pressed – so full reverse thrust still commanded, the action for release of button 25 will still set the value A_FC_THROTTLE_LEFT_INPUT to 2.0 and bringing the throttle back to IDLE thrust. The reverse thrust for the right engine is set the same way. You can setup the first button in FSUIPC GUI, but the second one will need to be done in the ini file. Here’s mine: 333=CP(+K,26)K,10,CM4:6,0 -{Macro FNXA320: L:A_FC_THROTTLE_RIGHT_INPUT dec}- 335=CU(+K,26)K,10,CM4:5,1 -{Macro FNXA320: L:A_FC_THROTTLE_RIGHT_INPUT inc}- I attached the macro file and my FenixA320.ini profile file. It is not copy and paste setup, you need to know a little bit of FSUIPC background and here is not the place to explain the syntax of the lines. But, you most likely just need to change the joystick letter/number and line numbers in the lines provided above and it should work. So, it is not so much of a rocket science then 🙂 The FenixA320.ini profile is more likely for inspiration. Maybe that someone may find something helfull for him/her. It contains more stuff than just what I described, some are historical copied from other of my aircraft profiles. 🤷‍♂️ Hopy you will find it usefull and maybe someone will even write a script to map the Lvars to axis input for really smooth reverse thrust control. And maybe even forward thrust, but I left mine mapped to THROTTLE1_AXIS_SET_EX1 and THROTTLE2_AXIS_SET_EX1 events. fnx320_macro_and_profile.zip

It appears that many users have problems with Saitek Quadrant drivers setting up the Registry incorrectly for one or more of the levers, with the result that either only 50% of the range use used or the values you get are only on (max value, 16383) or off (min value 0 or -16384). Here is the way to edit the Registry and fix this, at least until Saitek fixes their installers. (Thanks to a main forum reply by "goaround"): ==================================== Here is our registry calibration guide: One way to re-calibrate your device is to reset the raw data values that are held in Windows registry. To do this: 1. Remove the USB plug for your controller from the PC. 2. Press and hold the Windows key on your keyboard and then press the letter R. This will open the Run box. 3. Type regedit and then click ok. For Windows Vista/7/8/8.1 4. The Registry Editor will have a list of folders on the left hand side. Go down into the following folders in order by clicking the + next to the folder name. + HKEY_LOCAL_MACHINE + System + CurrentControlSet + Control + Media Properties + Private Properties + Joystick + OEM 5. Delete any folder inside the Direct Input folder that begins VID_06A3 or VID_0738, if you know the specific PID number or your device then you only need to delete the string that matches the VID and PID. 6. Then navigate to the DirectInput folder + HKEY_CURRENT_USER + SYSTEM + CurrentControlSet + Control + Media Properties + Private Properties + DirectInput 7. Delete any folder inside the Direct Input folder that begins VID_06A3 or VID_0738, if you know the specific PID number or your device then you only need to delete the string that matches the VID and PID. 8. Once deleted, close the editor, then plug the USB back into the original port. Move all the axes of the controller through their full range of movement four times. This will rebuild the data range for all axes.