1. Right Click on Start an go to Settings\System\Display\Graphics

 A. Confirm Optimizations for Windowed Games is Enabled
 B. Hardware Accelerated GPU Scheduling is Enabled

2. Install the latest Nvidia Graphis Drivers - Perform a Clean Install

3. Install the latest Nvidia App

4. Open Nvidia App

 A. Select Settings
 B. Ensure Nvidia Overlay and Game filters and Photo mode are Active
 C. Next go to the About page and activate the "Opt in to access beta or experimental features"
 D. Next go to Graphics/ Global Settings
 E. Look for Shader Cache, set the size to your preference, turn on the Automatic Shader Compilation (beta)
 F. Left mouse click the three dots (upper right corner), select clear cache and then Compile now (beta)
 G. Close Nvidia App

5. Install Nvidia Drivers 566.36, Do Not Install Any Options Other Thank The Drivers

 A. Perform a Custom Install
 B. Check the Perform a Clean Installation checkbox

6. Run MSFS2024 and you should have all your filters available for use.

I noticed with the latest updates that Pop Out Panel Manager wouldn't pop out all my glass screens, at best I'd get three out of four. To get around this issue I found that if I offset the "Identity" location to the lower right side of each of the glass screens and saved those locations, all panels now pop out. Putting the identity in the center of each display doesn't see to work as advertised.

Sunday is Simday!!

If you like the SWS PC-12 then you will want to check this out!!

Linked in the Video is the EFB Add I have been working on. 

Enjoy!

https://youtu.be/V4onxOB1_uA

WT21 / CJ4 Navigraph Plugin Updated.  Now supports 2020 (still need to bind charts button in hardware but plugin will now parse the route and display charts.)

Implemented retaining EIS and Data Bar when Charts are open.  Fixed PFD H events being captured.  Added improved Menu Navigation, Logout support and QR Authentication support.

https://youtu.be/__isw2nF-v8

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>

 

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 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!

It might be a common misconception that you can't fine tune views w/ the default camera system.  I was perplexed by this too until a few months ago, which mostly affected my main frontal pilot view, primarily because I found it nigh to impossible to center HUD display in its HUD frame.  Turns out it's super simple to fine tune it or any view:  the trick is to 

1. Open the Camera interface from the dropdown toolbar
2. Move the Freelook Speed slider down to a very low speed, 5 or 10.

Now you can you your default motion keys (Shift+ A, S, D, Q, E) in fine increments.  When happy, simply hit Ctrl-Alt+# to lock it in.  Then can put the speed slider back to its default, or leave it for future adjustments.

As a side point as some are not aware of this reality in 2024:  one can change any controller setting while in flight, that is without the need to hit Esc to get to Settings.   The Console Controller icon in the toolbar drop down gets you into the controller interface where you can make any changes and the changes are automatically saved upon closing the interface.

Both of these were touted by one user who recently picked up ChasePlane for 2024 to be significant reasons he is enjoying Chase Plane so was surprised to learn, I believe from his replies, these already exist in the default camera system.

Enjoy

First time using surround you have to set it all up manually. After that Cntrol Alt S will turn surround on and off quickly (if you have left that box checked).

Quirk: On my system toggling surround off will turn off all monitors except one. But Windows Display settings (right click on desktop) will allow you to extend the display across the screens and that will turn on all the monitors with one click. And surround will be off and all monitors back on.

Cntrl Alt S will turn surround back on quickly when desired. 

Quite a number of people have made suggestions - and I have scoured all over for an answer - even those put forward by Microsoft would not help me

For the record - yesterday - I came across a suggestion that changing the "Host" - whatever that means? - might fix this problem faced - by others before

I followed the attached URL ------  and 2024 -- loaded straight away in 30secs for the first time👍

How to reset the Hosts file back to the default - Microsoft Support.

https://support.microsoft.com/en-us/topic/how-to-reset-the-hosts-file-back-to-the-default-c2a43f9d-e176-c6f3-e4ef-3500277a6dae 

YeeeHah !!!!!

The next week was a snap, crackle, popping mess of sound and stuttering.

Today I uninstalled 2024, completely,  <b>deleted my appdata folder </b> for msfs 2024, cleared the rolling cache and shader cache and reinstalled it all.

Stuttering and crackle noises are gone and it is running even smoother than the beta.

So, yes, Virginia, uninstall IT ALL.

i had deleted the cache before this update I saw this morning wanted to be installed

Nice varied scenery with many challenging landings in confined helipads. The locations are in the Reunion Island...Saint-Paul...Saint-Pierre near Madagascar.

I think the helipads are part of the following freeware addon, or something similar at flightsim.to:   reunion-megapack 

https://youtu.be/RLc1_fKEXQs

1: click the ships wheel icon

2 Fill in four boxes with file paths for each sim you want to use: 4 for msfs 2024 store, 4 for msfs 2024 steam, 4 for 2020 store, 4 for 2020 steam, 4 for DCS, 4 for PMDG, 4 for some sort of Falcon Sim.

Unfortunately Winwing does not tell you which 4 filenames to search for in order to type in the correct path to those 4 files.. But it dos show you some popular standard locations. Using those as clues, I had to guess the files they wanted the paths for. You type in the path of the first file on the top line. But there are 4 of them. As you start entering the paths starting in from the top line, some of them below will populate by themselves, saving you some time. 

The images below are just the suggested locations provided by Winwing, apparently for default installation locations. You may need to change them for every sim, 4 new locations.

After I did this once, then the panels always light up when in a plane that Winwing supports.

The official msfs 2024 Controller Settings FAQ

Tip of the day: assign SHIFT-C also to QUICK PREFLIGHT! 

(If you use another key to get into the plane then assign that same key to this new function. Duh.)

So: you start a flight, click on Ready to fly and then simply hit SHIFT-C to 1. remove all chocks etc. and 2. get into the cockpit in one go! Just tested it a few times and it works like a charm.

Note that the QUICK PREFLIGHT option only does its thing at the very start of the flight: pressing it again (and again) won't do anything anymore. It's not a toggle or something. So after skipping these (according to some) unwanted and unneeded steps you still can use SHIFT-C all the time to get in and out of the plane. No problem at all.

.REG files are just text files created in notepad that run a batch (.bat).

You should create the 3 lines of text in both .REG files (on/off =000000000/00000400

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\NGXCore]
"ShowDlssIndicator"=dword:00000400

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\NGXCore]
"ShowDlssIndicator"=dword:00000000

To use, open file explorer and click one of the two .REG files you made, for instance the two I made (to which the red arrows point). And then start up MSFS. So you don't have to go editing the registry keys manually, a single mouse click does all the work to show or hide the text.