PurdueKev

Well I figured out what is happening, at least for NXi-equipped aircraft (I tested in the C172 G1000 as well as the DA62), though I am not certain if it is a bug or if it is supposed to work this way: - if you engage the flight director prior to engaging the AP (either by clicking FD or another mode like HDG or NAV), the AP will indeed default to PIT mode if you haven't set a vertical mode, so that works like real-life; - however, the pitch angle is set at the moment you activated the flight director, not the moment you engage the AP; - if you haven't pre-selected any mode in the flight director, when you click AP then indeed ROL and PIT are displayed on the annunciator by default and your roll and pitch angles will be set at the moment you engaged the AP. So the behavior is just as Ark observed: you can start a climb, engage the AP and the aircraft will hold the pitch and roll angles by default until you select other modes. - But, if you click FD or, say, HDG or NAV (in case you want to initially follow a runway heading for example) while still on the ground, the pitch angle is set at whatever your nose attitude is while sitting on the runway! So, when you do engage the AP, the flight director will try to deliver the pitch angle you had when you activated the flight director command bars (which on the ground is basically level flight), not the pitch angle of the climb you are in. I confirmed this by checking the magenta command bars on the flight director while climbing before hitting AP - sure enough, they were pointing down, indicating the aircraft would pitch down to level flight as soon as the autopilot servos were turned on. - What this means is that if you want to, for example, preselect a desired runway heading to follow with the heading bug before takeoff, you have to be careful NOT to click HDG while still on the ground without also commanding a climb mode in the flight director like VS or FLC - otherwise, when you click the AP on the plane will level off abruptly to the pitch angle that was set on the ground. You can simply pre-tune the heading bug as desired but you have to leave the flight director off, so that the pitch angle initially followed under PIT mode is set as your nose attitude at the moment you engage the autopilot once established in your climb. Some people might think that is all intuitive, but it wasn't to me. It especially means people who like to fly airliners, where you do typically engage the flight directors while still on the ground, can't do that in a G1000-equipped aircraft in MSFS. Someone who knows how the G1000 works in real-life would need to confirm if that is a bug or if it really is the way the real system works. By the way, I also did observe that the default steam gauge autopilot indeed defaults to VS mode but does NOT capture the climb rate at the time you engage the autopilot. Instead, it levels you off at 0fpm as MarkDH noted, and there is no way in the MSFS unit to preset the vertical speed to anything other than 0fpm without all that SPAD programming. That is definitely a bug, or at minimum a gross oversimplification of the real-life KAP140 (which I know for a fact lets you pre-program the desired VS before engaging the AP while on the ground).

Are you sure on the WT NXi? I just tried it, and I am absolutely certain I am getting ALT mode when I hit the AP button, even when I have PIT showing on the annunciator. This is for the Bonanza (both default and the modded) and the C182. Which planes can you confirm this on? I haven't been through everything that uses the NXi, so maybe it is aircraft specific.

I tried a search for this specific issue, and I just need to check that I am not crazy in seeing this behavior (which I think is a bug)... In any of the G1000 aircraft (yes, running the WT NXi mod from the Marketplace) and also any of the steam gauge aircraft with the default traditional autopilot: when engaging the AP in a climb and having no other vertical modes selected, the autopilot seems to default to ALT mode and violently checks the ascent to get back to whatever altitude you were when the AP was engaged. My understanding of at least the G1000 (but also the type of generic steam-gauge autopilot that is being modeled) is that the autopilot should default to PIT mode when no other vertical mode is commanded in the flight director. In other words, you should be able to establish a manual climb to say 10-degrees nose up, and if PIT is indicated on your instrument then the aircraft should hold that pitch angle upon engaging the autopilot, until/unless you have commanded one of the other vertical modes (ALT, FLC, etc). My questions: 1) Am I correct that the default mode should be PIT, not ALT? (I know the G1000 manual says it should be PIT) 2) Is everyone else seeing the same behavior? I figured this would be well known and I would have found posts on this via Google, but I don't see anything about this specifically (there is lots on crazy AP going into dives and such, but this is not that). Want to get confirmation before I file this as a bug with both WT and Asobo. The reason this is important is that it forces you to preselect either FLC mode or VS mode with a preselected climb rate, which I understand is not realistic and wouldn't necessarily be forced SOP in the real world. I haven't checked all of the aircraft, but my brief survey with the Cessnas, Beechcrafts, etc all show this behavior.

I am using the latest game-ready derivers that came out on Monday, 511.79. Main reason is I just got a 3080 and so I wanted the most up-to-date drivers on my system to take advantage. As a general practice, though, I tend to not jump on new drivers until I pick up software or hardware that needs it. I prefer to do a clean install on video drivers, and I can't keep up with constantly re-doing my game-specific settings all the time... so probably I update only every few months. No reason for me other than convenience and time.

This would be my hesitation as well. It did appear that they got things sorted in the end, but it took them a real long time to get there. I don't know if that was a one-off and they have now figured out how to do this right on the 2nd go-around, but it gives one pause. Spending $80-90 on an add-on that works fully "out of the box" with maybe just a few bugs to fix (a la PMDG, FSL, etc) is one thing... Having to wait months or years for the product to function properly while they have your money is entirely something else. I am tired of flight sim software developers who treat their paying customers like angel investors to finish their projects. I could be convinced to spend this much from a developer with a longer track record of quality. I will personally "wait-and-see" on this one, especially at this price.

So how long are paying customers supposed to wait for a fundamental advertised feature to be functional and reliable? I don't remember reading anywhere that MSFS is an Early Access title.

Yes, I think all 172 amphibian has this problem as well. No one has found a workaround that I can tell. Basically those planes are useless as amphibians because you can't steer them - even differential brake application doesn't work. This is one of those silly bugs that, while not game-breaking per se, makes you scratch your head as to how it gets through testing and how long it will take to fix it.

Allow me to make a slight counter-argument... I have been fairly fortunate in that I have not encountered the CTD's and the only issues I have run into are either annoyances, or issues that while disappointing still allow use of the sim. However, that doesn't help the not-insignificant segment of the user base that isn't able to use a product that they paid for because a mandatory update was pushed to them. If the platform is intended to be as developmental as you say, and indeed as the developers openly suggest, then frankly the constant drumbeat of mandatory updates that either break major features of the sim or break compatibility with major complementary payware packages (packages that the develop encourages by providing an in-game marketplace, by the way) is not compatible with that objective. It simply creates extreme frustration amongst the user base and third-party developers, and it is borderline questionable from the standpoint of a business practice. Any user that has their use of the program interrupted by program-breaking bugs in a mandatory update really has no recourse but to complain as loudly as they can - the publisher already has their money, and they can't get a refund. What else are they supposed to do? DCS and Xplane have largely taken a different approach with updates - there is almost always an optional public beta branch for the next update cycle in order to test new features and changes with the maximum number of users, and that allows experimentation in a development environment where users aren't forced participate and thus have full use of the product they paid for while bugs are worked out on the beta. For both platforms, those public betas have in many cases taken months before release candidates were rolled out to everyone. This is especially important in a PC environment with so many different configurations of hardware and software. It is laudable that the developers have a long-term vision for the platform, and I agree that the level of commitment to a very public long-term roadmap is a breath of fresh air. But there is a commercial term for when software developers would like to offer a product to users with the promise of long-term development where features may be removed, broken, repaired and reintroduced in an experimental manner - it is called Early Access. But that is not how this program is marketed, is it? In my opinion, the flight sim community has been far too tolerant of this kind of behavior from developers and publishers. When someone has paid full price for a product or service, it is reasonable to expect that product or service to be available for use and not rendered unusable (as it is for some users right now) or with major features and performance removed or dismantled. MSFS isn't a community payware product - so why do we contend we have to treat it like that? The best and most trusted developers are the ones who try to get it right out of the gate, and take care to keep it that way as they continue to improve their product. And they get a massive amount of loyalty because of it. Again, I am overall satisified with MSFS myself and haven't gone back to [other flight sim that shall not be named] in many months, and excited for the development possibilities for the future. I certainly expect this sim to innovate far beyond what [other flight sim that shall not be named] did in a similar period of time. But the "tut-tutting" from certain quarters that implies people should just be happy with whatever bugs, CTDs and broken features they are served on a regular basis gets tiresome. And Asobo/Microsoft really should rethink their approach to rolling these mandatory updates out if they want more flexibility to "push the envelope."

This is exactly what it seemed to me as well - you articulated it better than I could. The way reflections are displayed seems completely nerfed. Someone in this or another thread compared to Xplane, and that is what immediately came to mind for me as well. XP's reflections (at least up to a year or so ago - I haven't tried the latest release) were always a bit weird and ugly, and what I see reminds me of that.

I saw the same. The only way I am able to do it is by using the Prop level on my throttle quadrant, which is bound to the Prop axis. With full prop, the throttle lever in the sim slides left to flight idle; when I move my prop lever to the bottom, the lever slides back to the right.

I will be honest - it doesn't appear to be consistent from session to session (at least what I have observed in limited time with SU5). Did a flight around Hawaii last night, and there was very offputting morphing all over the place (that was why I posted my initial response) - worse than what I had ever seen previously with MSFS. But I just did a flight around Bella Coola, BC which is particularly mountainous and there was hardly any significant morphing. Different flights, of course, so I don't know if there was another variable at play. Also don't know how much is being controlled on the "backend" by what the servers are feeding. I spent a little time in dev mode trying to see how high I could move each setting without impacting my system, but I am honestly scratching my head understanding what sliders do and don't do what. I don't now if there is a slider that addresses or impacts the terrain complexity and LOD distance. For now, I basically just set each setting to the max level where I wasn't dropping frames - I don't know if that did anything to the terrain morphing or not.

I don't think it is your hardware or bandwidth - terrain morphing is significantly more noticeable after the update than before.

Yes - the "Ignore" function in our Profile is our friend in this case.

I'm with you. I find little point in flying alone without any AI. Took a break from MSFS waiting for this update; guess I will wait a little longer. Don't understand how this kind of bug can be de-prioritized 9 months after launch. Appears MS got everyone to spend full price on what appears to be the equivalent of an Early Access title, with the way major features are broken in every "update."

Same for me. 9 months after launch, and we still have to put up with inconsistent performance that just comes and goes. *shaking my head* Hoping that the vaunted "performance upgrade" coming later this month will finally fix things, but I will believe it if and when I see it.