spokes2112

A good test! 👍 Found the problem. For some reason, on your system, the string that makes up the working path / file name prefix is not concatenating. ( ".." in lua) ex. Here's a revised test. If it gives you a similar output as mine then I will make a revised version. If it does not, will still make a revised version, but this time with a manual path entry in the user settings to bypass the automatic path discovery. 👎 local SavePath = tostring(ipc.readSTR(0x1000, 256)) SavePath = string.sub(SavePath, 1, string.match(SavePath, '^.*()\\')) SavePath = tostring(SavePath .. "ZZ_Lua_Save_") ipc.setowndisplay("Lua Autosave TEST", 30, 2, 40, 0) ipc.display(SavePath, 15) ipc.sleep(15000) Roman

Hi David, All done and fully tested. This includes all the center pedestal switches dealing with startup/shutdown, you can pick and choose what you really need. For a full simulation, without the dummy SFE switches you would need 6 buttons total. If your SOP includes getting the props locked on shutdown & you don't need the feather buttons, then you would need 5 joystick buttons total. (Ground Starter Select, SRL Toggles, Left RCS, RIGHT RCS, Starter) All animations work along with sounds. Attached. Hope it works well for you. Roman FSW MU-2 Hardware Interface.zip

No.. What you are doing now is directing the logic yourself via the STOP, RUN, and/or CRANK L:Vars. The way it was designed is that the animation L:Vars (SWITCH_RCS) control these. Once you bring back the animation all the vars you use will be overridden by the internal logic. I can stop over at my friends place (need to anyway) and fire up the MU2 and try a few things. I still think lua is the way to go, it will work as the designers intended & also keep your buttons/keys tab in FSUIPC from being greyed out. Once that happens you will have to assign any other keys/buttons by editing the FSUIPC.ini manually. An added plus is that you would get the switch click sounds back too. Looking at the model again I think I can do the following with just 4 buttons : 1) Left RCS 2) Right RCS 3) Starter(s), L & R logic separately controlled by the states of the above 2 RCS switches 4) SRL ( L & R combined into 1 ) Will work on something, just to try it.. ( like doing this stuff ) Roman

David, Was just about to delete the VC.mdl my friend sent me.. 😱 Anyway, looked at it. ( code below ) Using 1 button for both RCS switches may not work, look at the VC code, comments provided. There are 3 logic L:Vars inside the VC coding that rely on the RCS switch L:Var (sw position), this may not be so easy. The situation(s): 1) Engine 1 is started, engine 2 is not. You put the single, dual control, RCS switch into RUN. --> Engine 2 probably will not start. ( and vice versa ) 2) The stop position of either switch, a whole nother story, it controls both engines. 3) Using a .mcro to "toggle" the single, dual control, RCS switch from CRANK --> RUN & versly, from RUN --> CRANK probably will not work as the needed values are 0 and -1. If it weren't these values the macro could of used with the command of "TOGGLE" along with 2 buttons. A .lua is an option. Some options (?) : 1) (easy) Only if situation #1 above is NOT true, and, you want to go in only 1 direction (crank --> run) then you could use a simple gauge added to the VC to 1 way mirror the 2 switches. (below) The problem with this is that it will always be active. The master will be the left RCS sw so you could add this : 3=L:SWITCH_RCS_L=SET to the start .mcro, then use a parameter of -1 for a button. This will keep your FSUIPC key/buttons tab from being greyed out. The gauge: <Gauge Name="MU2_RCS_Match" Version="1.0"> <Update> (L:SWITCH_RCS_L,bool) -1 == (L:SWITCH_RCS_R,bool) -1 != and if{ (L:SWITCH_RCS_L,bool) (>L:SWITCH_RCS_R,bool) } </Update> </Gauge> 2) (IMO best) Go to pure lua for everything, including the starter switches. Use 2 buttons for the RCS & 1 button for the Starters. If both RCS switches are in CRANK, the starter button will control the left engine. Otherwise the starter switch will follow whatever RCS switch is in CRANK. The button(s) for each RCS switch will toggle between CRANK & RUN unless.. Both RCS switches are in RUN, both engines are running, aircraft is on the ground, parking brake is set, (maybe 1 more "safety" requirement), only then will it go to STOP. OFC controlling both switches, keeping with the internal VC logic. All of this is based on the following VC code. If you would like to discuss this more perhaps it would be good to PM me, would be happy to help. <!-- ENGINE 1 --> <!-- LEFT CLICK, RUN POSITION (-1) --> (M:Event) 'LeftSingle' scmp 0 == if{ (L:SWITCH_RCS_L,bool) -- -1 max (>L:SWITCH_RCS_L,bool) 1 (>L:XMLSND61,enum) } <!-- RIGHT CLICK, CRANK POSITION (0), IF ALREADY ON CRANK, TEMPORARILY GOES TO STOP (1), ON RELEASE GOES TO CRANK (0) --> (M:Event) 'RightSingle' scmp 0 == if{ (L:SWITCH_RCS_L,bool) ++ 1 min (>L:SWITCH_RCS_L,bool) 1 (>L:XMLSND61,enum) } (M:Event) 'RightRelease' scmp 0 == if{ (L:SWITCH_RCS_L,bool) -- 0 max (>L:SWITCH_RCS_L,bool) } <!-- MIDDLE CLICK, STOP POSITION (1), ALSO STOPS ENGINE 2, ON RELEASE GOES TO CRANK (0) --> (M:Event) 'MiddleSingle' scmp 0 == if{ 1 (>L:SWITCH_RCS_L,bool) 1 (>L:SWITCH_RCS_R,bool) 1 (>L:ENG2_STOP,bool) 1 (>L:XMLSND61,enum) } (M:Event) 'MiddleRelease' scmp 0 == if{ 0 (>L:SWITCH_RCS_L,bool) 0 (>L:SWITCH_RCS_R,bool) 1 (>L:ENG2_CRANK,bool) 0 (>L:ENG2_RUN,bool) 0 (>L:ENG2_STOP,bool) } <!-- INTERNAL VC LOGIC CODE BASED ON THE VAR (L:SWITCH_RCS_L,bool) --> (L:SWITCH_RCS_L,bool) -1 == if{ 1 (>L:ENG1_RUN,bool) 0 (>L:ENG1_CRANK,bool) } <!-- THIS MAY GET BAD WITH A SINGLE RCS SW --> (L:SWITCH_RCS_L,bool) 0 == if{ 1 (>L:ENG1_CRANK,bool) 0 (>L:ENG1_RUN,bool) 0 (>L:ENG1_STOP,bool) } (L:SWITCH_RCS_L,bool) 1 == if{ 1 (>L:ENG1_STOP,bool) } <!-- ENGINE 2 --> <!-- LEFT CLICK, RUN POSITION (-1) --> (M:Event) 'LeftSingle' scmp 0 == if{ (L:SWITCH_RCS_R,bool) -- -1 max (>L:SWITCH_RCS_R,bool) 1 (>L:XMLSND61,enum) } <!-- RIGHT CLICK, CRANK POSITION (0), IF ALREADY ON CRANK, TEMPORARILY GOES TO STOP (1), ON RELEASE GOES TO CRANK (0) --> (M:Event) 'RightSingle' scmp 0 == if{ (L:SWITCH_RCS_R,bool) ++ 1 min (>L:SWITCH_RCS_R,bool) 1 (>L:XMLSND61,enum) } (M:Event) 'RightRelease' scmp 0 == if{ (L:SWITCH_RCS_R,bool) -- 0 max (>L:SWITCH_RCS_R,bool) } <!-- MIDDLE CLICK, STOP POSITION (1), ALSO STOPS ENGINE 1, ON RELEASE GOES TO CRANK (0) --> (M:Event) 'MiddleSingle' scmp 0 == if{ 1 (>L:SWITCH_RCS_L,bool) 1 (>L:SWITCH_RCS_R,bool) 1 (>L:ENG1_STOP,bool) 1 (>L:XMLSND61,enum) } (M:Event) 'MiddleRelease' scmp 0 == if{ 0 (>L:SWITCH_RCS_L,bool) 0 (>L:SWITCH_RCS_R,bool) 1 (>L:ENG1_CRANK,bool) 0 (>L:ENG1_RUN,bool) 0 (>L:ENG1_STOP,bool) } <!-- INTERNAL VC LOGIC CODE BASED ON THE VAR (L:SWITCH_RCS_R,bool) --> (L:SWITCH_RCS_R,bool) -1 == if{ 1 (>L:ENG2_RUN,bool) 0 (>L:ENG2_CRANK,bool) } <!-- THIS MAY GET BAD WITH A SINGLE RCS SW --> (L:SWITCH_RCS_R,bool) 0 == if{ 1 (>L:ENG2_CRANK,bool) 0 (>L:ENG2_RUN,bool) 0 (>L:ENG2_STOP,bool) } (L:SWITCH_RCS_R,bool) 1 == if{ 1 (>L:ENG2_STOP,bool) } Good luck! Roman

Perhaps something to try, sorry, do not own the MU-2. The command JET STARTER (65572, use parameter for engine number) is a throwback from the old days in the lear 45. Automatic, the starter stays engaged until combustion occurs, then disengages. It probably won't matter that it's trying to spool up a turboprop. EDIT - Got a hold of a friend that has this aircraft, you will need a macro or lua to control the following L:Vars: Engine 1 Press - 1 (>L:C441_STARTER1,bool) Engine 1 Release - 0 (>L:C441_STARTER1,bool) Engine 2 Press - 1 (>L:C441_STARTER2,bool) Engine 2 Release - 0 (>L:C441_STARTER2,bool) *(the var names seem to be leftovers from a previous release of theirs) Copy the following code and paste it into an empty text file, save it as MU2_Start.mcro and place it in the modules folder. [Macros] 1=L:C441_STARTER1=SET 2=L:C441_STARTER2=SET Then in the FSUIPC dialog use the commands for your buttons: MU2 Start: L:C441 STARTER1 set & MU2 Start: L:C441 STARTER2 set, with parameters of 1 for press & 0 for release. It should work for you. Roman

Not to step on this discussion, having a similar problem. This is an untested hypothesis based on a post in the main FSUIPC room, of which I cannot find. It will get rid of the constant reading / writing of the aircraft's internal vars therefore speeding up the response. It should also work on almost all encoders when there is a matching led display being used ( Hand to eye response ). Some things like frequencies may be a bit tougher. ----------------------------------------------------------------------- Pete had mentioned something in regards to encoder delays and I think it is the way to go, if this is how he does it.. I believe it is. This is an example for a MCP heading encoder w/ LED display - 1) When the aircraft is first loaded, get the aircraft's internal HDG value and send it to a user offset. Do this only once, as an ini. ( .exe, .dll or .lua ) 2a) From the encoder, set it up in the FSUIPC interface as button/key press command. ( the key/button polling setting in the .ini is your adjustment ) 2b) Use the special commands listed on/near page 38 of FSUIPC for Advanced Users.pdf, "FSUIPC Offset Controls:" Heading up: x5200zzzz Offset Word Cyclic Increment (user offset = zzzz), hexadecimal, with parameter(s) of: Slow Increment ( 1° ), with a cyclic limit of 359 - 00000001011001110000000000000001 = 0x1670001 = 23527425 Fast Increment ( 10° ), with a cyclic limit of 359 - 00000001011001110000000000001010 = 0x167000A = 23527434 Decrement should be similar with the opposite control. 2c) Use the offset directly, with formatting as needed, to drive the LED display, I believe this will be quicker in response, for the eyes. 3) Using .exe, .dll or .lua, listen for the user offset to change, if it does, only then update the aircraft's internal heading variable so it matches the led display ( the offset ). Again, just a hypothesis.. Good luck, carry on. 😁 Roman

Tested your code unaltered on my system and it works fine for me. Hmmm.. Either the save path given to the lua is in UNC format ( which i cannot test ) or there is a permissions issue. Could you use the following lua once to give me the FSUIPC given path? Simply save the following code and save to whatever name you wish (*.lua), then, assign a temporary keyboard key to run it. Please take a screenshot of this running lua and attach. local SavePath = ipc.readSTR(0x1000, 256) SavePath = string.sub(SavePath, 1, string.match(SavePath, '^.*()\\')) .. "ZZ_Lua_Save_" ipc.setowndisplay("Lua Autosave TEST", 30, 2, 40, 0) ipc.display(SavePath, 15) ipc.sleep(15000) Your reply will give me a direction on which way to go with this. Roman

Bunch of ideas, Perhaps the bold red "P" is a syntax error. Each line already knows it's a press with the beginning call ( #=CP ). Try removing them. 10=CP(F+A,9)PA,1,C66507,101 ;//OpenPanel101-DBG 11=CP(F+A,9)PA,1,C66507,1064 ;//OpenPanel1064-Norden 12=CP(F+A,10)PA,1,C66508,101 ;//ClosePanel101-DBG 13=CP(F+A,10)PA,1,C66508,1064 ;//ClosePanel1064-Norden ------------------------------------------------------------------------------------------------ If that doesn't work, I wonder if the "up" (U) listeners are clearing the flag before it can be used.. ( original post, lines 5, 7 & 9 ) IE the physical button or the yoke software treats it a "one shot" press. Maybe something like the following may work, it sets the flag for the current button but clears the flags for all others, the flag(s) would become a "latch". The following removes the second "P" too. 4=PA,10,C1003,10 -{BUTTON FLAG Set: Joy A Button 10}- ; MODE 3 5=PA,10,C1004,9 -{BUTTON FLAG Clear: Joy A Button 9}- 6=PA,10,C1004,8 -{BUTTON FLAG Clear: Joy A Button 8}- 7=PA,9,C1003,9 -{BUTTON FLAG Set: Joy A Button 9}- ; MODE 2 8=PA,9,C1004,10 -{BUTTON FLAG Clear: Joy A Button 10}- 9=PA,9,C1004,8 -{BUTTON FLAG Clear: Joy A Button 8}- 10=PA,8,C1003,8 -{BUTTON FLAG Set: Joy A Button 8}- ; MODE 1 = Normal operations? 11=PA,8,C1004,9 -{BUTTON FLAG Clear: Joy A Button 9}- 12=PA,8,C1004,10 -{BUTTON FLAG Clear: Joy A Button 10}- 13=CP(F+A,9)A,1,C66507,101 ;//OpenPanel101-DBG 14=CP(F+A,9)A,1,C66507,1064 ;//OpenPanel1064-Norden 15=CP(F+A,10)A,1,C66508,101 ;//ClosePanel101-DBG 16=CP(F+A,10)A,1,C66508,1064 ;//ClosePanel1064-Norden ------------------------------------------------------------------------------------------------ Another option is to use direct button polling without flags. 4=CP(-A,8)(+A,9)(-A,10)A,1,C66507,101 ;//OpenPanel101-DBG, MODE 2 5=CP(-A,8)(+A,9)(-A,10)A,1,C66507,1064 ;//OpenPanel1064-Norden, MODE 2 6=CP(-A,8)(-A,9)(+A,10)A,1,C66508,101 ;//ClosePanel101-DBG, MODE 3 7=CP(-A,8)(-A,9)(+A,10)A,1,C66508,1064 ;//ClosePanel1064-Norden, MODE 3 8=CP(+A,8)(-A,9)(-A,10)A,1,<some control> ;//Available control for MODE 1 9=CP(-A,8)(-A,9)(-A,10)A,1,<some control> ;//Normal assigned control for button 1 Just a hunch or 2 , hope it may help.. Good luck. Roman

@ram123, I updated the lua almost immediately after releasing it. I used "WinMerge" to compare your file to the updated version & they are the exact same except for the settings. You have the updated version.. Good! I don't know why you are having these problems. Mine has been working fine for months. One thing I did notice while testing : If you are watching the folder: My Documents\Flight Simulator X Files while the lua is saving, you may have to use the right click context menu and use refresh to see the changes. Maybe it's just my computer, but Windows doesn't update the file explorer window while this is happening. Also, as stated in the readme, if you a referring to any special files (.FMC / .ASC for example) saved by the aircraft on a flight save, only the newest will be saved overwriting the previous. Nothing* can be done about this, it is triggered and handled within the aircraft coding itself. * (Just had an idea on how to handle this, will give it a try over the next few days) Roman

An idea for where to look. In the older sims this was defined in the aricraft/sim.cfg under the [autopilot] section.. If the AP master was turned on & no other lateral mode was selected/armed prior, then heading hold would be turned on. default_bank_mode= # This determines the default bank mode when the autopilot logic is turned on. 0 = None 1 = Wing Level Hold 2 = Heading Hold (current heading). If no value is set, Wing Level Hold will be the default Also, use_no_default_bank = # Setting this flag to 1 will cause the default bank mode to be "None". It will actually set the variable default_bank_mode to zero, so that there is no default bank mode when the autopilot logic is activated. The preferred method is to set the default_bank_mode directly. (above)

Just got done testing on the local FS machine, the only way L:Var detection via Lua will work. Works fine except... You should write to the offset as a 32bit float. The frequency values are floats, but they have rounding errors! That can be fixed on the WideFS lua. function writeFDCmdr(varname, value) ipc.writeFLT(0x66CD, value) end event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr")

Downloaded and took a quick look at it. Ahh that's it.. My hunch was kind of right. On every one of the click commands (the ones that finalize something) lines 182-366, somewhere in each of those click spots is the command ( an instant reset, faster than 1 msec ) : 0 (&gt;L:CpitCmdrSetValue, number) Your original lua should pick up on each numerical digit as it's pressed and added up only to the point prior to sending to a radio / ap command. Will install his gauge and make a lua for my sacrificial aircraft to test more. Never used excel in FS, probably never will. In all the "weird" stuff i've ever created, either a xml gauge, advanced FSUIPC.ini programming or lua fits my needs. - sorry. Roman EDIT... Are you running this L:Var detection lua on the local or the WideFS machine? If on the WideFS machine it will not work as stated in the FSUIPC Lua Library.pdf. If you run the L:Var detection on the sim machine, then use event.Offset on the WideFS machine it should work then.

This is just a hunch as I have run into this with the MaddogX. I also noticed other advanced aircraft use this procedure. The L:Var "CpitCmdrSetValue" sure does sound like it is a command to do something with the internal programming / logic of the aircraft. EX. Sending the value 12258597 to the L:Var will open the map box, just an example. In the gauge logic it would be something like - ( in XML ) <Update> (L:CpitCmdrSetValue, number) 0 != if{ <!-- Open the map box --> 12258597 (L:CpitCmdrSetValue, number) == if{ <!-- Provide code for animating the map box opening --> } <!-- Close the map box --> 12258598 (L:CpitCmdrSetValue, number) == if{ <!-- Provide code for animating the map box closing --> } <!-- This resets the L:Var --> 0 (>L:CpitCmdrSetValue, number) } </Update> As you can see, if the L:Var is zero it bypasses most of the code. If the L:var is not zero then it will find what value matches, then do something.. After that it resets the L:Var back to zero. This is the key part. The gauge system is much faster (55 msecs) versus the L:Var polling of the lua (100 msecs). What may be happening with you is that yes, the L:Var is changing, but it is returning to zero so fast that the lua is not picking it up. It sounds like you would like to find out what the value is to, later on, maybe do something. IE provide a custom command thru a L:Var or have some kind of indication. If this is the case you could try it in the following Lua. Note - you still may have to toggle the L:Var command a few times before the lua will catch the value, after that, at least, you will have the necessary value. function writeFDCmdr(varname, value) if value ~= 0 then ipc.writeUW(0x66CD, value) end end event.Lvar("L:CpitCmdrSetValue",100,"writeFDCmdr") Again just a hunch.. May be way out of the ballpark too 😉 Roman Yes.. Just assign a keyboard key to the dropdown command "Lua <lua name>" ( not LuaKill, LuaToggle, LuaSet or LuaClear)

Maybe this will help. A few points - - 0x2E80 is 4 bytes = 32 bit = Double Word. Therefore the Offset designator should be a "D" - According to the docs the "0x" for the offset isn't shown in the examples. - Your second entry, 415, is on the release "U", therefore when you press the button it will turn off, if on. Once you will release the button it will turn on again. Avionics already on - Press = 413 turn off, 415 is skipped , Release = 413 is skipped, 415 turn on Avionics already off - Press = 413 is skipped, 415 is skipped , Release = 413 is skipped, 415 turn on This may do it for you - 413=D2E80=1 PF,24,C66701,0 -{AVIONICS_MASTER_SET}- 415=D2E80=0 PF,24,C66701,1 -{AVIONICS_MASTER_SET}- Avionics already on - Press = 413 turn off, 415 is skipped, Release = nothing Avionics already off - Press = 413 is skipped, 415 turn on, Release = nothing Roman

@John Dowson I can only imagine how little hair you have left! 👍😅 @jgoggi Good news! You're welcome. I really like these little projects, even if not for myself. They go well with the morning coffee, it gets the brain cell working again. 😅 This morning I started the version with the landing gear lever, but will stop. 1) If FSL, on the next update, gets this fixed then great! If not, I may revisit the landing gear lever arming. 2) Without the landing gear lever arming the lua above reads these 3 lines every 4 seconds throughout the whole flight. local alt = ipc.readUD(0x31E4) -- get the current RAlt if (armed == 1 and alt > trigger_alt) or (armed == 0 and alt < arm_alt) then -- bypass most of code, nothing valid return It is not much at all in the whole scheme of things but would be nice if it didn't have to read the var / decide for the whole flight. I do have the variable I need to do this but it's output could be reversed, there is no way I can tell, this would make testing a possible "back and forth" chore. ( would the negligible gains be worth it? ) Roman

@John Dowson It is for the FSLabs A320.. Kind of weird problem with this user, maybe others. (here) Just a nice, quick, little project. @jgoggi What is the command for the landing gear lever? Is it the stock P3D landing gear command? If I knew that, it could even get better, if it works in the first place. Right now, the lua is constantly on - getting RAlt values every 4 seconds. Not much really. But, if the landing gear lever was monitored - if the lever was up the lua wouldn't do a thing except listen for the lever being moved. If the lever was down then the lua would monitor RAlt as it does now. Just a little more efficient. Roman

Here's a quick & dirty lua. Maybe someone could put another set of eyes on it or even test it with the Bus. It is far as I can go for the weekend. It has been tested for syntax errors, proper RA conversion to feet & the arm/disarm. Roman -- Special FSL Airbus LL toggle controller, 05SEP20, Roman Stoviak (spokes2112) -- USER ADJUSTMENTS samples = 4000 -- The time between RAlt samples. In milliseconds. wait = 1000 -- The wait time between LLs turning off, then back on. In milliseconds. arm_alt = 2500 -- the altitude (at or above), in feet, where the system will arm. trigger_alt = 1000 -- the altitude (at or below), in feet, where the system will trigger the LL toggle, if armed. -- END USER ADJUSTMENTS armed = 0 -- convert the user RAlt adjustments in feet to the "raw" FSUIPC read RAlt value in meters arm_alt = arm_alt * 19975.3728 trigger_alt = trigger_alt * 19975.3728 function do_it() local alt = ipc.readUD(0x31E4) -- get the current RAlt if (armed == 1 and alt > trigger_alt) or (armed == 0 and alt < arm_alt) then -- bypass most of code, nothing valid return elseif armed == 0 and alt > arm_alt then -- arm it armed = 1 elseif armed == 1 and alt < 998768.64 then -- disarm it if the trigger was never met. IE on, or very close (50 ft.) to the ground armed = 0 elseif armed == 1 and alt < trigger_alt then -- trigger it local l_llit = ipc.readLvar("L:VC_OVHD_EXTLT_Land_L_Switch") local r_llit = ipc.readLvar("L:VC_OVHD_EXTLT_Land_R_Switch") if l_llit == 20 and r_llit == 20 then -- !!! BOTH left and right LLs MUST be ON to trigger !!! ipc.control(66587, 72496) -- turn off left LL ipc.control(66587, 72506) -- turn off right LL ipc.sleep(wait) -- delay between turning off lights, then turning back on ipc.control(66587, 72497) -- turn back on the left LL ipc.control(66587, 72507) -- turn back on the right LL armed = 0 -- disarm the system until next take off / climb end end end event.timer(samples, "do_it") --[[ Notes.. (L:VC_OVHD_EXTLT_Land_L_Switch, number) (L:VC_OVHD_EXTLT_Land_R_Switch, number) LVAR ON = 20 LVAR OFF = 10 LVAR RETRACT = 0 FSL COMMAND = 66587 LEFT LL INC = 72497 LEFT LL DEC = 72496 RIGHT LL INC = 72507 RIGHT LL DEC = 72506 31E4 4 Radio altitude in metres * 65536 ]]

James, Believe it or not I pondered what needed to be done for this with the morning coffee! I also read the thread over at Avsim. I believe it could be done - yes... The problem is, I do not own the FSL Airbus. * If a SDK is somehow available I may be able to help.* With that being said - 1) if the landing light control can be done with L:Vars or stock landing light commands then a XML gauge would be the way to go for sure - if not... 2) then lua would do it, a bit more work in coding, but doable. A hypothesis on operation - Arming - once the aircraft gets above, say, 2500 ft RA the system would arm. ( a cushion for varying terrain ) Trigger - If armed and the aircraft gets below 1000 ft RA then : If the lights are on - turn off the lights and wait for about 1 second or less, turn them back on, then disarm the system. If the lights are off - just wait until they are turned on then do the above. The arm / disarm system is there so the turn off/on procedure is only done once. ( IE not repeating < 1000 ft RA ) * Found the LINDA kit for A3xx-X 1.5 and was able to see what is needed. It can be done in LUA. Won't be able to get into it fully until Tuesday, it is Labor day weekend in the US.. Testing will be tough not owning the aircraft, but again, doable. Roman

The B58 fuel pump hi/lo is fake. In high or low the pump is on, otherwise it is off. It also uses G:Vars (FSX 2D panel) which are not accessible to simconnect/fsuipc/lua. Visual status : (A:General eng1 fuel pump switch,bool) 0 != d (G:Var1) ! * + The click command : (A:General eng1 fuel pump switch,bool) if{ (G:Var1) if{ 0 (&gt;K:TOGGLE_ELECT_FUEL_PUMP1) } els{ 1 (&gt;G:Var1) } } els{ 0 (&gt;G:Var1) 0 (&gt;K:TOGGLE_ELECT_FUEL_PUMP1) } The most confusing code i've ever seen! "If OFF and G:Var is cleared, turn pump ON. If ON set G:Var (for visual HI). If ON and G:Var is true then clear G:Var, finally turn pump OFF " In FS2020 the code in the VC is most likely transposed from the above using L:Vars or S(SP)/L registers. Probably just best to live with OFF/LOW. Roman

Rhys, " I'm using the update nemeth bros model. " Is it one of these: here or here? If so, both use the same logic with the starter. I downloaded both and checked. ( only have FSX here ) Being the case, none of the built in FSUIPC commands will work. You will need to use a lua or .mcro script to do the following : 1 (>L:Eng2StarterSwitch, bool) In XML code, the repeat flag is on so you may want to include that too. It was just a quick look, there is a lot of built in logic ( some very weird ) with these models. If it doesn't work, let me know, can look deeper into it. Roman

Rhys, You could try ( not sure, it depends on the aircraft ) the command "Jet Starter" with a parameter of 1, 2, 3 or 4. ( the engine number )

Not to step on anyone's toes here.. For an interim solution why not use lua? ( available in profiles ) It works pretty good for most programs and is can be timed as wanted ( ipc.sleep(msecs) ). It gets called once, when done, it dies. Some programs can be a pain as they just don't accept a second attribute within the lua for starting ( "start in" ). For those I call a batch file from the lua to do all the work for starting. Works well.

Owen, Yes, exactly.. (page 14-15 FSUIPC Lua Library.pdf) Except, I get the panel name from the panel.cfg to make sure there is no errors caused by display formatting etc.. To see if there are any lua errors you could use the FSUIPC logging, with a second (or more) monitors it is awesome! FSUIPC is the best thing ever created for flight simming )) Roman

In my case (FSX boxed) if the open windows are undocked and placed on primary fs screen when the flight is saved it will work. Prior to saving a flight I have a lua that will do this - -- moves the window titled "GPS /RADIO" to my primary FS monitor, in this case it is monitor 2 ext.position("GPS /RADIO", 0, 0, 100, 62, 2) ipc.exit() Then when I start a saved flight I press a key to run this lua to move it back where it belongs - -- moves the window titled "GPS /RADIO" to my secondary FS monitor, where it belongs in this case it is monitor 1 ext.position("GPS /RADIO", 0, 0, 100, 62, 1) ipc.exit() You can add as many ext.position("name", x, y, cx, cy, screen) commands as needed for each window in each of the luas.

No... Copy the complete xml file & paste it as a new file with a new name.. Modify that one. Then call that one as the second iteration of the G1000 in your panel.cfg.