docs(spec): the two open measurements are settled — and one premise was wrong - #352
Open
stellarfeline wants to merge 1 commit into
Open
docs(spec): the two open measurements are settled — and one premise was wrong#352stellarfeline wants to merge 1 commit into
stellarfeline wants to merge 1 commit into
Conversation
…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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
deathCountscoreboard criterion, guarded byunless data entity @s {Health:0.0f}, which is exactly what deferscp_respawn_checkto 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;
LastDeathLocationis 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_deathcan 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_playercovers 1 of 5 causes.entity_hurt_playerfires 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.0000in 46/46 trials, including teleports 143 and 157 blocks straight up. Landing damage isfloor(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 − 3is a fit); whether a real client matches the bot; and what does reset fall distance — only same-dimension/teleportwas tested, so the mechanism that would make a lift safe is unmeasured.Two incidental findings that constrain the verbs
Incorrect argument for commandand 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./killanswersKilled <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-dupesandcheck-reference-versionsgreen. The measurements themselves landed in #349 with the rig and 4140 raw samples committed and re-runnable.