LRBS

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.

Yes, it's an Airbus, but these two pilots are genuinely exceptional. Such a good, relaxed crew. Hats off to you, dear ladies!

Very interesting take, but it doesn't align with either my experience or the broader discussion within the flight simulation community. There are numerous reports from both experienced simmers and real-world pilots describing overly twitchy control responses and exaggerated aircraft reactions in Microsoft Flight Simulator 2024. One of the most common comparisons is with X-Plane 12 and DCS, where many users report being able to fly comfortably with essentially linear control curves, while MSFS 2024 often requires substantial negative sensitivity (S-curve) adjustments simply to achieve a comparable level of controllability. Describing this as merely a "speed of light" or generic mathematical limitation misses the point. If it were simply an unavoidable mathematical problem, we would expect every modern simulator to exhibit the same behavior. That is not what many users report. The statement that "it's the same exact thing in every sim" is contradicted by a significant number of user experiences. In both X-Plane 12 and DCS, I can leave my controls essentially linear and the aircraft exhibits realistic inertia, damping, and proportional control response throughout the entire control travel. Small inputs remain progressive, larger inputs remain predictable, and maneuvers such as stall recovery, trimming, and high-angle-of-attack flight feel natural without requiring excessive sensitivity compensation. In contrast, MSFS 2024's sensitivity implementation often forces users to introduce large negative S-curves to tame the response around center. While this makes the aircraft easier to control initially, it also produces an increasingly nonlinear response toward the extremes of travel. That is fundamentally different from having a truly linear control law combined with realistic aerodynamic damping and inertia. The fact that so many users independently arrive at similar sensitivity adjustments—and frequently compare the handling unfavorably with other simulators—strongly suggests that this is not simply a universal mathematical limitation, but rather a consequence of how MSFS 2024 currently maps controller inputs and models the resulting aircraft response.

In my opinion, it's a combination of both. The primary issue is that the control response is not truly linear across the full range of travel, and the underlying flight dynamics are not yet sufficiently refined. The result is exactly what we're seeing. Some developers have managed to tune or mask the shortcomings caused by the current S-shaped control response, while others have not. However, the common denominator remains the same: the underlying implementation of the control response is fundamentally flawed. I also find the growing tendency to dismiss or shut down comparisons between products concerning. Honest technical comparisons are essential for improvement. If users cannot openly discuss strengths and weaknesses or point out obvious shortcomings, meaningful progress becomes much more difficult. Constructive criticism is not an attack on a product—it's one of the most valuable tools for making it better.

For @flyingscampi and @cianpars , I'm glad you're one of the few people who understand and have identified the real issue. The problem is not simply that the controls are too sensitive around the center. The real problem is the way ASOBO has implemented the Sensitivity adjustment. Instead of providing a linear reduction in control response, it applies a pronounced S-curve across the entire control travel. While this does reduce sensitivity near the center, it progressively increases the nonlinearity as the controls approach full deflection. The result is that aircraft response is no longer proportional to pilot input. In a real aircraft—or a Level D simulator—the relationship between control movement and aircraft response remains essentially linear, allowing the pilot to accurately predict the aircraft's behavior throughout the full range of travel. For example, if an aircraft requires a sensitivity setting of -50% to -60% just to feel stable in normal cruise, the first half of the yoke travel may feel acceptable. However, the last portion of the travel becomes increasingly distorted, producing aircraft responses that differ significantly from the nearly linear behavior expected in real-world aircraft. This forces users to choose between excessive sensitivity around the center or unrealistic control response near the limits of travel. This is the fundamental flaw in the current implementation. ASOBO needs to understand that large S-curves are only masking the underlying problem. They may improve the feel around the center, but they do so at the expense of realism everywhere else. What the simulator needs instead is the ability to reduce overall control sensitivity while preserving a linear relationship between pilot input and aircraft response across the entire control range. Until that is addressed, the aircraft will continue to exhibit the "arcade-like" handling characteristics many experienced pilots have been describing. As you rightly pointed out, this is also why users of other simulation platforms generally do not have such aggressive sensitivity curves to achieve realistic handling.

Howard, I don't own that particular yoke. My friend just purchased the unit with Vector Gear MCP and lighting MCP; nice additions and the desk mount. I think it's good quality (too early to have an opinion), smooth, but to my taste a bit light on control tension. It can be easily fixed if you don't like it. IMHO, way better than the Thrustmaster TCA Yoke Boeing Edition Flight Sim Controller. And yes, the B-JET Yoke Handle will arrive shortly.

That is very unusual, especially at -75, IMHO. I've never heard of such values. I'm wondering whether you calibrated your joystick properly using its own calibration software rather than in Windows. Very strange; you have very high-quality Hall sensors there.

Based on the research I've found online, many of the recommended sensitivity settings above -30 (I've seen up to -70) appear excessively aggressive, creating steep S-shaped curves that result in unrealistic handling characteristics. Users frequently describe the outcome as "twitchy" or overly reactive compared to the predictable, proportional control response expected in real aircraft. As a general rule, we should avoid using a Dead Zone unless the controller exhibits measurable noise or jitter. Real aircraft flight controls do not have a dead zone, so introducing one unnecessarily reduces precision around the neutral position. A word of caution regarding the Extremity Dead Zone: values above +0.9 are generally not recommended. Increasing this setting reduces the available control travel, limiting maximum control deflection and resulting in unrealistic aircraft responses. If anyone is interested, you can monitor the flight control synoptic page as you move the controls. With a high Extremity Dead Zone setting, you'll notice that the control surfaces no longer achieve their full travel. A Sensitivity setting of -50 softens the response around the center, making small control inputs less aggressive. However, as the controls approach their limits, the response curve becomes progressively steeper, making the controls increasingly sensitive near the extremities and bringing back the notoriously "twitchy" feel. The larger concern is that these exaggerated S-shaped response curves produce a control feel that is neither linear nor smooth throughout the full range of travel. This can lead to overcontrolling, inconsistent control authority, and abrupt aircraft reactions during larger control inputs or precision hand-flying. This may be worth bringing to ASOBO's attention. A review of the current sensitivity implementation and response curves could lead to a more realistic and intuitive control model for all users.

Thanks. I would like to wait to get more details to identify where the problem might be. I don't want to jump to any conclusions, which is why I'm interested in the numbers used in these settings. Much appreciated.

While configuring control sensitivity on three different PCs, we observed the following: Aileron and Elevator: A sensitivity setting between -20 and -25, combined with an Extremity Dead Zone of +0.8, provided consistently good handling and control. Rudder: On all three systems, a sensitivity setting of approximately -50 was required to achieve a comparable feel, using the same Extremity Dead Zone of +0.8. The rudder pedals tested were the Thrustmaster TPR, MOZA, and Honeycomb models. We're interested in learning which rudder sensitivity settings the wider flight simulation community uses. Any feedback would be greatly appreciated.

Thank you! Will try later today.

Perhaps I should try again. If no trouble, which preset did you download, and what changes did you make to your liking? Thanks.

For sure, I spent hours and hours trying something different.

In that version of ActiveSky and MSFS, all of the options I mentioned should be available. I tested them myself, and they were working at the time. The ActiveSky documentation and menus should explain each setting in detail. I don't have ActiveSky installed anymore because I found it added too many background processes for my liking. For me, it felt like it was just trying to put lipstick on a pig. Hopefully someone who still has it installed can walk you through the exact steps or confirm where each setting is located. Sorry.

I used this guide: 1) ActiveSky (Weather Engine – Physics First)Core PhilosophyPrioritize real METAR fidelity + smooth interpolation, not dramatic weather morphing. Recommended SettingsWeather Injection Mode ✔ Hybrid or Smooth Dynamic Mode (avoid pure “instant METAR”) ✔ Update interval: 5–15 min Clouds Maximum layers: 6–8 Coverage smoothing: ON Cloud transition smoothing: HIGH Wind Gust realism: 70–85% Wind variation smoothing: ON Turbulence scale: Low level: realistic (not enhanced) Cruise: light to moderate only unless SIGMET Thermals ✔ Enabled but reduced: Strength: 30–50% Avoid aggressive convective spikes (non-realistic in most airline ops) Visibility Set to METAR-driven only Avoid artificial “ultra haze injection” if flying IFR/airline ops Pressure / QNH ✔ Strict METAR sync enabled 2) REX Atmos CORE (Visual Layer – Subtle Airline Look)Core PhilosophyMatch real-world cockpit visibility perception, not cinematic lighting. Sky / Color GradingSaturation: -5 to -15% Contrast: slightly reduced (-5%) Blue intensity: neutral to slightly muted Avoid: Heavy “teal/orange” cinematic LUTs Over-bright HDR skies Haze / Visibility RenderingHaze intensity: realistic low-medium Horizon fade: subtle (important for cruise realism) Visibility smoothing: ON Avoid extreme “clarity boost” presets 👉 Real airline rule of thumb: Clouds (Visual Rendering Only)Cloud brightness: natural / slightly desaturated Cloud edge sharpness: medium (avoid cartoon crispness) Cloud shadow depth: moderate realism Lightning exaggeration: OFF or LOW LightingSun bloom: low HDR glare: reduced Night lighting saturation: neutral (avoid neon airport look) 3) MSFS 2024 Core Weather & Graphics (Critical Layer)Weather SystemUse ActiveSky as sole injector Disable any built-in MSFS live weather conflicts Clouds (Sim Settings)Cloud quality: Ultra Volumetric detail: High or Ultra Cloud resolution scaling: 100–120% (RTX 4090 safe) Atmospheric EffectsLOD: High (not max extreme) Raymarched effects: ON Motion blur: OFF (real cockpit feel) 4) Real Airline Feel Adjustments (Important)Turbulence PhilosophyReal airline turbulence is: Mostly light/moderate Occasional short bursts Rare sustained severe turbulence (avoided operationally) So: Do NOT max turbulence sliders in ActiveSky Avoid “constant shaking cockpit” setups Wind Shear / TransitionsKeep shear realistic but not dramatic Sudden 50–100 kt shifts = unrealistic unless storm front 5) Operational Matching (What This Setup Feels Like)With this profile, you will see: ✔ Stable cruise with subtle drift corrections ✔ Realistic cloud layering (not towering exaggeration everywhere) ✔ Smooth ATC/approach transitions ✔ Turbulence that feels like: Light chop in cruise Occasional bumps in cumulus Clear-air turbulence only in jetstream regions ✔ Runway visibility consistent with METAR (not over-simulated fog walls)