Lorby_SI

You're right, it doesn't. Strange, that used to work. Must be a bug of some kind, I will look into it.

What kind of input does this control send? Joystick buttons? PMDG have their own SDK, and there are custom events for just about everything. In AAO, open the normal event selection dialog, then go to the tab "Aircraft SDKs". PMDG events are in there too - maybe filter for "EVT_MCP_" that should be the ones you need. (I'm not sure if you have to activate the PMDG SDK first - there is a chapter in the AAO manual that tells you how to do that "Chapter 17 PMDG Aircraft with AxisAndOhs")

String literals must be enclosed in single quotes 'A35'·(>A:ATC·ID,·String) Spec is here: AAO manual -> "RPN Operators in AAO" -> "String operators" -> first line after that header.

Actually, that should be blacklisted as well. I know, this sounds weird, but AAO communicates with mice and keyboards through other means. When you have trouble like this, make sure to blacklist absolutely everything - except for your game controllers = joystick/yoke/pedals/TQs But what I suspect is that maybe not all keyboard events are reaching AAO, and it will miss the odd key press or release and ultimately potentially get stuck. Not sure.

In what way does this concern a Lorby app? Are you assigning the keyboard keys in AxisAndOhs? If so, make sure to update the device blacklist. And maybe consider using vJoy instead of keyboard commands.

Either way works - they do the same thing. Then MAN-RPN option in the button assignment is only there for convenience, when you want to assign small scripts. In this case I would recommend testing it in the script editor first, so you can see if it works for you.

To add: the other option would be to use vJoy or ViGEm. With that you can use AAO as an interpreter between exotic hardware and standard joystick events which you assign in the sim.

Only way I know of is sending a Coherent command directly into the sims' Javascript processing by using the AAO InGame panel. Check out chapter 8 in the AAO manual, there is an example for doing that for the ATC panel. That's a question for Asobo - why are they listing key events in their SDK documentation that clearly don't work. ATC panel isn't the only one, Camera and Vierw events don't work either (haven't been working since the Alpha version of MSFS 2020 - but are still part of the SDK spec...) Be mindful that the controller assignments in the simulator and what an app like AAO is allowed to do with the SDK are not the same thing. Many items in the assignments have names similar to SDK K-events - but they are not related.

Or Dev Mode ->Tools -> Behaviors -> click back into the sim -> hover the mouse over the knob/button/lever you are interested in (=where you see the mouse cursor change) -> press "CTRL + G" . This brings up the behavior code of that component. Then look at the "MouseRect" (FS24) and/or "...Interaction..." (FS20) parts of the component. There you will see the RPN code that is triggered when you use the mouse on that knob/button/lever. That is what you want to replicate in AAO.

No. You are supposed to switch the box to "MAN" with the green button below it. Then select RPN, then input the script into the box. Screenshot

Sorry, no idea. It is just working for me, without any fuss. Only difference is, that I'm not using any external scripts, and that my numerical command is just a single item, not multiple ones (again, not sure if that even works - or if you just put one ! at the end? Key down event for the commit looks wrong. This should be on MAN all the time, how did it end up looking like that?

I thought about this for a while, and I don't think you can do it like that. It is logically impossible -the moment that you send the OFF event, voice recognition is turned off, and you can't get it back with a voice command. What I did instead is use a "commit" command with an RPN script, and that seemed to work. My script sends the OFF, waits for a second, and then it turns speech recognition back on. So I just say "set altitude two thousand", and then I add "commit". Create a new button assignment Set the Key Down Event to "MAN" with the green button below the event box. Select "RPN" as the event type Enter this code into the box: 1 (>K:AAO_VOICEREC_OFF) (SPLIT:1000) 1 (>K:AAO_VOICEREC_ON) Select Device "Voice" Enter "commit" as the assigned button/key (or whatever you like) Save Make sure that there is no other button that is calling AAO_VOICEREC_ON or AAO_VOICEREC_TOGGLE! Also, be mindful that this will not work with the Bridges, only default Windows Speech recognition. The Bridges cannot be used with an "open mic" (at least that is what I remember about them)

I have no idea if that even works (or rather, I am almost certain that it doesn't, because it is not supposed to). ON and OFF are supposed to be used with a "push-and-hold" button. If anything, that it can possibly only work using the "TOGGLE" event. But I doubt that it is that easy. The entire logic just wasn't made for this use case.

I've tried that a couple of times now, and I am not getting that message. I got it once, just after installing the bridge, but never again. Did you create the two necessary Autoscripts to start and stop the bridge? The green LEDs on the bridge and on the bottom left of the AAO main screen are "on" / bright green?

Did you read the whole chapter? There is a typo in the very first example - the name of the LVar with the numerical input is incorrect. But it is correct on the subsequent pages: (L:AaoVoiceRecNum). Also, for simple assignments, you don't have to use this variable at all - there is also an example for that in the chapter. Other than that, yes, PTT is mandatory for this. I would also recommend to use the "Voice Recognition Status" gauge in AAO, so you can see what is being picked up (or not).

P3D's own cfg files are supposed to be UTF-16 LE BOM

This is probably setting a certain AP slot or mode. Add that initial turn to the script? Either to this one (=turn first, set later) or create an Autoscript that runs every time that you load the plane, so the indicator doesn't say "---"?

The Avar that I've posted above works for me in the C172 G1000.

Trial & Error, looking at the behavior code, experience. There is not much else if the you have to work around the work around = when the devs don't care about the SDK rules and just do whatever they want in their plane - and that includes Asobo/Microsoft themselves! Initally (=25 years ago), you always needed events (K:) to change the values of the variables (A:). All AVars were read-only in the early days, but this has changed over time. If you can write to a variable directly or not is still in the SDK documentation: Simulation Variables And the events that change them are also in the SDK Key Events AAO has both the variables and the events in the initial lists. But the devs can and will go way beond that, use LVars, BVars, IEs, HVars whatever - which you can usually find out by looking at the behavior code using MSFS developer mode. Turn on dev mode, open "Tools->Behaviors". Now click back into the sim, hover the mouse over the button/lever/knob that you are interested in and press Ctrl + G. In most planes (not all!) this will bring up the code associated with the control. Look into the "MouseRect" components, identify the code that is triggered when you use the mouse on the control, and replicate that in AAO. There is a shortcut: with more recent aircraft, check if the developer made InputEvents for it - you will find them on the AAO event selection dialog on the tab "MSFS IEs". They (or their bindings the BVars) can just be utilized by doubleclicking them. That you couldn't see this particular action in the behavior code is normal though - the buttons on the G1000 don't need to set a specific altitude, they are always only dialling it up or down.

Try writing to the variable directly: (L:AaoVoiceRecNum)·(>A:AUTOPILOT·ALTITUDE·LOCK·VAR:0,·Feet) This variable is indexed (the ":0" is the index). Depending on what slot the autopilot is set to (think of it as the "managed", "selected", "manual" etc. modes), you have to write to the appropriate var: (>A:AUTOPILOT·ALTITUDE·LOCK·VAR:0,·Feet) (>A:AUTOPILOT·ALTITUDE·LOCK·VAR:1,·Feet) (>A:AUTOPILOT·ALTITUDE·LOCK·VAR:2,·Feet) (>A:AUTOPILOT·ALTITUDE·LOCK·VAR:3,·Feet) There is also a default without the index (which should be the same as the "0") (>A:AUTOPILOT·ALTITUDE·LOCK·VAR,·Feet)

MSFS 2024?

What exactly did you assign, what does your script look like? The SET event incrementing the value is highly irregular - there is another event for that in the SDK. All aircraft can have custom solutions for everything, especially in MSFS. There are no guarantees that anything will work as the SDK says, in many cases the devs disregard the specs and work around them. Since AAO is essentially just a translator between you and the sims SDK, some detective work may be required to figure out what needs to be done to get a certain effect. What aircraft are you trying to do this with exactly?

AAO has no voice recognition system, it relies on Windows speech'to'text by default, or the bridges (Windows Online = "Cortana", Azure, Polly). I'm not sure what I could fix though, the Cortana bridge seems to work normally for me? What should I be looking at? Apparently, recognition works very well for some people, and not so great for others. Not sure why that is, AAO is using the same mechanisms as most other tools, including I think VA... One of the AAO testers even built an entire ATC voice interaction system based on AAO, using custom grammars and lots of Javascript.

Not for me, I can't confirm that one. Can you specify what "breaks" means? What exactly are people reporting? I am running StreamDeck 7.5.1 right now (just updated as well), with the AAO plugin, using the BKSQ StarShip profile in MSFS 2024. Seems to work just fine. Cross checked with the Lorby Gauges profile, working as well.

That is not enough information. How this must be operated depends on what type of asset it is (HVar, IE, BVar, LVar etc.), and what value you should be sending with it. And IE will do different things when you send value 0 with it than when sending 1. Not at my computer at the moment - I would suggest taking a look at the knob's behavior code. Activate MSFS developer mode, open Tools->Behaviors, click back in the sim and hover the mouse over the knob. Then press Ctrl-G. Now take a look at the MouseRect component - it shows what happens when the knob is operated with the mouse - that's what you then replicate in AAO.