martinboehme

I've done time compression with the DA62 NGX and can definitely say that it behaved as it should, i.e. fuel was also consumed at an accelerated rate.

This is true in DX11 but not DX12 - it's one of the big differences between the two. In DX12, when you run out of VRAM, you simply can't allocate any more textures. If you want some kind of virtual memory mechanism, you have to implement it yourself. The idea is that you can get "closer to the metal", but it does place an extra burden on the programmer to manage memory that isn't necessary in DX11.

Maybe because you want to challenge yourself to use all of the aircraft's range, including a MTOW takeoff, and see if you got the planning right. Or you want to simulate a given real-world operation, maybe because you've flown that flight yourself. Or maybe you want to do a flight to a location that simply can't be reached without a longish leg (Perth, Azores etc.). All of these are reasons why I like to do longer legs, and I like to use time acceleration because I only have a limited amount of time to dedicate to simming (and leaving the sim running while I do other things doesn't fit into my schedule either).

Not sure if 300% fps gains are realistic -- I would suspect it very much depends on what you're currently limited by (CPU or GPU), as foveation benefits are more easily obtained for the GPU part of the rendering pipeline. And of course, Asobo would have to implement foveated rendering support in the first place (it's something that needs to be implemented in the game engine itself). To get an idea of the potential gains, you could turn your render scaling down to, say, 10%. That should give you an approximation of the potential that would be there with foveated rendering, if implemented well. I suspect the increase will be well short of 300% though, as the bottleneck will shift to some part of the pipeline where the effort doesn't depend on the resolution. (Disclaimer: I've done some work with foveated video rendering, but I don't have any first-hand experience with foveated 3D rendering.)

Or if it's a 70: "We'll follow the little Fokker." 😉 I have good memories of the Digital Aviation version too - will be following this one!

Among other things, I understand it doesn't do RF legs and DME arcs correctly and instead approximates them using a series of "synthesized" fixes that aren't in the actual procedure.

Took the Hunter for a spin around the Mach Loop yesterday -- very enjoyable!

I assume you're right -- I was just mentally putting it in the same category. Ooooh, how could I forget that one. Another classic. This thread has given me a serious case of classic British airliner nostalgia. I've held off on getting the BAe 146 so far, but I think I can't resist any more now...

Seconded - I have fond memories of David Maltby's planes too! I think the VC10, Trident and HS.748 were all by him? Absolute classics.

Awesome - thanks for the heads up! I loved flying this back in the day - FS9 I think it was?!

I believe @tup61 is not asking how to get the current QNH but how to pre-set it so that it will be available once switching out of STD. It also sounds as if this question is specific to Airbus.

Maybe they had this in the original release, then took it out at some point? As @Bobsk8 notes, you don't really need the EFB to tell you the flap and slat retraction speeds as the FMS is going to calculate them anyway. Maybe they removed the feature because of this?

Also, if you have it, could you post a screenshot in the snow?

I believe AviTab (for XP) let's you georeference PDF charts manually. I'm not sure if there is equivalent software for MSFS though.

To explain the abbreviation: MAC stands for Mean Aerodynamic Chord. It's customary to give the CG as a percentage of MAC, which is presumably why they omitted the "CG" - it's implied from context.

That depends on what I want to do. If I only fly offline, then outdated charts are fine. That said, I don't think a "pay once" model makes business sense for Navigraph. There would be a real risk of cannibalizing their existing subscription offerings.

Keep in mind also that They have monthly costs to keep the servers running. Under a "pay to own" option, they would have to store the charts and navdata for every cycle indefinitely, instead of just the data for the current cycle. This increases their server costs for the very customers from whom they would only be receiving a single payment that needs to cover the server costs indefinitely.

Something to keep in mind is that, depending how high you fly, you're not always going to experience thermals (and hence turbulence) even if it's a sunny summer day. In high pressure fair weather conditions, it's common for an inversion to develop, and inversions are "thermal killers". Because the surrounding air gets warmer with altitude, the thermal will eventually not be any warmer than the surrounding air, and so it will stop rising. If you're flying above the altitude where this happens, you won't experience any thermals.

Just to clarify, do you mean you landed with 5 tons total, or with 5 tons more than you should have had according to the plan? Also How much fuel should you have had remaining according to the plan? What cost index did you plan for? Did the flight plan contain any step climbs (i.e. maybe keeping you low initially for ATC reasons)? Can you post the (relevant parts of) your flight plan here?

I can see how it wouldn't be producing much reverse thrust, but my understanding was always that idle reverse should at least eliminate all forward thrust. The OP is saying that they're still accelerating in idle reverse, which does seem odd to me. Can that really be right? To the OP: Can you verify that you are in fact in idle reverse when you observe this, i. e. do you see a green "REV" on your N1 gauges?

Awesome, thanks everyone!

Thanks for the info! Out of the two, I only have the Maddog at the moment anyway, so good to hear it works there. Do you have to save the panel state separately, or does it get saved automatically when you save the flight?

Wait, are you saying this actually works reliably in the PMDG and Maddog? Since essentially forever I've resigned myself to not being able to save flights in complex airliner addons and having to do every flight in one sitting. Certainly never worked for me with any of the airliners I've flown in FS9, FSX or XP (never made the leap to P3D). If there's at least some addons that are able to do this now, that's a real game changer to me. It'd be great if the Fenix could do this too, of course, particularly since it doesn't support time acceleration (at least for now).

As others have said, it's all about what you're used to. Proof: I can't even make my mind up about what I prefer personally. I'm a glider pilot and got used to metres for altitude and kph for airspeed in that context, so that's what feels "organic" to me... but only for gliders! When I'm flying airliners in the sim, I'd be hopeless if I had to plan my descent in metre altitudes and kilometre distances. Give me feet and nautical miles or I can't function.

From your description, I'm not sure: Are you trying to do a straight-in landing from that approach? That's not going to work, and the approach is not designed to be flown that way. Note that: The approach is labeled as a "cloud-break procedure" The minima say "landing rwy 15/33", not "straight-in landing" to a single runway as you would see on a straight-in approach At PR816, you're still at 13,800 feet, almost 6,500 feet above field elevation, but only nine track miles to the threshold. That would equate to a descent angle of about 7 degrees if you wanted to make a straight-in approach. Anyhow, the missed approach point at PR808 is right above the airport, and your MDA for category C is 10,320 feet, still almost 3,000 feet above the airport. (This equals an altitude loss of about 3500 feet from PR816, which corresponds to the 3.5 degree angle noted on the chart.) I believe the way this is flown in real life is that after PR808, they visually fly a series of descending turns in the valleys to lose altitude and bring them back to the airport. I don't think there's any official information on this available on the web -- in the real world, I'd assume it's taught as part of a course you need to get the "authorization required" noted on the chart. Here's some relevant sim-focused discussion however: https://community.infiniteflight.com/t/a-guide-to-the-paro-approach/500927 https://simfest.co.uk/paro-special-briefing As to your question on why you weren't able to descend below 13,800 feet, I'm honestly not sure. If you were in FINAL APPR mode (i.e. you pressed the "APPR" button), I _think_ that should take you down the glide path depicted on the chart. Maybe this is an issue with how the approach is coded in the navdata? Flying it in FPA mode is of course an alternative, but in any case, you'll have to do the visual approach after PR808.