UndertaleModTool: reading and rewriting GameMaker data files

Pointer-safe writes on top of a byte-exact reader

The core promise is a round trip. UndertaleModTool reads every byte of a GameMaker data file into an object tree, then recreates a byte-for-byte identical copy from what it decoded. That promise carries its own limits, stated in the same breath: it covers the latest versions of Undertale, Deltarune and most other GameMaker games, so anything older or unusual sits outside the guarantee.

Editing is what the pointer handling buys. GameMaker containers reference each other by file offset, so inserting one object shifts every offset after it. The tool rewrites those references as it saves, which is why adding, removing, lengthening or moving entries does not break the format. Skip that step and one added sprite corrupts everything that follows it.

The editor on top reaches almost every field, hedged in the project's own wording by "(almost)", and it will show values that carry no name at all. A simple room and level editor ships alongside it. Everything here operates on the decoded tree, so the byte-exact writer stays in charge of layout and the editor never has to reason about offsets itself.

Five numbered steps and a ZIP you must not run from

On Windows the entire path from nothing to an editable game file is five numbered steps and a ZIP archive, with no installer and no package manager in sight. The quick start insists that the archive has to be extracted to a folder first, and it gives no reason beyond the instruction itself.

2. Download the GUI version (e.g. `UndertaleModTool_v0.9.2.0-Windows.zip`), or the CLI version if you know what you're doing
3. Extract the ZIP file to a folder (do not run from inside the archive!)
4. Run `UndertaleModTool.exe` to start the tool
5. Open your game's data file (e.g. `data.win`, `game.ios`, `game.unx`, etc.) via File → Open

Step one is a link to the Downloads table rather than a command, and the archive named in step two, `UndertaleModTool_v0.9.2.0-Windows.zip`, matches the current stable build rather than the nightly tag. Step five is the only stage between launching the executable and reaching a decoded file. Every container named there goes through the same dialog, so a second title such as Deltarune needs nothing else before you start editing.

macOS and Linux get a CLI, a port and Wine

There is no official way to run the graphical interface on macOS or Linux, and the README says so without hedging. Three routes are offered instead, and each one stops short of a finished product.

The command-line build removes the interface entirely and is pitched at automation and quick tasks. A work-in-progress port of the GUI to a cross-platform framework lives in pull request 2126; it is called incomplete, yet credited with support for many features that are commonly used. Third is Wine, either configured by hand or driven by an unofficial, community-maintained installer script hosted in a different repository.

That last route carries the sharpest warning in the document. The Underminers team says it is not associated with those third-party projects and asks users to confirm any scripts are safe before running them. A script that fetches and patches a native binary is exactly the artifact most people will not audit line by line, so the honest summary for a non-Windows user is primitive, unfinished, or unverified, and you pick which one.

Two builds marked default, and a nightly behind stable

Two packaging decisions sit underneath that archive, and the trade-off is documented rather than hidden. Bundling every dependency into one executable keeps a folder tidy, while the same text warns that this build can also cause stability issues. The unpacked alternative places all dependencies next to the executable, which the project quantifies as hunting for the right executable among roughly 300 DLL files.

* `GUI` (default) - the tool has a full graphical interface, making data file viewing and manipulation convenient.
* `CLI` - the tool is accessible only via a command-line interface, which is useful for automation and quick tasks, but is more difficult to use.
* `Single file` - the tool is only one executable, with all dependencies embedded within it. This makes your folders cleaner, however it can also cause stability issues in certain cases.
* `Non-single file` (default) - all dependencies are not embedded within the executable, and are now located right next to it. Choose this if you don't care about finding the right executable within ~300 DLL files, or if the stability issues from the `Single file` build affect you.

Both `GUI` and `Non-single file` carry the word default, so reading the labels literally selects two different builds at once. Neither choice is wrong on its own, but nothing in the document says which one a first-time user ends up with.

The nightly channel is where the numbers disagree with the promise. Nightly is described as carrying the most recent features and fixes at the cost of a higher chance of breakage, yet its tag is timestamped 2026-08-23T16:05:35Z and the 0.9.2.0 stable build is timestamped 2026-08-23T16:27:17Z. The bleeding-edge tag sat behind stable that same afternoon.

The command-line build is the non-Windows answer and the least capable one

That leaves the uncomfortable corner of the project. Non-Windows users are pointed at the CLI build, and the compilation notes describe it as "Currently is very primitive in what it can do". The officially supported path on Linux and macOS is therefore the component its own documentation rates lowest.

There is a reason the weak build still matters. Scripts written in C# can modify a data file automatically, which is the stated route for mod distribution and for anything repetitive enough to script. What a person gives up is the room editor, the value tree and the GML view, because the graphical project needs Windows even to compile and the cross-platform port is unfinished.

For continuous integration that gap is workable. For interactive work on a Linux desktop it is not, and nothing in the quick start tells you which parts of the interface you will end up without.

GML editing reaches the VM but stops at YYC

Code editing is where the tool goes deepest and hits the hardest wall. GML VM code can be edited directly, and custom code can be added through the built-in GML compiler or written as GML assembly. Compiled targets are excluded outright: the README states that YYC is not supported, which removes the backend GameMaker used for exported commercial builds.

The decompiler above that is broader. It handles a large range of GameMaker versions and, in the project's phrasing, most important GML features, with a few still missing and no list of which ones. For someone working from current Undertale or Deltarune data this rarely blocks a mod, since object and room trees are what most changes touch. Reconstructing an older game is where the missing features become the ceiling.

One extension pushes further: the tool can generate a `.yydebug` file that the GM:S debugger reads, which allows editing variables live in a running game. The linked documentation for that feature covers the GM:S 1.4 data.win format and its VM bytecode together, so the debugger story belongs to that generation of the format.

A dna.txt file switches file associations off

Opening a data file is not the only thing this program touches. At first boot it offers automatic file associations for all GameMaker related data files. The offer is opt-in, and it can be withdrawn by placing a `dna.txt` file next to the executable, which is the entire kill switch. Convenient on a locked-down machine, awkward when several people share one install.

The tool also reaches outward on purpose. Core functionality is extracted into `UndertaleModLib` so other programs can use it, and a bundled collection of C# scripts extends the editor further, with their names and purposes recorded in SCRIPTS.md instead of in the quick start.

Read those two together and the adoption question sharpens. Automated data file rewriting and live variable editing are documented features of a program that runs with the file system permissions of your own user account, and no sandbox is described anywhere in the documentation.

Windows, a recursive clone and three compilable projects

Building from source brings its own constraints. The `.NET Core 10 SDK` or later is required, and a Git clone must pull submodules recursively, because the `Underanalyzer` dependency arrives as one. Three projects are listed as compilable: the core library, the command-line front end and the graphical front end, and the last of them requires Windows.

dotnet publish <Project>

The placeholder takes one of those project names, and the IDE route opens `UndertaleModTool.sln` instead of typing anything.

The root holds more than these notes cover. `UndertaleModLibTests`, `UndertaleModTests` and `UndertaleModToolUpdater` sit beside the three documented projects with no mention in the quick start or the compilation section, and a SECURITY.md file sits next to CONTRIBUTING.md, whose stated AI policy is a flat no.

The repository is not archived, and the last push on master was on 2026-09-07. The code ships under GPL-3.0 with the terms in LICENSE.txt, which matters to anyone who plans to redistribute a build patched with their own changes.

Editorial conclusion

Adopt this if you own a GameMaker game and can work on Windows. Its own repository description claims it is the most complete tool for that job, and the byte-for-byte write-back promise is the first claim worth testing yourself. Pass on it if Linux or macOS is your only machine and you need the room editor or the GML view, since the supported route there is a build the project itself calls very primitive, and check the YYC exclusion against your target game first. Back up the data file, load and save it unmodified, compare the copies, then edit.

Frequently asked questions

Official sources

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