Commit Graph
3 Commits
Author SHA1 Message Date
SamandClaude Opus 5.5 c025c9a1ae tests: 24 protocol tests check what their names claim
Thirteen now assert what they claimed:
- every bare trade status, and the 444-byte extended snapshot for
  empty, full and mixed slots;
- the status-1 and status-3 battlefield tails;
- every quest-share verdict byte through encode, parse and decode;
- the greeting pick itself, and the whole compressed-move batch.

Eleven are renamed to what they check, where the claim had nothing to
check against: no capture bytes, no production opcode list, no server
encoder. No strengthened assertion failed.

Probe and assert messages drop their record numbers. The aura probe's
refusal message no longer claims the level-6 probe accounts need a
grant for a level-4 command.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 21:04:27 +07:00
SamandClaude Opus 5.5 bfb5c008b8 comments: protocol, the auth to reputation integration tests
1,039 comment lines become 472 across 19 files; the code is unchanged.
The movement test's claim that write() never serializes a transport
tail is gone: it does.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 20:12:46 +07:00
SamandClaude Fable 5 ea3ff5d050 quest sharing is in, and declining at an NPC reopens its list
- quest sharing lands whole: four opcodes, the Share button live with the reference's own predicate (registering the one party event it does for the one reason it does — joining a party changes the answer without changing the log), nine verdict lines for the sharer, and the escort confirm as its own dialog whose No sends nothing at all, because there is no decline packet for it; the push result's u64 means two things by direction — the sharer being answered going up, the member the verdict is ABOUT coming down — and the verdict stays a raw byte so an unmapped value shows the reference's own nothing rather than killing the packet
- the receiving half needs almost no code, and that is the design: the server sends an eligible member an ORDINARY quest-details packet whose giver guid is the sharing PLAYER, and Accept answers with the ordinary accept — a shared quest lands on the questgiver panel we already have, and the guid's own type bits drive the two real differences: declining a share owes the sharer a DECLINE verdict, and the panel is not held to the 5.56-yard NPC service range (the server's bound for a share is 14 yards, tested at accept)
- the fold-back corrected three things days-old code had just shipped: DeclineQuest and CloseQuest are ONE routine in the reference — what varies is the giver, not which button you pressed; declining an NPC's quest RE-OPENS its list — the session end sends the giver a fresh hello, refuting our five-month-old claim that "vanilla's client-side decline sends no packet" (and the details packet's trailing u32 we had parsed and ignored is exactly what suppresses that re-open) — so declining at an NPC now returns you to its menu instead of closing the window; and BUSY is the client's OWN verdict — a share arriving while any panel is open is refused client-side, covering the mid-turn-in case the server cannot see

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 20:14:06 +07:00