xEdit: the conflict resolution workbench behind Bethesda's mod scene, written in Delphi

A conflict resolver for plugin formats, not a general mod tool

xEdit is described as the editing and conflict-resolution tool for Bethesda game plugins, covering Oblivion through Starfield. That range is the whole story of what the project is and is not.

Bethesda's games store mods as plugins, and plugins record changes to a game's data. When two mods both change the same record, one overwrites the other, and the modder has to work out what was intended. That reconciliation is what xEdit does, and it is a specialised problem: it requires understanding the record formats of several games at once, which is why the project ships a table of game-specific executables and per-game record definitions.

The description credits xEdit by ElminsterAU, updated and maintained by Sharlikran, Zilav and Hlp, and the README's maintainer section gives a fuller picture. ElminsterAU is the author and upstream maintainer, since 2006. robertgk2017 is co-maintainer, listed with record definitions across all supported game formats, BSArch and BSArchPro, core editor fixes, and as the integration point for incoming contributions. Regular contributors named are Jonathan Ostrus, fireundubh and eckserah, LOD tooling is credited to Sheson for xLODGen and DynDOLOD, and Hlp, Zilav and Sharlikran are listed as historical maintainers for 2012 to 2019.

That roster is a signal about the project. It has been continuously maintained across two decades and through several generations of maintainers, and the work is spread across specific areas rather than one person, which is how tools of this age stay workable.

The primary language is Pascal, in the form of Object Pascal for Delphi, and the licence is MPL-2.0, which is a file-level copyleft grant appropriate for a tool whose code people build on top of. This review does not interpret the licence terms, and the practical point is that the source is open and the file-level licence is the one commonly used for libraries in a larger application.

One executable per game, chosen by name or by argument

The xEdit versions section answers the question every new user asks, which is which binary to run.

All xEdit executable files can support all game modes, and there are two ways to choose the mode. You can launch the application using a command line argument, or you can rename the xEdit executable to include the game mode. The table then maps games to executables and arguments, with Oblivion as `TES4Edit.exe` and the argument -TES4, Enderal as `EnderalEdit.exe` with -Enderal, and Oblivion Remastered as `TES4REdit.exe`.

That dual mechanism is a practical piece of engineering. Renaming the file means the mode travels with the binary, so if you keep a copy per game on a modding machine, each copy is already pointed at the right game. The command line argument does the same thing without touching the file, which is what you want in a script or a shortcut. Both routes avoid the alternative of separate executables per game per build.

The mode matters because the underlying record formats differ between games, and the newer Bethesda titles, Starfield among them, have their own. Picking the wrong mode gives you a tool that reads the file but does not understand the game, which is exactly the kind of confusing failure the argument and rename mechanisms are there to prevent.

The repository layout shows how the tool is decomposed. There are xEdit.dpr, xEdit/ and xEdit/ for the main editor, BSArch and BSArchPro with their own project files for the archive layer, Core/ for shared code, Tools/ for the utilities, Sniff/ for the conflict detection tool, xDump/ for dumping records, Build/ for the build scripts, and External/ for the third party sources including the JCL, JVCL, VirtualTrees and FileContainer libraries the build instructions tell you to compile. The top level also has BethWorkBench.groupproj, which is the project group you open in Delphi to build the whole thing, and whatsnew.md, the per-release attribution file, alongside modgroups.md and the md2rtf.py script that produces whatsnew.rtf.

Building from source needs a Delphi environment and a lot of setup

The developer documentation is honest that getting started requires a properly configured Delphi environment, and the steps are long enough that the README calls them a minimal viable setup.

The first requirement is Delphi itself, and the recommendation is Delphi 12 Community Edition if you do not already have an environment. Then two Delphi extensions: Project Magician and DDevExtensions. DDevExtensions needs two specific IDE settings changed. Under Extended IDE Settings you enable Disable Package Cache, and under Form Designer you enable Do not store the Explicit properties into the DFM. That second one is not cosmetic, since the build depends on the DFM files not carrying properties the code sets at runtime.

The source is a set of submodules, and the README says to clone the xEdit repo and initialize submodules with:

git submodule update --init --recursive

The JCL then needs its template include files generated per platform, with jcl.template.inc copied to jcld29win32.inc for 32 bit and copied again to jcld29win64.inc for the 64 bit build. You open the JclPackagesD290.groupproj inside External, build all, install the non-runtime packages, those with green icons, and restart Delphi. The JVCL follows the same pattern with D29 Packages.groupproj, except that it also needs library paths added under Language, Delphi, three paths in total pointing into the JCL and JVCL lib directories. Then VirtualTreeView.groupproj and FileContainer29.groupproj, each built and installed, the latter as VirtualTreesD29.bpl and FileContainerD29.bpl.

The last requirement is a licensing wrinkle. If you do not have commercial DevExpress components, you need to open BethWorkBench.groupproj and set the Build Configuration to `LiteDebug`. The project otherwise expects components you may not be able to use.

The practical read is that a contributor to xEdit is not someone who clones and runs a build script. It is someone who sets up a Delphi toolchain, installs four component libraries by hand, and gets the include files right for the bit width they want. The Build/ directory at the root of the tree holds the project's own build tooling, separate from the per-project group files, and the top level also has BSArch, BSArchPro, Core, Tools, Sniff and xDump as separate Delphi projects that all feed into BethWorkBench.groupproj.

Builds come from Discord, and the tags lag the branches

The distribution story is unusual and worth understanding before you rely on it.

The README says the most recent builds are available through the xEdit Discord in the `#xedit-builds` channel, and that the archive provided in the repository is generic and works with all current game modes. So the repository's release archive is a fallback, and the current builds live in a chat channel.

The rest of the release list is a set of links to per-game packages on Nexus Mods, for the older, less frequently updated ones: FO3Edit, FNVEdit, FO4Edit, FO4VREdit, TES4Edit, TES5Edit, TES5VREdit, SSEEdit, FO76Edit and SF1Edit, plus a mirror link to the GitHub releases. The LOD tools have their own list, with FO3LODGen, FNVLODGen, TES4LODGen, TES5LODGen, TES5VRLODGen and SSELODGen.

The tag list tells you where the versioning stands. The recent releases are xedit-4.1.5f from 2024-04-28, xedit-4.1.5c from 2024-02-11, described as EXTREMELY EXPERIMENTAL, and xedit-4.1.5 from 2023-11-04, also labelled EXPERIMENTAL. Two of the last three tagged builds are explicitly marked experimental, and the suffix letters f and c read as a lettered series within a minor version, which is the convention for pre-release builds of a single 4.1.5 line.

Meanwhile the default branch is named dev-4.1.6, and the last push was on 2026-10-19, on that branch. So the development line is 4.1.6, the newest tagged build is a 4.1.5-series release candidate from 2024, and the repository is not archived.

The upshot is that if you want the current tool you take it from Discord, and if you want a fixed artefact you take a 4.1.5-series build that the maintainers labelled experimental. Both facts are stated plainly in the README, and together they mean the project has a live development line, a lagging tag history, and a primary distribution channel that is a chat room.

Documentation that had to be rewritten, and a help system in the binary

The documentation situation has a history that is worth reading, because it tells you where to look.

The README says that with the 4.0 update all previous guides are obsolete, and points instead to the xEdit Quick Auto Clean documentation for the mod cleaning workflow. Two training manuals are listed for the older tools, a Fallout 3 manual that applies to all game versions and a Fallout New Vegas manual with the same caveat, and both are hosted on Nexus Mods.

The online documentation story is more complicated. EpFwip started an HTML conversion of the Fallout 3 Training Manual many years ago, and with the help of GitHub Pages and Jekyll the online documentation for xEdit is now available. New screenshots of the Fallout 3 examples that Miax and JustinOther presented will be added as time permits, and the site will continue to evolve over time. The current resource for xEdit functionality, however, is the Tome of xEdit, a PDF with step by step illustrations of the built-in functions, and the README notes that while the UI itself has had few changes over time the functions work the same and only certain functions are game-specific.

So there are three documentation bodies of different ages and different status, and the README is clear about which one to use.

The best option is in the binary itself. The online documentation is available from the Help button built into the developmental version of xEdit, or from the linked site, and the Tome of xEdit remains the current resource for functionality. For a tool that has been running for twenty years with an interface that has barely changed, that is a defensible arrangement: the reference text is close to the program, and the interactive documentation is the first place to look.

One more documentation artefact is worth knowing about. The README's issue tracker section says the tracker is a place to submit and discuss feature requests and bug reports, asks that criticism be constructive, and asks people not to use the tracker for general help and support on how to use xEdit. The per-release attribution is in whatsnew.md, which is the file to read when you want to know what changed.

Editorial conclusion

xEdit fits a mod author who has to merge two plugins that touch the same records, since conflict resolution for Bethesda formats is the problem it exists to solve and the per-game executables keep the format differences handled for you. It is the wrong choice for a general modding workflow that also needs asset editing, since the LOD generation tools live in separate xLODGen releases, and it is the wrong choice if you need a stable downloadable release, because the most recent builds come from a Discord channel and the newest tag is xedit-4.1.5f from 2024-04-28 while the default branch is dev-4.1.6. Before you start, pick the executable for your game from the versions table, and read the mod-cleaning documentation, since the README states that all previous guides became obsolete with the 4.0 update.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. TES5Edit/TES5Edit on GitHub