18 minutes ago, Lorby_SI said:

"Dear user, don't rely on the legacy events, as they might not work"

yes, now you got the idea 😊

IMHO it is not a good strategy to add sentences like this one to a manual. It will cause even more questions. 

I stand by what is written in the product description of the shops: "Try the demo first. No support is provided if you don't. If it doesn't do what you want, please don't buy it.".

Edited September 20, 20214 yr by Lorby_SI

One thing would be nice though - if somebody or a group put together a "how-to-handle" especially MSFS when it comes to external controllers and what methods there are.

In the legacy sims you had the built-in events and variables, the developer specific events (K:#12345), then custom LVars and "hacks" like the ROTOR_BRAKE trick (where developers would use that event to transmit "triggers" to their own logic inside the sim).

MSFS has all that, and then some, like the HVars (H:) and BVars (B:) (and a lot more, that are also not accessible from the outside, like O: and I:). 

Both share the same "problem", as discussed here: yes, many events are predefined in the sim and the SDK spec. But not every developer uses them. For some logic it is easier or even required to go outside of the box, and that is where LVars, custom events, rotor brake etc. come in.

The challenge for us mere mortals is to find out exactly what it is that we are supposed to do if we want to flip a switch in a custom made virtual cockpit. Even more so since everything has become so "unspecified" in MSFS, where new types of variables and input events have been invented, but not standartized. So several different "logics" exist side by side, and every developer can effectively do it differently with every plane.

So what do you do if you wish to access advanced instruments that don't seem to react to the simulator events?

• Make sure to check if there has been an API or SDK released by the aircraft developer - or any publication at all about events or variables that can be accessed from the outside.
• If there is nothing of that sort, you start with the built-in event IDs. See if those where the name sounds about right do anything. There may be several Event-IDs sounding almost the same, and all can potentially do the same thing (or not). Those events are what you get in the AAO treelist by default.
• If that doesn't work, you start looking for HVars or LVars on the Net. Be aware that LVars are mostly used to control the animation, so even if you see the button moving after manipulating the LVar, that does not necessarily mean that the system behind it has been activated. At this point you may also be looking at making your own RPN scripts in AAO, but for the next step this is a hard requirement. AAO can help with that too, with the HVars and LVars scans that are described in the manual. Unfortunately, due to many, many errors in the simulator XML files, the HVars scan is prone to failure.
• If you can't actuate the button itself, you start looking for scripts - for some buttons and knobs just manipulating a single thing is not enough. I have seen many planes where a button caused a handful of events being fired or variables to be set. And you need to replicate this. There are two ways to figure that out, either in the behavior debug console in MSFS developer mode, or in the animation definition XML files themselves (the latter is not too hard, it is just a matter of repeatedly using "find in files" in Notepad++).
• Upvote the threads on the official MSFS forums about giving us easy and consistent access to all those variables, including the new B: var logic. Otherwise we will be left behind at some point. BVars are immensly helpful to the aircraft developers, but there is no way to trigger them from the outside without a code change in the aircraft itself (I've posted a hack about how to do that)

And then there is the other side of the coin. You may want to get information back from the aircraft about the state of a system. That is just as complex, but you are looking for A: and L: variables instead of events. 

It is unfortunate that all the concrete details are all over the Internet. But I don't see a way how to consolidate this, and to bring together the PMDG SDK; the FSLabs one (which officially doesn't exist, but works nonetheless), the various LVars and HVars that are in use in MSFS planes, the method how to trigger a BVar through an LVar etc. That is a huge undertaking and probably best suited for a Github project, Reddit thread or Discord. Unfortunately I don't have the time to manage something like this myself, but if there is such a place I will be happy to contribute if that is requested.

Edited September 21, 20214 yr by Lorby_SI

(I sent most of this via e-mail to support@ and just duplicated here for the community)

Hello Oliver (and gang), and thanks for creating this wonderful tool. I paid for it without even seeing it as the community needs more of this regardless of my specific use case. Good luck with it.

So my use case is the CRJ with Honeycomb's Alpha and Bravo. This seems like a really problematic combo and on my first glance and read-through I'm unclear on a few things that I hope you can help me with.

 

1. My Alpha axis control works great for the elevator and ailerons, but the various axis controls on the Bravo seem to be entirely outside your control even though you clearly show them registering in AAO. They just never translate to moving in the cockpit. What am I doing wrong?

 

2. Do you not support various ON/OFF states over a toggle option? For example, I can use the 7th switch on the Bravo for my Parking Brake, but the only event I see is "Toggle Parking Brake" (or something close to that). I'd obviously prefer events for "Parking Brake On" and Parking Brake Off" as both the Alpha and Bravo use many switches where each setting is a button. 

 

3. Even when I did set these many of them seemed to do nothing. Take, for example, the Beacon, Taxi and Strobe lights of the CRJ. The Alpha has switches for these. Even if I set them to toggle it still wouldn't move those switches in the cockpit. What am I missing?

 

Thanks for any help you can offer.

 

One thing I'd suggest as a UI change is to set off, for example, the first three boxes of the app perhaps with a gray background or something and maybe even the word "OR" in the two gaps between them to make this stand out. Stupid me, I spent about an hour trying to get things going before RTFM and would have gotten it with this aid. It might also help to put a note under the axis and button inputs to tell the user to move the control or push the key/button/switch.

What am I missing?

I will answer to your email.

8 hours ago, Agrajag said:

One thing I'd suggest as a UI change is to set off, for example, the first three boxes of the app perhaps with a gray background or something and maybe even the word "OR" in the two gaps between them to make this stand out.

I don't understand that one - what do you mean exactly?

Edited October 15, 20214 yr by Lorby_SI

31 minutes ago, Lorby_SI said:

I don't understand that one - what do you mean exactly?

If you're like most people you tend to think, "this can't be that confusing" and you just load the app and try to guess how it works. In the manual you clearly took the time to explain the entire metaphor of those boxes being a case of "Do this OR do this OR do this." Given that, it would be more naturally intutiive if that section of the app itself made that clear. The lower area of the screen isn't like that. Those inputs are all related to what you do above. So, if you made those top three stand out from the others, people will realize "these are different" and will be drawn to wonder why and ask. You can even offset that as I mentioned -- perhaps by literally cordoning them off visually. In code/math we know intuitively that 2+(6x5) means multiple 6x5 FIRST and then add 2 because the "6x5" is cordoned off from the rest of the equation. Same thing here. 

By putting a literal OR on the app screen itself, you won't need people going to the manual and we'll visually also relate those three inputs if they stand out from the other fields. That can be done graphically perhaps by doing something like:

1. Select ONE of these: 

-----> Input 1.

-----> Input 2.

-----> Input 3.

2. ............

Above I clearly get that the first step requires me to only do one of the first things and then I go on to another section. That sort of thing. Sorry for the long explanation. I owned a QA company for two decades so this is just built into anything I look at. heheh

Edited October 15, 20214 yr by Agrajag

4 hours ago, Agrajag said:

you won't need people going to the manual

But I want people to go to the manual - it is imperative that they do. The matter of assigning external controllers, especially with MSFS, is complex. And AAO has so much functionality that users will get lost or miss a lot of good stuff if they just start clicking away.

Edited October 15, 20214 yr by Lorby_SI

The above is exactly what I was suggesting. Thanks for considering it. Of course the user would always be best going to the manual, but in my view there's never anything wrong with helping where possible. It helps overcome that horrible initial feeling of something being too much to take on. 

Has anyone created a video to help me set up my AXAIR miap with AAO's ?? I'm reading the manual but I do not understand. Need help with what the actual events do. 

9 hours ago, Tuckster2020 said:

Need help with what the actual events do

The "actual events" are not an AxisAndOhs invention - they are simulator assets, and their description is in the SDK documentation of the sim(s).

Their functionality is aircraft specific, you have no guarantee that an aircraft developer is using the default events at all, or how they work if he did. And they are just a small part of the potential controller options, many things are not controlled by sim events but use LVars, HVars or BVars instead - or they require entire RPN scripts.

So when asking for assistance in a forum, please make sure to include information about the simulator and aircraft make and model, and what exactly it is that you want to do.

Edited December 8, 20214 yr by Lorby_SI

2 hours ago, Lorby_SI said:

The "actual events" are not an AxisAndOhs invention - they are simulator assets, and their description is in the SDK documentation of the sim(s).

Their functionality is aircraft specific, you have no guarantee that an aircraft developer is using the default events at all, or how they work if he did. And they are just a small part of the potential controller options, many things are not controlled by sim events but use LVars, HVars or BVars instead - or they require entire RPN scripts.

So when asking for assistance in a forum, please make sure to include information about the simulator and aircraft make and model, and what exactly it is that you want to do.

Thanks for the quick reply. This is much much more about me than AAO's. I thought following the manual would make it easier and it does but I still get stuck on some of the directions. I did see a you-tube video that may be some help. I am a PC dummy !!!

One other question for you. Can I leave my joystick alone (set up thru MSFS) or should I set it up thru AAO's along with the AXAIR ??

50 minutes ago, Tuckster2020 said:

Can I leave my joystick alone (set up thru MSFS) or should I set it up thru AAO's along with the AXAIR ??

Doesn't really matter, you can do it either way. AAO doesn't claim 'exclusivity' concerning the controllers. 

3 hours ago, Lorby_SI said:

The "actual events" are not an AxisAndOhs invention - they are simulator assets, and their description is in the SDK documentation of the sim(s).

Their functionality is aircraft specific, you have no guarantee that an aircraft developer is using the default events at all, or how they work if he did. And they are just a small part of the potential controller options, many things are not controlled by sim events but use LVars, HVars or BVars instead - or they require entire RPN scripts.

So when asking for assistance in a forum, please make sure to include information about the simulator and aircraft make and model, and what exactly it is that you want to do.

Actually, it was an older video you produced back in Oct. 2020. It covers mainly the joystick stuff. Wish there was one that covered the buttons. I'm trying to set up my Axair miap using AAO's. There is one good video showing the setup of the Behringer X-Touch that I may be able to follow. The manual is great, I just get confused with the verbage. Can I assme the "key down event" would be the same as pushing a button AND/OR pushing a rotary button ?? Like the rotary button on the A320 where a "push" is setting it to managed mode and a "pull" is setting it to manual mode. 

Also, there is a video out (by Tumbi T) that says you need to download the profile for the streamdeck A320 even if you don't have a streamdeck ???

FYI, I have the FD on/off button working so I'm making progress. 

45 minutes ago, Tuckster2020 said:

Also, there is a video out (by Tumbi T) that says you need to download the profile for the streamdeck A320 even if you don't have a streamdeck ???

For the more advanced aircraft in MSFS you will need RPN scripts. These downloadable profiles for the StreamDeck or the X-Touch are made for specific aircraft, and they usually come with an XML file containing the scripts that the authors made for that plane - and that script file is all you want. Import it into AAO, and if it already has all you need, you don't have to learn to write RPN scripts yourself.