Here is an example of how to use AAO to access the MSFS cameras.

With this WebPage for AAO you can create your own "sets" of MSFSs' predefined camera positions and use scripts to toggle through them. Once you've created some sets, the WebPage does not have to be open to use the scripts, you only need it to manage the sets.

All this is free and open source - any web developer who thinks that this should look different, please feel free to alter it to your heart's content! (I mean that, I am no artist by any stretch of the imagination)

https://www.dropbox.com/scl/fi/1fbm8ehpvs99gshc6jh3u/camctrl.zip?rlkey=9wii773n8akrddusjrpkv3wff&dl=0

Edited June 28, 2025Jun 28 by Lorby_SI

Btw. the package is (only) making use of the official camera variables (or rather four of them).

Spec is in the MSFS SDK: Camera Variables

Edited June 28, 2025Jun 28 by Lorby_SI

Why is it that returning to the original cockpit view is sometimes refused?

For example:

(2,1,1,1) → (2,5,2,0) → (2,1,1,1) does not work

(2,1,1,1) → (2,5,2,0) → (2,1,1,0) works

(2,1,1,0) → (2,5,2,0) → (2,1,1,0) does not work

(2,1,1,0) → (2,5,2,0) → (2,1,1,1) works

Even when I build a script, I keep running into this problem. Could you explain why this happens?

I am monitoring the SimVars directly, so I can confirm the values change exactly as shown above.

45 minutes ago, ninguru said:

Why is it that returning to the original cockpit view is sometimes refused?

For example:

(2,1,1,1) → (2,5,2,0) → (2,1,1,1) does not work

(2,1,1,1) → (2,5,2,0) → (2,1,1,0) works

(2,1,1,0) → (2,5,2,0) → (2,1,1,0) does not work

(2,1,1,0) → (2,5,2,0) → (2,1,1,1) works

Even when I build a script, I keep running into this problem. Could you explain why this happens?

I am monitoring the SimVars directly, so I can confirm the values change exactly as shown above.

Sorry, no idea. That is one of the things that MSFS is just doing because of reasons unknown. I have the same problem with the WebFMCs Vol2. The question would be better directed at Asobo.

I've experimented with short (SPLITs between the variable settings, but that doesn't make a difference either. Maybe it is related to the other camera variables, but I won't even pretend to know what they are supposed to do.

To clarify, these variables aren't AAO assets, they are SDK components, see the spec here:

Camera Variables

I suppose that nobody really knows how they work, we are all just stumbling around in the dark.

Edited September 13, 2025Sep 13 by Lorby_SI

Thank you very much for your quick reply, Lorby_SI.

For the time being, I will try to use the virtual keyboard to implement this and assign it to my controller.

Thanks again for your support!

5 hours ago, ninguru said:

Thank you very much for your quick reply, Lorby_SI.

For the time being, I will try to use the virtual keyboard to implement this and assign it to my controller.

Thanks again for your support!

It is not impossible that one of the SDK events will work for calling up the default view, or a Coherent Call. Both could be used with AAO too.

Or maybe it is about the sequence in which the variables are changed. Know what I mean? For example, when you are in a sub-view number that doesn't exist for the Pilot camera, and set the main view back to 1, then there will be an error, and changing the rest of the variables amounts to nothing. Maybe it would help if you reverse the order in which the default view is called (= fist reset the sub views to 1, then the main view).

Edited September 13, 2025Sep 13 by Lorby_SI

Lorby_SI,

Afterwards I found out on the MSFS DevSupport page that this issue has already been registered in the bug tracking system:

https://devsupport.flightsimulator.com/t/camera-reset-events-and-variables-dont-appear-to-work/11444/4

In any case, what I wanted was to always switch to the cockpit pilot view, no matter which view mode I was currently in.

I was struggling with why the following sequence did not reliably set the pilot view:

2 (>A:CAMERA STATE, Enum)

1 (>A:CAMERA SUBSTATE, Enum)

1 (>A:CAMERA VIEW TYPE AND INDEX:0, Enum)

1 (>A:CAMERA VIEW TYPE AND INDEX:1, Enum)

 

But it seems everything is resolved (at least for now) by adding

1 (>A:CAMERA REQUEST ACTION, Enum)

as the first line.

Setting this line by itself appears to have the effect of force-resetting everything except (A:CAMERA STATE, Enum).

You may have already known this, but I wanted to report back.

Thanks!

What I meant was to try and reverse the order in which the variables are set, to avoid switching to an invalid combination of STATE, SUBSTATE und VIEW TYPE that the pilot camera potentially doesn't support.
OK? What I suspect is, that if for example you have a current SUBSTATE of "5" and then try to switch to STATE "2", that might cause an error (=the camera doesn't switch), because there is no substate 5 for state 2.

1 (>A:CAMERA VIEW TYPE AND INDEX:0, Enum)

1 (>A:CAMERA VIEW TYPE AND INDEX:1, Enum)

1 (>A:CAMERA SUBSTATE, Enum)

2 (>A:CAMERA STATE, Enum)

 

2 hours ago, ninguru said:

But it seems everything is resolved (at least for now) by adding

1 (>A:CAMERA REQUEST ACTION, Enum)

as the first line.

Setting this line by itself appears to have the effect of force-resetting everything except (A:CAMERA STATE, Enum).

You may have already known this, but I wanted to report back.

No, I didn't know that. Thank you for posting it.

3 hours ago, Lorby_SI said:

What I meant was to try and reverse the order in which the variables are set, to avoid switching to an invalid combination of STATE, SUBSTATE und VIEW TYPE that the pilot camera potentially doesn't support.
OK? What I suspect is, that if for example you have a current SUBSTATE of "5" and then try to switch to STATE "2", that might cause an error (=the camera doesn't switch), because there is no substate 5 for state 2.

1 (>A:CAMERA VIEW TYPE AND INDEX:0, Enum)

1 (>A:CAMERA VIEW TYPE AND INDEX:1, Enum)

1 (>A:CAMERA SUBSTATE, Enum)

2 (>A:CAMERA STATE, Enum)

 

Yes, I have tested that in various ways too. I also tried inserting a longer split, but there is no response unless I set (A:CAMERA STATE, Enum) first. However, if I set (A:CAMERA STATE, Enum) first, then some kind of internal stack seems to take priority.

From here on it’s just my personal speculation: for example, when you press Ctrl+4 twice, it returns to the previous view. At that moment, the previous view must be stored somewhere in a stack, and when moving from the previous view to the next (or returning), the simulator plays out a smooth transition animation. Because of this mechanism, there seem to be two states — the “previous view” and the “next view.” I suspect that this mechanism is internally programmed to avoid directly setting the previous view, in order to preserve that transition behavior.