LOOT Plugin Load Order Optimizer for Starfield and Bethesda Game Mods

LOOT's scope for Starfield, Skyrim, Fallout, and related games

LOOT addresses a specific problem in modding for supported games: plugin files have dependencies, compatibility conflicts, and relative load priorities that are difficult for a player to maintain by hand. Its target audience is therefore not a general game developer, but a player or mod-list curator who already knows how plugins and mod load orders work. The README explicitly says that users should retain a working knowledge of mod load ordering.

The supported list is broad. It includes Starfield, Morrowind, Oblivion, Oblivion Remastered, Skyrim, Skyrim Special Edition, Skyrim Anniversary Edition, Skyrim VR, Fallout 3, Fallout: New Vegas, Fallout 4, Fallout 4 VR, Nehrim: At Fate's Edge, Enderal: Forgotten Stories, OpenMW, and several Enderal variants. The game list alone does not guarantee identical feature coverage. The Linux build documentation warns that not every feature has been implemented there, and says that issues labelled `linux` cover missing features where implementation is possible.

LOOT also supports Wrye Bash through Bash Tag suggestions, but it is not a Wrye Bash replacement. Its stated contribution is metadata, warnings, usage notes, and ordering assistance. A user who needs a feature specific to another mod manager should check the platform documentation and issue tracker before adopting it.

Metadata-driven ordering and conflict detection

The central mechanism is LOOT's calculation of a plugin load order from plugin metadata. According to the README, LOOT aims to satisfy all plugin dependencies while maximizing each plugin's impact on the game. That is a constrained ordering problem rather than a simple alphabetical sort. The metadata supplies enough information for LOOT to determine which plugins must appear before or after others and which plugins have conditional or game-specific requirements.

The repository layout indicates that the application is built in C++ and includes a separate `libloot` dependency. CMake variables such as `LIBLOOT_GIT_REPOSITORY`, `LIBLOOT_GIT_COMMIT`, and `LIBLOOT_URL` control where that library is obtained. This separation matters to operators building from source because it gives them control over the library source or archive used during compilation.

LOOT maintains a masterlist of metadata for each supported game. Users can add custom metadata, which is the documented extension point when a plugin is sorted incorrectly or needs a specific warning. LOOT also claims to detect many issues and provides plugin-specific usage notes, warnings, and Bash Tag suggestions. The metadata is consequently part of the product, not merely an optional description beside the code. A stale or incomplete masterlist can limit the quality of an ordering decision even when the executable itself works correctly.

Installing a release or Flatpak on Linux

The README directs users to the GitHub Releases page for normal downloads. For Linux, it specifically recommends installing the application from Flathub. The page also links to an unofficial AUR package, but that package is separate from the project's official release guidance and should be evaluated under its own maintenance and compatibility conditions.

A real first installation path for a downloaded single-file Flatpak is shown below. Place the bundle in your downloads directory, then run the command. The README presents this exact command as the installation method for a snapshot Flatpak bundle.

flatpak --user install ~/Downloads/loot.flatpak

The `--user` option installs the bundle for the current user rather than requiring a system-wide installation. After installation, open LOOT from the desktop environment and select the game directory or installation that you want to manage. The README does not document a command-line workflow for calculating an order, so it would be misleading to invent one. The first practical check is that the correct supported game is detected and that LOOT can read the game's plugins and masterlist data.

Snapshot artifacts have additional constraints. They are retained for 90 days, can be downloaded only by a logged-in GitHub account, and are accompanied by a GPG signature. The release workflow also uses several Windows build dependencies, including CMake, curl, gettext, Git, Inno Setup 6, Python, Visual Studio 2022, and 7-zip. Those build requirements are separate from the requirements for installing an already packaged application.

Building LOOT from the repository on Linux

For a non-Flatpak source build, the README gives an Ubuntu 24.04 example. It installs the Qt 6 base development package, Boost locale, ICU, TBB, Rust tooling, CMake, a C++ compiler, and Git. The example then configures a Release build and compiles it with CMake. These commands are for producing the project, not for installing an end-user package.

sudo apt-get install cmake g++ git libboost-locale-dev libicu-dev libtbb-dev qt6-base-dev rustup
rustup default stable
git clone https://github.com/loot/loot.git
cd loot
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel

The source build may need the dependencies fetched through CMake. The README's CMake table says that `LIBLOOT_GIT_REPOSITORY` defaults to the libloot Git repository and `LIBLOOT_GIT_COMMIT` selects a release commit by default. It also notes that older dependency versions available through a Linux distribution may work less well than the versions used in CI.

The Linux build has two concrete boundaries. First, not all application features are implemented in Linux builds. Second, binaries built in the `linux` dev container can link against libraries unavailable on the host distribution. The repository also contains a Flatpak build path, but `scripts/generate_manifests.sh` and `scripts/build_flatpak.sh` cannot run in an unprivileged container. That restriction makes containerized build environments unsuitable unless they are configured with the expected privileges.

Cross-platform constraints and dependency choices

LOOT's build system exposes choices that directly affect the resulting binary. On Windows, the documented process assumes Visual Studio 2022 and several command-line tools. Cross-compiling from Linux is possible, but the README does not recommend it because support for symlinks and long paths is more limited. A `mingw.shared` dev container is offered with a specific toolchain configuration, while a `mingw.static` dev container can produce a statically linked `LOOT.exe`, except for `libloot`, which remains a DLL.

The static option carries a documented functional warning. It uses an older `libstdc++` that does not properly support overwriting files when copying them, which breaks some LOOT functionality. That makes the static container unsuitable when file replacement behavior matters. The shared container example uses Qt paths under `/opt/qt/6.11.1`, so copying the command into a machine without those paths will not reproduce the documented build.

These details show why source-build adoption is different from installing a release. A binary can compile successfully while still having platform gaps, unavailable shared libraries, or a known copy-file defect. The right artifact depends on whether the user needs complete Windows features, Linux portability, or reproducible dependencies rather than merely whether a compiler command completes.

Maintenance, licensing, and upgrade boundaries

The repository is not archived. Its recorded last push was on 2026-10-15, and the release history includes `0.29.2` from 2026-08-16, `0.29.1` from 2026-04-18, and `0.29.0` from 2026-04-11. This information establishes recent repository activity, but it does not guarantee that every supported game or Linux feature receives equal attention.

LOOT is distributed under GPL-3.0. For organizations that modify and redistribute the program, the practical implication is to review how the GPL obligations apply to the distribution and source-code provision. This is a licensing boundary, not an endorsement or a substitute for legal review. Users who only install an unchanged package should distinguish that case from distributing a modified build.

Upgrades can involve more than replacing the executable. Masterlist metadata, plugin-specific notes, translations, and the separately resolved libloot code are all relevant to behavior. The README does not provide a rollback procedure, so users who depend on a particular mod list should preserve their own game configuration and confirm compatibility before changing versions. It also does not claim that every feature is available on every platform. A version comparison should therefore include the supported game list, metadata state, and operating system rather than checking only the release number.

LOOT versus manual ordering and Wrye Bash

The clearest alternative is manual plugin ordering, supported by a player's own knowledge and by comments in the mod list. Manual editing offers direct control over every entry and does not depend on whether a plugin has metadata. Its weakness is that maintaining a large list requires repeated interpretation of dependencies and conflicts.

LOOT changes that workflow by calculating an order from metadata and presenting warnings and usage notes. The result is easier to reproduce, but the automation is only as complete as the metadata available for the plugins in the installation. The README explicitly acknowledges that some plugins need additional metadata.

Wrye Bash is another related option, but the difference is scope. LOOT supplies Bash Tag suggestions for Wrye Bash, which means it can complement that ecosystem without attempting to replace every Wrye Bash feature. Users who already depend on Wrye Bash Bash Tags should keep that boundary in view. Users who want a standalone ordering utility may find LOOT more focused, while users who need a full mod-management workflow should check the missing feature list before migrating.

Editorial conclusion

Adopt LOOT if you manage mods for one of its supported games and want metadata-driven load order calculation with issue detection. Do not treat it as a replacement for understanding plugin dependencies or as a guaranteed fix for every mod conflict. Verify first that your game and edition are supported, that the installed masterlist is current, and that your platform receives the features required by your workflow.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. loot/loot on GitHub
3. Project website
4. README
5. Releases