Minecraft hardcore server: deathbans and revives

To make a Minecraft server hardcore, set hardcore=true in server.properties before the world is generated. Difficulty is then locked to hard, players get the hardcore hearts, and anyone who dies is put into spectator mode instead of respawning - permanently, unless an operator switches them back with /gamemode survival <name>. That is the whole built-in feature. Everything a group actually argues about - how many lives, whether dead players can watch, whether there are revives, what happens when the server lags someone to death - is up to you, and most of it can be built with a few gamerules and a twenty-line datapack. This post covers the setting, the alternatives to it, and the rules that keep a hardcore server fun after the first death.

What hardcore=true actually does#

On a dedicated server, hardcore is a property of the world, and it changes three things:

• Difficulty is locked to hard. The difficulty property in server.properties and the /difficulty command no longer change it.
• Death is final for that player. Instead of a Respawn button, the death screen offers to spectate. The player stays connected, in spectator mode, able to fly through walls and watch.
• The hearts change. Players see the hardcore heart style, which is purely visual but tells everyone what kind of world they are in.

Older versions of the game banned a player from a hardcore server when they died. Modern versions do not; they leave the player in spectator mode. If you want the old behaviour, you have to add it yourself, which is covered below.

What hardcore does not do: it does not remove the world when everyone dies (the server keeps running with a world full of spectators), it does not stop operators from changing game modes, and it does not change any gamerule. Ops can revive anyone at any time, which makes the operator list the most important setting on a hardcore server.

hardcore=truedifficulty=hardpvp=truewhite-list=trueenforce-whitelist=truespawn-protection=0level-seed=

difficulty=hard is redundant with hardcore=true but documents intent for whoever reads the file next. spawn-protection=0 lets everyone build and break blocks near spawn; the default of 16 reserves that area for operators, which feels arbitrary on a world where everything else is fair. The whitelist matters more than usual: a stranger who logs in and dies has wasted nothing, but a stranger who sets fire to someone's base during their last life has ended a season. Whitelist and permissions covers the setup.

Setting it up on a new or existing world#

The hardcore flag is stored in the world's level.dat when the world is created. The reliable way to get a hardcore world is to set hardcore=true before the first start of a fresh world:

1. Stop the server.
2. Set hardcore=true in server.properties.
3. Rename or remove the existing world folders (world, plus world_nether and world_the_end on Paper), keeping a backup if you want the old world.
4. Optionally set level-seed to a seed you have chosen, or leave it empty for a random one.
5. Start the server. A new hardcore world is generated.

Converting an existing world is less predictable. Whether changing the property alone makes an old world hardcore has varied between versions and server software. If you need to convert one, stop the server, open level.dat with an NBT editor, set the hardcore byte in its Data compound to 1, and set hardcore=true in server.properties too so both agree. Back up level.dat first.

On RE:NODE, Minecraft servers arrive with a world already generated, so starting a hardcore world means stopping the server, changing server.properties in the file editor, removing the generated world folders through the file manager and starting again. It takes a couple of minutes. Every server.properties key explained has the rest of the file.

Gamerules that shape a hardcore server#

Hardcore leaves gamerules alone, but several of them decide what hardcore feels like. Run these from the console (without a slash) or in game (with one):

gamerule keepInventory falsegamerule naturalRegeneration truegamerule showDeathMessages truegamerule spectatorsGenerateChunks falsegamerule playersSleepingPercentage 50gamerule announceAdvancements true

spectatorsGenerateChunks false deserves attention. A dead player has nothing to do except fly around, and a spectator flying at full speed in a straight line generates new terrain as fast as the server can make it. That costs CPU at exactly the moment the living players are trying not to die to lag. Turning it off means spectators can only see chunks someone else has already loaded or generated. Pre-generating the world inside a border removes the problem entirely - world borders and pre-generation has the procedure.

Lives instead of one death#

Plenty of groups find one life too brutal for a long-running server and settle on three. Vanilla has everything you need to build that: a deathCount scoreboard objective and functions that run every tick. The trick is to leave hardcore=false, set difficulty=hard, and let a small datapack decide when someone is out.

The layout, for Minecraft 1.21 and later (older versions use functions and tags/functions as the folder names):

world/datapacks/lives/  pack.mcmeta  data/lives/function/load.mcfunction  data/lives/function/tick.mcfunction  data/minecraft/tags/function/load.json  data/minecraft/tags/function/tick.json

{ "pack": { "pack_format": 48, "description": "Three lives" } }

48 is the data pack format for 1.21 and 1.21.1; use the value for your version. The two tag files register the functions with the game:

{ "values": ["lives:tick"] }

load.json is the same with lives:load. Then the functions themselves:

scoreboard objectives add deaths deathCount "Deaths"scoreboard objectives setdisplay list deaths

execute as @a[scores={deaths=3..},tag=!out] run tellraw @a [{"selector":"@s"},{"text":" is out of lives."}]tag @a[scores={deaths=3..}] add outgamemode spectator @a[tag=out,gamemode=!spectator]

The deathCount objective counts deaths automatically. When a player reaches three, the tick function announces it once, tags them out, and keeps them in spectator mode even if they respawn. The death count shows in the Tab list, which makes everyone's remaining lives part of the game. Run minecraft:reload after installing the pack - on Paper, plain reload is Bukkit's plugin reload, which you do not want - and check datapack list shows it enabled. The datapacks guide covers the folder rules and how to debug a pack that does nothing.

With a lives system, the keepInventory choice comes back into play. With it false, every death is still expensive; with it true, deaths only cost a life. Most groups keep it false.

Deathbans, and whether dead players should stay#

When a player dies in pure hardcore, they stay on the server as a spectator. That raises a question every group answers differently: can dead players watch and talk?

• Spectators allowed. Dead players stay in the community, which matters on a friends' server. The cost is information: a spectator can fly through the ground and tell the living where the diamonds and the strongholds are. Most groups handle this with a rule rather than code.
• Deathban. The dead are removed from the server for the rest of the season. Harsher and cleaner. In the datapack above, you can replace the gamemode line with ban @a[tag=out], but ban is an operator-level command above what functions can run by default. Functions run at the level set by function-permission-level in server.properties, default 2, and ban needs 3, so raise it to 3 if you use this.
• Temporary deathban. A ban for a set time - a day, a week. Vanilla has no timed ban; this needs a moderation plugin that supports temporary bans on Paper, or a manual routine.

Whichever you choose, write it down before the first death. The argument about whether spectators may share coordinates is much shorter when nobody has died yet.

Revives, and who is allowed to do them#

A revive is just /gamemode survival <name> from an operator. The player becomes survival wherever their spectator camera is, with an empty inventory, because everything they carried dropped where they died.

That simplicity is the danger. On a hardcore server, an op account is a revive button, and "just this once" is how a hardcore season turns into an ordinary SMP. Agree on a revive policy up front:

1. No revives at all. The only fair policy for a competitive server.
2. Revives for server faults only. A crash, a lag spike, a rollback. The most common choice and the hardest to judge, which is why the next section exists.
3. Earned revives. Living players pay a price - a rare item, a boss kill, a ritual at spawn - and an op performs the revive. Several plugins and datapacks implement revive altars or player heads that bring someone back; check that whichever you pick supports your exact version, and test it on a copy of the world.

If you run a lives system, reviving also means resetting the score and the tag:

scoreboard players set Alex deaths 0tag Alex remove outgamemode survival Alex

Keep the operator list short. On a hardcore server the people with op should ideally not be playing the season, or should be trusted by everyone not to use it for themselves. Server rules, moderation and staff has a broader take on staff roles.

Lag deaths, crashes and rollbacks#

The single most common hardcore dispute is a death caused by the server rather than the player: a lag spike that froze someone in front of a creeper, a rubber-band into lava, or a crash that rolled the world back to before they made a safe choice.

Prevent what you can:

• Pre-generate the world. Chunk generation during play is the main cause of lag spikes, and on hardcore a lag spike can kill. Generate the playable area before the season starts.
• Keep view and simulation distance modest. view-distance=8 and simulation-distance=6 are reasonable for a small group. Paper optimisation has more.
• Leave memory headroom. A server that hits its memory limit is stopped from outside. On RE:NODE the container is stopped and restarted clean rather than left to swap - better than a server grinding for minutes, but the world loses whatever happened since the last save, and on hardcore that can include a death or an escape from one.
• Watch the graphs during busy sessions. The console shows CPU and memory against the plan's limits. CPU is a hard throttle to the share you bought, so a server pinned at 100% is slow rather than broken - and slow is exactly what kills people in hardcore.

Then decide in advance what happens when it goes wrong anyway:

• Lag deaths: is a player who died to visible server lag revived? Who decides, and on what evidence? A rule like "if the server log shows a Can't keep up! warning in the minute of the death, revive" is objective and easy to check.
• Crashes and rollbacks: if the server crashes and the world rolls back, a dead player may be alive again, or a living player may lose an hour of progress. Most groups accept the world's state after the restart as the truth.
• Restores from backup: restoring the world to fix corruption also revives anyone who died since that backup. Agree whether those deaths stand.

Backups still matter on a hardcore server, perhaps more than usual: the world is the season, and corruption ends it as surely as a creeper. Every RE:NODE game plan has backup slots stored off the machine, on demand or on a schedule. World backup and restore covers taking a consistent copy and restoring one player or area.

Seasons and resets#

Hardcore servers tend to run in seasons: the world lasts until everyone is dead, or until a fixed date, or until the dragon falls. Ending a season is a world reset:

1. Announce it. Give players a last day to take screenshots.
2. Stop the server and take a final backup, and download it. Players will want the world later; offer it as a download.
3. Remove the world folders. Keep server.properties, the whitelist and any plugins.
4. Reset scores if you used a lives datapack. The scoreboard lives in the world's data/ folder, so a new world starts clean anyway.
5. Pick a new seed or leave it random, pre-generate inside a border, and start.

A season is also a good moment to revisit the rules: was three lives right, were revives too easy, did spectators spoil the game? Small groups tend to settle into a format after two or three seasons.

FAQ#

What happens when you die on a hardcore Minecraft server?

You are put into spectator mode and cannot respawn. You can stay connected, fly through blocks and watch other players. An operator can bring you back with /gamemode survival <name>, and you return with an empty inventory where your spectator camera is.

Can I turn an existing world into a hardcore world?

Sometimes, but it is not reliable across versions. The dependable route is a new world with hardcore=true set before generation. To convert an existing one, set the hardcore byte in level.dat to 1 with an NBT editor as well as setting the property, and back up first.

Can players be banned automatically when they die?

Not by vanilla hardcore in current versions. A small datapack can ban players whose deathCount reaches a limit, but ban needs permission level 3, so set function-permission-level=3 in server.properties. A moderation plugin is the alternative if you want timed bans.

Can I change difficulty on a hardcore server?

No. Hardcore locks difficulty to hard, and the difficulty property and command are ignored. If you want hard difficulty with respawns, set hardcore=false and difficulty=hard, and use a lives system instead.

How many lives should a hardcore SMP have?

There is no right answer, but one life suits short, intense seasons and competitive groups, while three lives suits longer survival seasons where one bad night should not end a player's month. Decide before the first death, not after.