spokes2112

As John mentioned the camera definitions in the aircraft.cfg override any of the same/similar global camera definitions when the aircraft is loaded. If you can live without the F11 command for the pedestal view then - 1) The AB 320/321 not loaded in sim 2) in the aircraft.cfg find the camera definition for the "pedestal view" and comment out the HotKeySelect line as shown below - //HotKeySelect=3 (NOTE - this COULD be HotKeySelect=2, do not have the 320 and the P3D SDK somewhat conflicts with the FSX SDK) 3) Load the AB 320/321 up in the sim 4) Use the FSUIPC command "View Camera Select 3" You will now have your spot view but lose the pedestal view. You could get them both back but it would require good knowledge of the camera system and the use of HotKeySelect & View Camera Select #. https://www.prepar3d.com/SDKv4/sdk/cameras/camera_configuration.html

In most cases, for a turboprop type flight model, the mixture commands apply to the condition levers. Have you tried those? The Q400 is a different animal altogether so it may not work, worth giving it a try.

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

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

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

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

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

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

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

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

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

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

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")

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

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

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.

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 -

It's all in the Offsets Status.pdf. (pages 20 & 62) 0x66C0 has 64 bytes available for whatever you would like. 0x0D70 (L:var name) is for reading / writing to L:Vars but uses the 0x66C0 range as a temp register of the L:Var value.

PM me, if wanted, with a list of the aircraft controls you need scripted.. Will give it a shot.

Howdy, I added one line of code to get you close.. Line #43 - ipc.setowndisplay("Throttle Commanded", 48, 2, 4, 0) Left edge located at 48% of total sim width (2784px from 0) , Top edge is 2% down (in case you have UI menu showing - 22px from 0), a window width of 4% (232px).. The last value, % of sim height, I have found in testing that it will automatically grow in height to accomodate text if set to zero. The above values should set the info window dead center in your sim. Adjust values if necessary (Note - Unsure, but believe only integers are allowed) then change to different aircraft, then back to original aircraft to test. For more info on this command, see Modules\FSUIPC Documents\FSUIPC Lua Library.pdf, page 8 or so. Just redownload the package again to get the new lua. Hope it works for you. Roman

No.. Not really. In the original request the user had 3 axis' available for throttle, mixture & props. In that download (V1 &V1.1) the throttle lua controlled the mixture and prop lua's too. That part of the code needed to be removed and the instructions updated. A new kit just for throttles (2 engine only) is here.

Yes.. Make 3 modes with one (cycle modes), or multiple buttons / keys (hot select mode) - Both Engines, Left Engine & Right Engine.. I have similar on my single axis stick.

"AP VS VAR DEC" and "AP VS VAR INC" The list is in --> simulator\Modules\FSUIPC Documents\The 2016 List of FSX and P3D Controls.pdf (or similar)

Sorry Pete, just tested the old fashioned way with the Carenado A-36, via keyboard.. Works perfectly via FSUIPC commands. Suppose too much coffee & over thinking it based on previous posts.. Have a great evening. Roman

If FSUIPC 5 contains the same run functions as FSUIPC 4 then take a look at the \modules\FSUIPC Documents\FSUIPC Documents\FSUIPC# for Advanced Users.pdf look for the "Programs: facilities to load and run additional programs" section. If it all carried over from FSUIPC 4 then something like the following "may" work - (as an example) RunIf1=READY,DELAY,C:\Windows\System32\notepad.exe The above will give a 10 second delay "after" the sim is up and running. Again this is under the assumption that the facilities are still available in FSUIPC 5 No hurting in giving it a try.. Pete will be back soon and can give further advise.