Jump to content
The simFlight Network Forums

spokes2112

Members
  • Content Count

    168
  • Joined

  • Last visited

  • Days Won

    6

spokes2112 last won the day on February 12

spokes2112 had the most liked content!

Community Reputation

17 Good

1 Follower

About spokes2112

  • Rank
    Advanced Member
  • Birthday 04/03/1967

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. Rustam, Just gave it a go using the keyboard for a quick test. It looks like NEXT_VIEW (65827) & PREV_VIEW (65828) may be either pre-FSX commands or for use with 2D cockpits. The following seem to work in FSX - 16=97,8,65567,0 -{Num1: Press=VIEW_MODE }- 17=98,8,65749,0 -{Num2: Press=VIEW_MODE_REV }- Keep in mind that in order to cycle thru views like this that the following camera.cfg entry must be "No" for each of the cameras you want to be included for the view mode changes using the commands above. CycleHidden=No Roman
  2. spokes2112

    LVars for C47 Start Switch

    Tom, Did you get it work? If not, this may help. Many times there is logic involved within the visual model on the clickspot. When using the FSX or greater SDK to compile the model the XML animation / logic code is visible using a hex editor. This is the case for the C-47, below is the retrieved code. (comments on engine 1) Note that 0 = OFF & 50 = ON for the starter switch. Looks like he combined the animation and logic together. <!-- STARTER 1 --> <!-- TURN STARTER OFF AND QUIT ALL FURTHER CODE --> (L:Starter switch:1, enum) 0 != if{ 0 (>L:Starter switch:1, enum) 0 (>L:Starterturn1, rpm) quit } <!-- TURN STARTER ON BUT IF THERE IS NO POWER QUIT ALL FURTHER CODE --> 50 (>L:Starter switch:1, enum) (A:Circuit general panel on, bool) ! if{ quit } <!-- IF ENGINE ACTUALLY FIRES (USING SOME SLOW START CODE) QUIT ALL FURTHER CODE --> (A:PROP RPM:1, rpm) 0 > if{ quit } <!-- INITIALIZE THE SLOW START VISUAL CODE --> (L:slowprop, rpm) (>L:Starterturn1, rpm) <!-- STARTER 2 --> (L:Starter switch:2, enum) 0 != if{ 0 (>L:Starter switch:2, enum) 0 (>L:Starterturn2, rpm) quit } 50 (>L:Starter switch:2, enum) (A:Circuit general panel on, bool) ! if{ quit } (A:PROP RPM:2, rpm) 0 > if{ quit } (L:slowprop, rpm) (>L:Starterturn2, rpm) This may be a good candidate for lua but because of the "quit" the coding would have to be done carefully. May give it a try after some thought. EDIT - decided to give it a go.. Here is a lua as a direct copy of the VC starter code - tested, seems good. Note - during testing it was found that there are a few obscure bugs dealing with power supplied and the starter logic. I kept any corrections out of it to keep the intentions of Manfred true. Code below and attached. --[[ 1) With FS Closed, copy this code into a blank text file located in /modules and name it "MJC47_START.lua" 2) To use starter one, use the FSUIPC command "Lua MJC47_START" with a parameter of 1 3) To use starter two, use the FSUIPC command "Lua MJC47_START" with a parameter of 2 ]] local startSw = 0 local propSlow = 0 local propRpm = 0 local pnlPwr = 0 -- STARTER 1 if ipcPARAM == 1 then startSw = ipc.readLvar("Starter switch:1") if startSw ~= 0 then -- TURN OFF STARTER ipc.writeLvar("Starter switch:1", 0) -- PHYSICALLY MOVE SWITCH TO OFF POSITION ipc.writeLvar("Starterturn1", 0) else -- TURN ON STARTER ipc.writeLvar("Starter switch:1", 50) -- PHYSICALLY MOVE SWITCH TO ON POSITION propRpm = ipc.readDBL(0x2400) pnlPwr = ipc.readDBL(0x2840) if propRpm == 0 and pnlPwr ~= 0 then -- QUIT IF ACTUAL PROPS TURN BY FS CONTROLLED ENGINE OR NO PANEL POWER propSlow = ipc.readLvar("slowprop") ipc.writeLvar("Starterturn1", propSlow) -- SLOW PROP TURNING INI end end end -- STARTER 2 if ipcPARAM == 2 then startSw = ipc.readLvar("Starter switch:2") if startSw ~= 0 then -- TURN OFF STARTER ipc.writeLvar("Starter switch:2", 0) -- PHYSICALLY MOVE SWITCH TO OFF POSITION ipc.writeLvar("Starterturn2", 0) else -- TURN ON STARTER ipc.writeLvar("Starter switch:2", 50) -- PHYSICALLY MOVE SWITCH TO ON POSITION propRpm = ipc.readDBL(0x2500) pnlPwr = ipc.readDBL(0x2840) if propRpm == 0 and pnlPwr ~= 0 then -- QUIT IF ACTUAL PROPS TURN BY FS CONTROLLED ENGINE OR NO PANEL POWER propSlow = ipc.readLvar("slowprop") ipc.writeLvar("Starterturn2", propSlow) -- SLOW PROP TURNING INI end end end Roman MJC47_START.lua
  3. spokes2112

    Problem with ipc.display

    Quite possibly your display window may be off screen if undocked and set there once before. In FSX this display location is saved in a saved flight file. Maybe try setting a new location and also give it a display duration in case it is clearing too quick. Also try in windowed mode if you are full screen. ipc.setowndisplay("My Lua Display Test", 48, 2, 4, 0) -- this will relocate the window top dead center in the fs main window ipc.display("HI", 5) -- 5 second display duration ref = sound.play("GearUpCall") Roman
  4. Good deal... 😄 My apologies on the L:Var, and good find! Took a closer look at the A321 in FSX (boxed) and sure enough, there is a long standing bug! Never noticed because I've never flown the A321. An example of the ECAM controller buttons for ECAMS2 popup. (ECAMS 1 has no controller) [Window11] Background_color=0,0,0 size_mm=1024,768 position=0 visible=0 ident=503 gauge01=Airbus_A321!popup_ecams_screen_bezel, 683,415,341,353 <-- Stock example below gauge02=Airbus_A321!ecams2, 707,441,289,289 <-- Stock example below popup_ecams_screen_bezel - ... <Script> (M:Event) 'LeftSingle' scmp 0 == if{ 1 (&gt;G:Var1) 0 (&gt;L:ECAMS Display, number) } (M:Event) 'LeftRelease' scmp 0 == if{ 0 (&gt;G:Var1) } </Script> ... <Script> (M:Event) 'LeftSingle' scmp 0 == if{ 2 (&gt;G:Var1) 1 (&gt;L:ECAMS Display, number) } (M:Event) 'LeftRelease' scmp 0 == if{ 0 (&gt;G:Var1) } </Script> ... <Script> (M:Event) 'LeftSingle' scmp 0 == if{ 3 (&gt;G:Var1) 2 (&gt;L:ECAMS Display, number) } (M:Event) 'LeftRelease' scmp 0 == if{ 0 (&gt;G:Var1) } </Script> ecams2 - ... <Visibility>(L:ECAMS2 Display,number) 0 == (A:CIRCUIT GENERAL PANEL ON, bool) &amp;&amp;</Visibility> ... <Visibility>(L:ECAMS2 Display,number) 1 == (A:CIRCUIT GENERAL PANEL ON, bool) &amp;&amp;</Visibility> ... <Visibility>(L:ECAMS2 Display,number) 2 == (A:CIRCUIT GENERAL PANEL ON, bool) &amp;&amp;</Visibility> ... As you can see.. The Controller cannot even control ECAMS 2! 1 (&gt;L:ECAMS Display, number) <!-- VERSUS --> (L:ECAMS2 Display,number) 1 == Again my apologies 😥 but glad it is working for you. 👍 Roman
  5. Tom, Ahh, I see now.. I believe you will need to monitor all 3 buttons with conditions on all 3. First off, need to change the CP (compound press) to CU (compound unpress / release) then have three conditional button monitors on 3 (not 4 buttons) EX - 24=CU(-B,0)(-B,6)B,12,C65927,0 25=CU(-B,0)(-B,12)B,6,C65927,0 26=CU(-B,6)(-B,12)B,0,C65927,0 Even better, but may not work if real speedy movements are made with the rotary switch. Magneto order, with pseudo example button #s - OFF (none) --> L Mag (#1) --> R Mag (#2) --> Both (#3) --> Start (#4) So if turning things off (right to left) then all you need to monitor the unpress of #1 and make sure #2 doesn't get pressed to trigger the Mag Off. 24=CU(-B,2)B,1,C65927,0 Any of the above could be dependant on the rotary switch types - "make before break" or "break before make" and the polling speed of your hardware, just needs testing.. Roman
  6. The document needed is Modules\FSUIPC Documents\FSUIPC Lua Library.pdf with the command needed on page 10 at the top. For any lua scripting in FSUIPC this will be the "go-to" document with others as references. (... List of FSX and P3D Controls & ... Offsets Status are the main ones) If... And only if this is the only operation you want done via lua then you can get away with a "run once, self killing" lua script with no major consequences. A plus? 1 line. ipc.writeLvar("ECAMS Display", ipcPARAM) 1) copy the above code and save as 321ECAMS.lua in the modules folder 2) use the command "Lua 321ECAMS" and then the number (shown above) of the display wanted in the parameter field of the FSUIPC dialog
  7. Tom, Pete or John may intervene if I flub this up.. I believe you are getting confused in the FSUIPC document. You have his example definitions as actual code. EX.. (-jB,b0) The "-" signifies that the button is unpressed, + is pressed The jB signifies the device. If you have AutoAssignLetters=Yes then this will be a single letter, otherwise will be a number. The b# signifies the button on the said device, will be a number. Also, the last definition is the trigger, not the conditions(s) and shouldn't be in parentheses. Given AutoAssignLetters=Yes and your device is letter "D" the code, using buttons 0 & 6 as conditions (both unpressed) and 12 as the trigger - 24=CP(-D,0)(-D,6)D,12,C65927,0 Not using AutoAssignLetters and your device is number "3" the code, using buttons 0 & 6 as conditions (both unpressed) and 12 as the trigger - 24=CP(-3,0)(-3,6)3,12,C65927,0 Good luck.. Roman
  8. They are L:Vars, here's a list I have on hand for the 321- 0 = Engine 1 = Bleed 2 = Pressurization 3 = APU 4 = Hydraulics 5 = Fuel 6 = Flt Controls (>L:ECAMS Display, number) Roman
  9. sLYFa, Wow! That original supplied lua was really a killer. Not only did it self kill itself but when restarted on each command it initialized, at minimum, 75 variables. Only 2 are needed. I rewrote it using all the commands. It does take quite a bit on the first load (using auto) to read and compile everything - about 10 seconds! After that, while listening for commands, it just sits there. On a command it goes through about 6 lines, taking a millisecond or less. Seems to work well. Overall the complete method & about 80% of the code was changed. In my opinion it still lies in a grey area for redistribution since it was originally supplied as payware, and, I don't own it. If you would like to try it just PM me and I will send you the link. Roman
  10. The lua itself is still self - killing so when autostarted it will just end. Needs to be re-written. Most likely because it is still compiling on each start. An overview of what is needed: 1) A rewrite of the lua so it does not kill itself. The use of an event listener - event.flag("<function name>") will accomplish this. 2) Use auto start in profiles, or, globally to test. [Auto] 1=Lua <my F-14 lua name> 3) Use any of the following FSUIPC commands to initiate the already running lua. Do not use Lua <my F-14 lua name> as this will just restart it a) LuaToggle <my F-14 lua name> <-- This will most likely be the one to use. b) LuaSet <my F-14 lua name> c) LuaClear <my F-14 lua name> A friend sent me the lua from his AS F-14 package. Will be able to look closer and test now, he wants a rewrite too! 😉 Roman EDIT - Just looked at it.. It uses ipcParam instead so my notes above are invalid (in red). Will be able to get this much more efficient though..
  11. John and/or Pete, As a self taught lua scripter I was wondering if my example above still isn't very efficient. Was thinking that creating ~200 separate 'event.flag' listeners isn't a good idea. Based on that premise I did some experimenting and created the following using a global 'event.flag' listener. It seems very efficient for use with many functions. Works fine but the only drawback seen is that FSUIPC logging does not recognize the ending function because of the use (?) of the global namespace to call it. No big deal, or is it? Thoughts? and/or tips? Currently have no use for the example but probably will in the near future so keeping it in the back pocket for now. Pete - Congrats on your upcoming retirement! Cannot Thank You enough for your contributions to the flight sim community! More so, I have learned lua, VB.net, and a little bit of C# (thanks Paul Henty) only because of the existence of FSUIPC.. That is worth a million Thank-You's in of itself. Happy New Year! Roman -- Landing Lights, param = 1 function funcNum1() ipc.control(65751) end -- Nav Lights, param = 2 function funcNum2() ipc.control(66379) end -- Parking Brake, param = 3 function funcNum3() ipc.control(65752) end -- Flaps Up, param = 4 function funcNum4() ipc.control(65595) end -- Flaps Down, param = 5 function funcNum5() ipc.control(65603) end -- Select proper function above in global namespace -- This function called from funcProtect (below) function funcSelect(flag) _G['funcNum' .. flag]() end -- Call "funcSelect" (above) in protected mode (below) -- If FSUIPC parameter does not call a function -- Show lua window giving bad parameter number - keep lua running function funcProtect(flag) if pcall(funcSelect, flag) == false then ipc.display(flag .. ' is not a valid parameter for this lua!', 2) end end -- Using "LuaToggle" event.flag("funcProtect")
  12. It sure does look like a run once, self killing lua. (need full code) Meaning it launches each time a button is pressed, then killing itself. Loading the lua then iterating through all the if/elses to find the correct one, doing the command then killing itself will put a tax on the sim. A more efficient way would be to rewrite the code using functions and using an event listener such as event.flag then have the lua be auto started (using profiles) on the F-14 aircraft load. Re-assigning buttons or keys would not be that difficult either - changing from "Lua <lua name>" to "LuaToggle <lua name>" using the same parameters. (even easier via editing the FSUIPC.ini) Can almost guarantee that a rewrite of the code (based on the provided above) to something similar to the following should fix it up nicely - local SCov = 0 local OSw = 0 local tog = 0 -- Sweep Rocker to Auto Mode function P1(flag) ipc.writeLvar(Sweep_R1, 0) ipc.writeLvar(Sweep_R2, 0) end -- Sweep Rocker to Bomb Mode function P2(flag) ipc.writeLvar(Sweep_R1, 2) ipc.writeLvar(Sweep_R2, 2) end -- Sweep Rocker to Manual FWD function P3(flag) ipc.writeLvar(Man_Sweep, 1) ipc.writeLvar(Sweep_R2, 1) end -- Sweep Rocker to Manual AFT function P4(flag) ipc.writeLvar(Man_Sweep, -1) ipc.writeLvar(Sweep_R2, 1) end -- Sweep Rocker to Center function P5(flag) ipc.writeLvar(Man_Sweep, 0) ipc.writeLvar(Sweep_R2, 1) end -- Emergency Sweep Cover Toggle function P6(flag) tog = 0 SCov = ipc.readLvar(Sweep_Cover) if SCov == 0 then tog = 1 end ipc.writeLvar(Sweep_Cover, tog) end -- Oversweep Toggle function P7(flag) tog = 0 OSw = ipc.readLvar(Over_Sweep) if OSw == 0 then tog = 1 end ipc.writeLvar(Over_Sweep, tog) end event.flag(1, "P1") event.flag(2, "P2") event.flag(3, "P3") event.flag(4, "P4") event.flag(5, "P5") event.flag(6, "P6") event.flag(7, "P7") EDIT - Looking at your FSUIPC.ini It looks like my assumptions are indeed fact - a run once, self killing lua with possibly 200+ commands!?! That is a lot of iterations to run through each time an assigned button is pressed. Also below is an example of how easy it could be by hand editing the .ini after the lua code change, changes in bold red. Ex.. 1=P0,17,CL1:R,0 -{Lua Aerosoft_F14AB}- would become 1=P0,17,CL1:T,0 -{Lua Aerosoft_F14AB}- and on and on for the rest of the F-14 assignments. Roman
  13. spokes2112

    Lua - ipc.setowndisplay, a bug?

    Pete - Thank you as always! The revised shift #s has saved me from a big headache.. Did some more testing regarding the constant entries of the "lua type" window opening within a saved flight file. Somewhere in FS it temporarily saves each time the "lua type" window gets opened from the simconnect call. When the flight is saved it logs each one of these "opens" to the flight file. Guess that is what MS wanted - Oh Well, again, no big deal. But it just doesn't seem correct. Thanks again, Roman
  14. spokes2112

    Crashing with AI traffic

    To further give some insight.. When it does stop working, go to the FSUIPC dialog, "Key Presses" tab then click the "Reload All Keys" button. Does it come back? If so, most likely something for Pete. ( it happens very rarely to me in FSX, I don't mind, the reload fixes it ) If not, then a possibility is that something (other program or service) is hammering simconnect, rejecting your FSUIPC command.
  15. Hi Pete, Hope your travels & visits were nice. Something just noticed & not really a big deal except for the repetitive nature (the repeats could get quite large) in a saved flight file. The logging of the lua type window keeps going and going.. Maybe a simconnect bug? I've tried setting ipc.setowndisplay just once on the lua load, and, for a different test, each time the display function gets called - makes no difference. Shouldn't it just update the required entries under the window header? ( [window name] ) Replace, not append? FSX Acceleration, FSUIPCv4.974b (maybe applies to FSUIPC v5 too?) EDIT - second question. Just may find out before you return but if not, need clarification. In the Lua Library pdf when using ipc.keypress it says to use the keys chart in the advanced users pdf while when using ext.sendkeys it refers to the key chart in the Lua Library pdf. Are these 2 different on purpose? The only glaring difference is the use of shift code 8, "normal" versus "tab". Regards, Roman Records from a saved flight below -
×

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.