lgcharlot

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.