Lorby_SI

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.

To explain this a bit. The biggest problem with the behavior code is this part: (L:SW_SOV_PANELS_Door_Baggage) ! (>L:SW_SOV_PANELS_Door_Baggage) (L:SW_SOV_PANELS_Door_Baggage) (>L:SW_SOV_PANELS_Latch_Baggage_1_1) (L:SW_SOV_PANELS_Door_Baggage) (>L:SW_SOV_PANELS_Latch_Baggage_2_1) (L:SW_SOV_PANELS_Door_Baggage) (>L:SW_SOV_PANELS_Latch_Baggage_3_1) (L:SW_SOV_PANELS_Door_Baggage) (>L:SW_SOV_PANELS_Latch_Baggage_4_1) (L:SW_SOV_PANELS_Door_Baggage) (>L:SW_SOV_PANELS_Handle_Baggage) For one, none of the LVars has a unit - which means that AAO will treat them as internal vars, and never send them to the sim. The solution is to add at least the default ", Number" Second, the AAO RPN parser works a little differently than the sim. In the first line, the SW_SOV_PANELS_Door_Baggage is changed. In the subsequent lines, this new value is written to a bunch of other LVars. The AAO parser doesn't work like that, it will replace all occurences of SW_SOV_PANELS_Door_Baggage with its current value before executing the script. As a result, all the LVars will receive the OLD value of SW_SOV_PANELS_Door_Baggage, not the new one. One solution I have outlined above, and that is using registers, which are updated at runtime. Another solution would be to apply the "!" operation to all assignments of the SW_SOV_PANELS_Door_Baggage: (L:SW_SOV_PANELS_Door_Baggage, Number) ! (>L:SW_SOV_PANELS_Door_Baggage, Number) (L:SW_SOV_PANELS_Door_Baggage, Number) ! (>L:SW_SOV_PANELS_Latch_Baggage_1_1, Number) (L:SW_SOV_PANELS_Door_Baggage, Number) ! (>L:SW_SOV_PANELS_Latch_Baggage_2_1, Number) (L:SW_SOV_PANELS_Door_Baggage, Number) ! (>L:SW_SOV_PANELS_Latch_Baggage_3_1, Number) (L:SW_SOV_PANELS_Door_Baggage, Number) ! (>L:SW_SOV_PANELS_Latch_Baggage_4_1, Number) (L:SW_SOV_PANELS_Door_Baggage, Number) ! (>L:SW_SOV_PANELS_Handle_Baggage, Number) I know, this doesn't really make sense. It is one of those things that you just have to know about AAO. It has been implemented this way at the beginning. Over the years everybody worked around it in code. Now it is too late to change it, because that change would probably invalidate a large amount of existing scripts.

There is another problem that AAO will have with the behavior script. AAOs RPN parser does not propagate variable changes inside the same script. I've altered the code it so it uses a register instead: (A:SIM·ON·GROUND,·Bool)·1·==·if{· ·(L:SW_SOV_CONFIG_Simple_Openings,·Number)·0·==·if{· ··(L:SW_SOV_PANELS_Latch_Baggage_1_1,·Number)· ··(L:SW_SOV_PANELS_Latch_Baggage_2_1,·Number)· ··(L:SW_SOV_PANELS_Latch_Baggage_3_1,·Number)· ··(L:SW_SOV_PANELS_Latch_Baggage_4_1,·Number)· ··(L:SW_SOV_PANELS_Handle_Baggage,·Number)· ··and·and·and·and·if{· ···(L:SW_SOV_PANELS_Door_Baggage,·Number)·!·(>L:SW_SOV_PANELS_Door_Baggage,·Number)· ··}· ·}· ·els{· ··(L:SW_SOV_PANELS_Door_Baggage,·Number)·!·s0· ··l0·(>L:SW_SOV_PANELS_Door_Baggage,·Number)· ··l0·(>L:SW_SOV_PANELS_Latch_Baggage_1_1,·Number)· ··l0·(>L:SW_SOV_PANELS_Latch_Baggage_2_1,·Number)· ··l0·(>L:SW_SOV_PANELS_Latch_Baggage_3_1,·Number)· ··l0·(>L:SW_SOV_PANELS_Latch_Baggage_4_1,·Number)· ··l0·(>L:SW_SOV_PANELS_Handle_Baggage,·Number)· ·}· }·

The boolean "and" only checks if both vars are true/1. It does not check if they are the same, that would be the "==" '1 1 and' => true/1 '0 0 and' => false/0 '1 0 and' => false/0 '0 1 and' => false/0 ******** '1 1 ==' => true/1 '0 0 ==' => true/1 '1 0 ==' => false/0 '0 1 ==' => false/0

Correct. Behavior code must always be adapted for AAOs RPN dialect. Most importantly, all LVars must have a unit (like ,Number). Otherwise AAO will treat them as internal, and will not sync them with the simulator.

On a side note, LVars are always numbers. TMBK, giving them a different unit, like "Bool", has no effect. You can just as well stick with "Number". Just make sure that the value range of the LVar is actually "0 or 1". In most cases, LVars have much larger value ranges, like 0 to 30 or 0 to 100. They are often used to control animations, and their value represents the "frame" that the animation is currently at. Another note: For AAO "0" always means "false". But many operators tolerate "true" as being "not 0".

From my perspective, the two yellow scripts in your post do the exact opposite from each other. They cannot produce the same results. This script returns true when both LVars are true (= have a value of 1.0, Lvars are always Numbers) "1 1 and" results in a value of 1.0 (true) And this script is the exact opposite. You query explicitly if both LVars are false (= have a value of 0.0)

I'm sorry, but I don't understand your question. From my perspective all your scripts are incomplete or syntactially incorrect, and none of them can "work". What are you trying to achieve with them? The big question for me would be, what the actual value range of those LVars is. As far as I know, LVars are not converted internally, so they are always numbers. Supplying the unit "Bool" does not change that. So if those LVars are animation variables (which is their usual purpose), they can have any value between 0 and 30 or 0 and 100 - or whatever. There is no guarantee that their value is always 0 and 1, like a true boolean would be.

The script group name has a "-" in it, right? Check out this post https://www.avsim.com/forums/topic/697373-bug-notice-about-aao-457-solved-with-458/

Please note that the version number of the app hasn't changed in the manual. The documents still say 4.57 (but there is no difference anyway)

Hello @ll, AAO version 4.58 b02 has been uploaded to the shops. Please give them a couple of hours until they deploy them. The only change is that AAO 4.58 will tolerate (invalid) script groups with a "-" in their name again. I cannot promise that they will work everywhere though, and they will run a tiny bit slower that properly named scripts (yes, this restriction has been in the AAO manual since forever - AAO relies on the "-" to split group and script names when a script is called as (>K:group-title)

Version 4.58 is out now. Invalid script groups will be tolerated again - to a certain extent. I cannot guarantee that they will work everywhere, and they are running a tiny bit slower than scripts with correct group names. But you can no longer create groups with a "-" in their name, so that problem should subside over time. I still recommend that all authors update their script group names if they have a "-" in them at the moment.