How do I fly the FlyByWire A32NX with YourControls in MSFS?
Fly the FlyByWire A32NX with YourControls in MSFS: match builds, set up shared cockpit, transfer control and fix synchronisation problems.
To fly the FlyByWire A32NX with YourControls in Microsoft Flight Simulator, both pilots need Windows PCs, the same simulator generation, matching A32NX and YourControls builds, and the correct aircraft profile. Connect before programming the MCDU or flyPad, let one pilot establish the aircraft state, then verify synchronisation before pushback.
Are the FBW A320 and YourControls free?
Yes. The FlyByWire A32NX and YourControls are free, although each pilot still needs a licensed PC installation of Microsoft Flight Simulator. YourControls is the shared-cockpit utility; it is not part of MSFS multiplayer and does not let two people share one simulator installation.
The aircraft is often called the FBW A320, FlyByWire A320 or FBW A320neo. Its proper project name is A32NX.
What does A32NX or NX mean?
A32NX is the name of FlyByWire's custom Airbus A320neo simulation for Microsoft Flight Simulator. The letters NX are part of that project name; they do not identify a separate simulator or an Airbus aircraft variant that must be purchased.
How do you set up an A32NX shared cockpit?
Build two matching installations first, then connect YourControls before either pilot configures the aircraft.
- Confirm platform compatibility: Both crew stations must be Windows PCs. Use the same simulator generation on both machines; do not pair MSFS 2020 with MSFS 2024. For MSFS 2024, follow the correct A32NX installation process for that simulator and confirm that your YourControls release and aircraft profile support the combination.
- Test the aircraft separately: Load the A32NX on each computer and check that the displays, flyPad and custom systems initialise normally. Fix duplicate or stale aircraft installations before adding shared-cockpit networking to the problem.
- Install and connect YourControls: One pilot hosts and the other joins using the same YourControls release. Our YourControls installation, firewall, hosting and joining instructions cover the network setup.
- Match every relevant version: Compare the simulator build, A32NX branch and build identifier, YourControls release, A32NX-specific profile and navigation-data source. Restart MSFS after changing or updating the aircraft.
- Prevent competing inputs: Decide who initially owns the sidestick, rudder and thrust axes. Remove duplicate bindings, increase dead zones where noisy hardware sends unwanted input, and disable piloting assistance that can move controls automatically.
- Load the same situation: Select the same airport, parking stand and aircraft state, preferably cold and dark. Match time and weather for procedural consistency, and disable multiplayer aircraft if it creates a duplicate aeroplane at the stand.
- Connect before cockpit preparation: Allow the A32NX to finish loading on both PCs, connect YourControls and then have one pilot apply power and perform the initial setup. Do not import separate flight plans or independently configure fuel and payload first.
- Verify the shared state: Compare battery and external-power indications, overhead switches, barometric settings, FCU values, trim, flap and gear indications, and an MCDU page. Move one mapped control as a test and confirm that it changes once, correctly, at both stations.
Which stable A32NX build and YourControls profile should you use?
Use the exact A32NX build supported by the selected aircraft profile; for most flights, matching stable builds are the safest choice. A shared-cockpit profile maps specific aircraft events and variables, so an aircraft update can break synchronisation even when the add-on still works perfectly in solo flight.
| Configuration | When to choose it | Risk |
|---|---|---|
| Same supported stable build | Normal shared-cockpit flying | Lowest risk, but the exact build must still match |
| Same development or experimental build | Only when the profile explicitly supports it | Aircraft-system changes can outpace the profile |
| Different A32NX builds | Never intentionally | Switches, displays, MCDU state and autopilot logic may disagree |
| Generic Airbus profile | Basic connection or axis testing only | Many A32NX custom systems will not be mapped |
A mistake we see constantly is matching the word stable but not the actual build. If one computer updated after the other, make both installations identical before changing firewall rules or control bindings. Once a working pairing is established, avoid updating either installation between planning and completing the flight.
Does everything in the A32NX cockpit synchronise?
No. YourControls exchanges only the events and variables defined in its A32NX profile; it does not stream one pilot's screen or complete simulator state to the other computer.
With a compatible profile, you can expect many flight-control inputs, FCU selections, autopilot commands, overhead controls, flaps, landing gear and profile-mapped MCDU key presses to be shared. The displays are still calculated locally, so identical button presses can produce different indications when the underlying flight plan, navigation data or aircraft state differs.
These items commonly require checking or manual matching:
- flyPad pages, preferences and some tablet-triggered actions
- Fuel, payload, boarding, doors, chocks and ground services
- Flight plans imported before the shared-cockpit connection
- Weather, traffic, time, toolbar windows, cameras and audio settings
- Controller calibration and local assistance settings
- Navigation databases and locally calculated route or performance data
Nominate one pilot to manage the tablet, fuel, payload and ground services. The other pilot should reproduce any state that does not transfer; our guide to the A32NX flyPad's flight-plan, loading and ground-service controls explains the items the crew should coordinate.
Why do the controls snap back or the cockpit states disagree?
Controls usually snap back because another device or assistance feature is sending a competing command; broader cockpit disagreement usually points to mismatched builds, profiles or starting states.
| Symptom | Likely cause | Fix |
|---|---|---|
| A switch or lever immediately returns | The other pilot's hardware, a duplicate binding or piloting assistance is sending the opposite input | Assign one control owner, remove the duplicate binding and check both stations for noisy axes |
| Overhead or ECAM indications differ after loading | Different aircraft builds, profiles or saved aircraft states | Disconnect, reload the same state on both PCs and reconnect before cockpit setup |
| Thrust levers show different detents | Throttle calibration is local and does not match | Use the A32NX throttle-detent calibration procedure on both computers |
| MCDU routes or navigation displays disagree | The route was loaded before connecting, or the navigation-data sets differ | Match the data source, clear the route on both sides and let one pilot enter or import it after connection |
| Autopilot disconnects without an obvious reason | A sidestick, rudder or trim axis is producing unwanted input | Check bindings and dead zones, then test with the non-flying pilot's conflicting axes temporarily unbound |
| Aircraft positions separate or jump | The pilots loaded different stands, or one used pause, slew or a different simulation rate | Reload the exact same stand and avoid slew, active pause and simulation-rate changes during the session |
| EFB, doors or chocks do not match | The selected function is local or absent from the profile | Have one pilot command it and manually reproduce the resulting state on the other PC |
| The connection fails or drops | Different YourControls releases, incorrect host details or blocked network traffic | Recheck release matching, host information and firewall permission before troubleshooting the aircraft profile |
Do not repeatedly operate a disagreeing switch from both stations. That creates a control fight and hides the original fault. Stop, identify which station is sending the unwanted event, then rebuild the shared state if necessary.
How should two pilots divide A320 duties?
One person should be pilot flying and own the flight-control and thrust axes, while the pilot monitoring handles agreed system tasks without duplicating commands.
- Brief the pilot-flying and pilot-monitoring roles before engine start.
- Let one pilot initialise the MCDU and flyPad rather than importing the route independently on both PCs.
- State FCU changes aloud and avoid turning the same selector simultaneously.
- Assign fuel, payload, doors and ground services to one crew member.
- After an abnormal indication, compare both cockpits before continuing the checklist.
How should control be transferred in YourControls?
A transfer should be deliberate: the giving pilot centres the controls, announces the hand-off and uses the YourControls transfer function only after the receiving pilot is ready.
- Stabilise the aircraft: Avoid transferring during rotation, flare or a rapid configuration change.
- Neutralise competing inputs: The giving pilot releases the sidestick, rudder and thrust hardware as appropriate.
- Transfer ownership: Use the YourControls hand-off and wait for confirmation.
- Confirm the result: The receiving pilot makes a small input and checks the sidestick, rudder, thrust, flight-director and autopilot status before saying that control is accepted.
Can you use YourControls with the A32NX on console?
No. YourControls requires a Windows desktop application and local aircraft-profile files, so it cannot run on Xbox Series X|S, PlayStation 5 or PS5 Pro. Both crew stations must therefore use compatible PC installations, even though MSFS 2024 itself is also available on those consoles.