LRBS

At this point, you've moved well beyond the original question and into personal commentary, which really speaks for itself. If you have something substantive to say about the actual technical issue, I'm happy to discuss it. Otherwise, I think we're done here.

And regardless of how I answer, you still don’t seem satisfied. Every answer simply results in another question, which makes me wonder what exactly you’re trying to accomplish here. I already explained that discussing this with @Stearmandriver, who is part of the technical team, puts the information directly in front of the people responsible for the product. So the suggestion that there is somehow “no resolve” simply doesn’t make sense. If you disagree with my choice of where to raise the issue, that’s fine. Continuing to challenge it after that serves no purpose other than creating an unnecessary argument.

A couple of reasons. First, and most importantly, here I can interact with @Stearmandriver and a few other people on a professional level. Over there, just as here, you’ll also find some “jumpers” who resort to unnecessary attacks and are unable to accept criticism constructively.

Andrew, with all due respect, I’m not trying to fault anyone here, and I think that point has been made unnecessarily complicated. I fully understand that it is impossible to model every possible cockpit layout, equipment configuration, or airline option. I also understand that developers have to make choices and provide menu options for different configurations. My comment was simply a suggestion based on how these things are actually handled elsewhere. Regarding the statement, “Probably, but that’s also something that would be implicitly understood by everyone with knowledge of these aircraft and this industry,” I have to disagree with that assumption. If something is airline-specific, then it should not necessarily be left to an “implicit understanding” of the user. In fact, other developers have specifically identified and documented these differences as airline-specific configurations, precisely so there is no ambiguity about what is being represented. That is especially relevant when discussing a product that is intended to accurately represent a particular aircraft and its configuration. People can have extensive knowledge of the aircraft and the industry and still reasonably interpret what they see differently if the configuration is not clearly identified. So, no, I wasn’t suggesting that every possible option needs to be developed. I was simply pointing out that clearly identifying an airline-specific configuration would eliminate the very misunderstanding we are discussing here. That was the entire point of my comment.

I think what triggered this thread is that this particular variant, and some of the features discussed, may not be as common or as familiar to all of us as they are to pilots operating other airline configurations. That is understandable, given the number of options and configurations available to customers. More specifically, I think the misconception comes from treating what “our” airline has configured, or what we have become accustomed to seeing in our operation, as if it were necessarily the standard way the system works—or even the only logical way it can work. That can easily lead to comments such as, “Pilots aren’t sure why it works this way,” or “I can’t find a good reason for it,” when in reality the explanation may simply be an airline-specific configuration or option. In the context of the FMC, that distinction is particularly important. Different aircraft, FMC software versions, and airline options can produce differences in the way certain functions are presented or operated, even when the underlying Boeing capability is the same. Perhaps many of these surprises and comparisons could be avoided simply by stating upfront: “This is an airline-specific option/configuration.” That immediately puts the discussion into the proper context and prevents one operator’s implementation from being presented as the industry standard or as the only way the system is supposed to work.

Now I have the information. After creating a Place/Bearing/Distance (PBD) waypoint, as you did with your FMC version, selecting that waypoint will return the associated PBD information. That is obviously a different implementation. On other Boeing FMC versions, however, once the waypoint is created and selected, the LEGS page displays the complete definition—for example, GTF075/5, rather than simply GTF04. The same principle applies to all manually created PBD waypoints, providing a clear and detailed representation of how the waypoint was defined. So, yes—if the simulation is accurately mirroring the representation and behavior of the particular Boeing FMC software version being modeled, then all is good. Different FMC software standards can present the same underlying waypoint definition differently. That is precisely why constructive discussions are important. They help us distinguish between an actual discrepancy and simply a difference between FMC software versions. Thank you!

Perhaps it's a different FMC version? Good timing, but unfortunately, I can't take any pictures. These guys are quite strict about that. I've already driven two of them crazy, and they still can't figure out the issue. They're talking to the MX guys now, so it could possibly be related to the upgrade. I honestly don't know. And, well, it's certainly not the first time I've been wrong. 😄 All I know is that when I had access to their 737 simulator, it behaved exactly as I mentioned. One person referred to it as the GE/Smiths Model 2907C1, while the other called it the GE Aerospace Model 2907C1 FMC. IMHO, it may simply be the same basic software under a different name. What I do notice is that the new TCDU looks quite similar to the 787, and that may explain why it's displaying that information on the scratchpad. We do train the military guys on "I've never had occasion to create an offset waypoint from an offset waypoint, and I have trouble imagining a scenario where this would be useful." Granted, different world.................. Some additional data This is a short version of one part of our curriculum for the P-8, E-7, KC-767, VC-25, E-4, and VC-25B. All of these aircraft use PB/PB to create a new waypoint, as we know, and from there the procedure is essentially the same. A typical air-refueling/reconnaissance sequence would be: ARIP → ARCP / Refueling Track → Exit Point If a required point is not already in the navigation database, it can be defined using a PB/PB waypoint, based on two known fixes/radials. For example: PB/PB Fix 1 / Bearing Fix 2 / Bearing ARCP — Air Refueling Control PointThe ARCP is normally the controlling point for the refueling operation. If it is not already in the database, it can likewise be created as a PB/PB waypoint. For example: ARIP — PB/PB ARCP — EXIT This is, of course, a simplified representation of the procedure, but it illustrates the basic logic we use: define the required point, insert it into the flight plan, and then build the appropriate refueling track from there. Thank you.

Certainly. This is what I said: I thought that was quite clear, but apparently it wasn’t. Hopefully, this clarifies exactly what I meant and answers your question. P.S. worth mentioning: the IFly 737 SWATH function works perfectly, whereas the PMDG is partially broken. Thank you.

Thank you, I just did. It’s such a pity that things had to come to something like that.

Unfortunately, 100% correct. Yet, instead of evolving and improving, some chose such a disappointing path.

I find your response quite frankly insulting, and it does nothing to address the actual point being discussed. Calling someone “totally obsessed” because they notice and report an operational inaccuracy is not a rebuttal. It is a personal attack and an attempt to dismiss the discussion rather than engage with it. If you disagree with the technical point, then explain why it is correct—not why the person who noticed it is supposedly obsessed. Nobody is claiming that a simulator can reproduce the smell of an aircraft, the physical forces on your body, turbulence through the seat, or every sound and sensation of real flight. That is an absurd comparison and completely beside the point. We are discussing the accuracy of the things the simulator is actually designed to simulate. An FMS either behaves correctly according to the aircraft's operational logic, or it doesn't. The fact that you consider the discrepancy “minor” does not make it correct, and it certainly doesn't justify dismissing anyone who has enough experience to recognize it. I've already explained that my criticism is not an attack on the developer or the product. Quite the opposite: identifying shortcomings is precisely how products improve. If everything is simply dismissed with “it's a game,” then there is no meaningful reason to discuss accuracy at all. And suggesting that I go play Kingdom Come: Deliverance 2 because I pointed out an FMS discrepancy is particularly telling. It avoids the technical issue completely and turns a product discussion into a personal judgment about me. We are perfectly entitled to disagree about how important a particular issue is. What I will not accept is being labeled “obsessed” simply because I have higher expectations for operational accuracy and am willing to point out where something is wrong. If you want to debate the actual FMS issue, I'm happy to do that. If the response is going to be personal insults and “it's just a game,” then there really isn't much of a technical discussion left. Enjoy your lovely day.

I think it is worth mentioning, as it may help clear up some of the muddy waters. For me, and for many others, flying—or simming—is a hobby. It is something we enjoy, and that perspective helps put things into context and clarify our priorities. As you’ve noticed, I’m certainly not the only person who flies for a living and genuinely enjoys this hobby. While some may perceive pointing out shortcomings as being overly “critical,” the purpose is simply to identify issues that could be improved. It is not an attack; it is intended to benefit everyone—the developer and the customer alike—by bringing the product as close as possible to the real thing and, ultimately, making it more enjoyable for everyone. For some reason, however, some people take these comments out of context and turn them into unfortunate and unwarranted speculation, sometimes even making them personal. IMHO, we should keep the focus on what can actually be demonstrated, documented, and potentially fixed, regardless of what anyone may or may not know about the person making the observation. At the end of the day, improving a product—whether we call it a “game” or a simulator—doesn’t hurt anyone. Quite the opposite: it makes the product better for all of us.

So here we go again. There are two specific FMC issues/bugs related to how the system functions, and instead of addressing the actual technical issue, you’re trying to turn the discussion into one about the price of the addon and the fact that it’s “just a game.” That completely misses the point. I’m not asking for perfection, nor am I suggesting that a £60 addon should somehow replace a multimillion-pound Level-D simulator. I’m simply pointing out specific behavior that is operationally incorrect and should be fixable. In fact, another developer has already implemented the same function correctly within the exact same simulator and technical constraints. That alone demonstrates that this is not an unreasonable expectation or some impossible demand for “real life” simulation. Reporting bugs and explaining why they matter is exactly how products improve. If something doesn’t work correctly, the appropriate response is to discuss the issue and hopefully get it fixed—not dismiss it by changing the subject to the price, calling it “just a game,” or making assumptions about why someone cares about realism. Frankly, I find this kind of response very disappointing. Disagree with the technical point if you wish, but diverting the discussion and making it personal adds nothing to the conversation. The issue is the issue: the FMC function is not behaving correctly, and I’m pointing it out in the hope that it gets fixed. That should be enough.

Of course. Everything I pointed out is pretty straightforward. Both products have their strengths and weaknesses, and this is simply one of the shortcomings/bugs I happened to run into. Believe me, there are plenty on both sides. In this particular case, though, PMDG simply does it better—because it works the way it does in the real airplane. That's all I'm saying. Operationally, this specific behavior is not correct, regardless of how rewarding or enjoyable the overall product may be. We're talking about a system-specific issue, nothing more. And I'm quite sure the “RL MAX pilot” would agree with my findings. I don't think his view would be any different when it comes to the actual operation of the FMC.

I understand the “it’s a game” argument, and I agree that no add-on is going to be completely free of bugs. However, I would respectfully disagree with calling this merely an “annoyance.” Having been previously qualified on the real equipment, my expectations are naturally a little different. When an aircraft system is modeled incorrectly or a particular functionality simply isn’t there, I see that as a functional limitation or a bug, rather than just a minor annoyance—especially when we are talking about systems that should behave in a specific, predictable way. Of course, the importance of an issue depends on what we know about the real aircraft and what we consider an accurate simulation. Some users may never notice or care about these things, while others will immediately recognize them. And yes, you can certainly find minor problems in many paid add-ons. But that doesn't necessarily make the problem insignificant. Other “games” have implemented certain systems more accurately, while others haven't. For me, the question is less about whether it is technically a game and more about what level of simulation the developer is claiming to provide and what we should reasonably expect from it. From my experience flying the real equipment, that's where I tend to have a somewhat different perspective.

Yep, unfortunately, they still have quite a few bugs despite all the claims. 😄 That said, despite my criticisms of PMDG, I have to admit that, overall, the PMDG 737 and 777 FMCs are much better in certain aspects of operation and workflow.

I started using the iFly 737 today and have already encountered two additional issues related to pilot-defined/manual waypoints. 1. PB/PB waypoint created from a previously created PBD waypoint This occurs in the following scenario: After creating SOR01 as a PBD waypoint using the appropriate place/bearing/distance entry, I attempted to create another pilot-defined waypoint as a PB/PB (course intersection) using: SOR01 120 / GIPOR 225 In other words, the second waypoint is defined by the intersection of the 120° bearing from SOR01 and the 225° bearing from GIPOR. The FMC currently returns “INVALID ENTRY.” This is incorrect. The Boeing 737 FMC logic allows PB/PB waypoints to be defined using existing fixes, and the previously created pilot-defined waypoint should be a valid reference point. The resulting waypoint should therefore be accepted and displayed as SOR02, following the normal Boeing naming convention for successive pilot-defined waypoints. 2. Scratchpad display of a previously created PBD waypoint There is another related issue. When SOR01 is selected into the scratchpad, instead of displaying the original waypoint definition, i.e. the PBD information: SOR225/8.0 the FMC returns only: SOR01 That is also incorrect. The Boeing FMC allows the expanded definition of a created waypoint to be retrieved from the route/LEGS page. For a PBD waypoint, the underlying place/bearing/distance definition should be available rather than simply returning the abbreviated waypoint identifier. These two issues appear to be related to how the FMC handles pilot-defined waypoint references and to the distinction between the displayed abbreviated identifier (SOR01) and the underlying waypoint definition (SOR225/8.0). Perhaps a little more attention is needed during both programming and testing of the FMC waypoint logic. It is quite unpleasant to discover a different bug at almost every flight, particularly with fundamental FMC functions that are well established in the Boeing 737 implementation. The expected Boeing behavior here is quite clear, so I hope these issues can be reviewed carefully and corrected.

When I had the RX 6600, I used this tutorial with satisfactory results. It helped a lot in my case.

Thinking back to the classics, we had a few guys who went sideways after retirement. We used to call them “switch bitches”—always complaining, always finding something different. They weren't professional FEs, and it could be difficult to adjust to having them around. But the really good ones—the professional FEs—we called the “systems gods.” And they truly were. It was both hilarious and painful to see a former CA, after so many years in the left seat, suddenly find himself in that position. But we knew each other well, so you can imagine the back-and-forth comments and the good-natured abuse that went with it. Many times, on ferry or no-revenue flights, I would reward them out of respect by giving them the left seat and letting them have their moment. That worked beautifully until one rather weak FO decided to turn me in. I was lucky that the CP and DO were classmates, and I escaped with nothing more than a serious verbal warning: “Cut it out!” Those were different days—different airplanes, different characters, and, in many ways, a different airline culture. Looking back now, some of those memories make me laugh, while others make me realize just how fortunate I was to have been part of that era. Now, after retirement, I spend two weeks on and two weeks off in the simulator. I have to admit, I get humbled by what I see and by how much there still is to learn. But honestly, it is a wonderful feeling to still be involved in airline training, to share what I've learned, and—just as importantly—to keep learning from others. Not as much as before, of course. The days of living in the cockpit are behind me. Now I feel like a lion in a cage. But I'm genuinely grateful for this opportunity. After all those years, I never imagined that retirement would still give me a chance to sit in a simulator, teach, share a few stories, and continue learning alongside the next generation. And perhaps that's the best part of all: you never really stop being a pilot.

I use this TP-Link Powered USB 3.0 Hub with 7 USB 3.0 data ports and 2 smart-charging USB ports. It’s compatible with Windows, Mac, Chrome, and Linux, and it also has a power on/off button and a 12V/4A power adapter (UH720). I’ve had no issues with it since purchasing it. At the same time, I would recommend checking that your USB ports aren’t going to sleep. This can be adjusted individually, or you can select a power plan that prevents your peripherals from being put to sleep unnecessarily. I hope this helps and that it solves your similar issue!

Very good question and short answer. You don't independently change your cruising level merely because you cross the national/FIR boundary. The level change is made according to the clearance/transfer/handoff arrangement between ATC units, and is normally coordinated so that you enter the next area at the appropriate level. This EUROCONTROL structure differs in certain respects and uses different semicircular allocations, requiring a level change for traffic entering the next area. Operationally, it's quite interesting to see in upper European airspace that the controlling sectors frequently don't correspond to national boundaries. Maastricht UAC, for example, controls upper airspace over Belgium, Luxembourg, the Netherlands and northwest Germany, and its sector boundaries are designed around traffic flows rather than national borders. Normally, for a normal European overflight, the level change is often handled almost invisibly to the crew because it has already been coordinated between sectors. Just to remember, you fly the cleared level, not the level you calculate from the new country's semicircular rule. You do not climb on your own; you remain at your assigned FL until ATC clears the change.

I would check this option under “My Plane.” On my end, I’m not experiencing that issue. Regarding A/T engagement, SOPs vary between operators. Some specify A/T engagement during the preflight flow, while others place it in the Before Takeoff checklist or as part of the takeoff sequence. There is a good operational reason why some airlines deliberately avoid engaging the A/T too early. Keeping the system inactive during preflight and taxi reduces the opportunity for an inadvertent thrust or automation-mode activation while the aircraft is still on the ground. NTSB investigation material documents several instances of inadvertent TOGA/go-around activation and highlights the human-factors risks associated with automation mode errors. That does not necessarily mean that one SOP is universally “right” and another is “wrong.” Both can be valid when properly designed, trained, and monitored. However, from a human-factors standpoint, there is a reasonable safety argument for delaying A/T activation until the aircraft is configured and the crew is at the appropriate point in the Before Takeoff/takeoff sequence. It minimizes unnecessary automation during taxi and establishes a very deliberate transition into takeoff thrust management. In my opinion, the NTSB data provides enough evidence to take that additional layer of protection seriously, even if it does not establish that one particular airline SOP is universally safer than all others.

Boeing 777-200LR was offered with three optional auxiliary body fuel tanks, providing approximately 21,000 liters (5,550 US gallons) of additional fuel capacity in total. Boeing lists the standard wing-tank capacity at 47,890 US gallons (181,260 L), with the three optional body tanks adding the additional capacity. The actual fuel-tank configurations were part of the aircraft's customer-specific configuration, so the presence and configuration of the auxiliary tanks depended on the aircraft ordered by the customer. For the 777 Freighter, auxiliary fuel tanks are a much less attractive operational option because additional fuel capacity also means additional weight. In cargo operations, the operator is often better served by maximizing payload and, where operationally practical, using a technical fuel stop rather than carrying the additional fuel weight for the entire sector. In other words, a freighter operator may choose to carry more revenue-generating cargo and make a fuel stop when necessary, rather than sacrifice payload capacity for additional auxiliary fuel. That is an operational and economic decision based on the specific route, payload, fuel requirements, and economics of the flight. So, in the PMDG 777-200LR, the availability of auxiliary fuel tanks reflects a real Boeing customer configuration option. The important distinction is that Boeing's published documentation identifies three optional body tanks as a configuration, rather than a generic requirement that every 777-200LR have them installed.

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.