the next version of AxisAndOhs will provide read&write access to the internal LVARs of the MSFS planes.
LVARs can be queried from the simulator at runtime and are used in the AxisAndOhs RPN scripts. The app will provide a list of all LVARs that are active in the running sim so you can add them to the RPN scripts more easily. The scripts can then be triggered with any compatible external controller (Joystick, MIDI devices, Saitek Panels etc.) or accessed via the AAO WebAPI.
For example, this script toggles the yoke in the cockpit:
1·(L:XMLVAR_YokeHidden1,·Number)·-·(>L:XMLVAR_YokeHidden1,·Number)
This has revealed, that contrary to a widely accepted belief, the controls of the Maps on the PFD and MFD (like zoom and scroll) are NOT operated by local variables, at least not all of them. Instead they query the inputs of the HTML instrument itself. To access that logic, using H-vars is required, which is also possible with AAO.
Well⊠where can I find all those methods, classes or just examples for better scripting? Do you have some great recommended sources.
Another example 1·(L:XMLVAR_YokeHidden1,·Number)·-·(>L:XMLVAR_YokeHidden1,·Number)
What does the 1 in front do? Why do we need the minus -? Why do we set to the L with >L when your list tells us that the Y is settable?
You see I am really confused, I need a lot of examples to get all of this.
Another example 1·(L:XMLVAR_YokeHidden1,·Number)·-·(>L:XMLVAR_YokeHidden1,·Number)
There are a ton of resources about the MS flightsim RPN scripting - even when they are 15 years old, they are still valid. TMBK the MSFS SDK documentation doesnât cover this yet, but the Prepar3D SDK documentation is accessible online. Google for âP3D RPN scriptingâ, or âFSX XML gaugesâ, visit fsdeveloper or just search for the variable name that you want to handle in the script. This type of coding has been used in the MS XML gauges for almost 20 years, that is why it was chosen for programming purposes in AAO.
As for your example above - this is RPN, so postfix notation. Postfix is how a computer actually works, and it was very common when computers were still young.
Simply put:
Code is written stack-oriented: push value, push value, call operand/calculation etc.
Nothing of the high-level programming languages like Javascript exists.There are no classes, objects, procedures, functionsâŠ
â(L:â is the getter method
â(>L:â is the setter method.
This goes for all variables, A, H, too
Something must be on the stack to be set to the variable, so âsomethingâ is required before the setter is called.
1·(L:XMLVAR_YokeHidden1,·Number)·-·(>L:XMLVAR_YokeHidden1,·Number)
converted into infix notation is
L:XMLVAR_YokeHidden1 = 1 - L:XMLVAR_YokeHidden1;
Why do I do this? Because it is supposed to be a toggle. The LVar is 0 or 1 and the value determines if you can see the yoke or not. So when it is visible, I set 1-0 = 1 to the LVar, and it disappears. Calling the script again will set 1-1 = 0 to the Lvar and the yoke reappears.
Split into two separate scripts (for an ON button and an additional OFF button):
Thank you for posting the examples. I am with Perform3r. I am not a programmer. I have managed to get around Lua P3D scripts and FSUIPC macros by copy & paste with variable replacement. It is always trial and error, mostly error. So, the more examples I can look at the better the chance I will get it to work.
Thatâs not an LVar.
1 (>B:AIRLINER_LS_Toggle)
or
0 (>B:AIRLINER_LS_Set)
and
1 (>B:AIRLINER_LS_Set)
etc.
LVars arenât InputEvents, they are just - variables. Normally they are used to control animations and internal states. Sometimes you are lucky and manipulating an LVar will in fact actuate an aircraft system, but that is in no way a âstandardâ or rule of any kind.
To find out what a certain button or lever in the cockpit does when you operate it with the mouse, do this:
Activate MSFS developer mode
Open âTools->Behaviorsâ
Click back into the sim window
Hover your mouse cursor over the button or lever that you want to investigate and press âCtrl Gâ
This will bring up the behavior code in most aircraft. Near the end of the list of components there are usualls things like âAsobo_GT_Interaction_LeftSingleCodeâ that contain the code that MSFS executes when the associated mouse event is received - and that is what you replicate in AAO.
In the future (as soon as the bug with the input events has been sorted out by Asobo) this will be mostly obsolete, because then AAO can read the existing input events directly from the aircraft and you can select them from a list. At the moment (MSFS 1.34.16.0) this only works when developer mode is on (check out the chapter about the MSFS InputEvents in the AAO manual)
Sorry, no idea why it would look different for you. I donât have any special settings or anything.
That is a question that you would have to ask Asobo.
Iâve been using Behaviors to find VARS, but the only way I knew was to manually dig through the behaviors until I found what I thought was the correct VAR.
In some aircraft that is still required. For example, the FBW A320 doesnât react to Ctrl G at all.
I found the âComponent searchâ element very helpful too.
In the future (or when you keep devel mode turned on) you can use the InputEvents (IE:) directly in AAO. There is a chapter in the manual about them.
I use SPAD, and finding the VARS is of course the important thing, regardless of which tool one uses.
It has Data Monitor, and Event Viewer to find VARs. Similar to IE in A&O?
Event Viewer is easy, but I find that many VARs donât show up there, and require digging into Data Monitor. Itâs a powerful tool, but sometimes requires a lot of guessing to find out which VAR does what - unless of course the developer provides a comprehensive SDK list. Thatâs something I find sorely lacking, which of course is the reason we need to dig into Behaviors in the first place.
Iâm assuming that Ctrl+G in Developer Mode is not exclusive to A&O, and will help SPAD users a lot, even if it wonât help with every cockpit control.
No, IEs have nothing whatsoever to do with anything that we knew before. They are a new asset that Asobo introduced with SU13, but at the moment they are only available in AAO when you set MSFS to developer mode (that is an official bug that Asobo is working on).
IEs are supposed to end this struggle with the Behaviors, as at least HVars and BVars are apparently related or even derived from the InputEvents.
LVars are a different matter, as normally they shouldnât be used like this. Their main purpose is animation control and data transfer between internal modules. It is entirely possible to move a lever in the cockpit through LVars while the actual aircraft system remains unaffected (like with the PMDG aircraft).
Thanks for the detailed info. One of the main frustrations I have when using SPAD is when I know an event that has been bound to a switch on, say a Bravo TQ, is controlling something (Landing Lights, for example) but the switch in the virtual cockpit doesnât move. My (limited) understanding is that the switch animation is sometimes a Bvar, which Microsoft hasnât allowed control of in the past.
Perhaps with IE thatâs starting to change, and the new control A&O users have will soon be available in SPAD.
Not sure that I understand - you can control BVars right now, it is just a little more involved technologically for the app that is doing it.
In case of your unmoving switches, that is probably the usual split logic. One part of the behavior code is actuating the aircraft system, the other handles the animation of the 3D switch. You just have to find out how the animation is handled (often by an LVar or A:Var or combination thereof) and replicate that in your app (Iâm sorry, but I know nothing about how SPAD works). With BVars and IEs that becomes a lot easier - IF the aircraft developer can be bothered to use them and implement them correctly. A small part of detective work will always remain.
