I'm setting up checklists for the LearJet, and have learned a lot from the documentation and a C172 checklist I found on flightsim.to. 

So far I've been pretty successful with reading the variables and checking to see if switches are turned on, but I do have some problems here and there with trying to get the correct variables from the sim. I guess I'd like to know if there's any tricks or tips for knowing which one(s) are the correct ones? 

For example: the one I'm having a tough time with now is the fuel pumps. I know the switch for the left pump is: (L:GENERIC_LEAR_FUEL_MAINPUMP1_1, Number) and 0/1 for off/on. But I'm having no luck in my script with reading that switch...this is my code: 

(L:GENERIC_LEAR_FUEL_MAINPUMP1_1, Number) 1 == if{ (goto:r_eng_start) }

If I used the observe variables window, I can see this change. 

I've tried a few others such as: (A:GENERAL ENG FUEL PUMP SWITCH:1, Bool) and (A:GENERAL ENG FUEL PUMP ON:1, Bool) but neither work also. I'm guessing with the "index" number as these say the "indexed engine" and I'm assuming it's engine1, etc. In all these cases, I'm not seeing any changes in the observe window. 

I know there's sure to be some trial and error when discovering which variables to use, but I'm really stuck on this one.

Thanks!

 

Edited October 18, 20241 yr by bahnzo

1 hour ago, bahnzo said:

...this is my code: 

Thanks!

The contents of the if{ are wrong, the AAO "GOTO" command must be written in capital letters.

RPN operators and AAO commands are very different and they work differently too. That is why RPN operators are written in lower case and AAO commands are written in capital letters.

The general rules are these:

1.  AAO RPN is case sensitive, you cannot write operators, commands, variables or events any other way than it is spelled out in the manual. When in doubt, use the lists on the RPN Editor where you can select commands and operators (there are separate buttons for each list on the editor window)

2. AAO RPN cannot deal with incorrect space characters. They must be set exactly right, one space between each operand, operator or command, or the script won't work

3. Brackets and parentheses aren't formatting characters, they belong to their respective operators, commands or variables. You cannot use them any other way

 

Edited October 18, 20241 yr by Lorby_SI

1 hour ago, bahnzo said:

In all these cases, I'm not seeing any changes in the observe window. 

Then the aircraft developer decided to work outside of the SDK - nothing you can do about that. If he decided to implement LVars for you to use, then you are in luck. If he didn't create any such information, then that's that. He doesn't have to, if some information is only required inside his own logic, there is no reason to add LVars into the mix.

What aircraft is this? There are as many different implementations as there are developers and potentially aircraft - this is all different from one model to the next.

Edited October 18, 20241 yr by Lorby_SI

57 minutes ago, Lorby_SI said:

The contents of the if{ are wrong, the AAO "GOTO" command must be written in capital letters.

I thought I had double checked for typos, apparently not well enough. From reading the code for the C172, it seems all the variables he uses are of the "A:" type, does this matter I'm trying to use an LVAR, or are these simply different variables and it doesn't matter?

I've been a programmer, albeit on a hobby level, now for 35 years, so I'm pretty versed in coding. RPN is new to me however and requires a little change in thought since it "feels" backwards in it's comparisons.  

54 minutes ago, Lorby_SI said:

What aircraft is this?

This is the Learjet 35A from flightsimware. The devs seem to have put nearly everything into an LVAR; even the curtains in the cabin are settable. 

Edited October 18, 20241 yr by bahnzo

1 hour ago, bahnzo said:

From reading the code for the C172, it seems all the variables he uses are of the "A:" type, does this matter I'm trying to use an LVAR, or are these simply different variables and it doesn't matter?

I'm not sure that I understand the question. They are all different variables. A:, E:, L:, B: etc. are not just an attribute. They are either used and contain a value, or not. LVars are invented by the aircraft developers, A: variables are hard coded into the MSFS SDK:

Simulation Variables (flightsimulator.com)

These are all of type A: and they normally should contain values - otherwise the developer would have implemented the aircraft systems externally, and very few people go there.

1 hour ago, bahnzo said:

RPN is new to me however and requires a little change in thought since it "feels" backwards in it's comparisons.  

RPN is just post fix notated. Think back to when you learned programming, you should have come across the same thing in the past. I remember having to learn machine code/Assembler way back in the eighties, same thing. And quite a few electronic calculators were working this way, especially in business applications - enter first number, enter second number - enter what to do with them - get result

If you are uncomfortable with this, use JScript or VBscript instead, AAO understands those too (see manual). But that is way slower in operation of course. 
(version 4.50 will also have native Javascript)

1 hour ago, bahnzo said:

The devs seem to have put nearly everything into an LVAR; even the curtains in the cabin are settable. 

The native purpose of the LVars is to control the animations. That is why they are there. A developer will only create an LVar when he wants to transport information between modules in his aircraft that is not covered by the hard coded A: variables in the MSFS SDK. In MSFS, the behavior code will read the LVar and then trigger the animation or emissive properties accordingly. It is entirely possible to move a switch by changing the LVar without actually affecting the aircraft system that the switch is supposed to operate. Look closely at the behavior code to make sure that you don't fall into this trap.

For example those curtains - in the behavior code of the curtain, the developer will have created a mouse rectangle. Clicking with the mouse changes the value of the LVar, and the behavior code will also continously read the LVar in another section and will then trigger the animation to open or close the curtains. At least that would be the standard procedure.

Edited October 18, 20241 yr by Lorby_SI

About how to find out about variables etc.

First thing is to check if the aircraft developer made Input Events. These are in a separate list in AAO. You can only see that list when you are sitting in the cockpit, because IEs are loaded from the sim when the aircraft has been recognized. IEs are individual assets for each plane. IEs can be assigned to Buttons and Axis directly, but care must be taken to supply the correct values. IEs can be written to and read from. BVars are related to them, usually, when there is an IE there is a BVar of the same name. BVars have their own logic and might be more useful in certain situations.

If there aren't input events, use the MSFS developer mode to look at the models' behavior code:
- Activate the Developer Mode
- Open "Tools->Behaviors"
- Click back into the simulator window
- Hover the mouse over the knob/switch/lever that you are interested in and press "Ctrl - G"
This will bring up the behavior code for the item in the dialog. Look for the "...Interaction..." components first, usually at the bottom of the list. These contain the RPN code that is triggered by your mouse actions, and that is what you want to replicate in AAO. 

Edited October 18, 20241 yr by Lorby_SI

8 minutes ago, Lorby_SI said:

About how to find out about variables etc.

Thanks. I've learned much of that already from reading your previous posts in the forum. Very helpful. 

Edited October 18, 20241 yr by bahnzo

Instead of making a new thread for every little question I have, I hope it's ok to just add to this one....

Is there a variable for your ATC clearance altitude? I don't see one, but maybe it's called something else? There's one called (A:ATC CURRENT WAYPOINT ALTITUDE, Bool) but it doesn't return a Boolean, and it's actually a really high number in the case I'm looking at now...over 100k so hmm?

Also: is there a way to declare variables and store something in them so you can check it later in a script?

Finally: is there any significant performance hit if I tell the script to watch for something for a long time? IE: if I tell it to watch for my descent past 18K so I can start a checklist?


I think I enjoy writing the checklist more than I do flying, there's some cool stuff you can do with AAO in this regard. 

Edited October 20, 20241 yr by bahnzo

2 hours ago, bahnzo said:

Is there a variable for your ATC clearance altitude? I don't see one, but maybe it's called something else? There's one called (A:ATC CURRENT WAYPOINT ALTITUDE, Bool) but it doesn't return a Boolean, and it's actually a really high number in the case I'm looking at now...over 100k so hmm?

No. ATC is a black box. What do you need it for? 

2 hours ago, bahnzo said:

is there a way to declare variables and store something in them so you can check it later in a script?

That is what LVars are for. They don't have to be declared anywhere, they begin to live when they are first used. Make sure to read the section in the AAO manual about LVars. If an Lvar is only used in your scripts, it doesn't have a Unit (L:myinternalvar). Only when you need this LVar somewhere else in the sim, you provide a unit (L.simlvar, Number). Exception: (L:somestring, String) String - LVars are always internal. The distinction between internal LVars and sim LVars is important, because every simulator LVar will add to the load of the interface to the sim, and you don't want that to happen needlessly. Also check out the section about Arrays and Hashmaps in the manual. And the part about Registers, they are very helpful in RPN scripts.

3 hours ago, bahnzo said:

Finally: is there any significant performance hit if I tell the script to watch for something for a long time? IE: if I tell it to watch for my descent past 18K so I can start a checklist?

Depends on how you are doing that. There are several mechanisms available for doing that kind of thing, but flight following/virtual FO/virtual attendant are usually implemented using CONVERSATION type script files. There are some AAO testers who have built very extenisve logic with that, spicing up their flight with a virtual flight crew and whatnot.

 

3 hours ago, bahnzo said:

(A:ATC CURRENT WAYPOINT ALTITUDE, Bool)

The unit for that is probably "Feet"? Simvars don't have fixed units, the simulator will convert them internally. If it can, I doubt that there is a valid conversion between a numerical value and bool.

Simulation Variable Units

For example the first table "Length": in general, you can use any one of those units with a variable that contains a distance or altitude. (A:PLANE ALTITUDE, meters), (A:PLANE ALTITUDE, feet), (A:PLANE ALTITUDE, inches) etc...
There are some exceptions, where that conversion doesn't work, but the simple one usually do.

 

Edited October 20, 20241 yr by Lorby_SI

1 minute ago, Lorby_SI said:

No. ATC is a black box. What do you need it for? 

I was hoping to simulate the copilot entering altitude clearances when ATC gives them. 

 

 

3 minutes ago, Lorby_SI said:

That is what LVars are for.

I think you misunderstood me maybe. I'm wondering if I can store a value in my own declared variable. I have a couple places where it would be easiest to compare a couple LVAR and store one in a variable for use so I don't have to constantly compare them. There's surely a workaround for what I want to do, but being able to simply store the value in a variable would be easiest. 

 

 

6 minutes ago, Lorby_SI said:

Depends on how you are doing that.

I'm thinking about using something like [(A:Altitude, feet) 18000 <] to start the descent checklist. But I have no idea if having that sitting there the entire flight (maybe hours even) would cause any sort of issue. If so, then it's easy enough to use the voice commands, but I've been using it for takeoffs, 10k checklists, etc and it works very nicely to have AAO watching your altitude (or speed in some case) and react like a copilot when certain criteria are met. 

6 minutes ago, Lorby_SI said:

The unit for that is probably "Feet"?

I tried changing it to ,Feet and didn't make a difference. Something weird in MSFS maybe. I'll bookmark that sim variables page tho, there's good info there I was looking for earlier. 

1 minute ago, bahnzo said:

I think you misunderstood me maybe. I'm wondering if I can store a value in my own declared variable. I have a couple places where it would be easiest to compare a couple LVAR and store one in a variable for use so I don't have to constantly compare them. There's surely a workaround for what I want to do, but being able to simply store the value in a variable would be easiest. 

?? As I said, that is what LVars are for. You can just create your own at any time, using whatever name you fancy.

100 (>L:mylvar)

in another script: (L:mylvar) 100 == if{...

1 minute ago, Lorby_SI said:

?? As I said, that is what LVars are for. You can just create your own at any time, using whatever name you fancy.

100 (>L:mylvar)

in another script: (L:mylvar) 100 == if{...

Ok, that'll be great then. I was under the impression LVARS were only declared by the dev of the plane for us to read. Being able  to create my own will really open up some ideas I had then. Thanks!

1 minute ago, bahnzo said:

I tried changing it to ,Feet and didn't make a difference. Something weird in MSFS maybe. I'll bookmark that sim variables page tho, there's good info there I was looking for earlier. 

I would assume that this variable will contain a value when you are in the air following the flight plan = when there is a "current waypoint". There is a similar variable in the GPS section.