spokes2112

I ran into this similar problem, but using the GPS. 4 GPS's - 2 in VC, 2 in a popup. The 530's were isolated from the 430's by using indexing in the GPS var --> C:fs9gps:<index number> All fine until the 2d popup GPS's were opened. The stock GPS's along with the G1000 use event listeners residing in the XML code. The listeners will not work in the popup until they are opened. If you are using a second iteration of the G1000 in your G1000 board then you now have 2 listeners... The result? 2 commands performed on a control input. It is basically a gauge thing, not your hardware or interface. If this is the case with you ( 2 iterations of G1000 ) the you need to copy the original and rename it to something like : g1000_pfd_no_listen.xml Use that one for the G1000 board or the VC, you will now be using 2 different versions of the same G1000, 1 for VC, 1 for hardware. Then starting around 8167, the start of event listeners comment out the the ones that you are using in your hardware in the "no_listen" version. Ex. <Trigger id="G1000_PFD_SOFTKEY1"> <KeyEvent>G1000_PFD_SOFTKEY1</KeyEvent> <Script>@Softkey0</Script> </Trigger> Becomes.... <!-- <Trigger id="G1000_PFD_SOFTKEY1"> <KeyEvent>G1000_PFD_SOFTKEY1</KeyEvent> <Script>@Softkey0</Script> </Trigger> --> Note.. This also occurs when the keyboard is active for ICAO lookup.. 2 letters get entered per keyboard press. If you want to get rid off all of the listeners in 1 fell swoop for your hardware then comment out the lines 8150 thru 8265 as shown below. Hope this may get you going in the right direction.. ( not the wrong one - heh ) Roman EDIT -- If you are going for a full hardware cockpit, IE not using the VC at all then just comment out the G1000 gauge in the panel.cfg so it is not active. Then you would not have to do the above.. The same procedure could also be used as an easy test to see, if indeed, 2 listeners are causing your problems.

With just a quick look found many errors, that is.. If you supplied the full code. Here's the code with errors commented out and 2 lines added to replace bad ones. function AB_PDS_CPT_Radios_on () ipc.writeLvar("AB_PDS_RADIO_CPT_POWER", 1) -- AB_OVH_Pushbutton () NO FUNCTION WITH THAT NAME -- DspShow ("Rdio", "on") NO FUNCTION WITH THAT NAME end function AB_PDS_CPT_Radios_off () ipc.writeLvar("AB_PDS_RADIO_CPT_POWER", 0) -- AB_OVH_Pushbutton () NO FUNCTION WITH THAT NAME -- DspShow ("Rdio", "off") NO FUNCTION WITH THAT NAME end function AB_PDS_CPT_Radios_toggle () -- if _tl("AB_PDS_RADIO_CPT_POWER", 0) then WRONG FORMAT, NO FUNCTION WITH THAT NAME if ipc.readLvar("AB_PDS_RADIO_CPT_POWER") == 0 then AB_PDS_CPT_Radios_on () else AB_PDS_CPT_Radios_off () end end function AB_PDS_FO_Radios_on () ipc.writeLvar("AB_PDS_RADIO_FO_POWER", 1) -- AB_OVH_Pushbutton () NO FUNCTION WITH THAT NAME -- DspShow ("Rdio", "on") NO FUNCTION WITH THAT NAME end function AB_PDS_FO_Radios_off () ipc.writeLvar("AB_PDS_RADIO_FO_POWER", 0) -- AB_OVH_Pushbutton () NO FUNCTION WITH THAT NAME -- DspShow ("Rdio", "off") NO FUNCTION WITH THAT NAME end function AB_PDS_FO_Radios_toggle () -- if _tl("AB_PDS_RADIO_FO_POWER", 0) then WRONG FORMAT, NO FUNCTION WITH THAT NAME if ipc.readLvar("AB_PDS_RADIO_FO_POWER") == 0 then AB_PDS_FO_Radios_on () else AB_PDS_FO_Radios_off () end end event.flag(1, "AB_PDS_CPT_Radios_on") event.flag(2, "AB_PDS_CPT_Radios_off") event.flag(3, "AB_PDS_FO_Radios_on") event.flag(4, "AB_PDS_FO_Radios_off") When creating luas, this part of the "most excellent" logging tab of FSUIPC will tell you what's wrong, the line number, what it is doing etc.. Indispensable! (note, this screenshot is from an older version, but should be close)

@ram123, Sorry for the lateness, "next couple of days" turned into weeks.. Been extremely busy with all sorts of personal things. In any case you may find the autosave project here. Hope it works well for you, Roman

This lua script was done only as an interesting project in response to this thread, requiring that autosaves not occur during the most critical phase of flight in an advanced aircraft.. The landing. For FSUIPCv4.xx only. FSUIPCv5+ already has facilities to toggle off/on its own built in AutoSave. A lua script has also been made for FS9/FSUIPCv3.xxx, introducing auto save for this older sim where none was available beforehand in FSUIPC. If there is interest I may finalize the script with more substantial testing and then upload it. You may get it here. Roman

All that code looks like you are waiting for an L:Var change, if it does, write to 0x66C0 & C2 as signed words. The following code could (not tested) replace all that by using the on "event" listeners in the lua library. The function will not do anything until a L:Var change. When logging luas, use the left side option of the logging tab "Debug/Trace Lua". (something like that) Looking at your "all in one" code the only thing I found, and is probably the reason... "MRTTBoom" is not the same variable name as "MRTTBOOM" , CaPiTaLiZaTiOn counts.. 😉 Roman

Deleted

Hey Sven... ( you 'ol dog 😃 ) In lieu of spad next - Does the X-52 have a calibration control panel where you can test the led's? If so -and- the HIDFeature.lua doesn't pick up the led stuff being controlled from the control panel, maybe try Process Monitor and attach it (filter) to a Saitek .dll or something & see if that sniffs out the data needed. Just an idea, you're much more computer savvy than I. Hope all is well, staying healthy etc.. Roman

Luis, Not sure if this will cause it ( use lua logging ) but when using 2 parameters ( flag#, function name ) or just the necessary 1 parameter ( function name ), the flag number triggering event.flag gets passed to the function "Lights_TAXI_toggle". You have no variable name in the function for the value to get passed to. IE function-name(flag) Not really sure, but it could be the reason and may cause the lua to fail. Here's one other way: Use: LuaToggle <lua name> with parameters of 1 = taxi, 2 = landing, 3 = strobe, 4 = beacon Roman

It's been done for a while now using FSX boxed, using steam will make no difference as FSUIPC is the interface. Works great, been using it the last month, forgot it was even active in my sim! Just the difficult part remains - the readme / instructions. ( hate it ) It has an UI that can be used in flight along with some default settings that need to be initially set up. It is compatible with any of the following file formats - .a2a, .FLT, .FSSAVE, .SBP, .ipcbin, & .WX Does the Aerosoft 320 save any other of file type? I can set it up right from the start. In the next couple of days or so, Roman

Are you flying multiplayer -or- having any Carenado/Alabeo aircraft injected into the sim as AI in any way? If so.. It is NOT the plane you are flying in, but what is portrayed in the sim. Carenado/Alabeo aircraft have built in piracy protection and when these aircraft get injected into the sim as a non-user aircraft the anti piracy doesn't work correctly and as a result AXIS_MIXTURE_SET gets sent as a shared cockpit variable. Note - this does not affect FSX because the FSX panel system runs at a higher level than P3D when the aircraft is "non-user". LM reduced this panel priority for non user aircraft to increase overall sim performance. Just a hunch - it is totally proven though. Poor coding on their part. Roman

I don't think with FSUIPC there is a way. Unlike, for instance, keyboard software. Some keyboard software includes a timer between each keypress while FSUIPC polls the keys differently. "Shifts" IE Ctrl/Shift/Alt etc.. are added up. (see ~page 23, FSUIPC# for Advanced Users.pdf) Example (using lua) for both CTRL-SHIFT-X and SHIFT-CTRL-X 1) CTRL-SHIFT-X = ipc.keypress(90, 3) 2) SHIFT-CTRL-X = ipc.keypress(90, 3) The same thing.. Roman

Here's some notes from my MaddogX lua, also reported by Pete. Should be no problem if you are not using these programs - --[[ NO USES IN FSUIPC GENERAL USE (0x66C0 - 66FF) NO USES IN FSUIPC RESERVED 0x6700-0x67FF (JEAN-MICHAEL BISTON "MICHAEL" FOR AIRBUS GAUGES) INSIDE OF FSUIPC RESERVED 0x6800-0x6BFF (ROBERT FISCHER, FS-COMMUNICATOR) BYTES GO FORWARD FROM START, OTHERS COME BACKWARDS FROM THE END ]] Roman

Reinhard, I save the flight with the panels undocked, of course all of them show up on the main window on flt load.. One key press --> ( ext.position) and voila.. Right where they need to be and the correct size. Nice idea.. Roman

Ok, maybe I misunderstood your intentions then.. My fault. Missed the very first part where you wanted to "manually" enter the card direction. ( bangs head! 😒 ) This one just sets it to your current mag heading.. Egg on face. Roman PS - nice to see old adf navigation alive and well :)

Dane, You could run with this single line lua.. Tested ok. Copy the code below and save it as ADF_CARD_SYNC.lua Assign a key or button to "Lua ADF_CARD_SYNC" Done. Roman ipc.control(66039, ipc.readDBL(0x2B00))

Don't have GSX either but have read that, and also experienced in other modules, that the L:Var isn't created in the gauge system until ready to use for the first time. Wish I knew how they did that. )) In any case the lua may fail if dealing with strings, or keep running and return zero. You could try something like this: GSXNumPassengers = ipc.readLvar("FSDT_GSX_NUMPASSENGERS_BOARDING") if GSXNumPassengers = 0 or GSXNumPassengers = nil then ipc.display("Passenger loading hasn't started") else ipc.display(tostring(GSXNumPassengers) .. " passengers are boarding on this flight.") end Roman

This could be a perfect project in lua. It seems everything that is needed is provided in the FSUIPC offsets & in the lua library. Just will take some time, may look into it but not until the weekend is over. Ideas - - FSX only - The built in FSUIPC autosave must be turned off to use this - The lua will be listed in the FSUIPC.ini [auto] section. It will start / restart on sim load or aircraft change. - The ability turn off / on the autosave via keyboard or button (forced off = no automation at all, must be turned back on via keyboard or button). A status window will automatically show as described below. - The ability to bring up the current state and settings in the lua with the keyboard or button - In the lua file there will be 2 easily adjustable values: Time in minutes between saves, the number of saved flights - 3 states: Forced off, Automatic off & Armed - If retractable gear and gear is down = autosave is temp disabled (automatic return to active unless forced off) - If fixed gear and speed is less than 1.35 (or 1.4) * Design speed VS0 (stall speed full flaps), normally 1.3 * VS0 for VRef = autosave is temp disabled (automatic return to active unless forced off) Looking into it just a bit more, file handling might be a little bit of a chore.. Still doable. Roman

In the FSUIPC offsets the heading is probably, don't really know, "normalized" already. Once you bring in the MagVar into the equation* it could become non-normalized. *self.headingCorrected = self.instr['Heading'] - (self.instr['MagneticVariation'] * 65536) Another option is just to get the magnetic heading and not deal with MagVar for self.headingCorrected - self.headingCorrected = 0x2B00 (Gyro compass heading (magnetic), including any drift. 64-bit floating point.) Roman

In pseudo code, similar to the built in flight sim XML DNOR function. (degrees normalize) Don't know python (( If self.headingCorrected > 360 then self.headingCorrected = self.headingCorrected - 360 End If self.headingCorrected < 0 then self.headingCorrected = self.headingCorrected + 360 End Roman

My writing is terrible.. 👎 On click, for true heading - 0x0580 --> [ value & variable type conversion ] --> 0x07CC On click for magnetic heading - 0x2B00 --> [ value & variable type conversion ] --> 0x07CC It think that is what Ing. Nieto is getting at, setting the heading bug to the current heading. Roman

On the press of the button send either, depending on what you want: 1) 0x0580 4 dWORD Heading, *360/(65536*65536) for degrees TRUE. -OR- 2) 0x2B00 8 FLOAT64 Gyro compass heading (MAGNETIC), including any drift. 64-bit floating point. send to, after math & variable type conversions - 0x07CC 2, WORD - Autopilot heading value, as degrees*65536/360) ----------------------------------------------------------------------------------------------------- Al presionar el botón enviar, dependiendo de lo que desee: 1) 0x0580 4 dWORD Heading, * 360 / (65536 * 65536) para grados VERDADERO. -O- 2) 0x2B00 8 FLOAT64 Rumbo del compás giroscópico (MAGNÉTICO), incluida cualquier deriva. Punto flotante de 64 bits. enviar a, después de las conversiones de matemática y tipo variable - 0x07CC 2, WORD - Valor de rumbo del piloto automático, como grados * 65536/360)

Make bit 5 to 1 (SET) --> ipc.setbitsUB(0x5400, 32) Make bit 5 to 0 (CLEAR) --> ipc.clearbitsUB(0x5400, 32) Setting or clearing multiple bits, add them up.. Make bits 1,5 & 7 to 1 (SET) --> ipc.setbitsUB(0x5400, 162) < 2 + 32 + 128 > Make bits 1,5 & 7 to 0 (CLEAR) --> ipc.clearbitsUB(0x5400, 162) Roman

Just a hunch, Shouldn't this be - handle, error= ext.run("C:\\SIOC.exe", EXT_CLOSE) The second optional parameter is a string for command line options, after that one could have up to 4 more options, but they do not seem to be strings. You really shouldn't use EXT_KILL unless EXT_CLOSE doesn't work.. SIOC might not like a forced close, IE time to write saved settings and the like. Roman

For kicks just tested. It seems to work fine. I used - ipc.setbitsUB(0x5302, 1) ipc.setbitsUB(0x5302, 2) And the monitored, expected output was correct.. 3 The mask is the integer equivalent of the bit, not the zero based location of the bit.

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>