# Let There Be Flight adds a flying mode to every car in Cyberpunk 2077

> Let There Be Flight is a Cyberpunk 2077 mod that gives all cars a flight mechanism with several modes, built on RED4ext, TweakXL, ArchiveXL, Redscript and Input Loader. It also shifts how explosions behave and lets you eject mid-flight, and it needs manual work on every game update.

**jackhumbert/let_there_be_flight** — A flight mod for Cyberpunk 2077

- Repository: https://github.com/jackhumbert/let_there_be_flight
- Stars: 521 · Forks: 47
- Language: Swift
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jackhumbert-let-there-be-flight

## One flight mechanic, applied to every vehicle in the game

Let There Be Flight is a mod for Cyberpunk 2077 that adds a flying mechanism to all cars, with a couple different modes and options.

The scope is what makes it interesting. This is not a single vehicle with thrusters bolted on; it is a generalisation across the whole vehicle catalogue, with the mode and the options exposed to the player. The README links a video preview of the Drone and Acrobat modes, so at least those two are visually distinct, and the mode naming suggests the flight behaviour is not a single one-size-fits-all treatment.

The other features are small but they shape the feel of the mod. There is an imminent explosion audio indicator, so you get a warning before something goes wrong. Visual explosions happen more readily with other cars, which combined with the audio warning means near misses are more common and more audible. And there is a quick-eject in flight mode, on hold exit, which is the single most sensible design decision in the list: a car that can fly can also crash, and being able to bail out immediately is what makes flying in a dense city tolerable rather than infuriating.

The audience is Cyberpunk 2077 players on PC. The mod ecosystem it plugs into is entirely PC-only, built on the RED4ext and ArchiveXL modding frameworks, so the console versions of the game are out of scope by construction rather than by choice.

## The dependency stack is the real installation

The dependency list is longer than the mod itself, and installing it means installing all of it:

* [RED4ext](https://github.com/WopsS/RED4ext)
* [TweakXL](https://github.com/psiberx/cp2077-tweak-xl)
* [ArchiveXL](https://github.com/psiberx/cp2077-archive-xl)
* [Input Loader](https://github.com/jackhumbert/cyberpunk2077-input-loader)
* [Redscript](https://github.com/jac3km4/redscript)
* [Mod Settings](https://github.com/jackhumbert/mod_settings) (optional)

Five of the six are required and one is optional. RED4ext is the mod loader and the extension framework everything else plugs into. TweakXL handles the tweakable game options. ArchiveXL is the archive format used for the mod's own data files, and the mod ships a .archive and a .archive.xl file. Input Loader is the mechanism that makes the keybindings editable, since the mod's inputs live in an inputs.xml file. Redscript is the scripting layer the mod uses for its game logic. Mod Settings is optional and is what the README means when it says Mod settings values saved by Mod Settings live in its own files, not in the LTBF folder.

Two of these are by the same author as the mod itself, Input Loader and Mod Settings, which suggests a coherent set rather than a grab bag.

The README's installation advice is short, because the real work is in the dependencies: releases are available on the project's releases page, and if you are upgrading, check the release notes for special instructions. That last clause is the one to take seriously, and it comes back later in the upgrade procedure.

The release history shows how tightly this tracks the game. The recent releases are v0.3.18 for game version 2.31 on 2026-09-13, v0.3.17 for 2.30+ on 2025-08-29 and v0.3.15 for 2.30+ on 2025-07-18. The version number in the tag names the game build, not just the mod.

## Keybindings live in an XML file you can edit

The configuration story is unusual for a game mod, because the mod exposes itself as two editable files rather than an in-game menu.

The first is `red4ext/let_there_be_flight/inputs.xml`, which contains all the keybindings for the keyboard and controller, and you can customize these to your liking. The README links the RED4ext input key reference for all the possible keys, which is the sort of documentation a platform mod provides for its own bindings.

The second is `red4ext/plugins/let_there_be_flight/packed.reds`, which is where the other settings live for the time being. The instruction for finding them is a search string: search for `FlightSettings.SetFloat` to see all the variables used by the mod. That is a Redscript call, so the numeric tuning parameters of the flight model are reachable by searching for a specific function call in the packed script file.

So the mod is configured by editing XML for the controls and a Redscript file for the flight parameters. That is a developer-grade configuration surface. It is also why the mod ships a .redscript-ide directory in the repository, which is the editor integration for that file type.

For a player who wants to try the mod, the input file is the one to touch. For a player who wants the flight to feel different, the packed.reds file is where the numbers are, and the search hint is what turns an opaque binary-ish asset into something you can adjust.

## Per-vehicle flight configuration is the extension point

Vehicles can be customized via extending the IFlightConfiguration class, and the README warns that it should not be extended directly if you do not know what you are doing. Instead you are meant to extend one of the three concrete classes: CarFlightConfiguration, SixWheelCarFlightConfiguration or BikeFlightConfiguration.

The example makes the mechanism clear. The class you write overrides a single method, CanActivate, returning a Bool, and the class name encodes the vehicle it applies to. The example disables flight for all vehicles by extending each of the three base classes with CanActivate returning false, and then enables it for one specific vehicle, the Jen Rowley Type 66, through a class named after that vehicle and its variant:

```swift
public class CustomCarFlightConfiguration extends CarFlightConfiguration {
  public func CanActivate() -> Bool = false;
}

public class CustomSixWheelCarFlightConfiguration extends SixWheelCarFlightConfiguration {
  public func CanActivate() -> Bool = false;
}

public class CustomBikeFlightConfiguration extends BikeFlightConfiguration {
  public func CanActivate() -> Bool = false;
}

public class FlightConfiguration_quadra_type66__basic_jen_rowley extends CarFlightConfiguration {
  public func CanActivate() -> Bool = true;
}
```

So the effective result of that snippet is flight for the Type 66 only, and no flight for anything else. The three separate base classes exist because the game has different vehicle chassis categories, and a configuration for a car does not apply to a six-wheel vehicle or a bike.

The naming convention is what makes this work. FlightConfiguration_quadra_type66__basic_jen_rowley parses as the type, the model, and the variant, with a double separator between the segments. The examples directory in the repository shows the same convention applied to other vehicles, with files named FlightConfiguration_br_spinner__basic_black and its black2 and black3 variants, plus one for the methodd oni oni, so the pattern is not limited to one vehicle.

This is a genuinely good extension design for a mod that touches every vehicle in the game. Rather than adding a toggle per vehicle in a config file, you write a small class and the mod resolves which configuration applies to each vehicle by name.

## Updating for a new game build is a manual address hunt

The development section documents what the author does to update the mod for new versions of the game, and it is the most important thing to understand about the project as a piece of software.

The steps are listed as some of the steps the author takes to update the mod for new versions of the game, and it involves manual address look-up using IDA, a custom version of Zoltan, and the author's fork of RED4ext.SDK. Then the individual steps: merge deps/red4ext.sdk from upstream, update all addresses with the current version marker in RED4ext.SDK, with patterns and hints for each address in each file, and a note that addresses that do not have the current version likely are not used by the mod. Then run Generate Addresses in the VS Code project, update the game option addresses in src/red4ext/FlightSystem.cpp, and update the RED4ext.SDK VFTs, which involves uncommenting the VFT finder in a specific line of FlightSystem.cpp and then, and this is the striking part, running the game until it crashes, which is expected, and copying the defines from the mod's log file into the SDK header.

That last step is the one that tells you what kind of project this is. The mod hooks into game internals by absolute address, and when the game changes, those addresses have to be rediscovered by running the game until it faults in the right place, then reading the fault address out of the log. It is the standard technique for this class of mod, and it is why every release is tied to a specific game build and why the release notes matter.

The repository layout backs this up. There is a src/ directory with a red4ext subdirectory holding FlightSystem.cpp, a deps/ directory holding the red4ext.sdk submodule, a .vscode/ directory for the Generate Addresses task, a CMakeLists.txt and cmake/ directory, an experiments/ directory, tools/ and docs/ directories, and a CLAUDE.md file at the root.

The maintenance cost for a user is therefore a fixed amount of work per game update: install the new release, read the release notes, and possibly redo the steps. It is not a set-and-forget mod.

## Uninstalling is a batch file, and the file list tells you what it does

Uninstallation is handled by a script that ships in the zip next to the plugin folder. Run `red4ext/plugins/let_there_be_flight_uninstall.bat`, and it deletes every LTBF file and the plugin folder, then itself. The dependencies are left alone, which is the right behaviour since other mods may be using them.

The README also lists the files the mod installs, which is useful documentation in its own right because it shows the shape of the installation:

```
red4ext/plugins/let_there_be_flight/            (the whole folder)
    let_there_be_flight.dll
    let_there_be_flight.archive
    let_there_be_flight.archive.xl
    let_there_be_flight.tweak
    let_there_be_flight.yaml
    packed.reds
    module.reds
    inputs.xml
    base_sounds.bank
    base_sounds.strings.bank
    fmod.dll
    fmodstudio.dll
    readme.md
    license.md
red4ext/plugins/let_there_be_flight_uninstall.bat
```

Two things stand out. The .archive and .archive.xl pair is the ArchiveXL data format, so the mod carries its own game assets in the modern archive layout. And fmod.dll and fmodstudio.dll are the FMOD audio engine libraries, which is why the mod ships its own copies of them rather than relying on the game's.

The base_sounds.bank and base_sounds.strings.bank files are the FMOD sound banks, which is where the audio side of the mod lives, including the imminent explosion indicator.

For a manual uninstall, the README says to delete the same list from the game folder, which is everything the mod installs.

The crash reporting section is worth a mention too, because it is unusually thorough. To report a crash you are asked to expand What does this report contain? in the crash handler window, find the Cyberpunk2077.dmp file, and copy it along with the red4ext/logs/ctd_helper.log file, and to do that before running the game again because it will be overwritten on each launch. Including both files makes it a lot easier to track down bugs, which for a mod that hooks game internals by address is the difference between a fixable report and an unreproducible one.

## Translating the mod means shipping a WolvenKit archive pair

The localisation workflow is unusual and worth understanding, because it tells you something about how this mod is distributed.

The en-us localisation dictionary lives at a WolvenKit source path in the repository and is a JSON-formatted file. To create a new translation, you copy that file and adjust all of the femaleVariant values, and you use the standard language tag such as en-us or fr-fr as the file name. You can then send it to the author to be included with the mod, or host it yourself on Nexus or elsewhere.

Hosting your own language pack is the interesting branch, because it requires you to package it as a WolvenKit archive. You will need to use Wolvenkit convert and pack this into an .archive file, named with the language tag, for example let_there_be_flight.fr-fr.archive, and that file has to be paired with a let_there_be_flight.fr-fr.archive.xl file to be read correctly by ArchiveXL:

```yaml
localization:
  onscreens:
    fr-fr: user\jackhumbert\localization\let_there_be_flight.fr-fr.json
```

You will need to replace all fr-fr instances with your language code.

The reason for the .archive plus .archive.xl pairing is the ArchiveXL dependency: a modern archive is not a single self-describing file, it needs a sidecar index file, and the mod's own installation shows the same pattern with let_there_be_flight.archive and let_there_be_flight.archive.xl sitting next to each other.

So the translation effort splits in two. The JSON dictionary is a text file anyone can edit. Turning it into something the game will load requires the WolvenKit conversion and a two-file output that has to be placed correctly. The README credits WolvenKit and its team, along with RED4ext, the Redscript toolkit, CET, and the FMOD-related help, which is the dependency list of a Cyberpunk 2077 mod in general rather than this one specifically.

## Where Let There Be Flight is the wrong tool

The first wrong-tool case is console play. The whole stack, RED4ext, ArchiveXL, TweakXL, Redscript, is a PC modding framework. There is no console version of this mod and there cannot be one on this architecture.

The second case is a player who does not want to manage a dependency stack. Six dependencies, one optional, each of which is another mod that can conflict with others, is a real cost. If you already run a large Cyberpunk 2077 mod list, every one of those has to be compatible with RED4ext and ArchiveXL, and the README does not document a compatibility matrix for the mod list.

The third case is a player who expects a mod to keep working across game updates without intervention. The release tags are named for the game build they target, v0.3.18 for 2.31, and the upgrade procedure described in the development section involves rediscovering addresses by running the game until it crashes. This is a mod you re-adopt after each patch, not one that persists.

For the alternative approach, the difference in approach is between adding a new capability to the game and changing the behaviour of an existing one. Other Cyberpunk 2077 mods exist for vehicle handling, for physics, for netcode, for the HUD, and for overhauled graphics. The difference in approach here is that this mod extends the vehicle logic with a flight mode and a per-vehicle configuration system, and does so by hooking the game at a low level and reading its option addresses, whereas a handling mod tunes parameters that already exist. If what you want is a different driving feel, a handling mod is less work and less breakage. If you want to leave the ground, this is the one to look at.

## Conclusion

Let There Be Flight suits a Cyberpunk 2077 player on PC who wants a flight mechanic across the whole vehicle roster and is willing to keep a stack of mod dependencies updated. It does not suit console players, or anyone who wants a mod that survives a game patch without intervention, since every release is tied to a specific game build. Before installing, read the release notes for the version matching your game, install the listed dependencies in order, and check the compatibility of your own mods against RED4ext and ArchiveXL before you start a long session.

## FAQ

### What does the Let There Be Flight mod do in Cyberpunk 2077?

It adds a flying mechanism to all cars, with a couple different modes and options, plus an imminent explosion audio indicator, explosions that happen more readily with other cars, and a quick-eject in flight mode on hold exit.

### What does Let There Be Flight need to be installed?

RED4ext, TweakXL, ArchiveXL, Input Loader and Redscript are required, with Mod Settings optional. The mod itself comes from the releases page, and the README says to check the release notes for special instructions when upgrading.

### How do I disable flight for some vehicles in Let There Be Flight?

Extend CarFlightConfiguration, SixWheelCarFlightConfiguration or BikeFlightConfiguration and override CanActivate to return false, then name the class after the vehicle and variant you want to enable, for example FlightConfiguration_quadra_type66__basic_jen_rowley, and return true there.

### Where are the Let There Be Flight settings stored?

Keybindings are in red4ext/let_there_be_flight/inputs.xml, and the other settings are in red4ext/plugins/let_there_be_flight/packed.reds, where searching for FlightSettings.SetFloat shows all the variables the mod uses.

## Sources

- [Issues](https://github.com/jackhumbert/let_there_be_flight/issues)
- [jackhumbert/let_there_be_flight on GitHub](https://github.com/jackhumbert/let_there_be_flight)
- [License: MIT](https://github.com/jackhumbert/let_there_be_flight/blob/main/LICENSE)
- [README](https://github.com/jackhumbert/let_there_be_flight/blob/main/README.md)
- [Releases](https://github.com/jackhumbert/let_there_be_flight/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jackhumbert-let-there-be-flight