Jump to content
The simFlight Network Forums

spokes2112

Members
  • Content Count

    212
  • Joined

  • Last visited

  • Days Won

    6

spokes2112 last won the day on February 12

spokes2112 had the most liked content!

Community Reputation

18 Good

1 Follower

About spokes2112

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    _KGRB
  • Interests
    FS Programming, Electronics, Vintage Radios

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. spokes2112

    Twin magneto problem

    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
  2. 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
  3. 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
  4. spokes2112

    Throttle Offset Tracking

    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
  5. 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
  6. 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
  7. 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
  8. spokes2112

    Tilesix LUA modification

    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 )
  9. spokes2112

    FlyBy view assignement

    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
  10. spokes2112

    Record to csv file example

    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
  11. 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
  12. 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
  13. 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
  14. 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")
  15. spokes2112

    Counting Ai on ground and airborne

    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
×

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.