How do I add SIDs and STARs to a custom MSFS airport?

Add SIDs and STARs by defining <Departure> and <Arrival> records, their runway, common and transition legs, and the required fix references in the custom airport’s source XML, then rebuild its BGL package. Microsoft Flight Simulator has no complete graphical procedure designer, so follow the schema supplied with the SDK version used to build the package.

Visual airport scenery and navigation procedures are separate systems. If this is a real airport, first check whether the simulator’s navigation database already supplies the procedures under the same ICAO and runway designations. Our airport SDK workflow explains that distinction and the wider package-building process.

What goes into the airport XML?

A working SID or STAR needs a procedure identity, an ordered sequence of supported leg types, resolvable fixes, runway applicability and any published altitude or speed constraints.

A STAR normally feeds an approach or an approach entry fix; it is not the approach itself. Likewise, a SID must connect the runway departure path to an en-route transition without duplicating legs or leaving an unintended gap.

How do I add the procedures with the MSFS SDK?

The reliable method is to translate the published procedure into the installed SDK’s Airport XML format and compile that source through the project’s BGL asset group.

1. Confirm that new procedure data is necessary. Load the airport without the custom scenery and inspect its SIDs and STARs. If they exist in the base simulator but disappear with the add-on enabled, repair the airport identity, runway mapping or replacement settings instead of recreating the procedures.
2. Collect the source data. Use an authorised aeronautical publication showing the procedure name, runway branches, transitions, fixes and restrictions. Our guide to finding suitable airport charts covers the useful chart types. Only redistribute data that its licence permits you to distribute.
3. Map the chart before writing XML. List each procedure from beginning to end, separating runway-specific legs, common legs and en-route transitions. If the chart symbols or sequencing are unclear, use our explanation of runway branches, transitions, fixes and restrictions before choosing SDK leg types.
4. Edit the source, not the compiled package. Locate the airport’s source <Airport> record inside its existing XML wrapper and add the departure and arrival records there. Do not edit a BGL in the built package or create a second airport record with the same identifier merely to hold procedures. Keep a backup because saving through visual scenery tools can rewrite managed XML.
5. Resolve every fix precisely. Reference the exact identifier, facility type and region expected by the schema. Identifiers are not always globally unique. If a fictional or local fix does not exist in the simulator’s navigation data, define it with the supported waypoint or navaid record at the package scope required by that SDK schema.
6. Encode the actual path and constraints. Enter legs in the order required by the schema, including fly-over behaviour and published altitude or speed restrictions where supported. Follow the SDK’s stated units and magnetic or true-course convention rather than assuming that a charted value can be copied into any course field.
7. Rebuild and reload the package. Run the package build, inspect its output for XML and facility errors, then reload the package or restart the simulator. Navigation facilities do not always refresh as predictably as visual scenery during a live editing session.

How should I choose SID and STAR leg types?

Choose the path terminator that describes how the aircraft reaches or leaves the next fix, not simply the one that is easiest to encode.

For example, IF identifies an initial fix, TF represents a track to a fix and CF represents a specified course to a fix. Heading, vector, altitude-termination and radius-to-fix segments require their corresponding supported types. Use only the types and fields documented by the SDK version targeting your simulator.

Turning every segment into TF may make the procedure appear in a flight planner, but it can create wrong intercepts, missing vector sections and unrealistic turns. Some cockpit avionics also interpret advanced or discontinuity-producing legs differently, so a successful package build is not proof that the route will fly correctly.

Why does the SID or STAR not appear in MSFS?

A missing procedure is usually caused by an unresolved facility reference, a runway mismatch, stale compiled data or a conflict between packages.

• Wrong airport identity: Confirm that the procedure belongs to the exact airport ICAO used by the scenery and facility record.
• Runway mismatch: The procedure’s runway must match the airport’s designation. This often breaks when a real runway has been renumbered but only the visual scenery or only the navigation data reflects the change.
• Unresolved fix: Check the fix identifier, type and region. A correctly spelt identifier can still point to the wrong facility or no facility.
• Invalid sequence: Check for a missing initial leg, duplicated transition leg or branch that does not join the common route.
• Over-broad replacement settings: Airport deletion or replacement directives can suppress base facility content. Remove only the records the package genuinely replaces.
• Package conflict: Another airport or navigation-data package may supply a competing record for the same airport. Test with other third-party airport and navdata packages disabled, then resolve the duplicate or package priority.
• Old build still loaded: Delete or replace the previously built package through the normal project workflow, rebuild it and perform a full simulator restart.
• Planner filtering: Check every runway and transition selection. The World Map and individual aircraft avionics may expose procedure choices differently.

How should I test a custom SID or STAR?

Test the procedure in both the MSFS flight-planning interface and a representative aircraft FMS, then inspect and fly every branch rather than checking only that its name appears.

• Verify the procedure name, runway choices and transition list.
• Inspect the loaded route leg by leg for duplicates, gaps, unexpected discontinuities and reversed sequencing.
• Confirm that altitude and speed constraints appear on the intended fixes.
• Fly each runway branch and at least one route through every transition.
• Check turn direction, intercept geometry, fly-over fixes and vector or manual-discontinuity behaviour.
• Test with other airport and navigation packages restored to expose load-order conflicts.

Do not use ATC or autopilot tracking as the sole validator. Procedure availability, route construction, autopilot behaviour and ATC clearance handling are separate parts of Microsoft Flight Simulator and can fail independently.

Does the method work in MSFS 2020 and MSFS 2024?

The same facility-based principle applies to Microsoft Flight Simulator 2020 and 2024, but the package should be built and validated with the SDK intended for each target simulator.

Schema requirements, validation and avionics behaviour can differ between simulator generations and updates. Retain the editable source, rebuild against the appropriate SDK, and test in both simulators if the package claims compatibility with both; do not assume that one compiled BGL will behave identically everywhere.