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.

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.

I have managed to capture a video clip of my new CL-415 making a water drop, from a custom camera located below and aft of the plane. With no known keybind to open the drop doors, this wasn't easy to do, but I managed to catch all but about the first 1/2 second of the drop. It's a pretty good visual effect, considering that the CL-415 isn't a native MSFS-2020 plane. I can't wait to get MSFS2024 next month, but my enthusiasm is also somewhat dimmed by memories of 4 years ago, when we all struggled for months on end with the seemingly never-ending memory faults and Crash-To-Desktop bugs that plagued the initial release of MSFS2020. Being an early adopter of almost any software nowadays seems to mean that you are an unpaid beta tester for at least the first few months. Anyway, this CL-415 is a fun airplane to fly, about as fast as the Grumman Goose, and it's easier to land because it's got tricycle gear and thus won't ground-loop like the Goose does on occasion. The surface textures are stunningly detailed, both inside and out.

The plane arrived in my Content Manager this morning! I test flew it for about an hour, out of Comox, BC (CYQQ), including a water pickup and drop. First impressions: 1. The CL-415 is pretty easy to fly. Takeoff and approach/landing no more difficult than in the Grumman Goose or Cessna 208 Caravan. It has plenty of power, and taking off with full fuel and water tanks is no strain, just use 10% flaps and about 10~15% up trim. 2. There's no autopilot, so all flying is manual. If you are simming a long ferry flight, it can be tiring. The CL-415 is not as unstable as a P-51, but not as stable as a Cessna 172 either. You can fiddle with the power and trim controls and get the plane to settle into level flight, but it won't stay there very long. Any little wind gust will tip it into a shallow turn, and it won't level out on it's own, you have to be actively controlling it all the time. Think "helicopter", but not nearly that unstable. 3. All of the exterior and interior is modeled in unbelievable detail: every rivet from the nose to the tail is there, both inside and out. Most of the things that are moveable in a real plane aren't operational (cabin doors don't actually open and close), but maybe this will be upgraded in the future. There's even a boat hook and boarding ladders clipped against the port side of the cabin in back! 4. To execute a water drop, you first have to extend the scoops - there's a switch for that - land on the water and let the tanks fill, take off again, retract the scoops, then Arm the drop doors with another switch. To open the doors and make the drop, there's a button on the yoke clearly labelled "water drop". If there are keybindings to do this from the keyboard hotkeys, I couldn't find them. I wanted to watch the water drop from External or Showcase view, but couldn't figure out a way to be in Exterior view, and push the drop button on the yoke at the same time. Maybe by opening an auxiliary view window it could be accomplished; I'll try it tomorrow. 5. The CL-415 has very forgiving stall characteristics for such a large twin. A power-on stall sounds the horn and the plane mushes down, but doesn't fall off on either wing into a spin unless you do something really stupid like deliberately mash the rudder full over. Just push the yoke forward; the node drops and she goes back to level flight with no fuss. Power-off stalls are more dangerous; one or the other wing may lose lift suddenly and the plane will start to spin, but recovery is fairly easy. 6. Visibility out of the cockpit is remarkably good. 7. Ground handling is very smooth, controlling the plane while taxiing is easy. The landing gear has a quite wide stance considering that it's similar to a Grumman Albatross or Goose (folds up into the fuselage instead of into the wing or engine nacelles). Turning sharply at any speed faster than about 10 mph will tip the Goose over and you'll bang a wing into the ground - this isn't a problem with the CL-415. It takes corners on the ground with considerably less drama than the Goose or the JRM Mars, if anyone reading this ever flew the Hawaii Mars in FSX. 8. Power management is easy. There's a digital bar-graph display for torque, ITT, and propeller rpm that's clearly marked with red. yellow, and green zones. Just set your propeller pitch to keep in the center of the green zone, and use your throttles to get the power you want. 9. To shut down at the end of a flight: Pull the prop pitch levers all the way back - this cuts off the fuel, then on the overhead panel, find the battery and external power switches and turn them all off. You should get the end-of-flight dialog box as long as you are on an actual runway. As with other seaplanes in this sim, taking off and landing from water or ground other than official runways may not give you credit for a takeoff/landing.

Thanks! I just checked the Content Manager; the plane isn't there yet, but now that I know where and how it's supposed to be delivered to me, I'll check for it again over the weekend and it it's still not there by Monday, I'll send the ticket to Zendesk. s

I just "released the parking brake" and did the pre-order for MSFS-2024, premium deluxe edition. According to the website: "Microsoft Flight Simulator 2024 — available for pre-order today on the Microsoft Store — will launch in a variety of editions on November 19, 2024, and the Standard Edition will be available day one with Game Pass. All pre-orders will receive the De Havilland Canada CL-415 firefighting aircraft to use instantly in Microsoft Flight Simulator (2020)...." Does anyone here know what else I might need to do to actually receive this pre-order bonus? I did the transaction yesterday, 24 hours ago, but have not yet received the aircraft. When I logged into the sim a few minutes ago, it downloaded a sizeable update, 2 gB more or less, with several patches to the Pilatus PC-6 and a couple of the other planes, but nothing new. Is this CL-415 going to come as an add-on, that I have to manually drop the files to the Community folder? Has anyone done a pre-order and actually received this bonus, and if so, in what form? Thanks!

My hardware is barely good enough to run MSFS 2020 at "high" graphics quality and still maintain 30 fps; "Ultra-High" drops me below 16 fps, and that's at only 2K resolution. I don't understand how anyone is running this sim in 4K, although I've seen videos on YouTube of MSFS-2020 flights that were recorded in 4K. I can see by the performance graphs in Windows Task Manager, that my Ryzen 5-3600 CPU has more than enough processing capability, and I have 64gB of DRAM, so the bottleneck is in the GPU. It's a Radeon RX 6800 XT. It was one step below the top-of-the-line when I bought it in 2022, and cost me $750, more than half the total cost of the system hardware, so I can't just dump it and drop another $900 on an RX 7900 XTX card. And looking at the specs on that card, it's got only about 20% more compute units, so it's not a huge improvement over what I've already got. If, as I suspect, MSFS-2024 is going to require a top-of-the-line GPU, then I won't be interested in purchasing it until I am ready to build a new system, and that won't be for at least 3 or 4 more years, unless my current GPU fails for some reason. The one thing that might tempt me: If Asobo were to implement multi-view windows like FSX had, and the ability to easily build custom instrument panels, like FSX had. I wasreally disappointed when MSFS came out, that there so many features that FSX had that were dropped in MSFS. Not to mention that some of my favorite planes - the Grumman HU-16 Albatross, Cessna C-182RG, and Martin JRM Mars - have never been ported to MSFS.

I have just completed a couple of hours of network data testing, using MSFS v.1.37.19.0, Little Nav Map v.3.0.9, and Kinetic Assistant v.0.17.3.0. I installed MSFS in Sept. 2020, and have logged about 657 hours flight time. Not a lot compared to some of you, but enough that I have established what game settings I like. My system has an AMD Ryzen 5-3600 6 core CPU, the GPU is an AMD Radeon RX-6800-XT, and I have 64 gB of DRAM installed. The GPU was 1 step below top-of-the-line when I bought it 2 years ago, but it can't quite run Ultra quality graphics mode, even in 1920x1080, and still maintain 30 fps, so I have the game graphics mostly set to "high", with some of the less important things like grass and bushes disabled. I'm not complaining - MSFS graphics are still light-years better than FSX even at "high" instead of "ultra-high". I have always been a little concerned about network data overage charges from Comcast, especially since home entertainment is shifting ever further away from movies on DVD and BluRay disc, to Streaming. So I loaded my NetWorx speed meter/recorder. started a flight, and made some recordings of the network traffic consumption to share with the community here. ---------------------------- Flight Test 1: DG-808s Glider (from Alex Marko at TouchingCloud). Region, Central Nebraska, average IAS 80 kts, average altitude 14,000 ft AGL. Big World Graphics and Photogrammetry disabled. Little Nav Map set to use Open Topo Map. Kinetic Assistant active with 2085 Hotspots enabled for thermal updrafts (CONUS and Southern Canada coverage). Elapsed time of recording: 00:36:57 Received 21.0 MB Sent 2.93 MB Total Data Transferred 23.9 MB ----------------------- Flight Test 2: DG-808s Glider: Region, Central Nebraska, average IAS 80 kts, average altitude 18,000 ft AGL. Big World Graphics Enabled, Photogrammetry Disabled. Little Nav Map set to use Open Topo Map. Kinetic Assistant active with 2085 Hotspots enabled for thermal updrafts Elapsed time of recording: 00:36:57 Received 202.0 MB Sent 10.4 MB Total Data Transferred 212.0 MB --------------------------------------- Flight Test 3: DG-808s Glider: Region, Central Nebraska, average IAS 80 kts, average altitude 16,000 ft AGL. ALL on-line functionality Disabled, and Little Nav Map set to use Off-line background Map. Kinetic Assistant active with 2085 Hotspots enabled for thermal updrafts Elapsed time of recording: 00:36:57 Sent: 1.38 mb Received 21.8 MB Total Data Transferred 23.2 MB ------------------------------------- Flight Test 4: DG-808s Glider: Region, Chicago, IL., average IAS 75 kts, average altitude 3,600 ft AGL. Low-Altitude overflight of Downtown Chicago and suburbs (dense, Urban scenery), landing and re-launch at Chicago-Midway, and final landing at Chicago Executive Airport. Bing World Data Active, Photogrammetry disabled. Kinetic Assistant active with 2085 Hotspots enabled for thermal updrafts, LNM active and using Open Topo map. Elapsed time of recording: 00:36:57 Sent: 17.2 mb Received 395.0 MB Total Data Transferred 412.0 MB Conclusions that can be drawn: 1. During the 37 minutes of each of these four tests, comparing the results against each other, it can be inferred that Windows itself, and various background apps unrelated to MSFS and Little Nav Map, were drawing about 627kB/minute. 2. Subtracting the 627kB/min background app usage from the totals, Test #1 implies that Little Nav Map was drawing about 19kB/minute worth of Open Topo Map tiles from the OSM server. 19kB/min is insignificant and I can quit sweating about LNM's data usage. 3. Test #2 and #4, with Bing World Graphics turned on, is the data usage of most concern: Subtracting the 627kB/min for background apps, and the 19kB/min for LNM's use of Topo map tiles, the data indicates that on flight #2, at high altitude over rural terrain, MSFS was downloading 5.084 MB/min worth of aerial photo tiles from the Bing server. On Flight #4, at low altitude, in a large Urban area with very dense and detailed scenery, MSFS was downloading 10.49 MB/minute from the Bing server; this is 629.4 MB per hour of flight time, so 158 hours of flight time in an urban area, would add up to about 100 GB of scenery data. That's 39 hours a week of flying MSFS, and I doubt that anyone has that much spare time - I sure don't. So I guess I can quit worrying about going over my Comcast monthly data cap.

I've just spent a couple of hours trying out the last of the amphibious planes that I had not tested out previously: the Pilatus PC-6 on floats. I've now spent at least 1 hour flying all of the amphibious planes that come with MSFS, and one that I downloaded from a third-party site. There's the Zlin Shock Ultra, the DHC-2 Beaver, the Cessna 172, the Pilatus PC6/Turbo-Porter G950, the Icon A5, the Hughes H4, the Grumman G21A Goose (Asobo), the CubCrafter X-Cub, and the one I downloaded from Flightsim.to: OzWookiee's Grumman Goose G21A Redux II. This is a high-quality port of the Goose from FSX. The exterior textures have that "fuzzy" quality so common to FSX imports (for example, rivets and other small details), but most of the instrument gauges look quite sharp. The main differences between the G21 Redux-II and the stock Asobo G21, are that the Redux aircraft has 3-blade props, and the floats retract to become the wingtips - this gives the aircraft about a 30-knot sped advantage at normal cruise power settings. The Redux-II is stated to be modelled more-or-less on a 1943 US Navy JRF-5, of which 184 were built. A search of the Internet shows that at least 1 airframe very similar to the Redux-II Goose, was still flying sometime in the 1970's, out of Milne Bay, Papua New Guinea. A bunch of photos of it can be seen here: https://www.net-maquettes.com/pictures/grumman-g-21-goose/#bwg979/71351 This airframe has the 3-blade props and the retractable wing floats. In my opinion, it's more fun to fly than the Asobo Goose: the engine sound file is way better than Asobo's, and the flight performance seems better, although both are supposed to have the 450 hp engine. Apparently, a few G21's were produced, or later modified, that had the "SC-G" variant of the R-985 Wasp Junior engine, that could produce 525 hp for climb, and 600 hp for up to 4 minutes for takeoff. I modified the config file to simulate this engine, and the plane felt overpowered and "unrealistic", so I dropped it back to the stock 450 hp. One of the problems with the float planes, is that as far as I can tell, none of them have fully functional animation of the landing gear and water rudder. Some of them are rendered with the landing gear "up", and others with it "down". On one of them, the DHC-2 Beaver, hitting CTRL-W when you have an exterior view, does show the water rudder going up and down. Where this is a problem, is that if you use Exterior views while setting up to land, it's confusing to see the landing gear "down" when you are getting ready to land on water, or "up" on a normal runway approach. Clicking the "G" key or your joystick button that's been set to toggle the landing gear, isn't going to help - you won't see the gear move, forcing you to pop back into the cockpit to check on the gear condition switch, lever, or annunciator. I wish Asobo would fix this. So which is the best amphibian? There are two general categories: the small, 4 cylinder planes like the CubCrafter, Zlin Shock Ultra, Icon A5, and the Cessna 172, and the heavier-lift planes like the Pilatus PC-6 and the Goose. If you like to be as realistic as possible, and pretend that this sim is the real world, and you would personally have to pay for the fuel, the Pilatus has by far the highest fuel consumption, 48 gallons per hour at 108 knots at 5,000 feet. You can bring this down a bit by flying up near the service ceiling, but if this was the "real world", everyone on the plane would have to be on oxygen, and somehow, I kind of doubt that float planes ever fly at 24,000 feet. At that altitude, the engine would be burning maybe 36 gallons per hour, and the ground speed would be 190 knots. The Goose Redux-II burns less fuel, it's 40 knots faster than the PC-6 at normal cruise power and neutral elevator trim, and all of the landing gear and wingtip/float animations work. And it's got much larger fuel tanks than the Pilatus, and about double the range. Just be careful when landing on a runway, to slow way down before making turns: the landing gear track is very narrow, and the plane will tip over and damage your wing if you whizz through taxi turns going faster than about 15 mph. Also, the Goose is a tail dragger, so be gentle on the brakes when coming to a stop so you don't slam the nose into the ground. One other difference between the Redux-II and the Asobo versions of the Goose: The Asobo plane has a user-selectable lock/unlock switch for the tailwheel caster. The Redux-II doesn't have this, but it behaves as if the caster is locked. The Asobo Goose is twitchy and very easy to ground-loop, whereas the Redux-II Goose doesn't have any noticeable tendency to ground-loop, yet it still steers with the rudder pedals like any plane with a steerable rear wheel. This isn't actually accurate, because the "real" Goose, all versions, had a castering tailwheel, and you had to steer it on the ground with either the engines, or differential braking. For the small amphibians, I like the X-Cub best, It's easy to fly, and has a very nice glass cockpit. The C-172 with the G-1000 cockpit is also a good choice; it's a little faster than the X-cub, and it has seats for 4, but 25% higher fuel consumption. The Zlin Shock Ultra has crazy-low STOL capabilities, even on floats. With half-flaps set, and 25% up-trim, it will lift off the water at 30 knots and actually fly, if you are careful to not stall it. You could fly the Zlin onto and off of really small lakes that none of the other amphibs could possibly operate from, but there's no glass cockpit, no autopilot, the fuel tank is very small, and the Zlin is the slowest of all of the amphibs, with a VNE of only 99 kts (114 mph). It's fun to fly around a small area and practice STOL maneuvers, but be very mindful of your speed - the Zlin will break up in flight if you pass that VNE by more than a couple of percent, and it's easy to do in the float plane version if you pull off the power too abruptly without sufficient nose-up trim. The drag of the floats will yank the nose down, and the plane will accelerate past the VNE before you can react to correct the problem. All of the float planes need a lot of up elevator trim, but the Zlin has the lowest VNE and is the easiest to destroy by overstressing it with too much speed in a dive.

I really wanted this to work, because the in-cockpit viewpoint restriction has been driving me crazy for 4 years, but I just tried this with the DA-62 and it doesn't work. I still can't move the eyepoint outside of the cockpit. I changed the Model.cfg file as shown in the example and re-booted the game, but there was no effect. Still restricted. The only method I've found that works, is to define eyepoint cameras outside of the cockpit in the camera.cfg file. Also, when you change these two lines in the model.cfg file to "false", it messes up something in the Showcase/drone camera system, and the W/S/A/D/R/F keys no longer work for moving the drone camera.