Skip to content

Development Environment

Required Software, Tools, and libraries

Git and GitHub

To access our source code, a GitHub account is required.

Also, some git client is necessary to interact with the GitHub repository.

Either use a standalone git client (terminal or UI based) or one integrated into your editor.

Make sure you are familiar with the basics of working with git/GitHub. The GitHub Quickstart documentation is a great help.

Docker

FlyByWire provides a preconfigured docker container that has all necessary tools included and preconfigured to compile the aircraft.

To use this, you need to download and install Docker here.

Use either WSL2 or HyperV backend work, but the latter is faster.

Editor or IDE

Most of our team works with either Visual Studio Code or IntelliJ IDEA-based IDEs for development. Obviously, your choice is yours as long as the resulting code conforms to our standards.

Getting the source code

To work on the A32NX project, you need to create a fork ( GitHub fork) of the aircraft repository.

Clone this fork to your local environment. You can use the command line git or a UI-based git to do this. On the command line, go to your projects folder and clone it into that folder.

git clone https://github.com/flybywiresim/aircraft.git

You now have a copy of the aircraft repository on your local machine to review and change the source code. The subfolder ./fbw-a320nx contains the A32NX source code.

Compiling the source

To compile the source code into a package you can install into the Microsoft Flight Simulator Community folder, we have prepared a few scripts you need to run, which in turn use the Docker container mentioned above to compile the aircraft add-on.

PowerShell or Cmd Prompt
cd aircraft
.\scripts\dev-env\run.cmd ./scripts/setup.sh
.\scripts\dev-env\run.cmd ./scripts/build.sh
git bash or other *nix shells on Windows
cd aircraft
./scripts/dev-env/run.cmd ./scripts/setup.sh
./scripts/dev-env/run.cmd ./scripts/build.sh

The setup.sh is configuring the build process and is sometimes necessary when you changed branches which for example use a different Nodes configuration.

The build.sh is actually using the docker container to compile and build the add-on into the folder flybywire-aircraft-a320-neo.

Compiling on Linux (incl. WSL)

You should use run.sh instead of run.cmd if you are on Linux/WSL.

If you are using WSL, ensure that the Vmmem process is not memory limited. At least 10 GB of memory is the recommended setting. This can be configured in C:\.wslconfig.

Create working branches

We recommend when making changes on your fork, you create a new branch, titled with the change you're looking to make or something similar.

After a successful build, it is possible to copy the flybywire-aircraft-a320-neo folder into your Community folder and use the compiled A32NX in your simulator. See next chapter for a more convenient way to update the add-on after a compile.

Important step!

Make sure you remove any existing copy of the aircraft from your community folder before doing this.

Linking Dev folder to Community folder

To avoid having to copy the flybywire-aircraft-a320-neo folder after every compile, it is possible to use a so called symlink from your Community folder to your compiled flybywire-aircraft-a320-neo folder.

To create your symlink, open your command terminal and run the below command, substituting the correct file paths with your community folder, and the 'flybywire-aircraft-a320' folder from your new project.

Important step!

Make sure you remove any existing copy of the aircraft from your community folder before doing this.

mklink /J [MSFS Community folder\flybywire-aircraft-a320-neo] [Project folder path\fbw-a32nx\out\flybywire-aircraft-a320-neo]

Example:

mklink /J C:\Users\USERNAME\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\Community\flybywire-aircraft-a320-neo C:\Users\USERNAME\IdeaProjects\aircraft\fbw-a32nx\out\flybywire-aircraft-a320-neo

If this works, you'll receive the response:

"Junction created for [Community folder] [Project Folder]" from the terminal.

Now you've compiled and symlinked your GitHub fork to your community folder, you should be able to load into the aircraft as normal.

Open MSFS and check everything is working with your compiled branch before progressing.

Hello World Example

Before changing anything, we recommend creating a new branch from the master branch:

git checkout -b test-branch master

Open this file in the editor/IDE: fbw-a32nx/src/systems/instruments/src/MsfsAvionicsCommon/displayUnit.tsx

Go to line 181 and add the following after that line:

    <text
        class="SelfTestText"
        x="50%"
        y="62%"
    >
        HELLO FLYBYWIRE A32NX!
    </text>

After you save, it should look like this:

displayUnit.tsx
    <svg style="display:none" ref={this.selfTestRef} class="SelfTest" viewBox="0 0 600 600">
        <rect class="SelfTestBackground" x="0" y="0" width="100%" height="100%" />
        <text
            class="SelfTestText"
            x="50%"
            y="50%"
        >
            SELF TEST IN PROGRESS
        </text>
        <text
            class="SelfTestText"
            x="50%"
            y="56%"
        >
            (MAX 40 SECONDS)
        </text>
        <text
            class="SelfTestText"
            x="50%"
            y="62%"
        >
            HELLO FLYBYWIRE A32NX!
        </text>
    </svg>

Now recompile your branch:

.\scripts\dev-env\run.cmd ./scripts/build.sh --no-cache

The optional --no-cache option makes sure everything is recompiled.

After the successful compile, start the sim and load the FlyByWire A32NX cold & dark at a gate.

When turning on power to the aircraft, the screens will do a self test. See if you can spot your code change there.

hello-world-pfd

Congratulations! You have successfully made a code change and deployed the new add-on to the simulator.

Development Workflow

The above is obviously not an efficient workflow as you have to restart the simulator after every code change. There are several ways to avoid this and hot reload the code into the simulator while it is running. But this is out of scope for this guide as it only serves to test the basic development environment.