lgcharlot

Do you find it annoying that hitting the 'Pause' button in MSFS 2020 (and 2024), stops the active flight and returns you to the Utilities menu, but it doesn't pause the GPU from rendering the flight scenery? You hit 'Pause', but your PC fans are probably still running at high speed, and probably still making a lot of noise, and a lot of heat is still pumping out of the computer into your room and wasting a significant amount of electricity. I've just discovered that there's an easy fix for this. You just need to download the 'Sys Internals Suite' from Microsoft. It was created by a team working under Mark Russinovich, who's been making Windows Power Tools since the earliest days of Windows, back in the 1980's I think. Within this suite of applets lives one that's the heart of this post: [pssuspend64.exe]. What is does is simply freeze the CPU's execution of whatever Process ID you point it at; in this case, Flight Simulator. When you freeze the MSFS process, both the CPU and GPU stop processing the game, stop gobbling electric power, and stop generating heat, so your fans can spin down. You implement this tweak via a couple of very simple batch files that you plant on your desktop where they're easy to get at when you want to pause the game so you can work on something else for a while. Here's what you need to do in a step-by-step process. If you don't already have it, download SysInternals Suite from MicroSoft at [https://download.sysinternals.com/files/SysinternalsSuite.zip]. This is freeware. It will come in a ZIP file, extract everything to a folder on your hard disk where you can remember where it is. I suggest a folder called "Utility_Software_Archive" if you don't already have something similar. Once you have unzipped the package into your new folder, look through the content and find [pssuspend64.exe]. Right-click on it and click "Copy as Path" from the Context Menu. Or left-click the file and press [SHIFT-CTRL-C] to load the path into your clipboard. NOTE: If [SHIFT-CTRL-C] does NOT load your file path to the keyboard, and you have an AMD Radeon GPU, the problem is likely the AMD Adrenalin software that supports your GPU. It includes a bunch of gaming features that re-map keyboard shortcuts, many of them standard Windows hotkeys, without warning you that it has done so. If you experience this, and you have Adenalin running (which you likely do if you have a Flight Sim session active), open Adrenalin's main window, and look for the gear icon in the upper left, and click on it. A sub-menu bar will appear at the top of the window: Select 'Hotkeys'. In the upper left ares of the window, you will see 'Use Hotkeys'. If you don't use Adrenalin's gaming add-ons, switch this to 'Disabled', and it will quit interfering with Windows hot keys. So now you should have the path to [pssuspend64.exe] on your clipboard. On your PC's desktop, create two new text files, and rename them [Pause MSFS.bat] and [Resume MSFS.bat]. Open the [Pause MSFS.bat] file in whatever text editor you like, and paste this code into the file. IMPORTANT! take note of the line near the bottom where it says "******Paste The Pathname You Stored to PSSupend.exe between these quote marks******", and do exactly that. Save the revised batch file. @echo off echo Focusing MSFS 2020 and pressing Escape... :: PowerShell script to activate the window, send ESC, and minimize it powershell -NoProfile -Command ^ "$ws = New-Object -ComObject WScript.Shell;" ^ "$p = Get-Process FlightSimulator -ErrorAction SilentlyContinue;" ^ "if ($p) { " ^ " $ws.AppActivate($p.Id);" ^ " Start-Sleep -Milliseconds 400;" ^ " $ws.SendKeys('{ESC}');" ^ " Start-Sleep -Milliseconds 400;" ^ " $type = Add-Type -MemberDefinition '[DllImport(\"user32.dll\")] public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);' -Name 'Win32ShowWindow' -Namespace 'Win32' -PassThru;" ^ " $type::ShowWindow($p.MainWindowHandle, 2);" ^ "}" echo Freezing the process... "******Paste The Pathname You Stored to PSSupend.exe between these quote marks******" -accepteula FlightSimulator echo MSFS 2020 is safely paused and minimized. timeout /t 3 >nulNow open the [Resume MSFS.bat] file in your text editor and paste this code block into it, again, replacing the pathname with your own where it says to do so, then save the revised file. @echo off echo Waking up MSFS 2020... "******Paste The Pathname You Stored to PSSupend.exe between these quote marks******" -accepteula -r FlightSimulator echo Restoring simulator window... :: PowerShell script to find the game window and bring it back up powershell -NoProfile -Command ^ "$ws = New-Object -ComObject WScript.Shell;" ^ "$p = Get-Process FlightSimulator -ErrorAction SilentlyContinue;" ^ "if ($p) { " ^ " $type = Add-Type -MemberDefinition '[DllImport(\"user32.dll\")] public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);' -Name 'Win32ShowWindow' -Namespace 'Win32' -PassThru;" ^ " $type::ShowWindow($p.MainWindowHandle, 9);" ^ " Start-Sleep -Milliseconds 200;" ^ " $ws.AppActivate($p.Id);" ^ "}" echo MSFS 2020 is ready! timeout /t 3 >nul Start the Sim and spawn a flight. To see where these scripts really make a difference, spawn over a large city with dense scenery that really makes your GPU work hard. Adjust the desktop layout so that you can see the Simulation main window, the task bar, and the two batch file icons you just created. Open Task Manager, or your GPU's utility software (AMD Adrenalin for Radeon GPU's, GE Force Experience or NVidea App for Nvidea high-end GPU's), and take note of CPU and GPU utilization and power consumption. Now click the [Pause MSFS.bat] icon and hit [Enter]. There will be a 2 to 3 second delay while the script identifies which Process ID is handling MSFS, and then you will see the Sim freeze and minimize to the task bar. Now look at the Task Manager: the CPU and GPU utilization has dropped to zero, and the fans will spin down. Wait a few seconds, then try the [Resume MSFS.bat] icon; the game should pop right back to where it left off. I've figured out that Asobe can't implement this into the 'Pause' command, because 'Pause' opens up a secondary menu that lets you adjust Commands, Data use, Graphics, and other features, so it can't stop the CPU and GPU or the whole screen would freeze up and you wouldn't be able to use those other features. But if you are pausing the game to work on something completely external to the sim itself, for example manual editing of an airport source XML file in Notepad++, you don't need the sim to be running while you work in the editor, and this hardware pause will let you do those other tasks on the PC without the GPU fans roaring or 300 watts of waste heat pouring out of the computer into your office. Hope this helps some of you!. BTW, I can't take credit for the code itself, just the idea for it: the code was generated by Google AI.

I have just spent the better part of a week on a project to replace some landmark buildings in San Francisco; the Asobo stock scenery had modeled all of these structures as apartment blocks or towers, and I strongly dislike the Bing photogrammetry, as it makes everything at ground level look like half-melted wax. I much prefer vector graphics. I targeted the following structures for upgrades: Coit Tower, the Mt. Sutro TV antenna tower, the Ferry Building, the De Young Museum, the California Academy of Sciences Museum, the California Palace of the Legion of Honor, and the Palace of Fine Arts. I started this project knowing absolutely nothing about importing building models that aren't already in the Asobo Object Libraries; I had assistance from several sources to learn the workflow, and it's not as difficult as you might think, if you have already found a source for pre-made models. But sadly, I found out that most of the building models I was trying to use were no good. They were all accurate as to size and shape, but they were useless for my purpose because they are modeled in solid colors and don't come with photo-realistic texture files. This is a critical flaw; one of the buildings imports into MSFS as solid black, and even after tinkering with the color palette in ModelConverter-X, I couldn't fix it, and had to delete it from the project (this was the Palace of the Legion of Honor building). The De Young Museum and Academy of Sciences came in as solid brown and featureless. Only Coit Tower and the Palace of Fine Arts were 'useable' - Coit Tower because the color palette is a close match for the real thing, and the Palace of Fine Arts came with over 130 PNG texture files that make it look really nice. I wish I could tell you how to paste photogrammetry images on top of a vector model, but that's not in my skill set, yet. I do know from the file description, that the model of the Palace of Fine Arts that I downloaded from the Trimble 3D-Warehouse, was made with photogrammetry from Google Earth, so I know it's possible, I just done know how (yet). So the main lesson I want to convey is: don't bother importing architectural assets into an MSFS Scenery Design project unless they come with photo-realistic texture files. Buildings modeled with solid colors might be okay if you never overfly them below 2,000 feet AGL, but if your goal is to import a 'landmark' building that you can 'visit' at ground level and walk around, or overfly at very low altitude, you are wasting your time unless it comes with texture files. It's always irritated me that Asobo never included Coit Tower, the Ferry Building, the TransAmerica Pyramid, the Palace of Fine Arts, and the Sutro TV Tower as realistic models. Those are arguably the most famous landmarks in San Francisco, and in the stock scenery, they're modeled as apartment buildings.

I have created a Polygon for MSFS 2020 Airport Design, that eliminates the inappropriate deciduous tree forest that covers the North Slope of Alaska and the Canadian Arctic, and replaces it with the "SmallScrub" biome. This biome isn't exactly the Arctic Tundra vegetation that you would see in the real world, but it's the closest you can get with the default Asobo library assets. Most importantly, you can now land a bush plane with tundra tires anywhere that is covered by this exclusion polygon without worrying about crashing into autogen trees that don't exist in the real world that far north. I created the polygon in Google Earth, exported it as a KML file, then added the proper SDK attribute tags to the lat/long data, and attached the header from an existing exclusion polygon that had the biome attributes I want. This isn't a perfect solution - the ground colors are still unrealistic - but at least the autogen trees are gone, and the ground cover vegetation is more or less "tundra-like". The polygon covers all of the Canadian High Arctic islands, and a slice of the continental land mass that includes most of Nunavut, the Northwest Territories north of Great Bear Lake, and the North Slope of Alaska north of the Brooks Range. This is not rigorously accurate, but anyone is welcome to refine the polygon to make it's coverage area more precise; just be aware that the BGL compiler imposes a maximum limit of 13,107 vertices on Polygons. Scenery designers are advised to use multiple polygons with fewer vertices if necessary, to stay well below the 13.107 limit. If you would like to try this, take any airport you have designed in the far north, and in the Source XML file, splice in my code block just above the <AIRPORT object. If you have any existing Polygons, make this the last one. It covers 4,878,120 square kilometers (1,422,232 square nautical miles), so you have a huge area of tree-free Artic tundra to explore. If you land somewhere and decide to camp, or just relax for a while, just keep in mind that if it's summer season, your avatar in the sim will be getting eaten alive by simulated mosquitos. 😉 BTW, you do not have to increase your "Airport Test Radius" value. Vegetation exclusion polygons are not part of "airport" data, so the Sim won't care that this polygon is enormously larger than your airport. <Polygon displayName="tree exclude" groupIndex="6" altitude="0"> <Attribute name="UniqueGUID" guid="{359C73E8-06BE-4FB2-ABCB-EC942F7761D0}" type="GUID" value="{36C272A8-AD90-4345-9EC7-074F4FD28EB3}"/> <Attribute name="VegetationScale" guid="{6A043F59-E6F2-4117-A2E4-D510E7317C29}" type="UINT32" value="0"/> <Attribute name="VegetationDensity" guid="{41EFF715-C392-4B31-A457-50A504353A90}" type="UINT32" value="0"/> <Attribute name="TreeBrightnessFactor" guid="{63040596-0B21-48FD-8B5F-A9E84A5B7BC9}" type="UINT32" value="0"/> <Attribute name="BiomeName" guid="{E5FA1B20-BB2F-40D5-913B-480C547CC9B8}" type="STRING" value="ScrubSmall"/> <Vertex lon="-155.2914908493373" lat="68.15237995260851"/> <Vertex lon="-149.5871794850976" lat="68.43629545054165"/> <Vertex lon="-144.6554214552498" lat="69.24997055846178"/> <Vertex lon="-138.4630439225604" lat="66.77073961744587"/> <Vertex lon="-134.6636730666596" lat="66.62782832926895"/> <Vertex lon="-119.5366350895035" lat="67.16700880076132"/> <Vertex lon="-103.8448564838584" lat="64.50576389349278"/> <Vertex lon="-92.21432288881323" lat="61.09715597166249"/> <Vertex lon="-84.56258474688607" lat="60.30590250843139"/> <Vertex lon="-79.28998425487480" lat="61.01413718854442"/> <Vertex lon="-78.66847454366531" lat="62.66905542363784"/> <Vertex lon="-75.35417541139145" lat="62.63369692759734"/> <Vertex lon="-72.57565064418981" lat="62.44471756383010"/> <Vertex lon="-64.72532277606648" lat="60.96009610496460"/> <Vertex lon="-61.75094386639130" lat="61.90332180394193"/> <Vertex lon="-58.85025621101383" lat="65.29542413689802"/> <Vertex lon="-64.96612776430141" lat="71.25154508246699"/> <Vertex lon="-73.32029428464792" lat="74.81867585083741"/> <Vertex lon="-74.46182713722315" lat="77.50284436034669"/> <Vertex lon="-72.66326279416352" lat="78.92443722981079"/> <Vertex lon="-67.73352160765003" lat="80.51268813959428"/> <Vertex lon="-62.58333952664752" lat="81.72501326961340"/> <Vertex lon="-59.23234045077193" lat="82.64842795773453"/> <Vertex lon="-62.90958458873958" lat="83.69866090578088"/> <Vertex lon="-75.86943172024455" lat="84.82932444649522"/> <Vertex lon="-120.2348644025080" lat="79.20545501221262"/> <Vertex lon="-131.7764604185893" lat="74.23892440366959"/> <Vertex lon="-129.5517002991992" lat="70.82723864289754"/> <Vertex lon="-135.0787114475045" lat="70.38558250059234"/> <Vertex lon="-140.2535393652618" lat="70.28769269360542"/> <Vertex lon="-145.4535008532789" lat="70.69512624893864"/> <Vertex lon="-151.3973062432938" lat="71.25684228307175"/> <Vertex lon="-156.6807094307236" lat="71.59025543367548"/> <Vertex lon="-163.0192773990730" lat="70.52688455140388"/> <Vertex lon="-167.3682278149874" lat="69.26078570607743"/> <Vertex lon="-167.8123091778309" lat="67.02887137730350"/> <Vertex lon="-155.2914908493373" lat="68.15237995260851"/> </Polygon>

I've just spent the better park of a month teaching myself how to use the more advanced features in the SDK, to design some airports in northern Canada that aren't in the Asobo stock scenery. My latest one to complete is Sach's Harbour, ICAO: CYSY. I had just finished several hours work on fine tuning the RNAV approaches, and to really test them, I set up a flight in the G-36 Bonanza, with the weather totally socked in, below minimums in fact, with heavy rain, and 100% overcast all the way to the ground, and 12 knots of cross-wind. The approach and missed-approach legs for both runways worked perfectly: I couldn't see the runway or even the end lights until I was crossing the threshold, and the autopilot had me right on the centerline, with the wheels hitting right on the touchdown stripes. Perfect! So I taxied over to an available hangar and parked inside - remember I said it was raining? and guess what; it's still raining, inside the hangar! The hangar I'm using has an automatic animated door that cycles about twice a minute, so if it's closed when you want to enter or exit, you just have to wait a few seconds. So I taxi in, expecting the rain to stop as I pass under the doorway, but noooo, it's still pouring down on the aircraft and the hangar floor. Here's the XML code for the hangar I'm using: <!--SceneryObject name: pbk-hanger-anim1--> <SceneryObject groupIndex="13" lat="71.99267218583974" lon="-125.23838684204300" alt="0.00000000000000" pitch="0.000963" bank="-0.000963" heading="-94.780616" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="TRUE" snapToNormal="FALSE"> <LibraryObject name="{9EB1A726-8362-447A-8630-BCF00D514E7B}" scale="1.500000"/> </SceneryObject> What a disappointment! I wonder if all of the various hangars and roofed structures in the scenery designer are like this, and have "leaky roofs", or just this particular one? Is the problem with the hangar, or is that the Sim doesn't understand the concept of blocking rainfall under a roof?

After nearly two weeks of struggle around designing custom scenery for a set of 25 airports in the Canadian far north that are missing from the Asobo stock scenery, I have finally worked out how to build an RNAV approach that actually works with the Working Title Garmin G-1000 avionics suite that's in several of the Asobo stock General Aviation airplanes. I've tested the following code in the Beech G-36 Bonanza and the Cessna C-172 G1000. I nave NOT tested this in any of the large jet airliners. Before you dig in to the code block, I want to point out a few important tips about it: All of the Approach code, including the waypoint data, needs to be placed at the end of all other Airport data, typically in between the <ApronEdgeLights/> line, and the </Airport> line, as shown below. The Scenery Compiler is extremely persnickety about the syntax, punctuation, and ordering of the code. If the compiler throws any error messages whatsoever, do not try to use the resulting Package in the Sim, even if one gets generated. You have to track down and eliminate ALL errors in the code before you copy a package to the Community folder and start testing it. Although an approach might seem to run okay if you put the waypoints at the end of the approach data, or mixed in with it, there are obscure problems with this; always put all of your waypoint data above the first [<Approach type="RNAV"] line, as shown below in the full code block. If you want your RNAV approach to have maximum versatility, and use all of the features in the G1000 avionics package, your [<Approach type="RNAV"] lines need to include these four tags: lnav="TRUE" lnavvnav="TRUE" lpv="TRUE" lp="TRUE". If any of these four tags are "FALSE", the Vertical navigation features of the autopilot will probably not work; pressing the VNAV and APR buttons on the autopilot will not put you in VPTH or GP mode to fly down the glide path. Looking at the Waypoint data, the waypoints that refine the top of the Final Approach leg to the runway threshold need to have the [waypointType="FAF"] tag, the waypoints that define the IF (Initial Fix, i.e. beginning of the approach), and Missed Approach points, need to be [waypointType="NAMED"]. All waypoints must have a valid [waypointRegion=] code; in this example, "CY" is Canada, and a valid magvar value, which you can get from Little Nav Map. You need to verify, again using Little Nav Map with a freshly uploaded database, that your waypoints have unique ID's that don't exist anywhere else, either in stock Asobo or third-party scenery. If any of your waypoints duplicate Stock or other ID's, your airport might compile okay, but the approach will probably malfunction. Your FAF waypoint needs to have Latitude and Longitude coordinates that line up exactly on the runway centerline, at least 3 miles out from the threshold. The compiler might allow this point to be closer, but the logic processor in the Garmin G1000 might reject the approach if the FAF leg is too short, or it's not lined up accurately enough on the centerline. The easiest way to get the lat/long coordinates and altitude for the FAF waypoint is to ask Google AI. Tell the AI the latitude and longitude of the runway reference point, the runway length, and the elevation of the threshold points at each end of the runway: you get the Runway ARP coordinates from the airport Source XML file, to 14 decimal places, and the threshold elevations from the Gizmo tool in the Scenery designer. Temporarily place a small single-point object like a traffic cone at each end of the runway, on the centerline, and make a note of it's altitude from the Gizmo tool. In your request to Google AI, include this elevation, and tell the AI to add 50 feet to the runway's [altitude1] tags for the [fixType="RUNWAY"] legs of the approach. This is needed because you want your plane to cross the threshold on final 50 feet above the ground, so that the wheels hit right on the touchdown stripes. The IF and Intermediate waypoints can either be in line with the runway, or, if your approach heading conflicts with high terrain, you can lay out the approach path off to one side or another, or even design a route that zig-zags through mountain valleys to reach the FAF point, as long as the turns aren't too severe. Just remember that some of the airplanes flying this approach will be flying at 130 knots or more, so the legs have to be long enough to give the plane enough time to make any turns. The Runway 33 approach in this code block actually has 3 legs with 2 such turns. There is high terrain on the approach path, so I had to offset Legs 1 and 2 down the fjord to the southwest of the approach. Now to the Approach Header tags. [designator="NONE"] and [gpsOverlay="FALSE"] seem to be the standard. The [fixType="WAYPOINT"] refers to the IF point, in this example, I33AB at the top of the approach path. The {heading] tag is the True Heading along the first leg of the Approach, between the IF and the next point down from it (R33AB in this example). The [fixIdent] tag is always the name of the IF waypoint. The [missedAltitude] tag contains the MSL altitude of the target climb-out; i.e. the minimum safe altitude to which you must climb after declaring a missed approach, to be able to orbit safely above the terrain. And last but most important of all, is the [altitude=] tag. This will be the MSL altitude of the IF point, and you have to derive it by building the approach backwards from the threshold. In step 7 above, you determined the threshold elevation, and added 50 feet to that. Now compute the altitude of the FAF waypoint by taking the horizontal distance in feet between the threshold and the FAF point, multiplying that by tangent of the glide path angle, usually 3.0 degrees, and adding the result to the threshold crossing altitude. For example, your Final Approach leg is exactly 5 nautical miles long, and the glide path is 3.0°. The tangent of 3.0 = 0.052407779283. Multiply this times the distance in feet 30,380.577 = 1,592.18 feet. If your runway threshold ground elevation is 460.2 feet, and you've added 50 feet for clearing the threshold, your grand total altitude for the FAF point is 1592.18+50+460.2=2,102.38 feet. That will be the altitude you code for the FAF point, but now you need to work the same math up the slope for each leg until you get to the IF point. You need to do this with extreme care fo accuracy. If the altitudes don't agree with the leg distances and the math of the 3° glide path, the autopilot will refuse to follow the glide path: the VNV (Vertical Navigation) and APR (Approach) buttons on the Garmin won't put the autopilot in VPTH or GP modes, and you won't see the Pink Diamond in the PFD Glide Slope Indicator that tells you that the Vertical Navigation system is controlling the plane's descent with GPS and WAAS satellite data instead of barometric altitudes. The Working Title G1000 NXi in the Asobo planes is a very accurate simulation of the real thing: it won't tolerate sloppy coding in your XML source file. If the elevations of your Fix points don't agree with the glide path angles and leg distances, it will level off the aircraft at the FAF altitude rather than risk a CFIT, or missing the runway entirely, because of an error in the source code of the airport's scenery file. You can ask Google AI to compute the altitudes. First plan the route of the approach path to avoid high terrain, if need be. Do this in Google Earth, and try to keep the total path length to no more than about 15 miles. This gives you 3 legs of 5 miles each, and puts the IF point about 4,800 feet above the runway. Make note of the Lat/Long coordinates of each point, feed your data to Google AI, and ask it to adjust your FAF point coordinates to exactly line up on the runway centerline, and compute all the point altitudes to maintain a precise 3° glide path. Onward to the Approach Legs! The first line is the IF leg. [Leg type="IF"]. You need 6 tags, no more, no fewer: [type="IF"], [fixType="TERMINAL_WAYPOINT"], [fixRegion="??"], [fixIdent="?????"], [altitudeDescriptor="+"], [altitude1=[????F"]. IMPORTANT! [altitudeDescriptor] must be "+" here. If you put "-" or "A", the Vertical Navigation may not work as expected. The next one or more lines will be Intermediate Fix points, if any, else the "FAF" point for a simple 2-leg approach. There will be exactly 8 tags in each Intermediate Leg: [type="TF"], [fixType="TERMINAL_WAYPOINT"], [fixRegion="??"], [fixIdent="?????"], [altitudeDescriptor="+"], [altitude1=[????F"], [trueCourse="???.??"], and [flyOver="FALSE"]. After the Intermediate Legs, comes the Final Approach Fix, or FAF. This leg aims you on the correct heading for the runway centerline, and if you programmed the Altitudes correctly, the autopilot should set your plane's wheels down exactly on the touchdown stripes, 950 feet down the runway from the threshold. There are exactly 9 tags in this Leg: [type="TF"], [fixType="TERMINAL_WAYPOINT"], [fixRegion="??"], [fixIdent="?????"], [altitudeDescriptor="+"], [altitude1=[????F"], [trueCourse="???.??"], [flyOver="FALSE"], and [isFAF="TRUE"]. This last one is crucial! The autopilot will not bring you down to the runway in GP mode, or show you that pink diamond indicator in the PFD, without the [isFAF="TRUE] tag. The last leg is the Runway. There are 8 tags: [type="TF"], [fixType="RUNWAY"], [fixRegion="??"], [fixIdent="????"], [flyOver="TRUE"], [altitudeDescriptor="A"], [trueCourse="???.??]", [altitude1="??"]. The [altitude1] value is the ground elevation of the runway threshold plus 50 feet. NOTE: This is the only Leg where you use "A" instead of "+" for the [altitudeDescriptor=]. The Missed Approach legs are pretty self-explanatory, but take note of these potential pitfalls: The [time=] tag needs to have 1 decimal place in it, i.e. "1.0", instead of just "1". Otherwise the Garmin software might mis-interpret the tag as a distance instead of 1 minute of time. The [speedLimit=] tag in this exaple is set to 250 knots, which is the general speed limit in all airspaces below 10,000 feet AGL, but setting it to a lower limit, if you want to for some reason, doesn't seem to adversely affect the functioning of the simulation. A few last words. Waypoint ID's are limited to no more than 5 alphanumeric characters. Capitol Letters and Numbers only, no punctuation marks. You can use whatever letters and numbers you like, just make certain you aren't duplicating an existing waypoint or Navaid ID in the stock Asobo scenery or any third party scenery add-ons in the Community folder. Use True, not Magnetic courses, especially anywhere north or south of the 73rd Latitudes; the convergence of the Longitudinal meridians, and the extreme distortion of the lines of magnetic variation near the Poles, can make the Garmin G1000 malfunction in ways that are not well documented and are difficult to diagnose and correct, if you try and define approach legs with magnetic courses. Remember, when you are descending an RNAV approach, you should see that pink Glide Path diamond in the PFD if the lnavvnav, lpv, and lp tags in the Approach Header line are all set to "TRUE"; if you are still not seeing it when you get to the FAF point, or the plane levels off at the FAF and doesn't continue on down to the runway, something is wrong with your XML coding for the approach. Look through it very carefully, make corrections if you can find the problem, and re-compile the package. Good Luck and happy landings! <ApronEdgeLights/> <Waypoint lat="73.11126536241320" lon="-85.51777587748280" waypointType="NAMED" waypointRegion="CY" waypointIdent="I15AB" magvar="24.5" /> <Waypoint lat="73.06079022716540" lon="-85.29010626416480" waypointType="FAF" waypointRegion="CY" waypointIdent="C15AB" magvar="24.5" /> <Waypoint lat="72.9208306350795" lon="-84.6713659765127" waypointType="NAMED" waypointRegion="CY" waypointIdent="M15AB" magvar="24.5" /> <Waypoint lat="72.8600240616" lon="-84.455184653" waypointType="NAMED" waypointRegion="CY" waypointIdent="I33AB" magvar="24.5" /> <Waypoint lat="72.9617097678" lon="-84.8499479159" waypointType="FAF" waypointRegion="CY" waypointIdent="C33AB" magvar="24.5" /> <Waypoint lat="73.09110553491770" lon="-85.42654971513200" waypointType="NAMED" waypointRegion="CY" waypointIdent="M33AB" magvar="24.5" /> <Waypoint lat="72.8880188758" lon="-84.7206286765" waypointType="NAMED" waypointRegion="CY" waypointIdent="R33AB" magvar="24.5" /> <Approach type="RNAV" runway="33" designator="NONE" gpsOverlay="FALSE" fixType="WAYPOINT" fixRegion="CY" fixIdent="I33AB" altitude="4540F" heading="289.83" missedAltitude="2500" lnav="TRUE" lnavvnav="TRUE" lpv="TRUE" lp="TRUE" > <ApproachLegs> <Leg type="IF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="I33AB" altitudeDescriptor="+" altitude1="4540F"/> <Leg type="TF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="R33AB" flyOver="FALSE" altitudeDescriptor="+" altitude1="2950F" trueCourse="289.83" /> <Leg type="TF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="C33AB" flyOver="FALSE" altitudeDescriptor="+" altitude1="1360F" trueCourse="332.80" isFAF="TRUE" verticalAngle="3.00" /> <Leg type="TF" fixType="RUNWAY" fixRegion="CY" fixIdent="RW33" flyOver="TRUE" altitudeDescriptor="A" trueCourse="307.51" altitude1="81F" /> </ApproachLegs> <MissedApproachLegs> <Leg type="TF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="M33AB" flyOver="TRUE" trueCourse="307.65" altitudeDescriptor="A" altitude1="2500F" /> <Leg type="HM" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="M33AB" trueCourse="307.65" turnDirection="R" time="1.0" speedLimit="250"/> </MissedApproachLegs> </Approach> <Approach type="RNAV" runway="15" designator="NONE" gpsOverlay="FALSE" fixType="WAYPOINT" fixRegion="CY" fixIdent="I15AB" altitude="3275F" heading="127.65" missedAltitude="2500" lnav="TRUE" lnavvnav="TRUE" lpv="TRUE" lp="TRUE" > <ApproachLegs> <Leg type="IF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="I15AB" altitudeDescriptor="+" altitude1="3275F" /> <Leg type="TF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="C15AB" altitude1="1751F" altitudeDescriptor="+" trueCourse="127.65" verticalAngle="3.00" isFAF="TRUE" /> <Leg type="TF" fixType="RUNWAY" fixRegion="CY" fixIdent="RW15" flyOver="TRUE" altitudeDescriptor="A" trueCourse="127.65" altitude1="81F" /> </ApproachLegs> <MissedApproachLegs> <Leg type="TF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="M15AB" flyOver="TRUE" trueCourse="127.65" altitudeDescriptor="A" altitude1="2500F" /> <Leg type="HM" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="M15AB" trueCourse="127.65" turnDirection="R" time="1.0" speedLimit="250"/> </MissedApproachLegs> </Approach> </Airport>

I have begun a project to build 25 airports in Canada, in Northwest Territories and Nunavut, that Asobo doesn't include in MSFS2020 stock scenery. I ran into a problem with coding RNAV approaches for them; nothing fancy, just straight-in, 2-legs, IF>CF>Runway. The problem I had was that the plane I was testing this with, the Rheims FR-172 from flightsim.to, equipped with the PMS50 GTN750 and a Bendix Autopilot, was touching down right at the edge of the threshold instead of on the touchdown stripes. You code this in the XML source file by adding 50 feet to the runway elevation, like this: <Approach type="RNAV" runway="07" designator="NONE" gpsOverlay="FALSE" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="I07SY" altitude="4200.0F" heading="84.00000" missedAltitude="2100.0F" lnav="TRUE" lnavvnav="TRUE" lpv="TRUE" lp="FALSE" > <ApproachLegs> <Leg type="IF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="I07SY" altitudeDescriptor="+" altitude1="4500.0F" /> <Leg type="TF" fixType="TERMINAL_WAYPOINT" fixRegion="CY" fixIdent="C07SY" flyOver="FALSE" recommendedType="RUNWAY" recommendedIdent="RW07" theta="3.0" rho="10.0N" altitudeDescriptor="A" altitude1="3800.0F" magneticCourse="65.3" distance="10.0N" isFAF="TRUE" /> <Leg type="TF" fixType="RUNWAY" fixRegion="CY" fixIdent="RW07" flyOver="TRUE" altitudeDescriptor="A" altitude1="359.00F" magneticCourse="65.3" theta="3.0" rho="10.0N" distance="10.0N" verticalAngle="3.0" /> </ApproachLegs> In this example, the IF fix point is at 4,500 ft MSL, the FAF fix at the top of the glide path is at 3,800 ft, and the RW fix is shown at 359 feet, which is 50 feet above the threshold. The Theta, Rho, Distance, faf="TRUE", and verticalAngle tags are all designed to instruct the aircraft's GPS and Autopilot to provide a Glide Path of 3.0% from FAF to the runway, with the plane crossing the threshold 50 feet AGL, and setting the wheels down more or less exactly on the touchdown stripes. So I spent about 20 hours struggling with this, and the plane kept touching down right on the threshold: it was doing this not only at my custom airport, but also at a couple of Asobo stock airports that I tried, too, and that gave me an idea: "maybe the problem is in the plane's hardware, and not in my Approach code?". So I rebooted the sim with the stock Asobo C-172, G-1000 version, and again with the Bonanza G-36 Turbo (also equipped with the G-1000), and my RNAV approach worked perfectly at both runway 07 and 25. So lesson #1 learned: when designing custom scenery, Approaches are usually the hardest part of any custom airport, because the SDK scenery designer offers you very little assistance, if any; every ILS approach I've ever built, originated with XML code generated in Jon Masterson's ADE. But now I'm trying to work out how to build RNAV approaches, and had to find hints on how to do it from whatever examples I could find on the Internet, and a lot of them ultimately had bugs and didn't work. Lesson #2 learned: If the code for an approach isn't working, yet it compiles in the SDK without throwing an error message, try flying it in a different aircraft that uses a different GPS. If you are testing a new airport with a plane you got on the Marketplace, for example the C-182RG from Carenado, and something is not working as you expect, maybe you've found a previously undiscovered bug in the source code for that plane's avionics. Try a stock Asobo plane, and if your airport is now fully functional, you know the problem wasn't in your code, it was in the third-party aircraft. Good luck! There's nothing more satisfying than that first successful touch and go at an airport you designed from scratch, where you test all of the ILS and/or RNAV approaches, and everything works as it's supposed to.

I recently ran into a problem involving Airport design, specifically, a situation where some of my custom airports were not showing up on a Garmin GPS when using the "Nearest Airport" feature. This was happening with both the PMS50 GTN 750 add-on, and the Garmin 1000 in the stock Asobo Cessna 172. The airport itself is in the sim, and you can spawn a flight at any of the parking spaces or runway starts, and you could type in the ICAO in the Garmin in "Direct To" mode, and plot a flight path to the airport, but the "Nearest Airport" feature wouldn't show it. The airports in question are CYCY (Clyde River), CYAB (Arctic Bay), CYSY (Sach's Harbour), and CYVL (Colville Lake), all in Cahada's NWT or Nunuvut. There are at least 25 airstrips in NWT and Nunavut that have been built or improved in recent years by the NWT and Nunavut Provincial governments, but as of 2026, Asobo has still not included them in the FS2020 stock scenery. These are all un-towered dirt and gravel strips, but some of them actually have PAPI2 or PAPI4 approach lights - you can see them on Google Earth images - and all of them have small terminal buildings, and at least occasional service from small regional airlines. So I have begun a project to make airports at all 25 of these neglected places in Canada's far north, and had completed nine of them, when I made the disturbing discovery that four of them are invisible to the "Nearest Airport" feature, even when the plane is right there at the airport in question. So, I began digging through my XML source files, trying to find some errors that might account for why those four airports were having this problem, when the other 5 were okay. And after a full week of head scratching and frustration, I finally found the problem, and it's not something most people would ever think of: it was runway material. The five airports that didn't have the problem all had runways coded with either Asphalt or the Asobo "Gravel01" material. The four malfunctioning airports all had the runway coded with "Gravel_Ground", also from the Asobo library, so it's a stock material in the SDK. The GUID for this material is [05C575AB-4367-42AA-963F-F0F1EACBC400]. I have just re-coded all runways, ground polygons, and aprons, to use Gravel_01, surface GUID [9E7A4A2E-32C0-4495-BDDF-79B24AFB25ED], and now the four airports show up in the GPS "Nearest Airport" function as you would expect. I can't explain why the sim's internal functioning would have an issue with a material that is in the official Asobo library; maybe the software that searches the scenery database for airports when you click the "Nearest Airport" button on a GPS, cross references a list of runway materials, and this list either doesn't include Gravel_Ground, or there's just a glitch in the software somewhere that's never been noticed until now.

This post aims to help anyone creating basic airports, using Google Earth to trace ground area polygons. My specific use case: I have identified 25 airports in Canada's Northwest Territories and Nunavut, that are still not included in MSFS 2020, even though that sim was released almost 6 years ago. These are dirt-and-gravel strips bulldozed out of the native surface (tundra, permafrost, or whatever was there), and on Google Earth, it's easy to see the perimeter of the graded area; it's generally a tan to light brown color, and of course all the trees have been removed. It's too laborious to transcribe the coordinates for the vertices from Google Earth, and manually type them in one at a time in the Scenery Designer, so here's a better work flow. First off, you will need Google Earth on your PC, if you don't already have it, and a text editor that has "Block Select Mode". TextPad has this, and you can download it from several places on the 'net. I use Text Pad v4.0; there are newer versions, but I've never felt the need to upgrade. Once you've installed it, you access "Block Select Mode" in the "Configure" pull-down of the main menu. You will need this to re-configure polygon vertex data from Google Earth. Okay, now here's the actual workflow: Create your airport in the Scenery Designer, then place the Runway(s) using lat/long coordinates from Google Earth for the centerline heading and overall length. Create a simple 4-sided Polygon around the airport's general area, then set the attributes to exclude vegetation, and set the appropriate material and color (gravel, grass, dirt, etc). Don't worry about the exact positions and coordinates of the vertices, you will be overwriting them with Google Earth numbers. Find your airport on Google Earth, then create a Polygon, of however many sides and vertices you need, that covers the desired area; in my case, the total area that was graded to remove trees and create the runway, ramp area, and parking lot. In Google Earth, set this polygon to be just the outline, without fill color. Name this polygon something you can remember, usually the airport name, with "ground poly" appended. Now, click the "Save Scenery" button in the Scenery Editor window. Save the Polygon as a KML file to the root folder of the airport's SDK Scenery folder tree. In Windows Explorer, Navigate down the Scenery folder tree to the folder where your scenery XML source file lives. [Airport Project Root] > [PackageSources] > [Scenery] > [your airport project name] > [scenery] > [your airport's ICAO.xml]. Copy this file to the Desktop as a backup in case something goes haywire. Open the source XML file with TextPad, then scroll down until you find the Polygon you created in Step 2. Take note of the exact syntax of the XML code that defines the vertices of the polygon, you will need to duplicate this in the next couple of steps, exactly as it's shown in the Scenery Design source file. If the Polygon data is there, close the Project in the SDK Project Editor. If it isn't there, go back to the Scenery Editor and click "Save Scenery" again, reload the file into TextPad, and if it now looks good, close the Project. You are going to be manually manipulating this file in the next several steps, and you don't want it to be open in the SDK Project/Scenery editor when you do this. Now open the KML file from step 3 in another TextPad window. It helps if you are doing this on a desktop PC with 2 or 3 monitors; if you have multiple monitors, have the Scenery Design source file on one monitor, and the KML file from Google Earth open on the second monitor. Scroll down in TextPad until you get to the data section with the polygon vertices. Now here's where you need to do some data manipulation, and you will now find out why you needed a Text Editor with "block select mode". The first thing you will probably notice is that the FS2020 SDK Scenery source file lists the coordinates of the Polygon vertices with Latitude preceding Longitude, like this: <Vertex lat="73.01039815595590" lon="-85.06242575464277"/> <Vertex lat="73.01045739611199" lon="-85.06338988452819"/> But when you look at your Google Earth KML file, the vertex coordinates are reversed, with Longitude preceding Latitude, and all on one continuous line, like this: <LinearRing> -85.06496482104024,73.01027119730628,0 -85.06530450640419,73.00930469725016,0 -85.06301619198243,73.009041719816,0 -85.06119918730036,73.0087537054918,0 -85.0516528.......... These are the steps you need to follow to re-format the KML data so you can copy it into the Scenery Source file: In Text Pad, under the Configure menu, set Word Wrap mode. The data will no look like this: <LinearRing> -85.06496482104024,73.01027119730628,0 -85.06530450640419,73.00930469725016,0 -85.06301619198243,73.009041719816,0 -85.06119918730036,73.0087537054918,0 -85.05165289266428,73.00670576431472,0 -85.04330821520668,73.00485228295746,0 In this example, the "-85's" are all Longitudes, the "73's" are Latitudes. The first thing to do is pad any of the coordinates that are short, with extra zeroes at the end, to make them all the same character length. This is essential for using "Block Select Mode". Go down the list and add a carriage return/line feed (using the Enter key) at the end of each coordinate. The data will now look like this: -85.03823750423923,73.00382200296775,0 -85.03778603609133,73.00350055634115,0 -85.03718214840056,73.00338098881501,0 -85.03535327195833,73.00299144730749,0 The extra '0' at the end of each line is the elevation, you can now delete it from each line (just delete the zero, leave the comma). Now, switch TextPad to "Block Select Mode", and draw a selection block around all of the Longitude numbers, and hit CTRL-X to "cut" them to the clipboard. Now place the cursor at the end of the first line and hit CTRL-V. The data should now look like this: 73.00120451092420,-85.02731795006505, 73.00151274992268,-85.02693774189574, 73.00175121653570,-85.02719804405363, 73.00280683410942,-85.02649060748708, Use Block Select to grab all of the commas on the ends of the lines and delete them. Now you will use the 'Find and Replace' tools in TextPad to add the 'Vertex', 'lat', and 'lon' Tags to the coordinate data, so that you end up with this: <Vertex lat="73.00930469725016" lon="-85.06530450640419"/> <Vertex lat="73.00904171981600" lon="-85.06301619198243"/> <Vertex lat="73.00875370549180" lon="-85.06119918730036"/> <Vertex lat="73.00670576431472" lon="-85.05165289266428"/> You need to be very careful here; the syntax, spelling, and punctuation has to match exactly what the compiler expects, or the file will not Build into a finished Package. If you are sure you haven't made any errors in adding the tags to the coordinate data, you can now import the modified vertex data from the KML file into your Project Scenery Source [ICAO].xml file. Select all of the modified vertex data lines from the KML file and hit CTRL-C to copy them to the clipboard. Now, switch to the Project Scenery Source [ICAO].xml file, and highlight the four existing Polygon vertex data lines, then hit CTRL-V to paste/overwrite them with the Google Earth polygon data. Hit CTRL-S to save the file. Re-open the Project in Scenery Designer, re-open the Scenery Editor, and hit "Load This Asset Group". Now look at the airport in Camera Top Down view mode. Zoom out until you can see the whole airport. If you did everything correctly, you should see that the random 4-sided Polygon you originally created as a placeholder, has been replaced with the actual airport outline polygon you created in Google Earth. If you get any error message, or the "Load This Asset Group" command fails, there is probably made an error in Step 8. Look very closely at the syntax and punctuation; the tiniest boo-boo, like a single quote where the compiler expects a double quote, or a missing '/>' or '=', will cause the compiler to crash. If everything looks good, proceed with the rest of the scenery design, then compile the way you usually do, either with the 'Build' command in the SDK, or the command-line compiler (my preferred way). These instructions may seem complicated, but they do allow you to import a Google Earth polygon with an unlimited number of vertices into the Scenery Designer, with no other tools except Google Earth itself, and TextPad (or any other text editor that supports Block Select Mode). You don't need QGIS or other fancy 3-D ESRI shapefile tools to do this, since these Exclusion polygons are two-dimensional. Once you master TextPad and how to use Block Select Mode and the Find and Replace tools, it's pretty easy and intuitive. NOTE: I have only tested this procedure in the FS2020 Scenery Designer. It should work the same in FS2024, but I can't guaranty it.

All of the options shown in this thread that refer to "clicking on the Empty box" only work in FS2024. FS2020 doesn't offer an "empty box" or "none" for the pilot/co-pilot avatars. If you are trying to delete a co-pilot avatar in FS2020, I have not yet found a way to accomplish this after many hours of searching the MSFS forums.

Many of you who have years of experience with coding add-on scenery for FSX and MSFS may already know this, but some of you might not - especially if you have been struggling with intermittent problems coding ILS's and VOR's. This is embarrassing to admit, because I ran FSX for at least 15 years, and now FS2020 and FS2024 since 2020: I didn't know that the frequency band for VOR and ILS radio navaids was split up into specific pairs of frequencies. In other words, if you are coding an ILS, you can't just throw in any frequency between 108.10 and 111.95 mHz - there are 40 specific frequencies available, and they aren't contiguous. If you tell the MSFS SDK to use, say, 111.45 mHz for the Rwy 24 ILS at your airport, the SDK will do so, and when you Build that Project, the compiler isn't going to throw an error code. But when you actually fly the approach to that runway, your autopilot isn't going to capture either the Localizer or the Glideslope in NAV or APPR modes: because 111.45 mHz is a VOR frequency, not an ILS frequency! If you are using Jon Masterson's (Scruffy Duck's) Airport Design Editor, and you select your ILS frequency from the provided pull-down menu, it will only show the 40 authorized frequencies for ILS's - this is how I found out that there are only 40 channels for ILS's, out of the 200 available 50 kHz channels between 108.00 MHz and 118.00 MHz. I went searching on the Internet, to try and find out why ADE only provides 40 ILS channels, and found this document: https://wiki.radioreference.com/index.php/Instrument_Landing_System_(ILS)_Frequencies I've clipped out just the section for ILS's as a JPEG if anyone might find it useful to have: https://drive.google.com/file/d/1ld16kChkjF6NIqKRdN9A86ZyuyFtG8Ag/view?usp=sharing So when you are designing custom scenery that's going to include a VOR/DME or a runway with an ILS, you need to be careful to not use VOR frequencies for ILS's, or ILS fequencies for VOR/DME's. The SDK will allow you to do this and the Compiler won't throw an error code, but in-sim, the game engine does seem to be aware of the difference between VOR's and ILS's, and they won't behave properly if you used a wrong frequency - especially, the NAV and APPR autopilot functions probably won't work properly, or maybe not at all. In order for the autopilot in your plane to fly a glideslope, you need to manually add an APPROACH element to your XML file; for some reason, Asobo's SDK doesn't seem to include a tool to do this. I've covered this issue in a couple of separate postings on AVSIM, but to reiterate briefly, your ILS needs to have a couple of Approach Legs and Missed Approach legs, with a minimum of 3 terminal waypoints that define them. In order for your ILS to function properly, the Approach Legs and Waypoints have to be laid out in a specific geometry and with specific tags; it's a pretty complex chunk of code, and if your runway is on a heading that isn't exactly 0, 90, 180, or 270 degrees, computing the lat/long coordinates for the Waypoints is a heavy chore. It's easiest to let ADE do this, by starting an ADE project, putting in just a runway with the correct location, heading, and length/width, adding one or both ILS's to it, then Export the XML code, Copy and Paste the code for the Approach from ADE's XML file to the XML file you are building in the Asobo SDK, and Build it there. ADE20's compiler appears to be broken - I've never been able to get it to actually Build an ADE20 project into a completed Package, and ADE20 was left as an incomplete Alpha build when Jon retired, so it will probably never be "finished". Anyway, this is a extra hoop you have to jump through just to get a functional ILS, but I know of no easier way to generate the XML code for a basic ILS Approach, and without it, the autopilot in your plane can't capture the Localizer or the Glideslope. BTW, If anyone knows "why" the tools to build an Approach are missing from the Asobo SDK, when an Approach is a requirement for an ILS to work properly with an Autopilot even in the smallest GA planes like the NX Cub and C-172, I'd be interested to know. Good luck! Coding custom airports is a bewildering job at first, especially learning the ins and outs of XML coding, but the rewards are a lot of fun. I imagine building a small gravel runway in a meadow next to a lake somewhere in Alaska or NWT in Canada, and populating the scenery with some camp chairs, a campfire, a tent (yes, these are available in some add-on scenery packs), and imagine myself sitting in that chair and watch the sun set while I make some S'Mores over the campfire.

I have done some additional experimenting with the radio navaids, and have come up with some interesting new results. Apparently, the maximum range at which you can receive the navigation signals from a VOR or NDB depends not only on their type ("HIGH" for VOR/DME's and "HH" for NDB's gives maximum range), but also on the altitude of both the aircraft and the transmitter. In my earlier experiments, the beacons were only 10 meters (30 feet) above sea level. and the aircraft were flying at about 6,500 feet. I got a max range of about 140 nautical miles. In this new experiment, I created a VOR and an NDB at the summit of Mt. Everest - the highest point of land you can get too in both the real world and FS2020. In the sim, this comes out to 8,741 meters, about 28,677 feet MSL, which is actually lower than the summit in the real world, which is 29,035 feet; the DTM that FS2020 is using apparently isn't 100% accurate. The "range" value for both transmitters was set to 199 nm. I then started a flight in the Turbo Bonanza from Lukla, and flew south, on a radial directly away from the transmitters, and climbed to 30,000 feet - just about as high as the plane could get without stalling - and watched the DME and the gauge needles. At 168nm, the needle for the NDB snapped back to the neutral position, although I was still hearing the Morse code audio signal. At 199nm, I lost the VOR/DME signals, and oddly, I was still hearing the Morse code from the NDB, although I was now more than 30 miles past where the navigation signal had dropped off. I flew several loops back and forth to test the range for consistency. The VOR always cut in or out at 199 nm. The NDB cuts out at 168 nm when you are flying away from it, and cuts back in at 164 nm when flying toward it. The conclusion I draw from these two experiments, is that the sim may actually be accounting for line-of-sight and height above the apparent horizon. With the transmitter at sea level, and the aircraft at relatively low altitude, you don't have to get very far away before the transmitter drops below your horizon. With the transmitter and the aircraft both at 30,000 feet, you still have clear line-of-sight between them for about 400 miles before the curvature of the earth would cut off the direct line of sight between them. In reality, it's more complex than this, because radio waves get refracted by the atmosphere and the "maximum range" at which you can hear a radio signal changes from hour to hour. Also, in the real world, I've read that VOR's and NDB's aren't reliable beyond about 100 miles even for the high-power ones. If anyone would like to try this on their own, here's the XML code for placing these two beacons on the summit of Mount Everest. You get two visual scenery objects, a VOR/DME and an NDB transmitter tower from the scenery library, and the radio parameters for the two transmitters. It's created on a fictional airport I call "Everest_Base_Camp", but there's no runway, just the two nav aid scenery objects. Create the new airport in the SDK, using your own name, then open the XML file in a text editor, paste in my code and save the file, then Build it in the Project Editor. If the Console doesn't report any errors, you can then copy the Package to your Community folder, start the sim, and try it yourself. I suggest using a turbine aircraft like the Beech King Air, or maybe the Cessna 208. It needs to have an avionics package that supports NDB/ADF navigation (not all of the planes do). The Garmin G1000 has this, but if you are going to start the flight from Lukla, remember that the runway there is less than 2,000 feet long, and the elevation is something like 9,500 feet. They fly Twin Otters from Lukla, and I was able to fly the Bonanza G36 Turbo from there, although it took a long time to climb to 30,000 feet. Here's the XML code: <?xml version="1.0"?> <FSData version="9.0"> <!--SceneryObject name: OCE_APT_NZGS_VORDME--> <SceneryObject lat="27.98881833921670" lon="86.92376212320278" alt="0.00000000000000" pitch="0.000000" bank="0.000000" heading="-179.999995" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="TRUE" snapToNormal="FALSE"> <LibraryObject name="{3CC5CC14-8178-463E-BC9F-DFE5CDD34AC3}" scale="1.000000"/> </SceneryObject> <!--SceneryObject name: ndb-tower-25m-cbj--> <SceneryObject groupIndex="1" lat="27.98899383407348" lon="86.92390485546913" alt="0.00000000000000" pitch="0.000000" bank="0.000000" heading="-179.999995" imageComplexity="VERY_SPARSE" altitudeIsAgl="TRUE" snapToGround="TRUE" snapToNormal="FALSE"> <LibraryObject name="{78531B6D-0968-4AD8-DBFC-1633590B8E9D}" scale="1.000000"/> </SceneryObject> <Airport displayName="EVEREST_BASE_CAMP" groupIndex="2" groupID="1" groupGenerated="FALSE" region="NP" country="NEPAL" city="EVEREST_BASE_CAMP" name="EVERST_BASE_CAMP" ident="ICAO" lat="27.98881833921670" lon="86.92376212320278" alt="0.00000000000000" magvar="-0.300000" trafficScalar="1.000000" airportTestRadius="22000.00000000000000" applyFlatten="FALSE" isOnTIN="FALSE" tinColorCorrection="TRUE"> <Aprons/> <PaintedElements/> <ApronEdgeLights/> </Airport> <Ndb lat="27.98899383407348" lon="86.92390485546913" alt="8741.0M" type="HH" frequency="0425.00" range="199.0N" magvar="-0.3" region="NP" ident="NDEV" name="EVEREST_NDB"/> <Vor lat="27.98881833921670" lon="86.92376212320278" alt="8741.0M" type="HIGH" frequency="114.950" range="199.0N" magvar="-0.3" region="NP" ident="VREV" name="EVEREST_VOR" dme="TRUE" dmeOnly="FALSE"> <Dme lat="27.98881833921670" lon="86.92376212320278" alt="8741.0M" range="199.0N"/> </Vor> </FSData>

I've been getting deeper into designing custom airports with the SDK and Scruffy Duck's ADE20 editor, and have discovered a couple of things about NDB's. If this info is buried in the SDK docs somewhere, and this isn't "news", my apologies, but maybe it will help someone who is struggling with getting their custom airport to work properly. First off, there's a lot of data on the Internet regarding the "maximum range" of NDB radio beacons. I've seen some documents listing this as 199 nm for "HH" class NDB's, so I tried 199nm as a range setting for an NDB at Howland Island (This was the mid-ocean refueling point that Amelia Earheart and Fred Noonan were trying to get to). It turns out that MSFS 2020's SDK will build a BGL file with a 199nm range for an NDB without showing any compiler error, but when you get in your Cessna 152 and try to fly an NDB approach there, the sim seems to have a max range of 146 nm built in, that overrides the NDB range value in your XML file if you set it to anything over 146nm. As I fly toward this "HH" type NDB, the needle on the ADF gauge swings off of the neutral position and the Morse code becaomes audible in the headphones, right about when Little Nav Map says the distance is 146nm between the aircraft and the NDB site. This was with the Cessna 152 flying at 6,500 ft MSL. I've tried it with the DH2 Beaver, the Cessna 208, and the Beech Bonanza, and the behavior is pretty much the same whether the ADF is a dial gauge on the panel (Cessna 152 and DH Beaver), or it's on the Garmin 1000 PFD (Cessna 208 and Bonanza).

I have been struggling for two weeks to build a custom airport with an ILS for MSFS2020. I used to know how do this in Scruffy Duck's ADE for FXS, 20 years ago, but apparently Asobo has changed things. After several days of frustration, and untold hours spent experimenting with Heading and Magvar settings in the XML file, and researching potential solutions on-line, I have finally figured how to construct this data in the XML file so that the ILS localizer lines up with the runway, and the cockpit instruments (VOR or PFD) work the way they're supposed to. This is a long post, maybe too verbose, but I'm hoping it will help some fledgling MSFS scenery designer who is going crazy trying to get their ILS to work properly. I am going to assume that someone reading this has at least a minimal familiarity with the XML file structure and data syntax used by the Asobo SDK. I have built the minimum possible airport (1 runway, with 1 ILS) to demonstrate how the data in the XML file needs to be formatted so that the ILS works properly. The critical issue is that the Headings and Magvar (magnetic variation) values have to be input correctly, in a specific way, in each section: 1. Before you start on coding your airport, you need to obtain some data: the ground elevation and magnetic variation at the airport definition point (typically the geometric center of the runway, or group of runways. You can't ignore this because the Sim is going to access magnetic variation from Navigraph every time it loads, so your airport coding has to include magnetic variation tags in a few specific places. The easiest to access source for this data is probably Little Nav Map - if you are dabbling with scenery design, you are advanced enough in this hobby that you probably already have it installed, and I'm going to assume that you do. I'll abbreviate it as "LNM" for the rest of this tutorial. Find your preferred location for this airport in LNM, make sure the Map Theme is set to "OpenTopoMap", and place the cursor on the spot where you want to build your airport. Look in the bottom right corner of the screen, and you will see the values for Latitude, Longitude, and (when you stop moving the mouse), the ground elevation. In the cell just to the right of the elevation, the magnetic variation will be shown, to the nearest 1/10 of a degree. Remember that East variation is a negative number, West variation is positive. 2. In the <Airport> section, you need a latitude, longitude, altitude, and region code, but no heading or magvar. While it is possible to put a magvar tag in this section (the compiler won't choke on it), the sim will ignore it since it is using on-line data, I assume from Navigraph, to build in magnetic variation for wherever it is you are building your airport or flying your plane. Note that the airport test radius needs to be large enough to enclose all scenery elements in your airport. If you add something, for example a beacon tower on a nearby hill, you might need to increase the test radius. 3. In the <Runway> section of the XML file, the data for headings and magnetic variation have to be input in a particular way; if you mess this up, the ILS localizer won't line up with the runway, and/or the VOR/PFD indicators on the instrument panel in your plane won't behave the way they are supposed to. The Heading for the runway is measured from True (Geodetic) North. The Runway Number is the first 2 digits of the magnetic heading; for example, if the runway heading is 0°, and the magnetic variation you obtained in step 1 is 12.5° East, the Runway compass heading is 360-12.5=347.5°, so your Runway Number is "35". If the true heading if the runway is 210°, and variation is 8.2° West, you add them to get 218.2°, and the runway number would be "22". Runway numbers are 10° apart, so there are 36 possible numbers, and you round up or down to the closest one. If you want runway numbers that have a leading zero, for runways on magnetic headings between 0 and 94 degrees, add this tag to the <Markings> section: [leadingZeroIdent="TRUE"]. This is the standard for US Military airports, and Civilian airports in some parts of the world. Do not use the <magvar> tag in the Runway section. 4. In the <ILS> section, the Heading will be the magnetic heading of the runway centerline, which you calculated in the last step to determine the runway number. Again, this is the runway's Geodetic (measured from true north) heading, plus the magnetic variation if it's West, or minus the variation if it's East. The <magvar> value will be Variation you got from LNM. Again, don't forget the negative sign if the variation is East. 5. In the DME and Glideslope sections, you don't use either Heading or Magvar tags, but don't forget to set the glide slope pitch to your preferred value; this is usually 3° unless you need it steeper to clear some obstacle like a hill or tall structure in the approach path. 6. In the Runway Start sections, the Headings are Geodetic (true north), same as the Runway, and <magvar> tags are not used. 7. Approachs. For each ILS, there needs to be at least 1 Approach section in the XML file. If this is not included, aircraft autopilots and Flight Plans will not work properly with the ILS. Here is a sample of a 'minimal' Approach for a single runway airport with one ILS. This was generated by Jon Masterson's 'Airport Design Editor 20' software, included here as a sample: ------------------------------------------------------------------ <Approach type="ILS" runway="00" designator="NONE" suffix="0" gpsOverlay="FALSE" fixType="TERMINAL_WAYPOINT" fixRegion="K2" fixIdent="FF00N" altitude="3100.0F" heading="0" missedAltitude="4100.0F"> <ApproachLegs> <Leg type="IF" fixType="TERMINAL_WAYPOINT" fixRegion="K2" fixIdent="IF00N" altitudeDescriptor="+" altitude1="3100.0F" /> <Leg type="CF" fixType="TERMINAL_WAYPOINT" fixRegion="K2" fixIdent="FF00N" flyOver="FALSE" theta="0" rho="0.0N" magneticCourse="348.3" distance="4.0N" altitudeDescriptor="+" altitude1="3100.0F" /> <Leg type="CF" fixType="RUNWAY" fixRegion="K2" fixIdent="RW00" flyOver="FALSE" theta="0" rho="0.0N" magneticCourse="348.3" distance="6.0N" altitudeDescriptor="A" altitude1="1051.0F" /> </ApproachLegs> <MissedApproachLegs> <Leg type="CF" fixType="TERMINAL_WAYPOINT" fixRegion="K2" fixIdent="HH00N" flyOver="FALSE" theta="0" rho="0.0N" magneticCourse="348.3" distance="10.0N" /> <Leg type="HM" fixType="TERMINAL_WAYPOINT" fixRegion="K2" fixIdent="HH00N" turnDirection="R" magneticCourse="348.3" time="1" /> </MissedApproachLegs> </Approach> <Waypoint lat="35.9208932772687" lon="-117.257150799828" waypointRegion="K2" waypointType="UNNAMED" magvar="-11.7" waypointIdent="IF00N"> </Waypoint> <Waypoint lat="35.9875599127261" lon="-117.257150799828" waypointRegion="K2" waypointType="UNNAMED" magvar="-11.7" waypointIdent="FF00N"> </Waypoint> <Waypoint lat="36.2761702887753" lon="-117.257150799828" waypointRegion="K2" waypointType="UNNAMED" magvar="-11.7" waypointIdent="HH00N"> </Waypoint> ---------------------------------------------- 8. Unfortunately, ADE20 is "retired" software. The last version, Alpha_21, is now 3 years old and as far as I know, there was never a Beta Test or Stable Release version. The built-in compiler has never worked for me - maybe it's not compatible with Windws 11? So I have to export an XML file from ADE and use the Asobo compiler in DevMode in the Sim. ADE-Alpha_21 has some significant bugs that produce XML files which can cause compiler errors with the Asobo BGL compiler, but these errors can usually be corrected by manually editing the XML and re-building, until you eventually get a successfully built package that can be copied to your Community folder. In the above section, the 'waypointRegion' tags have to be manually added to each waypoint; ADE20 didn't include them, and the Asobo compiler will throw an error code and abort if they're not there. Actually, there are several ADE20 scenery element types that can cause problems with the Asobo compiler, because it expects region codes and ADE sometimes doesn't include them in it's XML file output. Look carefully at the error listing in the Compiler Console window (this is in MSFS when it's in Developer Mode), and you can usually suss out what the problem is, correct the XML file, and re-compile. It might take several re-tries, each time correcting another glitch or spelling error, or adding a missing data element, but eventually you'll get a clean compile if you persevere. Note that Asobo's compiler seems to be persnickety about "case sensitivity" in element tag naming; for instance [waypointRegion] and [waypointType] have to be spelled exactly as shown, with the 'w' and 'p' in lower case, and the 'R' and 'T' capitalized, or the compiler throws an error code. Good luck! This is a lot of work, but when you finally get it right, and you make that first perfect ILS approach on autopilot to an airport you created, it's worth it!

Using the FS2020 SDK, I have built a new airport at Sawmill Bay, NWT in Canada. This is the site of an abandoned airport built in 1943 to air-lift uranium ore from a local mine to the US for the Manhatten Project. The two runways are clearly visible in Google Earth, as are the roads, and the remains of the nearby airbase buildings. The facility was used for a few years after the war as a fishing and hunting camp, but this operation was abandoned by 1969 due to radioactive contamination in some of the buildings and the soil. So my problem is that Asobo/Microsoft supplied airplanes don't work with the ILS I put in, but the third-party planes I have (that have ILS capable autopilots) do. Specifically, the Asobo planes show the proper behavior on the VOR gauges or PFD - the DME distance, and the Localizer and Glideslope bearing pointers work as you would expect, but pressing the NAV button on the Autopilot just causes the word VOR to flash for a few seconds on the PFD, then go back to ROL or HDG. Pressing APPR has no effect; the autopilot won't capture the glideslope. When I re-spawn the game with a third-party aircraft like the OZX G21 Goose Redux II, the autopilot behaves as you would expect: it captures the Localizer and Glideslope and flies down to the runway threshold perfectly. BTW, the default scenery for this location does not contain any airport data, so there's nothing existing in the Asobo scenery that my airport would be in conflict with. Has anyone else stumbled on this problem or knows how to fix it? I never had Navigraph installed, and I've already tried the Package Reorder Tool to force this airport to load last, but nothing I've tried will fix this. The C-172, Cub Crafter NX, C-208, Beech Bonanza and Baron - all resolutely refuse to work with my Custom Airport ILS's, that work just fine with 3rd-party airplanes. FS2020 is now more than 5 years past initial release date, and it's kind of annoying that bugs like this still haven't been fixed. Or is this not a "bug", but simply a policy that Asobo-supplied planes won't work with Navaids defined in Custom scenery files in the Community folder?

I was just made aware this afternoon that aircraft I "own" in FS2024 can be imported into FS2020. This is significant for me because I've been spending most of my time in 2020 for the last several months. Why? Because FS2024 has been a bit of a disappointment. The enhanced scenery is awesome, sure, but I can't actually use it, because my Radeon RX-6800-XT GPU apparently doesn't have enough mojo, even though it was just 1 step below top of the line in 2023 when I bought it. I've had to turn off or downgrade to "Low", a lot of the graphics settings in FS2024 that work just fine at Medium or High in FS2020. Trying to run FS2024 graphics with the realism set any higher than Medium drops the frame rate to below 20 fps, and drives the GPU fans to max speed, which sounds like an F-18 at full afterburner. I refuse to shell out another $1,500 for an Nvidea 5090 GPU, especially since I'm not certain that my 5 year old mobo and Ryzen 5-3600 CPU would then prove to be another bottleneck. Then there's the issue of problematical compatibility with legacy aircraft and add-on utiliites. Some of my favorite planes and add-ons from FS2020 don't work properly or at all in FS2024; the Touching Cloud DG-808s glider has various glitches in FS2024, for example some of the avionics are dead. Kinetic Assistant doesn't work at all: the tow planes, the glider launch winches, and thermal hotspots are all non-functional in FS2024, and without thermals, the gliders are crippled. Half the time, the tow planes and winches that are built in to FS2024 don't work right - the tow plane creeps slowly along the runway, eventually rolls of the edge into the grass, and just stops there. So I've more or less abandoned FS2024. So the amazing news I got today is that one of my favorite FSX planes, the Grumman HU-16 Albatross (known as the SA-16 to USAF SAR crews), which is part of the FS2024 Premium package, can be imported into FS2020 if you bought licenses for both, as I did. I've flown the HU-16 and the G-111 variant several times in FS2024, and it's a lovely aircraft both to fly and just to look at. It's not fast, being a flying boat, but with the float tanks and drop tanks, it's got the "legs" (fuel capacity and range) to fly all the way from the West Coast to Hawaii, or Seattle to Coast Guard Station Kodiak, Alaska, if you wanted to simulate a long non-stop ferry flight. It's a much larger plane than the G21 Goose, and it handles more "ponderously" if you will, but it has huge flaps and a very low stall speed. It's perfectly stable on final approach at 75 KIAS, even with nearly full fuel tanks, and on a water takeoff, it gets up on the step at about 35 kts, and simply accelerates until it has enough lift to break free of the water at about 80 knots. The modelling is incredible: the interior seats and stretcher racks (in the SAR version) are incredibly detailed. The cabin doors open and close, and you can almost imagine what it would be like to take a ride in the plane if it were real. I flew it for about an hour around Sacramento, CA, made a couple of water landings and take-offs in Folsom Lake, and landed at McClellan Air Park when I was done. What a joy! I also live the OZX G21 Goose Redux II - it's very fun to fly, but it doesn't have the range of an HU-16. Happy Thanksgiving, everyone, and don't forget to return your seat backs and tray tables to their upright and locked positions after you enjoy your Turkey feast tomorrow.

I have solved this problem. It has to do with weight distribution and trim. The location of the wing fuel tanks was placed too far forward in the flight_model.cfg file. This parameter should be -5.382 (fore/aft), +/-10.256 (left/right), 4.041 (up/down), 110.000 (gallons), 0.000 (unusable), and somehow it was changed to -4.0, +/-10.256, 4.041, 110.000, 0.000. This error was making the aircraft nose-heavy, requiring 20% up-trim to maintain level flight: as soon as the autopilot was engaged, the elevator trim would go to 0, and the plane would go into a dive. I shifted the CG further aft, from 27% to 45%, to allow level flight at 0% elevator trim, and now the autopilot behaves properly. I don't know why the aircraft is requiring the CG to be moved aft this much; 45% is a couple feet aft of the trailing edge of the wing, so it's obviously wrong, but where the underlying cause is - probably in the model files somewhere - I can't suss out. Anyway, it's now flyable, except for the radios still having no visible numbers.

I live just down the road from Placerville, in South Sacramento, so now I have a bespoke local airport to explore! Thanks, I'm d/l'ing it now!

One of my favorite planes in FS2020 was the Grumman G21A Goose Redux II, by OzWookie and the OZx team. This project is an FSX import, but unlike many other such 3rd-party add-ons to FS2020, the OZx Goose was amazingly responsive and fun to fly - she felt "alive", in a way that most other FSX imports never did. The skin textures were obviously FSX: low resolution, rivets and screw heads were fuzzy and indistinct, as we all remember from FSX, and the instrument and switch labels were often hard to read. But the engine sound was amazing right from the moment you toggled the starter, until the moment your flight was over, the bird was parked, and you shut 'er down. The OZx team re-created the instrument graphics and liveries in high-def resolution, so you could actually read them without squinting, and everthing was configurable, right down to the load and CG balancing. Flying off land or water, she was gentle, forgiving of mistakes, with enough power to cruise at 148 knots and climb at 750 fpm. She had retractable wing floats, which were added to some existing airframes in the 1950's and 1960's, and this gives the OZz Goose about a 25 knot speed edge over the official Asobo/Microsoft G21 Goose. The OZx Goose is so much more fun to fly! She has an autopilot, which the Microsoft version of the plane lacks, and the sound files are a better rendition of the rumble of the R-985 Wasp Junior engines, than what comes with the Microsoft Goose. Sadly, I have to report that the OZx Goose Redux II has issues in FS2024. Two problems are so serious that they make the plane almost unflyable: The numeric displays on the Bendix radio stack, which are red LED's, are blank. This affects the Nav and Comm radios, the ADF, and the Autopilot (the DME never worked, even in FS2020). But the problem is more serious than no numbers on the radio stack: the autopilot has some bizarre fault: as soon as you press the AP power button, the plane noses down into a steep dive, and doesn't respond to any inputs on the VS Up/Down buttons or elevator trim commands. The only way to recover is to disable the autopilot and re-trim to level flight. And pray that you recovered before passing VNE speed, which is only about 190 knots. I've tried every suggestion to isolate the problem so that (maybe) a fix can be found, including removing all other files from the Community Folder, but this didn't help. There must be something in the plane's autopilot modeling that's incompatible with FS2024. It's a big disappointment, because I love this plane, but I've discovered several other compatibility problems with importing 3rd-party aircraft, these also worked fine in FS2020 but have issues with FS2024. Microsoft/Asobo's claim that "most FS2020 add-ons will work seamlessly in FS2024" seems to be not as reliable a claim as we all hoped. I never saw this behavior in FS2020 - everything worked perfectly except the Bendix DME - the OZx user manual stated that they were unable to make this work, but were hoping to bring it online in a future release. The autopilot always worked perfectly, exactly as it should; I made many ILS approaches in the OZx Goose and never encountered a glitch, except one time, in very bad weather, when apparently the gyro tumbled and I had to use the Increase/Decrease Drift Angle keybind to re-calibrate the gyrocompass. As far as I know, development on the Goode Redux II was discontinued 3 or 4 years ago, when the OZx team began work on a new project, a payware version of the G-21A Goose modelled on the US Navy JRF-6. This model is closer to the WWII Goose, with fixed wing floats, and flight dynamics more or less like the Asobo version.

I just experimented with this too. Started a flight in northern Canada at the Great Bear Lake airport. Setting the environment to -50°F, and the maximum snow depth of 29". The lake certainly looked like snow covered ice, but put a plane on it, and it behaved like liquid water. I tried the Cub Crafter XCub with skis. Rolled as slowly as possible off the lake shore into the lake, the skis immediately sank into the "snow" and a few seconds later the sim generated a crash. Next I tried the XCub with floats, at same location, same environment, The plane rolled down into the lake and floated on the "snow" exactly like it does on water. Made a couple of takeoffs and landings on the "frozen lake", and the Cub's floats and water rudder behaved exactly as they would on a sunny summer day with the lake at 75°F without so much as a single snowflake or ice cube in sight anywhere. I then experimented with the Cub on tundra tires on 29" deep "snow" on the airport runway. In real life, the landing gear would have sunk completely out of sight, but in the sim, the plane was perfectly happy to take off and land on the "snow" as if it was a dry grass landing strip. Oh, there was a big plume of show being blown back by the prop wash, but no other effect on the plane's actual handling or performance. The obvious conclusion is that "snow" in FS2024 is just a surface visual effect with no actual depth. Water doesn't freeze into ice no matter how cold you set the environment, except that your pitot tubes and carburetor will clog up in icing conditions if you don't have pitot and carb heat on, the windshield will frost over, and you might completely lose control of the aircraft if the wings and control surfaces ice up too much. Don't fly through thick clouds in cold weather: that will generate ice on your place, but water sitting on the ground doesn't freeze no matter how clod you set the weather to.

For all of you who loved flying the SA-16/HU-16 in FSX, and have been eagerly looking forward to flying the new version in FS2024, I have a real-world story to tell about this airplane. Back in the 1990's, I was working for CalTrans Office of Structure Design as a drafting tech, and had a co-worker who had been in the USAF from 1950 to 1972, retiring as a Major. After basic basic pilot training, he got an opportunity to train in the SA-16A as a SAR (Search and Rescue) pilot. This training was in Florida, and the students flew the aircraft out of a base near Lake Okeechobee, using that base to train in landing and taking off from water (the lake was great for training because it was almost always calm, and being a freshwater lake, the aircraft were not exposed to as much saltwater corrosion). After graduation, he was posted to a SAR squadron in southern Greenland, at Narsarsuaq AB; this base had been built in 1942 and was first called "Bluie West 1". The specific mission for this squadron was to respond to emergency ditchings of USAF or US Navy aircraft flying between St. John's or Gander in Newfoundland, and Kevlavik or Reykjavik in Iceland. Fighter jets being deployed to England or Germany, or returning to the States from Europe for factory repairs or modifications, would be loaded up with ferry tanks, and make these flights on their own - my friend told me that land-based Air Force fighters were not designed or equipped to be transported as deck cargo on a ship, although that seemed to me to be a safer and less risky way to move a fighter between North America and Europe. It was risky for the pilots, as there was always the possibility of a catastrophic mechanical failure that might make the aircraft unflyable, in which case the pilot would have to ditch, or bail out and parachute into the water. But this was the height of the Cold War, and military aircraft needed to get wherever they were needed as quickly as possible. So pilots were tasked to fly the planes across the North Atlantic as long as the weather wasn't unacceptably bad. An emergency ditching never actually happened during the 2 years that my friend was in that squadron at Narsarsuaq (1953-1954), but they trained several times every month, whenever ferry flights were passing by southern Greenland, to fly the 100 mile long fjord between the coast and the air base, in every kind of weather including zero-visibility dense fog, knowing that there were 3,600 foot mountains on both sides of the fjord waiting to claw them out of the sky if the flight crew made a navigation error. They would then patrol along the route of the ferry flights, just in case. In theory, the SA-16 could land and take off again in waves up to 10 feet high, but my friend told me that the roughest sea conditions he ever actually landed in were 5 foot high, long period swells, and the plane was barely able to get back in the air without being battered to pieces. In the North Atlantic, the weather and sea conditions are hardly ever less than "very rough", and my friend told me that the chances of actually being able to get to and rescue a downed fighter pilot before he died of exposure or drowned in that freezing cold water were slim, but the effort had to be made. So any time you fly the HU-16 in FS24, maybe you'll remember this little story, and it will add something to your appreciation of the effort Asobo's developers put into creating this sim model.

I've test flown both in the last couple of days. The only differences I've been able to spot: 1. The basic airframe and powerplant are the same for both. One is in the livery of a Coast Guard HU-16E, serial number 7399. However, this livery is incomplete: there should be a banner: "COAST GUARD" painted in large black letters both sides of the fuselage, and it isn't on either side. There are some other oddities about the livery than I can't put my finger on, but there is a real HU-16E in Santa Rosa, California at the Pacific Coast Air Museum, #7245 "San Francisco", and there are several elements of the paint job on that aircraft that are missing from the livery of #7399 in the sim. On the interior, the seats are old-style, with low backs, steel tube frames, very Grumman 1950's looking. The flight deck is mostly steam gauges and toggle switches. Both aircraft have Curtis electric propeller hubs, so the pitch control is by a pair of two-way toggle switches, instead of the big pitch control levers I was expecting to see, like you get on the G21 Goose. 2. The first thing you notice about the G111 variant is the lack of the dual 295 gallon drop tanks, This loss of 590 gallons of fuel capacity puts a serious dent in the maximum range of the G111, but on the interior, you get a glass-cockpit flight deck. The livery is ambiguous - I assume this aircraft's livery was modelled after a G111 in private ownership somewhere; it doesn't seem like a Military livery. The interior passenger cabins of both of these aircraft, behind the flight deck, are the same: nicely textured and accurately modelled; mostly empty space, but you can really see that the Albatross is way bigger than the G21 Goose. They are both fun to fly, and easy to operate off land or water. Very good visibility out of the pilot's seat, but be sure to use the noise-cancelling Headphone Simulation option; those two R-1820's just a few feet away are deafeningly loud. There is a switch on the panel labelled "Anchor Light", and the real Albatross did in fact carry an anchor, as did it's smaller nestmate the G21 Goose, but as far as I could tell, there's no actual anchor in the sim model. This could be significant if you land on the water, in a lake or river for example, and there's some wind blowing; the aircraft will drift downwind if you've shut it down to go exploring "on foot" - a passtime that actually means something in FS2024 with it's stunning ground and vegtation texturing.

I run 3 monitors. A 28" 4K monitor in the center, flanked by a pair of older 26" 2K monitors. This setup wasn't originally intended for flight simming, although it's good for that purpose; I started running dual monitors nearly 30 years ago, at CalTrans, with Bentley MicroStation CADD back in the late '90's. Every civil engineer or draftsman I know long ago gave up on single monitors, as soon as graphics workstations became available with the ability to run dual (or more) monitors. When you are trying to juggle a plan view, profile view, orthometric views, and maybe a half-dozen detail cuts into some complex structure like a highway bridge, having to do this on a single monitor is like putting yourself into a straight jacket and trying to play golf. Once you've done any kind of technical work on a PC with 2 or more monitors, you would rather shoot yourself in the foot than go back to a single-monitor PC. Even my partner, a retired accountant, felt that her productivity using Excel and the FisCal Accounting software was improved on dual monitors.

Your profile says you live in Yukon. That made me think, someone should make a set of Buffalo Airlines liveries for the DC3, CL-415, Lockheed L-88, and the C-46, if there actually is a C-46 available for MSFS, with Avatars of Joe and Mikey to go with them! Humor aside, my experience with FS20 was the same as yours: it was more than a year before I could get through an 8 hour flight in the 747-8i without a CTD, although landings in San Francisco in any of the big aircraft with approach and touchdown speeds around 140 knots were still dicey for another year after that, if you pushed the sim to the limit by having it be raining, too.

That's what I keep telling myself. One good experience I had is that in several hours of testing yesterday and today, the sim never threw a CTD at me - the #1 issue that plagued FS20 for more than a year, and that might have caused me to stick with FSX, except that I had already dropped US$750 for an AMD Radeon 6800 XT GPU, which is totally overkill for FSX. A couple of other observations: When you are out of your plane and walking around an unpaved area, the grass and wildflowers are amazingly detailed, and the plants sway gently if there's any breeze blowing, but the colors are wrong - fuzzy and muted somehow. In the mountains, if there are Ponderosa or Lodgepole pines in the area you are walking your avatar, they look amazingly detailed right out to the tips of the branches, and exactly like pine trees. The green color of the needles and the reddish brown of the branches and trunks is pretty close to the real thing. And from the middle of a clearing surrounded by pine forest, you can see that there's lots of variation in the trees, just like there should be. It all looks great, if not a bit "too" perfect. "Is it Live, or is it Asobo?" to steal an old Memorex cassette tape TV advertisement from about 40 years ago. I need to jump around more, explore more of the virtual world in this sim at different seasons, before settling on a final opinion, but in the area of the central Rocky Mountains where I've been flying, the ground colors aren't quite right from altitude. The valley bottoms along river courses should be more green and less gray, even in early winter, as it is now, and the mountainsides should be more varied in color - everything from gray granite, to orange sandstone. And I can't understand why the air looks so smoky and hazy when there is no wind blowing, and the condition setting is "Clear Air". Mountain air in Colorado is crystal clear, with unrestricted visibility of up to 50 miles as long as there aren't any forest fires burning. Maybe this sim actually models fire smoke? BTW, I got to visit Wellington once - we spent most of the day at Te Papa - a truly awesome museum, and I was amazed and gratified to see the care your curators put in to the collection of land survey gear - most of my fellow Americans that aren't Civil Engineers or Land Surveyors would walk right past that display with hardly a glance. That's what I did the last 7 years of my career, albeit with modern electronic theodolites (Total Stations) and GPS gear. I also walked up to the top of Mt. Manganui when we were in Tauranga, and saw the big Geological Survey Control Monument at the summit. We have similar installations in the States, but much smaller: they are generally a heavy steel pipe concreted several meters deep into the ground, with a full time GPS receiver and Geodetic grade antenna bolted to the top of the pipe under a plastic weather dome, and powered by an adjacent solar panel and batteries.

It took me about 24 hours to break through the first-day installation logjam, but I finally got in the air, for a test flight in my two favorite FS20 planes, the Cub Crafters NX Cub (the one with tricycle gear), and the Beach G36 Bonanza. But right away, I ran into problems - not unexpected in a new release, but these problems left me wondering if Asobo even tested all of the planes before shipping the product. The worst problem with the NX Cub you won't notice in the daytime, but at night it makes the Cub unflyable: the light output from that huge Garmin MFD screen is so intense by the time full darkness arrives, that the pilot is totally blinded, and I couldn't find any way to tone it down. The only way I could land the plane was to scrunch my eyepoint way up at the ceiling as far forward as the cockpit bounding box would allow. There's also a bug in the electrical system config file somewhere, that even with the Master Battery Switch and Avionics switch turned on, and the plane actually flying, the sim is certain that the electrical system is turned off, and it won't let you call ATC (shaking my head here). This plane works perfectly in FS20; what the hell did Asobo do to the plane's model and config files to bollix it up? You can fly it, (but not at night), and only if you don't get a weird feeling just taking off or landing somewhere without making a radio call to anyone. I've never been a "real" pilot, but even I know better then that. One other problem I noticed is that some of the electrical switches that do work in FS20 are "inoperable" in FS24 - including the landing light and pulse/steady switch. There's one other inop switch, the IGN battery power switch, but since the plane flys okay, it must not be essential. Now on to the Beech Bonanza G36. The problem here isn't with the plane itself, it's with Asobo's assurances to us that "most" 3rd party add-ons in the FS20 Community Folder would transfer directly over to the FS24 Community Folder. Umm, no, they don't. I very specifically made sure that my G36 Turbo add-on got copied over. This add on boosts manifold pressure to around 36" at altitudes up to about 7,500 feet, and boosts the service ceiling to about 24,000 feet. Not realistic I know, unless you want to pretend that you've got an O2 system installed, but for flying in and out of high mountain airports in the Colorado Rockies, or exploring steep canyons, it's nice to have the extra power. Anyway, it's obvious that the FS24 game engine is ignoring at least some of the add ons in the Community folder. On a climb out of KRIL (Rifle-Garfield County Airport, elev. 5503', I could only get 20" of manifold pressure, and the plane could barely get out of it's own way after I hit 12,000 feet. A couple of other observations, before I close up: The key bindings that come with the game for my joystick and keyboard are completely at variance with what I've been used to since FS 2004. I'm going to have to re-program all of them - and so will you if you got used to FSX keybindings and carried them over to FS20. It's crazy: There are dozens of keys that Asobo has bound, 3, 4, even 5 different functions to: you might be trying to lower flaps, click on Joystick Button #4 (for example) and sudden have the engine flame out, because there's also a Cut Throttle keybinding on that button (what were they thinking of?!). This drove me crazy until I saw posts on the Microsoft MSFS Forums where a bunch of other people had crashed on their first FS24 flights before discovering these multiple keybindings.