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

No worries Roger, what I was asking for is a stock cameras.cfg file.. I have 1 highly modified one, and 5 backups. None of my backups were of the bone stock one. 😒 Alas, after reading thru the SDK it was found that FSX keeps a stock, unmodified one in the FSX root folder.. Now I have 2 stock ones just in case. With that, I can be 100% certain of the hot keys used by the master cameras.cfg file. 1 thru 4.. That leaves 0 & 5 thru 9 available for your own use. No, already done & tested - thanks. I like it as it gives a full view of all the avionics close up ( GPS specially ) so my weary eyes can see it better. Plus it shows, as a bonus, the Nav 2 OBI & the ADF Indicator, a nice extra specially if the yoke is visible. Glad it is working out for you 👍 Roman

Good news Roger ! I believe you could do it.. Although, just to make sure, go to C:\Users\<USER>\AppData\Roaming\Microsoft\FSX\Cameras.cfg and check that file for all the HotKeySelect= entries. If 7 is not used in any of them then it is free to use with no side effects. May I ask a favor? I noticed my backup Cameras.cfg files are not good backups.. I don't have a stock backup. In lieu of attaching yours here (path above) I did a little work & setup a view that shows the garmin, nav/com 2 & the adf, all without seeing the quadrant levers.. ( kind of tough ) This replaces the mostly useless 2nd Row Passenger camera. [CameraDefinition.007] Title = "Garmin, NAV/COM 2, ADF" // "2nd Row Passenger" Guid = {0456199A-99D4-11DC-B263-66CC55D89593} Origin = Virtual Cockpit MomentumEffect = Yes // You could optionally change this to No SnapPbhAdjust = Swivel SnapPbhReturn = False PanPbhAdjust = Swivel PanPbhReturn = False Track = None ShowAxis = YES AllowZoom = TRUE InitialZoom = 0.30 // 0.40 SmoothZoomTime = 2.0 ZoomPanScalar = 0.4 ShowWeather = Yes XyzAdjust = TRUE ShowLensFlare=FALSE Category = Cockpit PitchPanRate=20 HeadingPanRate=60 InitialXyz=0.3, -0.275, 0.555 // 0.6, 0.1, -0.65 InitialPbh=0, 0, 0 // 2, 0, 345 HotKeySelect=7 Roman

Roger, An edit after another test.. When the button is released, using VIEW CAMERA SELECT 1 "should" return you to the original direction, position, zoom etc.. in the VC "Should" = I cannot be 100% positive with this view select number, my master camera.cfg file is highly modified, checked my backup and it was 1 also. If it doesn't work try VIEW CAMERA SELECT 0, VIEW CAMERA SELECT 2, VIEW CAMERA SELECT 3 etc.. One of the numbers will get you back. Roman

Hello Roger, Noticed you posted this on Avsim too, hopefully this will help. Alabeo provided camera definitions for the fuel selector panel in the aircraft.cfg :) This will make it easy. 1) First you need to provide a "hot key" entry & number to your aircraft.cfg camera definition for the view "Fuel Selector". I have modified mine as such. Make a backup of the cfg if wanted. Warning! Do not go "willy nilly" on the hot key numbers. Numbers 0-4 (i believe) are reserved in the master camera.cfg file. I used 9, the max, as the value just in case you use some other kind of camera software IE ez-dok. ( don't know, dont own ) [CameraDefinition.003] Title = "Fuel Selector" Guid = {195EAB58-9E4A-2E2A-A34C-A8D9D948F079} Origin = Virtual Cockpit MomentumEffect = No SnapPbhAdjust = None SnapPbhReturn = False PanPbhAdjust = None PanPbhReturn = False Track = None ShowAxis = FALSE AllowZoom = TRUE InitialZoom = 1.00 //0.45 I optionally put in 1.0 for ease of reading the fuel selector panel, originally 0.45 SmoothZoomTime = 2.0 ZoomPanScalar = 0.75 ShowWeather = Yes XyzAdjust = TRUE ShowLensFlare=FALSE Category = Cockpit PitchPanRate=20 HeadingPanRate=60 InitialXyz=0.25, -0.1, 0.1 InitialPbh=80, 0, 0 HotKeySelect=9 // This is the new entry 2) In FSUIPC assign your rocker as such: "Control sent when button pressed" = VIEW CAMERA SELECT 9, parameter 0 or leave blank "Control to repeat while held" = unchecked "Control sent when button released" = VIEW VIRTUAL COCKPIT FORWARD, parameter 0 or leave blank It works great except... On release of the button it goes back to default VC view, not where you may have been before with zoom, position etc.. ( not really a big deal ) Hope this helps, Roman

Completely agree with you John, in fact I can almost bet 100% that the Logitech installer is using text string based logic rather than using the XML DOM & imports to their program such as system.xml to do the work. ( the tab spacing seems to give it away ) An idea for "gracefulness" when improper <Launch.Addon> additions are made by a program that is not doing it properly IE using text strings to figure it out. Use line breaks in key locations.. This should help when a text string based program is trying to add to what you already have. XML doesn't care about whitespaces whereas text string based logic does. Old : <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"><Descr>Launch</Descr><Filename>EXE.xml</Filename><Disabled>False</Disabled><Launch.ManualLoad>False</Launch.ManualLoad><Launch.Addon><Disabled>False</Disabled><ManualLoad>False</ManualLoad><Name>FSUIPC7</Name><Path>C:\FSUIPC7\FSUIPC7.exe</Path><CommandLine>-auto</CommandLine><NewConsole>False</NewConsole></Launch.Addon></SimBase.Document> New: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"><Descr>Launch</Descr><Filename>EXE.xml</Filename><Disabled>False</Disabled><Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Disabled>False</Disabled><ManualLoad>False</ManualLoad><Name>FSUIPC7</Name><Path>C:\FSUIPC7\FSUIPC7.exe</Path><CommandLine>-auto</CommandLine><NewConsole>False</NewConsole> </Launch.Addon> </SimBase.Document> Just an idea....

One of the the 2 installers/dameon is providing its own closing </SimBase.Document> closing tag which is part of the "root" document - not good. The file will not parse, therefore not load due to the error. Mistake shown shaded below. This should work by either removing the highlighted selection above from your own file or, Copy the complete code below and replace all the code in your file with this, save it. <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>EXE.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>FSUIPC7</Name> <Path>C:\FSUIPC7\FSUIPC7.exe</Path> <CommandLine>-auto</CommandLine> <NewConsole>False</NewConsole> </Launch.Addon> <Launch.Addon> <Name>Logitech Microsoft Flight Simulator Plugin Steam</Name> <Disabled>False</Disabled> <Path>C:\Program Files\Logitech\Microsoft Flight Simulator Plugin\LogiMicrosoftFlightSimulator.exe</Path> <CommandLine>-r</CommandLine> </Launch.Addon> </SimBase.Document>

Gustavo, Most, if not all the switches/buttons you are referring to have logic built in to the VC click spots, mainly timers. Much like interfacing the AP, there is no real way to do this via L:Var macros & lua is out of the question too. Just returned home after some time away and continuing on your AP interface ( some FMC too 😉 ). If you take some screenshots highlighted with all the buttons & switches you need , I can add those too. (send via our PM thread) Roman P.S. Here's an example of the APU code needed just to make it work - (M:Event) 'LeftSingle' scmi 0 == (M:Event) 'WheelUp' scmp 0 == or if{ (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 2 &lt; if{ 1 (>L:ClickSoundCar,number) } (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) ++ 2 min (>L:ASD_SWITCH_APU_MASTERSTART_DIR,number) (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 2 == if{ (P:local time,seconds) 05 + (>L:ASD_SWITCH_APU_MASTERSTART_TIMER) } } (M:Event) 'RightSingle' scmi 0 == (M:Event) 'WheelDown' scmp 0 == or if{ (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 0 > if{ 1 (>L:ClickSoundCar,number) } (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) -- 0 max (>L:ASD_SWITCH_APU_MASTERSTART_DIR,number) } (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 2 == if{ 1 (>L:APU_START,number) 1 (>L:APU_GENERATOR_SWITCH,number) 0 (>L:APU_STOP,number) } (L:ASD_SWITCH_APU_MASTERSTART_DIR,number) 0 == if{ 0 (>L:APU_START,number) 0 (>L:APU_GENERATOR_SWITCH,number) 1 (>L:APU_STOP,number) } }

Definitely a non-standard way of using the sim. When this happens, did you try going to the FSUIPC dialog --> Axis Assignment Tab --> Click the "Reload all assignments" button? That should fix it for you without restarting the sim. 1 extra step for your non-standard SOP. Roman

I like doing these things. Still workin on it, hope to get all the AP done today. May even include the DCP(?) and the CCP(?), while not as complicated AP there are some slightly funky things going in the code. Roman

Have it going & it works, just to give an idea of the background logic here's just the press of the VS button. There's also the release. The AP master and VNAV are even more complicated! <!-- VS Press, Param = 5 --> (L:XP850_HW_IF, number) 5 == if{ 1 (>L:BUFFER_BTN_FMC,number) 0 (>C:carenado:AutoPilotAltitudeEnabled) (A:AUTOPILOT MASTER,BOOL) 0 != (C:carenado:AutoPilotAltitudeEnabled) 0 == and if{ 1 (>L:ASD_BTN_850XP_VS,number) (A:Autopilot Nav1 Lock,bool) (>L:NAV,bool) (A:Autopilot Heading Lock,bool) (>L:HDG,bool) (L:AUTOPILOT MASTER, BOOL) 1 == (L:ALT_VS_SEL_ON) 0 == and if{ 0 (>L:CUSTOM_AUTOPILOT_AIRSPEED_HOLD, number) (>K:AP_ATT_HOLD_ON) (>K:AP_PANEL_ALTITUDE_ON) 0 (>K:AP_ALT_VAR_SET_ENGLISH) (A:AUTOPILOT VERTICAL HOLD VAR, feet per minute) (>K:AP_VS_VAR_SET_ENGLISH) (A:AUTOPILOT VERTICAL HOLD VAR, feet per minute) (>L:AP_VS_VAR_SET_ENGLISH) 1 (>L:ALT_VS_SEL_ON) 1 (>L:ALT_SEL_ON) 0 (>L:CUSTOM_AUTOPILOT_AIRSPEED_HOLD_ALT, number) 0 (>L:ALT_ARM_SEL_ON,number) 1 (>L:GAUGE_ALT_ALERT_MODE, number) (A:VERTICAL SPEED,ft/min) 100 / near 100 * (>K:AP_VS_VAR_SET_ENGLISH) (A:VERTICAL SPEED,ft/min) 100 / near 100 * (>L:AP_VS_VAR_SET_ENGLISH) } els{ 0 (>L:ALT_VS_SEL_ON) (>K:AP_ALT_HOLD_OFF) (>K:AP_ATT_HOLD_OFF) 0 (>L:ALT_ARM_SEL_ON,number) 0 (>L:ALT_SEL_ON) } (L:NAV,bool) 0 != if{ 0 (>K:AP_NAV1_HOLD_ON) } (L:HDG,bool) 0 != if{ 0 (>K:AP_HDG_HOLD_ON) } } 0 (>L:XP850_HW_IF, number) quit }