Jump to content
The simFlight Network Forums

spokes2112

Members
  • Content Count

    217
  • Joined

  • Last visited

  • Days Won

    6

spokes2112 last won the day on February 12

spokes2112 had the most liked content!

Community Reputation

19 Good

3 Followers

About spokes2112

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    -KGRB
  • Interests
    FS Programming, Electronics, Vintage Radios

Recent Profile Visitors

2,353 profile views
  1. 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
  2. Hi Spoke,

    im here again for the interface of my maddog. thank you for mervellous work done in mounths ago, but nowi need some other offset if is possible to complete the cockpit. The LUA IPC found and tune from old skalarki file is incomplete, missed gears, doors, weel no turning, art switch, loops onafter oh. I tried to read the IPC from fsuipc but the problem is that run very fastly and i can read the offset. Can you help me again ? many thanks Simone

    1. Show previous comments  17 more
    2. sisoffi

      sisoffi

      maddogX.lua with update EFIS button led,

      in the after misse the 4 apu and gpu pwr avaialbe 

      MADDOG_X.lua

    3. spokes2112

      spokes2112

      Hi Simone..

      It looks like the luas & mcc files you sent don't include any reference to the "original" FGCP offsets. That is what I was looking for. 

      Please don't add anything to the luas.. I am having a tough enough time keeping track of what is going on with it now. 


      Is this the ONLY .mcc you are using? If so... It will be all redone! All new offsets. ( I will modify your .mcc with changes )
      The original Skalarki version used so much memory! I can do it differently with a 75% reduction in memory usage. There is no sense in using a 32bit offset for a boolean ( 1 bit ).

      Do you have skype or teamspeak? I could get answers much quicker that way. 

    4. sisoffi

      sisoffi

      no Roman, because I don't have my fgcp ready yet.

      As I told you, Skalarki works with his own armored system inaccessible for modifications, he has his own profile (I talked to the developer but he doesn't intend to update the profile with macros and lua from mddog2010 to...

      Do you want tot try to open dll and profile?

       

      skype: muranoshop

      TW yes also

       

      SkalarkiIOProfiler4.1.zip MD80Leonardo.zip

  3. Thanks Pete, All points rectified and working smoothly.. 👍 Roman
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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 )
  15. 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
×
×
  • Create New...

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.