Tool interoperability
GameMaker patching pipelines
A mod manager is only as trustworthy as its patch pipeline. Every fallback, temporary file, and concurrency boundary affects user data.
Problem
Deltamod needed to support multiple patching backends while preserving repeatability and avoiding races around extracted native tooling.
Engineering approach
- Integrate G3MTool as a first-class backend while preserving existing GM3P and Device Fusion paths.
- Apply compatible VCDIFF payloads in process and use original backups as the source for idempotent repatching.
- Remove silent partial-success fallbacks and fix parallel extraction races with guarded, per-process temporary state.
Outcome
- The integration was merged into Deltamod with clearer failure semantics and faster compatible patch paths.
The hardest problem
Make three patch backends cooperate without ever silently producing a half-patched game.
Backends disagree on formats and failure modes, extracted native tools race under parallel installs, and the existing fallbacks reported success on partial output, the worst possible lie a mod manager can tell.
Apply compatible VCDIFF payloads in-process from pristine backups, guard temporary state per process, and delete every silent fallback so failures surface immediately.
How I worked through it
Idempotency drove the design: because repatching always starts from the original backup rather than from whatever bytes happen to be on disk, running the same patch twice is safe, and a recovered install converges instead of layering corruption.
The G3MTool integration landed as a first-class backend next to GM3P and Device Fusion rather than a special case, so backend selection stays explicit and each path keeps its own failure semantics, 409 lines added, 127 removed, merged upstream.
Technologies
- C#
- JavaScript
- Electron
- VCDIFF
- Concurrency
- Process integration