LRBS

I see, but can't find any "about the requirement for custom control settings".

Do you have a link to that? It would help a lot to take a look and reevaluate. Meanwhile, I just spent an hour and a half in the 757 Level D sim, courtesy of one of our instructors, and came to the same conclusion as @ahsmatt7 about our findings.

Of course, there are limitations, just as there are even in Level D simulators. Surprisingly, some of today’s aircraft add-ons stand out for their flight dynamics, coming remarkably close to Level D simulator standards. Certification, however, is an entirely different game. Asobo is responsible for the underlying simulation platform, its flight-model capabilities, and the SDK and tools made available to third-party developers. When those tools have limitations, or when certain systems and programming aspects are not sufficiently exposed, developers are restricted in what they can achieve, regardless of their expertise. Third-party developers, on the other hand, are responsible for how well they understand and use the tools available to them. They must get the aerodynamics, flight-control response, engine performance, and overall aircraft behavior as close to the real airplane as possible. The SDK may impose limitations, but it does not excuse every shortcoming in a flight model. Some developers have demonstrated that, with the right programming expertise, a solid understanding of aircraft dynamics, and careful testing, it is possible to produce a remarkably convincing simulation within the platform's limitations. Ultimately, Asobo must provide the right foundation, and developers must make the best possible use of it. Both have a responsibility to improve the overall fidelity of the simulation. And, of course, replicating realistic flight dynamics is one thing; meeting the rigorous requirements for actual Level D simulator certification is quite another. As for the YouTube creators, I’m with you 100%!

The PFC, no; RTRHOBBY B737 force feedback has its own proprietary software. Interestingly, both are quite close in feel, regardless of profile. To be honest, I did not expect that.

Just a thought: the Boeing 757 is not a twitchy airplane. Unfortunately, the BB757 shows some of these characteristics, but I believe we can correct them with relatively straightforward flight-model adjustments. My question to this “757 pilot” would be: Which airplane is he using as a reference for comparison? Responsiveness, control sensitivity, and control feel are not interchangeable terms. When he says the nose wants to come up, we need to distinguish between CG, stabilizer trim, and the aircraft's pitch response. For every takeoff, the actual loading and CG must remain within approved limits, and the stabilizer must be set according to the applicable takeoff data. The FMC or approved performance calculations establish the required takeoff parameters; the stabilizer setting is not simply a means of correcting an out-of-balance airplane. The smooth rotation shown in this clip is consistent with a properly executed rotation, and establishes that the CG or trim setting is correct. I would also question the YouTuber's interpretation that the pilot is pushing the yoke forward to maintain speed. From what is visible, the pilot appears to maintain aft control pressure while trimming to relieve the associated control force. Without cockpit indications and control inputs, however, we can't determine the exact control-and-trim sequence from the video alone. Another important distinction: engine power has nothing inherently to do with control sensitivity. The 757's powerful engines do not make it twitchy. An airplane can respond positively and promptly to a control input without being excessively sensitive. We must distinguish between the aircraft's response to a given control input and the control force or displacement required to produce that response. Control sensitivity describes the relationship between input and response; control feel concerns the forces the pilot experiences at the controls. They are related, but they are not the same thing. The 757 should respond positively to elevator inputs without feeling excessively light, nervous, or prone to abrupt pitch changes in response to small, normal inputs. That is the behavior I believe needs attention in the BB757 flight model. The Boeing 757/767 Flight Crew Training Manual emphasizes small, measured control inputs when manually maintaining altitude at cruise altitude and high speed. At those conditions, relatively small inputs can produce meaningful flight-path changes. That is normal transport-category aircraft behavior, not evidence that the airplane is inherently twitchy. Finally, takeoff rotation must be considered in the context of the correct loading, CG, stabilizer trim, thrust, and rotation technique. Across aircraft such as the 707, 727, 747, 757, 767, and 787, the pilot should be able to achieve the prescribed rotation and establish the required initial climb attitude without fighting an abnormal pitching tendency. The aircraft should then be controllable along the intended flight path, with the appropriate speed target—the airplanes will easily settle to a V2 + 10 up to 20 effortlessly. My point is simple: the real 757 is a powerful, responsive, and well-designed transport-category airplane. It should not feel nervous or excessively sensitive merely because it responds positively to the controls. I believe the BB757 would benefit from a careful review of its pitch response, control sensitivity, and stabilizer-trim behavior (by the way, stab trim is slow) to achieve a linear response. Getting these characteristics right would make a meaningful difference in bringing the simulation closer to the real airplane.

100% correct! Unfortunately, some people took offense at BlueBird’s recommendation to study the manual. In my opinion, that is excellent advice, particularly for an aircraft of this complexity. We need to keep in mind that a real-world airline pilot’s type-rating process involves considerably more than simply getting into the cockpit and learning to fly the airplane. Depending on the airline and training program, the process typically involves several weeks of ground school, systems study, and technical examinations, followed by simulator training, an oral examination, and a final simulator evaluation. Simulator training itself commonly spans approximately 10 days, although the exact duration varies by program. If that level of preparation is necessary for a qualified pilot transitioning to a new aircraft type, why would anyone expect to master a sophisticated simulation of that aircraft without studying its systems, procedures, and operating logic? Even a Cessna 152 requires familiarity with its operating handbook and checklists. The difference is the depth of systems knowledge required, not the importance of preparation. That said, let's be clear: the BlueBird 757 has genuine bugs and shortcomings. I have encountered several myself, including issues that should be immediately apparent to anyone with real-world experience on the aircraft. Can these problems be fixed? Absolutely—and the developers should address them. However, we must distinguish between an actual programming or flight-model defect and behavior resulting from an incorrect procedure, an improperly configured system, or a misunderstanding of the aircraft’s operating logic. So, yes, a considerable number of complaints can be resolved simply by understanding the aircraft and studying the documentation. Those complaints should not automatically be dismissed, but neither should every unexpected behavior be labeled a bug before the facts have been established. Learn the airplane, verify the procedure, and then report the problem. That is how we help the developers identify genuine defects (if they listen), improve the product, and ultimately deliver a more accurate simulation.

@jon b , thank you so much for your kind words! From the day I started flying, throughout what I consider my golden years in aviation, I’ve come to realize that there’s always something new to learn from every flight, simulator session, and even a simple discussion about flying. Even today, I’m blessed to continue learning alongside my colleagues in the sim. We share plenty of laughs at what we think we know, while constantly reminding ourselves of just how much more there is to learn and how much room we all have to improve. That, to me, is one of the beautiful things about aviation: no matter how much experience we accumulate, we never stop learning. Thank you again for your kind words! 😊

Indeed, such an unpleasant inconvenience with this "Nest"; who would have thought it wouldn't start automatically? Dah!

Could you please let me/us know which yoke and sensitivity settings you’re using?

Sorry for the confusion; I actually agree with you 100%. It was for the other guy.

If that’s true, then there’s a serious problem. The airplane simply shouldn’t fly like this. If you compare the iFly 737 with the PMDG 777, the control feel should fall somewhere in between. There’s clearly room for improvement, and this should be a relatively straightforward fix.

I'm using PFC 737 and RTRHOBBY B737 force feedback with these settings. The airplane can be tweaked to achieve satisfactory results, but I was expecting something different.

Sorry, but you’re wrong. @ahsmatt7 and I have flown the real airplane, and he probably has more hours on it than I do. Regardless, this model is nowhere near an accurate representation of how the 757 actually flies. The controls feel far too light, and the aircraft is excessively twitchy. The 757 is known for its substantial, positive control feel, particularly in pitch. It is not a 767, which is noticeably lighter and more sensitive on the controls. These are distinct aircraft with distinctly different handling characteristics, despite their common type rating. If they really did use a 737 pilot as a consultant for the 757/767, perhaps that explains the problem. Knowing how to fly a 737 does not automatically mean you understand how a 757 should feel and respond to control inputs. The flight model should reflect the actual aircraft, not the characteristics of another Boeing type.

Installing it was a much more complicated process than with my other purchases—A BIG HASSLE! Unfortunately, the textures are disappointing. I took it on a short flight from JFK to LGA: It is way too sensitive for a 757/767—not realistic. LNAV/VNAV has been a "pleasure" so far, though I haven’t tested it extensively. I couldn't get ATIS. The A/P and AT mapping work for all the other airplanes, but not this one. I couldn’t find a way to set my startup situation, as I can with PMDG or IFLY. I have to go to work, so that’s all for today.

100 % correct. It was just an honest opinion/view on this.

You are 100% right—it’s not just PMDG. That said, we need to make one thing absolutely clear: I did not criticize the product before release; I voiced my criticism only afterward. My opinions were based on firsthand experience with aircraft I had flown extensively, whose FCOMs I knew, and whose systems, handling, and operational characteristics I understood. Furthermore, in my opinion, regardless of how impressive a showcase may be, it means very little if the person evaluating it lacks the knowledge and experience to understand what is actually being demonstrated. Time will tell. There will undoubtedly be bugs—some people will identify them, while others will insist they do not exist. That has always been part of this hobby, and no amount of marketing or showcasing will change that.

Somehow, we’ve gone from discussing a demonstration to being told to do our homework. Of course, but how else would you determine whether the aircraft is accurate without consulting the FCOM? That, however, is precisely the point: consulting the FCOM is research; demonstrating the product is the developer’s responsibility. They are not the same thing. Perhaps I’m old-fashioned, but I consider “I’d like to see the aircraft demonstrated before spending $80” an entirely reasonable expectation—not an unreasonable demand. And expecting a YouTube video to demonstrate the aircraft’s full capabilities is hardly realistic. A video can showcase selected features, but it cannot establish the depth, accuracy, and reliability of the product as a whole. As for the price, it’s their product, and they’re free to charge what they consider appropriate. Equally, potential customers are entitled to expect meaningful evidence of what they’re paying for before committing their money.

I hope you realize that fully demonstrating a product’s capabilities before release is virtually impossible. To my knowledge, no developer has ever comprehensively demonstrated everything their product can deliver; in fact, many carefully avoid showcasing bugs or limitations. We’ve seen other developers publish abundant promotional material, praise their products, and showcase their features extensively before release, yet nobody seemed to go to the lengths you are going to criticize this product before it even launches. That contrast is precisely what makes your approach questionable. I would understand criticism after release, once you’ve spent several hours testing the product and become thoroughly familiar with its systems and capabilities. Until then, I believe it is premature to draw conclusions.

You simply cannot please everybody. However, let's not overlook a rather inconvenient reality: when other developers have released aircraft with demonstrable flaws in their systems, the very enthusiasts who claim to value depth and realism have often been overshadowed by those who either ignore the deficiencies, pretend they don't see them, or dismiss them with arguments such as “it doesn't bother me” or “it's good enough for me”—often for products in virtually the same price range. And what about previous showcases? Some have been misleading, incomplete, or riddled with inaccuracies, yet there was remarkably little criticism from the same people now demanding a higher standard of transparency and demonstration. Those products were purchased, sometimes with little more scrutiny than one would give to buying a cup of coffee, while legitimate questions about systems fidelity, operational accuracy, and overall depth went largely unasked. So, I beg to ask: what has changed so drastically now? Is the expectation of transparency and technical accuracy suddenly different, or does it depend on which developer is being scrutinized and which product people are willing to defend? Demanding a proper demonstration of an expensive product is entirely reasonable. But applying that standard selectively, while overlooking comparable or even more obvious shortcomings elsewhere, is not consistency; it is a double standard. Ultimately, the issue isn't whether a developer should demonstrate an aircraft's capabilities. Of course they should, particularly at this price point. The issue is whether we are applying the same critical standards to everyone—or only when it suits our expectations.

100% Joking aside, if he was lonely, why not simply “request that a cabin crew member OCCUPY the First Officer’s seat in the cockpit”? Perhaps we should pay closer attention to the actual wording rather than fall for distorted “news” or make sensational statements designed to feed people’s appetite for nonsense. The key detail here is that the captain declared a “Mayday.” Under ICAO Annex 2, paragraph 2.3.1, the PIC may depart from the Rules of the Air when such departure is absolutely necessary in the interests of safety. Similarly, the FAA authorizes the captain, in an emergency requiring immediate decision and action, to take whatever action is considered necessary and deviate from prescribed procedures and applicable Part 121 requirements to the extent required in the interests of safety. The fundamental point is that a declared emergency gives the captain emergency authority to act in the interests of safety. Whether a particular action is legally justified depends on the circumstances and the specific regulations involved, but when interpreting the facts, the emergency context should not be ignored. Plus, these news outlets need to stop their interpretations and educate themselves before spreading "spectacular news." And food poisoning remains a serious threat.

This is more likely.

IMHO, POSKY was the undisputed gold standard in FDE, arguably unmatched by anything else at the time. Those airplanes were an absolute joy to fly, and hand-flying them was one of the most rewarding experiences in flight simulation. Few, if any, ever came close to capturing that same feeling.

That's interesting. Based on my experience and understanding of the statistics, I believe passenger airlines are generally safer than cargo airlines, although the comparison depends on the type of operator and the metric used. Another important factor is flight-duty and rest requirements. All-cargo Part 121 operators are not generally required to use Part 117, as passenger operators are, and may instead operate under the applicable cargo-specific rules. Looking back at my own experience, some of those cargo flights—boxes, after all—raised serious questions about operational risk and required more careful planning and stricter handling than passenger flights. At the time, I often felt that the margin for error was smaller than many people might assume.

I may be misunderstanding your point, but my personal opinion is that if an aircraft is truly native to MSFS 2024 and uses its new modular structure, I would hope that at least some of the longstanding issues dating back to the FSX and P3D era would have been addressed, rather than carried over to a new simulator platform. That said, this drag issue is something new to me, as I haven't noticed it with the PMDG aircraft since SU7. Perhaps I'm misunderstanding the relationship between being “native” and the underlying flight-model implementation. I'm certainly open to being corrected. Ultimately, I just hope they investigate and resolve this issue properly, as they claim.

Perhaps I'm reading this wrong, but the Asobo B738 Max8, 748I, and 747F claim to be native to 2024 and use the new modular structure. I’m skeptical of PMDG's claims of being "native," given that the same bugs from the FSX era have carried over. Time will tell.