RF455-113 RF 4.55: the KO window's second revive button (03/47, revive at HQ) is dropped unhandled, and the killer's name is never sent in 03/17

Game: RF 4.55 (Dragonborn), server v0.4.0, Windows build (stock gameserver.exe, SHA-256 0b9c9099…). Client: the supported Taiwan build, RF_Online.bin SHA-256 46528aac…2bbc558 (2025-07-16), Language=Taiwan. Expected (wiki): the 4.151 "Ataraxia's Arrival" patch notes describe the KO window: revive in place or at the save point, the killer's name, and an auto-revive countdown.

Summary

• The death window (CGUIReviveInfoWindow) has exactly two revive buttons. One sends 03/25 player_revival_request_clzo (handled: revive at the bind point / race start). The other sends 03/47 player_revival_request_hq_clzo, which no handler receives — the window closes and nothing happens; the player stays dead with no reply.
• The window also renders a killer-info line (who killed you) from fields in the death message 03/17 — two bytes at message offsets 6–7 and a name string from offset 8. The server's 03/17 is 8 bytes total (header + u32 + u16), so the name is read past the end of the message and shows blank/garbage.
• The window's auto-revive countdown is a client-local 300-second display that does nothing at zero (read); the revive is always manual. Reported for completeness; the two items above are the actionable bugs.
• The "revive in place" options are the revival potions (temp effects 52/72), already reported as part of RF455-037Released (potions not modelled).

Client side

• CGUIReviveInfoWindow (vtable 0xaea844), event handler 0x7732f0: button this+0x800 → 0x567bd0 builds header 03/25 with an empty body; button this+0x940 → 0x567c60 builds header 03/47 with an empty body (both through the standard send at 0x562be0). No choice byte; the destination is the opcode.
• Own-death 03/17 handler 0x5661d0: at 0x5662b4–0x5662cf it passes message bytes [6], [7] and the string at +8 into the window populate 0x773650, which formats the killer line (NDLanguage 0x78b/0x3d/0x3e/0x1545).
• Countdown: populate sets a local counter to 300 (0x773680); the per-frame update decrements once a second, turns red at 10, stops at −1 and never sends 03/25.

Server side

• registerWorldHandlers 0x14087dc00 registers these type-3 subs: 0x0b, 0x13, 0x15, 0x16, 0x19, 0x1e, 0x1f, 0x20, 0x21, 0x24, 0x25, 0x29, 0x2e, 0x31, 0x3f, 0x45. There is no 0x47 — mov ebx, 0x47 appears nowhere in the gameserver package — so 03/47 falls through to the unknown-opcode hex log.
• 03/25 → handleRevival 0x14080bd40 → reviveDest → the character's bind point, else the race start point.
• onPlayerDeath 0x14080b800 builds 03/17 at 0x14080b8cf: makeslice(8), opcode 0x1703, u32 at +2, u16 at +6, broadcast with length 8. No killer fields. (The client parses a longer retail 03/17 — inferred from the client code; I don't have a retail capture.)

Suggested fix

• Handle 03/47: revive at the race HQ (the race start point on the home map — what reviveDest already returns when there is no bind point). If both buttons are meant to differ, 03/25 should honour the bind point and 03/47 force the HQ.
• Extend the 03/17 sent to the dying player with the killer fields the client parses: byte, byte, then the killer's name as a zero-terminated string at message offset 8 (the attacker is known in onPlayerDeath's callers: monsterMelee, PvP kill paths, onPlayerKilled). The broadcast copy to others can stay short if the length byte distinguishes them.

Local workaround

None.