How do I create a custom aircraft for Microsoft Flight Simulator?

To create a custom aircraft for Microsoft Flight Simulator, use the matching PC SDK to build a package around an optimised 3D model, aircraft configuration and flight dynamics. Add cockpit instruments, systems, animations, textures and sound as required, build it in Developer Mode, test the output in the simulator, and distribute the complete package rather than your editable source files.

What do you need before creating an MSFS aircraft?

Aircraft development requires a Windows PC running the simulator version you intend to support; the development SDK and package tools are not available as a comparable console workflow. Install the SDK that matches your Microsoft Flight Simulator build and keep the simulator updated before diagnosing unexplained build errors.

• A 3D modelling application with an SDK-supported glTF export workflow.
• A PBR texture editor for base colour, normal, metallic, roughness and related material channels.
• A code editor for configuration, XML, JavaScript, CSS and other project files.
• Reliable aircraft data covering dimensions, mass, centre-of-gravity limits, engine performance and control geometry.
• Source control so that a broken configuration or export can be rolled back.

Our overview of the tools used for aircraft modelling, systems and flight dynamics explains which specialist applications are useful and when they become necessary. If all you want is a new paint scheme, make a livery package instead; a complete aircraft is a much larger project.

Should you build for MSFS 2020 or MSFS 2024?

Choose a primary target before creating the project because MSFS 2020 and MSFS 2024 have different SDK generations and aircraft capabilities.

Avoid changing SDK versions halfway through the project without making a backup. Package definitions, model behaviour and systems assumptions can change, and an apparently successful build may still produce faults inside the simulator.

How do you build a custom aircraft in Microsoft Flight Simulator?

The reliable workflow is to produce a small flyable aircraft first, then add cockpit depth and visual detail in controlled stages.

1. Define the aircraft and its scope. Decide whether it is a real or fictional design, which simulator version it supports, how detailed the cockpit will be and which systems must work. For a real aircraft, use lawful reference material and record the source and units of every performance value.
2. Create an SDK aircraft project. Enable Developer Mode, install the matching SDK and start from an official aircraft sample or a clean project rather than copying an installed premium aircraft. Follow our SDK setup and first-package workflow for the project, package and build-tool basics.
3. Model at real scale. Build the exterior, cockpit and moving components with consistent axes, origins and pivots. Separate the control surfaces, propellers, landing gear, doors and cockpit controls that need animation. Plan level-of-detail meshes early; trying to reduce an excessively detailed master model at the end usually creates poor LOD transitions.
4. Create materials and export the model. UV-map the meshes, make PBR textures and export using the SDK-supported glTF workflow. Connect the model to its definitions and behaviours, then check animation names, ranges and part references. A valid glTF file alone is not a working MSFS aircraft.
5. Configure mass and flight dynamics. Establish the reference datum, empty mass, centre of gravity, fuel stations, payload stations and contact points before tuning lift or engine power. Configure wing geometry, stability, control effectiveness, drag, propulsion and landing gear in the appropriate files, commonly including aircraft.cfg, flight_model.cfg and engines.cfg, depending on the target SDK.
6. Add aircraft systems. Implement fuel, electrical power, lighting, engine starting, anti-ice, hydraulics or other systems relevant to the design. Link cockpit switches to the correct simulation variables, input events and model behaviours. Do not simulate complex systems merely to increase the feature count; simulate the systems the aircraft actually needs and test their failure states.
7. Build the cockpit instruments. Use supported gauge technology for analogue instruments, glass displays and controls. HTML, JavaScript and CSS are commonly used for displays, while model behaviours operate physical cockpit parts; WASM may be appropriate for specialised code. Do not copy protected gauges, models or textures from another aircraft package.
8. Add sound, effects and cameras. Configure engine, switch, warning and environmental sounds using the supported sound workflow. Set useful pilot, instrument and external viewpoints, and verify that effects such as lights or exhaust remain attached to the correct model points.
9. Build the package. Run the SDK package build and inspect every warning and error. The distributable output must contain valid manifest.json and layout.json files, a unique package identity and all assets you have permission to distribute. Do not release the editable project source by mistake.
10. Test inside the simulator. Test cold-and-dark starts, runway starts, engine shutdowns, fuel use, electrical loads, stalls, flap and gear operation, crosswind handling, maximum and minimum loading, camera positions and cockpit interactions. Watch the Developer Mode console while testing, then repeat the test with Developer Mode disabled.

What should the first flyable build contain?

A first flyable build should contain only enough functionality to prove that the model, package and aircraft simulation agree with one another.

• An exterior model and basic cockpit at the correct scale.
• Working elevators, ailerons, rudder, throttle, flaps, brakes and landing gear where fitted.
• Credible empty mass, centre of gravity, contact points and fuel capacity.
• A functioning engine, starter and fuel supply.
• Essential flight instruments and a usable pilot viewpoint.
• One complete material and texture set.
• A package that rebuilds without unexplained errors.

Do not begin with a detailed flight-management computer while the aircraft still sinks into the runway or loads with the wrong centre of gravity. Each major stage should remain testable before the next one is added.

Why does a custom aircraft fail to appear or work?

Most early aircraft failures come from package structure, bad asset references or disagreement between the visual model and the simulation configuration.

• The aircraft is missing from the selector: check for a failed build, invalid manifest or layout, missing user-selectable aircraft data, a duplicate package identity or an extra folder level. The package root should contain its manifest, not a structure such as Community\MyPackage\MyPackage\manifest.json.
• The aircraft loads but the model is invisible: inspect model paths, XML references, exported filenames, materials and object names. Paths that work only on the developer's computer are a frequent cause.
• Controls move but do not affect flight: visual animation does not create aerodynamic behaviour. The corresponding control surface geometry and effectiveness must also be configured in the flight model.
• The aircraft bounces, tips over or sinks into the ground: recheck the reference datum, contact-point positions, centre of gravity, wheel radius and gear compression. Mixing measurement units or measuring points from different model origins produces extreme ground behaviour.
• The engine will not start: verify fuel quantity and routing, starter and ignition logic, electrical power, mixture or condition controls, combustion settings and cockpit input events.
• Cockpit displays remain black: confirm that the required electrical bus is powered, brightness controls are initialised and the gauge has no path or runtime errors.
• Frame rate is unexpectedly poor: examine material count, draw calls, texture memory, missing LODs and gauge update loops. Polygon count is only one part of aircraft performance.
• It works only in the development project: look for absolute file paths, unpackaged assets and undeclared dependencies. Install only the final output in a clean Community folder and test again.

For package-specific checks, use our aircraft-not-showing troubleshooting checklist.

Can you convert an FSX aircraft directly to MSFS?

No reliable one-click conversion turns an FSX aircraft into a native Microsoft Flight Simulator aircraft. The geometry may provide a starting point if you own the necessary rights, but materials, animations, flight dynamics, gauges, systems, sounds and packaging normally need to be rebuilt with the MSFS SDK.

Our explanation of FSX aircraft compatibility with MSFS 2020 and 2024 covers why legacy packages and gauges cannot simply be copied across. Never convert or distribute somebody else's aircraft without permission from the rights holder.

How do you prepare the finished aircraft for release?

A release build should install and run without access to your source folders, modelling files or local development paths. Test the archive on a clean installation, confirm its supported simulator version, document any required dependencies and include only files you are licensed to distribute.

PC users can install suitable third-party packages through the Community folder. Xbox Series X|S and PlayStation 5 or PS5 Pro do not provide the same open folder-based sideloading workflow, so console distribution requires a supported in-simulator distribution route and the relevant approval process.