rpfm reimplements the Total War modding tool in Rust and Qt6

A rewrite of PFM, not a wrapper around it

PackFile Manager has long been the tool of choice for Total War modding, and Rusted PackFile Manager is a rewrite of it rather than an extension. The project describes itself as a Rust and Qt6 reimplementation of PFM, and states that it opens, inspects, edits and saves PackFiles for every Total War game since Empire: Total War. Where the original was a Windows tool, this one ships as a set of platform packages, with the Linux side documented in the README down to the individual system libraries.

The scope of the editors is the reason it is interesting. The project ships integrated editors for DB tables, Loc files, scripts, animations, portrait settings, rigid models, videos, and what it describes as a long list of other formats. Each of those is a format that has its own internal structure, and a modder who changes one of them by hand is editing binary or text data whose meaning is defined by the game's own schema files.

The rewrite brings a different kind of value, and it is worth being honest about what it is. It is not a claim that the tool is faster, because the README makes no performance claim. The gain is architectural: the same code is available to the desktop app, to a headless server and to third party tools, which is the subject of the next section. The rest is a working, MIT licensed tool that covers every Total War since Empire: Total War, and the author is explicit that it should be read through before use, since the manual is linked at the top of the README.

The UI is a thin client over rpfm_server

The architectural decision in rpfm is that the desktop application and the backend are separate pieces. The crate list makes this explicit. `rpfm_lib` is the core file format library, covering packs, schemas, DB, Loc, RigidModel, audio and video. `rpfm_extensions` holds higher level workflows such as dependencies, diagnostics, search, the optimizer, the translator and glTF export. `rpfm_ui_common` holds shared Qt6 helpers used by every UI consumer. `rpfm_telemetry` handles logging, crash reporting and opt-out action telemetry. `rpfm_ipc` is the command and response protocol shared between UI and server.

The two executables are `rpfm_ui`, the Qt6 desktop application most people interact with, and `rpfm_server`, the backend that does the heavy file, schema and filesystem work. The UI spawns the server automatically.

That split has a consequence worth planning for. Because the two communicate over a command and response protocol rather than by calling functions directly, the same backend can be driven by something other than the Qt interface. A second UI, a script, or a test harness can speak the protocol instead of opening a window. It also means the work that is slow, and the work that touches the filesystem, happens in a process you could run on its own.

WebSocket and MCP are exposed by the backend

The README states that rpfm_server exposes WebSocket and MCP for AI tools. That single line is the most unusual thing in the project, and it changes what kind of tool this is.

A WebSocket endpoint means the backend can be driven over a network socket by a program that is not the bundled UI. MCP, the Model Context Protocol, means an AI assistant can be given tools that read and edit pack files, so a modder can ask for a table to be opened, a column to be inspected or a value to be changed without a human clicking through a tree view.

The audience this opens up is third party tool authors, and the README says as much: the crates exist so the same code can power the desktop app, a headless server, and any third-party tool that wants to read or write Total War files. For that group, `rpfm_lib` is the interesting piece, since it is the file format layer and it does not require the UI at all.

Two things are not documented in the README and would need checking before building on the protocol: the authentication and exposure model of the WebSocket endpoint, and which MCP tools are actually registered. A server that can modify your game files is not something to expose to a network you do not control, and the README says nothing about bind addresses, tokens or what a caller is allowed to do. The manual is where to look.

Schemas, not autodetection, decide how a file is parsed

The `schemas` directory holds RON schema files for every supported game, plus runtime patches and animation IDs. The `old_ak_files` directory holds archived Assembly Kit definitions for Empire and Napoleon, with the note that no Assembly Kit was ever shipped for those two titles. The `install` directory holds per platform packaging scripts, covering a Linux tar.zst, Flatpak, AUR and a Windows zip.

The schema approach is the load bearing idea in the whole project. A DB table, a Loc file or a rigid model has a structure that differs per game and changes between versions, and a schema file per game is how the library knows how to read and write each one. The runtime patches and animation IDs sit alongside those schemas for the cases where a file deviates from the expected shape.

The practical implication for a modder is that a new game or a new patch is not automatic. The library can only parse what it has a schema for, so a title that is not covered means the format is unknown and the tool cannot help. For anyone evaluating the project, the right first check is therefore not whether the interface looks right but whether the `schemas` folder has your game, and how recently it was updated.

The Rust side of the build is arranged around a workspace of seven active crates, with a commented out `rpfm_gpui` member suggesting an experimental alternative front end:

Building needs Rust 1.89 and a vendored Qt binding layer

The workspace definition at the root of the repository sets the shared metadata and the crate list:

[workspace]
resolver = "2"
members = [
    # Libs
    "rpfm_lib",
    "rpfm_extensions",
    "rpfm_ipc",
    "rpfm_telemetry",
    "rpfm_ui_common",

The shared package block pins the compatibility floor:

[workspace.package]
version = "5.2.0"
authors = ["Frodo45127 <[email protected]>"]
rust-version = "1.89"
edition = "2021"

The dependency list shows how the Qt bindings are obtained. Instead of pulling a published binding crate, the workspace points at paths inside `3rdparty/src/ritual`, with `qt_core`, `qt_gui` and `qt_widgets` resolved from generated output and a `cpp_core` crate beside it, and the `3rdparty` directory is excluded from clippy because of a comment about the code generator. In other words, building from source means generating or building the Qt bindings locally rather than downloading a prebuilt one, which is the kind of detail that turns a fifteen minute clone into a long afternoon.

The rest of the profile configuration is a performance-minded setup, with thin link time optimisation and debug symbols enabled in the release profile, and the Qt crates compiled with reduced code generation units. The repository also carries `AGENTS.md`, `CLAUDE.md` and `GEMINI.md` at the root, a `CHANGELOG.md`, a `CONTRIBUTING.md`, a `book.toml` for the manual, and `test_files/` for the test suite.

Windows is a zip, Linux is a package, macOS is not there yet

The requirements section is short and worth reading literally. On Windows the instruction is to just download, extract and run. On Linux, Arch Linux and derivatives have it in the AUR as `rpfm-bin`, and other distributions need Qt6, xz and 7zip installed, or the Flatpak. For macOS the README says you will know it when the author manages to compile it for Mac, which means there is no macOS build to install today.

Downloads are hosted as GitHub releases, and the FAQ explains a point that catches people out: if there is no `.exe` in what you downloaded, you downloaded the source code rather than the program. The project also publishes an AUR package badge, so the Arch route is a first class installation path rather than a community afterthought.

There is a second FAQ entry about contributing a mod translation, and it describes a workflow that is worth knowing even if you never translate anything. You use the translator tool to produce a translation JSON and submit it to the Total War Translation Hub repository, where Runcher picks it up automatically for any user with translations enabled. That is a decentralised path for user contributed content, and it depends on the translator crate in `rpfm_extensions`.

Translating the interface is a file copy in the locale folder

The interface translation process is the simplest thing described in the whole README. You go to the `locale` folder, copy `English_en.ftl`, rename it to the name you want with your language code, for example `Español_es.ftl`, and translate it. The format is Fluent, with the `.ftl` extension doing the work of identifying the file, and the pattern means a new language is a new file rather than an edit to a shared one.

That simplicity has a consequence. Because each language is a separate file, translations do not merge, and a string added to the interface in a later release is simply missing from every translation until somebody updates the file. The repository does not say how that is handled, so if you are maintaining a translation you will want to check the project documentation for how new strings are supposed to reach existing locale files.

The project also lists a credit roll of contributors by area, which is a good indicator of where the project has actually needed help: the core work is credited to Frodo45127, with extra programming by Vandy, DDS read support by Phazer, AnimPack research, Ca_vp8 research, LUA functions and LUA types for Kailua, RigidModel research, and TW: Arena research and coding credited to other named people. The application icons are credited up to v1.6.2 to one contributor and from v2.0.0 to another. Reading that list tells you that a rewrite of this size was assembled over years by a small group, and the project is MIT licensed with the licence file in the repository root.

Editorial conclusion

rpfm fits a modder who wants to inspect and edit pack files for any Total War since Empire: Total War, or a tool author who wants the same file format code through an IPC server, and it does not fit a macOS user, since the README says the Mac build is not there yet. Before you commit, open the manual linked from the README and check the `schemas` folder for your game, because the parser behaviour for each title is driven by the RON schema files shipped with the project rather than by autodetection.

Frequently asked questions

Official sources

1. Frodo45127/rpfm on GitHub
2. License: MIT
3. Project website
4. README
5. Releases