Managing Tail Winds

[chris_c]

FS Aviator's PT goes into the subject of dealing with headwinds in a propliner but how does one deal with excessive tailwinds that reduce IAS significantly?

Was flying the BSAA Montevideo - Buenos Aires segment in a Lancastrian MkII, 8000' at cruise power, real wx and with FS Metar for updates. Attitude good, wings level and IAS 176 mph with a sleight quartering tailwind from the left.

Suddenly IAS dropped 40+ mph, the nose came up and the a/c started to wallow in yaw from side to side. My first thought was ice but was in clear air between cloud layers and the OAT was +22C. Copped out and checked Shift Z where it showed a 45 knot wind with an almost 100% tail component and getting stronger to boot. As wind velocity increased, IAS continued to decay and the Lanc seemed close to stalling.

Got the nose down and went to maximum sustained power, +7" boost @ 2650 RPM and descended to 2000' where things settled out and I was able to resume cruise power since the wind strength reduced to 12 knots. Successful crosswind at Ezeiza runway 17 followed.

So it would seem that the immediate action in a significant tailwind is similar to that when one encounters a significant headwind particularly when low and slow, reduce altitude and increase power. Does anybody have any insights or advice?

Thanks in advance.

Chris

[ashaman]

What you just surmised is a shortcoming of FS, when using real weather.

I'll tell you my story. At the time, first months FS9 got out, was flying the default 747 on a jaunt from EGLL to LIRN and had the magnificent idea of using the integrated Real Weather. All over France was unable to find a Flight Level without severe turbulence, making it one heck of a travel for my passengers, but the best had yet to happen, and it did when I was almost over the alps. At the switch from a METAR station to another, the unanticipated severe (more than 100 knots) headwind that almost made me decide to make a stop-over to LIPE to refuel (took off with pretty good calculated fuel and was running low because of the trice damned headwind), made a sudden 180 without changing strength. You can imagine what happened on a plane that at FL240 (there trying to find a FL with less turbulences) was traveling at about 280Kias.

That was my first crash on FS9. In spite of everything I tried, my plane fell tail first into the ground somewhere north of Aosta, killing everyone on board.

Solution? Buy a registration to FSUIPC and use it to dampen the intemperances of the switching of the METARs.

Sorry, but at today no freeware solution has yet to appear, leaving the need to register FSUIPC the only solution. Even external weather programs like Active Sky (yet to be available at the times anyway) do not really help a lot in this matter without a registered FSUIPC limiting the winds variations strength. I myself, with a complete absence of enthusiasm (not to use terms that would be out of place among polite company), had to fork over more money (had bought FS9 only some days back) to buy the then freshly converted to payware FSUIPC.

PS
That was the start of my antipathy against freeware that suddenly becomes payware as well, but this, as they say, is another story.

[ozbeowulf]

Interesting experiences from ChrisC and Ashaman. I haven't struck the problem in FS yet, but it's very interesting to know it can happen in our cyber world. Thanks for sharing.

Those were FS quirks, of course, but that is exactly the dangerous situation that can occur when a thunderstorm is near an airport. In this case, the sudden strong tailwind comes from a downburst, where a strong downdraft hits the ground and fans out. If you're in the wrong spot at the wrong time, instant tailwind, loss of airflow over the wings, high sink rate.... possible boom!

Modern heavy jets are the most vulnerable because the only way they can increase aiflow over the wings is to accelerate the aircraft, which takes time. At least the propeller aircraft we favor here could get some extra airflow as propwash over the wing by going to full power.

Cheers,

Glenn

[ashaman]

Happened to experience microbursts and windshears sometimes (with Active Sky though), memorably once, when I was landing the 707 AF1 in Athens, and, having experienced them all (or almost all), can tell you it is a little different from what happened to me on the alps.

Of course I'm talking about my experiences on FS9. Can be wrong if compared to real life ones or even other simul-pilots experiences. No hard feelings.

[Tom/CalClassic]

Hi,

Yes, it's a bug in FS. Either buy FSUIPC or just be ready for it...

[ozbeowulf]

Just one last niggly point.

Generally speaking, tailwinds are to be treasured. Free miles "across the ground" for the same miles "through the air." What's not to like about that?

But if the wind instantly changes and blows hard from behind, the problem is the temporary loss of "apparent wind," i.e. the airflow over the wing. In reality, an aircraft at altitude would accelerate, probably by losing altitude and adding power, as Chris did, then continue ahead of schedule. A heavy jet on short final might crash short of the runway. It has happened.

Chris and Ashaman have experienced this problem in FS. I haven't (probably because I have FSUIPC), but it sort of sounds like fun. After all, there aren't all that many unexpected FS emergencies to deal with.

Cheers,

Glenn

[chris_c]

Thanks much for the input, I too have had unpleasant experiences with FS9's horrific upper air wind changes but in this particular instance I am not convinced they were in play here.

The general wind direction was constant and remained so, at takeoff (sea level) FS Metar indicated winds from 128 at 10 gusting 24 kts and with a track of 278 magnetic across the Plate estuary, this was the quartering tail wind I mentioned in the opening post. When the gale hit the direction changed less than 30 degrees, backing to around 100 degrees or so and essentially staying there across all the intervening Metar updates.

Typically, when FS9's winds go nuts they vary in velocity and direction almost instantly but this did not happen here. The velocity and direction change probably took 30-40 seconds but I failed to appreciate what was happening in time and the realization that I was in trouble came on suddenly.

Had I thought this was just a typical FS wonky-winds episode I never would have posted the question.

Chris

[Tom/CalClassic]

Hi,

A response from FSAviator:

<<I too have had unpleasant experiences with FS9's horrific upper air wind changes but in this particular instance I am not convinced they were in play here.>>

I agree. Before I explain the two things that could have caused the symptoms you reported let me answer the question;

<<FS Aviator's PT goes into the subject of dealing with headwinds in a propliner but how does one deal with excessive tailwinds that reduce IAS significantly?>>

A change of wind vector alters speed (KTS) not profile drag (IAS). I will illustrate why in a moment, but your question is already answered in the 2008 Propliner Tutorial. Word searching the 2008 Propliner Tutorial for 'tailwind' provides guidance for all phases of flight. Searching instead for the main heading TAILWIND in upper case takes us directly to;

>>>>>>>>>>>>>

REACTION TO NO SIGNIFICANT HEADWIND OR A TAILWIND

Later during the same flight we notice that a leg (or legs) planned to take 20 minutes only took 19. Now we must react in the opposite way. We must seek a higher cruising level and we may reduce to one lesser stage of power from whatever we currently have applied. We never want our speed to exceed planned speed. We are being paid not only to reduce the TIME that our propliner suffers headwinds, we are also being paid to maximise the TIME it rides tailwinds. When we encounter a tailwind we climb in the hope of finding an even stronger tailwind at a higher semi circular cruising level and then we reduce power to enjoy the tailwind for as many minutes as possible.

This power reduction might potentially be a reduction from econ cruise power to long range cruise power. In some handling notes there will be an injunction against using LRC power until the weight is below a specified value or the fuel state is less than a specified percent.

In real life we discover these values by asking whichever crew member we appointed as Flight Engineer, (often this will be Pilot Not Flying = PNF), what they are. In MSFS we need to open the fuel and payload menu to obtain the answer or consult a Calclassic notepad.

The intention is, over the lifetime of the airliner, to maximise the time with a tailwind and minimise the time with a headwind. Over the long run it improves economy of operation and when simulating airline operations in propliners that is a major part of the 4D navigation process. If we always cruised at the same power setting we would spend more time flying with headwinds than with tailwinds. That would be very bad captaincy.

Real world aerial navigation is not a 2D process. It is very much a 4D process. The vast majority of the navigation task is the captaincy required to manage (reactively) the vertical profile of the flight and applied power versus perceived headwind. Simply planning and following the 2D course should be a tiny fraction of our navigation workload.

>>>>>>>>>>>>>>>>

When you assert wrongly that wind vectors vary profile drag (IAS) in flight you are confusing speed measured in KTS with profile drag measured in IAS. The Propliner Tutorial begins by explaining that speed and drag are different things and that the ASI in the cockpit can only measure profile drag.

Imagine we are in a small boat travelling at a speed of 10 KTS with a profile drag of 10 KIAS. There is no current. That profile drag (not our speed) is creating a visible and measurable bow wave. Now we meet a current going the other way at 10 KTS. *Our bow wave neither doubles nor disappears*. Our profile drag is still 10 KIAS. The bow wave is only the consequence of power we apply to the structure. The bow will not be stove in when we mead a current however fast. The bow has the same profile drag and bow wave whatever the current if we do not vary applied power or drop a see anchor. The current we have encountered and are immersed in cannot alter our drag (IAS) whatever direction it comes from. It can only alter our speed (KTS) relative to some land distant from our vessel.

Our profile drag is still 10 KIAS, our bow wave is unaltered, but our speed is now zero KTS. We do not progress relative to the distant land. Our speed still has zero influence over our profile drag producing the bow wave. If we meet a 15KTS current our speed will be minus 5 KTS but we will still have a bow wave that depends only on applied power. We control our profile drag (IAS = bow wave = structural failure probability) by moderating power to create the handling note target values and avoid the handling note limit values. Our speed (KTS), and only our speed, varies with the speed (KTS) of the currents we encounter. A wind is just a current of air. Currents have zero influence on drag in an aeroplane or a boat.

IAS measures profile drag on the vessel's structure

TAS measures aircraft velocity (how well it manoeuvres in flight or deforms in a collision)

KTS measures vessel speed (progress relative to some distant land)

The profile drag (IAS), shown on our ASI, to which the airframe is subjected by our choice of power input, is neither its velocity (TAS) nor its speed (KTS). This is at the very heart of navigation and is the 'eureka' moment that many FS users never come to terms with. An ASI does not register speed and it cannot register a change of speed, due to a change of current, or anything else. It only registers a change of profile drag on the pitot tube which we control with applied power or sea anchors (air brakes / flaps).

Now a second confusion. Turbulence in the fluid is a separate issue but is being muddled with strength of current. Turbulence can be caused by 'mixing of currents' or 'rate of change of the speed of the current', but that must be differentiated from the strength of the current. A fast current may have zero turbulence. Severe turbulence may exist where there is no current. There is zero correlation.

Big waves and strong currents are different things.

Our bow wave varies in turbulent seas. Our drag increases as we smash into a huge wave, but then it rapidly diminishes. The bow may be stove in or the tail may be ripped off before it diminishes. When profile drag (IAS) suddenly increases structural failure may occur, when it suddenly diminishes an aeroplane may stall. It is only the profile drag (IAS) on the wings that supports our weight. Waves smashing into the bow and turbulent flows over the pitot tube can, and do, vary profile drag (IAS), but that has nothing to do with whether a current is even present.

Variation of current causing variation of KTS is not at all the same thing as variation of wave size (turbulence) causing change of IAS.

Your report cites an increasing and prolonged decrease in profile drag (IAS). That prolonged change cannot have been caused by either a change of current (wind vector) or a change of wave state (turbulence).

The consequence of turbulence (big waves) is rapidly fluctuating profile drag (IAS). Since any such increase may rip the tail off (stove the bow in) we must reduce power and reduce our target profile drag (IAS) whenever we encounter significant turbulence (big waves), even though that may make stall more likely in an aeroplane. Stall is better than structural failure.

We do *not* reduce power when we meet strong currents opposed to our bow. Strong currents which vary KTS and big waves which vary IAS are not the same thing and they require different captaincy responses.

<<Was flying the BSAA Montevideo - Buenos Aires segment in a Lancastrian MkII........Suddenly IAS dropped 40+ mph....,As wind velocity increased, IAS continued to decay and the Lanc seemed close to stalling.>>

Your incident report is clear. Your attribution of cause is false. The strength of the current you were immersed in, whatever its direction of travel, was irrelevant. It could not alter profile drag (IAS). So something else did. There are only two possibilities. Change of POWER and change of DRAG. There are three logical reasons why those two things might happen in MSFS.

1) Bogus drag imposed by the gauge code

It may or may not apply here, but many FD supplied for use in MSFS have 'cheat modes'. Some suddenly auto deploy invisible air brakes (sea anchors) when they should not, because the gauge code is bugged or the developer had some misconceived notion about flight dynamics.


2) Progressive engine failure in the gauge code

Some releases have 'engine failure code' which reduces power causing persistent loss of bow wave = profile drag = IAS for reasons which are lost on the user, but which represent mismanagement by the user, at least according to the developer.

Maybe your Merlin engines overheated whilst cruising in very hot air that was ISA + 23C. Maybe you failed to open the radiator gills sufficiently on all engines for that extreme outside air temperature. Ice was the least of your engine management problems! Maybe the developer imposed a failure for reasons you have not understood. Maybe the failure code malfunctioned.

If you were punished with code that varied mixture to emulate user engine mismanagement and consequential partial failure there may have been no loss of MAP. It can be very hard to tell when a developer decides to punish you. We have no way of knowing what gauge code may be in every propliner downloaded or purchased. You should investigate whether your aircraft specific operating manual cites engine cooling, radiator gill status and progressive engine failures. If not you should ask the developer what they think happened in the forum where they provide support.

Unless you accidently reduced thrust. or accidentally altered aircraft drag configuration you were almost certainly afflicted by developer gauge code that you did not expect to run, and you probably have no idea what you did to cause it to run. If your aircraft specific operating manual does not explain the incident I believe only the developer will be able to explain what third party code was invoked to cause persistent loss of profile drag on the pitot tube (IAS).

3) Sudden false change in altitude density.

Using real METARS invokes risk of real human data input error. If the real meteorologist or data entry clerk entered 19.92 inches when they intended to enter 29.92 real pilots will read it and realise it is human error. Computers won't. Our computers just reduce altitude density at all altitudes massively in an instant. If you are high enough in relation to the encoded engine specific critical altitude MAP falls accordingly at constant throttle opening. The sudden loss of applied power causes profile drag = bow wave = IAS to decay very fast at first, and then much slower, potentially and eventually to stall.

However since you do not report a sudden change of actual height or displayed altitude this is much less likely in relation to your incident than fake air brake code or fake mixture code invoked by the developer from the gauges.

Prolonged or progressive decay of profile drag (IAS) in level flight can ONLY relate to power change, or aircraft configuration drag change, never to wind vector (current) or turbulence (wave state).


FSAviator

[dutch11]

I read FSAviator's reply, and as usual it is fascinating. One thing that I thought of is the possibility that the OAT was changing just as fast as the wind was. I have been flying the Pan Am round the world flights using Real World Weather, as opposed to Fair Weather as I was used to do. Normally, in the DC-6B, using Fair Weather, I am able to cruise at FL210 at about 185 KIAS, but when flying the legs into Bangkok and Hong Kong, I was only able to manage about 176 KIAS at FL190, the OAT only being about -5C. There were times, like when flying from Tokyo to Wake that the temp. changed quickly; when I left Tokyo, it was -32C at FL210, but about 1 hour out of Tokyo it changed rather abruptly to only about -5C again. I was flying the Strat at FL210 at about 204 KIAS, and wound up at FL150 at 184 KIAS when I gave up and switched to Fair Weather because I didn't want to descend to FL130. This is often the reason you get a pronounced nose down attitude in the DC-6/7's and many don't recognize the problem. If temp. drops, so will your nose. I hope I haven't put my foot in my mouth, I'm just sharing what I've learned lately.

[Tom/CalClassic]

Hi,

BTW, FL130 was not unusual for the Strat over the Pacific.

[chris_c]

Thanks to FS Aviator for the detailed response and to the others who added to the thread.

I learn something on practically every visit here and if I confused cause and effect, I know more now than I did before.

I do not have a lot of Lancastrian time but compared to a DC-6B or Connie, it is really a bit of a dog so whether what happened was pilot (me) or model induced, I guess I'll never know for sure.

Next step is over the Andes to Santiago and see how I do at 24,000 feet and the subsequent visual approach into Los Cerrillos.

Once again, Thanks to all for their input.

Chris

[volkerboehme]

Hi,

Randy beat me posting it at the archive.

Maybe my 2 cents on this subject: I am not sure whether FS representation of windshear could cause this problem as well. Apparently FS has a very aprupt way of changing Wind between flight levels, but that is only hearsay. And at low altitude, you could get significant windshear if you pass a canyon that is carrying a lot of wind. This seems to be the case for take-off at Anchorage. However, I'd doubt that FS is modeling such a sophisticated wind phenomenon in relation to ground structure.

Best regards,
Volker

[dutch11]

Notice the OAT that Chris reported; 22C at 8000 ft. Given a standard lapse rate of 2 degrees per 1,000 feet, that makes it about 38C or about 102F at sea level. Reciprocating engines just don't perform well at that temp and lift is diminished in such hot air. I don't know how well MSFS models humidity, but at that temp. humidity would also have a significant impact on engine performance. As I said before, if temp drops, your nose drops, if temp rises, your nose rises, perhaps to the point of stalling if steps aren't taken to compensate. I know from experience that temps in Real World Weather can change just as quickly as winds do. I may be wrong, but it's something to think about.

[Tom/CalClassic]

Another message from FSAviator:

I think it is well worth moving on to examine the consequence of outside air temperature (OAT) variation, but it wasn't the original question and doing so will turn this into a very long multi part post. The temperature reported in the original post was neither a data error nor a problem (outside of engine cooling).

First some further examination of the consequences of currents and waves, (wind vectors and gusts) in MSFS seems appropriate. Every equation has two sides. Input and output. In MSFS the amplitude and wavelength of gusts is calculated and input by the hard coded weather model. If the data supplied to the equations of the weather model are false then input made by the weather model to MSFS is false.

A rate of change of wind velocity (current) alone may cause a gust / wave. The merging of two opposed currents may cause a gust / wave. A gust / wave is just a variation of amplitude which also has has a defined wavelength. It is not a speed. It is a transient amplitude variation event. The gust / wave is not the current. The current influences vessel speed (KTS). The gust / wave influences vessel drag (KIAS) and will always also influence vessel pitch in a transient way which depends on the amplitude and wavelength of the gust / wave.

With real weather in use over an ocean in MSFS we will suddenly move from the real weather at one weather ship to the weather at a different weather ship maybe a thousand miles away. The current will be different, the temperatures will be different, the pressure will be different. The 'boundary event' is sudden in MSFS, but takes 1000 miles in real life. We encounter a fake wave / gust event at the sudden boundary.

Over land if two nearby weather stations have very different currents due to the topography of the terrain channeling the currents we will encounter a calculated gust event due to current mixing which is real. With real weather in use the weather model also calculates gusts as wind shear at vertical boundaries. It has both currents on either side of the shear and the transient gust consequences at the turbulent mixing boundary. We will encounter a (series of) gust(s) that are more or less realistic.

This is the problem for Microsoft. Too much smoothing eliminates real gusts. Payware FSUIPC eliminates some real gusts via its smoothing algorithms in order to eliminate fake gusts.

The underlying problem is that data entry clerks at real METAR stations do not pay sufficient attention to their work. Real pilots and controllers know the QNH is not 19.92. Our computer does not. If the real approach radar controller drove to work in a blizzard he knows the OAT must be -10 not +10 even if his screen says +10 so he broadcasts minus ten / blizzard not plus ten / blizzard whatever the screen says. Our computer just accepts +10C and falling snow. This cannot be error trapped. Neither FSUIPC nor any other program can tell whether -10 or + 10 is logical for London today. The weather in the UK is so variable that it could be either.

Smoothing causes loss of real data and full error trapping is not possible. Payware FSUIPC does a good job of protecting us from huge fake transient gusts but we lose some real ones. Its our choice.

However what happens is not a mystery. With real weather in use MSFS calculates the gust that should be created by rate of change of current or mixing of two currents at their boundary and imposes that wave / gust, whether real or bogus. That wave / gust is a transient event. We hit the wave, it adds profile drag, flow becomes turbulent, (spray is generated), and we also pitch up losing profile drag (IAS), and may stall, or we may pitch down, and may suffer structural failure.

If the IAS falls below Vbg <> Vx (the aeroplane is perturbed onto the wrong side of the drag curve), the wing continues to pitch up if no action is taken via power or elevator to prevent the imminent stall.

As far as Microsoft are concerned there is no bug in the real weather engine. The code is real. The events are real. The inputs it makes to MSFS are real. It is the data provided by real world METAR data clerks that is bugged. If we use real weather we live with it or we buy payware FSUIPC to smooth bogus gusts and suffer some loss of realism when the gust is real due to real wind shear or real topographical channeling.

A gust / wave is anyway not a current / tailwind or a headwind. Wind vectors cannot alter IAS. They can only alter KTS. Opposed wind vectors can cause a transient gust. It does not endure. It has a short wavelength. It is our job to cope with the gust event. It is our job to avoid stall and it is our job to avoid structural failure. Nobody can see huge waves coming at night in a boat either.

This is why we must not allow our profile drag (IAS) to exceed either Vno or Mno. If we do we must expect structural failure when we encounter a significant gust. Big unseen waves have been causing structural failure of vessels underway with excessive power applied causing excessive IAS for hundreds of years. In an aeroplane as we pitch up the wave we may also stall. The maritime equivalent would be capsize, but it is not an exact parallel.

None of this is a bug. It is the sudden data difference used to calculate the gust (wave amplitude) that may be false.

From time to time I try to illuminate the difference between the Flight Model (FM coded by Microsoft) and the aircraft specific Flight Dynamics (FD coded by third parties). The FM calculates all this stuff (more or less) correctly. The weather model also calculates (more or less) correctly. The problem is that fake data may be fed into the accurate Microsoft code. The FD author must research and encode realistic gust response for the specific aeroplane. Most simply don't bother or maybe they just think they should emulate the code in default Microsoft contractor FD.

Every equation has two sides. Input and output.

For years a series of third party FD authors have done their best to explain to the FS community that various parts of the aircraft specific code retailed by MS are broken. Everything from the scenery projection code in '2D panels' to more obscure things like gust response. Third party developers do not avoid creation of the exact same aircraft as Microsoft released. They know they can do better. One way that they can do better is to improve the output in MSFS. The other side of the equation.

Those who have flown a real C172/182 will know that the real thing does not behave like a leaf tossed around on the breeze in light turbulence, let alone in still air. The real thing is not unstable and undamped in still air. According to Microsoft and their 'expert contractors' Cessnas have little inertia, little stability, and little damping. In MSFS the default Cessnas are hard to move from one energy state to another in still air without bucking and yawing like a bronco. Amusing consumers with bogus 'head bobbing' in relation to tiny G forces that would not cause anyone to lose control of head position has replaced any attempt to release realistic default dynamics (or their physiological consequence).

Errors in the output side of MSFS equations are just as important as errors on the input side. They are less discussed and less understood, yet in some aircraft the output data is most of the problem. When the weather engine creates a realistic gust the specific aeroplane gust response is wildly wrong. Its FD have too little encoded inertia, stability and damping.

I think I can deduce why, but first an analogy which has some scientific inaccuracies, but may aid understanding. Imagine an Army truck is parked on a flat hard surface with the engine off, gear box in neutral, and the hand brake off. A child rides a bicycle into the rear steel fender at modest velocity. A force is briefly applied to the truck. The structure of the truck is not deformed and nor does it move. The truck is massive and has huge inertia. It also has high stability. It does not topple over.

Now imagine the truck is highly instrumented and the data is recorded by a black box. The needle on the relevant gauge (dynamometer =G meter) flicks up to record the impact. The data is recorded in the black box. The truck velocity is zero throughout. The speedometer needle never moves. An accident investigator is called in and he demands the black box data. He needs to know whether the truck was moving or stationary. He needs to know whether something impacted the vehicle. The black box data is used to produce time traces and discloses that the truck never moved, but that a G force was applied. The transient force failed to overcome the inertia of the massive vehicle which never moved. If the investigator knows the mass of the bicycle and its crew he can calculate its velocity at impact. The investigator does not confuse the trace which records the velocity of things that collided with the truck with the velocity they induced in the truck.

Each version of MSFS has introduced a different variety of bucking bronco called a Cessna 182, each said to be 'as real as it gets'. I deduce that somewhere in the mists of history either BAO or Microsoft obtained black box data for the Cessna 182 'gust response' and confused the trace of what happened to the needles on the gauges with the trace of what happened to the whole aeroplane.

When a real Cessna 182 departs into slight turbulence the pitot and static tubes detect rapid pressure fluctuations as gusts pass the pitot tube and static port. The mechanical parts of the gauges they drive have low mass and low inertia. they are usually poorly damped too. The ASI and the VSI may fluctuate rapidly. They are 'recording' air impacting the aeroplane faithfully. The stall warning horn sounds then stops, over and over again, as every gust impacts its reed. The passengers think the Cessna might stall, but the pilot knows that if he maintains the correct attitude = pitch = angle of attack the wing will not stall. He ignores the wildly fluctuation ASI and the VSI and targets the correct pitch. In light turbulence the aeroplane does not bounce around like the needles on those gauges. It is an army truck being impacted by a kid on a bicycle. Its inertia is not overcome. The acceleration induced in the entire high inertia vehicle in the x,y,z axes must be measured with a dynamometer (G meter) which creates a different set of traces to the traces which record the impacts.

Of course as the turbulence gets worse it will manage to 'move' (actually accelerate / decelerate) the entire aeroplane in space, but the needles that are showing how the air is impacting the massive aeroplane will move much faster and will fluctuate much more. The two things must not be confused. I believe that they were confused in the default FD a long time ago. Ever since slow but inadequate adjustments have been made to the default Cessna inertia and stability, but it still lacks realistic inertia and stability. This matters because third party FD authors plagiarise and extrapolate from what MS release, however broken it may be.

There is another FD content problem. CFS versus FS. Fighters are carefully designed to have low inertia and low stability in order to make them responsive. Transport aircraft are designed to have high inertia and high stability with excellent gust response, but they are less responsive. It is not just a question of relative mass and size. The design time intention is different. Third party air file compilers, and the help files of third party air file editors, often make false assumptions about the role of the aeroplane being encoded. A naval destroyer and a cargo boat do not share the same inertia, stability, damping, structural integrity, capsize probability, wave response, or handling even if they are the same length, and have the same mass.

The result is a huge number of FD released with inadequate inertia and stability. Their gust response is like a leaf in a breeze. They accelerate and decelerate too easily in gusts and are also toppled too easily by a realistic gust. A massive aeroplane with high inertia does not accelerate / decelerate in an instant to the velocity of the air impacting it. The VSI measures vertical SPEED increment. *Speed is relative*. In still air it is the aeroplane that is moving up through the air in the z axis. The VSI records aeroplane speed upwards. But when the air is moving downwards as we cruise the gauge cannot tell the difference. It quickly depicts the aeroplane as climbing when it is actually unmoved in sinking air. The gust ends almost as soon as it began and the aeroplane never accelerates to minus 300 VSI in the z axis. It may not sink at all or it may sink a little. It may acquire a z axis acceleration of -10 due to transient impact at -300. Nor is the aeroplane significantly toppled. It is stable. The real aeroplane does not pitch, topple and accelerate like a leaf when subjected to a breeze. Nor does it 'topple' when the pilot makes small control inputs to vary direction in any axis. It has been shaped so that it does not. It is stable as well as inert.

In a real Cessna the gauge needles react quickly because the inertia of the gauge mechanism is very low. They move all over the place recording air impacts correctly, the stall warning horn goes on and off, but if we target the correct pitch the massive aeroplane deviates up and down far less; and is not significantly toppled in the x or y or z axes either. In MSFS bad Flight Dynamics code (not Flight Model code, not Weather Model code), with inadequate inertia and stability encoded allows aeroplanes to be tossed around like leaves and the weather model is blamed.

There is another problem. All systems are damped. The long case clockmaker must control the inertia and stability of the pendulum, but he must also damp it so that the tick and the tock are exactly one second apart. Having been perturbed from rest by a transient force the pendulum returns to its prior status after a *designed* time constant. Remove the 'gusts' generated by the clockwork spring and it will soon be damped to rest. That will also take a very specific, but different, time interval.

Real FD authors design the damping of the aeroplane in all axes and it reverts to its prior equilibrium after the transient force is removed. Damping is the other principle component of responsiveness. 'Fighters' must have low inertia and be very unstable but superbly damped. When the pilot adds or removes an input force the motion must start / stop fast. Propliners are less responsive, but they are designed with adequate damping.

Like a pendulum (they are a pendulum) they revert to their prior equilibrium state without pilot input.....unless the aeroplane has been forced from the right side of the drag curve to the wrong side (is already so far perturbed that it continues to capsize). Well designed aeroplanes will stall at a much lower angle of upset than is required to capsize a well designed boat. This is another reason we always cruise close to zero pitch. We must make it difficult for the next big wave to pitch us up to stall pitch (capsize). If we cruise with substantial pitch we are vulnerable to stall in gusts. If we cruise nose down we are vulnerable to structural failure in gusts. On approach we must deploy flap to sustain low pitch (actually low angle of attack). If we don't have flap, or we fail to use flap to control pitch independently from flight path vector (glideslope), we are much more vulnerable to gusts on approach because we will already have invoked high pitch (actually angle of attack). If we fail to restrain pitch in descent, to restrain IAS in descent, we are vulnerable to structural failure during descents.

Many MSFS FD also have inadequate or excessive damping in relation to the designed role of the aeroplane. Many MSFS FD fail to associate design cruise power with zero pitch at design cruise altitude at design cruise weight. This makes the aeroplane more prone to stall in any gust during cruise. Many more FD fail to associate zero trim drag ('flippers neutral') with the same design condition. This leaves the human pilot and the AP without full elevator authority and without full trim authority, in one direction or the other, during recovery from gusts, (and all of the time).

So we suffer hundreds of excessively gust perturbed aircraft releases, which cruise at excessive pitch, even before they are excessively perturbed. Then most are too slow to recover prior equilibrium and require more rapid and more aggressive pilot intervention with power and stick than in real life. The need for 'realistic' FD does not just relate to realistic cruising velocities, realistic operational ceilings, realistic range versus fuel loaded etc, it also relates to handling and gust response, both of which depend on 'realistic' inertia, stability, damping, CL associated with zero pitch cruise, and trim authority (as well as other things).

Now please note that I am not claiming those values are correct in my FD. There is too little data in the public domain to know. Manufactures keep data for things like stability and damping secret. It has to be estimated and it is very difficult to estimate. For instance I never claim to estimate inertia to better than two significant figures, but most FD authors claim to have estimated it to eight. In many cases the encoded value is very precisely wrong, by more than 100%.

If the role of the aeroplane is transport then it is a good idea to simply encode values that err on the high side for inertia, stability and damping in each axis. The code in many FS releases has been very heavily influenced by code in CFS combat aircraft and is often wrongly extrapolated from 'fighter' values.

So, yes the MSFS weather model sometimes generates gusts of bogus amplitude due to data error, or bogus sudden boundaries between distant oceanic weather stations, but much of the problem is in the FD. And yes, currents can produce gusts (or not), but a wave / gust is not a current and in most cases a wave should only impose modest pitch up, (from near zero), causing modest IAS decay which should self restore. The bogus sudden boundary events should not invoke stall or structural failure from near zero pitch cruising. Even with most human data errors we should have time to avoid stall by addition of power and by pitching down. Save in some non propliner aircraft it should be possible to recover from stall, after stall.

We should never expect an AP to recover from stall and most may have maximum pitch rates that will not recover from the wrong side of the drag curve (IAS < Vbg <> Vx) without manual throttle addition. Using 'accelerated time' with AP ON does not manipulate all the pendulum time constants correctly within MSFS. We have all seen auto pilot induced oscillations (APIO) induced in still air as the AP servo control rates fail to cope with accelerated time and accelerated vehicle motion. When a gust is imposed in accelerated time an AP that would cope at 1x will not cope at 4x or maybe 16x. Nor in all probability would a human pilot. Yet for some reason there is an expectation that accelerated time should not impose additional stall / structural failure risk during gusts. It does and whether we add that extra risk is our choice.

If we use real weather we must accept that there will be data errors. They may cause departure from controlled flight. We can treat that as an emergency or we can just slew a few miles further on (not back!) and resume cruise knowing that what happened was a real world data error or a video game accelerated time error. Some of the human data errors will be so large that they will create gusts which even 'over realistic' inertia, stability and damping will not resist. Remember you cannot just increase those variables on their own after download without screwing up the flight dynamics in other ways at the same time. Lots of variables which do not appear to be involved in this stuff must move in concert with variables mentioned.

You may wish to take a break before reading Part 2 which deals with the outside air temperature (OAT) issues.

Continued in next post...

[Tom/CalClassic]

PART 2 - Outside Air Temperature = OAT

In everyday life around 94% of humans measure temperature versus the freezing point of water in the ISA. Many US aircraft have temperature gauges calibrated in C anyway. 20C is not twice as much as 10C. They must be converted to degrees Kelvin which begin at zero at absolute zero (-273C). 10C is therefore really 283K and 20C is really 293K. The difference is 10/283 = 3.5%. Even if temperature could jump by 3.5% in under a second in the open air, the wind speed could always change much faster in % terms than temperature. Wind speed can easily double in under a second. Air temperature never can.

However the point is that neither currents nor waves (neither wind speed nor gusts) affect power from an engine, whilst outside air temperature (OAT) does.

The amount of oxygen in a given volume of air depends equally on its pressure and it temperature. Oxygen is a large fraction of the fuel consumed by engines which produce ton after ton of CO2 and H2O. The H2O may soon turn to ice causing contrails. The CO2 is just pollution. The AVGAS or AVTUR only supply the C and the H. We must consume many tons of oxygen on each long haul flight to create many tons of pollution and rain.

Oxygen density varies with air density. How much power we can produce depends on air density. Air density depends equally on temperature and pressure.

Over planet Earth today the pressure at sea level in different places will vary from about 0.93 Atmospheres to about 1.07 Ata. The upper bound is about 15% above the lower bound. The temperature on the other hand will vary from around -60C to around + 50C. We convert that to Kelvin and we get 223K to 323K. The upper bound is about 45% above the lower bound. Although air density varies equally with change of pressure and temperature on this planet the temperature varies three times more. Hot things expand. Hot air is thin air. Across the whole planet today the average is 1 Ata and 15C = 288K at sea level.

The temperature at say FL80 over two METAR stations (typically just two airfields) only a few minutes flying time apart won't vary much. But Hong Kong and Anchorage are a long way apart and even if they have the same air pressure (QNH) they are likely to have very different temperatures. If the data entry clerk typed in the data correctly we will obtain much less power at a given MAP and RPM in hot air near e.g. Hong Kong than we obtain in cold air near e.g. Anchorage, but % variation of temperature as we fly along will be very gradual as MSFS varies it. However on an oceanic flight there are few weather stations and one may have very different weather to the next, so we may suffer sudden drop or increase in power applied when temperature varies by even 10C = 10K causing greater or lesser bow wave (IAS). The bow wave (profile drag created = IAS) diminishes because applied power was reduced, not because the fluid around the hull became thinner.

It is of course possible that temperature data entry error in a METAR could cause huge and sudden loss of power just like a QNH = air pressure error, but the original poster reported temperatures after the event that were 'normal' for the planetary location so I discounted bogus OAT variation as the cause of the incident.

OAT variation isn't about 'incidents'. It is much more important than that. The more the real atmosphere differs from the International Standard Atmosphere (ISA) cited above the more performance of aeroplanes differs from that reported in the 'Boys Book of Wonderplanes'.

Wind speed has no influence over power. Gusts have no influence over power. Air temperature varies power directly because it varies oxygen supply. This is just one reason that propliners have, and need, automixture. Failure to use automixture to vary mixture versus OAT in real time causes unnecessary and inappropriate variation of power in MSFS. OAT varies too suddenly and too often in MSFS for us to keep up manually whilst also performing many other crew roles in the cockpit. Manual mixture adjustment belongs in cheap, slow, low flying aircraft anyway.

Higher OAT = less power applied = less bow wave = less profile drag = less IAS = higher cruise pitch = inefficient cruising

Piston aero engineers only ever solved the lesser part of the problem. They added gas compressors to piston engines. If we are below the critical altitude of the supercharger it delivers the target MAP we demand with the throttle lever even if pressure (QNH) varies. In a propliner we can only control MAP (manifold air pressure) not MAD (manifold air density). Above the critical altitude of the gas compressor we must move throttle to sustain target gas pressure. We must advance the throttles when climbing above critical altitude and we must retard them at 3 inches or 0.1 C / Ata per minute when descending above critical altitude else we lose control of power applied and our IAS target in both directions.

The critical altitude of the gas compressor is lower when the QNH is lower. The critical altitude cited with MSFS FD is for ISA only; and in propliners it must be the critical altitude when the supercharger is running in cruise RPM (not TOGA rpm) else the Operational Ceiling in MSFS will be wrong.

Superchargers only compensate for pressure variation and only below their current critical altitude. Gas compressors never compensate for temperature variation. They are not refrigerators. In hot air we suck in less oxygen per stroke, the same MAP delivers less power, the automixture control delivers less AVGAS correctly, our range is preserved, our endurance increases, our profile drag created (bow wave = IAS) diminishes, and our pitch increases becoming inefficient at the hotter density altitude.

Turboprop engines on the other hand can be temperature trimmed, but not pressure trimmed. This is three times better, but still imperfect. In the CV58 or L188 we carefully target a TIT not a MAP. Turbine engineers never allowed aircrew to pretend they knew better than the engine creator what the mixture needed to be as OAT varied. The designers of the Allison 501 gave aircrew just a thrust lever and no other levers to play with. Aircrew were then 'empowered' to concentrate on the really important goals of IAS + VSI + pitch (energy state) targeting and accurate navigation in 4D.

The Lancastrian flight cited at the top of this thread was a 120 mile short haul at lowish altitude. In the absence of engine malfunction huge surplus power was available. The fact that + 7 PSI boost was needed to recover implies critically weak mixture, probably applied clandestinely by developer gauge code to punish the user for something he was deemed to have done wrong. Injection of a bogus surface temperature by a real METAR station data entry clerk in Uruguay can be excluded because ISA + 23 after the incident is 'realistic'.

However most flights in four engined propliners are not short hauls. For the reasons stated above OAT is the primary weather factor controlling Operational Ceiling (OC). Unless the flight is a short haul we must always determine OC and cruise just below OC. With no significant tailwind we must not exceed our Operational Ceiling. During initial climb we avoid doing so by monitoring IAS or VSI in relation to the OC climb rejection criteria in the handling notes. When we must reject climb depends on weight and weather, especially OAT.

With a significant tailwind we may extend range, increase speed (KTS) and increase profit by cruising just above operational ceiling, as explained in my first post(and the 2008 Propliner Tutorial) , but we must always know what our operational ceiling is at our present weight in the present weather. Our OC is determined mostly by OAT.

I am never sure whether I should analyse and comment on voyage reports posted here. They do provide me with an excellent way to understand which finer points of propliner operation FS users may be struggling with. The problem is that if I don't then bother to illuminate why encoded realism may not have exploited to the full, only I am the wiser. So I hope dutch11 won't mind if I use his B377 flight report to illuminate for the benefit of all how 4D navigation during that voyage differed from the guidance provided within the B377 'Read before Flight.txt' and how the handling notes and the supplementary documentation help us to extract additional flight profile (4D navigation) and energy state targeting realism from the supplied flight dynamics, as OAT varies.

For a B377 Stratocruiser we need to start with the supplied aircraft specific, 'Read before flight', which says;

>>>>>>>>>>>>>>>>>>>>>>>>

OPERATING TECHNIQUES

This first generation of long range postwar aircraft were challenging to operate and the following is mandatory reading if you hope to replicate a real world flight in any B367/377.

Firstly the Boeing 377

It is very easy to climb any Stratocruiser to flight levels where it cannot sustain an adequate cruising speed. The (R-4360-TS3B-G) engines cannot be flown continuously in climb power (45.5 inches and 2350 rpm), the maximum for cruise is 41 inches and 2100 rpm. In the real world the navigator would calculate the earliest time at which it was sensible to step climb another 2000 feet. In MSFS you will need to use a dynamic technique.

Passing 9000 feet or FL90 reduce rate of climb to 500 VSI with 45.5/2350 set. Monitor your airspeed closely. As soon as your airspeed falls to 175 KIAS level off at the next flight level. You have reached your operational ceiling and cannot climb any higher until you have burned off more fuel.

Accelerate > 190 KIAS in climb power and only then reduce to max cruise power (41/2100). After about 30 minutes you should be able to climb another 2000 feet at 500 VSI using climb power. Assuming you do not have a headwind, keep doing this until you reach FL250 several hours into the flight. Never climb into a headwind unless you need to cross mountains or are required to maintain a minimum cruising level by ATC. When you level off always accelerate > 190 KIAS in climb power, and only then reduce to max cruise power. If the speed decays through 190 KIAS in max cruise power (41/2100) you have exceeded your operational ceiling. Request a 2000 foot descent from ATC and attempt to establish > 190 KIAS cruise with 41/2100 set at the lower level.

Flying at 190 KIAS is not economical, but until you reach FL250 you want to use up the fuel at high airspeed to allow you to climb higher. Once you reach FL250 you must alter your technique. Once established in the cruise at FL250, gradually reduce MAP below 41 inches at 2100 rpm to keep speed down to 180 KIAS. Once you start to exceed 180 KIAS with 38/2100 set you must sustain 38 inches and begin to reduce rpm instead to maintain 180 KIAS. You may run out of fuel on a long flight if you do not manage economical cruise power at FL250 well, and at the earliest opportunity.

180 KIAS will yield about 265 KTAS at FL250. That is the optimum cruise condition, as the pressure cabin cannot withstand higher altitudes, but in a Stratocruiser it will take a very long time to establish this optimum cruise condition.

>>>>>>>>>>

Notice in a particular that the tutorial exhorts use of max cruise power for cruising, (only in the Strotocruiser), until / unless we are light enough to cruise at FL250 which is our certification ceiling. We must however understand that in adverse (hot) weather (places) we may never reach FL250. It may be too hot all along a particular route and we never step climb into a significant headwind either, (see 2008 Propliner Tutorial).

The step by step on screen handling notes say;

***********************************
En route Climb Power: (Climb stage 2)

COWL FLAPS - MID
2350 RPM
45.5 inches MAP

Minimum 500 VSI <<<<<<<<<<<

In high temperatures SPEED MAY DECAY at 500 VSI

IF UNABLE to maintain =>175 KIAS <<<<<<<<
REQUEST LEVEL OFF & STEP CLIMB from ATC <<<<<<<<
***********************************

Once we achieve stage 2 climb we determine initial Operational Ceiling by climbing at VSI = 500. When IAS < 175 we reject climb at the next semi circular level. Departing Hong Kong this could easily be only FL130 /140, or even less if we are full or the weather is especially hot. Ex London in colder air our initial OC will be higher at the same weight.

As we cruise along in a B377 we must still monitor our profile drag (IAS). At all times we must supply enough profile drag over the wings to achieve efficient low pitch cruising.

***********************************
Max Cruise:

COWL FLAPS - CLOSED
2100 RPM
41 inches MAP
If unable => 190 KIAS descend to lower level
Plan 650 GPH
Note: - Yields 295 KTAS at FL250
***********************************

Usually our weight will reduce fast enough (650 GPH of low density US 145 Octane AVGAS = 3900 PPH) that even if we are flying into hotter air, having step climbed we won't need to descend again, but if OAT rises fast enough we will.

<<I am able to cruise at FL210 at about 185 KIAS,>>

In a B377 (only) we are willing to expend fuel quickly when heavy to increase our operational ceiling quickly. We use max cruise power and we ensure our profile drag is at least 190 KIAS using the power targets above. This restricts how high we ever climb or cruise even with no significant headwind. The optimum level at that weight was only FL190.

<< but when flying the legs into Bangkok and Hong Kong, I was only able to manage about 176 KIAS at FL190>>

We should have descended to (or not climbed above) FL150 to sustain at least 190 KIAS. We were too high and our cruise pitch was too high, causing profile drag (IAS) to be too low for efficient cruising. Our wings needed more profile drag to be efficient. We were risking fuel exhaustion (if we needed to divert from Hong Kong) by operating well above our Operational Ceiling in that hot weather.

In passing note that the 'Service Ceilings' we may read about in the 'Boys Book of Wonderplanes' are of no consequence. For a propliner it is efficient flight using only cruise power that determines how high we ever climb or cruise and that varies with the weather, (but mostly OAT), place by place, leg by leg of our flight plan, and hour by hour.

<<, the OAT only being about -5C.>>

In the ISA temperature is always 15C at SL and declines by 2C per flight level. So B377 'book performance' at FL 190 is based on 15 - (19 * 2) = -23C. So at -5C we were suffering power loss due to ISA + 18; almost as bad as the Lancastrian over the Rio Plata (+23).

Flight simulation is mostly a strategic 4D battle against the highly variable weather over planet Earth not a tactical battle to control the aeroplane.

<< I was flying the Strat at FL210 at about 204 KIAS,>>

We would be 'noticeably nose down at 204 KIAS. Now we are generating too much profile drag to maximise profit, we are pointlessly exposing the top of the fuselage and the top of the tailplane to the oncoming 2 x hurricanes of profile drag. By doing so we are risking fuel exhaustion (if diversion required) by adding that unwanted drag and we are risking structural failure in the next gust. We should have step climbed to FL230 earlier to reduce profile drag (KIAS), increase pitch, and increase cruising velocity (KTAS). If we were deliberately nose down with high profile drag to battle a significant headwind we should have been much lower than FL210.

Efficient cruising below FL250, in the absence of a significant headwind, requires the profile drag to exceed 190 KIAS but we do not allow cruise pitch to become noticeably negative. When IAS < 190 we are above our operational ceiling and when pitch < zero we are below our optimum cruising level in the present weather (mostly OAT).

<<This is often the reason you get a pronounced nose down attitude in the DC-6/7's and many don't recognize the problem. If temp. drops, so will your nose.>>

Yes indeed. Or any other aeroplane. Cold air increases applied power at constant pressure and our bow wave (IAS) increases. That drag increase is unwanted. Our Operational Ceiling has increased in that colder air. In the absence of a significant headwind we intend to cruise at the highest semi circular level below our present operational ceiling. Our power has increased, so our operational ceiling has increased and if that causes nose down pitch (excessive bow wave), our operational ceiling has increased enough to step climb another 2000 feet to the next semi circular level. With real weather invoked achieving a realistic flight profile (realistic 4D navigation) requires us to enter a captaincy decision making cycle at least every twenty minutes in the cruise to review applied power versus head / tail wind vector and flight level v pitch and IAS.

With no significant headwind or tailwind it is our job to impose the correct cruise pitch which is never much above zero, and always at more than any minimum cited IAS, by 4D navigation in real time. 2D navigation is always the easy part. However on long enough hauls in favourable weather, (maybe over the much colder North Atlantic), we may reach certification ceiling and then our operating target is usually exactly zero pitch, but sometimes it is a defined IAS to reduce engine wear to maximise profit by trickle reduction of MAP and/or RPM. The engines on the B377 are horrendously expensive to maintain. In a B377 we have another reason to restrain our profile drag at high altitude rather than targeting zero pitch cruising. We must avoid transonic shock.

***********************************
Final Cruise at FL250:

38 inches MAP
Gradually reduce rpm from 2100 to maintain 180 KIAS
Yields 264 KTAS in ISA
MINIMUM 1400 rpm
****************************

Once we have achieved our ultimate and infrequent goal of attaining certification ceiling we concentrate on safety and profit not cruising velocity. A velocity of around 264 KTAS with profile drag retrained to 180 KIAS will do nicely in air as cold as it will be if our Operational Ceiling ever equals our Certification Ceiling. As it gets colder we are getting closer and closer to Mno and closer and closer to structural failure in the next gust.

On a short haul we plan a final cruising level well below our both our Operational Ceiling and our Certification Ceiling (see 2008 Propliner Tutorial). We self impose a lower final cruising level. Our cruise target is then zero pitch at that lower final level. This is quite different to a long haul. Until the captaincy decision making cycle just more than 20 minutes before Time of Descent we are always contemplating the possibility of another step climb during a long haul unless we have already reached Certification Ceiling.

The USAF did not impose a certification ceiling on the B367 Stratofreighter. The civilian B377 Stratocruiser achieves maximum cruising efficiency, (maximum profit, not optimum dynamics), if we eventually impose a profile drag of 180 KIAS at FL250 at 38 MAP with minimum RPM (friction = engine wear) subject to RPM > 1400, since less may invoke harmonic vibration.

How often we ever manage to reach FL250 to impose a profile drag of exactly 180 KIAS, and our associated target velocity of about 264 KTAS, depends on the weather and how good our fuel planning is. We mimimise our fuel load consistent with safety. We calculate fuel required carefully using the relevant planning value in the handling notes. In this case we must plan fuel required using 3900 PPH and 295 KTAS because we may never reach FL250 and may max cruise all the way. The fact we will never reach 295 KTAS is irrelevant. The miles per gallon will self resolve on the safe side. We should use the methodology in the 2008 Propliner Tutorial. That methodology is already replicated in any Calclassic Notepad that may exist for some Calclassic hosted aircraft.

Operational Ceiling is a crucial concept for propliners. 'Realistic FD' are much talked about and requested, but they do not 'script' realism. The user has to deploy substantial knowledge and skill to extract it. The real values are all in there waiting to be unlocked, but only if the developer explains what they are and how to unlock them. The truth is that explaining how to unlock the realism is more difficult than encoding it. The problem (for Calclassic aircraft) is not lack of documentation or explanation. The on screen handling notes are essential as shorthand memory jogging tools, but the devil is in the detail, and in the Tutorials. The problem is that compliant operation is difficult to explain, difficult to understand, and even more difficult to put into practice.

When using MSFS the issue should never be one of 'failure' in any sense, human or engine. The issue is compliance, or rather learning to comply with many specified targets, specified limits, and specified procedures, both aircraft specific and generic within the Propliner Tutorial. MSFS is a learning tool not an examining tool. We have no hope of real time one to one instruction so we must be allowed to 'fail to comply' in many ways whilst we 'learn to comply' at our own chosen pace. Punishing non compliance does not encourage learning. It frustrates learning. Most FS users want to be able to learn new complexity at their own pace or not at all. If readers are not ready to incorporate this level of realism that is just fine. It is there waiting to be unlocked anyway.

I struggle to work out how to explain compliant operation without resorting to equations. I find it difficult to predict which finer points of propliner operation will be misunderstood or not quite grasped. I don't know how to shine a spotlight on topics not quite grasped, other than by using forum content to illustrate the nature of the non compliance.

If compliance at the level I exhort and describe, (but often fail to achieve myself), were not extremely difficult airline pilots would be paid very little for their knowledge and skills. I know full well that achieving compliance is difficult, but that's what makes flight simulation interesting. The rules and skills of this game are not only complex. They are real.

Tom and I are always looking for ways to make the formidable process of compliant aircraft operation easier. The CalClassic Notepads are an important addition. They already ease the burden of accurate fuel planning, diversion planning, time of descent planning, significant headwind and tailwind calculation, etc, etc, for those who either struggle to create realistic flight plans or who do not bother. We hope to add automated Operational Ceiling planning which will allow for both pressure and temperature variation from ISA conditions by Easter.

However some / many Calclassic hosted aircraft may never acquire Notepad planning tools, and many downloader's will never use them, so my handling notes will continue to set out OC planning criteria in shorthand anyway. However the OC values calculated by any prospective Calclassic Notepad may be more accurate. Temperature, headwinds, tailwinds and other weather factors are major issues within 'realistic' flight simulation. They vary compliant operation of the same aircraft substantially hour by hour, leg by leg, and route by route and the more weather is incorporated, and the more full compliance is attempted, the greater the variety of experiences.

FSAviator.