LRBS

As long as they continue to disregard customer feedback, overlook their own documented functional standards, and carry the same unresolved bugs from one product generation to the next, the outcome is unlikely to change. Those unfamiliar with how the product is intended to function may not fully understand the concerns being raised and may simply accept the shortcomings. However, many long-time users and subject-matter experts have grown increasingly frustrated with the company's direction. Some will express their dissatisfaction publicly, while others will simply vote with their wallets. What makes this particularly disappointing is the stark contrast between the quality, accuracy, and attention to detail that once defined their products and the current emphasis on visual appeal over functional fidelity. A visually attractive product is certainly valuable, but accuracy and proper functionality should not be sacrificed in the process—especially when other developers have demonstrated that it is entirely possible to achieve both in a well-balanced and highly capable product.

I fully understand that. However, even if you fly these aircraft regularly and personally do not experience any issues, that does not necessarily mean those issues do not exist. In some cases, it may simply reflect a different level of familiarity with how the real aircraft is expected to behave. I do not say that in a derogatory manner; rather, I believe it is important to keep an open mind and recognize that what works for one person may not work for another. Beyond personal opinions, there are numerous reports on their own forum from users raising concerns about unresolved issues. What is particularly disappointing is that these concerns often remain unaddressed while the product continues to be marketed as though everything is functioning as intended. In my view, knowingly selling a product with well-documented unresolved problems while minimizing or dismissing customer feedback is not a sound business practice.

Unfortunately, your perspective suggests a lack of awareness of the standards this company once set for itself. What is even more concerning is the belief that a company's primary objective should be maximizing revenue rather than delivering a high-quality product that earns customer trust and, ultimately, profitability. This is the very same company that, for years, produced outstanding products, maintained high standards, and operated as a successful business without giving anything away for free. Profitability and quality were never mutually exclusive. Today, however, the situation appears fundamentally different. Quality control has deteriorated to the point where virtually every release is plagued by significant bugs and deficiencies. More troubling is the apparent unwillingness to acknowledge or address these issues in a meaningful way. As a result, customers are left paying premium prices for unfinished products while known defects remain unresolved for extended periods. Meanwhile, competing developers continue to improve their products, listen to customer feedback, correct deficiencies, and deliver meaningful updates. The contrast could not be more apparent. The issue is not the pursuit of profit; every business exists to make money. The issue is abandoning the commitment to quality that made customers willing to spend their money in the first place.

I am not sure what you consider "engaging the autopilot quite early." For the Boeing 777 and later Boeing 747 variants, FAA certification permits autopilot engagement as low as 200 feet AGL after takeoff. Individual airlines may establish more restrictive Standard Operating Procedures (SOPs), but they cannot operate below the certified minimum. As a result, it is common to see autopilot engagement at 200, 500, or 1,000 feet AGL, depending on company policy, but not below the aircraft's certified limit. The 200-foot certification threshold was not selected arbitrarily. It is directly tied to the aircraft's demonstrated low-altitude autopilot performance and the stringent certification requirements concerning potential altitude loss following a critical autoflight system malfunction. These are certification-engineering criteria rather than pilot-operating limitations. Historically, earlier 747 variants, including the 747SP, 747-100, 747-200, and 747-300, were generally certified for autopilot engagement at 250 feet AGL. That certification basis was initially carried forward into the 747-400 program, with later refinements allowing engagement down to 200 feet AGL. Regarding the behavior observed in their 777 simulation, what is being presented appears to be the result of incorrect flight control system modeling and a misunderstanding of the aircraft's Fly-By-Wire and speed trim logic. In the real aircraft, once performance data have been correctly entered and the takeoff trim has been properly set during preflight, the aircraft should rotate smoothly to the commanded pitch attitude with only light aft control pressure from the pilot. Following rotation, the aircraft should maintain the target pitch attitude without significant pitch oscillations, continuous trimming, or repetitive pitch-up/pitch-down tendencies unless commanded by the crew or influenced by significant atmospheric disturbances. Unfortunately, rather than objectively investigating these concerns, there appears to be a tendency to dismiss or minimize reports from users who identify discrepancies. This approach can be effective because many customers have not had the opportunity to fly the actual aircraft and therefore must rely on the developer's interpretation of how the airplane should behave. When a position is endorsed internally by RSR and subsequently reinforced by beta testers, contrary evidence from official documentation, certification data, and experienced pilots with thousands of hours on the aircraft can be overlooked. Once that occurs, meaningful technical discussion becomes difficult, and inaccuracies may persist across the product line. In my view, this helps explain why recurring issues—both major and minor—continue to appear throughout their simulations.

Both have the same issue: rough, visible wx transitions. We all know why it cannot be fixed. AS offers many useful adjustments to address certain MSFS shortcomings, and we can manually set the visibility range to useful values. This is an important feature for simulating visibility during VFR/IFR conditions.

This is not the first time I have attempted to publish a review for a product purchased through SimMarket. Unfortunately, whenever a review raises legitimate concerns or identifies discrepancies between the advertised features and the actual product performance, it appears that such feedback is not always published. This is yet another instance where a review was withheld. I find this practice deeply concerning. Honest customer feedback—whether positive or critical—is an essential part of maintaining transparency and trust within the flight simulation community. Preventing the publication of legitimate criticism undermines the credibility of both the marketplace and the products being sold. Equally concerning are marketing statements such as: "StrataWx is the modern alternative to Active Sky's clunkiness." and "Custom per-channel smoothing (coast, then ease out, with a cold-start snap so you load straight into correct conditions) is purpose-built to eliminate the abrupt jumps of older weather engines like Active Sky." These statements not only make direct comparisons to another developer's product, but they also create expectations that, in my experience, are not reflected in the actual performance of the software. This raises an important question: since when have SimMarket and StrataWx considered it acceptable to promote a product through potentially misleading claims while simultaneously disparaging competing developers? This is a troubling trend and one that should concern both customers and developers alike. For reference, the review I submitted was as follows: "Despite the attractive interface, I have noticed persistent issues with visible weather transitions. The overall experience is far from smooth, particularly when compared with the default weather system in MSFS 2024. One of the most frustrating issues is the turbulence implementation. All aircraft, including both default and third-party models, appear to be affected by unrealistic wind and turbulence reactions. It would be beneficial to provide users with a slider or adjustment option to reduce or fine-tune this behavior. Additionally, cloud coloration often appears noticeably darker than the default MSFS 2024 atmospheric rendering, resulting in a less natural visual presentation." This review was submitted in good faith and reflects my honest experience with the product.

Unfortunately, 100 % correct. Lately, in pursuit of a $, quality, and fidelity they were known for, it's not there anymore.

For me—and certainly for anyone who has actually flown the real airplane—it's nothing short of disappointing that this product so poorly captures the aircraft. There is absolutely no justice done to this airplane in the way it was developed. Those of us who had the privilege of flying the real aircraft know just how special it was. We loved it, respected it, and understood what made it unique. Seeing it represented this way is profoundly disappointing. Sadly, I've reached the point where I can no longer justify keeping it installed. It's not sitting in the maintenance hangar waiting for fixes—it's gone from my PC entirely. That's how deeply disappointed I am with what this product has become.

Unfortunately, this issue is directly related to the AFDS, FBW trim-speed logic, and the persistent pitch oscillations, "bouncing," and excessive control loading that continue to affect the entire PMDG 777 lineup. I am not sure where the idea originated that this behavior is somehow normal or related to FMC programming, SID/STAR procedures, approaches, or LNAV/VNAV operation. The real aircraft simply does not behave this way in any phase of flight. A temporary 5-knot speed deviation is not unusual for an autothrottle system, but the recovery is smooth, controlled, and stable. Whether FBW logic is involved or not, the aircraft does not enter repeated pitch-up/pitch-down cycles, nor does it become unstable as a result. What is particularly frustrating is the continued effort to attribute the problem to virtually everything except the underlying issue itself. Rather than acknowledging and correcting a behavior that clearly does not reflect the real aircraft, the discussion keeps being redirected elsewhere. Much like the longstanding LNAV issues, it seems far more convenient to assign blame to external factors than to recognize and address the root cause.

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.