Jump to content
The simFlight Network Forums

spokes2112

Members
  • Content Count

    221
  • Joined

  • Last visited

  • Days Won

    7

spokes2112 last won the day on January 23

spokes2112 had the most liked content!

Community Reputation

21 Excellent

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,451 profile views
  1. Just recently I needed to do the same thing, write to an L:Var that doesn't exist for AirManager . Created a small gauge and installed it into the VC. It just creates an L:Var by writing to once on load. Roman <Gauge Name="Maddog FGCP VS Mode Server" version="1.0"> <Update> <!-- DO THIS JUST ONCE ON INITIAL GAUGE LOAD --> (G:Var1) 0 == if{ 100 (>L:VS_Mode, number) 0 (>L:VS_Mode, number) 1 (>G:Var1) } </Update> </Gauge>
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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

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