LRBS

My impression is that their products are visually appealing, inside and out. However, I think a few shortcomings could be addressed relatively easily by adjusting certain configuration files. For that reason, I'm not interested in the Marketplace versions. Some of those files are protected, which prevents users from making further adjustments to suit their preferences. There may also be other limitations or inconveniences associated with selling products through the Marketplace. I suspect I am not the only customer who feels this way. Regardless, I believe the developers would be better served by offering their products through their own store as well as the Marketplace. Why limit themselves to a single distribution channel when they could offer both options? Letting customers choose where they buy their products would give those who prefer greater flexibility the option to make their own adjustments, while still accommodating customers who prefer the Marketplace's convenience. In my view, offering both options could broaden their customer base and potentially increase overall sales.

For taxing, it's also in its own code, but it can be helped a bit by changing to this [CONTACT_POINTS] point.0 = Name:Wheel_Central#Properties:1,70.3,0,-13.72,1500,0,1.791,55,1.401,1.4,0.450,13.5,13.5,0,485,0,5 max_speed_full_steering = 65 max_speed_decreasing_steering = 102 min_available_steering_angle_pct = 0.02 steering_time_constants = 6,9 allow_stopped_steering=1 spring_exponential_fix = 1

To confirm what you mentioned, this is an intermittent behavior and is not limited to the takeoff/climb phase. As you correctly stated, “I have my own way of doing things.” That is perfectly reasonable. Pilots develop their own techniques and preferences, and the 777 allows for that. However, regardless of the technique being used, the aircraft's response should remain consistent with the aerodynamic and flight-control characteristics of the real airplane. What concerns me is not the initial pitch response when a new speed is selected, but the rapid pitch oscillations or “bouncing” that can sometimes follow. In calm conditions, particularly with only 1 m/s of wind and zero gusts, that type of rapid, repeated pitch response would not be representative of the real 777. I would suggest making a short video demonstrating the behavior. That would make it much easier to identify exactly what is occurring and under what conditions. If what you are describing is the same small, rapid pitch oscillation I have seen, then I recognize the behavior. Similar micro-oscillations have been present in the simulator environment going back to FSX. From my experience with the real 777, this is not representative of normal aircraft behavior and is something that should be addressed in the flight model/control-law implementation rather than attributed to the pilot's technique.

@Christopher Low, I checked the takeoff sequence, and everything is correct. As I mentioned, when the airplane is below the selected 175-knot target and speed intervention is selected, the AFDS will adjust pitch as necessary to accelerate toward the MCP-selected speed. Conversely, if the airplane is already above 175 knots when speed intervention is selected and 175 knots is set on the MCP, the AFDS will increase pitch as necessary to decelerate toward the selected target. The important point is that selecting speed intervention overrides the FMC-computed VNAV speed target. In this case, the normal VNAV acceleration schedule is no longer controlling the airplane; the AFDS follows the MCP-selected speed instead. Therefore, if we select 175 knots during the climb, the airplane will remain at that selected speed rather than continuing with the programmed VNAV acceleration schedule. To return to FMC/VNAV speed management and allow the normal acceleration profile to resume, we need to deselect speed intervention by pushing the MCP IAS/MACH selector again.

Sorry, no, nothing like that in the real airplane.

Unfortunately, I don't find the PMDG 777's flying characteristics and flight-control behavior particularly convincing. This has been an issue, in my opinion, since the aircraft was first developed for the various simulators, including P3D, and some of the same characteristics appear to have been carried over into the current version. The overall result does not closely resemble the way the real 777 flies. For example, the 777 does not simply "pitch up" shortly after takeoff, nor does it rotate to around 10° and then suddenly pitch rapidly through 15°, as mentioned by @BWBriscoe. The actual rotation and subsequent pitch response are much smoother and more progressive. The airplane establishes the commanded flight path in a controlled, steady manner rather than producing that abrupt pitch change. I'll run your scenario and report back with what I observe. Regarding the speed window, there is another important point. Once you open the MCP speed window during a VNAV departure, you are intervening in the VNAV speed management rather than simply continuing to follow the programmed takeoff profile. The resulting pitch response depends on the relationship between the airplane's current speed, the selected speed, and the phase of the climb. For example, if the airplane is below 175 kt and you open the speed window and select 175 kt, the airplane will lower the nose as necessary to accelerate toward the selected speed. Conversely, if the airplane is already above 175 kt when you intervene and select 175 kt, the airplane will increase pitch to decelerate toward the selected target. That behavior is quite different from the airplane simply "pitching up" or "pitching down" arbitrarily—the flight-control system is responding to the selected speed target.

Could you elaborate on the issue? For example, at what stage (alt) do you engage the A/P, at what speed, and where is the speed bug set?

Thank you very much for the kind words. I really can’t form a personal opinion about the product since I don’t own or use it myself. I simply thought it would be helpful to share some information from someone who is knowledgeable about this type of equipment and has a great deal of real-world experience. I hope you find the information useful.

I asked a C-130J pilot currently in transition training about the engine-out characteristics. The C-130J has several systems that significantly reduce the workload following an engine failure. Most important is the Automatic Thrust Control System (ATCS). Following an outboard-engine failure, ATCS automatically reduces the power on the opposite outboard engine to reduce the asymmetric thrust moment. As airspeed increases and rudder effectiveness improves, ATCS progressively restores the power on that engine. Lockheed Martin describes the system specifically as a means of reducing asymmetric thrust and lowering the minimum control speed following an outboard-engine failure. The aircraft also has rudder boost, which provides the hydraulic authority necessary to obtain substantial rudder deflection with reasonable pedal forces. The published C-130J performance data show that rudder effectiveness and rudder-boost pressure are important factors in determining VMCA. The important point, however, is that ATCS does not simply sense the engine failure and automatically trim the rudder to remove the yaw. There is still an initial asymmetric-thrust response, and the pilot must establish and maintain directional control with rudder. ATCS primarily attacks the source of the yaw by reducing the thrust asymmetry. Rudder input and, as appropriate, rudder trim remain part of the pilot's control of the airplane. That is somewhat different from the way many people think of modern transport-category fly-by-wire aircraft, where the flight-control system can automatically provide significant engine-out yaw compensation and associated trim functions. As for a three-engine-out condition, there are no published C-130J performance/envelope charts establishing a normal three-engine-out cruise or level-flight capability. The C-130J performance material does contain published one- and two-engine-inoperative control-speed data, but that does not provide or guarantee a three-engine-out performance envelope. According to the pilot I spoke with, the training scenario for Engines 1, 2 and 4 inoperative, with No. 3 operating at very high power, is essentially a controlled emergency-descent exercise rather than a demonstration of sustained level flight. The objective is to demonstrate aircraft control and bring the airplane back to the runway—not to establish a practical three-engine-out cruise capability. The more impressive demonstration is the ability to remain controllable at approximately 10,000 ft within the prescribed training area/approximately 30 NM of the airport, with Engines 1, 2 and 4 feathered and No. 3 operating at very high power, before returning for landing. That is a training demonstration. And there is an important distinction concerning an engine failure immediately after takeoff. The C-130J's ATCS provides a substantial advantage in an outboard-engine failure at low speed, specifically by limiting the asymmetric thrust and reducing the rudder requirement. Lockheed Martin states that the system is designed to essentially eliminate VMC as a practical safety consideration during an actual or simulated outboard-engine failure when ATCS is functioning normally. But losing three engines on takeoff—particularly Engines 1, 2 and 3—would be an entirely different situation. With only No. 4 producing power, the airplane would have an enormous loss of total thrust and a highly asymmetric configuration. There is no published C-130J performance basis for treating that as a climb-capable condition. In practical terms, it would be a catastrophic emergency requiring immediate attention to airspeed, directional control and the possibility of landing essentially straight ahead. So, in short: ATCS makes a single outboard-engine failure considerably more manageable by reducing the cause of the yaw; it does not fly the rudder for the pilot. Rudder boost provides the necessary control authority, while the pilot remains responsible for directional control and appropriate trim.

I think the 8 GB of VRAM on the RTX 5060 could become a limitation in X-Plane 12, particularly if you’re running high-resolution textures, scenery, or XME. The FPS itself may be fine, but once VRAM becomes saturated, you can start seeing texture blurries and other compromises. I’d take a look at Micro Center and compare the price of the 5060 with cards offering more VRAM. If the price difference isn’t too large, I’d lean toward the card with more memory for X-Plane 12. That said, the 5060 is certainly capable of running XP12 well. I’ve seen reports of 30–40 FPS with reasonably smooth performance, but you’ll probably need to make some sensible adjustments to the graphics settings. For XP12, I’d prioritize VRAM capacity and texture quality over simply chasing the highest FPS.

Quito's published procedures are quite explicit about the terrain issue. The current AIP says that departures from both RWY 18 and 36 are normally restricted in climb to 17,000 ft for traffic-management/safety purposes and are to follow the published departure procedures or ATC vectors. It also contains specific restrictions on turns after departure because of terrain. For the Airbus, as you mentioned, you can skin the cat in different ways. A Keep NAV + CLB if you're following the SID. At/approaching 10,000 ft, pull the SPD knob to select speed. Set an appropriate climb speed that gives you the required climb gradient rather than immediately accepting the higher managed speed. Keep OP CLB/appropriate vertical mode as applicable and monitor the altitude restrictions on the SID. Once you're safely clear of the terrain and the procedure permits it, increase the selected speed. Push the SPD knob to return to managed speed when appropriate. The important Airbus point is that selected speed is a normal technique, not some simulator workaround. Airbus specifically describes selecting speed when a higher rate or gradient of climb is required. B Program it before t.o. If the departure requires a particularly steep climb, Airbus documentation says you can preselect the acceleration-altitude speed on the PERF CLB page when a high angle of climb is required because of obstacles. So, rather than waiting until the aircraft is already accelerating through 10,000: MCDU → PERF → CLB and use an appropriate ACCEL ALT / speed strategy for the particular SEQM SID. I would not simply pull OP CLB and dial in 250 kt and leave it there without considering the SID constraints. Airbus documentation warns that when you're no longer in managed CLB, the aircraft can disregard the altitude constraints programmed in the flight plan. NAV + managed CLB + appropriate selected speed is fundamentally different from abandoning the managed vertical profile altogether.

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.