In OC3

This is build 143.

• FBW altitude capture and altitude hold improvements

• FBW rotation and g-load improvements

• Lighting fixes

• Magenta line draw improvements

• Flight plan read improvements

• Engine fan artifact fixes

• Path cleanup for textures and models

• Rear axle steering animation when using Tiller + Rudder setting

• Multi-jetway operations (at supported airports)

started with a blank cockpit ie screens dead though starting on rwy, may have tp try again or re-install eventually

EDIT am on SU6 beta, so not complaining

Edited 13 hours ago13 hr by DAD

reinstalled the 777 and it loaded. though now does seemingly have no AIRAC data since the FMC does neither know KBOS nor EGLL... well...

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 Trim

In 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-Tie

The 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 Suppression

The 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. 

5 minutes ago, LRBS said:

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 Trim

In 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-Tie

The 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 Suppression

The 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. 

Silly question - have you submitted these concerns on their official forums or through a support ticket?

Edited 10 hours ago10 hr by Keirtt

Why is the PMDG 200LR so much less expensive than the 300ER?

46 minutes ago, Keirtt said:

Silly question - have you submitted these concerns on their official forums or through a support ticket?

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.

30 minutes ago, LRBS said:

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.

This is not limited to PMDG boards, to be fair.

For a developer, feedback of the sort yourself and others are offering is golden and should have been gladly accepted or at least acknowledged. The community, as you correctly observed, carries no lesser responsibility. When the focal point shifts form system fidelity and good dynamics to texture quality (nice as those might be) and when the heretics who dare to point out the shortcomings of the holy cows are getting stoned - why should the developer waste hundreds of hours on things very few would notice and even fewer will appreciate?

1 hour ago, Noel said:

Why is the PMDG 200LR so much less expensive than the 300ER?

because it was far less popular in the real world. Not everybody is interested in real world flights matched to correct equipment. But the majority are.

Nothing in life is free, so I'd never ignore free advice from an expert unless acting upon it ate into my profit margin 😉

47 minutes ago, flyingscampi said:

Nothing in life is free, so I'd never ignore free advice from an expert unless acting upon it ate into my profit margin 😉

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." 🤣

Edited 7 hours ago7 hr by LRBS

2 hours ago, LRBS said:

...

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.

...

I don't usually post emotional, unfactual opinions on forums or about the people who write there; after all, everyone forms their own view based on their personality, life experience, and knowledge of the subject.

But I share the opinion of @LRBS 's comments, having experienced the frustration of reporting a bug and receiving only responses from PMDG "experts" trying to prove me wrong.

It took submitting a support ticket for the PMDG developers (not the forum developers) to acknowledge the bug and fix it.

And in the end, the forum "experts" who had been criticizing my factual arguments became completely silent.

NB: the post https://forum.pmdg.com/forum/main-forum/pmdg-737-for-msfs/general-discussion-no-support/401675-unable-to-delete-aircraft-state-file

Edited 7 hours ago7 hr by Area

And let the bashing begin. I understand some wanting actual 777 simulation like the real thing, but this is not a level D simulated product. Maybe sometime in the future PMDG will address the short comings of their critics, but no one will really notice or really care.

49 minutes ago, Bigmack said:

And let the bashing begin. I understand some wanting actual 777 simulation like the real thing, but this is not a level D simulated product. Maybe sometime in the future PMDG will address the short comings of their critics, but no one will really notice or really care.

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.

7 hours ago, LRBS said:

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.

Submit a ticket. It's literally the ONLY WAY PMDG will ever see your concerns.