Stearmandriver

Dunno, you seemed to suggest that it's correct that the PMDG flies an arc as a series of straight segments but "that's ok, that's exactly how you fly a DME arc in real life.". It's... not. I'm also not sure what seemed "elaborate" about my correction. But cool, as long as we're all on the same page now that the PMDG definitely doesn't behave correctly in LNAV. It's a great addon in almost all respects, and sure, for a sub-$100 game allowances can certainly be made... But this is really something you should hope for them to improve.

Yeah I get that; it's just that you only said "handflying a DME arc" without specifying aircraft type as if it was done that way in all airplanes. Just pointing out that it's done differently in the plane the thread is about. ;) Handflying any LNAV procedure in the PMDG is less than comfortable these days because of the way the lateral guidance fluctuates. It's quite a separation from reality.

I'm with you. I'm just describing the other school of thought, which I do see merit in after years as a check airman: we'd really rather not have pilots evaluating an abort decision on a case by case basis. That's a recipe for delayed reaction times, fatigue-induced indecision or confusion on a multi leg day etc. There's value in having the decision be basically automatic: you're rejecting for these items within this speed regime, and you're continuing for anything else, and at V1 you're going for everything, period. Every takeoff, without exception. Adhering to those standards, margin is irrelevant. Now the flip side is, I do see the value in using margin as a determining factor as to whether you'd choose to request more conservative data. The flip side to THAT is, if your airline has default required margins set to a comfortable value, you won't need to... Can be argued either way but I think I fall in the camp of not wanting to bias a captain's abort decision, but just keeping it standard. Of course in MSFS, it's irrelevant. I was just saying that it's not necessarily unrealistic that the EFB not provide these margins, as many real world operations intentionally do not. Also though,I thought margin was graphically displayed on the runway graphic at the bottom of the tablet screen? I've only tried it a few times so not sure I'm remembering right though.

Sure, you can always manually define if you want data for a specific flap or bleed setting or thrust rating. The idea is just that once you have this data, margins don't matter - just fly a standard profile.

I will point out that this is not necessarily true. Accelerate go and accelerate stop (and many other factors) are all accounted for correctly in a proper takeoff data solution that is specific to runway, conditions, and weight. At work, I never see accelerate-stop or accelerate-go. I just use the takeoff data given: thrust setting, flaps, bleeds on/off, and V speeds. Abort for anything below 80kts, high-speed abort for fire, failure, fear, or shear prior to V1, go afterwards. That's all you need to know is V1, assuming you have well-calculated data. In fact there is a school of thought that says it's better not to provide specific margins to pilots because it may bias them to abort or go, and we really just want them to fly standard and use the V1 call as decision point. So it's not really unrealistic for PMDG to not provide these distances.

Hand flying a DME arc in a real 737 is nothing at all like what you're describing, is the point. In reality, an arc is drawn as an smooth, single-radius RF segment. The flight guidance tracks this smooth continuous curve perfectly. It commands one smooth roll into a turn, maintains the bank angle necessary, and commands one smooth roll out. When handflying, this is what you follow. You absolutely do not make a series of 10 degree segmented turns like you would in a bug smasher. PMDG's LNAV flight guidance is definitely not correct, and this is definitely not open to interpretation or opinion - it's demonstrable. Yes, it will get you there in the end, but it's very sloppy compared to the real airplane. Anyone on this thread that thinks it works correctly, feel free to post a video of you flying a complex LNAV procedure in the PMDG that you think went well, and I guarantee you that myself and others here can tell you all the things wrong with it.

But once again you're making invalid comparisons. The original Max was self-certified by Boeing, meaning there was very little oversight from any regulatory agency. After the accidents highlighted the problems in Boeing's safety culture, that airplane was grounded. The current Max has been redesigned as necessary, and not only the changes but the ENTIRE AIRPLANE have been scrutinized with the finest-toothed comb any regulatory body could find; by the FAA, the EASA, and several other global regulatory agencies. The two "certification" processes were at complete opposite ends of the spectrum, in terms of what "certification" means. The Max truly, objectively, is the most thoroughly vetted and proven aircraft in commercial aviation history at this point. That is not hyperbole, and there really isn't any room for opinion either, the facts are so overwhelming. People can believe the earth is flat too, but they can't actually justify that position. 😉

First, MSFS can of course use C++ natively as well; that's what web assembly is, after all. So it still doesn't make sense to claim that there's an advantage to P3d here. Secondly, I'm not the one who claimed there was a systems fidelity advantage to c++ on P3d; the iFly post claimed that. I'm not making things up to point out that this is untrue. Their post further singled out cat III approaches, giving us something specific to compare and as I explained, there's nothing more accurate about iFly's version.

It's worth noting that the Maxs flying today aren't the same airplane that caused the accidents. There was a significant redesign, and the entire aircraft - not just the related systems, but the ENTIRE AIRCRAFT - was completely re-certified. The Max in its present state is the most thoroughly vetted - and therefore likely the safest - aircraft in airline history.

Definitely not interested in a "sim vs sim" discussion either, but just wanted to point out a categorical untruth in this statement. There's nothing more accurately simulated about a cat III approach in the iFly in P3d than there is simulated by the PMDG in MSFS (or P3d for that matter.). That's just a marketing statement that kind of calls their credibility into question.

All that needs to match is the ZFW. Pax counts etc are irrelevant. They'll change your CG, but the PMDG distributes weight intelligently when you enter a ZFW on the payload page... Just double click the CG box on the takeoff ref page to have the CG autofill, then set takeoff trim. Trailing spoilers is an excellent thought here. It's almost certainly SOME kind of control binding issue, since obviously no one else is having the problem (re-installs hardly ever fix anything in flight sim.)

You could do all the unreliable airspeed lookup stuff... Or you could just realize that you've got an AoA gauge staring at you on the PFD and in the HUD, and put the needle in the approach band and be done with it 😁. Airspeed on approach is really just used as a proxy indication of AoA, but is only accurate at 1g and only if you have your weight correct; if you have a direct measurement of AoA that's always going to be more reliable (obviously excepting a faulty indication) because weight confusion, data entry errors, load factor, or anything else just don't matter... Correct AoA is always correct, at any weight or load factor. In the OP screenshot, the AoA is well above the approach band.

It's a new tablet feature.

The plane is definitely heavier than the box thinks it is... But that doesn't explain all of this. In reality, a 737 can be landed at MGTOW, you just write up the overweight landing for an inspection. This is why the airplane doesn't have the ability to dump fuel for an emergency return - it doesn't need to. You can land flaps 30 or 40 in those cases, and you may be within the lower amber airspeed band (below full maneuver speed for that flap setting) but you'll not have an A in the airspeed window, nor would you have a complete lack of maneuver margin present on the speed tape. I've never tried this in the PMDG, so I can't say if it's a problem with your setup specifically, but some of the NG models do have strange indications for low airspeed at high flap settings. On the -700 for instance, the red low speed band (shaker activation) is not even visible at approach speed. One of those low priority items I expect they'll get to eventually.

Neofly4 has a freelance mode where you can start wherever you like, in whatever airplane you like, and it'll generate appropriate missions. Works great for controlling where and what you fly, much easier than selling, renting, editing etc.

It does though, unless you're talking about cat IIIc. Cat IIIa and b do have published mins. Our ops specs have us disregarding a, b, or c mins and applying the same across the board to any cat III so they're actually less restrictive in many cases. But yeah, lots of cat III approaches do have published mins, and if an operator does not have ops specced relief from them, they're bound by them. (A, b, and c are the old classifications but still used in documentation; these days I think the only difference is a cat III with a DH of 30m, or no DH. Same differences apply though - a cat III may have a published DH, which ops specs may alter either way.)

Is there really an app that grades you on serving meals? Yeah... Try, as pilots, telling the cabin crew when and how to do their service... No coffee or crew meals for the rest of the trip lol.

Worth a try, but unless it's changed since I tried it, probably not as all it seemed able to do was follow a script. That's one of the reasons I like MCE; I can decide what I want done in the cockpit and he just does as he's told ;).

That's only true in aircraft with a 3 axis autopilot. In the 737 for instance, our ops specs dictate that a Cat III using either autoland or handflown AIII has a decision height of 50ft RA, and 30ft RA if flown as an autoland monitored with AIII.

I use Multi Crew Experience, so I just tell my FO "set MDA 5542" and it happens. It takes the same amount of time, but I can be doing other things in the meantime and can even have my FO do other things while he's setting mins; he's a good multitasker 😉.

It's in the MSFS control bindings, but it's named strangely and that makes it hard to find. It's something like TO GA, with the space in the middle.

Oh it's for sure proven... I've done it in sailboats. Just seems different in an airplane ;).

Tell me about it! This stuff is fascinating to play with in the sim, but the prospect of striking out across an ocean in reality with nothing but dead reckoning and a sextant is terrifying. 😬

A great one! And it's about to get even better, with manual user manipulation of the shot itself, and then autocompletion of the precomputation form, and even autoplotting. This is in a beta version that should be out soon. But the current version comes with great documentation / a tutorial to teach you how it all works. You just have to do some of the grunt work yourself... Soon there will be automated options though. I've done a little testing of the new stuff and it's awesome. https://flightsim.to/file/17738/celnav-for-msfs-celestial-navigation-sextant

The DC-6 remains my favorite plane for oceanic celestial nav flights. Gyropilot does a fine job at holding heading and altitude.