1 hour ago, Lorby_SI said:

OK, so I looked into it. There is a typo in the manual, the variable that holds the numerical value is called "(L:AaoVoiceRecNum)".
I would also recommend to run the "Voice Recognition Status" gauge, so you can see what is being picked up. I have to leave a significant pause between the text and the numerical value, and my microphone doesn't seem to be the best - the Bridge struggles to pick up the correct numbers.

Well that says alot then, I’ll try the new variable , weird nobody else had this issue, couldn’t find anything when I googled.

Regarding the gauge I can’t really find it, it doesn’t seem to be where the manual says it would be

4 hours ago, Lorby_SI said:

OK, so I looked into it. There is a typo in the manual, the variable that holds the numerical value is called "(L:AaoVoiceRecNum)".
I would also recommend to run the "Voice Recognition Status" gauge, so you can see what is being picked up. I have to leave a significant pause between the text and the numerical value, and my microphone doesn't seem to be the best - the Bridge struggles to pick up the correct numbers.

Well that’s says a lot then, weird nobody else seem to have had this issue, I found nothing when I googled about it .

About the gauge I can’t find that , seems it’s not where the manual says it would be , can you give me a hint ?

9 hours ago, Parme said:

Well that’s says a lot then, weird nobody else seem to have had this issue, I found nothing when I googled about it .

The variable name is only misspelled in the initial example. It is correct on the subsequent pages and also on the "LVars used by the voice recognition module" page.

9 hours ago, Parme said:

About the gauge I can’t find that

The gauge should be in the list by default, it is shipped with the app. "Gauges -> Desktop FIPS -> + -> Select 'Voice recognition status' from the dropdown"

Edited August 4Aug 4 by Lorby_SI

On 8/4/2026 at 7:30 AM, Lorby_SI said:

The variable name is only misspelled in the initial example. It is correct on the subsequent pages and also on the "LVars used by the voice recognition module" page.

The gauge should be in the list by default, it is shipped with the app. "Gauges -> Desktop FIPS -> + -> Select 'Voice recognition status' from the dropdown"

a question, do you plan do update the voice recognition system in AAO? or fix catana bridge ?

as for me now, i managed to get the agent plugin for VA but it lacks variables that i need and for example it cant change the altitude in G1000 cus it doesnt use the AP_ALT_VAR_SET_ENGLISH variable.

2 hours ago, Parme said:

a question, do you plan do update the voice recognition system in AAO? or fix catana bridge ?

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.

Edited August 11Aug 11 by Lorby_SI

17 hours ago, Lorby_SI said:

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.

17 hours ago, Lorby_SI said:

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.

As for Cortana bridge I don’t know, what happens is that every time I press PTT and releases a warning shows up saying that the information about the warning cannot be found.

But anyways , after some tweaking I got the windows engine to work pretty well, but then to a question connected to my voicebuild in aao, do you know why the standard variable for setting the altitude (set_alt_english) doesn’t work with the g1000 systems ? It just increments the number

43 minutes ago, Parme said:

But anyways , after some tweaking I got the windows engine to work pretty well, but then to a question connected to my voicebuild in aao, do you know why the standard variable for setting the altitude (set_alt_english) doesn’t work with the g1000 systems ? It just increments the number

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?

Edited August 12Aug 12 by Lorby_SI

23 minutes ago, Lorby_SI said:

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?

It looks exactly like the AAO manual, the plane I try it on is the Cessna 172 g1000, it works fine on the classic :)

What I’ve tried is to use the event reader and then rotated the inner and outer knob to see what events that triggers , funny thing is that the AP_SET_ALT_ENGLISH triggers but it’s not possible to use that event in the script cus then it just increments och decrements by 1000 or 100. I’ve also tried to use the inner and outer knob events but same thing happens

2 hours ago, Parme said:

Cessna 172 g1000

MSFS 2024?

2 hours ago, Parme said:

What I’ve tried is to use the event reader and then rotated the inner and outer knob to see what events that triggers , funny thing is that the AP_SET_ALT_ENGLISH triggers but it’s not possible to use that event in the script cus then it just increments och decrements by 1000 or 100. I’ve also tried to use the inner and outer knob events but same thing happens

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)

Edited August 12Aug 12 by Lorby_SI

13 minutes ago, Lorby_SI said:

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)

Thanks ! I will definitely play around with this instead ! Do you have a trick in your sleeve to find out this kind of information cus it didn’t pop up in the list of events

4 hours ago, Parme said:

Do you have a trick in your sleeve

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.

9 hours ago, Lorby_SI said:

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.

yeah i see, but none of the above variables for altitude change in the g1000 did work so i have to search more

2 hours ago, Parme said:

yeah i see, but none of the above variables for altitude change in the g1000 did work so i have to search more

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

Edited August 13Aug 13 by Lorby_SI