A hardcore gravestone gave no tooltip, and his log had the whole answer:
`go plate: 0xf112aea6e34d2828 has no template yet — asked, drawing nothing`. The
pick landed perfectly; the plate's only silent exit is the template. And the
guid says why — high `0xF112` names no 1.12 object family (`HIGHGUID_GAMEOBJECT`
is `0xF110`), so `guid::entry` answered `None`, `request` returned at its first
line, and the query was never sent. The word "asked" in that line was a lie.
Two graves differ in the entry slot by 77 (`…aea6e3…`, `…aea730…`), so on this
realm that slot is a counter, not an entry. `OBJECT_FIELD_ENTRY` is the
reference's own cache key (`0x60b160`) — the lesson `names.rs` and
`ui_pet_stats.rs` already carry for creatures and pets, where a guid's middle
field holds a pet number instead.
So `request` takes the descriptor's entry, and remembers the guid only when the
two disagree: a 1.12 guid costs nothing, and all sixteen lookup sites keep
taking a bare guid, which is all a hover has. `ui_item_text`'s is-a-GameObject
test goes the same way — `OBJECT_FIELD_TYPE` bit `0x20` first, guid bits only
when no descriptor arrived — because reading a custom object as an item asks the
wrong query entirely.
If a grave still draws nothing, the plate's line now prints the entry it asked
under, which says whether the server refused it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
a3334b279e