Custom Minecraft Launchers: Update Without Losing Player Files

Before accepting a custom Minecraft launcher, require an update rehearsal on an installation that already contains player files. Interrupt the download, supply an invalid file and retry the update. Acceptance should depend on preserving the agreed local data and reaching one identifiable modpack release, without silently mixing old and new files.

This matters to communities and event teams commissioning a launcher for repeat use. A clean installation can succeed while the second update damages settings or removes a player's additions. The checklist below is a proposed specification for the update process, not a tested Mineando implementation or a promise that every launcher behaves this way.

Separate the launcher from the pack it installs

Record two version identifiers: the launcher application and the modpack release. Updating the program that displays the download button is a different operation from replacing mods and configuration inside a game instance. Each needs its own supported platforms, release channel and failure procedure.

For example, if the application uses Electron, its built-in autoUpdater documentation describes application updates on Windows and macOS; it has no built-in Linux support, and macOS automatic updates require signing. Those details do not establish how the application updates Minecraft files. Ask the supplier to document that second mechanism separately.

Start with the modpack release handover so the target package is already identifiable. Then add the missing question: what happens to an installation somebody has used for several weeks?

Decide who owns each kind of file

Before development, agree a file policy with three categories. The paths below are examples for the commissioned design, not universal rules enforced by Minecraft.

File category	Proposed update policy
Pack-managed mods and required configuration	Replace according to the approved release; remove retired files only when recorded as managed.
Player saves, screenshots and personal additions	Preserve; identify conflicts without silently deleting the user's files.
Settings shared between pack and player	Define field-level migration, a documented reset, or a conflict decision before release.

Avoid a requirement such as “make the whole folder match the download”. It leaves no boundary between obsolete pack files and personal content. Conversely, keeping every old JAR can leave two versions of a managed mod together. Require a record of which files the previous release installed, and an explicit response when their contents have changed locally.

Use a concrete example in the brief. Release r4 removes a managed mod and changes an event configuration. The tester has also changed a key binding and added a local screenshot. State which files disappear, which settings change and which items must remain byte-for-byte intact. If a personal mod is unsupported, the launcher can explain the conflict and offer a separate clean instance; it should not silently erase it.

Verify downloads before making them active

For .mrpack, the Modrinth specification provides paths and hashes for downloaded files, and describes overrides copied into an instance. It also warns implementers against paths escaping the instance directory. This is a format specification, not proof of a launcher's recovery behaviour.

For your commission, require downloads to be prepared separately from the active release and checked against the trusted release record before activation. An invalid hash must produce a clear failure, not a successful installation message. A matching checksum identifies expected bytes; it does not independently establish that an unknown publisher is trustworthy.

Include archive extraction and override files in the review. The supplier should show that package paths cannot write outside the intended instance, including through filesystem links. Ask for controlled tests in a disposable directory, without targeting real personal files. A progress bar reaching the end is not evidence that these checks exist.

Define the state after an interruption

Write the required outcome before choosing an implementation. If a download fails before activation, the previous complete release should remain identifiable and intact. The unfinished candidate must not become launchable as if it were complete. After restarting the launcher, the user should be able to retry or cancel using the documented route.

Interruption during activation needs its own case. Ask the developer how the launcher detects an incomplete change and returns to a consistent state. The design may use separate release directories, a recovery journal or another approach; acceptance depends on demonstrated behaviour on the supported operating systems and filesystems. Calling an operation “atomic” is not evidence for an entire multi-file update.

Require the launcher to prevent conflicting updates to the same instance and to defer changes while that instance is running. Agree how disk exhaustion and locked files are reported. The test should verify the resulting files, not merely that an error dialog appeared.

Rehearse an update on a used instance

Create a disposable copy with representative player data and record the starting file inventory. Never interrupt a real participant's installation to test recovery. Run at least these cases for each supported installation route:

• Update normally from the previous supported release; verify the target inventory and retained user data.
• Disconnect during download; restart the launcher and retry.
• Deliver a deliberately mismatched file; verify rejection before activation.
• Interrupt activation using the developer's controlled test method; verify recovery after restart.
• Simulate insufficient space and a file that cannot be replaced; verify the documented response.
• Repeat the update request and attempt it with the game running; verify that operations cannot conflict.

Record launcher version, pack versions, operating system, starting state, expected outcome, actual outcome and evidence. Mark every unexecuted case “not run”. Agree disk-space requirements from measurements of the real package, including temporary files and retained releases; there is no universal multiplier supplied here.

Make recovery and handover explicit

Preserving an old package does not prove that an old client can join an updated server. Nor does switching mods back undo changes a newer version has written to a local world. Define which previous releases remain supported and keep world recovery separate from package recovery. Test these boundaries before advertising a “revert” button.

The handover should include the file policy, supported update paths, completed failure tests, user-facing recovery instructions and an operator procedure for withdrawing a defective release. Logs should identify the failed stage and release without exposing authentication tokens or unrelated personal paths.

For custom launcher development, bring the supported participant setups, update policy and acceptance cases. Mineando scopes and quotes paid projects individually. For an event rollout, agree who can stop distribution and who helps affected participants; maintenance and live coverage are separate scope decisions.