Put the killer's remaining health on the death notice, so a lost duel tells you whether you were one bullet away.
FeedEntry (src/client/world.ts, pushed in onKill) carries killer, killerId, victim, weapon, headshot and killerTeam — no health. deathNotice in src/client/spectate.ts hands that entry to hud.ts:530, which draws You are dead and who killed you, and the one number that makes the line worth reading is missing. CS has shown it for twenty years because it is the difference between I was outplayed and I had them at 8 hp.
It is a fact about the moment, not a live reading: record it at the kill and never re-read the killer afterwards, or a spectator learns the health of someone they should not see.
Done looks like
[ ] FeedEntry gains killerHealth (and killerArmor, if the HUD shows it), set in onKill from the killer as they were at that instant.
[ ] The dead panel reads e.g. Killed by Vika — AK-47 (headshot), 23 hp left, escaped and clamped like every other HUD string, and says nothing about health when the killer is the victim (bomb, own grenade).
[ ] A test steps a real kill through world.ts, damages the killer afterwards, and asserts the feed entry still holds the health at the moment of the kill.
[ ] The kill feed itself is unchanged — this is the death panel only, so the line above the crosshair does not grow.
[ ] saved.ts is untouched: the feed is not part of a snapshot, and a resumed match must still validate byte-for-byte as it does today. A test asserts a round-trip is unaffected.
[ ] bun run check green, with a test that fails without the change.
Files I expect to change
src/client/world.ts — the FeedEntry type and onKill.
README.md — the sentence describing what dying shows you.
Risks
FeedEntry is pushed on every bot kill too; one extra number per entry, on a list capped at five, is nothing — but do not start reading the killer live in the draw, which is the mistake this issue exists to avoid.
#199 also touches the kill path; these two do not overlap in the lines they change (effects vs. the feed entry), but a builder taking both should take them in one run.
Put the killer's remaining health on the death notice, so a lost duel tells you whether you were one bullet away.
FeedEntry(src/client/world.ts, pushed inonKill) carrieskiller,killerId,victim,weapon,headshotandkillerTeam— no health.deathNoticeinsrc/client/spectate.tshands that entry tohud.ts:530, which draws You are dead and who killed you, and the one number that makes the line worth reading is missing. CS has shown it for twenty years because it is the difference between I was outplayed and I had them at 8 hp.It is a fact about the moment, not a live reading: record it at the kill and never re-read the killer afterwards, or a spectator learns the health of someone they should not see.
Done looks like
FeedEntrygainskillerHealth(andkillerArmor, if the HUD shows it), set inonKillfrom the killer as they were at that instant.Killed by Vika — AK-47 (headshot), 23 hp left, escaped and clamped like every other HUD string, and says nothing about health when the killer is the victim (bomb, own grenade).world.ts, damages the killer afterwards, and asserts the feed entry still holds the health at the moment of the kill.saved.tsis untouched: the feed is not part of a snapshot, and a resumed match must still validate byte-for-byte as it does today. A test asserts a round-trip is unaffected.bun run checkgreen, with a test that fails without the change.Files I expect to change
src/client/world.ts— theFeedEntrytype andonKill.src/client/hud.ts— the dead panel's line.src/client/world.test.ts,src/client/hud.test.ts,src/client/spectate.test.ts.README.md— the sentence describing what dying shows you.Risks
FeedEntryis pushed on every bot kill too; one extra number per entry, on a list capped at five, is nothing — but do not start reading the killer live in the draw, which is the mistake this issue exists to avoid.Crew
vesper — the world tick and the HUD.