Skip to content

Item use follows the client: bag store, bar equip, BoE hold, control - #1086

Merged
samwhosung merged 11 commits into
mainfrom
sess/itemuse
Oct 12, 2026
Merged

Item use follows the client: bag store, bar equip, BoE hold, control#1086
samwhosung merged 11 commits into
mainfrom
sess/itemuse

Conversation

@samwhosung

@samwhosung samwhosung commented Oct 12, 2026

Copy link
Copy Markdown
Owner

Five item-use paths differed from 1.12.1's bytes:

  • PutItemInBag swapped a worn item instead of storing it (0x4c7d44), and sent a bag into itself (0x4c7cea).
  • UseSoulstone skipped the cast cancel before its use (0x48ae6b → 0x6e4940).
  • The bar's equip left a held item on the cursor; it now runs 0x5e1840 → SetCursorItem.
  • The bind-on-equip confirm emptied the cursor; the item now stays held under the question (0x5e16ce).
  • Item use ignored loss of control. The dispatcher's requirement and control gates (0x5d8e0e, 0x5d8eaa), the equip and SetCursorItem gates, the fear/charm exemption (0x6e9d70) and the trade-window refusal (0x1b4) now apply. They read our own character's control only (0x5fa600).

Tests cover each path and gate.

Fixes #1057
Fixes #1075
Fixes #1078
Fixes #1076
Fixes #1077

🤖 Generated with Claude Code

🤖 Generated with Claude Code

samwhosung and others added 11 commits October 13, 2026 05:07
@samwhosung @claude
PutItemInBag stores a worn item and cancels on its own bag
820b7ad 
The swap fork is a held item from bag slots 19-22 (0x4c7d44-0x4c7d5e) or a container (0x4c7dc4);
a held doll item of any other slot goes to the auto-store (0x4c7e06, 0x5e12e0). An item held from
inside the target bag cancels first, ClearCursor(1,1) with answer 1 and nothing sent
(0x4c7cea-0x4c7d11), where the store named the same bag.

Fixes #1057

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
UseSoulstone cancels the cast in flight before its item use
76d548b 
The item leg runs AbortCast(1,1) before the use (0x48ae6b -> 0x6e4940, reason 0x1c; use at
0x48ae7d): a pending targeting spell is dropped (0x6e4955), else the cast in flight is cancelled
on the wire (0x6e4970); the local event is SPELLCAST_FAILED and the trade-skill repeat ends
(0x4fd790). It runs ahead of the use's locked-item gate (0x5d8d32).

Fixes #1075

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
The bar's equip puts its item on the cursor, dropping a held one
7846c4f 
A bar slot's equip runs 0x4e602a -> 0x5e1840 -> SetCursorItem 0x494b60 -> AutoEquipCursorItem.
SetCursorItem's inner clear unlocks and drops a held item (ecx=1 at 0x494bb6, unlock at 0x4951d9),
the bar's item takes the cursor unlocked, and the send's clear empties it; a projectile's clear
unlocks (0x5e1763).

Fixes #1078

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
AutoEquipCursorItem keeps a bind-on-equip item held under its question
21670f9 
The bind-confirm arm fires AUTOEQUIP_BIND_CONFIRM (0x5e16c6) and returns (0x5e16ce) with no
ClearCursor, so the item stays on the cursor with the lock it held, and CancelPendingEquip
(0x5e1c50) only unlocks. The verb now decides in the call, off the slot's bonding and bound flag,
not in a drain after the clear. The bag's right-click and the bar put the item on the cursor first
(0x5e1840 -> 0x494b60), and the accept re-issues from the slot (0x5e1c23).

Fixes #1076

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
Item equips and the open arm refuse without control of the character
ce1e3ed 
The equip arm returns when [0xb4b3e4] is clear and the player is not on a taxi (0x4fa3ce-0x4fa3ec),
before its lock and send. SetCursorItem returns before its clear and set under the same test
(0x494b8d), which the bar's equip meets; 0x5e1840 still runs AutoEquipCursorItem after it
(0x5e18c9, 0x5e18d5). The use dispatcher runs the requirement check (0x5d8e0e; line 0x7 for the
proficiency leg, else 0x9c) and the control gate (0x5d8eaa, line 0x7f) before the open arm's lock.

Fixes #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
The item use gates guard every arm the dispatcher runs them ahead of
e318207 
CGItem::Use (0x5d8d00) runs the requirement check (0x5d8e0e) ahead of the PageText book (0x5d8e4c),
the mail letter (0x5d8e7b), the lootable arm and the generic use, and the control gate (0x5d8eaa,
line 0x7f) ahead of the lootable arm, the charter (0x5d8f95) and the generic use; the gift, wrap and
quest-starter arms run before both. The bag's read, letter, open and plain forks and the doll's
UseInventoryItem (0x4c7af0) now meet them in the call. An item with no on-use spell is refused
without control (0x5d8ec7, 0x5d8ee7) unless its spell is one the app feeds as passing.

Refs #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
An item whose spell breaks the control loss passes the control gate
4eaf580 
Without control, the dispatcher lets an item through when its on-use spell grants immunity to the
aura that took it (0x5d8ec0-0x5d8f6a): fleeing (flag bit 23) asks 0x6e9f20, aura type 7; confused
(bit 22) 0x6e9f40, type 5; charmed (CHARMEDBY set) 0x6e9f60, types 6, 177 and 2. Each helper runs
the scanner 0x6e9ca0 over the caster's 48 aura slots with the immunity matcher 0x6e9d70, which
needs AttributesEx bit 15 on the cast spell. The feed computes the passing spells off the flags
and auras and hands them to the VM, the same scanner and matcher the cast ladder uses.

Refs #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
0x5e1840 refuses an item offered in the trade window
733b67c 
An item among the trade window's offered slots (0x4bfd20) shows ERR_EQUIP_TRADE_ITEM (id 0x1b4,
0x5e18a5) and ends before SetCursorItem and AutoEquipCursorItem; the bag's right-click, the
action bar and the bind-confirm accept all run it. A refused right-click sends nothing, and still
locks the item (0x4fa418).

Fixes #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
HasFullControl and the control gates follow our own character only
232d199 
0x5fa600 writes [0xb4b3e4] and fires PLAYER_CONTROL_LOST only when the unit the packet names is our
own character (0x5fa6d0). A possessed creature released while feared or confused stops the mover we
drive but leaves the flag alone. The VM's control flag, its events and the item gate's exemption
feed now read the player's own control, kept apart from the mover's.

Refs #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
The app-sent item uses meet the dispatcher's gates
c40412c 
The bar's item use (0x4e607b), the soulstone (0x48ae7d) and a confirmed bind-on-use (0x5d92c1)
call CGItem::Use (0x5d8d00) directly, so they meet its requirement check (0x5d8e0e) and control
gate (0x5d8eaa, line 0x7f) past the quest-starter arm (0x5d8dcc), which runs ahead of both. The
bar's key for a trinket or potion no longer sends while feared unless its spell passes.

Refs #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung @claude
The trade request and attack legs read our own control
b5c94c5 
Both test [0xb4b3e4] (0x4bf79c, 0x48269b), which 0x5fa600 writes for our own character only
(0x5fa6d0): a possessed creature stuck under fear no longer makes us answer a trade request busy or
turns the attack cursor to Point. The mover's frozen state stays on control_lost, which the
movement, steering and input readers still need.

Refs #1077

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@samwhosung
samwhosung merged commit a7f331e into main Oct 12, 2026
1 check passed
@samwhosung
samwhosung deleted the sess/itemuse branch October 12, 2026 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment