grom opened the quest I had photographed on the reference client and counted
two reward buttons where we paint three. Yesterday I told him the reference
draws the same empty button, citing the DETAILS publisher. That reading was of
the wrong layer: `0x500ef0` really does copy `count` entries in with no test on
the item id (`500f41`-`500f58`) and zero-fill the rest — but the drop happens
one layer up, in the count.
`GetNumQuestChoices` (`0x501f00`) is a wrapper over `0x5016c0`, which walks the
six 36-byte records at `0xbdf020`, tests the record's item-id dword and `je`s
out of the loop on the first zero. It is a take-while, not a filter: a zero row
hides every row behind it too, and `GetNumQuestRewards` (`0x501ec0` →
`0x5016a0`) is the same loop on the reward triple's own first dword.
The record layout is pinned off `0x501700`, the shared row reader, which
string-compares the Lua type argument against 'reward' / 'choice' / 'required'
and reads `+0x00/+0x04/+0x08`, `+0x0c/+0x10/+0x14` and `+0x18/+0x1c/+0x20`
respectively; the first dword of each triple is the item id — it is what gets
pushed into the item-cache query at `0x55ba30` — and the third is the count. So
the publisher's pad is `(id 0, display 0, count 1)`, which is exactly the
`item 0 x1, displayId 0` the instrument printed on his session.
`GetNumQuestItems` keeps `.len()`: its counter (`0x5016e0`, from `0x501f40`)
tests `+0x1c`, the *display* id, not the item id at `+0x18` — the one counter of
the three that reads the wrong dword of its own triple — and QuestItemView
carries no display id to reproduce that from.
The instrument stays, narrowed to the case that is genuinely ours: a wire row
that names a real item and still resolves to neither a name nor an icon.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
3f29824458