martinboehme

Bear in mind though that size on disk doesn't have a lot to do with VRAM requirements. If a scenery uses LODs well, it can have a lot of detail up close and still be VRAM friendly. All other things being equal, it's true of course that more complex sceneries will require more VRAM. But I'd wait for a verdict from others before giving up on this.

Fascinating - I never knew that! Apparently, Little Navmap even has an option that lets you switch between whether to apply the current magnetic variation or the one the VOR is actually calibrated to: https://www.littlenavmap.org/manuals/littlenavmap/release/latest/en/MAGVAR.html @masconti This might be an option worth trying out. I assume on your system the option is set to use the current variation.

From @LtCdrDruid 's post though it appears that's what it is.

I don't think this is an accurate analogy. You wouldn't do the ingest / data conversion every time someone requested a certain date and time; you'd do it once, when a new model run becomes available, and then you'd store the data on your own servers in the format required by MSFS. How much data are we talking about? You say the US GFS model is tens of gigabytes in size. Which time window does that cover -- 24 hours? Let's assume it does, and let's assume NEMS30 is in the same ballpark -- let's say 30 gigabytes for a dataset covering 24 hours. The data for an entire year would then be just over 10 terabytes. That's not a lot of data to store and serve. Someone else mentioned that the global scenery that gets streamed is in the petabyte range -- 2.5 petabytes IIRC. Compared to that, the weather data for a whole year would be just a blip. Another point of comparison: On Google Drive, the free tier gives each user 15 gigabytes of data. 10 terabytes is therefore equivalent to the amount of storage consumed by about 700 users on the free tier. And Google Drive has about a billion active users. Technically, I think historical weather is eminently doable. The question is whether MS / Asobo will choose to make it a priority.

Interesting -- hadn't seen that yet! I found this part of the interview very revealing. It seems to me that Jörg has heard of the request for historical weather but truly believed it meant weather from 1947 (for example) and, from his statement quoted above, wasn't aware that meteoblue even has data going back 80 years. As you say, it's disappointing that this information still hasn't gotten through despite the efforts of the community, but maybe he's now finally understood that what people are asking for is really just weather going back 24 hours... which should be significantly more feasible than, say, recreating the weather conditions of Lindbergh's transatlantic flight (which is maybe what he understood). Not holding my breath... but we'll see.

Maybe what they meant is that it's common to be given a lineup clearance at Heathrow and other busy places because it's more efficient. You can only give a takeoff clearance once the departing aircraft has lifted off, but you can give a lineup clearance while the preceding aircraft is still on its takeoff roll. This keeps traffic flowing better, which is vital at a place like Heathrow that's trying to squeeze as many movements as possible out of two runways.

The fork is real: https://github.com/tcantenot/Atmosphere-Rendering-Parameter-Calculator And the person who forked the repo is apparently a Senior Engine Programmer at Asobo: https://theorg.com/org/asobo-studio/org-chart/thierry-cantenot Of course, this doesn't mean that the modified coefficients will in fact end up in MSFS. But at least we now know that this has come to the attention of a developer at Asobo, and they're interested enough to be looking at @Biology's code.

Very likely the latter. Only Asobo would know for sure, of course, but since the purple sunsets happen in all live weather conditions, it seems unlikely that they have some way of streaming the required coefficients to the sim.

Thanks for the explanation! Ah, excellent to hear that it's already been corrected there. I find it interesting that, apparently, both papers got this wrong? I think the pitfalls of only sampling the spectrum at the "centers" of the RGB primaries are pretty well known in computer graphics? Fingers crossed that you get traction with Asobo on getting this corrected. This would be an easy fix with such a big effect -- but the right person needs to hear about it.

Just guessing, but I assume @Biology found the shader file that computes the atmospheric effects and replaced the coefficients in it. No, that won't work. That Python program only computes the correct coefficients -- just a set of numbers. It doesn't do anything to make MSFS actually use these coefficients. @Biology This is an awesome discovery! The nice thing is that you don't need to increase spectral resolution (which would be a lot harder) -- you can just change the coefficients because IIUC, the computation of the atmospheric effects and conversion to sRGB are essentially commutative. IOW, instead of computing the atmospheric effect in high spectral resolution, then converting to sRGB, you can apply the sRGB response curves to the scattering and absorption coefficients, then compute the atmospheric effect in sRGB, and get similar or identical results -- correct? @jcomm has already suggested contacting MSFS's developer support. Another option might be to contact the Working Title folks, who are usually quite approachable, and ask them for an appropriate contact at Asobo. @MattNischan is quite active here -- maybe just PM him? It sounds as if X-Plane is also using the wrong coefficients from the paper? IOW, I assume your corrected X-Plane screenshot was also made by hacking your coefficients into X-Plane's shader? Or has X-Plane already corrected the coefficients? If not, are you planning to approach Laminar Research about this as well? I expect they would be pretty open to this, particularly as it's such a simple change to implement. I'm guessing Ben Supnik would be a good point of contact -- I believe he's responsible for a lot of the PBR work in X-Plane.

Here's an article from the NASA website on lightning in hurricanes: https://www.nasa.gov/mission_pages/hurricanes/archives/2006/hurricane_lightning.html "Generally there's not a lot of lightning in the hurricane eye-wall region. So when people detect a lot of lightning in a hurricane, they perk up -- they say, okay, something's happening."

Apparently, "expedite" is French for "I used to fly in the military". 😉

I think you'll need to provide more info so we can figure out what is going wrong for you. Which approaches at which airports are you trying to do? Which aircraft? How are you setting up the FMS? What are you doing to intercept the ILS? What exactly isn't going as you expect? A screenshot of the point when things go wrong would help too.

Unfortunately, I believe it's unlikely it will come to Xbox as the aerodynamics and engine simulation run outside the sim, which isn't possible on Xbox. I think I remember A2A talking about this somewhere.

These three are all short with great scenery: Las Vegas KLAS to Aspen KASE Sao Paulo SBGR to Rio de Janeiro SBRJ Christchurch NZCH to Queenstown NZQN

You may hear one or the other, often depending on the facility and the local procedures, and they mean different things. "Contact tower" means switch to the tower frequency and call them. "Monitor tower" means switch to the tower frequency and wait for them to call you (presumably because ground has already told them you're up on their frequency).

I do brief the missed approach as part of the approach - but I don't practice them as much as I should. And every time I do, I realize how rusty I've become.

Looking at the vectored approach, I do have to say that the vectors ATC gives are pretty strange. Approaching 16R at KSEA, ATC gives vectors onto a downwind with a heading of 340. So far, so good. However, ATC then turns the aircraft to a heading of 320, pointing it roughly towards AGANE, which is about 16 miles out on the final to 16R. ATC then clears the aircraft direct to AGANE and clears it for the approach. This requires the pilot to do a course reversal at AGANE, but none is published for this approach. Instead, I would have expected to see a vector for a base leg, then a localizer intercept. Bonus points for correct US PTAC phraseology. So it does look as if there's still some work to be done before release. Nevertheless, very excited for this.

In normal operations, that's expected. You'd only need to crossfeed in unusual circumstances, for example if you had to shut down an engine enroute or if you had used hotel mode for a long time. Another way that a fuel imbalance could develop, though, is by inadvertently filling only one of the tanks.

You gotta pump those numbers up. Those are rookie numbers in this racket.

Maybe you mean the ice accretion probe?

The Flight 1 ATR is one of my all-time favourites too! I remember planning a round-the-world trip at the time, starting somewhere in Europe - maybe Toulouse? - and going east. I got as far as Alice Springs before my attention got diverted to other things. But I'm now thinking I might pick up again where I left off so many years ago. As I recall my plan was to cross to South America via a string of islands in the South Pacific. It was going to be a close call in terms of range but just doable I believe, though most certainly not with legal reserves. I would then cross South America to Recife, then cross the South Atlantic with a refueling stop on Ascension Island Again, a stretch in terms of range but maybe just doable. From there, I would make my way through Africa back to Europe. I'm tempted to take another look at the flight planning for this and see if it can really work out.

Correct, he's the developer of the CRJ and ATR. Should have said that explicitly in the original post (and I'll see if I can still edit the title to make this clearer).

The latest episode of the German-language podcast "Die Simulanten" featured an interview with Hans Hartmann in which, among other things, he talks about his plans for the ATR and CRJ. I thought the information from the podcast might be interesting to those who don't speak German or simply don't want to listen to the whole interview. (There's a whole lot more there for those who want to listen to the whole thing.) ATR The changelog for the update coming on Tuesday contains around 45 fixes. VNAV wasn't complete in the initial release. Improvements are coming, and it sounded as if they might already be in the Tuesday update, but this wasn't entirely clear. There are further updates to come. He is planning to add a Load Manager, expanded GSX support and Simbrief flight plan import. Whether the initially planned cargo version will happen is unclear. CRJ An update is planned for the summer (it wasn't clear whether this means he will start work in the summer or whether this is the planned release timeframe). The update will contain fixes for various issues with the aircraft. Additional features are also planned, including Navigraph charts, Simbrief flight plan import, and a passenger cabin. All of this is as I understood it.

To be fair, it does seat more passengers and has a significantly higher MTOW. But don't get me wrong - I like the ATR and flew the heck out of it back in the FS9 days. It's got a slightly different mission than the Q400, and that's a good thing.