Stearmandriver

This is the way.

Oh, absolutely agree - I've always thought it was unreasonable to expect a sub-$100 sim aircraft to handle every outlier scenario correctly. Heck, even the level D sims still can't do that, though they got a lot better after the Colgan crash happened and the regulators mandated extended envelope training My point was just that if this maneuver is possible in the BB, then there are things wrong with the flight model that will affect how it behaves in every normal phase of flight as well. But I mean, I got this from Reddit. Who knows if it's even real lol. You guys with the airplane will have to do some experimenting!

I don't have the BB 757 and probably won't be getting it so I don't really have a dog in this fight, but I came across a video on Reddit that seems relevant to the flight model discussion here. Watch the pitch-up in this video... Looks like it reaches 60-70 degrees pitch up, while still traveling straight ahead in a level trajectory. That yields an angle of attack of roughly 60 - 70 degrees. And then the plane just flies away. The critical angle of attack of a 757 is similar to other airliners, at 15 - 18 degrees. This video displays a maneuver that is flatly aerodynamically impossible. It would require thrust vectoring lol. This isn't just an issue of pitch behavior. It demonstrates a very flawed relationship between pitch, angle of attack, load factor, induced drag, and inertia. So if this isn't a quirk of this user's install and the plane really does currently fly this way, the flight model is absolutely flawed. Hopefully they'll address it.

Well, some weather. MSFS does rain, stratus and particularly fog / reduced vis VERY well. Convective weather though, there's a lot of work to do.

That's a good thought.

Can't say I've heard of this one. There are no rudder lockout options in the iFly settings, I don't think. Question: are you using the normal sim controls menu to assign controls, or are you using a third party utility like FSUIPC?

It blows my mind that there is still not an extremely high fidelity 175/195 in the sim; like, iFly / PMDG / Fenix level. The e jet family is, by a large margin, the most common entry level airline jet for new pilots - and is quite a capable aircraft. It would be an insta-purchase for every simmer who plans to become - or even dreams of becoming - an airline pilot. I mean, it would probably be one of the best selling sim aircraft of all time. I can't believe devs aren't tripping over each other to cater to this market. Instead, there's just one dev who's been poking at this project for years and still has it at the bare minimum level of basic functionality, nowhere near "high fidelity"? Crazy.

There are a million video capture programs... Streamlabs or Streamlabs OBS work fine, but whatever seems easiest.

The iFly has controller lockout settings in the My Plane app under Autopilot. Be sure they're turned on, or a signal spike from your controller could conflict with the autopilot. However, this would probably disengage the autopilot. If that's not happening then something else is probably at work. If you can post a video I'll take a look and see if everything looks set up correctly. This is the first report I've heard of this so it would seem to be something local to your system.

I'll buy anything A2A makes. Even if another dev makes the same plane, there's pretty much zero doubt in my mind that A2A's will be better.

A slider to define visibility - exact visibility that never varies, to the tenth of a mile if not actually RVR values - is the single most glaring omission from this software if they want to call it a simulator. All the other shortcomings added together, don't even equal how ridiculous it is to be unable to set a visibility value. They do not even seem to understand why this is.

Don't let this intimidate you. It's not really going to be a course of study, just something you have to do a couple times and then you'll have it. There are plenty of graduate-level tricks and techniques that can be applied to these FMCs, but they also absolutely aren't necessary to use the aircraft on a normal flight. Most real life new-hires on one of these airplanes don't know all that either; they tend to learn it over their first months on the line. When they first get released from training, they only know the very basic workflow too. Pretty much every add on airliner comes with a tutorial that walks you through a flight, to include the setup and use of the FMC. It's not programming, it's just a workflow. Do it a couple times and you'll have it wired. Honestly, it's more user-friendly than the Garmin devices. I don't speak Airbus, but all you need to know for pre-departure setup on a Boeing is "follow the six-right road". Do it once and that'll make sense 😉.

Probably, but that's also something that would be implicitly understood by everyone with knowledge of these aircraft and this industry. There are countless options for almost every facet of an aircraft and modeling all of them would be a literal impossibility. Of course any particular aspect of any particular add on is going to be the one the devs chose to model. As long as it's a realistic and common behavior, I don't guess we can fault them for that.

Just to close the loop on this, I did test it in the real aircraft tonight and verified that point one is valid, as I expected. I'm also not quite sure what the refueling points example had to do with it though. I ran this by two former military and current airline guys; one a former tanker driver and one a former fighter pilot who spent plenty of time hanging off tankers, and they weren't sure either. They actually both asked me the same question: "why wouldn't you just create two PBD or PB/PB waypoints off the same fix(es), instead of creating a second user waypoint off of a first one?" Nonetheless, this was a good find as it should work, so it'll be addressed. Keep em coming! 👍

Nah, this isn't related to behavior in 2024; it'll be identical in 2020. The team is aware, although it only seems to affect this particularly weird case of creating a PB/PB fix using another user waypoint as one of the references. In general user waypoints are handled correctly. No one is quite sure why you'd want to do this 😉, but nevertheless it should work and so it'll be fixed. Note that his second point was erroneous; the iFly behavior is actually correct.