JRBarrett

I have done one flight so far from KMCO to KORD. The performance is fine, but this version definitely uses more VRAM than any other aircraft in MSFS 2024 on my system. I monitor VRAM using the Windows Gamebar performance widget. The 737 was using about 85% VRAM on the ground at MCO. It dropped to about 79% in flight and went up to a peak of 96% after landing at ORD. I did not run out of VRAM, but it came close. I have a RTX3080Ti GPU with 12 GB

The snow data provided by MeteoBlue does not have enough horizontal resolution in MSFS, so snow on the mountain peaks “spills over” into valleys. They do have higher resolution snow coverage data for New Zealand, which you can see if you go to the MB snow coverage map on their web site and zoom in. They either don’t provide the high resolution data to MSFS - (perhaps for reasons of cost?), OR MSFS cannot use the high resolution data because of the way the snow is overlaid on the underlying terrain tiles. The same problem exists in the European Alps.

Just because MSFS 2024 is a "new" sim, that does not mean that developers can (or should) re-write every bit of code "from the ground up". The data structures and classes that define the internal operations of something like the FMS take a long development time to test and optimize, and will almost certainly be re-used, because a new base sim platform does not automagically mean that there will somehow be a better way to implement those functions. For instance, the mathematical halversine formula, which is used to calculate the great circle distance between two sets of LAT/LON coordinates is over 225 years old, and is still used in every real world and flight sim FMS and GPS navigator today. The "ground up" rewrites will be for functionality that is new and specific to the MSFS 2024 SDK.

The approach should be valid. The current Navigraph Charts shows the RNP 24 approach at LSZG. The glide path angle is depicted as 3.34 degrees rather than 4.0 degrees. The chart is dated 06 March 26 and is effective 19 March 26. Could be a coding issue in the RXP nav data. I do not own the RXP product, so cannot verify.

If an aircraft is equipped with strobes, regulations require them to be operating at all times when airborne, no matter what the altitude. However, many airlines do switch off landing lights when climbing above 10,000 feet, and switch them back on when descending below 10,000.

In regular Live Weather, surface winds come from the latest METAR report (in knots) and winds aloft come from the MeteoBlue model. I believe the transition from METAR wind to MB model wind happens about 1500 feet AGL. Wind speed in a gridded weather model is always expressed in meters per second. The direction is expressed in rectangular coordinates U and V in which the U is the east/west component and V is the north/south component. Actual direction is calculated by doing a rectangular to polar coordinate transform. It appears that when winds are set manually, the entered direction is being used (as entered), but the conversion routines used for the MeteoBlue model wind speed are still active even though the model is not actually in play. That would explain why speed manually entered in knots is being interpreted as meters per second above a certain AGL altitude. It seems as if this would be an easy thing for the developers to fix. The MB model wind parser should be completely disabled when manually entering wind. The directional parser is indeed disabled, but the speed parser is still active when it should not be.

The initial beta just came out today. I am sure there will be many updates to come in the weeks ahead. Whatever changes/improvements to weather might be planned will probably come later in the Beta 5 process. They don’t necessarily include “everything” in an initial release.

I was 13, and the picture tube on our TV had died a couple of days before but the sound still worked, so I heard the landing but did not get to “see” it!

Domestic CPDLC is now being used increasingly in the US for communication with ATC centers. The difference is that the data is typically transmitted over a VHF data radio instead of via SATCOM.

Oceanic CPDLC, which is text based, uses ADS-C (not ADS-B), and is transmitted and received via a satellite link. If it does not work for any reason, the crew would fall back to giving verbal position reports on the HF backup frequencies given by Gander or Shanwick

It looks like the core of the storm this morning is over the Netherlands. Winds have decreased, but still rather strong south of the low pressure center.

It may be that the higher resolution snow data (like in the Alps) might not “fit” into the existing terrain grid without major modifications to the sim.

I would bet that it is something in the simulator rather than the aircraft. Possibly it assumes there is ice or snow on the taxiways when it is very cold (even if it not visible), and changes the ground friction model accordingly?

PMDG doesn’t have a separate “online model”. The way online aircraft appear to other users in Multiplayer or when on Vatsim is controlled entirely by MSFS itself. If the PMDG appears with gear down to other players, that is something that only Asobo could address.

There is no way that Asobo can (or ever will) “open up the API” for weather. The entire Live Weather system in MSFS is coded to work at a very deep level specifically and only with the gridded weather data contained in the NEMS30 weather model of MeteoBlue. If the API was “opened up”, for the existing Live Weather system, any third party would have to provide exactly the same data, and in the exactly the same format, as MeteoBlue already provides, which would be pointless. The only way that weather could be provided by 3rd parties, would be to scrap the current Live Weather system entirely and create an API that could use data from alternate weather models and using alternate parameters within those models. I don’t think that will ever happen. It is already possible to use METAR data alone to set the weather globally, which is what Active Sky and other add-ons already do. That is probably the best that can be hoped for as far as 3rd party weather injection goes.