I am currently running through all my plane types and try to configure everything I need.

Condition Lever

For normal single Prop planes, I mapped "Mixture 1" to one of my axis and can move the Mixture lever fine.

When I switch to a Turbo Prop (like the 208), I expected the Condition lever to move with the same axis and setting, but it does not.

When not using A&O, within MSFS I only configured Mixture to that Axis and it works for both Prop and Turob Prop planes. I also can not find something remotely named Condition or Cond in the A&O Axis lists. I am sure I am missing something and this is an easy fix.

 

Toggle Reverse

In MSFS default settings I configured 2 Buttons called Propeller Reverse Toggle and Throttle Reverse Toggle. It works like this: You pull back on your Throttle / Prop until idle, press the Toggle switch and then you advance the Throttle / Prop axis again and MSFS moves it back into the Reverse / Feather positions. To get out, you pull back on your Axis again and press the Toggle button.

Within A&O I defined the PROPELLER_REVERSE_TOGGLE and THROTTLE_REVERSE_TOGGLE to 2 different buttons, but I can not get it to work as expected. No matter if I press the Toggle Buttons or not, the Throttle and Prop Axis always move in the same range (that is all above Reverse / Feather).

Can I check in the Sim (Dev console?) if the Event gets even forwarded to MSFS?

1 hour ago, buedi said:

within MSFS I only configured Mixture to that Axis and it works for both Prop and Turob Prop planes.

What you can do in MSFS has nothing whatsoever to do with what the sim let's us do over SimConnect. You cannot compare the two methods. What you see in AAO is what the SimConnect API offers, and it works as per their spec.

Condition levers
With the 208 you will have to map a BVar with the "Lvar to Bvar" feature in AAO.
Here is what I did:
LVar : (L:AAO_Fuel_1_Condition_Lever, Number)
BVar get: (B:Fuel_1_Condition_Lever)
Bvar set: (L:AAO_Fuel_1_Condition_Lever, Number) (>B:Fuel_1_Condition_Lever_Set)

And a script to make use of it:
Script Group: C208
Script Name: Condition
Script code: (L:C208-Condition)·(>L:AAO_Fuel_1_Condition_Lever,·Number)

That script is then assigned to the lever.

Toggle Reverse:
AAO doesn't work like that. I think that you would have to create an RPN script for this action. ( As written above - whatever you can do with MSFS controller assignments has ZERO bearing on what SimConnect = AAO lets you do. When in doubt, keep the assignment in MSFS, AAO can be run in parallel).
Then again, I don't know what that toggle button does in MSFS. Maybe there is a SimConnect Event that you could use (=assign to a button) that effects this toggle. PROPELLER_REVERSE_THRUST_TOGGLE and THROTTLE_REVERSE_THRUST_TOGGLE sound good. But they may be indexed, so if they don't work with a direct assignment, you need (you guessed it) an RPN script in AAO. Indexed events are called like this: x y (>K:2:INDEXED_EVENT_NAME)
(I am assuming indexed because there can be more than one throttle lever)

Edited April 24, 20224 yr by Lorby_SI

Thank you very much for your samples. I will try that!

And sorry, I was not aware that it works like this. I had the impression a button assignment within MSFS also just triggers one of the Variables, but in the last hour I also found out that the Vars from the SDK documentation are not exactly the Vars we have in A&Os (at least naming wise). There's a lot to learn!

I have seen the LVar to BVar topic in the Manual, time to dive in I guess 🙂

5 minutes ago, buedi said:

the Vars from the SDK documentation are not exactly the Vars we have in A&Os

Those should be the same, the lists of variables and events are built automatically from the SDK documentation.

What doesn't correspond are the variables from the SDK and the actions in the MSFS controller assignment dialogs. That is probably because MSFS uses BVars more and more - and those cannot be accessed from the outside (only with a dirty hack - which AAO provides) The MSFS controller dialog can map the input to whatever internal asset - but a SimConnect client can't, they didn't give us the option. Most prominent example: the Camera controls. Those are even present in the SDK doc, but they don't do anything.

Edited April 24, 20224 yr by Lorby_SI

45 minutes ago, Lorby_SI said:

Those should be the same, the lists of variables and events are built automatically from the SDK documentation.

I did not dig deep enough yet, my first few attempts were with the Fuel Pump system and I tried to match them between A&O and the SDK Documentation. But then SimConnect probably exports them different than what is mentioned in the Documentation (or I use the wrong Documentation).

One Example is here: https://imgur.com/a/m24v3c9

(Edit: I just found out that in the MSFS SDK what I need is not in the Aircraft Simvars Chapter, but in the Event IDs Chapter, at least I see matches there!)

But since I can run A&O + the Sim in Parallel and can test every change as I make it in A&O, that makes it easy to try a few and see what happens. Much better than exiting into a Menu, change something, get back to the Aircraft etc. 🙂

 

I have just seen your edit about the Reverse Toggle! Totally missed that. Another reason to dig into the Scripts. And what you suspect makes absolute sense. The reverse toggle should work for multi-engine Aircrafts too, so it is highly likely that it needs an index!

Edited April 24, 20224 yr by buedi

34 minutes ago, buedi said:

One Example is here

You are comparing the wrong things there. The list on the left are sim Events (>K:WHATEVER), but the list on the right are sim Variables (A:WHATEVERVARIABLE:Index, Number). Like in the old days, sending an event changes the value of the variable associated to the event. And to read the state of that aircraft system you can only use the variable, not the event. You cannot assign sim variables to a button directly, they are not "actions", they represent "values". If you want to change a variable, you have to wrap them into RPN scripts ("34 (>A:whatever, Number)"). And that only works if that variable can actually be written to, which is not the case with the ones that you posted (hence the red symbol in the last column). You can only use those in a script or a gauge to determine the actual state of the system that they represent. When a variable can be written to, there is a green checkmark in that column of the SDK Spec. What you need to look at in the MSFS documentation are the lists below "Event IDs", not "Simulation Variables".

For reference, open "Scripting -> RPN Scripts Editor", press "Insert sim var" and filter for "pump" in that list.

"Automatically" was the wrong word. The lists in AAO are actually hard coded. The process to make those lists is automatic, but I have to do this in development.

You can add missing events and variables manually (Scripting->Input Events and Variables manually) or wrap them into an RPN script. 

Edited April 24, 20224 yr by Lorby_SI

2 hours ago, Lorby_SI said:

And a script to make use of it:
Script Group: C208
Script Name: Condition
Script code: (L:C208-Condition)·(>L:AAO_Fuel_1_Condition_Lever,·Number)

I start to feel really ashamed to ask. Your sample does indeed move the Lever now in the Sim. I also read the LVar to BVar part of the manual and was able to hook everything up so far.

The only thing I do not understand yet ist what the (L:C208-Condition) does. From where does it gets its value? If I leave it like that and assign it to a button or axis, checking the LocalVariable via the Dev Mode, the Variable AAO_Fuel_1_Condition_Lever gets set to 0 and the "Condition_Lever_CutOff_1" variable is set to 2, which results in High Idle (no Idea why it is in reverse btw).

If I change your line to:

0 (>L:AAO_Fuel_1_Condition_Lever,·Number) = that gives me High Idle with Condition_Lever_CutOff_1 set to 2

1 (>L:AAO_Fuel_1_Condition_Lever,·Number) = that gives me Low Idle with Condition_Lever_CutOff_1 set to 1

2 (>L:AAO_Fuel_1_Condition_Lever,·Number) = gives me Idle Cut Off with Condition_Lever_CutOff_1 set to 0

I am sure your thinking was that if I add that Script to an axis, the L:C208-Condition gets filled with a value when the Axis travels a Distance X. But I can not figure out how to fill the L: Variable with the values.

I could, however, create 3 Scripts now and assign each to the Axis I want and make adjustments with the blue Triangles, but I have the feeling there is an easier solution and transfer values from axis movements directly to the L:C208-Condition variable, right?

25 minutes ago, buedi said:

I am sure your thinking was that if I add that Script to an axis, the L:C208-Condition gets filled with a value when the Axis travels a Distance X. But I can not figure out how to fill the L: Variable with the values.

Right. Sorry, I forgot about that. In my axis configuration, Axis Min is 0 and Axis Max is 2. The BVar isn't actually an axis, it only has those three values. IIRC you cannot set the lever to positions between these three detents in the VC either.

25 minutes ago, buedi said:

The only thing I do not understand yet ist what the (L:C208-Condition) does

That is the script variable, (L:groupname-scriptname), should be on page 39 of the manual. It is AAO internal, you cannot see it in the sim. If an LVar in the AAO RPN script doesn't have a "Unit" like ", Number", AAO treats it as an internal variable and doesn't send it to the sim at all. Very useful if you do a lot of script programming. You don't want to flood the sim interface with variables that the sim doesn't need).
And yes, the script variable gets its value from the control that actuates it (axis or button). In this case I forgot that there are in fact only three values to begin with...
 

 

Edited April 24, 20224 yr by Lorby_SI

37 minutes ago, Lorby_SI said:

Right. Sorry, I forgot about that. In my axis configuration, Axis Min is 0 and Axis Max is 2.

That is what I thought, adjusted it and it did not help... but...

 

Quote

That is the script variable, (L:groupname-scriptname), should be on page 39 of the manual.

Now it clicked! Groupname-Scriptname... you did not just pick a random name for the Variable, it depends on how you create / name your Scripts! Silly me named my Script different than you did in your suggestion, that is why I could not figure out how that Variable can be filled at all. I changed the Variable to reflect my Group and Scriptname and now all comes together 🙂

Apart from the LVar to BVar chapter, I only was on page 31 yet. I should have read quicker. Now everything makes sense.

It blows my mind how much functionality you stuffed into Axis and Ohs. Genius!

 

Thank you for your patience. I learned a lot and I think I got the basics now to further refine my Templates.

One last question: A&Os crashed a few times today while clicking around in the GUI and 2 times when I stopped the Simulator. The Event Log messages sometimes show a .NET Stack, but I guess those are not super helpful. Does it make sense to send you information about crashes and if yes, what kind of information could help you when I encounter one?

There is FSUPIC who managed somehow to define an axis for reversers or an individual reverser for each engine if you wish.

Real airplanes that have reversers don't use buttons to activate or push forward thrust levers. You actually modulate linear the amount of thrust from idle to whatever value you need, the same idea as you wish to compare with prop rpm (as an example).

That's the disappointment for me regarding A&O Axis software and thats where also ASOBO doesn't get it.

EvenP3D and others have a reverser axis and you can modulate properly the amount of reverse needed.

Unfortunately using FSUPIC together with A&O Axis software to compensate for this issue will lead to some undesirable conflicts.

Edited April 24, 20224 yr by LRBS

11 minutes ago, buedi said:

Does it make sense to send you information about crashes

At the moment, no, it doesn't. 2.29 is not too far off, and that will have some changes regarding the simulator interface stability. 

But - this is not something that everybody sees all the time, I had just a handful of requests about stability. To be on the safe side, got to Hardware->Device Blacklist and move everything to the right with the "Ignore" button that isn't a controller that you want to use with AAO (that includes the Keyboard and the Mouse, leave only the game controllers). And if you are using extra controller software like Corsair iCue, that can be troublesome too.

Edited April 24, 20224 yr by Lorby_SI

15 minutes ago, LRBS said:

There is FSUPIC who managed somehow to define an axis for reversers or an individual reverser for each engine if you wish.

Depending on how the reversers work on a specific plane, you should be able to do the exact same thing in AAO. I can't see any reason why that shouldn't be possible. You "only" have to find out how the aircraft does it (aircraft models tend to be very different in terms of controller operations in MSFS) and replicate that, either through configuration or RPN scripts.

I have Saitek TQs, so I am mapping the reversers to the lever's button function that actuates when you pull it past the detent. Works absolutely fine and individually for each engine too.

Edited April 24, 20224 yr by Lorby_SI

6 minutes ago, LRBS said:

That's the disappointment for me regarding A&O Axis software

Sorry to hear that. But in 4 years you are actually the first person saying this. So I'm not really sure what to make of it - I wasn't aware that a problem like this even existed. 

I am using RPN scripts for the Throttle/Prop reversers where I directly set the position value, that way I can also make sure the reversers are not engaged when the axis is not at the bottom (which would be possible for example with the commercial levers of the HC Bravo).
For throttle the value for full reversers can be read from "A:THROTTLE LOWER LIMIT", but I can also override it with the value passed to the script. Best way to get the value for prop reverse is to pull the lever in the VC to the minimum and check the value of e.g. "A:GENERAL ENG PROPELLER LEVER POSITION:1", depending on the plane (if it has a prop reverse) it's usually somewhere between -2000 and -4096.

Examples:

 -- Reverser-REVERSER_1_ON --
(A:GENERAL·ENG·THROTTLE·LEVER·POSITION:1,·position·16k)·100·<=·
if{
(L:Reverser-REVERSER_1_ON)·0·==·
if{·(A:THROTTLE·LOWER·LIMIT,·position·16k)·}·
els{·(L:Reverser-REVERSER_1_ON)·}
(>K:THROTTLE1_SET)
}
 -- Reverser-REVERSER_1_OFF --
(A:GENERAL·ENG·THROTTLE·LEVER·POSITION:1,·position·16k)·100·<=·
if{
0·(>K:THROTTLE1_SET)
}
 -- Reverser-REVERSER_P1_ON --
(A:GENERAL·ENG·PROPELLER·LEVER·POSITION:1,·position·16k)·100·<=·
if{
(L:Reverser-REVERSER_P1_ON)·0·==·
if{·-4096·}·
els{·(L:Reverser-REVERSER_P1_ON)·}
(>K:PROP_PITCH1_SET)
}
 -- Reverser-REVERSER_1_OFF --
(A:GENERAL·ENG·PROPELLER·LEVER·POSITION:1,·position·16k)·100·<=·
if{0·(>K:PROP_PITCH1_SET)}

 

22 minutes ago, buedi said:

Does it make sense to send you information about crashes and if yes, what kind of information could help you when I encounter one

Having second thoughts.

If it happens a lot and if you get your hands on a stack trace, please send that over, so I can take a look at it.