LRBS

I don't believe a comprehensive, publicly available database exists that accurately documents the detailed configuration of every individual aircraft. The primary reason is that aircraft manufacturers provide operators with extensive configuration and optional equipment selections. Each airline customizes its fleet according to its operational requirements, regulatory environment, and budget. While the engine type generally remains unchanged throughout the aircraft's service life, engine control software and performance packages may be updated over time. In addition, aircraft are continuously modified through service bulletins, manufacturer upgrades, Supplemental Type Certificates (STCs), and airline-specific retrofit programs. It is not uncommon to encounter airframes that have received upgrades to avionics, radios, flight management systems (FMS/FMC), displays, or other cockpit equipment that differ significantly from their original delivery configuration. As a result, the most reliable source of configuration-specific information is often a pilot or maintenance engineer with direct operational experience on that aircraft within a particular airline. Even then, fleet standardization is not guaranteed, as aircraft may undergo major retrofits during their operational life, resulting in substantially different cockpit layouts or system configurations compared to sister ships. To manage these fleet variations, many airlines maintain aircraft-specific "Differences Data" or "Differences Training" documentation. These documents identify equipment and configuration differences between individual aircraft and are provided to flight crews during pre-flight briefing or through the airline's operational documentation to ensure crews are aware of any relevant variations before operating the aircraft.

Unquestionably, the EFB is too small. PMDG, again, was simply carried over (ported) without much thought or verification. Unfortunately, there doesn't seem to have been much effort to improve it or to thoroughly test its usability, especially on higher-resolution displays. In the meantime, you can work around the issue by creating a custom camera view: Hold the Right Mouse Button (or your assigned Freelook button). Move the camera: Forward: ~20–30 cm Left: ~10 cm Down: ~5 cm Rotate the camera: Yaw: ~25–30° left Pitch: ~10° down Reduce the cockpit Field of View (Zoom) to approximately 0.35–0.40 (instead of the default 0.60–0.70). This brings the EFB much closer to your viewpoint, making it appear nearly twice as large while keeping it square to the screen for much better readability. To save the view: Ctrl + Alt + 5 → Save as Custom Camera 5 (or any available slot) Alt + 5 → Recall it instantly whenever you need the EFB.

That's understood—no comment on that. In reality, these are two completely different aircraft with distinct aerodynamic characteristics, so they naturally don't flare the same way. Even in MSFS, you would expect to notice those differences, particularly since the Flight Dynamics Engine (FDE) includes parameters specifically intended to model flare behavior. If those parameters are properly tuned, each aircraft should exhibit its own unique flare characteristics rather than feeling identical.

Yeah, why would they fix it? 😂 Less work, but the customer's ATM is still working. Turn rate can be adjusted, but not the "wobble"; it's in their coding, as is the pitch stability. Bad programming; it's for them to fix the faulty coding. What puzzles me is that, despite many complaints, even on their forum, they are stubbornly in denial.

That's excellent news! Just a couple of questions: Do you have any custom panel states or saved routes? Before the transition from OC2 to OC3, if I remember correctly, there weren't any widespread WASM issues. When OC3 was introduced on April 10–11, 2025, it initially supported only the 777F, with the 777-300ER following a few days later. The 737 was migrated to OC3 sometime after that. It seems that around that period, people started reporting these WASM issues—although not everyone experienced them. I could be mistaken, but I wonder if the 737 migration, or something that changed during that process, might have played a role.

To be honest, I don't recall seeing this issue with any product other than PMDG. Looking at it now, it almost seems that a number of long-standing bugs from the FSX/P3D era have carried over into the MSFS versions as well. And on top of that, the same issue mentioned was not WASM's fault in FSX/P3D; it did not have it. So, IMHO, this is an issue with PMDG coding. Of course, I could be mistaken, but that's certainly how it appears from my experience.

Type MINUS and PLUS and assign to the HGD selector for left and right.

THE FIX The fix that worked for many users was to delete any custom panel states previously created in the following locations: Microsoft Store C:\Users\[your user name]\AppData\Local\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\WASM\MSFS2024\pmdg-aircraft-[specific model designation]\work\PanelState Steam C:\Users\[your user name]\AppData\Roaming\Microsoft Flight Simulator 2024\WASM\MSFS2024\pmdg-aircraft-[specific model designation]\work\PanelState For many users, that solved the problem immediately. In my case, however, it was a little different. Even after performing a clean reinstall, my work folder contained no custom panel states, yet the issue persisted. Surprisingly, it only resolved itself after I restarted my PC twice. I was also hoping this update would include improvements to LNAV, specifically the intermittent issue where the aircraft briefly turns left or right as it approaches a waypoint before crossing it. Since the release notes mentioned changes to the magenta route line drawing, I expected this behavior to be addressed as well. Unfortunately, the problem remains. It is a clearly visible issue that affects the quality and realism of the product.

Before this update, my PMDG aircraft worked without any WASM issues. Unfortunately, after installing the latest update, PMDG aircraft now fails with a WASM module crash, leaving all of the cockpit displays red and unusable. I've spent a considerable amount of time trying to resolve it on my own. I searched extensively online, including the PMDG forums, and found that I'm far from alone—many other users appear to be experiencing the same problem. I completely uninstalled the software, checked for and removed any leftover files I could find, and reinstalled everything from scratch. To rule out conflicts, I even restored a clean Windows backup containing only a default installation of MSFS 2024, with no third-party software installed other than PMDG. After reinstalling the PMDG 737, the result was exactly the same: WASM module crash and red cockpit screens. At this point, I'm extremely disappointed. What was previously a stable, working setup has become completely unusable after the update, despite every reasonable troubleshooting step I could think of. If anyone has found a genuine solution or workaround, I'd greatly appreciate your help. Any ideas are welcome.

Indeed, I loved KJFK to KEWR on 773, 744, and 748; we used a minimum fuel of 30T due to operational limitations. The kicker was waiting for tower-to-tower clearance to take off JFK 31L at 3,000 FT visual to rwy 29 in EWR. Speed was limited to 180 KTS; all that was no more than an 8-minute direct flight to CRI and line up for 29. Such is life. Even TO2 with assumed the temperature would give, as you mentioned, an over-20-degree deck angle to stay on profile.

I'm afraid that is not an entirely correct statement. Why would we know this? Because airlines routinely conduct ferry (repositioning) flights with little or no payload, moving aircraft between maintenance bases or operational stations. These flights provide a direct comparison between a virtually empty aircraft and one operating near its maximum certified weight. From a flight control perspective, the difference is surprisingly small—almost negligible. The force required to move the controls is governed primarily by dynamic pressure, which is a function of airspeed and air density, not aircraft weight. At a given airspeed, the aerodynamic hinge moments acting on the control surfaces remain essentially the same regardless of how much payload is on board. On aircraft such as the Boeing 737, the primary flight controls are hydraulically powered and incorporate an artificial feel system (control feel and centering unit). This system intentionally provides the pilot with consistent control forces that vary mainly with airspeed and hydraulic feel pressure, rather than with aircraft weight. As a result, the controls remain linear, smooth, and predictable whether the aircraft is nearly empty or operating close to maximum takeoff weight. For that reason, I have never encountered evidence supporting the statement that "these aircraft are designed with a certain weight in mind, and if you fly them empty the handling becomes much harder." That simply does not match either the aircraft's engineering or my operational experience. What does change is the aircraft's response, not the control force. An empty airplane has less mass and therefore less inertia. Consequently, it accelerates more quickly, decelerates more readily, rotates with less resistance, climbs better, and generally responds more briskly to the same control inputs. Likewise, lower weight reduces wing loading, improving climb performance and reducing stall speed. During repositioning flights, even with reduced takeoff thrust, the airplane accelerates noticeably faster and delivers significantly better overall performance. In other words, the controls themselves do not become "harder" or fundamentally different because the airplane is empty. What changes is the aircraft's inertia and performance, while the artificial feel system ensures that the pilot experiences nearly the same control feel throughout the certified weight envelope.

To be honest, I don't recall ever having to use full flight control deflection in real-world operations, whether flying military or civilian aircraft. I have, however, seen it occur occasionally in Level D simulators during engine-out scenarios or when operating at the maximum demonstrated crosswind limits. In fact, that's one of the issues I've been raising. Even under those demanding conditions, you generally should not be reaching full control deflection. Aircraft certification standards include a built-in safety margin—typically on the order of 10–20%—to ensure there is still reserve control authority available. This brings me back to what I believe is one of the shortcomings of Asobo's flight dynamics implementation. The exaggerated S-shaped control response curves produce unrealistic control behavior, particularly as control travel approaches its limits. In my view, they either have not prioritized addressing this issue or have been unable to refine it to a more realistic standard. Ironically, MSFS previously included the Reactivity slider, which helped mitigate this behavior by providing a more predictable and natural control response. Its removal has only made the underlying issue more apparent.

@BWBriscoe , I'd like to point out a few things that make a significant difference, based on my own flying experience. At one point, I was dual-qualified on both Boeing and Airbus aircraft. As far as PMDG and Fenix are concerned, both are excellent simulations. From a systems standpoint, they are about as close to the real aircraft as current software and development limitations allow. Like any complex simulation, both have their share of bugs—some are subtle enough that most people never notice them, while others are more obvious but are often overlooked or simply accepted. It's also worth remembering that the Boeing 777 is a Heavy wake turbulence category aircraft, whereas the Airbus A320 is a Medium. They were designed for different missions, and that influences how they fly and how pilots operate them. Where things become really interesting is in the design philosophy. Boeing's philosophy is that the pilot remains the final authority. The automation is there to assist you, and it can be disconnected quickly whenever you want to hand-fly the airplane. Airbus takes a different approach. Its philosophy centers on flight envelope protection. The automation is intended to remain engaged whenever practical, and the aircraft's flight-control laws and protections play a much larger role in how pilot inputs are interpreted. That means the biggest adjustment when flying both isn't learning how to move the controls—it's changing your mindset. With Boeing, the philosophy is: fly the airplane first and use automation as a tool. With Airbus, the philosophy is: manage the automation effectively and let it help you operate safely within the aircraft's protected flight envelope. From a psychological standpoint, that's the biggest difference. The 777 encourages more direct manipulation of the aircraft, while the A320 places greater emphasis on understanding automation modes, flight-control laws, and what the aircraft is doing at any given moment. In my experience, one of the biggest challenges when transitioning to Airbus is developing strong mode awareness and fully understanding the flight-control laws. Once that clicks, the logic becomes very intuitive. So, in my opinion, @Stearmandriver summed it up perfectly: they're different aircraft designed for different missions, and each requires a different way of thinking. IMHO, having both will broaden your flight experience.

Well said. Unfortunately, for many years in the U.S., we've seen hiring decisions too often influenced by race and gender rather than qualifications and merit. The results speak for themselves in many airlines. I've observed similar trends at some international carriers, but nowhere near the same level or with the same degree of emphasis as we've seen here.

While I agree that some developers have found ways to mitigate or mask ASOBO's shortcomings, the underlying issue still exists. Without even comparing MSFS to other simulators, it's worth remembering that MSFS 2020 included a very useful REACTIVITY slider. That option was initially carried over to MSFS 2024, and it significantly helped reduce the need for large negative sensitivity S-curves by producing a much more linear and predictable control response. Unfortunately, ASOBO chose to remove that feature, leaving users with a far less effective solution. Instead of restoring the Reactivity slider or addressing the underlying implementation, the current recommendation is to reduce axis sensitivity to values such as -90% or even -95% (MENTIONED ON THEIR FORUM). In my view, this is the wrong approach. Those extreme sensitivity reductions rely on increasingly aggressive nonlinear S-curves, making the controls progressively less proportional as they approach full deflection, rather than preserving a consistent, linear relationship between pilot input and aircraft response. Whether we choose to acknowledge the issue or not, the root of the problem lies in ASOBO's bad design decisions. Like many other obvious instances. This is simply another example where a more robust implementation would have provided a better experience for both developers and end users.