Microsoft Flight Simulator 2024

FFB-Bridge talks to MSFS 2024 over SimConnect's TCP transport. On a fresh install of MSFS 2024 this works out of the box on Windows and needs a single config tweak under Linux / Proton. The bridge's Doctor page can do the tweak for you — this guide covers both the one-click path and the manual one.

What MSFS installation do you have?

The default SimConnect location depends on how MSFS was installed. FFB-Bridge detects all three cases automatically, but it helps to know which one you're on if something goes sideways.

Install	`SimConnect.xml` location
Win Steam / standalone	`%APPDATA%\Microsoft Flight Simulator 2024\SimConnect.xml`
Win Microsoft Store / Xbox Game Pass	`%LOCALAPPDATA%\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalCache\SimConnect.xml`
Linux Steam + Proton	`~/.steam/steam/steamapps/compatdata/2537590/pfx/drive_c/users/steamuser/AppData/Roaming/Microsoft Flight Simulator 2024/SimConnect.xml`

Windows — out of the box

Every stock MSFS 2024 install ships with SimConnect TCP enabled on port 500, bound to all IPv4 interfaces. The bridge defaults to 127.0.0.1:500 on Windows. Launch MSFS, then launch FFB-Bridge — the Sim chip on the Dashboard should go green within a second or two of the sim reaching the main menu.

If it doesn't, open Doctor. The SimConnect config row tells you what it found in the XML and whether the port it's using matches the port the bridge is talking to.

Figure 1. Doctor's SimConnect row. The inline detail shows the host:port parsed from SimConnect.xml and whether that port is currently accepting SimConnect OPEN packets.

Ports other than 500

Some tools — FSUIPC, SPAD.neXt — add their own TCP entries in the same SimConnect.xml. If MSFS is listening on a different port than the bridge expects, the SimConnect config row on Doctor offers an inline Use port :X button. Click it and the bridge's preferences are updated to that port; no MSFS restart needed.

Linux — one-click fix via Doctor

MSFS under Proton ships the same stock SimConnect.xml as the Windows build, with TCP listening on port 500. But Linux treats ports below 1024 as privileged, and the Proton user-namespace process cannot bind them. The listen silently fails and no socket ever opens.

The fix is to add a parallel <SimConnect.Comm> entry on an unprivileged port (the bridge uses 5111 by default). Open Doctor; the SimConnect config row will show the privileged port and offer a Fix… button.

Figure 2. Doctor's Fix dialog on Linux. Shows the Proton prefix path it found and the port it's about to add. Clicking Install merges a new entry — existing entries are left alone.

Fix… merges a new entry into the existing XML (never rewrites it). If the existing file is unparseable, the installer first backs it up as SimConnect.xml.bak-YYYY-MM-DD-HHMMSS and writes a fresh generated config. Either way, restart MSFS after the install so it re-reads SimConnect.xml.

Which Proton prefix?

FFB-Bridge probes the well-known prefixes for Steam, Steam-Flatpak, Heroic, and Lutris. If you run MSFS from a non-standard location, set FFB_BRIDGE_MSFS_PREFIX=/path/to/prefix in your environment before launching the bridge. For a bare-metal override of just the XML file, FFB_BRIDGE_MSFS_CONFIG=/path/to/SimConnect.xml takes precedence.

Manual configuration

If you'd rather hand-edit, the XML looks like this:

<?xml version="1.0" encoding="Windows-1252"?>
<SimBase.Document Type="SimConnect" version="1,0">
  <Descr>SimConnect Client Configurations</Descr>
  <Filename>SimConnect.xml</Filename>

  <!-- FFB-Bridge: unprivileged TCP for Proton-on-Linux -->
  <SimConnect.Comm>
    <Descr>FFB-Bridge TCP</Descr>
    <Protocol>IPv4</Protocol>
    <Scope>local</Scope>
    <Port>5111</Port>
    <MaxClients>64</MaxClients>
    <MaxRecvSize>41088</MaxRecvSize>
    <DisableNagle>False</DisableNagle>
  </SimConnect.Comm>

  <!-- Keep any existing entries below this line. -->

</SimBase.Document>

After saving, open FFB-Bridge's Mock SimConnect page, switch the input source back to Live, and the bridge will pick up the new config. On Linux you can also go to Diagnostics and watch the log for SimConnect connected after relaunching MSFS.

SimVars the bridge reads

For reference — you don't need to configure any of this — here's the set of MSFS SimVars the bridge subscribes to:

Airspeed (indicated, true), altitude, vertical speed, pitch, bank, heading
G-force, angle of attack, stall warning, overspeed warning
Elevator, aileron and rudder deflection (trimmed and raw)
Trim positions (elevator, aileron, rudder)
Gear handle state, flap handle index, spoiler handle position
Per-engine RPM percent and combustion state, reverse-thrust engaged
Surface type enum (runway vs grass vs ice), brake pedal deflection
Autopilot master state, autopilot commanded pitch / bank

If MSFS doesn't recognise a variable name, the bridge logs it as a warning on the Diagnostics page but continues — missing variables default to sensible zeros. This is how the bridge tolerates third-party aircraft that don't implement every SimVar.

Troubleshooting

See Troubleshooting for:

MSFS connects but no forces — most often an arm-toggle problem, covered there.
MSFS pause sends frozen snapshots — a known data-flow quirk.
Stick goes limp 20–30 s into a flight — should be fixed in beta.2; check your version.