Skip to content

docs(spec): the two open measurements are settled — and one premise was wrong - #352

Open
stellarfeline wants to merge 1 commit into
mainfrom
docs/spec-measurements-settled
Open

docs(spec): the two open measurements are settled — and one premise was wrong#352
stellarfeline wants to merge 1 commit into
mainfrom
docs/spec-measurements-settled

Conversation

@stellarfeline

Copy link
Copy Markdown
Owner

spec-0031 and spec-0032 both blocked on the same question, and the question was phrased wrongly. Both said "the pre-respawn death advancement". The engine's edge is not an advancement — it is a deathCount scoreboard criterion, guarded by unless data entity @s {Health:0.0f}, which is exactly what defers cp_respawn_check to the tick after respawn.

The answer is favourable

5 causes × 3 repeats on pinned 1.21.11, every repeat agreeing: the edge is armed on the corpse, pre-respawn, for void, fall, drowning, lava and a mob control; LastDeathLocation is written on the same tick; the corpse's position is the death position and does not drift (0.000 — a corpse stops falling).

So on_death can fire corpse-side for every cause, and the recovery stake can be placed for every death a souls-shaped delve produces. spec-0032's single load-bearing unknown clears.

The reusable lesson

An advancement would have been the wrong instrument. entity_killed_player covers 1 of 5 causes. entity_hurt_player fires on the first damage event with HP still 16–20 — it means "was hurt", never "died here". Implemented as the spec wrote it, four of five death causes in a souls delve would have gone unaccounted, and the gap would have surfaced as content that mysteriously fails to fire.

Fall damage across a mid-fall teleport

It carries and applies at the destination — Δ exactly 0.0000 in 46/46 trials, including teleports 143 and 157 blocks straight up. Landing damage is floor(fall_distance) − 3; survived at 20.279 (3 HP left), died at 23.435.

An arriving lift car does not catch a falling player past ~20 blocks — it is the surface they die on. That agrees with the owner's design of record, which already says a player who jumps the shaft with the car below takes ordinary fall damage, lethal or not by height.

Recorded as unmeasured rather than assumed: the exact boundary between 20.279 and 23.435 (free fall quantises in ~3-block steps, so floor − 3 is a fit); whether a real client matches the bot; and what does reset fall distance — only same-dimension /teleport was tested, so the mechanism that would make a lift safe is unmeasured.

Two incidental findings that constrain the verbs

  • 1.21.11 rejects every legacy camelCase gamerule (all eight probed answer Incorrect argument for command and change nothing). The compiler already emits new names. The defect is not the rename — it is that neither offending site reads the command's response, so a rule that silently stopped applying looked identical to one that worked. Filed separately.
  • A respawned player is invulnerable for 59 ticks (~3 s), and /kill answers Killed <player> while doing nothing. Directly load-bearing for the lethal volume and the shaft-bottom volume, and it explains two things previously read as instrument flakiness. Filed separately.

What CI proves

Doc-only. check-doc-dupes and check-reference-versions green. The measurements themselves landed in #349 with the rig and 4140 raw samples committed and re-runnable.

…as wrong

spec-0031 and spec-0032 both waited on 'whether the pre-respawn death
ADVANCEMENT fires for non-entity deaths'. #349 measured it on pinned 1.21.11
and the premise was wrong: the engine's edge is a deathCount SCOREBOARD
criterion, guarded by 'unless data entity @s {Health:0.0f}' — which is exactly
what defers cp_respawn_check to the tick after respawn.

The answer is favourable. Over 5 causes x 3 repeats the edge is armed on the
corpse, pre-respawn, for void, fall, drowning, lava and a mob control;
LastDeathLocation is written the same tick; the corpse position is the death
position and does not drift. on_death can fire corpse-side for every cause, so
the recovery stake can be placed for every death a souls-shaped delve produces.

The reusable lesson is why an advancement was the wrong instrument:
entity_killed_player covers 1 of 5 causes, and entity_hurt_player fires on the
FIRST damage tick with HP still 16-20, so it means 'was hurt', never 'died
here'. Implemented as this spec wrote it, four of five death causes would have
gone unaccounted.

Fall damage carries across a mid-fall teleport and applies at the destination
(46/46 trials, delta exactly 0.0000), so an arriving lift car does not catch a
falling player past ~20 blocks — it is the surface they die on. That agrees
with the owner's design of record. What does RESET fall distance is unmeasured
and recorded as such.

Two incidental findings constrain the verbs: 1.21.11 rejects every legacy
camelCase gamerule, and neither offending site reads the command's response —
which is the real defect; and a respawned player is invulnerable for 59 ticks
while /kill reports success and does nothing, which bears directly on the
lethal volume and the shaft-bottom volume.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AjQ5p1Kv5MrkGPumi7yXWL
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant