Lorby_SI

Is the button not picked up by AAO or are you asking about the correct assignments? Those assignments are different for almost every aircraft, and must be figured out individually. Ideally by using the MSFS developer mode, Tools->Behaviors. Then click back into the sim, hover the mouse over the VC control that you are interested in and press Ctrl+G. Now analyze the Interaction components that handle the mouse events - replicate the code as required in AAO. For the Learjet, MSFS IEs or their BVars should work fine. Just checked the HDG button, no problem there 1·(>B:AUTOPILOT_Heading_Mode_Toggle)

Apparently you have to replicate the entire behavior code, just setting LVars is not enough (L:AFCAS_SPD_KNOB_ROTATE,·enum)·++··100·min·(>L:AFCAS_SPD_KNOB_ROTATE,·enum)· (L:AFCAS_SPD_KNOB_ROTATE,·enum)·100·==·if{·0·(>L:AFCAS_SPD_KNOB_ROTATE,·enum)·} 1·(>L:AFCAS_SPD_KNOB_INC,·bool)(L:AFCAS_SPD_KNOB_ROTATE,·enum)·--·0·max·(>L:AFCAS_SPD_KNOB_ROTATE,·enum) (L:AFCAS_SPD_KNOB_ROTATE,·enum)·0·==·if{·100·(>L:AFCAS_SPD_KNOB_ROTATE,·enum)·} 1·(>L:AFCAS_SPD_KNOB_DEC,·bool)Replace SPD with HDG for the other knob. Larger increments are not possible IMO.

Is that really an LVar? How/where did you get this name from? In general, LVars are not really meant to be used for controlling things. Their original purpose is controlling animations and storing data. LVars are not events - on their own, they don't do anything. INC and DEC - that looks more like IEs/BVars to me. Check the event selection dialog in AAO, specifically the tab "MSFS IEs"

You cannot compare the two - completely different technology.

Why did you change the port? Has it been changed both in the plugin and in AAO? Did you restart the Elgato software after changing the port? The extra "Connection" action was no longer necessary. There is no situation where the SD plugin would have a partial connection. It either works or it doesn't - which should become apparent on the buttons straight away. I would recommend to use the Lorby Little Gauges profile to check.

In all honesty, if it doesn't work for you right away, just leave it be. That is exactly why there is a demo version. AAO uses Internet technology to talk to the plugin. On some computers the network security is so tight that troubleshooting this is not worth the effort, IMHO

Did you read the PDF that comes with the plugin? There are screenshots in it that show what the actions should look like. Most common mistakes are: With the ready made profiles, many people overlook that you usually have to import one or more script packages into AAO that come bundled with the download. Not supplying an "Event value". With every event box (Key Down, Key Up, etc.) there is a numerical input called "Event value". This cannot be left empty, you must enter a value. For simple events, 0 or 1 will do. Entering the event incorrectly. "(K:PARKING_BRAKES)" gets entered by selecting "K:" from the drop down, then entering "PARKING_BRAKES" into the textbox to the right Copy/pasting code from the AAO script editor into the Elgato software. In general, you cannot copy script directly from the white editor box - you have to C&P it from the grey box below it, that contains the compiled code. Forgetting to press the "Submit" button at the bottom of the action dialog in the Elgato software Running an outdated version of the AAO plugin Expecting all events to work for all aircraft - that is not the case. In you test scenario, make sure that when something works while assigned to a button, keep the same aircraft/livery when you test it with the StreamDeck. On a side note, when posting questions here, please make sure to always include the simulator and aircraft that you are trying to control. Especially in the MSFS world they are all different. Some react to the SDK events, others don't. And all of them have custom logic of some kind that must be assessed from scratch for each aircraft.

You must be doing something wrong. Please post a screenshot of this assignment, what it looks like in your StreamDeck app.

Check if the AAO Community package "lorbysi-content-hooks" is present and active in the other computer.

Hello @ll, a bug has been discovered in AAO 4.58 b02 concerning the "L:1:" variables in MSFS 2024 In some RPN scripts, the "L:1:" variables will not work, for example when using the VARSEQ command or iseq operator. These variables exist only in MSFS 2024. The current solution is to replace the "L:1:" header with "Z:". According to the MSFS 2024 SDK documentation, they are the same. This bug will be fixed in AAO 4.59, but that version is still a long way away (unless something dramatic happens). So for now I recommend just switching "L:1:" to "Z:"

No, the problem is in AAO itself, and it is definitely about the L:1: variables. Something has changed regarding the initial identification and parsing of those vars. Curiously enough they work properly in some situations, but not in others. Which makes it really difficult to find the problem. But if the Z: is indeed the workaround solution, I will publish a note to that effect.

OK, now I'm getting somewhere. I bought the MSFS 2024 version of the Kodiak (I didn't know that there was one). Now I am seeing the same behavior code, and I have the same problem with the script. The cause is not VARSEQ or ISEQ, something must have changed about the L:1 variables, potentially in the sim itself. To be investigated... Try using Z: instead of L:1: (according to the MSFS 2024 SDK documentation they are the same) (VARSEQ:2~1~0~1|Z:SWS_FUEL_Switch_Pump_1,·Number)

Back to 4.56? That way you could make sure that it is indeed the new version doing something different than before. I think that looking at VARSEQ etc. is the wrong way to go. The RPN ops haven't changed, and they are working fine for me. Something else must be happening. How and from where are you calling this script exactly? Did you test it in the RPN Editor? Did you observe the LVar's value itself? The script processing debug is only of limited use, it is much better to look at the actual variable. Where did you buy the SWS? Somehow our versions are different. I got mine on SimMarket, and the latest Download that I can get is called "Installer_SWS_Kodiak_Wheels_MSFS_20260207.exe". So it apparently mine is the MSFS 2020 version?

Which version of the aircraft is that and in what simulator? I am looking at my SWS Kodiak in MSFS2024 and the variable for the AUX FUEL PUMP switch is called (L:SWS_FUEL_Switch_Pump_1, Number). It is not instanced, "(L:1:" doesn't work for me ?? Edit: same story in MSFS 2020 with the latest SWS (I think). The variable is not indexed, and a script like "(VARSEQ:2~1~0~1|L:SWS_FUEL_Switch_Pump_1,·Number)" is working fine for me.

Not for me. I am testig your script right now, and the sequence is as expected. I doublechecked with (VARSEQ:2~1~0~1|L:test) and the (L:test) goes 0-1-2-1-0-1-2 etc. (using "Scripting->Watch simulator variables" to observe the value of the LVar) Please note that there has been an update to the Kodiak, and that according to other users, the SWS LVars and their functionality have changed. I wouldn't rule out the possibility that there is a discrepancy between writing to the var and reading from it. Also, the 4.57 is already obsolete. All shops should have the 4.58 by now.