LRBS

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.