JDWalley

Randazzo had previously said that the MAX would follow the 739, and then we'd get the 777 followed by the 747. I wouldn't mind the order getting flipped so the 777 would come first.

That doesn't always work, either. I've had problems (not with MSFS) where I thought a restore would fix it but, instead, after a great deal of disk churning, I got a "System Restore Failed" message. (Or the system restore "completed" normally but the problem was still present.) In at least one case, the only solution was to wipe the drive and do a complete clean install.

Obviously, I'd prefer a lot more, but 48 hours is long enough to avoid the symptom of nighttime conditions at midday that I experience now.

Do you have a pilot's license at all? If not then, by your own standards, shouldn't you reason that being able to fly is something that's "never going to happen" and delete your sim?

Great to hear, but could you please put your specs into your signature so we could see what you're working with?

Exactly. Far better for non-beta-testers to stay on SU9 for a while longer than to have to install a buggy forced update that renders the sim unusable for them for that time.

Maybe I’m being obtuse, but…"AMD sharpening thingy" on an RTX 3060?

That's worrisome, as it suggests that the VRAM demands are very high. Has anyone with a 12GB 3080 had good results, or do you need to go all the way to a 3090?

Historical weather (or an interface to a third-party add-on like ActiveSky that could provide it).

More like "can a person who played flight sims as a kid (probably only using default aircraft) be able to handle a full-motion simulator?" The number of ways this video is half-(word not allowed) is almost beyond counting. First off, the way this sort of question is normally asked (as in the setup here) is whether a person who uses flight sims could land an airliner in an emergency. Assuming that the person in question had any sim experience with study-level airliners, they would obviously go for the first scenario -- get on the radio and get instructions on how to proceed to an airport with suitable weather and a Cat III ILS, and then do an autoland. He did so, and got the aircraft down safely. Mission accomplished! Since that is obviously not the result that the video wanted to emphasize (after all, they wanted to go on and on about Dunning-Kruger), they have to raise the stakes to where no one in that emergency situation would be ever think of going: having the non-pilot hand-fly the airliner. Even so, he did manage to get it down, but was told "you crushed the landing gear," without any mention of the actual landing rate, just letting him ad lib that "the plane slid on its belly and burst into flames." Maybe, maybe not. What about giving us the exact figures, so we could determine how damaged the gear really was? And the "best" is yet to come, where a non-pilot, with zero IFR training, is expected to hand-fly an airliner to a landing where the cloud base is at approximately 30' above the runway surface. Ever hear of the term "minimum?" If this (word not allowed) me off, it's because it seemed to me that they went into this "investigation" with their minds already made up and the conclusion fully-scripted, and then staged the "test" to get the results already decided upon and wrap it up in a smug little bow for the public to gobble up uncritically and consider themselves thoroughly educated on the subject...which, ironically enough, is an even better example of Dunning-Kreuger. BTW, if you want to see someone with actual current experience in PC flight sims take on a much more difficult task in a similar environment, check out Airforceproud95's experiment:

Just so I'm clear -- you now no longer need to install P3D and ActiveSky in order to get weather that isn't CAVOK?

I assumed this thread was long-since dead. I posted my issue last November, and they resolved not long thereafter.

The same could have been asked about MSFS itself. 😁

Well, I did check all the buttons on my joystick, and did find one duplicate assignment (and am I the only one that thinks this is a truly dumb design decision?), but it wasn't a button used on any of my prior flights, so that doesn't seem to be it. What it does seem to be, as far as I can tell, was that I was "cheating" on some of the flights and, since they were short and done with a clear skies preset, I would save time by entering the approach phase info (QNH, temp, winds, and transition level) before the MCDU prompted me for them. Don't know why that would screw things up (or if it would do the same in the real Neo), but I noticed that, every time I had problems with approach speed, it was when I entered the information early. Every time I waited until prompted, the approach speed was controlled properly in managed mode, so I guess it must be an issue.

As it turned out, the majority of the problem did turn out to be a weird key binding. On one test flight today, I set the camera at an angle where I could see the entire FCU and upper ECAM, and I discovered that, every time I dropped the flaps one notch, the A/T disengaged. Odd, because there was nothing set for that function. However, I checked the particular joystick button I was using for that, and found out it was controlling not only the extend-flaps-one-notch function, but also something to do with the engine thrust reversers (not deploying them all the way, but something that it obviously shouldn't have been doing). So, I deleted that assignment. Problem solved? Kind of... With that binding removed, I was no longer getting the completely haywire behavior I'd encountered before. However, while the A/Ps would now capture the LOC and G/S and follow them down, the airspeed control could be flaky. I've only tested it on a couple of routes into different destination airports so far, but I found that, on one, going into approach mode and deploying the flaps and gear at the proper points meant that the aircraft would slow on its own to the Vapp and remain there until touchdown; however, at the other airport, while the LOC and G/S would engage and bring the aircraft down toward the runway, the airspeed would remain where it was at the final speed constraint before the approach (i.e., if the final approach fix was at 210KTS at 7000', as it was at KDEN, the aircraft would start descending toward the runway at 210 and keep up that speed unless I dialed in the proper Vapp in selected mode, whereupon it would fly the approach properly. I still need to run further tests to figure out if it's something I'm still doing wrong, or a bug in what is after all still an experimental build.