Lorby_SI

A note for MSFS 2024 users: since SU5 there is the option to access O: and I: variables. Unfortunately this isn't bullet proof yet - I still have an open and confirmed bug ticket in the MSFS developer forum, because sometimes the process refuses to work. Here is an example that does work for the default C208, it pushes the GENERATOR switch up (reset) and holds it there 0·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:SwitchState,·Number)·1·(>B:ELECTRICAL_Alternator_1_Reset,·Number)· (E:SIMULATION·TIME,·seconds)·0.5·+·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_SwitchStateTimer,·Number)· (E:SIMULATION·TIME,·seconds)·0.5·+·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_Repeat_StartTime,·Number)· 1·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_MomentarySwitch_IsHeld,·Number)· This pushes the switch down (trip) and holds it there: 2·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:SwitchState,·Number)·1·(>B:ELECTRICAL_Alternator_1_Trip,·Number)· (E:SIMULATION·TIME,·seconds)·0.5·+·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_SwitchStateTimer,·Number)· (E:SIMULATION·TIME,·seconds)·0.5·+·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_Repeat_StartTime,·Number)· 1·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_MomentarySwitch_IsHeld,·Number)·This releases the switch: 0·(>O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:XMLVAR_MomentarySwitch_IsHeld,·Number)·And this will read the current position of the switch: (O:ELECTRICAL:ELECTRICAL_SWITCH_ALTERNATOR_1:SwitchState, Number) (... these scripts can probably simplyfied - I've just replicated the behavior code here...) Specs for reference in the MSFS 2024 SDK manual: SimConnect_AddToDataDefinition (at the bottom of the page there is a list of all variable types and how to assemble their names)

Hello @ll, AAO Version 4.57 build 21 has been uploaded to the shops today. Please give them a few hours to deploy the app. Should there be Defender/SmartScreen trouble with the files, please let us know. There is a way to get them cleared, at least by Microsoft security. Changes in AxisAndOhs version 4.57 General changes: - Change: Buttons: added "Double Click" Option - Change: Buttons: prevent keyboard from overriding joystick assignments - Change: Added Script Indexing mechanism to improve lookup times - Change: Added option to choose the AAO user files folder - Change: Added option to blacklist all DirectInput devices on the Device Blacklist dialog - Change: RPN: added winfocus and procfocus operators Simulator specific: - Change: MSFS 2024: updated to SU5 SDK - Change: XPlane: added access to XP WebAPI Bugfixes: - Bugfix: vJoy axis didn't have a center - Bugfix: Variable Selection dialog didn't handle IEs and BVars correctly - Bugfix: max/min value of event axis flight controls always forced to 16383 - Bugfix: RPN: Gauges/Scriptfiles "Compile" method skipping space characters after empty string literals. - Bugfix: RPN: WAIT: String LVars not processed correctly when using WAIT between assignments inside the same script.

Maybe your firewall is intefering? Letting the data pass one way only? To be on the safe side, you should create firewall rules that allow all traffice through the TCP port that you have configured for the WebAPI - in both directions, incoming and outgoing. Creating a rule for the AAO app itself is the wrong way to go, that won't work. Sorry, my bad, but this was B.S. When you are seeing data on the StreamDeck, then the WebAPI and the connection are both fully functional. The SD plugin is sending requests to AAO and gets the data in the response. So the API is working both ways. You are certain that the buttons on your SD are working? No others plugins that could interfere? The easiest way to check would be using an empty profile and creating a single AAO "Button" Action on it. This should be picked up in AAO when you open the "Add Button" dialog (same as with a joystick or button box, but it would show "WebAPI" as the source).

Sounds strange, never heard of that before, sorry. The only situation where this does happen is when the profiles call scripts and the user forgot to import the script package(s) into AAO...

That assumption is wrong. The checkmark does not indicate that something is "active". It is just local to this dialog, the checkboxes are there for selecting the addons that you want to change the web address/port for with the buttons below the list. It is disabled when you run the StreamDeck software, because in this state, AAO cannot change the Web Address in the plugin's config file (=the buttons wouldn't do anything) Please explain a bit more what you mean by that. What does "writing back" mean, what do you expect to happen when you do what exactly? When the WebAPI works one way, it works the other way too - this is one single mechanism.

I would still use my autoscript. Since the battery LVar apparently has 10 as the "ON" value, the script would look like this: (L:VC_Battery_SW_VAL, Number) (L:MyBatRef) != if{ (L:VC_Battery_SW_VAL, Number) 10 == if{ (EXECBAT:C:\myfile.bat) } (L:VC_Battery_SW_VAL, Number) (>L:MyBatRef) }This script will always start the batch file every time the Battery switch goes from OFF to ON. It will also start the batch file when you connect AAO after you've already switched to "ON", because that is the state that it is looking for. Initially, both LVars are 0, so the script won't fire. When you click the battery switch ON, the LVar changes to 10 and the if is executed. And since you only want to start the batch when the battery is turned on, the script checks for the value "10". There are probably a dozen other ways to script this, and there are alternatives too. You could create a CONVERSATION type script file and start this when you start your flight. In such a file you can make the logic wait for certain things to happen, then proceed with doing other stuff. AAO users are implementing thier own first officer and/or flight attendant with this technique. In this case, the line that waits for the battery switch would look like this: (...some code...) [(L:VC_Battery_SW_VAL, Number) 10 ==] (EXECBAT:C:\myfile.bat) (...more code...) That CONVERSATION you start at the beginning of your flight (via Autoscript), and it will wait for the battery switch.

As I wrote above, you cannot catch the "click", that is not possible with LVars. You can only react to the animation LVar changing its value (=observing the result of the click - that is not the same). Please specify what "the first click" actually means. Do you mean every change of the switch = both ON and OFF direction? Or only "ON" because you always start in cold and dark mode?

I'm sorry, but I have no idea what you are doing there. Why aren't you just using my script? Lose the // comments. They are bad form and only slow down processing for no purpose. You know what your own script is doing, you don't need a comment to tell you. (L:MyVarBat) is AAO internal, it doesn't have a unit. Lose the ", Number" (L:MyVarBat) MUST always have the same value as the (L:VC_Battery_SW_VAL,·Number). It serves as a reference, so the script knows when the Battery LVar from the sim has changed. OK? That's the whole "trick" here, it prevents the script from just running every time. You cannot just set it to whatever value you want (why 10? why 20?) LVars don't have to be initialized. Their life begins when they are first used in code. So (L:MyVarBat) is 0 every time AAO is initialized (restarted/connected to the sim/a script is alterted/ etc.)

You cannot "intercept" an LVar - they are just values, stored in the sim under this name. If this LVar keeps its value, you can write an Autoscript that compares it with your own reference value and then triggers some code of your own design - like calling a batch file. But if the aircraft designer chose to only use the LVar momentarily, this won't work. You will have to try, there is no knowing this in advance. You would create a script like this and save it. (L:VC_Battery_SW_VAL, Number) (L:MyBatRef) != if{ (L:VC_Battery_SW_VAL, Number) 10 == if{ (SPEAK:on) } (L:VC_Battery_SW_VAL, Number) (>L:MyBatRef) }Then use Scripting->Aircraft automated Scripts to run it every 500ms or something. Then, every time you turn on the battery (or rather, flip the switch to "on"), your computer will say "on" - that's what the SPEAK command does. Replace the SPEAK command with whatever you need, probably EXECBAT - see AAO manual. Be mindful that this is just off the top of my head. None of this is tried or tested.

What do you mean by "convert"? In general I would expect that you can just use the Lorby StreamDeck editor to drag the actions from the StreamDeck profiles to the StreamDock ones (you don't need an actual Elgato StreamDeck to install their software and consequently their profiles). But it has been a long time since I tried this myself. Neither the StreamDeck nor the Mirabox plugins were meant as actual features of AxisAndOhs. They are just examples of what to use AAO's WebAPI for and how to do it. They are a bit of Javascript, demonstrating the communication between the device software and the AAO API. The plugins are not set in stone, feel free to adapt and alter them at your leisure.

It does work for me, using the "StreamDock" software that comes with the original Mirabox N4. Version number is 3.10.194.0707, no further updates are available. The devices of the various brands and their associated software can be slightly different. As the AAO plugin is just a bit of Javascript, feel free to correct/alter it to your needs. The UI software should have a debug mode or debug web page, with the Mirabox it is http://localhost:23519/ But you may have to activate debugging first, not sure.

App focus issues are usually only relevant when you are using keyboard commands? In any case, I would not start AAO with the sim, that would be the first step. Next, disable Mobiflight and Voice Attack, see what happens. (are you aware that AAO also does voice recognition?) Mobiflight in particular can be problematic when used with AAO. Both apps essentially do the same thing(s), and they can step on each other's toes. P.s.: I won't be looking at your screenshot, sorry. My AntiVirus flags that web page as malicious.

In AAO you use the (EXECBAT: command, see AAO manual around page 83 "AAO specific RPN commands". But "click on a switch in the cockpit" can have many different consequences, and only very few of them can be observed from the outside by AAO. Essentially the sim only "reports" K: events and IEs over SimConnect. For those you can use the (LISTEN_FOR_RPN or (LISTEN_FOR_K script headers to catch whatever is being sent from your switch. If the switch doesn't send anything that you can observe, that would mean that you have to alter the switches' code in the sim to make that happen. Are you the developer of the aircraft? Ideally you would add a bit of Javascript to access the AAO WebAPI and send the EXECBAT command directly.

Then I have to assume that the issue is specific to your computer. Not sure how I can help with that. I don't even know where to start looking, this has not been observed before. If I have to guess, I would say that a piece of software, another addon or a driver is interfering here. Also, when there are app focus isues, I wouldn't let the sim start AAO. I always do it the other way round, my AAO starts the sim. That also prevents problems with admin privileges.

The correct syntax would be (L:1:CONST_FEATHER_Switch1, Number) LVars that are to be synchronized with the sim must have a unit in AAO. Use "Number" when in doubt. Otherwise the LVar remains internal to AAO (so you can freely use your own LVars in your scripts without weighing down the interface to the sim). On a side note, in the latest SDK documentation for MSFS 2024 Asobo says that "L:1:" equals "Z:". Don't know if that is true though.