By the way: What is the right syntax when I want to show or hide the ATC Window. The Event Name is “ATC”, but what is the Value? How to use the ATC commands (K:ATC_MENU_0)??
You mean from the stream deck? Or in the RPN scripts?
I don’t think that opening the ATC window works in MSFS. There are a few legacy events in the MSFS documentation that don’t do anything, and that may be one of them. The _1, _2 etc. events work though. I have mapped the _1 event to a button on my yoke, since this is the most used of them all. IIRC the ATC window doesn’t even have to be open for the menu events to work.
In the StreamDeck Event button you just select K: in the little drop down and enter ATC_MENU_0 in the textbox. The value to send is 1.
Full code In an RPN script is this (the > means “write to”):
Its possible i can get the New streamdeck plugin, for testing softkeys on the behringer and working with the streamdeck together.
There is nothing “new” in the version 2.3 of the plugin. The only difference is the way that the port for the AAO WebAPI is changed in the plugin, should that become necessary (=plugin not working at all because port 9080 is already in use by another app). I’ll send you a PM here in the forum again.
Is anyone having any issues with heading and speed scripts in the CRJ? I have set up scripts for both and they work fine, but then when I shut down MSFS and restart and load back into the aircraft, the heading bug is spinning round at about 2000RPM and the speed bug is hard locked to maximum (400 knots).
I had the spinning heading bug too yesterday, but I don’t know how I managed to get it. It has only happened in the AS CRJ though. Not even a sim restart cured it, I had to temporarily disable the AAO WASM module.
For me it happened right after I tried that “fix” for the CRJ where you are supposed to turn off asychronous loading of modules. I then reset that back to default, and the spinning didn’t happen again. But that isn’t saying much, I had my hands full working around the CRJ quirks in AAO 2.04…
The spinning is not really about the scripts. It happened to me after a sim start when AAO was not even running. It looks like there is something weird going on between the WASM modules. It is as if MSFS or the CRJ remember things between sessions - I’ve never seen anything like it.
I used MSAO to disable my module, restarted the sim, the spinning stopped. Reenabled the AAO WASM module and things were fine again.
Disabling the asynchronous loading of WASM modules in developer mode was mentioned as a CTD fix(?) on the Aerosoft forums. But TBH that doesn’t sound good, it is unclear to me what it will do to the AAO module that is supposed to load asynchronously.
Not sure. It looks like starting AAO after the plane has loaded helps a little bit with these LVar issues (there are more than just the heading bug). Maybe there are other LVars involved that have to be changed at the same time, that is quite common in MSFS. And in the CRJ there seem to be hundreds of LVars at work.
btw. I am using this code for the heading change now with a rotary encoder on the X-Touch. It even causes a bit of controller acceleration, turning the encoder really fast causes bigger changes of the heading bug
It would be really nice though, if addon plane developers would adhere to “established” simulator standards and process at least the simulator events documented in the SDK. Hundreds of customers scrambling to find solutions for trivial controller requirements doesn’t feel right to me.