LRBS

On Boeing aircraft (including the 737), there is a deliberate elevator feel and control-force characteristic around rotation. As rotation begins, there can be a region where additional yoke movement produces relatively little change in pitch rate. It is designed to prevent over-rotation and tail strikes. During rotation and aft pressure is applied, there is a slight lag before the nose begins to rise, and once the nosewheel unloads, pitch rate develops progressively. Next, control forces increase smoothly with pitch attitude. We target the rotation rate: approximately 2–3° per second for an initial target pitch 15° nose-up. All this is stable and smooth, I would not call it dead band, perhaps elevator feel future. That issue was brought to their attention, but as usual, they completely ignored it, and here you have it.

Yes, Andrew, that's exactly what I'm seeing in MSFS 2024. I noticed it immediately compared to the previous version. I no longer have MSFS 2020 installed, so I can't compare directly, but something definitely changed, and in my opinion the earlier version had better flight dynamics. To be fair, the new 2024 FDE entries actually work very well in 2020, which suggests the issue can likely be addressed without too much difficulty. That said, in many respects there is still no real comparison with the competition, and it's clear the developers are actively looking for improvements and refinements.

Whatever you like the most, this is my honest view. iFly 737 MAX is much better than the PMDG in certain respects. However, in my opinion, the previous iFly 737 MAX version had better flight dynamics than Version 1.1.0.0. We'll see what the next update brings, but at the moment, a few refinements would certainly be welcome.

It's 2024. I thought it was 20 KTS; however, the issue I had was that after disconnecting, landing, the rudder was less effective than it was during t.o. roll. Anyhow, there is lots of positive work and effort on this release. Someone mentioned that the competition 737 flies much better. All I can say is, oh boy.

The earlier version felt smoother and slightly less twitchy in terms of flight control response. The difference is not dramatic, but it is noticeable. Since I am using the same hardware and control setup, I was expecting very similar handling characteristics. It is possible that some additional adjustments are needed on my end. During takeoff, control authority was good in gusty winds up to 22 knots, and the aircraft remained stable throughout the initial climb in turbulent conditions. At 1:25, I noticed some wing rocking. With only about a 2-knot wind variation, I would not normally expect that level of response. While entering a speed restriction of 200/4000A for the DPK hold, I copied it to the scratchpad and then attempted to copy the hold information, but it would not accept it. This may be an FMS limitation. However, when I entered 200/4000A at the first DPK waypoint at 2:14, the CRZ ALT automatically changed to 4,000 feet. This is the first time I have observed this behavior. It may be aircraft-specific, as I never encountered it in the 737-400. I also observed another instance of wing rocking between the user waypoint CRI01 and ZETAL, resulting in a less-than-smooth transition. The capture and transition onto the localizer were very good. On final approach, there were noticeable deviations above and below the glideslope, and on short final the aircraft was significantly above the GS. The autoland touchdown occurred well down the runway, close to the 2,800-foot marker. This may also be specific to this aircraft model, but after touchdown it did not properly follow the ROLLOUT mode. The autopilot had to be disconnected, which resulted in a lateral deviation that could not be corrected effectively in the 20-knot crosswind. Interestingly, this issue was not present during takeoff, where directional control was very good. Overall, some areas show improvement, while others may still require refinement.

Does anyone know how to get from REAL to save as default SMOOTH? Any other changes work, while this does not stay in memory after a reboot. Thanks.

You are 100% correct. In my previous version, when I uninstalled, it was not there. After reinstalling, I found that setting, and I have to say that it is quite a "positive" improvement! No complaints regarding that aspect.

100% correct. Some people are not familiar with what to expect to see, even though a wx report can show different scenarios. A perfect example is Touchdown Zone, Midpoint, or Rollout visibility. Forget about the window scenario. If STRATAWX MSFS24 implemented a visibility slider, they would be well ahead of the competition. My problem is that ASOBO in MSFS 2020/2024 failed to implement a slider for visibility values. They managed to address the turbulence reaction slider but missed this important feature, necessary for a simulator aiming for an "as real as it gets" scenario.

I'm curious myself. What can't be ignored is that the same cloud transitions and morphing are still visible, even with ActiveSky, and they stand out quite clearly. The difference is that both MSFS 2020/2024 and ActiveSky provide ways to manage the overall experience, including adjustments for turbulence intensity. At the moment, the turbulence effects in this software seem excessive and not particularly realistic. Even Asobo recognizes that users have different preferences and provides adjustment options. A simple turbulence slider from 0% to 100% would likely satisfy most users and make the cloud morphing much easier to accept while still allowing everyone to tailor the experience to their liking.

Thanks for the offer. I purchased the product from Simmarket, and my findings are based on hands-on experience rather than speculation.

If turbulence "has been a major focus," I would encourage adding a slider or another way to adjust its strength, as in MSFS or Active Sky. That will help a lot and also improve the product. Right now, it needs lots of love, the way it is.

From my perspective, based on my own experience using this product and what is demonstrated in the video, MSFS 2024 remains the superior solution when it comes to smooth weather transitions and minimizing cloud morphing. While MSFS 2024 certainly has its shortcomings, ActiveSky also provides numerous configuration options and workarounds that can effectively mitigate many of those limitations. In contrast, the claims made regarding smooth transitions in StartaWx are not supported by the footage presented. Visible cloud morphing and transition artifacts can be observed at several points throughout the video, including approximately 1:45, 3:18, 4:16, 4:55, 6:25, and 7:56. These examples clearly demonstrate that weather and cloud transitions remain noticeable rather than seamless. Additionally, the persistent and often exaggerated turbulence depicted throughout the presentation further detracts from the realism of the experience. Unfortunately, based on the solutions currently available and the various approaches attempted by third-party developers, I remain skeptical that a truly effective weather engine can be achieved under the present limitations. Unless Asobo provides broader access to the weather API and related atmospheric systems, developers will continue to face significant restrictions that prevent them from delivering a product capable of fully overcoming these shortcomings.

Speaking of the FAA, I believe the organization deserves closer scrutiny, and in some areas, significant changes may be warranted. As for this particular topic, there simply isn't enough time during Level D simulator training to cover it adequately. The training syllabus is already packed with critical maneuvers, procedures, and evaluations that must be completed within a limited timeframe. However, during Initial Operating Experience (IOE), the subject is typically addressed in greater detail, and practical demonstrations are conducted when appropriate. This approach is not unique; many regulatory authorities and aviation organizations, including the FAA, generally rely on a similar training philosophy by introducing certain concepts during line training rather than dedicating valuable simulator time to them.

100% Correct. Let's not forget other developers selling the same product over and over, ported from P3D to MSFS 2020 and MSFS 2024, with known LNAV and APFD issues that still haven't been fixed after 4 years. We also paid for a complete product. I'm afraid that is quite all right.

As I recall, CPDLC was announced in August 2025 as one of the planned features for SP1. However, iFly never provided a firm release date specifically for CPDLC. When SP1 was eventually released on June 12, 2026, the feature was not included. iFly later explained that implementing CPDLC within the existing MSFS 2020/MSFS 2024 compatibility framework proved more challenging than anticipated, and that the feature would likely be deferred to the upcoming native MSFS 2024 version. While I understand that some may be disappointed by this and may place a high level of importance on CPDLC (whether justified or not is a separate discussion), it is worth considering how frequently it is actually used in real-world airline operations. For long-haul oceanic flights across the North Atlantic, Pacific, or polar regions, CPDLC can account for approximately 70–90% of routine ATC communications once the aircraft is established within CPDLC airspace. On heavily Data Comm-enabled international routes, the percentage can also exceed 70%. Conversely, on domestic operations in regions where Data Comm implementation remains limited, usage may be well below 20%. During departure and arrival phases, CPDLC is generally used far less than many assume—often only 0–10% of ATC interactions—because voice communications remain faster and more practical in rapidly changing traffic environments. For a typical Boeing 737 operation, CPDLC may only be utilized for 5–15 minutes during a two-hour flight, representing perhaps 10–20% of total ATC communications. What I find interesting is that we have developers who, after many years, still have not corrected fundamental LNAV and AFDS functionality—systems that are used on virtually every flight and affect nearly 100% of normal operations. Yet, some are quick to label a product as inadequate because a feature with comparatively limited operational use has not yet been implemented. Perhaps we simply have different priorities and different perspectives on what constitutes a critical feature.

The Boeing 777's electric stabilizer trim switches remain fully functional in flight, but they do not behave exactly like the trim system in a conventional mechanically controlled aircraft. The key difference is that the 777's fly-by-wire flight control system incorporates Trim Reference Speed (TRS) logic. During manual flight, the Primary Flight Computers continuously reposition the stabilizer to maintain a reference speed while minimizing sustained control-column forces. As aircraft configuration, thrust, weight distribution, and flight conditions change, the system automatically adjusts stabilizer trim to maintain the desired speed and handling characteristics. When the pilot actuates the electric trim switches on the control wheel, the stabilizer is commanded to move. However, unlike a conventional aircraft, this input is not simply a direct request to relieve elevator force. Instead, the flight control system interprets the trim input as a command to establish a new trim condition and corresponding Trim Reference Speed. The PFCs subsequently manage stabilizer position as required to maintain that new reference condition. As a result, nose-up or nose-down trim inputs effectively command a new speed-stability reference, after which the fly-by-wire system automatically trims the aircraft to eliminate sustained column forces. The pilot can therefore use electric trim for fine adjustments during manual flight, but the underlying system logic is fundamentally different from a conventional aircraft, where trim directly offsets elevator hinge moments and control forces. The PMDG 777 Trim Reference Speed establishment and subsequent automatic stabilizer repositioning do not accurately reflect the Boeing 777's intended flight-control laws and need fine-tuning.

Morning, After two reboots in MSFS 2024: The VNAV issue is gone, as well as the thrust rating issue Remaining issues: 1) Cannot save a panel state or fpl. I just checked the file permissions, and no issues there. 2) Regarding performance data, whether I click "read data from MSFS" or not, I still cannot select a runway. For example, before taxi, it was planned for KJFK 22R, then a runway change to 22L. Before any changes in the FMC, I want to run a runway analysis for 22L, but I cannot enter/change data. On our tablets, or Boeing FMC, and before this update on the original release, I could run any scenarios, any runway, and data changes without the need to "click the button to read MSFS data for runway information"; it was part of the NAV DATABASE. I can't understand the idea behind this feature. Other than that, the aircraft flies solidly and is very realistic, as far as I can see.

I loaded the SW version as you did. Very nice paint. My issues: Cannot save a panel state or route. Cannot use performance data due to being unable to load a RWY. It takes the airport ID, but cannot select a runway. Navigraph is set correctly. I had a TO2 assumed temp, but when I went TOGA, it reverted to full TO. LNAV is good as before, but on VNAV, it is hunting up/down for a while. None of this was experienced with the other version for performance data calculations or VNAV, and, of course, the panel or RTE state was not working before. If you have time, or if anybody else can check those, it will be greatly appreciated. I will check back tomorrow, stuck in the real simulator for hours to no end.

Thank you for the kind words. Unfortunately, two more issues surface with this PMDG 777. Not happening with the PMDG 737 or other product. NOT a NAVIGRAPH issue. On the legs page, the RWY end will show twice. I really wonder where the quality check is? Seriously, the implications are quite astonishing, from not knowing what to check before releasing to the public to failing to verify the legs page sequence and procedures, VNAV functionality, and fuel. Mistake after mistake, and people get upset when these issues are brought to light. https://www.dropbox.com/scl/fi/euum67pli2w3m8w3au3qo/777.png?rlkey=l94z0fwhjxxemk0g60kcqc3c7&st=cjc9j8l0&dl=0 https://www.dropbox.com/scl/fi/1w56q9dnq8iikcxaruru1/3of3.png?rlkey=isdqvwiv77d9ux85m21sqb2al&st=z17crzcv&dl=0 https://www.dropbox.com/scl/fi/943z1tbjh5lsjlfdup6fp/2of3.png?rlkey=3iljf6zxppmffqq6wbli9wb3v&st=t1vpahfp&dl=0

Actually, it's a very light hybrid. Personally, I prefer AB, but don't get me wrong, the 777 flies very nicely.

Some clarification is required regarding this new update. For an unknown reason, some users did not receive the update despite the release date. Although I was up to date (and this happened to other colleagues), they were advised to try a few times again. It appears the issue is related to version 2.4.140. After the update, we've observed some improvements in certain FBW logic, but there are now occasional micro-bounces with or without AP. As you were informed, this is on the "bug list". We'll see how long it takes to resolve. The LNAV issue, unfortunately, is unlikely to be fixed, as it still involves bouncing left/right before specific waypoints and requires fine-tuning of the entire APFD system. I wonder if you could increase the deadzone on your CH Flightstick Pro joystick, or even disconnect it, and see if the bounce persists.

In the real Boeing 777, the FBW system automatically maintains altitude in turns of up to including 30 degrees of bank without requiring pilot trim input. It continuously trims the aircraft to a target speed, which then becomes the reference speed. The system also compensates for changes in configuration and aircraft state, including flap and gear extension, thrust variations, center-of-gravity shifts, fuel burn, and numerous other factors. These characteristics become particularly evident when the aircraft is hand-flown. For example, during a visual circuit or a light-fuel ferry flight—perhaps 30 tonnes of fuel, no passengers, operating at 5,000 feet on a short sector such as KJFK to KEWR—the shortcomings become readily apparent. When the autopilot is engaged, most users will never notice them. I am not attempting to be condescending. Some individuals will recognize and understand these concepts to varying degrees, while others will strongly disagree regardless of the available evidence. That is simply the nature of these discussions. It is worth remembering that a pilot transitioning onto an aircraft of this complexity typically undergoes weeks of intensive training involving classroom instruction, computer-based training, systems study, and simulator sessions. Even then, mastering the aircraft and fully understanding its systems takes considerable time and experience. What I find disappointing is that discussions often reach a point where documented aircraft behavior, manufacturer publications, and the observations of qualified pilots with real-world experience are dismissed because they conflict with personal opinions or subjective impressions. At times, I can understand why many current and former airline pilots choose not to engage in these debates. When objective information is repeatedly challenged by those who have already decided what they believe, meaningful technical discussion becomes increasingly difficult. Enjoy your day, folks!

No, I believe you are mistaken. Numerous individuals here can attest that my expectations are entirely reasonable and are grounded in the standards established by this company's own previous products. Those earlier releases demonstrated a far higher level of accuracy, fidelity, and attention to detail than what is being discussed here. No one is suggesting that a consumer flight simulator product should replicate a Level D simulator. That is a strawman argument. The expectation is simply that the product should meet the level of quality and system accuracy that the developer itself has successfully achieved in the past. When a company has already demonstrated that standard, it is neither unrealistic nor unreasonable for customers to expect it to be maintained.

And I would like to add something that I believe is important. I don't know whether you currently fly, or have flown, the real aircraft. While I haven't flown the 777 for several years, I remain in contact with two friends who are current and qualified on the airplane. Both of them have independently raised concerns that closely mirror the issues being discussed here. Similar feedback can also be found on the PMDG forums, where other users have reported nearly identical observations. To ensure the issues were not related to my own setup, I took extensive steps after the latest update. I reformatted my PC, updated all drivers, recalibrated all peripherals, avoided any system tweaks or overclocking, and performed a completely clean installation of MSFS 2024. The only add-ons installed were the PMDG 737 and PMDG 777. Despite all of that, the same issues remain present, not only for me but also according to individuals with real-world experience and qualifications on the aircraft. I fully understand that some users may not be bothered by these issues, and that's perfectly fine. My intention is not to diminish anyone's enjoyment of the product. Quite the opposite—I have always appreciated PMDG's products and want to see them continue to improve. My concern is simply that, in recent years, I feel some aspects have drifted away from the standards that originally made these products so highly regarded. Of course, not everyone will notice the same things, but the fact that some users do not experience or recognize an issue does not necessarily mean it isn't there. My comments are made in the spirit of constructive feedback and with the hope that the product can continue to improve over time. That's really all there is to it—nothing more than a genuine desire to see the product become even better.