Masterius

For anyone using the Saitek/Logitech Pro Flight Yoke, the X52 HOTAS, or the X52 Pro HOTAS, you've most likely encountered difficulties with the Mode Switch when using anything other than the Saitek Smart Technology profile editor. Windows' Game Controller setting (joy.cpl) will show the Mode Switch as functioning, yet your game or third-party programming software (like LINDA or FSUIPC) will not recognize any input--programmed or native--from the Mode Switch. Everything else will work, just not the Mode Switch*. There is a reason for that, and a solution as well. The Mode Switch was intended to triple the amount of keybindings/controls that you could program. As an example, for the trigger switch, using the SST profile editor you might program Mode 1 for firing guns, Mode 2 for firing rockets, and Mode 3 for firing missiles. Outside of the SST profile editor, however, the Mode Switch does not work, and this is because Saitek designed their programming driver so that Windows would hide the Mode Switch function in order that their software would have exclusive access. The programming driver is not the same as the Saitek Smart Technology profile editor program. When the yoke or joystick is first installed you do not have to install the SST profile editor, only the drivers. The Saitek Smart Technology profile editor is optional, and unnecessary. However, whether you choose to install SST or not, along with the necessary driver(s) is the programming driver as well. One solution is to select the applicable Saitek/Logitech peripheral (Yoke or HOTAS) in the Game Controllers window. The easier way to do this is to enter in the search bar "Game Controller" then select "Set up USB Game Controllers". Scroll down and highlight the applicable controller--yoke or joystick--then click "Properties". As long as the Properties window is open and active the Mode Switch will now correctly function. Unfortunately, this requires remembering to do this each and every time you use your flight sim. However, there exists a more elegant--and permanent--solution. For each of the three controllers, Saitek has an associated programming driver. They should be located in C:\Windows\System32, and are as follows: Pro Flight Yoke: SaiD0BAC.pr0 X52 HOTAS: SaiD0255.pr0 X52 Pro HOTAS: SaiD0762.pr0 Make a backup copy for safety and then rename the applicable file. For instance, I've renamed SaiD0BAC.pr0 as SaiD0BAC.pr0.bak. That's it! Simply reboot your system and now you'll be able to use the Mode Switch outside of the SST profile editor software. *For the X52/X52 Pro, the mouse controller and scroll wheel is also effected and should work using this fix.

Here are my user functions: function P51D_Battery_On () ipc.writeLvar ("L:Battery1Switch", 1) end function P51D_Battery_Off () ipc.writeLvar ("L:Battery1Switch", 0) end function P51D_Engine_Start_On () ipc.writeLvar ("L:Eng1_StarterSwitch", "1") end function P51D_Engine_Start_Off () ipc.writeLvar ("L:Eng1_StarterSwitch", "0") end function P51_EnginePrime_On () ipc.writeLvar ("L:Eng1_PrimerSwitch", "1") end function P51_EnginePrime_Off () ipc.writeLvar ("L:Eng1_PrimerSwitch", "0") end function P51D_Emergency_LandingGearFairing_Closed () ipc.writeLvar ("L:EmergencyGearLever", "0") --ipc.writeLvar ("L:LandingGearEmergencyHandle", "0") --ipc.writeLvar ("L:LandingGearEmergencyHandlePast", "0") end function P51D_Emergency_LandingGearFairing_Open () ipc.writeLvar ("L:EmergencyGearLever", "1") --ipc.writeLvar ("L:LandingGearEmergencyHandle", "1") --ipc.writeLvar ("L:LandingGearEmergencyHandlePast", "1") end function P51D_FuelCutoffSwitch_On () ipc.writeLvar ("L:Eng1_FuelCutOffSwitch", "1") end function P51D_FuelCutoffSwitch_Off () ipc.writeLvar ("L:Eng1_FuelCutOffSwitch", "0") end function P51D_Fuel_Fuselage () ipc.writeLvar ("L:Eng1_FuelSelector", "1") ipc.writeLvar ("L:FSelP51State", "0") ipc.writeLvar ("L:FSelP51", "0") end function P51D_Fuel_LeftWing () ipc.writeLvar ("L:Eng1_FuelSelector", "2") ipc.writeLvar ("L:FSelP51State", "1") ipc.writeLvar ("L:FSelP51", "20") end function P51D_Fuel_RightWing () ipc.writeLvar ("L:Eng1_FuelSelector", "3") ipc.writeLvar ("L:FSelP51State", "2") ipc.writeLvar ("L:FSelP51", "80") end function P51D_Fuel_LeftDrop () ipc.writeLvar ("L:Eng1_FuelSelector", "4") ipc.writeLvar ("L:FSelP51State", "3") ipc.writeLvar ("L:FSelP51", "60") end function P51D_Fuel_RightDrop () ipc.writeLvar ("L:Eng1_FuelSelector", "5") ipc.writeLvar ("L:FSelP51State", "4") ipc.writeLvar ("L:FSelP51", "40") end function P51D_DropLeft_Tank () ipc.writeLvar ("L:DropTankLeftReleaseKey", "1") ipc.sleep (2000) ipc.writeLvar ("L:DropTankLeftReleaseKey", "0") end function P51D_DropRight_Tank () ipc.writeLvar ("L:DropTankRightReleaseKey", "1") ipc.sleep (2000) ipc.writeLvar ("L:DropTankRightReleaseKey", "0") end

Well, I'm not using my butchered bodge job script any longer, as Al (ark1320) very kindly created a trim tab popup script for me in response to my asking for coding assistance. Needless to say, it's a lot better written then mine! 🤪 Still, it was worth the experience, as I've never played with the parameters/coding like the ones in this script. And one thing I've discovered long ago: I enjoy coding as much as I do flying!

Ugh. Not sure how I screwed up, but somehow I did. Mostly, I suspect, because I've no idea how to create, only how to dissect, disassemble, then put back piecemeal. For whatever reason--and after a great deal of butchery--I've got something that works, and does just what I wanted. I cannot begin to tell you how appreciative I was--and still am--of your willingness to look into this for me. I have two questions about some odd behavior, however. I suspect I know what it is, but I thought I'd wing it past you nonetheless. For one, there is a line in the program --ipc.setowndisplay(" HUD Params", 35, 25, 12,12)-- that, instead of displaying the title of "HUD Params" instead displays "SimConnect". If I'm correct, that is because the FS I'm using is P3D and that simply is how P3D interfaces. The second is that one of the undocked windows flickers in time to the refresh rate of the program. I have three monitors, and the leftmost one is where I drag and position undocked panel windows such as radio panels, mini controls, etc. Again, if I'm understanding things correctly (which I assure you is seldom the case) P3D treats undocked windows differently through SimConnect, and so they are likely flickering because the HUD Params program is also working through SimConnect? At any rate, I now have a spiffy little popup that shows all three trim tab degree positions, which is exactly what I'd wanted. Thanks again for sharing the HUD Params script! ~Masterius

Whelp, I've played around with this for a bit, but I don't think it'll work, mostly because I'm using P3Dv5, and it doesn't seem to play well with ipc.setowndisplay and ipc.display. Thanks for getting me pointed in a direction though! ~Masterius

That is because I didn't make that clear. The intention was that they were trim tab positions, as would be implied by the panel window selection. So it would appear like this Trim Tab Positions: Aileron: [position in degrees] Rudder: [position in degrees] Elevator: [position in degrees] I'll do just that! And thanks for getting back to me! ~Masterius

Sorry if I didn't correctly define the subject title. I'm trying to create--or if I'm lucky, find and/or be pointed to a preexisting one--a 2D popup panel that displays the trim tab positions. I can easily position the tabs using either LINDA (as button and/or switch positions) or FSUIPC as the same or as an axis control. What I'm wanting is a small panel that will display, either analog or digital, the current positions of the trim tabs. I've tried mapping their LVars, but they come up oddly (elevator trim, for example, c1ElevatorTrim) and do not display their value when traced. Using their FSX controls I can input changes to their positions but I don't see any way of viewing their current positions. All I want to do is fairly simple, at least vis-a-vis the actual panel appearance. A simple small window that shows this: Aileron: [position in degrees] Rudder: [position in degrees] Elevator: [position in degrees] Hopefully someone can point me in the right direction. I'm not looking for software I need to buy in order to get preset panels, though. ~Masterius

Since I use the joystick calibration function of FSUIPC, and set their Max/Min at the full range of travel, and since both brakes are -16384/+16383, and since their Flight Control Response curve are both zero, I'm at a loss at how they could be construed as being "aren't calibrated very smoothly". Yes, it is quite logical, and also what I would expect. I commented on that as an observation due to the fact that the flight sim recognizes that by altering from a [DIFFERENTIAL BRAKE] condition to a full, dual [BRAKE] condition, in case that was germane to the rest of my post. The aircraft I'm using is the A2A AccuSim B-17. The toe brakes are assigned using individual axis, and are calibrated using joystick calibration. During testing, each brake smoothly alters from -16384 to +16383 without a halt, skip, or bobble. Using Windows setup USB game controllers also shows a smooth, even progression from full off to full on. P3Dv5, version 5.1.12.26829 Saitek Pro Flight Rudder FSUIPC 6.1.0

I currently have my left and right brakes set up independent of each other, functioning as differential brakes. For the most part this works great. I've a couple of issues, and a question, however. Issue one is that, on random occasions, the brakes just stop braking. The popup flag [DIFFERENTIAL BRAKE] will disappear whilst braking, then reappear when the brake pressure is slightly altered. Issue two isn't, I suppose, as much an issue as an observation: when brakes are equally applied, or fully applied, it alters from [DIFFERENTIAL BRAKES] TO [BRAKES]. This is actually a good thing in its way, but leads to question one. Getting the brakes to equally apply is terribly difficult unless fully applied. And it appears the differential application is 'all-or-nothing'. By that I mean it appears that if I'm applying pressure to both brakes, whichever one is seeing a higher pressure takes effect while the other brake is fully released. This results in rolling down the runway and the aircraft seesawing left and right as the brake pressure is altered to keep it heading straight. Is there any way of setting up differential braking so that if the brake pressures are within, say, 10% of each other [BRAKES] are equally applied rather than just left or right brake?

Try this: 1) Unplug the joystick and throttle 2) Uninstall in device manager 3) reboot 4) Edit your FSUIPC6.ini file [Joynames] as follows: [JoyNames] AutoAssignLetters=Yes A=Saitek Pro Flight X-55 Rhino Stick << MISSING JOYSTICK >> A.GUID={20AEA380-71FE-11EB-8001-444553540000} B=Saitek Pro Flight X-55 Rhino Throttle B.GUID={20AEA380-71FE-11EB-8003-444553540000} 0=Saitek Pro Flight X-55 Rhino Stick 0.GUID={20AEA380-71FE-11EB-8002-444553540000} 1=Saitek Pro Flight X-55 Rhino Throttle 1.GUID={20AEA380-71FE-11EB-8003-444553540000} A=Saitek Pro Flight X-55 Rhino Stick A.GUID={20AEA380-71FE-11EB-8002-444553540000} 5) plug the joystick and throttle back 6) reboot See if that helps.

Not sure if this will work, but look in your FSUIPC(x).ini file for the following: [Buttons] PollInterval=25 See if decreasing the poll Interval helps. From the Advanced User Guide: PollInterval=25: This parameter tells FSUIPC how often to read (“poll”) the joystick buttons. The time is in milliseconds, and the default, as shown, is 25 (40 times a second). A polling rate of 0 will stop FSUIPC looking at buttons altogether, and in fact this will remove the Buttons & Switches tab from the FSUIPC options. This may come in useful for checking whether a rogue joystick driver is causing problems. A polling rate of 40 per second is more than adequate for all normal button programming. It is only when you come to the more advanced uses that you may want to change this. Rotary switches, for instance, may give pulses so fast that some are missed at such a rate. Any value from 1 millisecond upwards can be specified, but those from 50 upwards result in a specific number of “ticks” (55 mSecs) being used. i.e. 40–82 actually result in 55 (1 tick), 83–138 in 2 ticks, and so on. Ticks are also approximate, in that they depend on the other activities and loading upon FS. Values 1–59 milliseconds are actually handled by a separate thread in FSUIPC and give more accurate results, but note that polling the joysticks too frequently may damage FS’s performance, and may even make its response to joystick controls more precarious. No truly adverse effects have been noticed during testing, but it is as well to be warned. If you think you need faster button polling, try values in the range 10–25, and make sure that FS is still performing well each time. Note that the PFCcom64 and PFChid64 “emulated” joysticks (those with numbers 16 upwards) are polled four times more frequently in any case—this is done because there is no overhead in doing so—there are no calls to Windows but merely some data inspections.

There was a lua script that I hadn't been using since I'd switched from FSX to P3Dv5. It had been located in the directory--and thus listed in fsuipc6.ini under [LuaFiles]--since the changeover, but due to mission requirements (basically I'll be using it this weekend to operate our Norden bombsight) I'd updated the [Auto] to have it autoload. The lua script in question contained the following: function VAS(control, vas) vas_in = ipc.readUD(0x024C) ipc.writeLvar("L:VAS", vas_in) if vas_in < 500000 then ipc.display("VAS = "..vas_in,2) end end as well as: event.offset(0x024C,"UW","VAS") event.timer(4000,"Calc_Track") event.timer(10000,"VAS") It would appear that the offset 024C is specific to FSX only, which was causing the problem.

P3Dv5 (5.1.12.26829) LINDA3.2.6.1111 FSUIPC 6.0.12 Starting yesterday, I've started getting a cyclical message popping up in a window. It's a SimConnect Window, stating that "VAS=0". I've disabled all my addons, and restarted using just the stock, default-provided aircraft. I do not get that message until I've re-enabled FSUIPC6. No other addon triggers the message window. Checking the FSUIPC6.log does not show any errors. I've been running the same conditions for weeks now without problems of this sort, and am clueless as to why this has suddenly started. Also have noted that moving about in the FSUIPC6 menu is now very slow, often requiring several clicks on a tab before it takes. Update#2: Discovered the source of the problem

Fixed and working >Update: Still working, with the script variables identical as before. Only change being the repositioning of function MixAdj_1 to allow for it being defined.

I have four identical scripts that differ only in their numeration, one each for engines 1 thru 4. All four have worked just fine this last week. All four stopped dead at the same time yesterday evening. All four have the same time stamp, dated last week. I assure you, they did run, and they haven't changed. I'll agree that something has to have changed. I meant that script. It auto loads using fsuipc6.ini, and is called using FSUIPC6 axis definition offsets. LINDA has nothing to do with these scripts. I'll update that right now.

P3Dv5 LINDA3.2.6 FSUIPC 6.0. 11 For over a week this lua has been working just fine. It was working fine this morning. And now it's not. When trying to load I get the following error message in the LINDA2.log: [E] *** LUA Error: C:\Prepare3D v5 Add-ons\FSUIPC6\A2AB17_MixAdj_1.lua:7: attempt to call global 'adjust_mix_1' (a nil value) The main script is set to autoload and run in FSUIPC6.ini. I have no idea why it ran without a hitch for days and now suddenly is faulting. function MixAdj_1(offset, input) MixAdj_1_in = ipc.readSW(0x66DB) n = (MixAdj_1_in + 16383)/327.67 m = ipc.readLvar ("L:MixtureLock") if m==0 then adjust_mix_1 () else end function adjust_mix_1 () if (0 <= n and n <= 10) then i = 4 elseif (10 < n and n <= 50) then j = 3 elseif (50 < n and n <= 90) then k = 2 elseif (90 < n and n <= 100) then l = 1 else end end if (i==4 and i ~= a) then ipc.writeLvar("L:MixtureRatioLever1Position", 3) a = 4 b = 0 c = 0 d = 0 j = 0 k = 0 l = 0 end if (j==3 and j ~= b) then ipc.writeLvar("L:MixtureRatioLever1Position", 2) b = 3 a = 0 c = 0 d = 0 i = 0 k = 0 l = 0 end if (k==2 and k ~= c) then ipc.writeLvar("L:MixtureRatioLever1Position", 1) c = 2 b = 0 d = 0 a = 0 i = 0 j = 0 l = 0 end if (l==1 and l ~= d) then ipc.writeLvar("L:MixtureRatioLever1Position", 0) d = 1 c = 0 a = 0 b = 0 i = 0 j = 0 k = 0 end end event.offset(0x66DB,"SW","MixAdj_1")

Problem is, FSUIPC doesn't recognize them. Nor, for that matter, does LINDA or FSX:SE. Windows USB game controller sees them, but for some reason nothing else does. ~Masterius

Thanks! I'll go and give that a whirl! ~Masterius

Pinkie Trigger [6] (stick): Button 6 Mouse Button [31] (throttle): Button 31 Mouse Button 2 [32] (throttle): Button 32 ~Masterius

FSX:SE LINDA 3.1.1 FSUIPC 4975A First off, not complaining. FSUIPC is an awesome tool, and I enjoy it--and use it--immensely. I've recently begun using my old Saitek X-52 H.O.T.A.S., and unlike in the past, when I used Saitek's (ugh) profiler, this time I've used LINDA and FSUIPC to assign controls and functions. Having done so, I've discovered controls that neither LINDA nor FSUIPC recognize. The specific buttons, switches and axis are: Mode Switch [MODE] (stick), Pinkie Trigger [6] (stick) Mouse Button [31] (throttle) Mouse Button 2 [32] (throttle); neither click switch nor rotary axis Mini Stick/Mouse (throttle) Just curious as to why they aren't recognized. It's not a big deal, I'm mostly curious.

OK, I'm admitting I've no idea what I'm doing. I've torn apart every .lua existing in the various folders, and after having done so I've no idea how DspShow is defined. I've specifically looked for "Fthr" to see where and how that is defined, and simply can't find it. I'm at a loss here. I've also read all the support manuals and instructions and have exhausted Google, and again come up short with an explanation for DspShow. Care to take pity on an ignoramous?

I've found the issue, but no idea how to fix it. I get this error when trying to run it: [E] *** LUA Error: ...am\steamapps\common\FSX\Modules\B17_Eng1_restart.lua:61: attempt to call global 'DspShow' (a nil value) It runs fine in LINDA, but I suspect that's because it's run within the larger file lib-user.lua function B17_Eng1_restart () ipc.writeLvar("L:Feather1Switch", 0) DspShow("Fthr", "1 off") ipc.sleep(500) ipc.clearbitsUB("2434", 1) ipc.sleep(2000) ipc.writeLvar("L:FuelValvesSafe",1) ipc.sleep(750) ipc.writeLvar("L:Eng1FuelCutOffSwitch",1) ipc.sleep(1500) ipc.writeLvar("L:FuelValvesSafe",0) ipc.sleep(750) ipc.writeLvar ("L:MixtureLock",0) ipc.sleep(1500) ipc.writeLvar("L:MixtureRatioLever1Position", 2) ipc.sleep(1500) ipc.setbitsUB("3125", 1) DspShow("Pump", "1on") ipc.sleep(1500) ipc.writeLvar ("L:MixtureLock",1) ipc.writeSB("0892", 3) ipc.sleep(750) restartIfNeeded1 () ipc.sleep(30000) ipc.writeLvar ("AutoCoPilotCowl", 1) end function restartIfNeeded1 () n = ipc.readLvar("Eng1_RPM") if n<=250 then B17_InertStart_show1 () else end end function B17_InertStart_show1 () ipc.writeLvar("L:Starter12Start", 0) Inert = round(ipc.readLvar("L:StarterInertiaSoundVolume")/2.5) if _MCP1 () then DspShow("Inrt", Inert .."%") elseif _MCP2 () then DspMed1("InrtStrt") DspMed2(" " .. Inert .."%") end B17_Engine1_Mesh () end function B17_EngineMesh_stop () ipc.writeLvar("L:Starter12Mesh", 1) ipc.writeLvar("L:Starter34Mesh", 1) DspMed1("") DspShow("stop", "") end function B17_Engine1_Mesh () ipc.sleep(12000) ipc.writeLvar("L:Starter12Mesh", 0) end DspShow("Mesh", " " .. 1 .. " ")

Oddly enough, had I searched for Lua in controls, I highly doubt I would have asked this question. Since I was going to be conditionally programming the .lua, and as you can't directly assign that through the GUI interface but are required to manually program that, I was trying to do so using the instructions found in pages 18 thru 28 of the FSUIPC4 for Advanced Users.pdf. The examples used there for control definitions are the typical Cxxxxx format, such as C65570. I'm familiar with that, and extensively use them in my scripts. I hadn't encountered the "CL" definition before, and since I was so focused on manually writing the script, it never occurred to me to use the GUI to get the script started. My bad. Thank you for the answer. Update: Having added the .lua as described, using the button does nothing. However, if I assign the .lua to the same button using LINDA it then runs. The buttons that aren't working are 14-17. Here is the code: [Buttons.B-17] 0=RA,32,C65734,0 -{PAN_UP}- 1=RA,34,C65672,0 -{PAN_RIGHT}- 2=RA,36,C65735,0 -{PAN_DOWN}- 3=RA,38,C65671,0 -{PAN_LEFT}- 4=PA,10,C1003,10 -{BUTTON FLAG Set: Joy 0 Button 10}- 5=UA,10,C1004,10 -{BUTTON FLAG Clear: Joy 0 Button 10}- 6=PA,9,C1003,9 -{BUTTON FLAG Set: Joy 0 Button 9}- 7=UA,9,C1004,9 -{BUTTON FLAG Clear: Joy 0 Button 9}- 8=PA,8,C1003,8 -{BUTTON FLAG Set: Joy 0 Button 8}- 9=UA,8,C1004,8 -{BUTTON FLAG Clear: Joy 0 Button 8}- 10=CP(F+A,9)A,1,C66507,101 ;//OpenPanel101-DBG -{PANEL_ID_OPEN}- 11=CP(F+A,9)A,1,C66507,1064 ;//OpenPanel1064-Norden -{PANEL_ID_OPEN}- 12=CP(F+A,10)A,1,C66508,101 ;//ClosePanel101-DBG -{PANEL_ID_CLOSE}- 13=CP(F+A,10)A,1,C66508,1064 ;//ClosePanel1064-Norden -{PANEL_ID_CLOSE}- 14=PA,21,CL12:R,0 -{Lua B17_Eng1_restart}- 15=PA,22,CL13:R,0 -{Lua B17_Eng2_restart}- 16=PC,6,CL14:R,0 -{Lua B17_Eng3_restart}- 17=PC,7,CL15:R,0 -{Lua B17_Eng4_restart}- [LuaFiles] 1=Lua KillAll 2=A2AB17_MixAdj 3=A2AB17_Mixture 4=A2AB17_Turbo 5=B-17_Heater 6=B17_Mechanic 7=Calc_Track 8=ipcReady 9=linda 10=pucker 11=fuelcheckAll 12=B17_Eng1_restart 13=B17_Eng2_restart 14=B17_Eng3_restart 15=B17_Eng4_restart [Auto.B-17] 1=Lua KillAll 2=Lua B-17_Heater 3=Lua B-17_Windows_both 4=Lua Calc_Track 5=Lua A2AB17_Turbo 6=Lua A2AB17_Mixture 7=Lua A2AB17_MixAdj 8=linda 9=Lua fuelcheckAll 10=Lua B17_Eng1_restart 11=Lua B17_Eng2_restart 12=Lua B17_Eng3_restart 13=Lua B17_Eng4_restart I've no idea why it runs in LINDA but not FSUIPC.

Can a button be programmed to run a .lua? It appears that buttons can be programmed for keypresses, controls, and macros, but not a .lua.

Bulls-eye!! Dead in the black. That problem's been vexing me for a while now. Thanks a heap!