Stearmandriver

You're probably describing differences in trim state. One thing the iFly does extraordinarily well compared to other airliners I've tried in MSFS is their handling of thrust/pitch coupling, and pitch moments with configuration changes. Every time you move the throttles (in an airplane with underslung engines and not much fly by wire), you need pitch trim if you want to stay in trim. If you don't, you'll be out of trim. Same with flap and even gear extension / retraction. This is probably one of the first things I noticed about the iFly flight model - I found myself using trim habits in it from the real airplane, where once you're comfortable hand flying, you'll find yourself anticipating trim state changes and trimming them out as they happen. I caught myself doing it in the sim and realized it was working. If you're used to the PMDG or other sim airliners, this'll feel exaggerated to you until you get used to it, but it's pretty good.

I'm not really sure they're "way too bright". These LED landing lights are ridiculously bright in reality. Flying through clouds with them on is an absolute glowing white wall; doesn't look much different than the sim to me. I think maybe people are noticing them more in 2024 because there's often some haze in 24 for them to reflect off of. The only real complaint I have with the landing light effects is that they should not be able to over power the HUD the way they do, but that's a matter of the HUD needing to be able to be brighter, vs the lights dimmer. On the other hand, I also run 2024 with a full -1 stop of exposure compensation. Everything about the sim looks more natural there, vs the cartooniness of 2020. I guess most people aren't doing that, and the lights are likely brighter then.

I don't know if different liveries have custom panel configurations, actually. I always have to reconfigure the official iFly Alaska livery after installing a new version, so I guess at least that one doesn't. Unsure what third party guys like @Steve Dra or Jviation do... Maybe Steve can chime in. As far as the blank space on the PFD, as far as I know that's standard on Maxs. The area with the clock, flight number, selcal, timer etc is called the aux display. In aircraft with the HGS, there will be a black display above that labeled "HGS"; this is called the HGS status panel and allows the first officer to monitor HGS modes and performance so that both crewmembers can verify they're getting what is needed in low vis. But other than that, yep, wasted space. The iFly accurately handles display auto switching, which causes the display configuration to change. If you're curious, give yourself an outboard DU failure and watch how the aux panel jumps up on top of the PFD side of the suddenly-split-screen inboard display.

I can't add much to what @LRBS and @ahsmatt7 have said. As they explained, there is an initial elevator feel resistance to start the rotation, and there is also an aerodynamic "dead band" about halfway through the rotation when the horizontal stab enters the area where airflow is partially blanked by the wings, with the mains still on the ground. But LRBS nailed it - the key here is that this all happens "stable and smooth". That's exactly right. There are no abrupt transitions in feel, and while a 73 is not a "heavy", it's still a heavy airplane at 180,000 or 190,000lbs gross weight (Max9s). You feel that inertial, the plane is a very stable platform, and nothing abrupt or jarring happens. PMDG simulates these effects but as noted, they just don't end up feeling much like the airplane. You feel as if you can tell when you've hit an abrupt coded transition, where "elevator feels like this, and then it feels like that.". It just doesn't end up working very well. "Stable and smooth" really sums up everything I like about the iFly flight model compared to the PMDG. It's extremely smooth, and you feel as if you're controlling a stable platform with some intertia behind it - which is how airliners fly. As LRBS and I were discussing, there are a few exceptions in 2024 right now where the iFly all of a sudden can be affected too abruptly by a gust or wind shift. It doesn't happen very often, but I notice it because of how it contrasts with the normal feel. I've confirmed that zero FDE changes were made to the aircraft for the SP1 update, so what we're seeing is related to how the 2020 flight model occasionally is at odds with 2024 physics. It'll be addressed in the 2024 native version; it's the reason they were careful to stick with the "experimental" tag for 2024. I only find I notice it maybe one time in every three or four flights on average so it's not too bothersome to me in the meantime, but it probably depends on the conditions you usually fly in. All my simming is done pretty late at night for instance, and I leave live weather on, so I'm sure I'm seeing less thermals and gusty winds than some others do.

The thing is, I don't think any flight model changes were included in SP1. Flight guidance and autoflight changes yes, but the actual hand flying flight model should be the same. I wonder if what you're seeing is a matter of 2020 vs 2024 physics? The plane definitely flies a little differently in each simulator. What I notice is, In 2024, ground effect, flare behavior, and crosswind effect are superior; but turbulence and wind gust effects are too abrupt. That'll be addressed as part of the 2024 native build. But I don't think there are any actual differences to FDE code.

Airliner: iFly Max8 Bush platform: Milviz/Blackbird PC-6 Porter Piston GA IFR platform: toss up between A2A Comanche and Aerostar, but I think the Aerostar wins. Pure stick and rudder, beating around the pattern at summer grass strips: just like in reality, this HAS to be a J-3 Cub, and the CAS Cub in the sim is perfection for it.

In case you weren't aware, Return to Misty Moorings does exist for MSFS 2020 / 2024 too. It doesn't include all of the epic previous locations they had, but what's there is a lot of fun still. I agree, I'm surprised this form of scenery design isn't more popular.

Yes, as well as cpu usage.

A patch has entered testing that should fix the excess resource usage by the iFly app and EFB. Also adds some extra customization options to the EFB (personal wallpapers, start up video.)

Well now this IS interesting. Thank you for the screenshots. I've created a bug and forwarded your screenshots in the report. I'll test the route myself tomorrow and get video for the team too. To verify, 2024, right? I know I've seen correct behavior (shallowing the descent before 10k, reversion to VNAV spd when appropriate), so I'm not sure if there was an uncaught regression somewhere in the test builds or if this is something that only affects certain arrivals etc, but it definitely looks like you had a bug on that flight. I made a flight in the iFly tonight to look at this and coincidentally (I did not see your post beforehand) I went to SFO and flew the SERFR. I did note that I needed speed brake on the descent, and it feels like I have been using the brake a lot on the plane lately, so I can't say what the plane would have done if I hadn't helped it. I'm wondering if it's possible that we're all so used to pulling the speed brake when necessary that this behavior snuck in without being noticed. I DID test it in an early SP1 build though, as we were specifically asked to, so I can see how no one might have been looking for it subsequently. But yeah, I'm going to beat it to death tomorrow night, I'll get them all the video they need. As far as banking behavior, I watched that closely at every enroute and terminal waypoint, and I still don't see a problem? Wondering if it depends on having a strong crosswind or something? The real plane will roll somewhat aggressively when necessary to stay on course; you see this most often during localizer intercept. But yeah, everything looked fine on my flight. I suspect whatever is being seen could be related to 2024's gust and turbulence modeling being different than 2020s. My flight tonight was pretty smooth.

Was this in 2024? I suspect some of what you're describing is a function of the custom flight model not playing nicely with the different gust and turbulence physics in 2024 vs 2020. I've seen nothing but consistently perfect autoland performance, but I'm always testing it with my catIII weather preset which has near calm winds, as catIII conditions usually do. I've also never tried a fail operational autoland since we use fail passive (no benefit to maintaining fail operational with the rollout guidance in the HGS), so I wouldn't know what I was evaluating anyway... But worth noting that the autoland crosswind limitation is 15kts.

Can't say I've noticed this, but I will try it out specifically tonight.

Not really. NGs won't do this any more than Maxs will; the plane will pitch up to slow at a set schedule in VNAV speed but it won't actually level off. Maybe you mean the PMDG will do this; I don't remember. But actual NGs aren't any more aggressive than a Max in the decel. If the scratchpad is informing you that drag is required, that's not an invitation to put on a dress. 😉 The iFly box definitely builds decel points for speed restrictions on the legs page. Again, depending on the accuracy of your descent winds, it may need help from you. As long as you see the speed bug properly command a decel, the box is working correctly. I'll try a star with some intermediate restrictions tonight, but I haven't seen any of this work incorrectly since SP1 started testing.

Well, is it a matter of the VNAV speed not commanding 250kts (actually 240kts below 10k is the default), or is it a matter of the speed being commanded but the plane not doing it? That's not unusual; the autothrottle mode is Arm during a VNAV descent so that the autothrottles are unclutched and the pilot can be a pilot. VNAV isn't magic; it expects you to add thrust when necessary, and also to add drag when necessary. So, if you're descending in VNAV path, and the speed has gotten fast approaching 10k and remains fast below 10k even though the speed bug is correctly commanding a decel, it's not the plane that isn't doing its job, it's you. 😉. The VNAV path will be built with a decel point to 250kt at 10k, and the plane will pitch up to follow the pre-built decel, but if you start that decel 20kts fast, you're probably going to finish it 20kts fast. The plane will eventually transition to VNAV Spd and pitch up to chase the commanded speed below 10k, but it won't happen immediately and it won't happen at 251kts. It happens a certain amount of time after exceeding commanded speed by a certain value - could be 10, 15, or 20kts fast depending on operator option. I forget which the iFly has modeled. But if you correctly use drag as necessary, just like in the actual plane, this won't be an issue.

I've seen one or two other reports of this; could you share the conditions it happened under? Were you in VNAV Spd or VNAV PTH approaching 10k? Was there an in-close waypoint with a faster speed restriction etc? In general, VNAV definitely does respect 250 at 10k (or whatever restriction you put in the VNAV descent page). I've never personally seen it not. But if there's an edge case problem, they'll want to fix it.