Learn how to install the matching Prepar3D v5 SDK, choose the right tools, build a first project, deploy it safely and fix common errors.
Install the Prepar3D v5 SDK as a separate package whose full build number matches your installed simulator. Run its installer, copy a sample to a writable project folder, then use the supplied compiler, modelling, SimConnect or PDK tools for your project. Deploy only the built output to Prepar3D, preferably through an add-on package.
The SDK is not a single development application and does not add a general developer mode to Prepar3D. It installs documentation, command-line tools, libraries, headers, exporters and samples for several different types of development.
How do I install the Prepar3D v5 SDK?
Install the SDK package made for the exact Prepar3D v5 build shown in the simulator’s About window. Matching only the major version is not enough: a different v5 point release can contain changed interfaces, tools or sample projects.
- Record the complete simulator version. Open Prepar3D v5 and note its full version and build number, not merely “v5”.
- Obtain the matching SDK installer. Use the official Prepar3D download area for that release. The SDK is separate from the main simulator installer; do not substitute a v4 or v6 SDK.
- Run the installer with administrative permission. A complete installation is the simplest choice because samples often depend on files from more than one SDK component.
- Keep the installed SDK folder intact. Its default location is normally protected by Windows, and some samples rely on paths configured during installation. Moving the folder manually can break project references.
- Open the installed documentation. Check the prerequisite and compatibility pages for the supported Visual Studio, Windows SDK and 3D modelling software versions for that particular build.
- Create a separate development folder. Copy any sample you intend to modify out of
Program Files. Build and edit the copy rather than changing the SDK’s reference files.
Visual Studio is needed for C++, PDK and many SimConnect projects, but not for every scenery task. Modelling exporters also support specific versions of their host application; installing an exporter into an arbitrary newer or older version commonly leaves it missing from the application.
Which SDK tool should I use?
Choose the SDK component according to the output you need; no single tool covers aircraft, scenery and external applications.
| Project | Relevant SDK area | Typical output |
|---|---|---|
| Airports and scenery objects | BGLComp and scenery schemas | Compiled .bgl scenery |
| Aerial imagery, elevation and terrain | Resample and related terrain tools | Terrain or imagery .bgl files |
| Vector scenery data | Shp2Vec | Compiled vector scenery |
| External utilities and hardware software | SimConnect SDK | An application communicating with Prepar3D |
| In-process modules | Prepar3D Development Kit and C++ libraries | A 64-bit DLL loaded by Prepar3D |
| Aircraft and other SimObjects | Modelling exporters, model tools and SimObject documentation | Models, animations, configuration and supporting files |
For airport, imagery or terrain work, our complete Prepar3D scenery-development workflow explains how the source files, compilers and scenery registration fit together. For an external program, follow the separate guidance on configuring SimConnect locally or across a network.
Prepar3D v5 is 64-bit. Any DLL loaded inside the simulator must use the correct 64-bit target and compatible SDK interfaces; an old Win32 FSX or Prepar3D v3 project cannot simply be recompiled without checking its code and dependencies.
How do I build and test a first SDK project?
Start with the smallest supplied sample that matches your intended project, prove that it builds unchanged, and only then modify it.
- Copy the sample. Place it in a writable source folder that is not inside either the SDK or Prepar3D installation.
- Read its supplied instructions. Confirm the required compiler, workloads, include paths, libraries and build platform.
- Build the untouched sample. This separates SDK and toolchain problems from errors introduced by your own changes. Command-line compilers should be run from a command prompt so their messages remain visible.
- Inspect every compiler message. A generated file does not guarantee valid content. Missing textures, rejected XML elements and invalid source paths can be reported as warnings.
- Package the output. Put compiled files, models, textures and configuration files into an external add-on package. Do not deploy source code, SDK headers or compiler tools with the add-on.
- Test with a clean configuration. Enable only the new package where practical, then check loading, placement, performance and the Prepar3D error log before adding other dependencies.
An add-on.xml-based package keeps development files out of the simulator’s core directories and makes removal much safer. Our guide to packaging and managing Prepar3D add-ons without altering the core installation covers that deployment stage.
Why does the Prepar3D v5 SDK fail to build or load?
Most SDK failures come from a mismatched build, an unsupported development tool, protected folders or an incorrect 32-bit versus 64-bit target.
| Symptom | Likely cause | Fix |
|---|---|---|
| An SDK program opens and immediately closes | It is a command-line compiler rather than a graphical application | Run it from a command prompt with the required source and output arguments so you can read its messages |
| A sample reports missing headers, libraries or paths | The SDK was moved, the installation is incomplete, or required compiler components are absent | Repair the matching SDK installation and install the prerequisites named in its documentation |
| A DLL builds but Prepar3D will not load it | Wrong architecture, incompatible SDK build or a missing runtime dependency | Build for 64-bit Prepar3D v5, match the SDK build and verify every dependent DLL |
| Scenery compiles but does not appear | The package is inactive, its folder structure is wrong, or the source coordinates and layer are incorrect | Check the compiler log, package registration, coordinates and active scenery configuration |
| A modelling exporter is missing | The host modelling application is not one of the versions supported by that SDK | Use the compatibility matrix and installation path documented with the matching SDK release |
| A SimConnect program works locally but not over the network | Client/server configuration, address, port or firewall rules are incomplete | Correct both SimConnect configuration files and permit the selected connection through the firewall |
A mistake we see constantly is testing several changes at once: a new SDK, modified sample, different compiler and custom deployment folder. Build an untouched sample first. If that works, change one part at a time; the first failing step usually identifies the real cause.