May 23, 20224 yr Last week LPPT got, due to a Magnetic Declination update, a modification of it's now only two runways - 03 / 21 - to 02 / 20. Now, in MFS when starting the simulator after midnight on the night of the official change, not only the runway magnetic azimuth was changed to the new 25º value but the runway numbers changed as well into 02 / 20. In XP11 and although I now keep it updated through Navigraph, the runways still read 033 / 21 although the magnetic azimuth has been successfuly updated to 25 / 205. Would be great to see this "automatic renumbering" available for XP12 too. Edited May 23, 20224 yr by jcomm Flying gliders since 1980 Flightsimming since 1992 AMD Ryzen 5600x, 32GB RAM, GPU Nvidia RTX 3060 Ti 8 GB, 1 TB and 500 GB nvme2 SSD drives, HP 27" 60Hz LED monitor @ 1920x1080, T16000, Hotas from old X52 Pro, Saitek Combat Rudder Pro (2010 model)
May 23, 20224 yr XP12 will feature updated magvar tables, although as far as I know runway numbers are defined by the scenery, which in turn depends on somebody updating it and pushing the change to the Gateway. @Janov may know more on this subject though. 7950X3D + 7900 XT + 64 GB + Linux | 4800H + RTX2060 + 32 GB + Linux My add-ons from my FS9/FSX days
May 23, 20224 yr Author 2 hours ago, Bjoern said: XP12 will feature updated magvar tables, although as far as I know runway numbers are defined by the scenery, which in turn depends on somebody updating it and pushing the change to the Gateway. @Janov may know more on this subject though. Yep @Bjoern, I am aware of the method used in XP11 and discussed the one comming for XP12 regarding Mag Var. I believe MFS / ASOBO have followed a really clever way of "painting" the runway numbers, making them computed "on-the-fly" depending on the current database value for Magvar at a given airfield. Probably those who create airport scenery for MFS can explain how it works ? Would be nice to have a similar implementation in XP12. This way the runway numbers would always agree with the default XP database OR those obtained for instance from NMavigraph. The case now at LPPT is that after fetching the latest Navigraph may 2022 cycle I have 25 / 205 as the magnetic azimuths for runways 02/20, but the numbers are still 03 / 21... Edited May 23, 20224 yr by jcomm Flying gliders since 1980 Flightsimming since 1992 AMD Ryzen 5600x, 32GB RAM, GPU Nvidia RTX 3060 Ti 8 GB, 1 TB and 500 GB nvme2 SSD drives, HP 27" 60Hz LED monitor @ 1920x1080, T16000, Hotas from old X52 Pro, Saitek Combat Rudder Pro (2010 model)
May 23, 20224 yr Runway numbers should NOT be updated with the latest MagVar tables! This is not how it is done in the real world. Yes, the world is tipping on its side, and the rate at which it is doing it is increasing. Magnetic variation changes are a real world aviation issue. NavCanada, Airbus, and Dassault have all proposed transitioning to True North from Magnetic North for aviation purposes. Your FMS computes its courses and tracks using True North. Internal magnetic variation tables convert these courses and tracks to Magnetic North for the convenience of the pilot flying the airplane. The FMS doesn't care. In the real world, a change in magnetic variation at an airport is a BIG deal. If the ILS MagVar changes more than 1 degree, it is ineligible for any approach lower than CAT 1. If the airport arbitrarily updates the runway numbers by repainting them and redesignating them to reflect the updated magnetic variation, e.g., changes them from 01/19 to 02/20, every RNAV approach immediately becomes unusable. Back in the mid 2000's, this almost...almost happened at Denver Intl. (KDEN). The airport was about to repaint the runways without telling FAA. In a users meeting it was Jeppesen who told them they couldn't do that without informing FAA as would affect every approach at the airport and literally shut the airport down for IFR operations. I got that first-hand from sources within Jeppesen. There are many runways that are not aligned to their proper magnetic variation. Sometimes, this is done on purpose to allow multiple parallel operations. Going back to KDEN, all the south runways have a magnetic heading of 172.6: 09077AD (faa.gov) Yet, these runways are numbered: 16L, 16R, 17L, and 17R. How is Asobo and X-Plane 12 going to handle this when the Denver's MagVar changes to make the magnetic heading 179.9 or 180.0? Now, if the Navgraph data reflects the latest runway numbering for an airport, then that's another matter. Runway numbering should be taken from official source documents. For the US, that the Electronic National Aviation System Resource, or e-NASR. It's open to public view: eNASR (faa.gov) I do not know what data sources Asobo or Laminar use to paint runway numbers. However, they should always be tied to an "official source" for that airport. If Navigraph is using all of Jeppesen's available data sources, which I believe that they are, then actual runway numbers should be available along with the magnetic heading of the runway. The published runway numbes should be used to designate the runway, not an ever-changing MagVar value. I don't know if anyone from Asobo or XPlane is reading this post, but please do not do what is proposed! Thanks, Rich Boll Edited May 23, 20224 yr by richjb2 Grammatical Corrections :-), and some clarifications Richard Boll Wichita, KS
May 23, 20224 yr 8 hours ago, jcomm said: Last week LPPT got, due to a Magnetic Declination update, a modification of it's now only two runways - 03 / 21 - to 02 / 20. Now, in MFS when starting the simulator after midnight on the night of the official change, not only the runway magnetic azimuth was changed to the new 25º value but the runway numbers changed as well into 02 / 20. In XP11 and although I now keep it updated through Navigraph, the runways still read 033 / 21 although the magnetic azimuth has been successfuly updated to 25 / 205. Would be great to see this "automatic renumbering" available for XP12 too. I check LPPT on the Navigraph/Jeppesen charts. The runway numbers for LPPT are 2/20. That change was effective with the chart effective date of 19 May 2022, which was the last AIRAC cycle date. These type of changes must always occur on an AIRAC cycle date because the procedures associated with runway redesignation must change as well. I have a suspicion that Asobo is updating with the latest "official" State source for runway numbering. If X-Plane 12 were to implement this option, then it would be acceptable. However, to update it on the basis of a MagVar table, that would not be acceptable. Rich Richard Boll Wichita, KS
May 23, 20224 yr Author 16 minutes ago, richjb2 said: I check LPPT on the Navigraph/Jeppesen charts. The runway numbers for LPPT are 2/20. That change was effective with the chart effective date of 19 May 2022, which was the last AIRAC cycle date. These type of changes must always occur on an AIRAC cycle date because the procedures associated with runway redesignation must change as well. I have a suspicion that Asobo is updating with the latest "official" State source for runway numbering. If X-Plane 12 were to implement this option, then it would be acceptable. However, to update it on the basis of a MagVar table, that would not be acceptable. Rich OFC I am not saying the update should be automatic based on the MagVar database ( these updates are properly scheduled by the responsible aviation authority - NAV here in Portugal ). Also magvar in XP12 will actually be updated according to new algorithm. I would be glad if rw numbers could change with the reference database in XP navdata, updated by XP update app itself or through external sources like Navigraph. Edited May 23, 20224 yr by jcomm Flying gliders since 1980 Flightsimming since 1992 AMD Ryzen 5600x, 32GB RAM, GPU Nvidia RTX 3060 Ti 8 GB, 1 TB and 500 GB nvme2 SSD drives, HP 27" 60Hz LED monitor @ 1920x1080, T16000, Hotas from old X52 Pro, Saitek Combat Rudder Pro (2010 model)
May 24, 20224 yr This is the #1 reason Ive not put more time into IFR for AutoATC so far. The scenery update is fairly straight forward, the new runway numbers should (assuming someone changes them) come via the xplane gateway - its also a fairly easy fix to do yourself in WED iirc. But default XP11 procedures are massively outdated (often 4 or 5 changes behind) - and while you can update them, magnetic var not so much (radio headings are magnetic not true..) and doing so seems to be best described as "quite buggy". Then no easy way to deal with people on different cycles (tested a few options, but "XP12 proceedures" seemed the path of least resistance). Really hope we get some sdk goodies in that respect, parsing the procedures database is a nightmare, waiting with baited breath to see what we get, nothing announced so far as far as I know. Also, if you dont know already https://airports4xp.info/ great site for planning XP flights. Edited May 24, 20224 yr by mSparks AutoATC Developer
May 24, 20224 yr Author Thanks for the comments and link mSparks ! Yes, were all on the hold for XP12... I phone Austin everyday, twice a day, in the early morning and in the late evening to remind him we need XP12 NOW ! 🙂 Flying gliders since 1980 Flightsimming since 1992 AMD Ryzen 5600x, 32GB RAM, GPU Nvidia RTX 3060 Ti 8 GB, 1 TB and 500 GB nvme2 SSD drives, HP 27" 60Hz LED monitor @ 1920x1080, T16000, Hotas from old X52 Pro, Saitek Combat Rudder Pro (2010 model)
May 24, 20224 yr slightly off topic but with speeding magvar drifting speed, and also upraise of GPS on GAs , I wonder when we'll use True Heading only...
Archived
This topic is now archived and is closed to further replies.