@LorbySI and one more thing, would it be possible to add a RPN command to read/write to a file? That would make it possible to save and load cockpit states in aircraft that don’t have that feature
Yes, I have the G910 and changed the port as per the instructions to 6080 and it works fine. Hope this helps.
Wht would you want to write to that file? And what should happen when you read it?
Cockpit state like Get/Set a bunch of variables?
You could do that with script files, which are already supported in AAO. You just write all necessary RPN commands to set up a plane into a file, then you can load it using the (SCRIPTFILE:…) command in an RPN script.
With new version 2.23b22 i cant import any scripts.
Have downloaded the new profiles from Guenseli at flightsim (e.g. fbwA320 and tbm). When i try to import the scripts AAO is not responding anymore and crashes. With the older version of aao that worked always. What can i do?
Think its working but its extremely slow…
I would like to read a bunch of variables (Lvars and Kvars), either continuously or when the flight ends, and write them and their current values to a file. Then I would like to trigger a script when the aircraft is loaded that reads the file and set all variables. In other words, a state saving feature. Is that possible now? Can I store the current value of an Lvar in a script file?
The only way I can think of that could work is to store the variables and values in an environment variable and then execute a separate app that parse that environment variable and saves it to a file (and vice versa)
Edit: The SAVEFILE command seems to save the complete state of the aircraft, so a LOADFLIGHT command would be awesome 
You may find Guenseli’s profiles requires the latest A&O released last week. Which if you are unfortunate like me and had bought from JustFlight, it is not available to you yet! Patience is required here I know.
Even if you could do that, I don’t think that it would work the way that you want. The aircraft instruments and systems use internal variables in their Javascript and WASM code, that we don’t have access to. Saving and reloading the sim variable values is not enough IMO, the way how they got that value is just as important (=all the steps inbetween, triggering internal code etc.) That is the reason why all makers of complex aircraft usually have their own aircraft state save/load mechanism.
I stand by what I wrote above - to load a certain aircraft state from disk, you would have to create a script file that goes through the required steps automatically that you would normally do by hand. If that is even possible.
But I will put a recording feature on the list, kind of like what you can do in MS Office. Maybe even with a timecode, so sequential actions can be timed correctly.
It would, if it would decide to work. MSFS doesn’t like it when you load a flight this way. The SAVEFLIGHT just triggers the flight saving mechanism that MSFS has built in. I will add the LOADFLIGHT in the next version, but no promises that it will work as expected.
Thanks, that made my day. Changing the port to 6080 did it.
I hear you and I’m aware that it’s not possible to save the entire state of the aircraft (or at least very difficult). But I think that just saving the values of “physical” switches like beacon light and fuel selector valve shouldn’t be that hard. I’ve actually done this with an app I created for the CRJ. I didn’t touch anything that has some kind of “logic” to it, just the knobs and switches that turn things on and off. That worked quite nicely but it can only do LVars.
As for the flight saving I did some tests and that feature is just as you said, not very good. It is for instance almost impossible to save a flight that is in a parked state. When loading a flight that was saved on the apron it interpret that as flying 15ft AGL 
Hard it is not, but - how do you propose that the configuration of that feature would work? How/where would you list the variables that you want saved? How would you know their names? I could write a list of all variables and their values to the disk that you touched with the current AAo configuration, but that is hardly the same thing.
Hello,
In the the X-Touch Mini leds have the same ID in layer A and layer B.
If i create a LED script in layer A it will be the same in layer B.
Is it possible to have diferent RPN led assignments in layer A and layer B?
Or some kind of variable that we could know which layer is selected?
Thank you in advance.
Great Application!!!
I think that you would have to make your MIDI Out - scripts conditional.
Just thinking out loud:
-
You create two MIDI out scripts, one for Layer A and one for Layer B that handle all your LEDs at the same time (yes, they will be big)
-
Then you create another script that queries a local LVar that you create (for example (L:MyLayerSwitch) or whatever) and calls either script A or B depending on the value of that variable 0 or 1. This is the script that you would run as the “aircraft automated script”.
-
And finally you make sure that the (L:MyLayerSwitch) is set to 0/1 accordingly when you change Layers (you can switch Layers with AAO and MIDI Out too, and that would be the way to go IMO).
I know that there are people who already did this. Maybe they will chime in also.
What about a RPN command like (SAVE_STATE:d:\state.txt, )? With that in a script one could have that running every 5 or so second.
Here’s something for inspiration:
Sure, but the question remains - what variables do you want AAO to query and save? Where will the app get this information from? IMO there would have to be a config file or something, where you specify the variable names for this specific aircraft.
Either a simple text file with a list of vars, or you could add an option to dump all LVars to a text file and then it’s easy to just copy/paste the once you want into the script.
Thank you for the fast response @LorbySI
Will try that!!!
Bought the app via justflight.com and i’m very happy with it 
Or maybe it’s just too complicated and we shall just forget it 
Problem is, that in many cases MSFS seems to hold all LVars that there are in all aircraft at the same time… that may be a little bit overwhelming.
And then you will want HVars and Bvars too - which cannot be exported this way - and we are back with the script files…
Either a simple text file with a list of vars,
Yes, that would probably be the way to go. But this will require an additional SimConnect module, to make sure that the sheer size of this query won’t compromise normal app operations. Personally, I wouldn’t run that one every 5 seconds…
Not for me, I just provide the hammer - I don’t build the house. But definitely for the end user, creating that config file is quite the challenge IMO. We all struggle with the intricacies of finding the correct variable names in all those different implementations of aircraft… let alone safely identifying a large number of them for the state config script.
I can add the functionality alright, that is no big deal. But what you make of it will be up to you…