spokes2112

This is in FSX, the commands are: ENG1 OFF - Mixture1 Set, parameter = 0 ENG2 OFF - Mixture2 Set, parameter = 0 ENG1 ON - Mixture1 Set, parameter = 8192 ENG2 ON - Mixture2 Set, parameter = 8192 Since you are using regular mixture axis' for this I would highly recommend using profiles and then on the axis assignment tab use the right side "set ranges for action". One to turn off fuel when your physical mixture lever reaches near the top of travel & one to turn on the fuel when your mixture lever reaches the lower part of travel. There are no midpoints on the AS Twin Otter for MixtureX Set, it is either on (8192) or off (0) BTW - This information was found using the logging tab in FSUIPC.. A very powerful tool! Roman

Simone, In the SIOC file it looks like all the var reads are DWords so change x020066D0 to x030066D0 John, I dont know.. I am assuming Simone wants 0-4096 from inputs -16384 to 16383 so tried this using the calculator - -16384 * 0.125 = -2048 + 2048 = 0 16383 * 0.125 = 2047.875 + 2048 = 4095.875 Unless the coffee hasn't quite kicked in yet. 😅 Roman

Simone, Look at ~page 46 "FSUIPC# for Advanced Users.pdf" titled: "Additional parameters to scale input axis values" My doc is for FSX, if it still holds true for P3D then modify (add to, in red) your .ini as follows & reload the axis assignments (a button on the Axes page) --> The delta (in blue) is probably to prevent jerkiness. I am assuming the pot is the feedback loop for the motor/stepper motor. [Axes] PollInterval=10 RangeRepeatRate=10 0=2X,256,F,x030066D8,0,0,0,*0.125,+2048 -{ FSUIPC: offset dword set, offset 66D8 }- ; ASI SPEED 1=2Y,256,F,x020066D0,0,0,0,*0.125,+2048 -{ FSUIPC: offset word set, offset 66D0 }- ;SALMON BUG 2=2Z,256,F,x030066D4,0,0,0,*0.125,+2048 -{ FSUIPC: offset dword set, offset 66D4 }- ; BARBER POLE Roman

Hello Pete and / or John. This is an idea, maybe for the future? ( too late now for FSX) This seems it would be very helpful for those working on a sim cockpit. An optional passing 3rd parameter on "event.Lvar". Have been working on a project for a friend where ~226 l:vars needed to be assigned to offsets so that mobiflight/arduino can use them for the cockpit. Mainly these are indicator lamps and the like - not updated/changed repetitively. All done with it and seen there was quite a bit of repetition. (~215 semi-repetitive functions) Thinking this would save (big time) on lua memory usage, writing of the script, and possibly quicker loading of the lua. Would something like this work? If it could work, any downsides? Of course tested it with grand hopes, but alas..... ---------------------------------------------------------------------------------------- local poll_spd = 300 function write2ub (varname, value, offset) ipc.writeUB(offset, value) end function write2uw (varname, value, offset) ipc.writeUW(offset, value) end -- etc... event.Lvar("lvar#1", poll_spd, "write2ub", 0x####) event.Lvar("lvar#2", poll_spd, "write2ub", 0x####) -- thru event.Lvar("lvar#225", poll_spd, "write2uw", 0x####) event.Lvar("lvar#226", poll_spd, "write2uw", 0x####) ---------------------------------------------------------------------------------------- Again, just an idea. Regards, Roman

Thanks Pete, All points rectified and working smoothly.. 👍 Roman

Have a question with ipc.ask for P3Dv4. I am making a lua for some friends using P3D but am still living in the stone age with FSX. Will the following code work? Anything to add? After many emails back & forth, it not working, they are giving up on me.. 😠 The recommendation of using ipc.getdisplay also confuses me. I am assuming using this is just to check if there is another Lua Display open ? Tests fine in FSX with the green line display. It is a "one shot" lua, currently being tested via a keyboard start, eventually hoping to go to [auto] so when the aircraft is loaded the lua will show and ask. Thanks in advance, Roman

Owen Not tested, logicly seems like it should work. Uses the Logic Library and the IPC Library operation: ipc.togglebitsUW Both in the document - ~\Modules\FSUIPC Documents\FSUIPC Lua Library.pdf. The key is to turn the bit(s) to check into its decimal or hex equivalent as the logic mask. (if multiple, add bits up) Hope it helps, Roman --[[ PARAMETERS 1 = If landing light is off, turn it on 2 = If landing light is on, turn it off 3 = If taxi light is off, turn it on 4 = if taxi light is on, turn it off ]] lights = ipc.readUW(0x0D0C) -- param #1 landing light on if ipcPARAM == 1 and logic.Nand(lights, 4) then ipc.togglebitsUW(0x0D0C, 4) end -- param #2 landing light off if ipcPARAM == 2 and logic.And(lights, 4) then ipc.togglebitsUW(0x0D0C, 4) end -- param #3 taxi light on if ipcPARAM == 3 and logic.Nand(lights, 8) then ipc.togglebitsUW(0x0D0C, 8) end -- param #4 taxi light off if ipcPARAM == 4 and logic.And(lights, 8) then ipc.togglebitsUW(0x0D0C, 8) end

In FSX-accel, boxed - For what it's worth, had the C-47 all setup for a flight.. Since ready, did some testing/looking around prior to departure. I have my controls as "send to FSUIPC calibration" and they work just fine. Even tried to break them by setting them up much differently - still worked. Looked at the VC animation code too.. Nothing really special about it except for a middle click to "link" both throttles together, but this only for mouse driven commands to the throttles. If I were to guess - it may be something like a "model specific" plan was setup at one time and never fully finished. Having a different set of eyes look at the FSUIPC4.ini may shed some light. Roman

Bob & John, May have found it. (a nice morning brain teaser to start the day) Testing with FSX it acts exactly the same as Bob's original post. There must be a difference between the command "Magneto" & "Magneto#". This was my setup for the 1st test (using numpad for ease) and it acted the same as Bob's original post - 25=97,8,65927,0 -{Num1: Press=MAGNETO1_OFF }- 26=98,8,65929,0 -{Num2: Press=MAGNETO1_LEFT }- 27=99,8,65928,0 -{Num3: Press=MAGNETO1_RIGHT }- 28=100,8,65930,0 -{Num4: Press=MAGNETO1_BOTH }- 29=101,8,65933,0 -{Num5: Press=MAGNETO2_OFF }- 30=102,8,65935,0 -{Num6: Press=MAGNETO2_LEFT }- 31=103,8,65934,0 -{Num7: Press=MAGNETO2_RIGHT }- 32=104,8,65936,0 -{Num8: Press=MAGNETO2_BOTH }- In gauge programming and in FS internals there are actually 2 separate magneto systems for each engine's magneto as a whole. Ex - There is a left engine 1 Mag, a right engine 1 mag, a left engine 2 mag & a right engine 2 mag.. 4 of them, all separate entities. In XML gauges the logic for just 1 magneto switch is as follows - <Rotate> <Value>(A:Recip eng right magneto:1,bool) 2 * (A:Recip eng left magneto:1,bool) +</Value> <Nonlinearity> <Item Value="0" X="111" Y="205"/> <!-- OFF --> <Item Value="1" X="133" Y="211"/> <!-- LEFT --> <Item Value="2" X="146" Y="227"/> <!-- RIGHT --> <Item Value="3" X="153" Y="248"/> <!-- BOTH --> </Nonlinearity> <Delay DegreesPerSecond="180"/> </Rotate> Something with the internal FS registers (the L & R mag per engine) is wonky dealing with these commands. For instance think of the L mag as bit 0, Right mag as bit 1, using the command MAGNETO#_LEFT will only set bit 0 but not clear bit 1. Using the command MAGNETO#_RIGHT will only set bit 1 but not clear bit 0. Although not tested, I can almost hazard to guess that the FSUIPC command "MAGNETO# SET" using parameters will work correctly with the following parameters - EDIT - This is much easier than using the workaround shown below, tested working. Engine 1 - "MAGNETO1 SET" (66400), params: 0 = Off, 1 = R Mag, 2 = L Mag, 3 = Both Engine 2 - "MAGNETO2 SET" (66401), params: 0 = Off, 1 = R Mag, 2 = L Mag, 3 = Both 25=97,8,66400,0 -{Num1: Press=MAGNETO1_SET }- 26=98,8,66400,1 -{Num2: Press=MAGNETO1_SET }- 27=99,8,66400,2 -{Num3: Press=MAGNETO1_SET }- 28=100,8,66400,3 -{Num4: Press=MAGNETO1_SET }- 29=101,8,66401,0 -{Num5: Press=MAGNETO2_SET }- 30=102,8,66401,1 -{Num6: Press=MAGNETO2_SET }- 31=103,8,66401,2 -{Num7: Press=MAGNETO2_SET }- 32=104,8,66401,3 -{Num8: Press=MAGNETO2_SET }- Going back to the original problem of possibly bad internal registers and using Bob's original commands - there is a work around and it is easy. To reset the wonky registers just turn the magneto off first before commanding either MAGNETO#_LEFT or MAGNETO#_RIGHT. Tested working correctly - ENGINE 1 - 25=97,8,65927,0 -{Num1: Press=MAGNETO1_OFF }- ; OK 26=98,8,65927,0 -{Num2: Press=MAGNETO1_OFF }- ; ENGINE 1 LEFT MAGNETO COMMAND SETS 27=98,8,65929,0 -{Num2: Press=MAGNETO1_LEFT }- 28=99,8,65927,0 -{Num3: Press=MAGNETO1_OFF }- ; ENGINE 1 RIGHT MAGNETO COMMAND SETS 29=99,8,65928,0 -{Num3: Press=MAGNETO1_RIGHT }- 30=100,8,65930,0 -{Num4: Press=MAGNETO1_BOTH }- ;OK ENGINE 2 - 31=101,8,65933,0 -{Num5: Press=MAGNETO2_OFF }- ;OK 32=102,8,65933,0 -{Num6: Press=MAGNETO2_OFF }- ; ENGINE 2 LEFT MAGNETO COMMAND SETS 33=102,8,65935,0 -{Num6: Press=MAGNETO2_LEFT }- 34=103,8,65933,0 -{Num7: Press=MAGNETO2_OFF }- ; ENGINE 2 RIGHT MAGNETO COMMAND SETS 35=103,8,65934,0 -{Num7: Press=MAGNETO2_RIGHT }- 36=104,8,65936,0 -{Num8: Press=MAGNETO2_BOTH }- ;OK Hope this helps, Roman

The original above was fixed.. The log gives the line number where the error occurred --> QWTcasAutobrake.lua:25: ')' expected near '}' How in the world did I miss the } where a ) should have been? Time to see the eye doctor I reckon.. 😉 math.max(val1, val2) & math.min(val1, val2) are comparators. They compare the 2 values and give either the lesser (min, a maximum limit) or the greater (max, a minimum limit) ex. n = 5 n = n + 1 -- n now equals 6 n = math.min(n, 5) -- n now equals 5 because 5 is the smaller (the minimum) of the 2 comparing numbers --> 5 and 6. 5 is the highest it will go acting as an upper limit. It is correct as is, even in XML gauge scripting the min / max throws people a curve. Roman

Just a quick look, and some notes for you for the future, hope it helps. Logging with FSUIPC can help you find any errors keeping the lua from running. I use the Logging Tab | "Debug/Trace Lua plugins" and "Send to console window". Very convenient, specially if you have multiple monitors. Here is what i have found : missing comment symbols in your notes at the top, specifically the variables section missing beginning quote in the first ipc.writeLvar attribute missing comma separating the attributes on the second ipc.writeLvar multiple missing "then"s after previous "if"s on the second ipc.readLvar the attribute was surrounded by ( attribute } rather than ( attribute ) Any of the above will cause the lua to fail. Below is an untested version written slightly different. Instead of using "if"s the lua math library was used to limit the values. If you plan on adding any more commands to this lua a re-write should be done using the FSUIPC/Lua Event library. Hope it works for you. Roman --[[ Parameters by Number : 1 Turn TCAS Clockwise one position 2 Turn TCAS Counter Clockwise one position 3 Turn Autobrake clockwise one position 4 Turn Autobrake Counter Clockwise one postion Variables : "L:QW_AFT_Transponder_Knob" "L:auto_brake_switch" ]] -- Declare variable n = 0 -- Inc TCAS if ipcPARAM == 1 then n = ipc.readLvar("L:QW_AFT_Transponder_Knob") n = n + 1 n = math.min(n, 4) ipc.writeLvar("L:QW_AFT_Transponder_Knob", n) end -- Dec TCAS if ipcPARAM == 2 then n = ipc.readLvar("L:QW_AFT_Transponder_Knob") n = n - 1 n = math.max(n, 0) ipc.writeLvar("L:QW_AFT_Transponder_Knob", n) end -- Inc Autobrakes if ipcPARAM == 3 then n = ipc.readLvar("L:auto_brake_switch") n = n + 1 n = math.min(n, 6) ipc.writeLvar("L:auto_brake_switch", n) end -- Dec Autobrakes if ipcPARAM == 4 then n = ipc.readLvar("L:auto_brake_switch") n = n - 1 n = math.max(n, -1) ipc.writeLvar("L:auto_brake_switch", n) end

For kicks I tested this both in the MV T-38A & MV T38A Advanced using FSX. 0x088C (l eng) & 0x0924 (r eng) using S16 work fine for both. There is an L:Var, not sure for what as it only monitors the left engine - (L:Engine1ThrottlePosition, number) - 50 = idle, 0 = full throttle. Again this is for both Talon A versions. Milviz must be using some other interface for P3D... Roman

In the initial post the last lua, "LVAR_SPECIFIC.lua" has been modified to include a check for nil values to keep the lua alive if a nil is ever encountered. Example of these are: 1) Poor L:Var name entries in to the lua. IE spelling, poor formatting etc... 2) Primarily this change came about when checking an output of a .dll where the .dll itself does not report/initialize its expected L:Var outputs until a certain situation has occurred. Roman

I would hazard to guess this may work, similar to batch or lua ext.shell(path, options) - Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE" "STEAM" Roman

It is not a problem with FSUIPC. Many designers must use L:Vars to create advanced autopilot functions incorporated into the stock AP. Some examples are FLCH, Pitch climb/desc, SPD climb/desc, FPA and so on. Consider the L:Var as the human ALT input into some hidden code that controls the "internal" AP ALT values. I do not have the Carendo DA62, but do have the Alabeo DA42, so the following "may" work. The Carenado/Alabeo guys have got themselves an assembly line when it comes to systems - they continually reuse old code from their other releases. For instance, in the DA42... (L:VARKNOB_MFD_ALT100_SR22, number) From the SR22 release.. ( BTW - that var just provides animation ) Looking deeper into the DA42 code I found, and "assume" this... 1 (>L:G1000MFDALT100WheelDN,number) --> sending a 1 to this var will decrease their "internal" calculated AP alt value. 1 (>L:G1000MFDALT100WheelUP,number) --> sending a 1 to this var will increase their "internal" calculated AP alt value. Even if these are the correct vars or not, a lua script or macro will have to be made to incorporate hardware into the DA62 alt adjust. Sorry, cannot help much more without the DA62, but hopefully it gives an idea of where to go from here. Roman EDIT - Unknown if Carenado did the extra work but it "is" possible to have traps that intercept stock commands and feed them to their internal calculations. You could try the following, listed in "The #### List of FSX and P3D Controls.pdf" found in your Modules\FSUIPC Documents folder. G1000 PFD ZOOMIN BUTTON 66748 thru G1000 MFD SOFTKEY12 66800 If any may work, they could any of the following - G1000 PFD GROUP KNOB INC 66757 G1000 PFD GROUP KNOB DEC 66758 G1000 PFD PAGE KNOB INC 66759 G1000 PFD PAGE KNOB DEC 66760 or G1000 MFD GROUP KNOB INC 66785 G1000 MFD GROUP KNOB DEC 66786 G1000 MFD PAGE KNOB INC 66787 G1000 MFD PAGE KNOB DEC 66788

I think there could be at least 2 different ways to do this - 1) When the lua is started it will get the .air file name then selecting the correct ext.position wanted from the air file name. Ex. Code not tested airFileName = ipc.readSTR(0x3C00, 256) -- get the air file name on lua load if string.find(airFileName, "Lear45") then -- air file name of FS9 Lear45 as an example ext.position("Electrical", 0, 0, 40, 20,3) ext.position("APU", 40, 20, 20, 15,3) ext.position("Throttle quadrant", 0, 20, 40, 76,3) ext.position("Trim", 65, 0, 20, 15,3) ext.position("Fuel", 40, 0, 25, 20,3) end if string.find(airFileName, "Aerosoft F-14A") then -- air file name of FSX Aerosoft F-14A as an example ext.position("Electrical", 28, 70, 35, 21,3) ext.position("Trim", 0, 70, 28, 26,3) ext.position("Fuel", 0, 48, 50, 22,3) ext.position("Overhead Panel", 0, 3, 68, 46,3) ext.position("Radio stack", 68, 3, 26, 71,3) ext.position("Landing Gear", 50, 48, 15, 22,3) end 2) Exactly what you asked for - This will ask you for a keyboard input to the ext.position wanted ... NOTE - In FSX I occasionally get a problem with this when the asking dialog comes up it also selects (right click on screen) "Mouse as Yoke" ?? it is very weird. (can live with it) Ex. Code partially tested but should work as is -- THIS IS THE POPUP ASKING DIALOG local askOptions = " LOAD WINDOW LOCATION TYPE\n Type in number then press ENTER\n\n 0 = none\n 1 = Lear 45\n 2 = Grumman\n 3 = empty slot\n 4 = empty slot\n 5 = empty slot" n = ipc.ask(askOptions, WHITE) if n == "1" then -- REPLY WAS 1, LEAR 45 ext.position("Electrical", 0, 0, 40, 20,3) ext.position("APU", 40, 20, 20, 15,3) ext.position("Throttle quadrant", 0, 20, 40, 76,3) ext.position("Trim", 65, 0, 20, 15,3) ext.position("Fuel", 40, 0, 25, 20,3) end if n == "2" then -- REPLY WAS 2, GRUMMAN ext.position("Electrical", 28, 70, 35, 21,3) ext.position("Trim", 0, 70, 28, 26,3) ext.position("Fuel", 0, 48, 50, 22,3) ext.position("Overhead Panel", 0, 3, 68, 46,3) ext.position("Radio stack", 68, 3, 26, 71,3) ext.position("Landing Gear", 50, 48, 15, 22,3) end if n == "3" then -- REPLY WAS 3, EMPTY end if n == "4" then -- REPLY WAS 4, EMPTY end if n == "5" then -- REPLY WAS 5, EMPTY end Here is a screenshot of the asking dialog ( of course from something of my own )

This is for FSX, unsure w/ P3D, assuming it should be very similar. <sim closed> 1) Open up your cameras.cfg in a plain text editor. (C:\Users\<USER>\AppData\Roaming\Microsoft\FSX) A backup might be a very good idea. 2) Go through each camera entry ( [CameraDefinition.XXX] ) and note if the section has this entry - HotKeySelect="#" 3) Make a note of each of the entries. Their camera type (Title = <type>) & the HotKeySelect number. 4) Go to the "Title=FlyBy" CameraDefinition entry and add the following line to the bottom of that section ( Only if not already provided! ) - HotKeySelect=XX, where XX is the next available number from the list you made in step 3. Save the file. <start sim> 5) Assign your flyby view button in FSUIPC as - VIEW_CAMERA_SELECT_XX, where XX is the new number you provided in step 4, or the number already listed in step 3. NOTE - The camera.cfg in Appdata is the "global" camera. Any aircraft designer can override the global HotKeySelect numbers in their own CameraDefintion(s) residing in the aircraft.cfg. It does happen, but rare. 😼 Shame on them. P3D reference here. Works great for me.. Roman

After a quick look the code above "seems" to be good - not tested. It looks like your text editor is making the error, introducing an illegal character. (line1) Make sure your text editor is in english & ANSI or UTF-8 encoding. Roman

For the first part - It looks like you may have a syntax error that FSUIPC doesn't catch, you are using a "repeat" modifier in the second half of the compound code. None of my compounds have this. Perhaps having this negates the original "CR" in the first part of the compound code. 45=CR(-3,29)R3,2,C65879,0 -{HEADING_BUG_INC}- 46=CR(-3,29)R3,8,C65880,0 -{HEADING_BUG_DEC}- 47=CR(+3,29)R3,2,C65663,0 -{VOR1_OBI_INC}- 48=CR(+3,29)R3,8,C65662,0 -{VOR1_OBI_DEC}- Maybe (?) this will work - 45=CR(-3,29)3,2,C65879,0 -{HEADING_BUG_INC}- 46=CR(-3,29)3,8,C65880,0 -{HEADING_BUG_DEC}- 47=CR(+3,29)3,2,C65663,0 -{VOR1_OBI_INC}- 48=CR(+3,29)3,8,C65662,0 -{VOR1_OBI_DEC}- For the second part - I see that you are using profiles and that particular profile is for the 310, perhaps the Milviz C310? I do not have that model from them so cannot test. I can bet apples to oranges that they are not using standard FS type coding, rather using L:Vars instead. (many designers do use L:Vars, specially for heading) My advice? Try your compound code with something stock and non-complex such as the 172 or Baron. If it works for the 172 / Baron then further investigation will need to be done, possibly using a lua file will need to be done to interface with it. Roman

Milan, Excellent - Glad it worked for you! Edited my post above with the capital "B" in case anyone else wants to use it. Thanks Roman

Many of the newer designers are using "sense" variables. Meaning that they sense the user did something. In background coding somewhere, that "sense" var triggers other code to do something. It then resets itself to zero once done. Acting somewhat like a "toggle" rather than a "set". This seems to be the case in the 787. From the simbuilders kit.pdf - Capt Baroset STD Select (STD Only for CAPT) | 6 | QW_MCP_L_BRST_STD_Button | 1=Pressed Using a parameter of 1 for both on & off should get it working correctly with your code. The problem is that your constant button may (and probably will) get out of synch with the 787 panel. Using a momentary push button would alleviate that. Roman

The first code probably wouldn't work, even if corrected, unless it was part of some other coding - it is a "one shot". Meaning it loads once then does nothing. The following "should" work (not tested) as long as the documentation of SB3 is forward compatible with vPilot & that the QW documentation is correct too. It also includes the ident button. Use [Auto] to start. (even better with profiles) -- SETTING 1 TO OFFSET EQUALS OFF / STANDBY FOR THE XPNDR function vPilot_XPNDR (varname, value) if value < 2 then ipc.writeSB(0x7B91, 1) else ipc.writeSB(0x7B91, 0) end end function vPilot_IDENT (varname, value) if value == 1 then ipc.writeSB(0x7B93, 1) end end event.Lvar("QW_AFT_Transponder_Knob", 250, "vPilot_XPNDR") event.Lvar("QW_AFT_Transponder_Button", 250, "vPilot_IDENT")

Ray, Yes I understand.. Wish that it could be stand a alone for the biggest airports.. It works great up to those biggest traffic areas though. EGLL was just above the limits until the traffic started flowing, it then settled down to below the limits. Going to keep going just for the learning experience, only a few meters away from the finish line. 😉 Why stop now? Paul Henty's newest module has some great new features haven't seen before and this little project will use them. Will advise when finished, even if not interested.. It's not a big deal - the learning experience is worth it! Roman

Hi Ray, Big problems here.. Using FSUIPC limits the count of both on ground and in air AI to 96 each. Are you sure Ai Companion runs over Wideclient? Rather I am thinking it is possibly simconnect instead in order to get over the 96 each max count. Simconnect is out of my league.. I could however use a server gauge in the test aircraft to get a full count "and" be able to center on an ICAO too.. Something that doesn't seem possible using the FSUIPC route. The program is to the point of integrating a XML gauge.. Your thoughts? Would using a server gauge, needed to be installed in the test aircraft be too much? Roman

Ray, Guess I didn't have enough coffee yesterday.. Forgot to look at the lua library - flags & l:var read/write are not available on wideclient. A gauge server to lua works great (see image) but only on the local FS computer. I wanted to give it some user adjustability, namely the AI lookup radius & AI lookup timing. ( the latter dependant on the users sim performance - kind of important ) In order to do this and run it on wideclient it would have to be: gauge server < --- > local sim lua < --- > fsuipc user offsets (or ipc. get/set) < --- > wideclient lua Each of the 4 parts need to "talk" to its neighbor in the logic chain. Kind of a mess to say the least.. So it looks like an exe will be the route.. Not the best as a self taught hobbyist doing exe programming so it will take a while. Another project for tomorrow's coffee 😉