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.

I have never seen anything like that in the PMDG NG, either in MSFS 2020 or the new 2024 version. I don’t use Chaseplane. I note in the video that your flight director is turned off, so there are no command bars displayed on your PFD.

In the past few months of using MSFS on an almost daily basis I have never had any issues with network connectivity. I just completed a 3 hour flight and the network was fine.

Owning a biz jet is an extremely expensive proposition - especially an older one like a Falcon 50. The operating expenses for fuel and ongoing scheduled and unscheduled maintenance can be very high. If it is being used for Part 135 charter, those expenses can be recouped through the fees that charter clients pay, but that doesn’t always work out if something expensive breaks and has to be repaired. We had to replace the cursor control device (basically a track ball) in one of our Falcon 900EX EASy aircraft this week. In 2021, Honeywell charged $33,000 for that unit. The current price is $140,000! That is the case for almost all avionics and engine components - price increases of 100 to 300 percent are typical over the past two or three years

Yet if you read some of the PMDG-related threads specifically on Reddit, you will see absolutely horrid abuse of the company and RSR by some (not all) posters. I can understand why Robert might have gotten his hackles up in this case if he read some of those posts. Not excusing it, but I can understand why it might have happened. Customers have as much a duty of respect towards how they address the company - especially on their own forums, as PMDG does towards how they deal with customers.

That information required to do those calculations is not contained in the FMS Nav data that Navigraph supplies. It may (or may not) be supplied in the AIRACs used by R/W FMS systems. The simulator EFB knows the total runway length, but one cannot assume that automatically equates to TODA (for instance). The EFBs used in r/w aircraft usually calculate takeoff and landing performance data from a separate app that is independent of the aircraft systems, and contains its own dedicated database. My company uses ARINC Direct for performance calculations which is a subscription service of Collins Aerospace. It would not be reasonable to expect any flight sim add-on aircraft to be able to do these kinds of calculations - the required data is just not available in a consumer flight simulator. The best that can be done is to do a basic balanced field length takeoff calculation based on total published runway length taking into account aircraft weight, engine thrust setting and OAT.

Make sure you don’t have any throttle quadrant levers bound to “mixture control”

If you purchased the 2020 version in the Marketplace you will also have to purchase the 2024 version in the Marketplace to get the discount.

Especially Seattle!

We don’t yet know what the upgrade price will be. It might indeed be equivalent to “a couple of cups of coffee” or it might not. The idea that it will be $50 is pure speculation at this point.

Additional info to my first post. I tested the G/S threshold crossing height at Asobo default KEWR 22R by spawning on the threshold in the Asobo default G-1000 Cessna 172. I tuned the ILS 22R (110.75) and displayed it on the PFD, then popped out the PFD in its own window so it was visible in slew mode, which only allows an external view. I also enabled the “full” HUD display in external view by selecting it in “Interface Options”. (The PFD altimeter does not work in slew mode, but the HUD altimeter does.) I entered Slew mode (SHIFT-Z) and slewed straight up until the glideslope diamond centered, and checked my indicated altitude. Initial altitude was 10 feet, and the G/S centered at 55 feet, indicating that the G/S crossed the threshold in a Cessna at 45 feet AGL, which was close to the published value of 50 feet. This is a test that could be used to check the glide slope accuracy at any MSFS airport. I did the same test at (default) EDDL 23R featured in Emi’s video linked a few posts above. The G/S crossed the threshold at 60 feet AGL, which is very close to the published TCH of 57 feet. I do not know if EMI was using the default Asobo EDDL or an add-on, but my conclusion is that there is absolutely nothing wrong with the G/S at either default KEWR 22R or EDDL 23R. I am assuming the disparity comes from which specific aircraft is being used. I am pretty sure that all the default MSFS aircraft use the standard simconnect variables to indicate localizer and glideslope deviation on the cockpit displays, as does the PMDG 777F, which I fly almost exclusively. Other add-on aircraft such as the Fenix may be using a custom implementation of their ILS LOC and G/S subsystem which could lead to the aircraft being too high crossing the threshold with a centered glide slope. I don’t know what specific Airbus model Emi was flying in his video. And of course, 3rd party airport sceneries may be using custom data for navaids which may (or may not) be accurate to the actual navaids.