Hardcore Reset

A Fabric mod for Minecraft 26.2. When any player dies, the death is cancelled and the entire world (Overworld, Nether, End) is thrown away and replaced with a freshly seeded one. Everyone online - including the player who died - is teleported into the new world with a clean inventory, XP, and advancements. Nobody is kicked, and nobody has to manually delete and recreate the save.

How it works

• ServerLivingEntityEvents.ALLOW_DEATH intercepts every player death server-side and cancels it before the "You Died" screen happens.
• The Fantasy library (by NucleoidMC) is used to open brand new Overworld/Nether/End dimensions at runtime, reusing the same terrain generators and dimension types as before but with a new random seed, without needing to restart the server.
• Every online player is teleported into the new Overworld's spawn, healed, and has their inventory/XP/advancements reset.
• The previous run's dimensions are then deleted. The very first reset leaves the real vanilla Overworld/Nether/End alone (untouched, just unused) rather than deleting them.

Portals

A run's dimensions are called hardcorereset:overworld_6, the_nether_6 and the_end_6. Large parts of vanilla decide what a dimension is by comparing its key against the Level.OVERWORLD / NETHER / END constants rather than asking the dimension anything about itself, so inside a run every one of those checks comes out false and the behaviour it guards quietly switches off. Two things break as a result:

• Nether portals cannot be lit. BaseFireBlock.onPlace only forms portal blocks when inPortalDimension returns true, and that is a bare dimension() == OVERWORLD || dimension() == NETHER. Flint and steel places fire on a correct frame, nothing converts, and the fire burns out.
• Portals lead to the originals. NetherPortalBlock.getPortalDestination and EndPortalBlock.getPortalDestination both hardcode the same constants, so a portal in overworld_6 would deposit you in minecraft:the_nether - the untouched copy the mod never deletes and never resets, making it a permanent safe deposit box that survives every death. The run's own nether and end would never be reachable at all.

ActiveRun holds the current run's three dimension keys and translates in both directions: toVanilla answers "which vanilla dimension is this standing in for" so identity checks behave, and toRun answers the reverse so lookups land in the run. Three mixins apply it:

The redirects deliberately translate the two lookups the vanilla method already makes rather than reimplementing it, so coordinate scaling, world border clamping and exit-portal searching are all untouched.

These are common mixins, not server ones. Single-player and Essential-hosted games run an integrated server inside the client, where server-only mixins never apply.

When no run is open - a fresh world before its first death - nothing is remapped and vanilla behaves exactly as shipped.

Totems of Undying

A totem still saves you, and saves the world with you. Holding one when you would have died consumes it, revives you on the spot, and no reset happens.

This needs handling explicitly, because Fabric's ALLOW_DEATH is a redirect of the isDeadOrDying() check that guards vanilla's entire death block:

if (isDeadOrDying()) {                      // <- what ALLOW_DEATH replaces
    if (!checkTotemDeathProtection(source)) {
        die(source);
    }
}

Cancelling the death there skips the totem check along with everything else, so the totem is never looked at, never consumed, and the world resets anyway. Instead the mod tests for a totem first and, if one would save the player, returns true and lets vanilla's own block run - the totem is spent, the player revives, and die() is never reached, so no reset is triggered either.

The test mirrors vanilla's own conditions: damage tagged BYPASSES_INVULNERABILITY (the void, /kill) ignores totems, and the item has to be held in a hand rather than merely carried. It keys off the DEATH_PROTECTION data component rather than the totem item, so any modded item granting the same effect works too.

Players who were offline

A reset can only touch players who are online at the time. Anyone logged out keeps their inventory, XP and saved position, and rejoins fully equipped, standing at coordinates in a world whose terrain is now completely different - very often inside solid rock.

Each player's run number is recorded in hardcorereset_players.txt in the world save. On join, anyone whose number is behind the current run is reset and moved to the new spawn, and told why.

Tracked by run number rather than by inspecting where someone logged out, because that does not distinguish the cases: a player who left during run 0 is still recorded as being in minecraft:overworld, which genuinely still exists, so nothing about their saved position gives the problem away.

Personal respawn points are cleared on every reset rather than moved. A bed or respawn anchor set in the previous run belongs to a dimension that has since been deleted, so leaving it in place would send that player somewhere that no longer exists the next time they respawn. With no personal respawn point they fall back to the new world's spawn.

The reset announcement

Each reset broadcasts how the run ended:

WORLD RESET - run #3 is over
Steve was slain by a Zombie
Somewhere, a speedrunner is laughing.
Time spent on that world: 1h 12m 40s
A new world has been generated. Good luck.

The death line is vanilla's own message, taken from the DamageSource before anything is reset, so it covers every death type and is already translated into each player's language. The line under it is picked at random from EPITAPHS in ResetManager - add your own there.

The run timer

/survived reports how long the current world has lasted, and the run number:

Run #4 | Survived so far: 8m 21s

Deliberately not /time - that is a vanilla command (/time set day, /time query daytime) and shadowing it would break world time control. The command needs no permissions, since it only reads a number back.

The timer counts server ticks, not wall-clock time: closing the world for a day and coming back should not add a day to how long the run has survived. It is persisted alongside the generation and seed, flushed every 30 seconds and on clean shutdown, so an unclean exit costs at most half a minute.

Waking up

Landing in the new world starts a full-screen black overlay that fades to clear, so a reset reads as coming round rather than as an abrupt cut. It is drawn as the last HUD element, so the blackout covers the hotbar and chat too.

The sound and the fade are both driven client-side, and the timing is the reason. The server cannot see when a client has finished downloading terrain, so anything it schedules starts counting while the player is still on the loading screen - the fade burns down behind it and the world appears already clear. Instead the server sends a wake_up payload that only describes what the effect should look like, and the client holds it until ClientLevel.hasChunk reports that the chunk the player is standing in has actually arrived. That is the same moment the loading screen gives way to the world.

This is also what makes the effect genuinely per-player: two people on very different machines each get it the instant they arrive, with no shared timer to compromise on. There is a 15 second safety net - if terrain never reports ready, the effect fires anyway rather than being silently swallowed.

The fade itself is timed off the wall clock rather than counted in ticks, so it looks the same at 20 fps and at 300. Players without the mod installed miss the effect entirely; the send is guarded by canSend, so a vanilla client is never sent a payload it cannot decode.

Tuning

Every setting is per player. /hcr shows your own, /hcr test previews the sound and fade on yourself without dying:

No permissions are required for any of it. Every branch reads or writes only the caller's own settings, so there is nothing one player could do to another - which means nobody needs op, and cheats do not have to be enabled.

delay is counted client-side, after terrain has arrived, so it is a deliberate pause before you come round rather than time lost to loading. It does not need to be raised to compensate for a slow machine - waiting for the world is automatic. 0 is the default and fires the moment the world is up.

Settings are written to config/hardcorereset-players.properties, keyed by UUID, on whichever machine is hosting. They live in the config directory rather than the world save so a player's chosen volume and fade follow them into every new world instead of resetting each time somebody dies.

Building

You need JDK 25 or newer. From this folder:

./gradlew build

(On Windows, use gradlew.bat build if you're not in a bash-like shell.)

The built mod jar will be at build/libs/hardcorereset-2.3.1.jar.

Installing

Drop hardcorereset-2.3.1.jar into the mods folder of a Fabric 26.2 instance that also has Fabric API installed (Fantasy itself is bundled inside the mod jar, so you don't need to install it separately).

Known limitations

• Stats aren't reset. Minecraft doesn't expose a simple "clear all stats" API, so playtime/blocks-mined/etc. carry over. Inventory, ender chest, XP, and advancements do reset.

  The ender chest matters more than it looks: it is a separate container that follows the player rather than living in the world, so it survives the dimension being thrown away. Left alone it becomes a safe deposit box - stash your gear before a risky fight and the world ending costs you nothing.

• Mid-run restarts. If the whole Minecraft process is closed and reopened in the middle of a run (before anyone has died since the last reset), the in-progress dimensions aren't preserved across the restart, since they're temporary Fantasy levels. The mod falls back cleanly - the game just starts a fresh run on the next reset - but you won't resume exactly where you left off terrain-wise. This only matters between deaths, not during normal play.

• Advancement clearing iterates every advancement and revokes any completed criteria; this is the one part of the code most likely to need a small fix if Mojang's mapped advancement API shifts in a future snapshot, since it's the least-documented corner of the API this mod touches.

License

Hardcore Reset's own source is licensed under the MIT License.

It bundles Fantasy by NucleoidMC, unmodified, as a nested jar inside the mod jar - Fantasy is licensed under the GNU Lesser General Public License v3.0. Bundling an LGPL library this way (as a separate, unmodified jar rather than merged into this mod's own code) doesn't require this mod's own code to be LGPL, but the license and a link to Fantasy's source must be included with any distribution

• both are provided above.