技术文档

Build and install (MSFS 2024)

此页为项目的英文技术文档原文。 docs/BUILD_AND_INSTALL.md

The aircraft is one MSFS package (msfs2024/): models, textures, flight model, the systems WASM module (lu737_systems.wasm, the rewrite of the Zibo logic) and, as they are written, the HTML display units. Nothing runs outside MSFS: the former LU737 Host and its WebSocket link are gone (see docs/REWRITE_PLAN.md).

Everything generated is committed, including the built WASM module, so you only need the toolchains below to change the generators or the code (section D). GitHub Actions builds and tests the module on every push.

A. Build the package in MSFS 2024#

Prerequisites: MSFS 2024, the MSFS 2024 SDK (Developer Mode → Help → SDK installer), Developer Mode enabled (Options → General → Developers).

  1. Clone or download the branch claude/737ng-xplane-msfs-convert-wel44p (the textures are ~700 MB).
  2. Developer Mode → Tools → Project Editor → File → Open project… → msfs2024\LevelUp737NG.xml.
  3. Select the package levelup-aircraft-737ng and Build All. Output: msfs2024\Packages\levelup-aircraft-737ng. The first build converts ~85 large PNG textures to DDS and takes a while.
  4. Keep the Console (Developer Mode → Tools → Console) open and save its errors/warnings for the test report.

Command-line alternative (path depends on your SDK install):

"C:\MSFS 2024 SDK\Tools\bin\fspackagetool.exe" "msfs2024\LevelUp737NG.xml" -nopause

Thirteen original textures are 8192 px (≈2.5 GB of GPU memory for all textures). If the SDK rejects them or memory is tight, rebuild with python3 tools/build_package.py --max-tex 4096 (section D).

If the modular SimObject layout (common/, presets/, liveries/) is rejected, generate the classic single-folder layout with python3 tools/build_package.py --skip-models --legacy and build msfs2024-legacy\LevelUp737NG.xml instead.

B. Install#

Copy (or junction-link) msfs2024\Packages\levelup-aircraft-737ng into the MSFS 2024 Community folder and restart the sim. The aircraft is "LevelUp 737-800 (CFM56-7B26)".

C. Check the systems module in the sim#

panel.cfg loads lu737_systems.wasm as the gauge LU737_Systems (VCockpit01, no texture). With the aircraft loaded:

  • the Console shows LU737 systems: initialised;
  • L:LU737_WASM_ALIVE = 1, L:LU737_WASM_BUILD = the build number in wasm/src/core/version.h, L:LU737_WASM_FRAME and L:LU737_WASM_TIME increase (Developer Mode → Tools → Behaviors → LocalVariables, or any L:var watch).

The current milestone and what to report are in docs/TEST_PLAN.md.

D. Regenerate from source#

Requirements: Python 3.11+ with numpy and Pillow; clang 18 + lld 18 with wasm32 support (Ubuntu: apt install clang-18 lld-18); Node.js 20+ for the display units.

python3 tools/build_package.py

Order: configs and panel.cfg from 737_80NG.acf → all original objects and textures (tools/convert/convert_aircraft.py, ~12 min the first time, cached after) → behaviour XML on the stable cockpit interface (data/sci; table data/cockpit_io.json) → the systems module (wasm/build.sh install; skipped with a note when wasm-ld is missing, keeping the committed module) → project files → the display units (npm run build in avionics/). --skip-models reuses build/model and build/texture; --skip-wasm keeps the committed module.

Systems module#

wasm/build.sh test

wasm/build.sh install

The first runs the native unit tests; the second builds wasm/out/lu737_systems.wasm, checks its imports/exports/feature set and copies it into the package's panel folder. The SDK headers and sysroot are in third_party/msfs2024-sdk. CI: .github/workflows/build-wasm.yml (artifact lu737_systems-wasm).

Oracle (original plugins, for comparison tests)#

The original Zibo/LevelUp plugins (lin_x64) run headless in the X-Plane plugin host kept as a test tool, with the stable cockpit interface (SCI). It is not part of the package.

xphost/build.sh

xphost/out/linux/lu737host --aircraft . --cold --sci-test xphost/test/sci/elec_cold_start.json

python3 xphost/test/replay_smoke.py

lu737host --replay in.bin --out out.bin feeds the plugins recorded frame inputs and writes their outputs (protocol in xphost/src/bridge.h); the differential tests of the rewrite use it. CI: .github/workflows/oracle.yml.

Reading the original logic#

tools/re/setup_decompiler.sh builds Ghidra's native decompiler from the Ghidra sources; python3 tools/re/decompile.py <function> prints a zibomod function (Linux build, which keeps its symbols) with its constant tables resolved. Output is for reading only and is not committed.