me3 attaches a mod host to FromSoftware games instead of patching game files

me3 attaches a host DLL to the running game instead of editing game files

me3 describes itself plainly as "a framework for modifying and instrumenting games", and the first sentence of the project description narrows that to games from FromSoftware. The implementation shape is visible in the workspace: crates/cli, crates/launcher, crates/mod-host, crates/mod-protocol, crates/mod-host-types, crates/mod-host-assets, crates/launcher-attach-protocol and crates/ipc.

The distribution tells the same story from the outside. The Makefile assembles three Windows artifacts, me3.exe, me3_mod_host.dll and me3-launcher.exe, and the developer quickstart describes the last step as attaching the sample host DLL to your game. So the model is a launcher that starts a game with a host library present, and that host talks to the tooling over a defined protocol rather than through loose shared memory.

Instrumentation and modification are the same mechanism here. A mod that wants to observe or alter game state does it through the host, and the protocol crate is what makes that surface explicit instead of ad hoc. The workspace also carries crates/env for environment handling, crates/telemetry and crates/binary-analysis, the last of which pairs with the pelite dependency for working with executable files.

For users, the point of this arrangement is that the game directory stays clean. Nothing in the quickstart asks you to overwrite files in an installed game.

Windows is the direct target, Linux and macOS arrive through Proton and CrossOver

The supported platform list is short and specific: Windows, Linux via Proton, and macOS via CrossOver. That ordering is a statement about where the work happens. The toolchain in the developer quickstart is Windows-first, with the Visual Studio C++ Build Tools and a rustup installer named as the Windows path, and the cross-compilation setup in the Makefile targets x86_64-pc-windows-msvc for the Windows binaries.

The game list covers five titles: DARK SOULS III, Sekiro: Shadows Die Twice, ELDEN RING, Armored Core VI: Fires of Rubicon, and ELDEN RING NIGHTREIGN. Two of those are recent enough that the project's release cadence has been exercised against them, which is a hint about how the compatibility work is organised.

The portability story has a catch worth naming: on Linux and macOS you are not running a native build, you are running the Windows build under a compatibility layer, and on Linux you also need Proton for the game itself. That is workable, but it means two layers of translation sit between you and the game, and a debugging session can end up inside either one. The developer quickstart makes the same point implicitly when it sets Cargo's runner to wine for the Windows target.

Documentation is published in English, Chinese and Polish, with Crowdin handling the translation workflow.

Building on Linux means pulling a Windows SDK down with xwin

The quickstart assumes you can build the Windows artifacts from any host. On Linux the Rust toolchain is installed the usual way:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

The harder half is the SDK, because a Windows target needs the Windows SDK headers and libraries. The project uses xwin for that:

cargo install xwin && xwin --accept-license splat --output ~/.xwin

After that, Cargo is pointed at lld-link and at the binaries xwin produced, in ~/.cargo/config.toml:

[target.x86_64-pc-windows-msvc]
linker = "lld-link"
runner = "wine"
rustflags = [
  "-Lnative=/home/gtierney/.xwin/crt/lib/x86_64",
  "-Lnative=/home/gtierney/.xwin/sdk/lib/um/x86_64",
  "-Lnative=/home/gtierney/.xwin/sdk/lib/ucrt/x86_64"
]

The paths in that snippet carry the maintainer's home directory, so they need editing for your machine.

The build itself is the ordinary Cargo sequence: clone the repository, then build the binaries.

git clone https://github.com/garyttierney/me3.git
cargo build [--release]

The last step attaches the sample host to a running game, and the game is named with a flag:

cargo run -p me3-cli -- launch -g elden-ring

Note that the release build flag is shown in brackets, meaning it is optional, and the bracketed argument is not a literal command line. Running the launch command with the elden-ring identifier is how the sample host gets attached during development.

The virtual filesystem layer borrows from Mod Organizer 2, the runtime from Mod Engine

The acknowledgements name two prior projects and say what each one contributed. Mod Engine is credited as prior art for runtime modification of FromSoftware games, and Mod Organizer 2 is credited as the inspiration for the VFS framework. Those two references describe the design lineage accurately: one for the act of hooking a running game, the other for the idea of layering a virtual filesystem over an unmodified installation.

me3's own contribution, as far as the repository shows, is the decomposition. A launcher crate, an attach protocol crate, a mod protocol crate, host types, host assets and a separate IPC crate are six distinct places where behaviour lives, and the binary set matches: a launcher executable, a host DLL and a CLI. Mod Organizer 2 is a single application with a plugin model, and Mod Engine is a standalone runtime injector, so the difference in approach is that me3 splits the launcher, the host and the wire protocol into separately versioned crates with a schema directory and schemars in the dependency list to generate the schemas for them.

The rest of the acknowledgements show how much of the work is compatibility feedback. A community mod called Elden Ring Reforged is credited with invaluable feedback on the end-user perspective, and Dasaav is credited with work on compatibility across a variety of FromSoftware titles. That tells you where the rough edges of a new title get smoothed: from outside the project, in the field.

One Makefile cross-compiles the tarball, the zip and the installer

The release engineering lives in the Makefile, and it is unusually explicit for a project of this size. Targets exist for a Linux tarball, a Windows zip and a Windows installer, with DESTDIR defaulting to out. The cargo_build helper pins SOURCE_DATE_EPOCH to the last commit timestamp, passes the commit id in as BUILD_COMMIT_ID, uses support/rustc.wrapper as RUSTC_WRAPPER, and builds with --locked and --features=sentry --release.

Reproducibility is handled by cargo vendor-filterer, which produces a tar.zstd of vendored dependencies for the platforms named in the workspace vendor filter: x86_64-unknown-linux-gnu, x86_64-unknown-linux-musl, x86_64-pc-windows-msvc and x86_64-pc-windows-gnu. The changelog becomes a PDF through pandoc before the installer is assembled, and the Windows binaries are signed using a certificate under releng.

Packaging covers three formats, which matches a project that has to serve three operating systems: installer.nsi for the Windows installer, installer.sh for a shell-based Linux install, and me3.spec for distribution packaging.

For the Windows binary, code signing is free through SignPath.io with a certificate from the SignPath Foundation, and the policy document is in the tree. The practical consequence for a user is that a signed Windows build avoids the usual smart-screen friction, which matters when the tool attaches a DLL to a game process.

Telemetry, crash reporting and an AI contribution policy sit in the build

Two things in the tree are worth a user's attention before installing anything. The first is telemetry: the workspace carries a telemetry crate published as me3_telemetry, and the release build enables the sentry feature through CARGOFLAGS, with sentry itself in the dependency list. Sentry is also listed as a sponsor, so the crash reporting service is part of the supported stack rather than a leftover dependency.

The second is process. The repository root carries AI_CODE_POLICY.md next to CONTRIBUTING.md, SECURITY.md, CODEOWNERS and RELEASE_CHECKLIST.md, plus a pre-commit configuration and a separate policy document for how contributions that use AI assistance are handled. The project documentation is explicit about it: contributors are asked to read the contribution policy to learn how the project strives and how AI-assisted contributions are handled.

The dependency list is small enough to read. Beyond the usual clap for argument parsing and eyre for error reporting, two entries explain the shape of the project: rkyv at version 0.8.14 for zero-copy serialisation, which suits a protocol that ships data between processes, and pelite at version 0.10, a PE file parser, which fits the binary-analysis crate and a tool that attaches to a game process. normpath, memmap and memchr handle paths and file access, and schemars generates the JSON schemas in the schemas directory.

The workspace targets Rust edition 2024 with a rust-version of 1.95, so a recent toolchain is a hard requirement rather than a suggestion.

The release tags and the workspace version string tell different stories

The published tags are v0.12.0 on 2026-07-18, v0.12.1 on 2026-07-19 and v0.13.0 on 2026-08-11. The last push was on 2026-10-14, so work has continued after the newest tag, which is normal for a project with an active changelog and a release checklist.

Inside the workspace, though, the shared package version reads 0.6.0-prerelease. Two readings are possible: the version field may simply not be the source of truth for the release numbering, or the crates may have been versioned separately for a while. Nothing in the tree settles it, and for anyone writing automation against the crate versions that is a genuine ambiguity to resolve with the maintainers rather than guess at.

End-user installation has the same documentation gap. The installation section of the README contains no commands at all; it points to the user guide at me3.readthedocs.io. For a developer that is acceptable, since the quickstart gives the source path. For a player who wants a working launcher with mods, the practical steps live in documentation this README does not restate, and the docs site rather than the repository is the place to start.

Licensing is worth reading closely: everything except the logo is under both the Apache Software License 2.0 and the MIT License, with LICENSE-APACHE and LICENSE-MIT in the tree, and the me3 logo is explicitly not available under any licence. Mod authors who want to ship the artwork need to sort that out separately.

Editorial conclusion

me3 is a good fit for mod authors who need runtime hooks across several FromSoftware titles and want the mod host, the launcher and the IPC protocol separated into their own crates, and for players on Linux or macOS who want a path that does not require a Windows-only setup. It is the wrong tool if you want a single-file injector or if you need a stable, documented end-user install procedure, since the README sends you to the readthedocs quickstart and the workspace version string does not line up with the release tags. Check the mod host DLL that ships with your build, confirm that your game title appears in the supported list, and read the documentation before assuming the launcher behaves like a conventional mod manager.

Frequently asked questions

Official sources

1. garyttierney/me3 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases