JRBarrett

You’re welcome! The amount a VOR’s variation changes over time depends on where you are located. Here in the US northeast, the direction of the magnetic north pole’s movement is almost directly away from us in a straight line. The local variation has changed less than 1 degree in the past 20 years. In the western US, the rate of change is much faster because the direction of the pole’s movement is basically at right angles to that part of the country. The FAA rarely changes a VOR’s north radial calibration once set, because it would result in many complications. The radial numbers would change, resulting in all publications and charts referencing the airways having to be modified. The path of a particular airway over the ground never changes, no matter how much the actual variation changes. It’s kind of a moot point these days, since so many VORs are being either completely decommissioned, or converted to DME-only facilites.

The number associated with a VOR radial on a published FAA chart is not (necessarily) the actual magnetic heading of the radial, nor the heading you have to fly to track it. This is a common misconception. 88 degrees is the course you set into your OBS in order track the airway (V12) with a centered CDI. When a VOR is first put into service, the zero-degree radial is aligned with magnetic north as it existed at the time the VOR was put into service. When ANX VOR was calibrated in the year 1965, the magnetic variation at that location was 7 degrees east. But, the earth’s magnetic North Pole is not fixed - it is continuously moving to the northwest, year by year. The magnetic variation at the location of the ANX VOR today, in the year 2023, is 2 degrees east. The actual magnetic heading of the VOR’s zero-degree radial is now offset 5 degrees from where magnetic north was in 1965. A VOR does not “know” or “care” where magnetic north actually is. The zero-degree radial of the VOR is an electronic reference set into the VOR transmitter by the technicians who calibrated it. The published radial for V12 is 88 degrees. That number represents the number of electrical degrees that the radial is offset (clockwise) from the VOR’s zero degree radial, and that zero-degree radial is based on 1965 variation. It has nothing to do with the heading you have to fly (today) to track the radial. Typically, once the variation of a VOR’s north (zero degree) radial is initially set, it is never changed again, no matter how many years pass, or how much the actual variation changes. Most of the VORs in the western US are based on 1965 variation, and many are now offset as much as 7 or 8 degrees from magnetic north in the year 2023. When ANX VOR was brand new in 1965, tracking V12 with a centered CDI needle wouid have indeed been done with an actual aircraft heading of 88 degrees (assuming no crosswind). In 2023, the aircraft heading required to track the radial would be 88 + 5, or approximately 93 degrees. Navigraph and LNM show the actual magnetic heading of V12. As long as your VOR course selector is set to 88, and you fly outbound from the VOR, (doing whatever you have to do aircraft heading-wise to keep the CDI needle centered), your track will follow the path of V12 over the ground perfectly. That would have been true in 1965, and is still true today.

The METARS used in live weather don’t come directly from the country in which you reside (or connect to via VPN) - they come from MeteoBlue in Switzerland, which provides the live weather data for MSFS. I assume that MB, like any other weather data provider, gets METARS from the World Meteorological Organization (WMO) data feed. The WMO continuously gathers and compiles hourly METARS from around the world and provides them to all interested parties. Since only the three NZ airports are available from the WMO, that would be all that MB (and thus MSFS Live Weather) has access to.

I can’t say how big the MB model file is, but I have worked with data sets from the US GFS worldwide model, and that is tens of gigabytes in size. I don’t think MSFS uses the MB model directly in its native GRIB format. It probably has to be modified to work within MSFS, which would either be done by Meteoblue before each new model run is sent to MS, or by Azure upon receipt as part of the server ingest process. To expect this to be done for each individual MSFS user who might want historical weather is just not realistic. It would kind of be like asking a restaurant which is closed for the day to bring in a full staff of cooks and servers to provide a meal for just one customer.

Weather from the previous 24 hours is probably do-able. Historical weather from weeks or years in the past would be absolutely impossible - even if MeteoBlue has data going back decades - at least with the way that MSFS Live Weather currently is designed. The entire MSFS weather system is based on the full NEMS 30 global weather model from MeteoBlue. Complete global weather models are huge in terms of the number of files and the file sizes. Many many gigabytes in size. The only way to make this work is to host the latest model files on MS servers and then stream it to end users. Each user gets the weather for their particular location on earth and current UTC time - not the entire worldwide model. With this system, if an individual wanted to fly in historical weather from (say) December 14, 2015, Azure would have to reserve multiple gigabytes of server space, download the model files from MeteoBlue for that date, and then stream the location-specific subset of weather data for the individual’s location in the sim. All this for just one end user. Multiply that by hundreds of users, all requesting different historical dates, and you can see that there is no practical way to implement such a system. However weather going back 24 hours would probably work, because each run of the MB global model contains forecast data for 24 discrete hours worldwide.

Weather from the previous 24 hours is probably do-able. Historical weather from weeks or years in the past would be absolutely impossible - even if MeteoBlue has data going back decades - at least with the way that MSFS Live Weather currently is designed. The entire MSFS weather system is based on the full NEMS 30 global weather model from MeteoBlue. Complete global weather models are huge in terms of the number of files and the file sizes. Many many gigabytes in size. The only way to make this work is to host the latest model files on MS servers and then stream it to end users. Each user gets the weather for their particular location on earth and current UTC time - not the entire worldwide model. With this system, if an individual wanted to fly in historical weather from (say) December 14, 2015, Azure would have to reserve multiple gigabytes of server space, download the model files from MeteoBlue for that date, and then stream the location-specific subset of weather data for the individual’s location in the sim. All this for just one end user. Multiply that by hundreds of users, all requesting different historical dates, and you can see that there is no practical way to implement such a system. However weather going back 24 hours would probably work, because each run of the MB global model contains forecast data for 24 discrete hours worldwide.

I have no problem with the original post or others like it. When it was first posted, an unexpected (minor) update to the Beta had dropped, and there had not yet been any information about it on the official MSFS forum. The OP was curious what the update was. If these kinds of topics are of no interest then simply ignore them.

There is not “a” server. When running, MSFS connects to multiple discrete IP addresses. I do not use multiplayer, ATC or r/t traffic, and I have still seen as many 9 to 12 discrete TCP/IP connections. I am in the US Northeast, and running checks of the IP addresses in use shows that some are physically located on the west coast, some on the east coast, and some in the Midwest. I am quite certain that the server that provides streaming scenery (for example) is in a completely different data data center than the server that provides live weather. End users have absolutely no control over which servers they connect to with the exception of multiplayer. One of the things that MSFS probably does during initial loading is to download a list of which IP addresses are being used for specific types of data, optimized for your specific physical location. The only way to change that, is to use a VPN which would show you as being in a different physical location in the world than you actually are.

Most MSFS services use TCP not UDP. All incoming packets have to be acknowledged - which could be part of the problem (in some cases), if there are problems in a user’s upstream connection. If incoming packets are not ACKed in a timely fashion, it could lead to packet re-sends or even a failed connection.

On the other hand, it would be a mistake to make the PMDG aircraft primarily an “EFB Simulator” with the aircraft part taking second place. Real aircraft EFBs don’t do “everything”. I currently work for a corporate aircraft operator. We have three Bombardier CJR-200s and three Dassault Falcon 900 EASy aircraft. Each pilot is issued an iPad Pro which are FAA-approved by our local FSDO for use as an EFB. They are each equipped with Foreflight with full worldwide Jeppesen charts, and an app for for filing flight plans and doing aircraft-specific performance calculations via ArincDirect - (which is a Collins Aerospace subscription service for professional aviation). The units have internet access on the ground via cellular, and in the air (above 10,000 feet) via GoGo ATG over aircraft WiFi. Other than Foreflight and ArincDirect, the EFBs don’t really do anything else. The pilots can also use the EFBs to send and receive email and SMS texts like any other IOS tablet. The aircraft all have the ability to fetch ArincDirect flight plans, but that is done via ACARS using the FMS, not the EFBs. It’s different in a flight sim of course. I would expect the upcoming EFB to have the ability to select various aircraft options previously accessed by by FMS menus, the ability to load fuel and payload and calculate CG, a runway-specific takeoff and landing performance calculator, and of course the ability to load flight plans from Simbrief and charts from Navigraph. For me personally, I probably would never use the Navigraph charts in-sim, as I also have an iPad equipped with Foreflight Pro and the Navigraph charts app. I prefer to have the charts on a real physical EFB that I can hold in my hand. But, I can certainly understand that in-sim charts are important to many MSFS users - especially those who fly exclusively in VR.

I’m not able to say how Fenix does it. Obviously you can speak directly for FBW. I can say for sure that the EFB in the current Aerosoft CRJ is 100 percent WASM, as I am a beta tester for that product. Hans Hartmann develops exclusively and only in C++/WASM. I recently asked him in our private Beta Discord if there was any JS in the ATR he developed for Asobo, and he confirmed that it is all WASM. The present CRJ EFB, which the aircraft has had since initial release, is “basic”. It is used for setting aircraft options, selecting panel states, loading fuel and payload etc. There is a CRJ update in the works which among other things will add full SimBrief and Navigraph support. I’m pretty sure Hans has been patiently waiting for the introduction of full TCP/IP functionality in WASM to proceed with adding that feature, as I know he has no interest in “doing” JS. There is certainly nothing wrong with JS as a development language. All of the default MSFS aircraft are written in JS, and as Working Title (and you folks at FBW) have shown, it is certainly possible to create extremely complex aircraft systems, graphics and avionics in JS to rival anything that could be done in C++, albeit with somewhat slower execution speed in some areas. But, PMDG is, and always has been a C++ house. Their MSFS 737 is 100 percent WASM and all of their previous products for FSX and P3D were developed in C++. Robert at PMDG somewhat disparagingly refers to JS as a “scripting language” which is not really an accurate description, but it probably shows he is not very comfortable in using it, and was only doing so out of necessity. I can somewhat understand his point of view. I am not an aircraft developer for any sim, but I do have a strong background in C++ and (especially) pure C - specifically in embedded systems. At age 67 I am too old a dog to learn new tricks. I still strongly a suspect that PMDG is going to drop whatever JS they have been using in the EFB in favor of pure WASM. Though I have no direct evidence, it’s quite possible that the EFB UI and all functions not requiring external access were already coded in WASM, with JS only being used for the backend TCP/IP bridge between JS and WASM. Or maybe they coded the whole EFB in JS. I guess we’ll know one way or another when it is finally released.

I don’t think it is particularly reasonable to expect feedback from Asobo on this right at the moment. Very likely all hands are involved in troubleshooting the very serious bug that has arisen in SU13 beta causing extremely long load times and crashes relating to some (but not all) Marketplace content. Expecting definitive feedback on this (potentially) new and improved graphics modification at this time would kind of be like pestering a firefighter for tickets to the firemen’s carnival while they are right in the middle of fighting a fully-involved structure fire.

It depends on how much additional revenue releasing the product on XBox brings in. If it is a substantial amount, they would be foolish to not do it, even if it complicates the development process.

Since the beginning of the EFB project, RSR has stated on more than one occasion that a significant challenge they faced was getting text data from the JS side to the WASM side, which is why they had to “hand roll” their own custom JS-to-WASM interface. Now, if that could have been easily accomplished using JSON as an intermediary, and they did not avail themselves of that option, then shame on them. But, perhaps there is a good reason why they could not do it that way. I have no particular insight into exactly how PMDG is coding their EFB, but neither do you. I can only rely on statements made by the person directly involved with coding the product. Yes I read it. I also read Randazzo’s post made just yesterday: Something that has been going on in the background, meanwhile- is that commencing with MSFS SU13, we **finally** have the ability for C++/WASM to communicate with the outside world like a normal C++ program (mostly) and like the script based products on the platform. This capability was locked out of the initial C++/WASM capability and it is incredibly important that we finally have this functionality What does this mean for the tablet? Well- we can toss out the Voyager 1 binary parsing language that we had to design for the tablet in order to pass data between the tablet and the airplane. This has already been done in testing and works the treat. It certainly seems to me that he is “raving” specifically about the added WASM TCP/IP functionality that is coming with SU13. Evidently whatever WASM TCP/IP support that was added in SU11 was not sufficient for their needs. The only reason PMDG was using Javascript at all in their EFB was because it allowed TCP/IP access to Simbrief and Navigraph. There was no other reason to use JS for any part of the EFB. Although RSR’s post does not say it directly, reading between the lines, it may well mean that with SU13, there is no longer any reason to have a JS/WASM “hybrid” EFB. If they now can do the entire thing in WASM, there is no need for the coherentBus, JSON, JS-to-C++ data structure conversion etc.

Doing things like performance calculations and setting aircraft options doesn’t even require getting JS involved. PMDG could (and probably does) implement that directly in C++. But, it’s not all numeric data that can be implemented using LVARS. Something like SimBrief FP import requires fetching text data. Seems simple enough, but strings in JS use imbedded metadata to indicate the string length whereas the PMDG FMS (written in C++) presumably expects strings to be null terminated. That data had to be passed from the JS side to the C++ side with a conversion. Both JS and C++ natively support serialization, but do not support serialization in one language and deserialization in another. JS numeric variables are all internally floating point (even integers) while C++ numeric variables have multiple dedicated types. This again becomes an issue when using cross-language serialization. The TCP/IP functionality was only needed for Simbrief and Navigraph Charts. If SU13 does indeed permit full TCP/IP access natively in WASM there is no longer any need for JS to WASM serialization with all the potential pitfalls.