A book says what it teaches, once the client has fetched the sentence #65

Manually merged
atanabe merged 5 commits from feat/065-a-book-says-what-it-teaches-once-the-client-ha into master 2026-09-04 06:55:36 +02:00
Owner

plan: add 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha

Along the way:

  • plan: start 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha
  • A book says what it teaches, once the client has fetched the sentence
  • plan: say 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha
  • plan: done 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha

Touches 8 files: plan/tickets/01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha/comments/01M1ZXK9A2DQN15DXYHF6W16DW.md, plan/tickets/01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha/ticket.md, scripts/harness/client/03-player.lua, scripts/harness/client/04-hands.lua, scripts/harness/sections/48-tooltip-arrival.lua, src/Core/Core.lua and 2 more.

plan: add 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha Along the way: - plan: start 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha - A book says what it teaches, once the client has fetched the sentence - plan: say 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha - plan: done 01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha Touches 8 files: `plan/tickets/01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha/comments/01M1ZXK9A2DQN15DXYHF6W16DW.md`, `plan/tickets/01M1ZXA5FV39H0A97Q0H7TSWFR-a-book-s-use-line-waits-on-a-spell-the-client-ha/ticket.md`, `scripts/harness/client/03-player.lua`, `scripts/harness/client/04-hands.lua`, `scripts/harness/sections/48-tooltip-arrival.lua`, `src/Core/Core.lua` and 2 more.
atanabe approved these changes 2026-09-03 06:25:16 +02:00
atanabe left a comment

A book waiting for the client to fetch its sentence is the right shape, and the ticket says what the reader does in the meantime. One note.

A book waiting for the client to fetch its sentence is the right shape, and the ticket says what the reader does in the meantime. One note.
@ -315,0 +368,4 @@
-- the text has landed, which is what UI/Tip.lua listens for.
local fetch = space.RequestLoadSpellData
if type(fetch) == "function" then
pcall(fetch, id)
Owner

pcall round the fetch and then an unconditional true. So the caller is told the request went out whether or not it did, and the only thing that ever corrects that is the text arriving. What tells the caller it never will?

`pcall` round the fetch and then an unconditional true. So the caller is told the request went out whether or not it did, and the only thing that ever corrects that is the text arriving. What tells the caller it never will?
Author
Owner

Nothing does, and that is the honest answer: there is no failure event for a fetch this client drops. The reader keeps the line it has and asks again the next time the book is opened, which is written above the call now.

Nothing does, and that is the honest answer: there is no failure event for a fetch this client drops. The reader keeps the line it has and asks again the next time the book is opened, which is written above the call now.
Hover Master First Aid - Doctor in the House in the bags and the box said the
name, the item level and "Requires First Aid (300)". The line it is carried
for, "Use: Teaches you advanced first aid, allowing a maximum of 375 first aid
skill.", was not there at all.

That line is not the item's. It is the spell's own sentence printed on the
item, and the client does not hold every spell's text at all times: it fetches
one when something asks for it and leaves the line off the tooltip until it
lands. A potion or a trinket reads correctly on the first hover because its
spell is already on the machine. A book teaching something nobody has ever
cast is the case where nothing ever asked, which is why this went unnoticed
while every other Use line in the addon was right.

UI/Scan.lua reads a tooltip once, at the moment the pointer arrives. Thin in
UI/Tip.lua already rebuilds a box that was waiting on an item and could not see
this one: the head band had lines in it and none of them was
RETRIEVING_ITEM_INFO. A box that looks finished and is not needs a second
question rather than a second reading of the same one.

So Scan.Waiting asks it. The item's spell id, whether its text is here, and the
request for one that is not, which are the three calls Syndicator makes on this
client in Search/CheckItem.lua. Thin counts a box waiting on that spell as
thin, SPELL_DATA_LOAD_RESULT joins GET_ITEM_INFO_RECEIVED on the frame that
drives the rebuild, and the box fills in where it stands. A worn slot carries
no link so one is asked for: a trinket you press has a Use line the same as a
book does, and the character sheet is nineteen hovers that all read a slot.

ns.ItemSpell hands back the id beside the name now. Nothing else reads it.

48-tooltip-arrival.lua is the gate, on a book fixture whose spell is not
cached: the first hover draws the client's own text without the Use line and
asks for the spell, and the sentence is in the box after the load lands. The
ask is asserted on its own, because a box that draws nothing and never asks is
a box that will draw nothing forever.
atanabe manually merged commit bf11ff4201 into master 2026-09-04 06:55:36 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
northgale/warriorkit!65
No description provided.