What is SimConnect in Prepar3D, and how do I set it up?

SimConnect is Prepar3D’s add-on communication API: it lets external programs read simulator data and send commands. Modern add-ons running on the Prepar3D PC normally connect through the bundled runtime with no manual setup. Only legacy applications or clients connecting across a network usually need extra runtimes or configuration files.

What is SimConnect in Prepar3D?

SimConnect is the interface through which compatible software communicates with Prepar3D while the simulator is running. It can provide aircraft position, simulator variables and events, and it can accept commands, create or control AI traffic and exchange custom data.

Moving maps, flight trackers, instructor stations, hardware interfaces and cockpit displays commonly use it. SimConnect is not a separate control panel, and there is normally no switch inside Prepar3D that must be enabled before each flight.

Do I need SimConnect.cfg?

You do not normally need SimConnect.cfg for an add-on running on the same PC as Prepar3D. The default local connection is sufficient unless the add-on’s own instructions require a particular configuration.

A remote client may need SimConnect.cfg to identify the Prepar3D computer and listening port. Some applications instead provide host and port boxes, generate the file themselves or use a bridge service. Use one method: combining an application’s connection manager with an unrelated CFG file is a mistake we see constantly.

For a conventional SimConnect client, put SimConnect.cfg beside the client application’s executable on the client computer. Some applications explicitly search the user’s Documents folder or their own data directory, so their instructions take precedence. A client CFG left only on the Prepar3D PC cannot configure a program running on another machine.

Where is SimConnect.xml in Prepar3D?

SimConnect.xml belongs to the active Prepar3D release’s roaming profile, not the simulator installation directory. The release-specific locations for Prepar3D v4, v5 and v6 are:

Before editing anything, confirm which executable is running. In Windows, open the properties of Prepar3D.exe and check its product version, or use Task Manager’s Open file location command while Prepar3D is open. The major product version identifies the matching v4, v5 or v6 profile.

Then enter %APPDATA% in File Explorer while signed in to the same Windows account that runs Prepar3D. The active release folder should also contain Prepar3D.cfg; its modification time after closing the simulator is a useful confirmation that you have the live profile. Multiple Prepar3D releases and Windows accounts have separate folders.

If SimConnect.xml already exists, back it up and preserve any SimConnect.Comm entries installed by other add-ons. Add a new communication block inside the existing document rather than replacing the file or creating a second XML root.

How do I connect SimConnect across a network?

A network connection requires matching protocol, address and port settings on both computers, plus an inbound firewall rule on the Prepar3D PC.

1. Choose a stable simulator address. Run ipconfig on the Prepar3D PC and note the private IPv4 address of the Ethernet or Wi-Fi adapter connected to the client, such as 192.168.1.50. A DHCP reservation in the router prevents it changing later.
2. Choose an unused high-numbered TCP port. The example below uses 50100. A port is not private merely because it has a high number: keep it non-public by limiting the firewall rule to the private LAN and never forwarding it through the router.
3. Create the server definition. Close Prepar3D, back up the active SimConnect.xml, then add the communication entry shown below.
4. Create the client configuration. Put the matching SimConnect.cfg where the remote application searches for it.
5. Allow private-network access. On the Prepar3D PC, permit inbound TCP traffic for the chosen port or the correct Prepar3D.exe, restricted to the Private network profile or local subnet.
6. Test with a loaded flight. Start Prepar3D, load fully into an aircraft and only then launch the remote application.

Multi-PC instruments and hardware are common reasons to use this arrangement; our Prepar3D home-cockpit configuration guidance explains how the SimConnect link fits into a wider cockpit network.

SimConnect.cfg and SimConnect.xml: working network example

This server example binds SimConnect to the Prepar3D PC’s private-LAN address 192.168.1.50 and listens on TCP port 50100:

<?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="SimConnect" version="1,0"> <Descr>SimConnect</Descr> <Filename>SimConnect.xml</Filename> <Disabled>False</Disabled> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>IPv4</Protocol> <Scope>global</Scope> <Address>192.168.1.50</Address> <MaxClients>64</MaxClients> <Port>50100</Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> </SimBase.Document>

The corresponding file on the remote client computer is:

[SimConnect] Protocol=IPv4 Address=192.168.1.50 Port=50100 MaxReceiveSize=4096 DisableNagle=0

Replace 192.168.1.50 with the actual address of your Prepar3D PC. If its address changes, update both files or restore the reserved address. Do not copy the example unchanged unless the simulator computer really owns that address and the port is unused.

Can you fix this? A practical SimConnect diagnostic sequence

Most failed connections can be isolated by checking the simulator state, active files and network path in that order.

1. Load an actual flight. Wait until the aircraft and simulation session are active. Blank data at the scenario screen does not prove that SimConnect is broken.
2. Check the real filenames and profile. Enable file-name extensions in File Explorer and confirm the files are named exactly SimConnect.xml and SimConnect.cfg, not SimConnect.xml.txt or SimConnect.cfg.txt. Verify that the XML is in the profile belonging to the Prepar3D release and Windows account being used.
3. Compare every connection value. The client and server must use the same protocol and port. The CFG address must be the simulator PC’s present private IPv4 address. Hostnames can resolve through the wrong adapter, so use the numeric address while diagnosing.
4. Confirm that Prepar3D is listening. With Prepar3D running, enter netstat -ano | findstr :50100 in Command Prompt, substituting your port. A LISTENING result should belong to the Prepar3D process. No listener usually means the XML was ignored, is malformed, is in the wrong profile or refers to an address the PC no longer owns.
5. Test the route from the client. In PowerShell on the remote computer, run Test-NetConnection 192.168.1.50 -Port 50100 with your real address and port. A failed TCP test points to routing, address, listener or firewall trouble rather than an add-on setting.
6. Check firewall scope. The inbound rule must apply to the network profile Windows is actually using. Prefer a rule limited to the Private profile or local subnet; do not expose the port to the public internet. Disabling the whole firewall is not a suitable permanent fix.
7. Remove adapter ambiguity. VPNs, virtual-machine adapters and extra Wi-Fi or Ethernet links can send traffic down the wrong route. Bind the XML address to the LAN adapter shared with the client, and temporarily disconnect irrelevant adapters if necessary.
8. Match privilege levels. Run Prepar3D and the client normally where possible. If one is elevated and the other is not, close both and retry at the same privilege level.
9. Check legacy runtime errors. A missing assembly, side-by-side configuration error or immediate client failure often means that an older application needs the exact SimConnect runtime against which it was built. Reinstalling only the newest runtime may not satisfy it.
10. Prove the remote client reached the simulator. Start the client and run the netstat command again. An ESTABLISHED connection involving the client’s private address confirms that TCP reached Prepar3D. If TCP connects but the application still reports no simulator data, concentrate on its runtime, CFG discovery, compatibility and loaded-flight requirements.

FSX/Prepar3D SimConnect SDK and runtimes

The SimConnect SDK is for developers; runtime redistributables are for users running compiled applications. Installing the full Prepar3D SDK is not a normal fix for an add-on that cannot connect.

Prepar3D includes the runtime needed by modern applications targeting that release. An FSX-era program may have been compiled against a particular older SimConnect assembly installed side by side in Windows. Newer interfaces do not automatically replace every older assembly, which is why the application’s specified legacy runtime can still be required.

Use the redistributable supplied with Prepar3D, included by the trusted add-on installer or explicitly required by its documentation. Our guide to installing the correct SimConnect runtime explains where the legitimate installers fit. Do not download an arbitrary SimConnect.dll and copy it into Windows system folders or beside random executables; that bypasses the proper side-by-side installation and introduces both security and versioning problems.

Bitness is related but separate. A 32-bit external program can communicate with a 64-bit Prepar3D release when its correct client runtime is installed. A module loaded directly inside the simulator process, however, must match the simulator’s architecture.

Developers should install the SDK corresponding to the Prepar3D release they intend to target and build against its documented headers, libraries or managed assemblies. For the v5 toolchain specifically, our Prepar3D v5 SDK installation and usage notes cover the components and development workflow without confusing the SDK with the end-user runtime.