The offsets came out of the realm's own patched `WoW.exe`, which carries
the patch in a PE section it names `.octoql` — 488 bytes used of 20 KB
at VA 0xd26000. `GetNumQuestLogEntries` (0x4df8b0, from
`reference/1.12-shapes.tsv`) begins `jmp 0xd26145`, and the routine the
detour calls at 0xd26000 is the entire contract in eight instructions:
slot against 20, 12 bytes per slot, `+0x28` for the first twenty and
`+0x10C8` for the next five, against the same `%edx`, with a `cmp $0x5`
that is the 25 the realm's Lua also declares.
Both arms index one dword array, so the step between the blocks is
`(0x10C8 - 0x28) / 4` = 1064 and slot 20 is field 198 + 1064 = 1262.
That checks out twice independently: 198 × 4 = 0x318, so `%edx` is the
field array plus 188 dwords, which is exactly `UNIT_END` — the player
block's own base, with `0x28` as slot 0 inside it; and 1262 is
`PLAYER_FIELD_COMBAT_RATING_1`, 1.12's dead twenty-field block, which is
what their `QuestLogFrame.lua` says in prose. Five slots take 15 of
those 20 fields, which is also exactly the run the detour's own
change-poll walks (`cmp $0xf`) before calling the client's
quest-log-changed path itself, those fields raising nothing.
`player_quest_log_field` holds both blocks and every caller already
iterates `0..PLAYER_QUEST_LOG_SLOTS`, so the quest log, the markers and
the probes pick the five up unchanged. The test pins each boundary and
the 1064 step against the disassembly, because every number here came
off a listing and a one-field slip reads a neighbour's counters.
Stated in the doc rather than guarded: a server that wrote real combat
ratings there would show slot 21 as a phantom quest. None does — the
block is dead in 1.12 and vmangos never writes it — and gating this
would mean asking the interface what the protocol should parse.
269 data-gated failures, identical to the baseline, all nine gates green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
56bdd15cfe