Stearmandriver

I've never bought a single 3rd party airline airport. There's no need. When it comes to atmospheric GA or bush strips, yes, 3rd party scenery can significantly help. When it comes to large airline airports though, pretty much all of them in the sim are plenty usable as-is. I'd say start with some airline flights to default airports and see if you even like this kind of simming before you start spending money on scenery you may end up not using regularly.

To be fair, "realistic" turbulence in 2020 and 2024 definitely isn't. I run turb on low and even then I see occasionally unrealistic air movements, though 2024 seems a bit better about this. But "realistic" is way overdone in both sims. But also, PMDG is known for accepting flaws in their flight model and auto flight behavior as LRBS says. They have a tendency to then try and gaslight their users into believing that it's a "realistic quirk" - until maybe they finally fix it a few years later and then tout themselves as the best dev in existence for being able to solve this suddenly egregious problem that they've told you was fine for a long time 😉. TL;DR - it's probably a little of both. You can't fix the PMDG issues, but you can certainly try turning your turbulence down.

Haha in airplanes this old, just about ANYTHING is a realistic option. There are as many restoration styles as there are airframes still flying. I've flown J-3s with no electrical system at all, I've flown them with nothing but an electric starter, and I've flown them with all manner of radios crammed in all manner of places. The one thing I'd say about the CAS Cub is: if I were restoring a J-3 and putting an electrical system in it to run radios, I'd surely give it an electric starter too 😁. But I suppose from a simming standpoint, the hand propping is novel. And I'll bet, somewhere out there, is a Cub in this exact configuration. There's always one.

Well, kind of. Yes if ATC needs you down early for traffic, you're coming down early. But usually this isn't the case and your initial descent clearance will be at pilot's discretion. They do this specifically because they know we want to remain on our FMC calculated vertical path, based on the cleared arrival. It would be fair to say that a pilot's descent calculations for optimized performance are secondary to traffic deconfliction needs, but I wouldn't say they mean nothing to ATC. I'm not sure what BATC is doing these days but if it's regularly forcing you to start down early vs using a discretionary descent, that would be pretty unrealistic.

Yep I've got it now. I explained above: the Navigraph app on my phone would not allow me to scroll the menu down far enough to see the final chart in portrait orientation. I could only see it when I turned to landscape. Would not have expected charts could hide haha.

Ah hah, there it is, sure enough. I was looking at the navigraph app on my phone, and weirdly I could not scroll down far enough to see that last chart in the list until I turned my phone from portrait to landscape. So I could see the charts for the BIG transitions but not OCK. Weird but good to know now that can happen.

The CAS Cub is hands-down the BEST stick and rudder airplane in MSFS. The BEST. And as the real J-3 is the best stick and rudder airplane that has ever been built, this works out well. Additionally, it's probably the airplane I've tried in the sim that feels the most like its real-world counterpart. I love Cubs, and this thing does them justice.

Maybe I'm missing something; I never did see it specified which STAR we were talking about. But from what I looked at, I only see one STAR that drops you at OCK (the fix referenced by the OP). Where are you seeing a charted transition from OCK to 09L? From BIG, yes, but how is that helpful if your STAR ends OCK? Looks to me like vectors are absolutely required. Not getting them would 100% match my experiences with BATC. It simply doesn't really understand vectors, when they're required, which parameters must be honored etc.

Yes, I'll try it again at some point. But it hasn't been THAT long since I last tried it, and in my experiments it still has not vectored me correctly, not even once. This spans airline flying into hub airports and GA IFR flying into a variety of fields. It's never once done things "correctly", there's always a time when I have to just shut it off. It's descended me into mountains. Given me 90 degree intercepts. Dropped me on downwind while on vectors and then shipped me to tower. Never even once has it given me vectors that are even close to a real world standard of "acceptable". Based on the latest reports, it's still not fixed so every time I think about trying it, I opt for Vatsim instead even if not fully staffed. One day, though. At this point it's kind of a game to see what it'll do next.

It's a game so sure, you can do whatever you want. But if you're suggesting this is what would happen in reality, that's definitely not true. Can you get hung high because ATC forgets to clear you lower and you can't get a word in? Sure. Can you get hung high because of conflicting traffic? Sure. But you'll never just "decide" to descend on your own. ATC doesn't care what your flight plan says, they've got traffic to deconflict and can't just have you doing as you like. In reality, you'll deal with the high as necessary - add drag, get relief on speed restrictions, get vectored for the descent, even enter a hold if necessary. You can't just do what you want unless it's a safety of flight issue, and even then you have to advise ATC asap. I have also seen BATC just completely break, in which case I just self-vector to final, but if that's really what the program "expects" you to do, then it's simply broken, is all. I haven't used it in a while for this reason; if it can't vector correctly, I don't even see the point. That's basically its only job.

Haha, they're trying hard to keep up with the iFly. Not quite managing though, especially compared to what's coming out soon from iFly.

The reason to use LNAV to join would be if you're given a steeper than 30 degree intercept, or if (in real life) you're far enough out and low enough to be receiving a shaky localizer. In these scenarios LNAV will do a smoother intercept with no overshoot. As long as you're in approach mode by the FAF, it's a perfectly acceptable technique. I doubt anyone uses it as an actual SOP, but it is a valid technique that has benefits in certain situations.

Just wanted to point out in case you weren't aware: there's currently a very, very good J-3 available, the CAS Cub. I haven't used the A2A version since FSX days but from what I remember, the CAS Cub is right up there with the A2A version.

No offense, but I'm guessing I've had a little more interaction with him than you have, and this is a false characterization. It's Discord; it's a sloppy disaster if someone doesn't keep it on track, and so yes, I'm sure he doesn't hesitate to use admin authority when that seems the best way to solve a problem. It's not ego, and it's definitely not iFly or Flight1 trying to "silence naysayers". I can personally speak to how glad they are for constructive, knowledgeable criticism. The adjectives are important in that last sentence. If criticism falls outside those boundaries (in other words, if it's typical of what is seen on platforms like Discord or Reddit etc) then yes, of course it'll be moderated. The idea is to use the platform for adult conversation, not whining or foot stomping. Back when I was active on the public facing discord of theirs, I can't tell you how many complaints I had to explain away as simply incorrect. Users often reacted poorly to being told by someone with experience that they were mistaken about the operation of an airplane they'd never even sat in. That doesn't make a lot of sense to me and that's why I don't bother with that server anymore, but such is the modern Internet. I'm frankly glad someone is trying to preserve some order.

This isn't like that at all. Many people raised issues when this product was released; I know, I was one of them. What was impressive was how seriously they took the feedback. We had multiple updates within a few weeks of launch, correcting all the big ticket items. Work has continued since then on what is a VERY polished SP1, in testing now. The team (and many of us testers) have given multiple updates on the status of SP1 along the way and especially over the last month or so as we get close. I don't like devs who push unfinished abandonware either. Let's be very clear that iFly is not one of those devs.

I'm a Boeing guy so can't speak to an Airbus specific procedure, but as general checklist methodology - if something isn't as commanded, you verbalize it. Maybe there's a proceduralized call for that; for instance, after landing we have a procedure for the pilot monitoring to call "speed brake" to verify the speed brake is deployed. If it's not, the PM calls "no speed brake". (This is really only applicable when the FO is PM because the captain will just pull it manually anyway). But that's a proceduralized call - "speedbrake" or "no speedbrake". But not every condition will have a proceduralized callout for a non-normal condition. At that point, you just have to lean on those good old fashioned plain language communication skills, and concisely and clearly tell the PF what is happening. We really, REALLY stress an assertive and communicative PM in the industry these days, huge emphasis item.

I don't hang out on the consumer-facing Flight1 discord because I'm on the other one, so I did not see this exchange. Knowing the moderator you mention, though... I would be willing to bet you earned the ban. He's a reasonable guy; I can't think of anyone on that team who would just randomly ban people for the fun of it. Quite a bit has been shown of the work that has been done on SP1 at this point, so your claim of "abandoned" software is simply irrational. Is this an April Fool's post or something?

This is really a personal preference thing. The only time seat height genuinely matters is in an aircraft with a HUD, where proper alignment with the combiner will dictate height. But otherwise, it's just preference. Everyone can learn to correctly process whatever visual cues are available from whatever sight picture you've got, and make smooth landings. What's more important is consistency - pick one seat position and stick with it. Constantly changing your sight picture will make life harder. Example: I've flown Stearman biplanes for years. There is literally zero forward visibility in the landing flare no matter where you put you seat, and on a runway narrower than 60ft, you cannot see any part of the runway at all as you're landing. But it's fine, everyone still learns to make smooth landings with peripheral vision. You can learn to make do with any sight picture.

Returning to this one late, but glad to see we're pretty well in agreement. I'll correct one thing: We request new takeoff data using different parameters all the time, as judgement dictates. Didn't want to leave the impression that some airlines aren't doing that. Certainly we also have a rigid procedure for verifying that the takeoff data solution is valid. I assume every airline does. It was only specifically the review of margin that I'm pointing out many airlines don't do. I wouldn't call it "controversial", just one of those differences, as you say. I've never heard the reason why margin is excluded but I could make some educated guesses from my time in human factors working groups, but I guess it doesn't really matter. Pretty much. This is something we do. A takeoff data solution guarantees that you can stop if the RTO is initiated at V1, but not necessarily 1 knot above it. Things are happening pretty quickly around V1, so if you use the actual V1 as the decision speed and you recognize a failure right at V1, you won't be initiating the abort until some speed above V1. Calling V1 5kts early allows for recognition and reaction time and ensures an RTO isn't initiated above V1. There are a lot of overrun accidents that were caused by a late abort.

Guys. Please no Internet drama, on my behalf or otherwise. LRBS and I have both been airline captains and check airmen for many years. We're peers. This isn't one of us lecturing or teaching the other. It's just a discussion, the same as I would have with another instructor over a beer. It's fun to get into the weeds on this kind of stuff, that's all. I see this particular issue as more of a human factors / risk mitigation exploration, vs a technical issue. That's probably not fun for everyone, but I like it. 😉. Other instructors usually do too, which is why it being perceived as some kind of attack confused me. I think there was some misunderstanding, hopefully all better now. Ok, so this is interesting. Where does the runway margin data come from, if it's not included by your performance calculator in a perf solution? For fun, I reached out to a couple buddies who fly for two other US legacy airlines, and asked them for examples of their takeoff data reports. They both use the Aerodata cloud calculation system, so of course they are pretty similar. I won't post either of those here, but here's an identical Aerodata takeoff performance report I found online (it's obviously for a corporate jet, but all the same data is provided - and omitted). https://www.garmin.com/en-US/blog/wp-content/uploads/2020/12/2-GP-P-FPc-NavLog-TLR-calc-top-copy-1136x1536.jpg We use a different tool called DynamicSource that does the same thing - server-side calculations of perf solutions based on parameters we specify (or optimum by default). Our reports contain exactly the same data, the only extra field being a customized obstacle clearance height that is used in our takeoff profile (it's just an altitude you maintain clean maneuver speed until passing if engine-out). So that's at least three US legacy airlines that aren't directly reviewing runway margin data as part of a takeoff performance solution, because it's built in. (Most regionals are now using one or the other of these systems as well). I'm not criticizing anyone for using a different system or different techniques, it's just always fun to see how folks are doing things at different properties. It seems there may have been some perception that directly reviewing runway margin data is an industry-standard part of takeoff data review, and as you can see, it really isn't. That doesn't mean there aren't places doing it, but it does call into question what purpose is really being served by doing so. That's the discussion I was looking for; I'd like to understand that position.

I'm unsure which airlines you're familiar with, but most major airlines in the US do indeed use the cloud-computed DynamicSource / Aerodata system. The on-EFB calculator is a less accurate (but cheaper) calculation tool, because of the relative difference in computing power between an iPad and remote servers. I guess where my confusion lies is in what kind of verification you believe you are performing. If I'm understanding you correctly (and of course, correct me if I'm not), you're comparing values to each other - but you're getting all those values from your performance calculator. If that's the case, you can see my point - you're simply trusting that the data returned by your performance calculator is correct, the same as my airline and others. You can't really perform a verification unless you're comparing data from different sources. Since everything you're comparing is being returned by your performance calculator.. is the comparison process really verifying anything? That's why we keep the data solution simplified. Obviously if there were a safety based reason to provide this data, we'd have it and more, and the FAA wouldn't have certified the largest airlines in the country to operate this way.

I'm genuinely unclear why you're understanding this to be some kind of argument. I asked out of curiosity, wondering why you saw value in knowing some of the parameters you listed, as I assume we agree that we do not want pilots modifying a takeoff profile based on a "feeling". Generating a new takeoff solution with any conditions the pilot would like to specify, of course we want people using their judgement and doing that. But once you have the solution in hand... You're going to fly the same profile every time, so I'm still curious why you think knowing those values matters? Just to clarify, I have nothing to do with development of anything at iFly; my question didn't have anything to do with iFly and isn't a commentary on anything they may or may not do.

I imagine you're aware no pilot is born at their career airline; we all go through various experience building stages before ending up where we want to be. I have worked for several airlines and flown quite a few different fleets. I can assure you there's nothing unusual about the way we handle performance calculations, it's industry standard. It seems there might be some misunderstanding about what is meant by "calculation". No pilot at any airline is really doing their own performance calculation, because they do not have access to the flight test data necessary. That data is extremely expensive and is not shared with line pilots 😉. What pilots do have is a variety of electronic calculation tools or performance charts that will return a solution with at least a known amount of buffer built in. Airlines vary in the way these solutions are obtained; some have a calculator on the EFB, some have access to a much more powerful calculator in the cloud that is accessed via an ACARS dialog, and some use tables. We certainly have the tables, but we use a combination of the DynamicSource cloud calculations, and those same solutions provided by dispatch on a dispatch packet. We can certainly change any conditions of the data we would like, and get new data with any derated or AT reduced thrust or not, up to full rated thrust; a flap setting or bleed configuration of our choosing, etc. But this isn't "calculating" takeoff data, it's simply requesting a solution with any given parameters we'd like to specify. The delivery device for these calculations may vary, but there aren't any pilots out there doing this differently. My point is that when you have a solution you're happy with, knowing all the values that entered into it isn't necessary or even helpful in any way I can see, because you certainly aren't going to alter your takeoff profile for it. We definitely do not want crews trying to apply judgement about when to abort vs when to continue, that's why this is made perfectly black and white in the trained profile. Many accidents have resulted from pilots choosing to go "off script" and make a different decision than their profile called for.

Confrontation? Certainly not, I'm honestly curious. If you're teaching a standard profile, then knowing these values doesn't change anything the pilots will do. In the low speed regime you'll reject for most anything. In the high speed regime you'll reject for given items. After V1 you'll continue. If you've got a standard profile, those items never change. You know you can stop when that's relevant, and you know you can go when that's relevant. The distances and margins enter into the performance calculations being done, but the pilots typically aren't the ones performing the calculations. If I request data for 22R at W in EWR and I get valid data returned, I know all of those parameters have been calculated and they all work with the standard profile. Knowing them wouldn't change anything I'm going to do, right?

Tried this tonight; intentionally held myself high until about 1,000ft above path. Vertical mode correctly reverted to VNAV ALT until I reset MCP altitude and hit alt intervention. Vertical mode then transitioned to VNAV SPD and entered an idle descent at FMC commanded speed. I helped it out with speed brake and it correctly reverted to Vnav PTH when rejoining path. So, all looked good to me. 👍