# Creating WASM Airports<no value>
In Microsoft Flight Simulator 2024 it is possible to WebAssembly modules ({{< glossterm >}}wasm{{< /glossterm >}}) to your airports. These are essentially [System Modules](creating-wasm-systems/) that don't render anything to the screen, but are used to process data relevant to the operation of the airport. For example, simulate a control tower or spawn VFX, like fireworks, when a plane lands. It is worth noting that another benefit of using an airport WASM is that they have a much better performance than the other available solution - standalone modules. This is because standalone modules are *always* loaded, while airport modules are loaded only when needed and then unloaded when no longer needed.

 

 

### Creating The Module

The system module for the airport is created in the same way that you would create *any* WebAssembly module, and the process is outlined here:

-   [Creating A WASM Project](creating-a-wasm-project/)

 

Within the module, the minimum includes that you'll need are as follows:

``` wasm
#include "MSFS/MSFS.h"                   // for MSFS_CALLBACK macro and Debug
#include "MSFS/MSFS_AirportContext.h"    // For FsWasmAirportContext struct
```

 

The rest of the code required will depend on the operations that you wish to perform, but it's important to be aware of the **callbacks** that are generated by the simulation, as these will be essential for your module. To see examples of how these callbacks are used, please check the following SDK sample project:

-   [SimpleWasmAirport](../../samples-tutorials/samples/sceneries/simplewasmairport/)

 

 

#### FsWasmAirportContext

This isn't exactly a callback - it's a struct - but it *is* sent back to the module from every callback, and as such it's very important since it defines the context of the callback information:

``` wasm
#define WASM_AIRPORT_ICAO_SIZE 18
typedef struct {
    char ICAO[WASM_AIRPORT_ICAO_SIZE];
} FsWasmAirportContext;
```

This struct has an `ICAO` member which will contain the {{< glossterm >}}icao_code{{< /glossterm >}} of the airport. This is usually 4 characters long, but can be up to 8 to cover special cases.

 

 

#### AirportInit

When an airport is instantiated, this callback is sent to let the WASM know the airport is ready:

``` wasm
bool AirportInit(
    FsWasmAirportContext* ctx
);
```

This callback is sent the very first frame that the module is initialised, and it contains the airport context `ctx`. The call back will return `true` if the instantiation has been done correctly, otherwise it will return `false` if there is an error.

 

 

#### AirportUpdate

After instatiation the following callback is sent every frame:

``` wasm
bool AirportUpdate(
    FsWasmAirportContext* ctx,
    float dTime
);
```

The callback contains the airport context `ctx`, the delta time `dTime`, ie: the time elapsed since the last frame. The call back will return `true` if everything is correct, otherwise it will return `false`.

 

 

#### AirportKill

The following callback is sent when the airport is "killed" (ie: the instance is removed from the simulation because the user aircraft has moved far enough away):

``` wasm
bool AirportKill(
    FsWasmAirportContext* ctx
);
```

The callback contains the airport context `ctx` that has been killed, and will return `true` if the execution of the "kill" has been done correctly, otherwise it will return `false` if there is has been an error.

 

 

#### Additional Information

It should be noted that:

-   An airport can reference several WebAssembly modules, and they will *all* be executed.
-   The same module can be executed by different airports, but note that this execution *will not be in parallel*, and that the allocated memory will be *shared among all of them*.
-   For airport specific data - especially if a module is shared between several airports - you should *always* use the {{< glossterm >}}icao_code{{< /glossterm >}} to ensure the data retrieved is for the correct airport.

 

 

### The Airport Package

When it comes to setting up the airport to access the WASM, this is done in two stages. The first is to add the relevant files to the package itself. If you haven't got the airport package setup, this is explained here:

-   [Creating Or Replacing An Airport](../../samples-tutorials/tutorials/creating-or-replacing-an-airport/)

 

Once you have your module files, these need to be added into a `wasm` folder at the top level of the airport package beside the airport XML file, eg:

{{< image-center
    src="images/6_Programming/WASM/wasm_airport_1_folder.png"
    alt="Placing The WASM Folder In The Airport Package" >}}

 

Once you have added the files, you need to link them with the airport so that they will run when the airport is instantiated. This is done from [The Scenery Editor](../../devmode/editors/scenery-editor/the-scenery-editor/), using the [WASM Module](../../devmode/editors/scenery-editor/objects/airport-objects/#wasm) section of **airport** object. In this section you simply add the path to the `*.wasm` file of the module, and if you have multiple modules for the airport then they can all be added here.

{{< callout context="note" title="NOTE" icon="outline/bulb" >}}

the path shown in the editor is **output path for the final package** not the **source** path.

{{< /callout >}}

 

If there are any issues with the module (not with the code it contains, but with the package setup), these will be flagged in the editor, for example:

{{< image-center
    src="images/6_Programming/WASM/wasm_airport_2_error.png"
    alt="Example Of An Error Display For A WASM In An Airport" >}}