How do I add navigation aids to a custom MSFS airport?

To add navigation aids to a custom Microsoft Flight Simulator airport, define each ILS, VOR, DME or NDB in SDK facility XML, include that source in a BGL asset group, and rebuild the package. A placed antenna model is only scenery; it does not create a tunable signal or FMS navigation record.

What counts as a navigation aid in MSFS?

Microsoft Flight Simulator stores radio facilities, instrument procedures and visible airport objects as separate data. The distinction matters because adding a beacon, antenna, PAPI or approach-light model will not create radio guidance.

How do I add the navaid with the MSFS SDK?

The reliable method is to add facility data to the airport project's XML source and compile it into the package's BGL. Use the SDK installed for the simulator version you are targeting.

1. Open or create the airport project. On PC, enable Developer Mode and confirm that the project has a BGL asset group connected to its airport or facility XML. Our SDK scenery project setup walkthrough covers the project, asset-group and build stages.
2. Edit the correct data source. Some SDK editor versions expose ILS properties through the runway object. If those fields are available, the editor writes the underlying XML. Otherwise, add the facility record directly to the source XML using the schema and samples supplied with that SDK. Standalone VOR and NDB facilities are navigation records, not generic scenery objects. Review the airport editor controls and airport-override behaviour before changing an existing airport.
3. Define the facility identity. Enter the airport ICAO, navaid ident, region code where required, latitude, longitude and elevation. Keep identifiers consistent across the airport, runway, navaid and any procedure records. A mismatched region or runway designator can leave a valid facility disconnected from the airport.
4. Enter accurate geometry. For an ILS, place the localiser transmitter beyond the far end of the runway and align its inbound course with the centreline. Put the glide-slope transmitter beside the touchdown area. MSFS facility geometry uses true headings, while painted runway numbers are rounded magnetic designations, so runway 27 is not necessarily an exact 270-degree XML heading.
5. Add the service data. Supply the frequency in the format and units required by the installed SDK schema, plus the ident, range and optional glide-slope or DME data. Associate an ILS with the correct runway end; assigning it to the reciprocal end is a common cause of reversed indications.
6. Build the package. Run the SDK package build and resolve every XML or compiler error. Raw XML copied into the Community folder is not active navdata; it must be compiled into the package. Keep only one built copy installed while testing, or the live project and an older Community package may compete.
7. Restart and test from the cockpit. Facility data does not always refresh reliably after a scenery reload, so perform a full simulator restart for final testing. Tune the frequency and verify localiser direction, glide-slope capture, VOR TO/FROM indications, DME distance or ADF bearing. Treat the World Map and FMS listing as separate tests.

This workflow broadly applies to MSFS 2020 and MSFS 2024, but editor fields and schemas can differ. Loose-package development and Community-folder testing are PC workflows; console installations do not provide the same direct package access.

Why does the ILS tune but not appear in the FMS?

An ILS signal and an instrument approach are separate records. The ILS can provide a working localiser and glide slope while the arrival or approach menu remains empty.

For a fictional airport, new runway or changed runway identifier, you must also code an approach with its transitions, legs, fixes and facility references. The XML procedure and facility-reference workflow used for SIDs and STARs explains the same package-building principles.

At an existing real airport, the simulator's navdata may already contain the approach, but it will attach only when the ICAO, runway and facility references agree. Some advanced add-on aircraft use their own navigation database rather than scenery BGL data, so a navaid can work on the radio while remaining absent from that aircraft's FMS.

What causes missing or misaligned navigation aids?

• Magnetic heading entered as true heading: the localiser beam is offset even though it is assigned to the correct runway.
• Wrong runway end: the signal points the opposite way or behaves like an unintended back course.
• Duplicate facility records: the default airport, an older build, another scenery package and a navdata package may all define the same ident or frequency.
• Incorrect ICAO or region key: the facility compiles but does not connect to the expected airport or procedure.
• Over-broad airport replacement settings: an airport override can remove default approaches or facilities that were meant to remain.
• No clean restart: scenery geometry updates while cached facility data remains loaded.
• Aircraft-specific navdata: the radio receives the BGL facility, but the aircraft's separate FMS database does not contain it.

When replacing an existing aid, use the deletion or replacement mechanism supported by the target SDK rather than stacking a second record with the same identity. Our guide to updating and reconciling MSFS navdata explains how simulator data, airport scenery and aircraft databases can conflict.

Should the navigation data be inside the airport package?

Keep facility data with the airport when it is unique to that airport and must always be installed with it. Use a separate navdata package when the same data serves several airports or needs to be maintained independently from visual scenery.