LRBS

I never mentioned ditching in the Hudson River. Once again, this appears to be speculation rather than a discussion based on factual knowledge. Since the topic of ditching has been raised, it is worth noting that Airbus aircraft—including the A320, A330, A340, and A380 families—feature a dedicated DITCHING push-button on the overhead panel. Commercial pilots operating these aircraft receive training that includes ditching procedures and water-survival considerations. During recurrent simulator training, we routinely practice emergency procedures such as securing the aircraft to minimize water ingress, evacuation procedures, life raft deployment, and related emergency checklists. In fact, at least six commercial airliners have ditched, demonstrating that while rare, this is not a purely theoretical subject. As someone dual-qualified on both Boeing aircraft and the A380, I have personally undergone this type of training. The primary difference is that Boeing aircraft, at least to date, do not incorporate a dedicated ditching switch or associated system logic in the same way as Airbus aircraft. This highlights a recurring issue in many of these discussions: individuals with little or no operational knowledge often make definitive claims, engage in arguments, and then become frustrated when experienced professionals provide factual corrections. Returning to your original statement, it is clear that you were unaware that ditching procedures and related emergency training are part of the curriculum for pilots. As for the outcome of any actual ditching event, no one can provide a definitive answer. Success depends on numerous variables, and ultimately there is always an element of uncertainty. Unfortunately, this is another example of a discussion becoming unproductive because it is driven by assumptions rather than informed understanding. That is genuinely disappointing.

Very well said. Unfortunately, @Claudius_ appears to have a rather adversarial approach to the discussion and seems unfamiliar with the level of training, experience, and operational knowledge required to become and remain an airline pilot. What is even more concerning are statements suggesting that "real-world pilots have no idea what a simulated flight model is." Such remarks are both inaccurate and dismissive of the extensive experience many professional pilots bring to these discussions. Real-world pilots are often uniquely positioned to evaluate how closely a simulation reflects actual aircraft behavior and operational procedures, making their input a valuable part of the conversation rather than something to be discounted.

This is a completely inaccurate statement. It implies that real-world pilots are attempting to impose authority rather than contribute professional expertise and operational experience. Suggesting that "real-world pilots dictate everything" is both inflammatory and unfair. Providing real-world operational insight is not the same as dictating decisions. On the contrary, it is simply sharing relevant knowledge and experience that can help inform discussions and improve the end product. If there is any frustration, it stems from the recurring accusation that real-world pilots are somehow trying to dictate outcomes when they are merely offering informed, experience-based feedback. Very disappointing.

ToLiss, very similar to what we have on our tablets.

One last point worth highlighting is the significant disconnect that often exists between some desktop sim enthusiasts and real-world pilots. It is remarkable how quickly individuals with limited aviation training or operational experience can dismiss the observations of professional pilots who have undergone extensive training, accumulated hundreds or thousands of hours in full-flight simulators, logged thousands of flight hours, and spent years and years operating aircraft in real-world environments. To put it into perspective, it's like a pilot directing a software engineer on how to code during development. Each profession has unique expertise, standards, and knowledge. Professionals depend on experience, training, and evidence, not guesswork. I also agree that a number of self-proclaimed "real-world pilot" YouTube creators have contributed to the problem by selectively overlooking product deficiencies, spreading misinformation for views and engagement, or acting as unofficial marketing departments for certain developers. While many creators provide honest and valuable feedback, there are certainly some who prioritize clicks, ratings, and access over objective evaluation, and that ultimately does a disservice to the community.

Current and qualified pilots bring operational knowledge, procedural understanding, and real-world experience that cannot be replicated through simulator use alone. The most successful developers recognize that pilot feedback is not intended to replace the broader testing community, but rather to complement it with valuable operational insight. The argument that real pilots "usually lack experience with home flight simulators" is, at best, an overgeneralization. Many airline, corporate, military, and general aviation pilots have extensive experience with home simulation platforms and are uniquely positioned to identify where a product aligns with—or diverges from—real-world aircraft behavior and procedures. Likewise, suggesting that real-world pilots sometimes ignore product issues does not invalidate the value of their feedback. Every testing group has potential blind spots, whether composed of pilots, enthusiasts, developers, or casual users. The solution is not to diminish one group's contribution, but to combine perspectives from all segments of the community. Most importantly, nobody is suggesting that customers without pilot qualifications are less intelligent or that their feedback is unimportant. Such an interpretation is both inaccurate and unnecessarily divisive. Customers are the ultimate users of the product, and their experiences matter. However, being a customer does not automatically make every opinion equally informed on highly specialized subjects. In any technical field—whether aviation, engineering, medicine, or software development—expertise remains relevant and should be given appropriate weight when evaluating complex issues. The strongest products emerge when developers listen to a broad range of users while also placing significant value on feedback from individuals with demonstrated subject-matter expertise. The shortcomings observed in this product illustrate what can happen when critical feedback, regardless of its source, is not adequately incorporated into the development and validation process.

I understand your point. For example, many airlines integrate this data into their operational systems, making it readily available to flight crews at all times. Interestingly, one developer has already incorporated it into their EFB, demonstrating that it can be done. Perhaps others will follow suit to provide an even more realistic and authentic simulation experience.

Both platforms have their strengths and shortcomings. In my view, one of the most critical factors in this hobby is maintaining a large, active pool of current, qualified beta testers—particularly real-world pilots who can provide operationally relevant feedback. Very few developers fully appreciate the importance of this, and those who do consistently deliver products that stand above the competition. MSFS 2024 has highlighted numerous discrepancies that can emerge when this aspect of development is not given sufficient priority. It also demonstrates some of the challenges inherent in an open-beta approach when key validation, testing, and quality-control processes are not adequately addressed.

Yeah, I’m not looking to debate it, but MSFS 2020/2024 has become notorious for these kinds of problems. I don’t experience any of them with Lockheed Martin Prepar3D or X-Plane 12. Unfortunately, a large number of users continue to report persistent issues involving keyboards, flight controls, settings randomly changing, peripherals disconnecting, and other input-related problems. Whatever the root cause may be, this is clearly not an isolated case — it’s an ongoing and well-known issue affecting many customers. Unfortunately, this ASOBO MSFS 2020/2024 is still unfinished software with very fragile, continuous cloud connectivity and synchronization for core functionality such as scenery streaming, authentication, profile syncing, controller profiles, marketplace entitlements, rolling cache, live weather, traffic, etc.

Bill, I believe you—no question. However, each system varies: some work flawlessly, while others are so frustrating you'd want to shoot them.

Rightly so, we strive to support each other, and this was definitely a mistake. Thank you for taking the time to correct all of us.

It’s not the user causing it. It’s Microsoft’s long-standing “power saving” philosophy, pushed heavily since the Gates era, where the system decides on its own which peripherals should be put to sleep by default — and then often resets those settings again after major updates. Some connected peripherals have well-written drivers, so the problem may go unnoticed. Others don’t, which leads to random disconnects, unstable behavior, changing sensitivities, or devices failing to wake up properly. For flight simulation and similar hardware-intensive hobbies, this approach is far from ideal.

This is what I use and is tailored for our hobby for flight sim peripherals, HOTAS/yokes, racing wheels, VR headsets USB disconnects, stuttering, disappearing devices, controller sensitivity changes, intermittent freezes Open PowerShell as admin, just paste the script: Get-CimInstance -Namespace root/wmi -ClassName MSPower_DeviceEnable | Where-Object { $_.InstanceName -match 'USB' } | ForEach-Object { Set-CimInstance $_ -Property @{Enable = $false} } And this if you prefer powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_USB USBSELECTIVE SUSPEND 0 powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_USB USBSELECTIVE SUSPEND 0 powercfg /SETACTIVE SCHEME_CURRENT

100% 👍

Perhaps we should consider a few facts. Active Sky's weakness, what I noticed, is that it does not display WX returns well on the radar, and they are heavily limited by the underlying Microsoft Flight Simulator weather radar API. MSFS 2020/2024 suffers from this unrealistic "volcanic ash" cloud color, which has nothing to do with the meteorology. It's just their wrong interpretation. In reality, clouds are much whiter and have more contrast, not this pronounced gray as in post-volcanic-eruption skies. See the pictures, such a difference. Another issue is the variations in cloud formations. Something to be taken into account and vehiculated around is this wrong impression/expectation that "I don't see this out of my window" compared to a METAR or ATIS. Many times, when taxiing out or during the approach, WX conditions are not quite 100% compared to the WX report; slight variations occur.

Interesting, regulatory requirements mandate that the information be in ATIS. Usually, when vis is below 1,200 FT RVR, or otherwise specified, and as it was reported by the controller, 1,000 RVR, the airport (if certified) must have and use LVO/SMGCS procedures in effect, and these must also be broadcast in ATIS. Also, for pilots, that information on the ATIS is a legal trigger. It warns the flight crew that they must transition from standard airport charts to specialized Low Visibility Taxi Charts. It also tells them that certain safety features, such as geographic position tracking (ASDE-X) and physically illuminated stop bars, are now actively monitored by ATC. There are two big problems here: inadequate ATC training and pilots being afraid to hold ATC to the standards. Otherwise, ATC will give you a number right away when we are wrong. I hope you filed an ASAP report (we rely heavily on it) and that the CP on duty is no longer there. Perhaps he was promoted to DO?

Thank you for the kind words.

My take on this. Once again, this highlights the persistent issue at many major U.S. airports: ATC often fails to provide clear, concise, and standardized responses. At KJFK in particular, there is an increasing number of controllers with questionable accents and limited proficiency in phraseology, which creates unnecessary confusion in situations exactly like this. Before the British Airways crew received clearance, they already had the ATIS — voice or digital — stating whether “Low Visibility Operations in progress,” “Low Visibility Procedures in operation,” or specific RVR values were active. We know whether LVO is in effect before the aircraft moves. There are no surprises. The operation is then conducted strictly in accordance with the airport 10-9 pages and the air carrier’s operational certification and procedures. The ATC response here was crystal clear: NO LVO. That immediately opens another issue entirely. If ATC is operating below standard visibility values without officially declaring LVO, that is extremely questionable. Even more concerning is how everyone simply goes along with it without challenging the inconsistency or asking why standard procedures are apparently being bypassed. I attached the 10-9 data for that runway.

No, I'm sorry.

So, in your opinion, if someone reports an issue, gets help resolving it, or expresses an opinion about a product, that automatically makes them a “hater.” By your logic, anyone who points out factual problems or criticizes product quality and accuracy deserves to be dismissed and labeled instead of being heard. The reality is that even customers on the PMDG forum itself have raised concerns about quality, bugs, and accuracy. Are they “haters” too, simply because they refuse to blindly praise everything? Criticism and accountability are not hatred. Customers have every right to discuss flaws in a product they paid for, especially when those concerns are based on facts and firsthand experience. This mentality of instantly branding any criticism as “bashing” is exactly what shuts down honest discussion and prevents meaningful feedback. Disturbing attitude.

Initially, PMDG prioritized product quality and accuracy, and then profit. Today, profit has become the main focus, often at the expense of quality. Unfortunately, this shows in many areas. The good news for us, the consumers, is that new developers are emerging with better products in many respects.

MASTER BRIGHTThe main brightness adjustment for a particular display or lighting group. On the 777, these are commonly used for: EFIS displays PFD/ND brightness EICAS display brightness Panel flood lighting Backlighting systems Rotary Knob (Brightness Adjustment)Turning the knob: Clockwise → increases brightness Counterclockwise → decreases brightness This adjusts display intensity for: Day operations Night operations Glare reduction Pilot eye adaptation PUSH ON/OFFThe knob is also a pushbutton. Pressing it: Toggles the associated display/light system: ON = display or lighting active OFF = display or lighting extinguished Common uses: Turning a display unit off if it has failed or is unnecessary Reducing distractions Power cycling a display

As it was before, at least the same way I did it.

After PMDG's most recent update, all my flight control settings were affected. Intermittent performance issues, PFS loss, and stutters. Before their update, everything was silky smooth. The same problem with the elevator electrical trim remains unresolved, and the airplane still cannot be trimmed below 500 ft. On the Boeing 777, there is no specific operational requirement that prevents the use of the elevator electrical trim from takeoff until 500 ft AGL. The system is fully operational and designed to automatically assist with pitch control. For some reason (I will simplify), they don't understand that the control wheel trim switches work as in conventional airplanes, plus this new FBW system's integration with speed trim logic. This system takes the pilot's inputs, which are interpreted electronically, and multiple computers monitor the trim commands. Excessive or unsafe trim inputs are limited. Here, there is a total misunderstanding of the system, where trim functionality is severely limited, or there is an intermittent, unnecessarily heavy elevator load, or it goes in the other direction, becoming overly sensitive, NOT IN THE REAL AIRPLANE. The airplane can be flown with only two fingers on the yoke, with very smooth, stable flight control responses. Such a dream to fly. I don't think they have the capabilities or knowledge to fix this. At one point, I was dual-qualified on both the 747 and the 777. Surprisingly, I favored the 777 in some handling aspects. What they did to this airplane is entirely frustrating and does no justice. It's a real shame.

Hats off to this developer. His FDE expertise is truly exceptional. I genuinely enjoy flying this aircraft—personally, I find it far superior to many of the alternatives currently available. With some additional refinement to the cockpit textures and gauges in the future, this could become an even more outstanding package. Once again, thank you for your impressive FDE work and for delivering such an excellent product.