Making flying airliners simple and straight forward even for new simmers. New FVC Tool

Discussion Hub Tools & Utilities
, ,
1

Hello fellow simmers.

I made this tool that makes flying an airliner and following the rules fairly easy for anyone even if you haven’t used a specific aircraft before, because it also comes with custom flight guides that shows to you in detail what to do, and when to do it. It is also 100% flexible regarding what you may choose to do your own way. This tool offers a hand that’s waiting for you to call it when you need it, not a compulsory guideline and flight style.

Here’s a video that explains what FVC is all about:

It requires a base software named “VoiceAttack” though, but it is not too expensive. You can find it in Steam or in their web page.

My tool FVC involves a plugin for VoiceAttack and various profiles for each compatible aircraft, besides the proper guides to fly and a user manual with all the information required to fully understand its usage.
The current version of this tool is actually free since i offer a patreon 7 day trial and once you download the content it is forever yours. If you want to keep an eye on future updates and be able to download them you are going to be charged though. It is pretty cheap, at $3 a month (you can unsubscribe whenever you want and keep the downloaded content). I need a way to justify all those daily hours dedicated to this at home :see_no_evil:

It is currently compatible with the following aircraft, but as more updates come, more aircraft are going to be added into the list:

-FBW A32NX
-FENIX A320
-HEAVY DIVISION B787
-PMDG 737
-SALTY B747

Here’s my patreon page:

And here’s the product announcement thread:

If you try it i truly hope you like it, and i’ll be happy to answer any previous concerns about it over here.

Cheers!

1 Like
2

Hello. Actually using MSFS addon for VA. I was trying to get two things, one of them you have implemented it, the other one no: Copilot saying V1 and Rotate at the right speed when taking off is perfect, but I want to get advice of the transition altitude for setting STD barometer and 100000 feet for turning lights off when ascending, and the transition level when descending for setting again the barometer to local QNH . I was looking at your profile and in the ready to take off flow you use “L:AIRLINER_V1_SPEED-G”, “L:AIRLINER_VR_SPEED-G” and “A:Airspeed_Indicated” and I can´t find those variables we introduce in the FMCDU in the simconnect SDK, How do you know that variables or where do you find them? Is it possible to get the “transition altitud variable” and “transition level variable” too?

3

Hi!, if you want to find out available variables i would advise you to enable MSFS dev mode. Then, while in the plane, click “tools” in the upper horizontal dev bar, then “behaviors”, and select “LocalVariables” tab. You’ll see then a list of every local variable set by the plane. The L type variables regarding V1 and VR speeds can be found in here, and their value is 0 until you set these speeds in the MCDU. “Airspeed indicated” is a an A type simulation variable (SimVar) that should be available through simconnect.
About the transition altitude and level, you can also find these as L type variables, which are not set (value = 0) until they appear as set in the MCDU. For example, in the case of the A32NX they are called “AIRLINER_TRANS_ALT” and “AIRLINER_APPR_TRANS_ALT”.
Now about the possibility of monitoring them, i want to first remark an important thing. VoiceAttack is not capable of detecting a variable change unless it runs a specific command that is programmed to keep monitoring that variable during the whole required time. In this case, is not possible to get a voice message unless we create a command that keeps monitoring the transition altitude and level variables during the whole flight. I’ve been reluctant to create such long duration commands because at the moment this command gets stopped for any reason, you would have to trigger it all over again in order to keep monitoring.
I see two solutions. One is to add this task into an existing command. This command could be the same “ready for takeoff” command, that after calling out the acceleration altitude keeps monitoring the altitude and calls out the transition altitude, and then the transition level. This would mean the “ready for takeoff” command would be active almost through the entire flight. The downside is that if it gets stopped for any reason, it would start all over again from the V speeds monitoring.
Another solution is to make new independent commands that can be dedicated specifically to monitor the transition altitudes. They would have to be triggered manually in the command list, or by some voice phrase. One of them could be triggered by a phrase after the after takeoff checklist , and the other could be triggered by a phrase when the descent phase starts.
If you have other ideas i’m all ears. Tell me if you want to test any of these possiblities and i can create the command and hand it to you if you want.
Cheers!

4

Oh man, I see you have very good knowledge about this. I basically use the method “test-error”, haha. I didn´t know about the dev mod and variables list you talk about in your first part of your answer. I will give a look at it as soon as I can, sure. About the “notification heights” thing, I have various thoughts. First, I have configured my profiles in a different way than you, because as I said I use the msfs addon for Voiceattact disponible online. But apart of that, I have been thinking before about how to trigger those commands. As you say, they have to be active to “listen” for the heigh changes, but buy say that means they have to be active almost the whole flight. I don´t think that. First, I explain how is the reality here in Spain: Transition altitude in the whole country is 6000 ft, but only Madrid airport and another one that I don´t remember now that use 13000 ft. Transition level is TA of destination airport+1000 ft, so almast always 7000 ft. Then at 10000 ft ascending you turn off the take off lights, and at 10000 ft descending you turn on the landing lights. So basically, that part of the command only is active until you reach 10000 ft ascending, and I think you get that altitude very fast, let´s say less than 10 minutes? What is the problem? None, because no other action is executed until you get the cruise altiitude, when you make the cruise checklist. Descending is where you have the command active more time, because you have to descend (normally slowly, open descent mode) from maybe 36000 ft and monitore it until 7000 ft. But again , no problem because you start your approach checklist below 5000 ft, so the command will not interfere with other. How to launch it in the ascent part of the flight? If I change all my profiles and adapt the config to use your plugin, not the one I use, and use your profiles mode, I think the best way to do it if at the end of the “ready for take off” command make a call to this new command that monitores the ascent. So if the system crashes it doesn´t trigger once and once. About the command for the descent profile, maybe I would trigger it saying " Top of descent - Checked" or something like that. Oh, and another variable I nedd to know if it exists if the moment when you retard thrust levers from TOGA or FLEX to CLIMB position. If I can obtain one variable of that moment I will try to modify your “ready for take off” command, and after the “positive rate - gear up” I would insert the voice advise used here of " thrust climb - climb" instead the “acceleration altitude” you use, because that´s not used here. If you have time and can help with the sequences for this it would be awesome, but no problem, you have helped me A LOT with your commands at this point. And thanks for your job. It can help a lot of people.

5

I agree the method you describe could be the more appropriate way to implement this.

Download the following document:

This is a profile for VoiceAttack. In VoiceAttack select the profile for the A32NX and then within the Edit window press the “Import command” button at bottom left. Then select the file i handed to you and import both commands.

One of them is to call out the transition altitude, and the other one to call out the transition level.
I haven’t tested them but i think they should work fine. They also include a reaction in the case you trigger them at a wrong altitude. For example if you ask to call out transition altitude when you are already above transition altitude, it will say “Already above transition altitude” and will exit the command.
If you trigger them at a correct altitude, it will check every 5 seconds and compare the indicated altitude of the aircraft and the registered transition altitude/level. You can change this monitoring time, but i believe checking every 5 seconds should be enough.
Once it reaches the altitude the monitoring pilot voice will call out “Transition altitude” or “Transition level”.

If you want you can add the transition altitude command to be executed at the end of the “ready for takeoff” command as you said. I think it’s a good idea. Also you can modify the triggering phrase to whatever you prefer.

About the thrust position, i’m not sure yet about the variables that can save that FMA indication. I can’t check on it now, i’ll do it later. But what i can say about it is that the “Acceleration altitude” triggers when the altitude above ground reaches 1500 ft, which is to my understanding the exact moment when the throttle should be set into climb detent. If this is true, you don’t need any other variable. Just edit the command and change the Text-to-voice part from saying “acceleration altitude” into “thrust climb, climb” or something like it. If the moment of acceleration altitude results to be different to the moment when the FMA advises you to change the throttle detent, tell me and i will search if there’s such variable.

Cheers!

6

Hi. I have imported your commands into VA, not tested yet in the sim, but looking at the sequences it seems to be perfect, should work, only on thing, I think you forgot to put an “Exit comand” at the end, between the “say transition altitude” line and the “end condition” line. Maybe it´s not neccessary?? I think , when there are loops it´s good to use it to avoid problems. But, once again, maybe I´m wrong and it´s not neccessary. Along the day I will test your commands and I´ll post my conclusions here later. I will try to go further and implement inside these two commands the notification of 10000 ft to turn on and off lights. I don´t know if I will reach it, but I´m trying. I think I have a problem with it: Normally after the loop where you monitor “A:Indicated_Altitude” lower than TA I would add another loop monitoring it to be lower than 10000 and then the voice announce on 10 thousand and it should work because normally (here, in Spain) first you reach 6000 feet and then 10000. But I have the problem of Madrid airport. There, the TA is 13000 ft, so you reach first the 10 thousand advise and later the TA, so this sequence won´t work. I have to figure out how to modify the loops to monitorize “A:Indicated_Altitude” against TA and 10000 at the same time, and when you reach one of them say the right voice announcement and still wait for the second altitude to trigger it´s right voice announcement and finally exit the loop and exit the command. With my “test-error” method this is going to take a long time, but I´ll try.

Another thing that I have been thinking is to automatize the launch of your transition level command. Yesterday I said one posibility was me saying " TOD-Check" but the light iluminated over my head and this is what I thought: When you start your descent first of all you turn on the seatbelts sign, so we can monitorize that switch and then monitorize if there is a negative vertical speed of more than 100ft/min. If both variables are OK then trigger the command. If only switch is On but no descent then exit the command. This is because in flight you can turn ON the seatbelts when there are turbulence but you don´t descent. At this moment I don´t know if the MSFS emulates the turbulence, I still didn´t flew with bad weather. If it´s not emulated then that comparison is unusefull because you don´t turn on seatbelts in cruise because no turbulence and you can trigger the command when “plane on air” and seatbelts ON, but if the game emulates it, then the double check of “switch and negative speed” is neccessary. I don´t know what more problems could happen with this way of activation the descent monitoring command, maybe you see any problem on it.

At the moment this is all. Later I´ll test your commands and tell my impressions. Thanks again for your help.

7

I forgot to talk about the 1500 ft AGL notification: You say it could be used to notify the “thrust climb - climb” advise, and I think you are right. Only two thing about this: The climb advise is a company procedure and it varies between 1000ft and 1500ft but almost always 1500ft, so you´re right, we could use it for the climb advise. But if you use a performance calculator like this one (perfcalc . pradz . de/) we obtain values in the THR RED / ACC fields that don´t match with that sometimes. I don´t know why, because you introduce the ICAO and it knows the height of the airport and shoul add 1500 to it, but I have noticed that happens sometimes. So if someone uses that parameters for the MCDU the advise won´t match with the moment of the thrust lever change. BUT I think this is a very minor thing. Personally I don´t change that values and I use the ones that are defined in the MCDU when you enter in that menu, that basically are what you say, 1500AGL. So for me it´s OK to use your take off command as now, only changing the voice anouncement. I only wanted to advise it.

8

Tested wour commands and 2 problems found: First, the variable “A.Indicated_altitude” can´t be found by VA. I have been looking for something in the list of Developer mode, and at the moment only found “A32NX_EGPWC_PRESENT_ALTITUDE”, Tested it and same result, value can´t be found (log of VA). Second error: Made a flow for test purposes with V1, Vr, V2 TA and actual height that writes in the log this parameters. The first time I execute it works but the height (because of the problem comanted before). If I execute the flow a second time it breaks and returns the value for TA in V1 and VR, and if you double click the line ""execute external plugin… to modify the height variable you obtain first an overlapped message box saying: “The plugin that is referenced by this action is not valid for this version of VA. The plugin is available for selection, however, if you try to run this plugin it will fail.” Then click on OK, and the window for edditting it appears normally. So I´m very confused at this point. My version of VA is the last one available for download, and paid registration. So, as I say, I´m very confused at this point.

9

Hi! sorry for taking this long to respond, my job kept me too busy.

I’ll do my best to answer all of your questions.

“I think you forgot to put an “Exit comand” at the end, between the “say transition altitude” line and the “end condition” line”

-As you say, it is not necessary since there’s no more actions after saying “transition altitude”, so the command exits on its own after this action. Previously in the sequence i added a command exit. I realize not that this action it’s probably unnecesary, since the command was going to exit on its own after saying “already above transition altitude”.

“When you start your descent first of all you turn on the seatbelts sign, so we can monitorize that switch and then monitorize if there is a negative vertical speed of more than 100ft/min”

-I believe your idea is basically that the command to monitor the altitude gets triggered when using the seatbelt sign switch. VoiceAttack can trigger a command in two ways: One by voice command, and the other by pressing a button on some peripheral hardware (keyboard, mouse, joystick).

image

The issue with this seatbelt sign idea is that as i explained earlier, the plugin is not constantly monitoring something unless you command it to do so. So you either assign a key to the seatbelt sign light (which will trigger the command EVERY time you press that key, so it renders the command unusable), or you create a voice command to start monitoring the seatbelt sign switch (which is also an extra unnecessary step if you consider to better make directly a voice command that monitors the altitude, like the “call out transition level” command i shared with you). Another alternative would be to make the “Ready for takeoff” to monitor the seatbelt sign switch at the end, but in this case it would be better to just make it monitor the transition level directly.

-About the acceleration altitude we could just take the variable for THR RED from the MCDU and make the command to say the acceleration phrase when it matches with that one. Thanks for bringing this up. I also agree it is a minor thing but i didn’t thought of it a lot. I will pay some more attention to it.

“the variable “A.Indicated_altitude” can´t be found by VA.”

-You are right, there was a little update required in the VA plugin from my part in order to be able to process that specific SimVar. Please re-download from patreon and reinstall (BEWARE, backup your custom profile because you will re download the default aircraft profiles). The only file required to be replaced is “MSFS-FVCplugin.dll” in any case, so you don’t need to reinstall the whole folder.
Now my commands for altitude monitoring will work.

Please refer to these two new commands i made. They callout transition altitude/level AND set the external lights at 10.000 for above or below. It is divided into three cases: TA/TL is above 10000ft, TA/TL equals 10000ft and TA/TL is below 10000ft. In each case, the order at which monitors TA/TL for calling out transition and monitors 10.000ft to trigger the external lights, varies.
Haven’t tested them yet.

Cheers!

10

About the THR ACC issue, i realize there’s no variable available for these MCDU numbers, so it will be impossible to get these numbers in order to use them with the “Ready for takeoff” command. The only way that i can think of is to create a command that makes the user to manually input these numbers in VA, and then use them in the “Ready for takeoff” command. If no new acc altitude is input, then the command can take a default number, (for example 1500).
Just an idea.

11

I have been fighting with this the hole day. Finally I found the right variable for height: " A:Plane_Altitude ". This variable reports real plane altitud (not above ground, baro altitude) wich is the altitude needed to check against 10000 ft and TA altitude. I will update the plugin dll and import your new flows to test them, but not today, better tomorrow, and I´ll report after testing them. I have made my own flows, not tested yet in the simulator (another work for tomorrow). If you can take a look at them and tell your opinion would be great. I insist, not tested in the simulator, maybe they don´t work. I´m sure it´s not the best way to code, and as I read your post I have made it in a different way then you. But tomorrow I´ll test them. The ascent flow will be triggered at the end of your ready for takeoff flow, and the descent flow, at the moment I will say “Top of descent reached” to trigger it. One thing that I was thinking and didn´t implement is to clear the variables I used in the flows before exitting the flow, because I think that if you land and program a new flight instead quitting the game, the variables will be in the wrong state at the begining of the new flight and it wont work. Tomorrow I´ll think a bit more about it.

I can´t include links (don´t know why, so yu have to edit the spaces in the link to get my profile for testing)

drive . google . com /file/d/1ekPHP9r0b3T2XM8vE5VSOCkXHuC8k87A/view?usp=drive_link

12

About the thrust reduction, tested today it doesn´t match with the moment of thrust reduction to climb position, so if I don´t find a variable that matches and adapt your flow, I will dismiss using the announcement, and will monitor the PFD for the request of retracting the levers.

I think I have seen those variables you say in the list (thrust reduction) . Tomorrow I will recheck if I find them again. Another interesting variables I found are A32NX_DECISION_HEIGHT (radioaltimeter field, for CAT 2 and 3 approach)
A32NX_MINIMUM_DESCENT_ALTITUDE (barometer field, for CAT 1 approach) . Maybe they are interesting for automatize the go around procedure or something like that.

I still don´t understan why you add L or A before your variables and it´s meaning. And also you add “-G” at the end of L:AIRLINER_TRANS_ALT, when I remember I have seen that variable in the list today and it comes without the L and G. Tomorrow more tests, your new modifications and the mine ones. Thanks for your time. Tomorrow will update with the results.

13

“One thing that I was thinking and didn´t implement is to clear the variables I used in the flows before exitting the flow, because I think that if you land and program a new flight instead quitting the game”

-This is correct, and it’s the reason why my commands always set the VA variables to be used within the command before evaluating or using them for manipulating sim variables. There’s two variables that my commands use the most (MSFS.ValueSet and MSFS.ValueGet). If i execute a command that uses these before setting them, and they come wrongly set after a previous command, the command could not work the way it should.

Now about the PLANE_ALTITUDE SimVar, it is to my understanding that this variable delivers the true altitude of the plane within the sim, and NOT the indicated altitude in the primary flight display. This last one should be the one used when a pilot evaluates the altitude, since that’s the altitude information he can count on. That’s why i used the INDICATED_ALTITUDE SimVar, but my guess is that there’s not going to be a great difference between both altitudes, so it’s probably a minor thing.

Cheers!

14

I wouldn’t automate the go around procedure based on decision height because that should be the pilot call. And when he decides at that height to go around he should say “go around” or “execute missed approach” or something like this. There’s a “Go around” command but at the time it only raises flaps and landing gear when you call it. It could be extended to do more things.

The L or A nominations are the variable type. MSFS deals with multiple variable types, the ones that are mostly used are local variables (L type), SimVars (A type), key events (K type) and html events (H type). The letter tells my plugin what to do to get or set that variable in specific, since each one is handled in a different way. There’s other variables that can’t be accessed like O and B type, and a lot of other things inside the cockpit aren’t translated into variables so it’s impossible to manipulate these kind things, like for example the THR RED number within the MCDU that i told you earlier.
If there’s actually a variable that changes when the FMA advises climb that would be a perfect variable to be used for that matter. I forgot to search that.
The “-G” part in a local variable context means that i want to get the actual value set in that variable and save it into a VoiceAttack variable that i normally call “MSFS.ValueGet”. If there’s no -G at the end, it means i’m copying the value of a VoiceAttack variable that i previously set (normally MSFS.ValueSet) into the value of the local value, thus modifying it.

Cheers!

15

Hi. About the Plane_Altitude variable this is what I did: I wrote a test profile, each time I say “check” it writes the variable in the log. Put the plane in a holding pattern at 5000 ft and started changing in the autopilot to 15000. Checking the pfd and the log at the same time aleatory saying “check” and confirming both show the same height. Repeated the same thing descending back to 5000ft. In both cases the values obtained in VA each time I trigger the command are accurate to the value shown in the pfd in real time, so I think this variable is valid for our pourposes. Tomorrow after updating the dll of your script and importing your new flows I will recheck again with your previous variable that didn’t work before. I will test your flows in flight too and later post my conclusions. Would be awesome if you can import my two commamds (made modifying your original ones) in VA and take a look at them. I would like to hear your opinion. Because of my limited knowledge about coding, all learned reading code and trying to understand how it works, and then making tests modifying and failing and modifying again, will be interesting to hear your opinion, as obvious your knowledge about it is much bigger than mine ( if I had to code a plugin I didn’t know how to start). More discussion tomorrow, now it’s very late for me. Cheers.

1 Like
16

Now I understand that the letters are related to your plugin for managing the values. I will keep your post for remembering this info in the future if I make any new adaptation of your flows. Today I spent a part of the day translating all the spoken phrases in your entire profile and adjusting the order of things in some flows. You have made the profile so extended covering a lot of triggers that it took me a good amount of time, you did an explendid job with the profile. It allow you to use it onle as copilot reading checklists and doing all the job manually by yourself, or you can automatize almost everythink, for those who are starting in simulation and don’t know the order of buttons and things to make the plane fly. Very good job. Cheers

1 Like
17

Hi there, finally found time to write. I have tested your profiles in flight. I imported them in VA and opened the “ascent command”. After taking a look at the code I understud how it works. Divided in 3 conditions, TA < 10K, TA=10k and TA>10k. It´s quite clear. Before opening the “descent command” I thought it would be the same code with inverted comparators, as we check to be lower than, not higher than, but I saw 8 rows added at the begining of the code that didn´t exist in the other profile. I tryed to understand what do they do, what do they check, and I couldn´t figure it out.
Well, once in the plane, the ascent command works in the 3 different conditions mentioned before, but the descent profile has any problem that I can´t understand. The first time I executed it, it read out instantly “TA reached” and “10 thousand”. THis ha0pened in the same moment I executed the command, at 15 thousand feet. I “erased” those first eight rows that I couldn´t understand their function and tested again. Now the voice anouncements don´t trigger when executing the command. The plane starts descending and I get the anouncements at the expected height. At this point I thought that it was everything ok, but I changed the condition of the test to TA lower that 10k, and when the plane arrived to that height the game crashed. A freezing in the screen and then my windows wallpaper. MSFS had closed itself. I thought it could be some minor thing,opened again and tested it on flight. Ascent command worked perfect, but in descent command another crash of the game. Something is wrong, I prefer to cancell the tests and coment with you the situation before doing anything else.

So I decided to test my profiles. the ones that I posted the other day. I made a correction for resetting the variables and added this four lines at the begining of each command:

Ascent command:__________________Descend command:
Set Boolean [Rta] to false____________Set Boolean [Rtl] to false
Set Boolean [Rten] to false___________Set Boolean [R10] to false
Set Boolean [taN] to false____________Set Boolean [tlN] to false
Set Boolean [tenN] to false___________Set Boolean [10N] to false

Everything works perfect, so by the moment I inserted them in your original profile. When ascending, at TA it sets automatically STD barometre and at 10k turn takeoff lights off. When descending, at 10k turns landing lights on and at TL sets barometer to local QNH (I have a question about this )

Finally I ended with translating strings, erased all the “write to log” lines (I don´t want it to be writting continuosly in the window) and adjusted a couple of processes. For example, the APU on doesn´t waits to be available to continue with the command of after landing flow. The command continues turning off switches and things and when the APU is available it reads it out and ends with the command. Changed a little the order of some flows and checklists, and added inside some checklist a question to me asking to continue with the next flow ( this is made for example in the “before start checklist”). After adjusting everything to my expectations I made two full flights, from cold and dark to again cold and dark in destination airport. Everything worked well, I was very happy because the experience is now much more realistic. Only a couple problems found:

Turning on and off the external power doesn´t work in the corresponding flows. If you trigger the specific command with your voice it works perfect, connects and disconnects it, but when executed trough the flow it doesn´t work. No connect and no disconnect. Tryed several times and no one I see it work. So I cancelled that lines in the flows. Now when you start the plane it goes to turn the APU on without the external power that goes before that in your flow. Another little problem found is that the plugin losts connection with the plane several times. I received various of these messages along the tests:

MSFS: Couldn’t make a connection to WASM, context: A:Indicated_Altitude
MSFS: Retrying connection

MSFS: Couldn’t make a connection to WASM, context: CC: 0 (>L:LANDING_2_Retracted) 1 2 r (>K:2:LANDING_LIGHTS_SET)
MSFS: Retrying connection

MSFS: Couldn’t make a connection to WASM, context: A:Circuit_Switch_On_22
MSFS: Retrying connection

Sometimes this happens when there´s a flow in execution, and it pauses until it reconnects and then continues executting the flow.

And my last question: when you set the altimetre in the “starting the plane command” you use the variable L:XMLVAR_Baro1_Mode. This is made with the plane on ground in the origin airport. As I told, in the “descent monitoring” commnad I execute it again at TL to set the local QNH, but my doubt is: the plane at that point is not stopped on ground, is flying, so where does that variable take the information from? That pressure setted in the baro corresponds to the same pressure in the destination airport. Because if not, the altitude is incorrect, and in an event of autoland the plane would crash agaist the floor. Is there another variable that obtains the barometric pressure of destination airport? Do I need to better change the command and not execute the function of auto setting the QNH and change it only for a voice anouncement and set it manually by myself?

Basically this is all by the moment.

18

“I “erased” those first eight rows that I couldn´t understand their function and tested again.”

-This is okay, those rows were remains that i forgot to delete.

“but I changed the condition of the test to TA lower that 10k, and when the plane arrived to that height the game crashed”

-This is weird. I tested myself these commands at all 3 conditions and i had no issues. I guess it’s not an issue anymore though since you are telling me you merged it with your command and it worked fine.

“Turning on and off the external power doesn´t work in the corresponding flows.”

-This is also weird. At my end in the “preflight flow” command the APU turns on just fine. At the “secure aircraft” command though there’s something to be noted. The APU in the A32NX takes a couple minutes to shutdown, so at the end of the secure command the APU is still on. Maybe that could be interpreted like the APU didn’t shutdown.

“MSFS: Couldn’t make a connection to WASM, context: A:Indicated_Altitude
MSFS: Retrying connection”

-This is something that sometimes happens and that we have to just deal with it for now, since i don’t have a solution. This is an issue with WASimCommander not being able to connect momentarily to WASM, but i designed my plugin in a way that it just retries connection until it manages to do the actions. Otherwise, these commands within a flow would just be skipped, and that is a bigger problem.

“the plane at that point is not stopped on ground, is flying, so where does that variable take the information from?”

The key to this command is the “K:BAROMETRIC” action. That variable sets the altimeter of the aircraft to the pressure that is outside the aircraft (MSFS has that number available at all times). Has the same effect as pressing “B” in the keyboard. You are probably right though. This should probably be the atmospheric pressure AT destination airport, for as close as it is to the pressure surrounding the aircraft at that point.
I will try to see if there’s a way to get that information instead.

Cheers!

19

I think I didn´t explained myself very good about two points, I´ll try again:

About the about the new checking height commands, as I told, the descent command makes the game crash when reaching 10k feet, don´t know why, but once and again and again, so I put them apart and I´m not using them. I´m using the ones that I tryed to make, that after testing them various times as I made before with yours, they are working perfect, giving the announces at the right heights, and with no crashes. So I implemented them in your original profile and everything works, at least by the moment. This is my test profile with your and mine different commands included (please take a look if you can): https://drive.google.com/file/d/1ca1cQV4ur9y3V07ERaZtyg5CDZXtdQcr/view?usp=drive_link

The problem with the external power is not with APU, it´s with GPU. In your preflight flow you start GPU, then start APU and turn off GPU again after APU started. Those two commands “external power on” and “external power off” are the ones that don´t work in the flow. I don´t know why. But if you trigger them with your voice they do work. I turn de GPU on and off with the voice without any problem, but when I launch the preflight flow you can check it´s button light remains “green available” all the time. It´s like if the flow went so quickly that it didn´t have time to trigger it. So, as I told, I erased the GPU commands from the flow, and if I need it I lauch it with my voice or the button.

About de “K:BAROMETRIC” variable, as it may not be the same than the destination airport, I will only trigger a voice command announcing the flight level and configure the destination local QNH by myself. If you find a variable that indicates the QNH in destination airport please tell us, so I can make the flow to set it automatically. I will take a look to the variables list too. Maybe four eyes better than two.

20

“The problem with the external power is not with APU, it´s with GPU”

Yeah i get what you mean, i don’t know why i confused myself. It’s weird though, i tested again and i don’t experience any of these issues with ext pwr.

“This is my test profile with your and mine different commands included”

It asked me to request access. I did request it but still can’t access the file.

Cheers!