fix(items): preserve wand stance and corpse use order
Keep active-combat AutoWield intent through ACE's pre-wield transition and queued trailing peace notice, while allowing explicit combat input to supersede it. Queue one-shot item interactions until the frame's movement edge has been serialized, so a movement release cannot cancel ACE's server-side corpse approach callback. Release build succeeds and all 5,890 runnable tests pass with five intentional skips. Co-authored-by: OpenAI Codex <codex@openai.com>
This commit is contained in:
parent
0392c6d721
commit
e6dd8bf6fa
10 changed files with 303 additions and 22 deletions
|
|
@ -116,11 +116,20 @@ on server-confirmed WieldObject(item):
|
|||
retain the ready mode implied by the confirmed equip location
|
||||
|
||||
on combat-mode notices after confirmed WieldObject:
|
||||
if the first notice is the retained ready mode:
|
||||
if the first notice is the retained ready mode
|
||||
and no authoritative transition occurred during blocker removal:
|
||||
clear the retained mode; the server already settled correctly
|
||||
else if notices form NonCombat -> retained ready mode -> NonCombat:
|
||||
else if blocker removal already emitted a non-ready transition
|
||||
and notices finish retained ready mode -> NonCombat:
|
||||
clear the retained mode
|
||||
request that ready mode from ACE's trailing NonCombat notice
|
||||
else if post-wield notices form NonCombat -> retained ready mode -> NonCombat:
|
||||
clear the retained mode
|
||||
request that ready mode from ACE's trailing NonCombat notice
|
||||
|
||||
on explicit user combat-mode request:
|
||||
clear retained AutoWield mode intent
|
||||
the user's newer request wins
|
||||
|
||||
on PrivateUpdatePropertyInt(property = CombatMode, value):
|
||||
if value is exactly NonCombat, Melee, Missile, or Magic:
|
||||
|
|
@ -145,12 +154,17 @@ not need a second request against the retail server.
|
|||
|
||||
acdream therefore preserves the user's desired ready mode only when AutoWield
|
||||
begins in active combat. Authoritative `WieldObject` arms settlement. A server
|
||||
whose first subsequent notice is already the desired mode needs no request.
|
||||
Local ACE instead emits `NonCombat -> desired mode -> NonCombat`; the client
|
||||
that emitted no blocker transition and immediately reports the desired mode
|
||||
needs no request. Local ACE can begin its old-weapon transition before
|
||||
`WieldObject`, report the desired mode for the new weapon, and then publish a
|
||||
queued trailing `NonCombat`; it can also emit the complete
|
||||
`NonCombat -> desired mode -> NonCombat` tail after `WieldObject`. The client
|
||||
sends one normal `ChangeCombatMode` request from that trailing notice,
|
||||
necessarily after the queued callback that caused it. All resulting state and animation remain server-
|
||||
authoritative. No update is ignored, delayed, or locally fabricated, and a
|
||||
transaction begun in peace sends no mode request. This narrow server-
|
||||
transaction begun in peace sends no mode request. An explicit user combat-mode
|
||||
request cancels retained settlement so the compatibility owner cannot fight a
|
||||
deliberate switch to Peace. This narrow server-
|
||||
compatibility adaptation is recorded as AP-118.
|
||||
|
||||
The request is not complete when `GetAndWieldItem` is merely sent. Retail
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue