spokes2112

Looking real good Rhys! 👍 Roman

John, Agree with you 100% It looks to me, from logs, that the command / param C68066 and the read offset 0x0298 work just fine. At one point the thread went on a small tangent (below) and I replied to that plus missed your suggestion in a reply. Sorry for wasting your time! Although, for knowledge sake, I wonder if updating the current aircraft speed to the autothrottle speed window cured it. Roman

Been reading this thread with interest even though I do not own MSFS. Just wondering, are you actually flying the aircraft when testing? Many advanced aircraft will act the same way, not broken, if going from managed to selected speed and not moving. Think about it, going to managed speed the autothrottle speed is taken care of... IE the FMC is injecting "a" speed for the autothrottle to follow whereas going to selected speed it does not. The autothrottle has no idea what speed you are flying at. This portion "might" be taken care of with internal logic embedded within the autothrottle button push code in the model ( something you might have to take care of yourself ). The 100 is coming up as a autothrottle lower limit "AND" as a warning to the pilot. It may work correctly if you are flying the plane.?.?.?. Here is the logic behind it, written in human terms. On press/pull of the auto throttle speed knob : If "speed slot" equals "selected" then // ((A:AUTOPILOT SPEED SLOT INDEX,Number) equals 1) Send FS control #68066 with a parameter of 2 // Managed is commanded, this part is done Else Send FS control #68066 with a parameter of 1 // Selected is commanded, more code might be necessary // Do the following code only if flying AND a "100" comes up on the speed window If INDICATED AIRSPEED (0x02BC) > 100 kts then INDICATED AIRSPEED (0x02BC) send to --> AUTOPILOT AIRSPEED HOLD VAR (0x07E2) Else a value of 100 send to --> AUTOPILOT AIRSPEED HOLD VAR (0x07E2) End End Just another set of eyes looking at it, hope it might help. Roman

Specially if the code snippet is copied directly from the lua library .pdf, then modified for your use. In a lot of cases ( not all ) the quote symbols used are of a MS Word type ( forward & reversed pairs ), not plain text type. That will trip up the lua. Just checked the v4 version of the lua library pdf, and sure enough - reverse paired quotes. OFC, attach the lua so it can be looked at. Roman

Bummer 😢 , was really hoping it would work for you... Oh Well. Good Luck, Roman

Chakko & Pete, I wonder if this would work, using a lua & offset 0x0D70.. It may be worth a test 😉 to see. The premise is that if the [Auto] section accepts an included folder within the name string than maybe, just maybe, 0x0D70 will too. A possible test lua to kill all the 747 luas is below, OFC not tested. Use the command window logging. Could've, but didn't, add a display to inform you what's going on. If this works you could then run a single lua under [Auto] and within that lua are the commands to start your specialized luas. OFC if this works you could also make a fully automated setup for each of your specialized folders using ipc.ask to select the specialty folder to use. It could become very easy to start/stop specialized luas that are within a folder group. Fingers crossed for you, Roman -- Kill [Auto] #1 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3inputsL") ipc.sleep(150) -- Kill [Auto] #2 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3inputsR") ipc.sleep(150) -- Kill [Auto] #3 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3outputs1") ipc.sleep(150) -- Kill [Auto] #4 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3outputs2") ipc.sleep(150) -- Kill [Auto] #5 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Overhead") ipc.sleep(150) -- Kill [Auto] #6 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Captain") ipc.sleep(150) -- Kill [Auto] #7 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Copilot") ipc.sleep(150) -- Kill [Auto] #8 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Centre") ipc.sleep(150) -- Kill [Auto] #9 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Quadrant") ipc.sleep(150) -- Kill [Auto] #10 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3RearPedstl") ipc.sleep(150) -- Kill [Auto] #11 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3_RN1") ipc.sleep(150) -- Kill [Auto] #12 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3_RN2") ipc.sleep(150) -- Kill [Auto] #13 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3RNinputs") ipc.sleep(150) -- Kill [Auto] #14 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3lights") ipc.sleep(150) -- Kill [Auto] #15 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Panels") ipc.sleep(150) -- Kill [Auto] #16 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3MotorQuad1") ipc.sleep(150) -- Kill [Auto] #17 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3MotorQuad2") ipc.sleep(150) -- Kill [Auto] #18 ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3ATstate") ipc.sleep(150) --[[ THE [AUTO] ENTRIES JUST FOR MY REFERENCE 1=Lua LuaB747v3\\b747v3inputsL 2=Lua LuaB747v3\\b747v3inputsR 3=Lua LuaB747v3\\B747v3outputs1 4=Lua LuaB747v3\\B747v3outputs2 5=Lua LuaB747v3\\B747v3Overhead 6=Lua LuaB747v3\\B747v3Captain 7=Lua LuaB747v3\\B747v3Copilot 8=Lua LuaB747v3\\B747v3Centre 9=Lua LuaB747v3\\B747v3Quadrant 10=Lua LuaB747v3\\B747v3RearPedstl 11=Lua LuaB747v3\\B747v3_RN1 12=Lua LuaB747v3\\B747v3_RN2 13=Lua LuaB747v3\\B747v3_RNinputs 14=Lua LuaB747v3\\B747v3lights 15=Lua LuaB747v3\\B747v3Panels 16=Lua LuaB747v3\\B747v3MotorQuad1 17=Lua LuaB747v3\\B747v3MotorQuad2 18=Lua LuaB747v3\\B747v3ATstate ]]--

According to the spreadsheet provided in the documents provided 0x0230 (Absolute Time) responds but in another column it states "Not Working". 0x0274 (frame rate) has no notes in the sheet whatsoever so it probably doesn't work. You may want to try the Local and/or Zulu time entries, Zulu minutes is noted as working, you could use that but ofc your resolution will be 1 minute 😞, maybe others work, although "Local" seems buggy from the notes provided. In the end though, an offset providing the connect info or a response to FSUIPC.Process() (its equivalent for FSUIPC7) would be optimal. Roman

It isn't just Carenado, many other reputable designers have the same thing - constant control firing. 2 reasons why this may happen : 1) Unavoidable, the logic behind the system requires constant updating, an example. Many years ago I programmed a terrain following radar tied to the AP. In order for it to work correctly I needed to send vertical speed & altitude commands to the AP as fast as possible. 2) Poor programming. Many many times this is the cause. In the case of the Phenom, I can see the MIXTURE#_RICH being used. Yes in jets it can be (and is) used, in the core of the sim it is basically the same as fuel valves. The firing of AP_PANEL_SPEED_OFF, whoah! That really looks like bad programming, in this case it should be something like : (A:AUTOPILOT AIRSPEED HOLD, bool) 0 != if{ (>K:AP_PANEL_SPEED_OFF) } Basically, if the AP speed should be off, and it isn't, well then, turn it off! In the case above it just isn't checking if already off. When it comes to constant firing it really isn't that bad (wasting resources) as long as it doesn't constant fire dozens (>36) of different commands. There is 1 command, the exits, (shift-E + #) that will always be affected by constant firing. When the exits command is used (other than #1) it will not work because the second part of the command, the number, is interrupted by the background constant firing of commands. A good sign that the aircraft programming is guilty of constant firing without actually checking for it. I see John has replied also. DontLogThese, that is one .ini entry that I just cannot live without, specially when it comes time for logging, be it lua programming or button/key/hardware checking. If interested, you could look here, I provided proof of constant firing for other reputable designers. (A2A, PMDG, Leonardo, Iris) Roman

John, Unlike the FSUIPC built in macro maker for C+ type gauges, macros for L:Vars have to be handmade. (~pg 43 FSUIPC4 for Advanced Users.pdf, "Macros to change Lvars") : The macro facility to operate Lvars can only be used by editing macro files and building them manually. The format is: N=L:name=ACTION Note, not a big worry as the .mcro files are no more than text files with a .mcro extension. Use Notepad or some other plain text editor to view/edit them. BTW, I attached a bunch of zipped up .mcro files as examples you can look at. They will serve no other purpose for you. The difficult part is finding the correct L:Var variable name, once you have that, the .mcro making part is easy. As Pete mentioned here - "To find LVars you can use the supplied Lua plug-in to log Lvars. Run that plug-in my assigning it to a keypress, then operate the button and see if an LVar value changes." There are other ways such as using a hex editor to inspect the interior model (.mdl) file and such but that is way beyond the scope here. That's about it, hard = finding the L:Var name, easy = making the .mcro file itself. Strange that the macro doesn't work on the keyboard, it should.. As for the modules folder location, yes, sorry about that, just used to it being "old style", contained within the simulator folder structure. Glad you got it working! Roman macro examples.zip

John, We are controlling only 1 L:Var here, therefore using Lua would be overkill.. Yes, Lua could be used, specially if controlling more than 1 L:Var and/or incorporating some kind of logic behind it. In this case there is no logic, it is either pressed or not pressed. In this example we are just using a .mcro file to inject a custom control to be used by FSUIPC. 1) Flight Sim closed. 2) Unzip the attached "P40_Hyd.zip" and place the "P40_Hyd.mcro" file into the <flight sim>\modules folder 3) Start FS and assign your joystick button as shown in the image below. Note - to use a keyboard key would be very similar, just use the "Key Presses" tab instead. 4) Done Good luck, Roman P40_Hyd.zip

John, This has been tested in FSX using the "C" model P-40, A2A Wings of Power III. Constructing a L:Var macro with the variable name - L:HydraulicPumpControl will control the control stick button. Assigning the macro on button press with a parameter of 1 will be a button push, 0 will be a button release. Ex. #=L:HydraulicPumpControl=Set You could get a slightly different action by assigning the macro with the action - TOGGLE (press once for ON, press again for OFF) ~pg 43 FSUIPC4 for Advanced Users.pdf Roman

Hi guys, The script I wrote for FSUIPC v3.x/4.x was done so some prerequisites could be used to turn on/off the auto save. Because the auto save in these versions of is basically a fixed function in FSUIPC I had to write a full save routine - requisites, save files, file name format, increment files etc.. The stock FSUIPC (v3/4) autosave works brilliantly already, it is just the problem that it is either on or off, switched within the UI of FSUIPC. FSUIPC v5+ now has a control (C1151) to toggle on or off the built in excellent, extensive autosave. All that is needed is a little lua to tell when to turn it off for performance explicit operations. ex.. If gear handle is down then disable auto save, else keep autosave on. My full lua would be overkill in this situation, even if it did work. Roman

A calculated guess here, but I do believe FSUIPC can automatically do that for you as long as the following is true in your FSUIPC7.ini ( default) : [JoyNames] AutoAssignLetters=Yes As stated in the v7 Lua Library for event.button : “joynum” is a joystick number, the same as shown in FSUIPC’s Button assignments tab. If you use joystick lettering, you can put the letter here instead but it must be "" quotes, as a string. Note, however, that the function is called with the translated number as its first parameter. With that you could change just 1 line in TripleUse.lua - joy = 1 -- around line 21 - change to - joy = "A" If you really need the number for your specialized coding, maybe you could use an "initialization" lua (or placed in your current code) to put the joy number into a user offset or variable within your lua. It does however, require that you press the assigned initialization button at least once to populate the offset/variable before using your own specialized triple use. jn = nil function getJoyNum(joynum, button, downup) ipc.writeUB(0x66C0, joynum) jn = joynum end event.button("A", 0, 1, "getJoyNum") -- button 0 on alpha (assigned "A") is the trigger 0x66C0 or the variable "jn" will now hold your actual joy number for any of your uses. Just an idea... Roman

John, Was working on a reply the same time as you were. Wouldn't the value of v be 4 if on? OFC "true" boolean is 0 or not zero, so it would work if checking for 0. v=logic.And(n, 0x4) if v == 4 then -- landing lights are on end - or - v=logic.And(n, 0x4) if v ~= 0 then -- landing lights are on end _____________________________________________________________________________________________________________ Here's another way to look at it.. Refer to this chart: Here is an example if you were to use a loop to check, not recommended at all... An example just to show how you can manipulate the checking of bits. a = ipc.readUW(0x0D0C) -- Landing Light is ON if logic.And(a, 4) == 4 then -- Do something end -- Landing Light is OFF if logic.And(a, 4) == 0 then -- Do something end -- BOTH Strobes & Logo lights are ON ( add up bit values ) if logic.And(a, 272) == 272 then -- Do something end -- BOTH Strobes & Logo lights are OFF ( add up bit values ) if logic.And(a, 272) == 0 then -- Do something end Another example, using a recommended event listener to call a function only if the bit value that is masked has changed. This is so much more efficient. BeaconDetect(offset, value) if value == 2 then -- the bit value -- turn ON led code here else -- turn OFF led code here end end StrobesDetect(offset, value) if value == 16 then -- the bit value -- turn ON led code here else -- turn OFF led code here end end LandingOrTaxiDetect(offset, value) -- this detects the landing OR taxi lights being ON (1 led) if value == 4 or value == 8 then -- turn ON led code here else -- turn OFF led code here end end event.offsetmask(0x0D0C, 2, "UW", "BeaconDetect") -- detect if bit #1 (value = 2) changes event.offsetmask(0x0D0C, 16, "UW", "StrobesDetect") -- detect if bit #4 (value = 16) changes event.offsetmask(0x0D0C, 12, "UW", "LandingOrTaxiDetect") -- detect if bit #2 (value = 4) -or- bit #3 (value = 8) changes Roman

@Eliagh, as mentioned here you can use only 1 L:Var in a .MCRO file. Using buttons, in this case, 1 button, you can cycle through the ranges and repeat : 1 = L:B747_8_MFD_Range = Cyclic,11 This will give 0,1,2,3,4,5,6,7,8,9,10,11,0,1,2 .... On each button press. See FSUIPC# for Advanced Users.pdf, "Macros to change Lvars" section. For an increment/decrement you would have to use lua. Something like this, NOT TESTED : Use [AUTO] in .ini to start the lua then assign buttons or encoder as such - Decrease = LuaToggle <lua_name> with a parameter of 1 Increase = Lua Toggle <lua_name> with a parameter of 2 Function mfd_adjust(flag) a = ipc.readLvar("L:B747_8_MFD_Range") if flag == 1 then a = a - 1 if a < 0 then a = 11 end else a = a + 1 end a = a % 12 ipc.writeLvar("L:B747_8_MFD_Range", a) end event.flag(1, "mfd_adjust") event.flag(2, "mfd_adjust") Roman