Files
benilla-octo/docs
gromandClaude Opus 5 b5259bd608 The missing item values were eight absent id getters, not the tooltips
grom reported no item values on quest-reward tooltips. The value line is pfUI's,
and `modules/sellvalue.lua` says plainly how it works: it hooks every `Set*Item`
tooltip verb and takes the row's **id** — never its link — then asks
`C_Item.GetItemSellPriceByID`. An absent getter answers nil and
`AddVendorPrices` returns on its first line.

So it was never about quests. This client answered exactly two members of that
family, `C_Container.GetContainerItemID` and `GetInventoryItemID`, which is why
his bag and equipped items had a price line and his quest rewards, loot rows,
loot rolls, merchant rows, mail attachments and trade-skill rows did not. The
other eight are here: `GetQuestItemID`, `GetQuestLogItemID`,
`GetLootSlotItemID`, `GetLootRollItemID`, `GetMerchantItemID`,
`GetInboxItemID`, `GetTradeSkillItemID`, `GetTradeSkillReagentItemID`. Each sits
beside that row's own `*Link` getter, in that row's own module, reading state
already held — no new feed, no new state.

The id is also the **earlier** fact, which is the part worth keeping in mind. An
item id rides the packet; a link is built only once the item's template has
landed to give it a name and quality, and `ui_quest::resolve_item` says so in as
many words. A quest reward is close to the worst case for that — it is usually
an
item the player has never seen, so its template is not in the 14,000-row cache
and the first hover beats the answer home. These getters answer there, where the
link beside them is still nil; the test asserts exactly that contrast.

Also, from the same thread of play reports: the sell-junk sweep now says what it
could not judge. `SellAllJunkItems` and `GetNumJunkItems` both gate on a *known*
poor quality, and a carried slot's quality is `None` until its template arrives,
so a grey sitting in such a slot is neither counted nor sold — which is what
"not all grey items sell" looks like from outside. Whether that is in fact the
cause is not something this end can tell, so the sweep records the slots it
skipped for that reason, with their item ids, once per click. If the next log
names some, the fix is to wait for those templates; if it names none, the cause
is downstream in the drain or the server's refusal, and the line says that too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
2026-10-28 22:13:28 -06:00
..