LRBS

You continue to attribute an “agenda” to me that simply does not exist. I have already explained, quite clearly, that my comments were directly related to the products being discussed in this sale — including both the 777 and 737 — and that I consider the 29% discount to be a fair price precisely in light of the remaining issues and limitations. That is a legitimate opinion about the value of the products being offered. It is not “hijacking” the thread, nor is it an attempt to turn every PMDG discussion into a bug report. I have been very consistent about this. I have acknowledged PMDG’s strengths, I have acknowledged the difficulties developers face with MSFS and Asobo, and I have also pointed out long-standing issues when they are relevant to the discussion. Disagreeing with my assessment does not give you a basis to assign motives to me or repeatedly claim that I have some hidden agenda. If you believe my comments are wrong, then please address what I actually wrote rather than repeatedly speculating about my intentions. That would make this a discussion rather than a series of personal accusations. I have no problem with people enjoying PMDG products or considering this sale a great deal. You are perfectly entitled to that opinion. I am equally entitled to evaluate these products based on my own experience and to mention the remaining issues when discussing their value. And, unfortunately, these issues are not something I have simply invented or brought up out of nowhere. The very same points I have mentioned have been discussed and reported by users on PMDG’s own forums. Anyone who takes the time to look can see that for themselves. Disagreeing with those reports does not make them disappear, nor does repeatedly accusing me of having an “agenda” change the facts. So, rather than continuing to make this personal, perhaps we can simply agree to disagree on the value of the products and leave it at that. Good luck with this, and I genuinely hope you have a better day.

Again, you seem determined to turn a discussion about documented software issues into something personal. Pointing out known bugs is not “bashing PMDG,” nor is it an “agenda.” These are issues that have been reported by multiple users on the PMDG forums, and in some cases have even been acknowledged by PMDG themselves. Disagreeing with you about the seriousness of those issues does not make the issues disappear. You accuse me of “hijacking” a thread about the PMDG sale, yet the title is “PMDG sale on right now.” My comment was directly relevant to the sale: I said that, in my opinion, a 29% discount makes the purchase more acceptable given the known and currently unresolved bugs. That is a perfectly legitimate opinion for someone considering whether the discounted price represents good value. What I find particularly concerning is that you repeatedly characterize legitimate criticism as “bashing,” accuse me of having an “agenda,” and now suggest that I am somehow hijacking discussions simply because I bring up issues you apparently don't want discussed. You are certainly entitled to disagree with my assessment of PMDG. What you are not entitled to do is turn disagreement into personal accusations. If you believe that something I have stated about a particular PMDG bug is factually incorrect, then identify it and explain why. I'm perfectly willing to discuss the technical issue. But repeatedly attacking the person instead of addressing the documented problems adds nothing to the discussion. Criticizing software is not hatred. Reporting bugs is not bashing. And disagreeing with you is not an agenda. Let's keep the discussion about the aircraft and the software, rather than making it personal.

I didn’t want to point out the obvious deficiencies of the PMDG 737 and 777 during this sale, especially with the products being offered at 29% off the regular price. However, I think it is fair to discuss what customers are actually buying. I also want to acknowledge that ASOBO/MSFS plays a significant role in making aircraft development extremely difficult. The simulator platform has its own limitations and changes, and developers sometimes have to work around problems that are outside their direct control. Some developers manage to overcome certain issues, while others struggle with them. That is understandable. What is much harder to understand, however, is when known, reproducible problems are reported repeatedly by customers and real-world pilots, discussed extensively on the developer's own forum, and remain unresolved for years. Bugs are part of software development. Unfixed bugs that are known, documented, reproducible, and repeatedly reported are a different matter. PMDG 737 / 777 — LNAV and Flight DirectorOne of the most noticeable examples is LNAV behavior. • The Flight Director can momentarily command the wrong direction—left or right—immediately before initiating an LNAV turn. • LNAV can exhibit oversteering, excessive bank, overshooting of the magenta path, followed by corrections and repeated oscillation. • There have been numerous reports since the transition to MSFS describing the FD briefly moving in the opposite direction before correcting itself and commanding the actual turn. • Similar behavior has been reported during RNP/RF procedures, where the aircraft can briefly bank toward the opposite side before establishing the correct turn. This is not simply a question of whether someone "likes" the way PMDG flies. The issue is that this behavior has been repeatedly reported, including by people with real-world Boeing experience, and has been discussed on the PMDG forums. As of August 10, 2026, I have not seen convincing evidence that this specific behavior has been conclusively eliminated. PMDG has also acknowledged in the past that its magenta-line and Flight Director architecture required substantial work, and there has been discussion of a completely new magenta-line/FD module for PMDG products because the existing system needed a major rewrite. That makes the continued presence of these behaviors even more disappointing. Other long-standing 737 / 777 concernsThere are also numerous other areas that have generated repeated customer and pilot reports over the years: • Flight-model and handling characteristics that do not always reproduce the expected Boeing behavior. • Pitch and trim behavior around rotation and during the initial climb. • Roll response and the way bank corrections are generated. • Yaw oscillation and Dutch-roll tendencies. • Engine-out handling. • Crosswind behavior. • Autopilot bank corrections that can sometimes become unnecessarily frequent or abrupt. • VNAV transition behavior in certain situations. • FMC waypoint and route-editing behavior. • OFFSET entry behavior. • VNAV constraint calculations in particular circumstances. • Electrical and other system behaviors that can produce unexpected results. • Ground handling, particularly nosewheel/tiller response. • Directional behavior on the ground in strong crosswinds. • Differences between the expected Boeing tiller/ground-steering response and what the simulator actually produces. And the list is not limited to the 737. The 777 has its own collection of flight-model, systems, navigation, VNAV, autopilot, and ground-handling concerns, some of which have also been discussed repeatedly by customers and real-world pilots. The point is not that PMDG software should be perfectNobody reasonably expects complex aircraft software to be bug-free. The issue is how long known problems remain unresolved and how they are prioritized. A customer can accept a bug when a developer says: It becomes much harder to accept when the same problem is reported over and over again for years, receives extensive discussion from experienced users and pilots, and still remains part of the product. At that point, it is reasonable for customers to question priorities. PMDG has produced some extremely sophisticated aircraft, and there is no question that developing these products for MSFS is technically difficult. I respect the amount of work involved. But complexity should not become an excuse for leaving documented deficiencies indefinitely unresolved. For me, the fundamental principle is simple: Bugs are acceptable during development. Known bugs are acceptable temporarily. Long-standing, reproducible bugs that are repeatedly reported and never conclusively fixed are not something customers should be expected to consider "normal." So, IMHO, when evaluating the PMDG 737 and 777 during a sale, the discount does more than simply lower the price. It also makes the purchase more representative of what the products actually deliver today—including their long-standing unresolved issues. And that is why, personally, I believe the discounted price is much closer to the price these products should command in their current state. This is not intended as an attack on PMDG or its developers. It is simply a customer's perspective: if a product is sold as a high-fidelity simulation, customers have every right to expect the important, documented problems to be treated with the same seriousness as the features used to sell the product.

You're arguing against a position I never took. At no point did I claim to be "the king" of anything or suggest PMDG must implement my ideas. That's a straw-man argument used to avoid addressing the actual issues. The concerns I've raised are not based on personal preference. They have been reported by numerous users over many years, discussed extensively on PMDG's own forum (https://forum.pmdg.com/forum/microsoft-flight-simulator-2020-2024-products-discussion/pmdg-777/autoflight-manual-flight-navigation-aa/399538-777-fbw-still-has-major-issues) , and even acknowledged by a pilot of their testing team. That alone disproves your claim that these are simply my opinions or that "no one really cares." Calling them "minute issues" doesn't change the facts. For anyone looking for a high-fidelity simulation, flight-control logic, FBW behavior, hand-flying characteristics, and long-standing bugs are fundamental—not trivial. If those details didn't matter, PMDG wouldn't market its products on their realism and technical accuracy. What's disappointing is that instead of discussing the technical evidence, you've chosen to attack me personally by portraying me as someone seeking attention or validation. That's not a counterargument—it's an attempt to discredit the person instead of addressing the subject. I've supported PMDG since the FSX days, purchased their products, and invested countless hours using them. Unfortunately, they keep-on-caring/not fixing bugs since that time. Customers have every right to point out reproducible deficiencies and expect them to be addressed, especially when some of those same issues have persisted across multiple simulator generations. If you believe the reported issues are incorrect, then explain why using technical facts. But dismissing documented concerns with sarcasm and personal remarks only weakens your own argument. Ignoring problems has never improved a product. Identifying them is how products get better.

You are welcome. I don't know; it's very difficult to give a correct answer. What I noticed first is the airline's SOP, and next is the version. For example, on the 747, 757, 767, 777, and 787, we had LNAV/VNAV armed on the ground. Today, with so many 737 variants, the answer can be very different. Some don't; what is interesting is that new airlines, even if the aircraft is capable, don't arm it. Some on the 757 and 767 swear not to arm it. I'm sorry, I don't have a good answer.

Some SOPs are quite different, but system-wise, after takeoff, if VNAV is armed (some do and others don't), VNAV automatically engages at 400 feet AGL. It has nothing to do with the logic in our case.

Excellent question. And it is true: many times, when at the gate (not at the runway threshold), and if it is a tight crossing restriction, VNAV will compute from that position and might give you UNABLE NEXT ALT. When taxing/arriving at the threshold point and pushing TOGA, VNAV logic will sample that position and update accordingly. We are on the same page here. Now let's pay close attention to the predictions on the legs page for TEB2; it is over 4,000 ft, and the restriction is only 3,000 ft, less than the prediction; there is no way to get the UNABLE CRZ ALT or UNABLE NEXT ALT. And the nasty one is at TEB01; instead of being at CRZ ALT of 9,000, it shows 3,000 after crossing TEB, climbing through 4,420 ft, and then descending back to 3,000 ft. That's why I'm saying the whole VNAV logic needs attention; something in the coding is off.

Again, this kind of response does nothing to address the actual coding problems. Rather than discussing how to improve a product that customers have paid for, the suggestion is simply to "ditch PMDG products." That is hardly a constructive approach. Many of us purchased these products because PMDG itself promotes them as being "created by a highly experienced aviation and software engineering team," "crafted with meticulous attention to detail," and "setting a new benchmark in realism and performance." Those are high standards that naturally create high expectations. When customers identify reproducible bugs—especially those supported by documentation or real-world operational knowledge—they are not attacking the product. They are asking PMDG to deliver the level of quality and fidelity that was advertised. Dismissing those concerns instead of addressing them does not improve the software, nor does it inspire confidence in the product or the company behind it. Constructive bug reports should be viewed as an opportunity to improve the simulation, not as a reason to tell paying customers to leave.

I'm afraid we have an issue with the VNAV logic, and it needs lots of love. In this picture, on the EWR-to-JFK flight, I have 5000 set for cruise. Note the T/C before the TEB wpt; I manually entered a restriction TEB 210/3000, and it returned an invalid entry. That entry should be accepted as typed and move the T/C after TEB. Not working well. On a second try I changed cruise altitude to 9,000 and added a new WPT (TEB02) before TEB with a restriction TEB02 210/3000. Now it took the restriction, but see the legs page. But now we have 4 problems related to the VNAV logic. 1. The UNABLE CRZ ALT should not be triggered. We have a T/C and a T/D. 2. At TEB, it shows correct acceleration and crossing at 218/4420 in climb to 9,000. 3. T/C symbol and computations are wrong; we cannot have the T/C there; it needs to be passed by TEB. 4. At wpt TEB01, we should be at 250/9000, NOT at the value we have in the legs page. Thanks.

Unfortunately, I have to disappoint you. 3 people did it, and maybe you got an answer, but not us. 😂

And unfortunately, this comment proves the point once again. Instead of discussing the actual issue, the first reaction is, "And let the bashing begin," as if reporting legitimate, documented bugs is somehow an attack on the product. It's an easy way to dismiss valid criticism without addressing the facts. No one is asking for a Level D simulator. That argument is simply a distraction. This has nothing to do with Level D fidelity—it has everything to do with correct coding and fixing functionality that should work as intended. Bugs are bugs, regardless of whether the product is a home simulator or a certified training device. This mindset is exactly why genuine issues remain unresolved for so long. Instead of encouraging constructive feedback that would improve the product for everyone, some people choose to ridicule or discredit those who take the time to identify and document problems. I find that approach extremely disappointing because it shifts the discussion away from the quality of the product and toward attacking the people trying to help improve it.

Absolutely. Others and I are used to the product's previous excellence; let's say there were not so many annoying bugs, and, I guess, they had very good profit margins. As was rightly mentioned above, the focus shifts from a very good quality product to a mediocre one, while others maintain superior quality while keeping profit margins in place. I also agree that very few would notice, and even fewer will appreciate, but unfortunately for them, other developers don't mind spending time to fix and constantly improve the product. Some even upgraded for free from 2020 to 2024, while they charged money for cockies and leftovers in the cockpit in such "upgrades," while the other bugs are still on the "menu." 🤣

There is no such thing as a silly question. The issues being discussed here are not based on speculation or personal preference. They have been identified by numerous current and former professional pilots, reproduced by multiple users, and supported by documentation and technical evidence. The unfortunate reality of the official forum is that you'll often find a vocal group of people who immediately dismiss any reported bug as an attack on the product. Rather than examining the evidence or engaging in a technical discussion, they resort to denying the problem, making excuses for it, or attempting to discredit the person reporting it. That approach serves no constructive purpose. A bug does not cease to exist simply because someone refuses to acknowledge it. Ignoring documented evidence or dismissing abnormal aircraft behavior only delays improvements and lowers the overall quality of the product. The purpose of a technical forum should be to identify issues, verify them, and help developers improve the simulation. That's how software evolves. Suppressing legitimate reports or treating every criticism as disloyalty does exactly the opposite. It creates an environment where genuine defects are overlooked, meaningful discussion is discouraged, and paying customers are left with unresolved problems. A mature community welcomes documented bug reports because they ultimately benefit everyone. Pretending that obvious issues don't exist may protect a brand's image in the short term, but it does nothing to improve the product. Facts, reproducible evidence, and technical discussion should always carry more weight than blind brand loyalty.

Unfortunately, again, many things are clearly not functioning correctly. The issues involving Primary Pitch Trim, Thrust Asymmetry Compensation (TAC), Wheel-to-Rudder Cross-Tie, and Gust Suppression either remain unresolved or have not been implemented in accordance with the Boeing 777 Flight Control System design. Primary Pitch TrimIn Normal Flight Control Mode, the Boeing 777's primary pitch trim operates differently on the ground than it does in flight. On the ground, the control wheel pitch trim switches directly command stabilizer movement to the selected trim position. In flight, the trim switches no longer drive the stabilizer directly. Instead, they command a new trimmed flight condition (trim reference speed) to the Primary Flight Computers (PFCs). The PFCs first command the elevators to establish the new trimmed condition and then automatically reposition the stabilizer to streamline the elevators, minimizing trim drag while maintaining the desired flight path. This fly-by-wire architecture provides smooth pitch control, reduces pilot workload, and improves aerodynamic efficiency by keeping elevator deflection to a minimum whenever practical. Unfortunately, this behavior does not appear to be correctly modeled. For reasons that are unclear, pitch trim commands appear to be inhibited immediately after liftoff until approximately 500 feet AGL. This behavior is not consistent with the Boeing 777, nor with any other aircraft, where pitch trim is available at all times unless there are mechanical problems. The issue is easily reproducible by activating the pitch trim switches during the initial climb: the aircraft shows no response, and the FBW TRIM SPEED indication (labeled by PMDG as "FBW TRIM REF SPEED") remains unchanged or has no effect. On the actual Boeing 777, primary pitch trim is available immediately after the aircraft transitions to flight mode. While the internal control logic changes after liftoff—from direct stabilizer commands on the ground to PFC-managed trim in flight—the pilot should retain continuous pitch trim authority. There is no Boeing limitation that inhibits normal primary pitch trim until 500 feet AGL. Additionally, there are phases of flight in which pitch trim intermittently fails to function altogether, which is inconsistent with normal Boeing 777 flight control operation. Thrust Asymmetry Compensation (TAC)The Thrust Asymmetry Compensation (TAC) system is designed to minimize uncommanded yaw and flight path deviations following an engine failure or significant thrust imbalance. In Normal Flight Control Mode, TAC continuously compares engine thrust. When the thrust differential reaches approximately 10% or greater, the system automatically commands rudder deflection to counter the asymmetric yawing moment. TAC is unavailable only: During ground operations below 70 knots, and Whenever reverse thrust is selected. Manual rudder pedal inputs override TAC at any time. The current implementation does not consistently exhibit the expected TAC behavior following asymmetric thrust conditions, suggesting that the system is either incomplete or not functioning as intended. Wheel-to-Rudder Cross-TieThe Wheel-to-Rudder Cross-Tie function allows the pilot to counter the initial effects of an engine failure using control wheel inputs alone, without requiring immediate rudder pedal input. Below 210 knots in flight, control wheel inputs can command up to approximately 8 degrees of rudder deflection. This function operates independently of TAC and is available only in Normal Flight Control Mode. Its purpose is to improve controllability during the critical initial response to asymmetric thrust at low airspeeds. Based on the aircraft's observed behavior, this feature does not appear to operate in accordance with Boeing's documented flight control logic. Gust SuppressionThe Gust Suppression function enhances ride quality by automatically reducing the effects of lateral gusts and atmospheric disturbances. The PFCs continuously monitor aircraft motion and command coordinated rudder and roll control inputs to dampen lateral accelerations. These corrections occur internally within the flight control system and do not produce visible movement of the control wheel or rudder pedals. This function is intended to improve both passenger comfort and aircraft handling while reducing pilot workload. The current simulation does not consistently demonstrate the expected response associated with Boeing's Gust Suppression system. Taken together, these observations suggest that several key components of the Boeing 777's fly-by-wire flight control system are either incomplete or not functioning in accordance with Boeing's published design. Given that these systems are fundamental to the aircraft's handling characteristics, they require careful review and validation against the Boeing FCOM and FCTM to ensure accurate simulation fidelity. Unfortunately, again, after I don't know how many revisions, it is still unsatisfactory with unreal behavior.

I'm not surprised by their answer. Typical PMDG. I suggest making a short video; there are a few qualified 737 drivers here who fly for a living. This issue was previously reported (2023) as a bug. https://forum.pmdg.com/forum/main-forum/pmdg-737-for-msfs/general-discussion-no-support/239702-issues-with-speeds-after-last-update#post239703 https://forum.pmdg.com/forum/main-forum/pmdg-737-for-msfs/general-discussion-no-support/238834-thrust-speed-issues-during-ils-approach