spokes2112

Works a charm in 4.947e. :) Thanks for the excellent support! Much appreciated. Have a great day!

Pete, single shot = single press / release [Keys] 21=135,8,L8:T,0,L8:K,0 That was just a test to see if buttons via FSUIPC acknowledged the keyup - which it doesn't. FSUIPC still captures the key down event while in lua, event.key captures the key down event only once. As mentioned above - Must use a repeating keypress as an event.key "reset" for only the numpad enter key. I am starting the lua via down arrow for now during testing ( 25=40,8,L8:R,0 ) , once completed it will be started via [Auto]. Here's the exact code I was using just to see if this style of code worked (beeps on event) - sound.path("C:/Windows/Media")function KeyStroke(keycode, shifts, downup) sound.play("Windows Default", 0, 100, -1)end-- NUMPAD ASSIGN ARRAY & EVENT LISTENERSlocal keyassign = { }for i = 1, 15 do keyassign[i] = i + 95endfor i = 1, 15 do event.key(keyassign[i], 8, 1, "KeyStroke")endevent.key(135, 8, 1, "KeyStroke") No worries though Pete. I went the different route using event.flag(s) via [Keys] and is working nicely. Just think this is a bug of some sorts. Whether or not it is significant is up to someone who wants to use it. Thanks for everything, Shuttin 'er down.. Having fun but it's 5 am & the eyes are on fire... :wacko:

Pete, Just noticed something when trying to use the numpad enter key using event.key in lua. IIRC there was something about this in the forum but through searches couldn't find it. This works just fine for repeats - event.key(135, 8, 5, "KeyStroke") For a single shot, this works only 1 time when lua is first loaded and the enter key is used. It doesn't "listen" for it afterwards. Unless.... The enter key is pressed and held logging repeating keypresses. Then, it will work just 1 time afterwards until repeated. (a repeating keypress as a "listener" reset) All other keys on numpad work just fine. Single shot use, the one that doesn't seem to work properly - event.key(135, 8, 1, "KeyStroke") Strange thing though. When logging keys for the numpad enter key this is it's output for a single click / release. KEYDOWN & KEYUP don't match. HMMM???? 3056715 KEYDOWN: VK=135, Waiting=0, Repeat=N, Shifts=0 3056715 .. Key not programmed -- passed on to FS 3056902 KEYUP: VK=13, Waiting=0 Through the FSUIPC interface it picks up the keydown, not keyup, but keeps on listening. [Keys]21=135,8,L8:T,0,L8:K,0 9333696 KEYDOWN: VK=135, Waiting=0, Repeat=N, Shifts=0 9333696 LUA.4: "KeyTune.lua": Flag 0 toggled 9333696 .. This key is programmed in FSUIPC4 'Keys' options 9333696 LUA.4: Lua Flag event: calling "KeyStroke" in "G:\FSX\Modules\KeyTune.lua" 9333696 LUA.4: G:\FSX\Modules\KeyTune.lua:9 9333712 LUA.4: G:\FSX\Modules\KeyTune.lua:10 9333712 LUA.4: G:\FSX\Modules\KeyTune.lua:11 9333712 LUA.4: G:\FSX\Modules\KeyTune.lua:12 9333743 LUA.4: G:\FSX\Modules\KeyTune.lua:14 9333758 LUA.4: Waiting for an event in "G:\FSX\Modules\KeyTune.lua" 9333852 KEYUP: VK=13, Waiting=0No lua kill afterwards but it keeps listening for downpress. Just wondering.. Could go another route but was really hoping on using event.key v4.947d on FSX accel boxed.

The first code was slightly bugged when using two monitors. For instance on the second monitor you had a 2D GPS window opened and just got done making that window active by clicking on it (clicking GPS buttons) when a screen shot was made it would capture the second monitor. The new modified code brings the mouse over to the main window (middle right top) and performs a mouse click. It then returns the mouse to the same position it originated from. The above code is modified to include the new coding. Relevant Section - -- REGAIN OWNERSHIP OF FS - FSX ONLY!!! x, y, xr, yr, xp, yp = mouse.getpos() mouse.move(66, 0, 2) mouse.click(0) mouse.move(xr, yr, 1) -- END FSX ONLY

This Lua file invokes the Print Screen button passing the clipboard to IrfanView.exe and, by using IrfanView's powerful command line options, processes the pasted file to an output .jpg modified as wanted. --[[ NOTES - USE WITH [AUTO] IN .INI TO START WITH FS - ASSIGN IN FSUIPC AS "LuaSet <Saved Name>" WITH A PARAMETER OF 1 - HTTP://WWW.IRFANVIEW.COM/ - SEE "I_OPTIONS.TXT" OR "I_VIEW32.CHM|OVERVIEW|COMMAND LINE OPTIONS" FOR COMMAND LINE DESCRIPTIONS. - EXAMPLE OF "SS_$U(%d%b%y_%H%M%S).jpg" IN OPTIONS = "SS_20Oct15_112307.jpg" - !!! IMPORTANT !!! - CHANGE "IV_Path" AND "IV_Options" TO OWN INSTALLATION AND REQUIRED OPTIONS - COMMAND OPTION "/convert=" WILL AUTOMATICALLY SHUT DOWN IRFRANVIEW AFTER PROCESSING - BECAUSE PRINT SCREEN IS INVOKED IN LUA, OWNED BY FS, IT CAPTURES ONLY THE ACTIVE MAIN WINDOW, IE FS. - !!! NOW MODIFIED FOR BETTER BEHAVIOUR - SEE COMMENTS IN "TRIGGERS SECTION" BELOW FOR OTHER ASSIGNEMENT OPTIONS END NOTES ]] sound.path("C:/Windows/Media") local flagged = 0 -- !!! IMPORTANT !!! - CHANGE THE FOLLOWING 2 LINES TO SUIT !!! local IV_Path = "E:/IrfanView/i_view32.exe" -- !!! IMPORTANT !!! - USE DOUBLE BACKSLAHES FOR OUTPUT PATH local IV_Options = "/clippaste /crop=(1443,62,1357,684) /sharpen=20 /jpgq=100 /convert=D:\\My Pictures\\FS_SCREENSHOTS\\PP_OUTPUT\\SS_$U(%d%b%y_%H%M%S).jpg" -- /crop=(13,62,1357,684) -- /crop=(1443,62,1357,684) -- PRESS PRINT SCREEN KEY, RUN IRFRANVIEW (SELF STOPPING), PASTE CLIPBOARD, OPTIONS PROCESSING, CREATE JPG & RETURN FOCUS TO FS function PrtScn(x, y, move, flags) flagged = ipc.testflag(1) if flags == 16 or flags == 32 or flags == 64 or flagged then ext.focus(0) -- REGAIN OWNERSHIP OF FS - FSX ONLY!!! x, y, xr, yr, xp, yp = mouse.getpos() mouse.move(66, 0, 2) mouse.click(0) mouse.move(xr, yr, 1) -- END FSX ONLY ipc.clearflag(1) ipc.control(1070, 300) -- WAIT FOR "PRTSCN" TO PROCESS, ADJUST HIGHER IF NOT PICKING UP FS WINDOW ipc.sleep(100) handle, error = ext.shell(IV_Path, IV_Options) if handle ~= 0 and error == 0 then sound.play("Windows Default", 0, 100, -1) end ext.focus(0) end end -- TRIGGERS SECTION -- SETFLAG TRIGGER, FOR JOY OR KEYS THROUGH FSUIPC ASSIGNMENTS event.flag(1, "PrtScn") -- MOUSEWHEEL CLICK - FSUIPC V4 ONLY! DISABLED FOR FSUIPC MOUSE LOOK FUNCTION USE -- event.mousemiddletrap("PrtScn") -- MOUSEWHEEL LEFT / RIGHT - FSUIPC V4 ONLY! DOES NOT WORK WITH MY MOUSE, USED KEYSEND MACRO IN MOUSE SOFTWARE -- event.mousehoriz("PrtScn")

Rustam, Thank You! Yes, there are other ways to do the same thing but they are too bulky meaning, must install gauge per aircraft, modify gauge to suit etc.. I've been using this setup extensively now and it saves a bunch of time.. Last night I decided to automate it a little more.. If I am going to run LVARS_2_TXT.lua doesn't it mean I want to see the output ALL LVARS.txt instantly? If I am going to read the output ALL LVARS.txt it doesn't it mean I want to modify LVAR_SPECIFIC.lua to include new Lvars to monitor? Why not open them up right away instead of navigating to them? Below is the last section of LVARS_2_TXT.lua to make this happen.. Remember to change paths/programs to suit what's needed! -- tidy up at end ... f:write("\n____________________ END OF LIST ____________________\n\n") f:close() ipc.display("A pre-formatted L:VARs list has been created as FSX/Modules/ALL LVARS.txt", 0, 1) ipc.sleep(1000) -- CHANGE PATHS/PROGRAMS TO SUIT !!!!!!! handle, error = ext.runif("E:/Notepad++/notepad++.exe","G:/FSX/Modules/ALL LVARS.txt") handle2, error2 = ext.runif("E:/Notepad++/notepad++.exe","G:/FSX/Modules/LVAR_SPECIFIC.lua") -- UNCOMMENT BELOW IF TEXT PROGRAMS DO NOT START - GET WINDOWS ERROR CODES -- ipc.display(handle .. error .. "\n" .. handle2 .. error2, 0, 5) -- ipc.sleep(5000) -- end of program

Jim, The controls still work in FSX, only, but only,,, if the aircraft has a "Concorde" style .air file. Revamping an .air file to include the required "Concorde" style will alter the performance of the aircraft soo much it isn't even worth trying.. Went up that tree a dozen times. As for the lights. If this is the FS9 freeware release then according to the aircraft.cfg there is no beacon circuit at all, they seem to be attached to the strobe circuit. Easily changed by changing the 2 into a 1. [lights] //Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit, 5=landing light.0 = 3, -25.50, -79.50, 1.90, fx_navred light.1 = 3, -25.50, 79.50, 1.90, fx_navgre light.2 = 2, 11.25, 0.00, 7.00, fx_beaconh light.3 = 2, 13.35, 0.00, -9.25, fx_beaconh light.4 = 2, -92.80, 0.00, 29.55, fx_beaconh light.5 = 4, 57.00, 0.00, 0.50, fx_vclight light.6 = 4, 54.00, 3.50, 1.00, fx_vclight light.7 = 4, 54.00, -3.50, 1.00, fx_vclight light.8 = 4, -35.00, 2.00, -2.00, fx_vclighth light.9 = 4, -35.00, -2.00, -2.00, fx_vclighth light.10 = 4, 47.00, -3.00, -2.00, fx_vclighth light.11 = 4, 47.00, -3.00, -2.00, fx_vclighth

This should be more efficient, it will get all the ADF1 & 2 data in one read and place the data into the variables as needed. adf2_main, adf2_frac, adf2_upper, adf1_main, adf1_frac, adf1_upper = ipc.readStruct(0x02D4, 1UW, 2UB, 0x034C, 1UW, 0x0356, 2UB)

Maybe this will help - referring to THIS post & then splitting the upper and fractions into their own variable by reading them as byte, per offset, instead of word. This will help in reading ADF1 at offsets 0x034C & 0x0356 - not contiguous. Quick & dirty, not tested at all. The formatting may be off due to not testing. adf2_main = ipc.readUW(0x02D4) adf2_frac = ipc.readUB(0x02D6) adf2_upper = ipc.readUB(0x02D7) adf2_main = string.format("%3X", adf2_main) adf2_frac = string.format("%01X", adf2_frac) adf2_upper = string.format("%1X", adf2_upper) ipc.display("ADF2 = " .. adf2_upper .. adf2_main .. "." .. adf2_frac .. " kHz")

Rustam, I would give this a try. All my compounds require the alternate trigger. Below are all the buttons that may be conflicting - color coded matching. [buttons.SW_AN2] 0=CP(+0,28)0,4,CL1:R,1125 ; adf near-far switch 1=R0,6,CL1:R,780 ; mixture lean 2=R0,7,CL1:R,781 ; mixture enrich 3=CR(+0,18)0,6,CL1:R,812 ; prop pitch decr 4=CR(+0,18)0,7,CL1:R,813 ; prop pitch incr 5=R0,2,CL1:R,891 ; elevator trim down 6=R0,3,CL1:R,890 ; elevator trim up 7=P0,12,CL1:R,88 ; flaps up incr 8=P0,13,CL1:R,79 ; flaps down incr 9=P0,4,CL1:R,751 ; emerg flaps switch 10=P0,5,CL1:R,131 ; brakes 11=CP(+0,15)0,5,CL1:R,133 ; parking brakes 12=P0,1,CL1:R,1 ; cold & dark + autostart 13=U0,14,CL1:R,59 ; landing light left 14=P0,14,CL1:R,58 ; landing light right 15=P0,8,CL1:R,60 ; navigation light 16=P0,9,CL1:R,62 ; strobe light 17=P0,10,CL1:R,61 ; taxi light 18=P0,19,CL1:R,300 ; cockpit door 19=P0,21,CL1:R,301 ; pax door 20=CP(+0,15)0,21,CL1:R,302 ; cargo door 21=R0,20,CL1:R,900 ; aileron trim left 22=R0,22,CL1:R,901 ; aileron trim right 23=P0,31,CL1:R,132 ; manual pump 24=CP(+0,18)0,31,CL1:R,107 ; manual primer 25=CP(+0,15)0,31,CL1:R,57 ; tailwheel lock 26=CP(+0,15)0,25,CL1:R,1264 ; fuel tanks 27=CP(+0,15)0,8,CL1:R,65 ; battery 28=CP(+0,15)0,9,CL1:R,64 ; generator 29=CP(+0,15)0,23,CL1:R,804 ; magnetos 30=P0,23,CL1:R,920 ; cowl flaps incr 31=P0,25,CL1:R,921 ; cowl flaps decr So as an example take a look at entries 23-25, they require multiple compound triggers. 23=P0,31,CL1:R,132 ; manual pump 24=CP(+0,18)0,31,CL1:R,107 ; manual primer 25=CP(+0,15)0,31,CL1:R,57 ; tailwheel lock At least in my case you must follow the opposite triggers in order for it to work correctly. Basically you have to tell FSUIPC to get the state of all the buttons when 1 action button has a compound. They are not assumed as unpressed. Edit - Another way of thinking about it is - an action button can be either a press or a compound, but not both. 23=CP(-0,15)(-0,18)0,31,CL1:R,132 ; manual pump - 15 & 18 unpressed, 31 pressed 24=CP(-0,15)(+0,18)0,31,CL1:R,107 ; manual primer - 15 unpressed, 18 & 31 pressed 25=CP(+0,15)(-0,18)0,31,CL1:R,57 ; tailwheel lock - 15 & 31 pressed, 18 unpressed A second, easier example, for generator and strobe light. Original - 16=P0,9,CL1:R,62 ; strobe light 28=CP(+0,15)0,9,CL1:R,64 ; generator New - 16=CP(-0,15)0,9,CL1:R,62 ; strobe light - 15 unpressed, 9 pressed 28=CP(+0,15)0,9,CL1:R,64 ; generator - 15 & 9 pressed For me a good tip is to reorder your buttons so the action buttons are paired up with the triggers. It will prevent a big headache! :smile: entries 10-11, 19-20, 23-25 & 29-30 are a good example of doing it.

A P3D v3.0 version of FSUIPC has not been released yet. 4.945a is good up to v2.5 w/ partial implementation for V3. Maybe this is why registration is not given.

Rustam, It looks like it should work (w/ a second set of eyes) but - Do you have other button commands for button 8 & 9 in your .ini? If so, are they using the opposite trigger? ex. ##=CP(-0,28)0,8,SOMETHING If not, it just may throw it out of whack.

I kinda needed the same thing you were asking - for some time now... Finally created it. See here in user contributions. Good luck in your upcoming programming.

I have always wanted to have a "quick and dirty" way to monitor specific L:VARs without installing a new gauge and trying to find the ones needed by scrolling etc. Perfect for things like programming sub-systems and such. It's a 3 step process. Run "LVARS_2_TXT.lua" to get the full list (output = "ALL LVARS.txt") of L:VARs currently loaded by the selected aircraft. It's a "run once" lua but, one can use it multiple times if multiple aircraft projects are being done as it appends to the file. (creates a master list) -OR- Run the FSUIPC command "List local panel variables" to do the same and written to the FSUIPC log (Formatting necessary!) , without using "LVARS_2_TXT.lua" - The former provides a pre-formatted, easy to use output. Pick the LVARs needed to monitor and copy them over into the array in "LVAR_SPECIFIC.lua". NOTE - The output in "ALL LVARS.txt" are pre-formatted for an easy copy --> paste. See notes in lua. Note - The lua display will truncate anything after 1023 characters so if this starts happening reorder your list in priority order. Run "LVAR_SPECIFIC.lua" to monitor your selected L:VARs. LVARS_2_TXT.lua -- "LVARS_2_TXT" Loaded LVARs writer, by Roman Stoviak, September 2015 -- Open an exisitng "All LVARS.txt" file to append to, or create it if it doesn't exist. -- It will go into the Modules folder because I've not included a full path (like "C:\....") -- By using "assert" you get an error message if this fails f = assert(io.open("ALL LVARS.txt","a+")) -- get aircraft name and air file name air, title = ipc.readStruct(0x3C00, "256STR", "256STR") air = air:gsub('%z','') title = title:gsub('%z','') -- write the text headings f:write("_______________________________________________________________\nTITLE, AIR FILE\n" .. title .. ", " .. air .. "\n_______________________________________________________________\n") i = 0 while i < 65536 do name = ipc.getLvarName(i) if name ~= nil then f:write("\"" .. name .. "\",\n") i = i + 1 else break end end -- tidy up at end ... f:write("\n____________________ END OF LIST ____________________\n\n") f:close() ipc.display("A pre-formatted L:VARs list has been created as FSX/Modules/ALL LVARS.txt", 0, 3) ipc.sleep(3000) -- end of program LVAR_SPECIFIC.lua Note - The lua below has the array preloaded with L:VARs "test1" thru "test4" as an example. -- "MONITOR SPECIFIC LVARS" fsuipc display, by Roman Stoviak, September 2015 --[[ NOTES - Enter each L:VAR to monitor by getting the "preformated" list provided by "LVARS_2_TXT.lua". Each L:VAR name MUST be surrounded in quotes and followed by a comma for each the array entry(s). One could use a single line for each L:VAR -or- Place all the L:VARs inline. EX. separate lines "test1", "test2", "test3", "test4", EX. same line "test1","test2","test3","test4", PLACE THE L:VAR LISTING IN THE ARRAY BELOW BETWEEN THE 2 COMMENTS CONTAINING "!!!!!" END NOTES ]] local monitor = { -- COMMENT !!!!! START ARRAY ON NEXT LINE !!!!! "test1", "test2", "test3", "test4", -- COMMENT !!!!! END ARRAY !!!!! } local size = table.getn(monitor) while 1 do local i = 1 local out = "" local disp = "" repeat out = ipc.readLvar(monitor[i]) if out == nil then -- NEW SECTION TO KEEP LUA ALIVE IN CERTAIN SITUATIONS out = "no value" end disp = disp .. monitor[i] .. " = " .. out .. "\n" i = i + 1 until i == size + 1 ipc.display(disp) ipc.sleep(50) end

If you want something like - during start spooling the switch stays latched & once fired it returns, then the equivalent xml token would be (A:GENERAL ENG COMBUSTION:index, bool). FSUIPC offsets would be - offset - bytes - description 0894 - 2 - Engine 1 combustion flag (TRUE if engine firing) 092C - 2 - Engine 2 combustion flag (TRUE if engine firing)

BINGO! Thanks for heading me in the right direction! Works great plus it was much easier to integrate more functions...The code is in the User Contributions section at the top replacing the old stuff. Have a great day!

THANKS PETE FOR THE NUDGE! Not only does it perform much better but it has more functions! Post # 1 has been modified with the new code.

Thanks Pete! My 1st 3 versions were done inside a single file. I tried just about everything you mentioned ( event.) and just couldn't get it to work reliably. Forgot about event.param. Going to try again. Trying to make it easy on the user side to setup. Thanks! will advise.

Gave it a go with excellent results. It helps out quite a bit when using a button, toggling on/off to get a mixed brake strength. The code is in the User Contributions section. Pete - If you see any glaring problems with this -or- have some ideas to make it better I would be grateful.. A lua beginner.

Here is a Lua file that progressively apply and/or disengage brakes, adjustable in both directions, for those who only have a button for brakes. [INSTALLATION] FS closed Copy the complete code block below, paste it into an empty .txt file & rename it Smooth_Brake.Lua Place the above file in the FS/Modules folder Add the following to the [Auto] section of the FSUIPC(4).ini file - X=Lua Smooth_Brake - Where X is the next available number in the [Auto] section. (pg. 42 - FSUIPC4 for Advanced Users.pdf) Comment out ( ; ) or remove the original brake button listing in the [buttons] section. Start FS Make sure the button is not programmed through the FS assignments dialog. For a simple, non-complex assignment to the joystick button see the picture below. For a complex assignment see pg. 22 - FSUIPC4 for Advanced Users.pdf - Using something similar to this for a button press - xx=CP(-0,11)0,0,CL6:S,211 and this for release - xx=CU(-0,11)0,0,CL6:C,211. Where 6 is the numbered lua under the [LuaFiles] section of FSUIPC(4).ini in my case as an example. Use the FSUIPC facility, "Reload Buttons", from the user interface in the Buttons tab to confirm assignment. Adjust user settings to ones own liking. Assign a keyboard key to reload the file using Lua Smooth Brake as the control sent to use for reloading tuning modifications. One can use the Logging facilities in FSUIPC, using the right hand side of the dialog (FSX + only), using 0BC4, 0BC6 & 0BC8 with a type of U16, display to FS Window, to help in adjusting user settings. The above settings result in this - 1=P0,0,CL6:S,211 2=U0,0,CL6:C,211 [USAGE] Basically all this does is gradually increase (depending on settings) the brake strength as the assigned brake button is pushed. It also works in reverse, on brake disengagement. One could, for instance press the brake button for only 1 second and after that toggle the brakes on & off at a repetitive rate to keep, lets say, ~ 50% brake strength. It's much better than full on or full off. The settings as given below give around a 2.75 second span between brakes off to full brake strength. Smooth_Brake.Lua - --------------------- USER SETTINGS rate_on = 300 -- RATE AT WHICH BRAKES ARE APPLIED minimum = 3500 -- MINIMUM BRAKES ON FIRST APPLY = REQUIRED PERCENT * 16384 rate_off = 300 -- RATE AT WHICH BRAKES ARE RELEASED dis_pbrake = 1 -- DISENGAGE PARKING BRAKE ON BRAKE APPLICATION? REQUIRES A REAPPLY FOR BRAKE ACTIVATION! diff_brake_override = 0 -- !!!! GIVES AN ALTERNATE DIFFERENTIAL BRAKE AXIS PRIORITY OVER BRAKES -- EXAMPLE - THE "T_FLIGHT HOTAS" ALTERNATE AXIS ON THROTTLE SECTION -- SEE PG.1 "FSUIPC LUA LIBRARY" - "n = ipc.axis(joynum, "axis")" FOR MORE INFORMATION. --------------------- END USER SETTINGS function stop() brake = ipc.readUW(0x0BC4) -- Get Parking Brakes If Button Pressed And Parking Brake Disengage Is Active if ipc.testflag(211) == true and dis_pbrake == 1 then p_brake = ipc.readUW(0x0BC8) -- Disengage Parking Brakes If Set if p_brake == 32767 then ipc.control(65752, 0) end end -- Brakes On while brake < 16383 and ipc.testflag(211) == true do -- Differential Braking Override if diff_brake_override == 1 then -- REQUIRES CUSTOM ATTRIBUTES FOR SPECIFIC HARDWARE special = ipc.axis(0,"S") if special > 1000 or special < -1000 then brake = 0 break end end brake = math.min(16384, brake + rate_on) brake = math.max(minimum, brake) brake_shift = logic.Shl(brake, 16) + brake ipc.writeUD(0x0BC4, brake_shift) end -- Brakes Off while brake > 0 and ipc.testflag(211) == false do -- Differential Braking Override if diff_brake_override == 1 then -- REQUIRES CUSTOM ATTRIBUTES FOR SPECIFIC HARDWARE special = ipc.axis(0,"S") if special > 1000 or special < -1000 then brake = 0 break end end brake = brake - rate_off brake = math.max(0, brake) brake_shift = logic.Shl(brake, 16) + brake ipc.writeUD(0x0BC4, brake_shift) end end event.flag(211, "stop")

Due to physical limitations I must use a button on the joystick.. Thinking this would be a perfect little LUA project to delve into. A log or linear increase in braking over time, ~2.5 seconds. This would reduce the harshness & give the ability use the momentary action as Pete mentioned above a little more effectively. A much better option than adjusting the .air file (only way to adjust) for each airplane. The brain is pondering... Will give it a go.

This post may help - using IP rather than computer names. http://forum.simflight.com/topic/79730-error-10061-code-cannot-open-wide-client-connection-from-client-to-server/

In sub forum above - "Download Links / Updated Modules" http://forum.simflight.com/topic/66139-updated-modules/

Save your FSUIPC4.key & FSUPC4.ini from the old installation (FSX/Modules), place them in the new FS setup (FSX/Modules) then reinstall FSUIPC (newest version)

Chas, Pete is going to be gone for a few weeks. Not a pro at this but will give a shot. It looks from the log that the J,0 conditions are being set just fine. What I suspect is that you have one or more rogue button entries on T that are both conditional and unconditional from J,0. 2893429 [buttons] 39=CR(+J,0)T,10,C1016,0 OK 2893429 .... Condition (+J,0) = TRUE OK 2893429 Repeating flag set: bRef=0, Joy=0, Btn=10 (RepeatDelayCtr=11) OK 2893429 FSUIPC Control Action: Ctrl=1016, Param=0 OK 2893429 Button held, flags=X05, repeat set: bRef=0, Joy=0 (T), Btn=10, (RepeatOk sets 2) 2893429 [buttons] 47=RT,10,C1024,0 LOOKS LIKE A ROGUE ENTRY FOR BUTTON T,10 - UNCONDITIONAL VERSION vs. [buttons] 39 above 2893429 Repeating flag set: bRef=0, Joy=0, Btn=10 (RepeatDelayCtr=11) 2893429 FSUIPC Control Action: Ctrl=1024, Param=0 2893429 *** EVENT: Cntrl= 66124 (0x0001024c), Param= 10000 (0x00002710) AP_ALT_VAR_SET_ENGLISH 2 EVENTS HAPPENING AT ONCE FROM T,10 2893429 *** EVENT: Cntrl= 66042 (0x000101fa), Param= 300 (0x0000012c) HEADING_BUG_SET 2 EVENTS HAPPENING AT ONCE FROM T,10 Maybe this will help ....