The gamemode decides respawn delay and point for each death

Status: Accepted (2026-06-27)

Context

The death and respawn cycle (ADR 0017) has a platform part and a gameplay part. The platform part must stay in the server core: committing a death once per life, the life generation, granting the respawn and keeping the grant idempotent. How long a player stays dead and where they come back ("10 s", "at the last checkpoint", "at the team base") is gameplay. If the core decided it, every new rule would grow inside the core.

The default point comes from the spawn policy (ADR 0012). The respawn itself is pulled by the client: a dead client repeats RespawnRequest on a timer, and the server answers with RespawnPlayer once the player is eligible.

Decision

• The gamemode hears the death. Every committed death raises the observe-only Lua event player_death(victim, killer, weapon, body_part) (ADR 0029), exactly once per life: the commit is idempotent, so a duplicate or late report raises nothing.
• It answers with a per-death decision. player:set_respawn{delay_ms, x, y, z, heading, interior} (facade set_respawn(id, delay, spawn)) records a respawn decision on that player's server state. It sends no packet; the grant still rides the client's request. The point is validated like every spawn point.
• Only while dead. A decision is a reaction to a death, so it is accepted only after the death commit and before the respawn grant; on a living or already respawning player the call fails with PlayerNotDead. A decision therefore cannot leak from one life into the next, and no cleanup at the next death is needed.
• The core defaults stay as the fallback. Without a decision the player is eligible 3 s after the death commit and respawns at the spawn policy point. With one, eligibility waits delay from the death commit (not from the call) and the grant carries the decided point. A gamemode that does nothing keeps the game playable.
• The point is fixed at the first grant. The first grant resolves the point once (the decision, else the policy), stores it with the player and consumes the decision. A repeated request while the respawn is still unconfirmed gets the same grant at the stored point: no new generation and no second PlayerSpawned (the reliable lane retransmits the one already queued).
• The decision lives and dies with the player. It sits in the player's state, which is dropped on disconnect, so a reused player id never inherits a pending decision (ADR 0021).

Consequences

• No wire change: RespawnPlayer and PlayerSpawned already carried a server-chosen point; the gamemode only changes where it comes from.
• The delay is enforced by the client's repeating request, not by a server timer: the core needs no scheduler, and a respawn happens at the first request after the delay.
• A gamemode that wants a persistent per-player spawn (a class, a team base) sets it at every death; a per-player spawn in the policy is a separate future extension.

Alternatives considered

• Per-player storage in the spawn policy. Rejected: a respawn decision belongs to one death and is consumed by its grant, while a per-player spawn in the policy would be a persistent choice with another lifetime. Mixing them would put transient per-death state into the policy.
• Ask the gamemode at grant time. Rejected: the core would call back into the gamemode on the request path, against the direction of the server facade (ADR 0009), where resources act on the core and the core only raises events.
• Allow the call at any time. Rejected: a decision set on a living player would wait for some later death and apply to it unexpectedly.