erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

fix(chat): Campaign CH user-gate round 1 — jump-in-air edge, portal cue cadence, wrap/prefix/color fixes

Browse source 
The user tested Campaign CH's CODE-COMPLETE build live and reported ten
defects (docs/plans/2026-08-09-chat-parity-campaign.md, "User gate —
round 1"). Items A-G are fixed here; the remaining three (extra chat
windows on 1/2/3/4, resize working in only one corner, transparency/
artifacts) are out of scope for a fix and filed as slice CH6.

A. Jump-in-air refusal never fired live: the jump block only ever
   evaluated input.Jump inside the grounded-charge or already-charging
   branches. PlayerMovementController now detects the press RISING EDGE
   while airborne and reports WeenieError.NotGrounded once per press,
   leaving the grounded charge/fire path untouched.
B. ChatVM's invented "[System] " prefix is dropped — retail prints
   system text bare. [Popup] is unchanged (AP-175).
C. SpewBoxController's color is now the user-pinned exact value
   (1, 1, 0.247, 1), the same bright yellow as an incoming Tell.
   Register row AP-178 updated: color CLOSES, size/position/font stay
   open per the user's live report that they still differ.
D. Closes #329: PortalTunnelPresentation now emits the portal wait cue
   unconditionally on every rotation-segment boundary, matching
   gmSmartBoxUI::UseTime's decompiled else-arm exactly instead of gating
   on a 5-second hold local transits never reached. PortalWaitNotice
   Controller now renders it in the same pinned yellow as item C.
   Register row AP-150 retired.
E. Closes #362: new ClientCommandResponses.cs parses and renders the
   four previously-unhandled inbound GameEvents (ChannelIndex,
   ChannelList, AvailableHouses, AllegianceInfoResponse), each ported
   line-for-line from the named-retail decomp's inbound handlers.
   Register row TS-70 retired.
F. ChatWindowController.WrapText now splits on embedded '\n'/'\r\n'
   first, then word-wraps each segment independently — server text like
   /help's reply no longer collapses onto one line.
G. The chat input field's right edge no longer holds a fixed absolute
   pixel position across a window resize; Bind now upgrades it to
   retail edge-mode 1 (UiLayoutPolicy) or the AnchorEdges.Right stretch
   fallback so it tracks the window's client width instead of
   overflowing past a narrower resize.

Full Release suite: 12,247 passed / 4 skipped / 0 failed (baseline
12,221/4/0 + 26 new tests across items A, E, F, G).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-09 23:42:32 +02:00
parent d1c1368a5e
commit 47e40900f3
17 changed files with 1428 additions and 81 deletions
Download patch file Download diff file Expand all files Collapse all files

126
docs/ISSUES.md
View file

@ -94,21 +94,6 @@ Register row: TS-69.
**Campaign:** `docs/plans/2026-08-09-chat-parity-campaign.md` (Campaign CH,
slice CH4).
## #362 — Four new CH4 outbound requests have no inbound response handler
**Status:** OPEN — filed 2026-08-09, Campaign CH slice CH4. `@index`,
`@clist`, `@hslist`, and `@allegiance info` send byte-correct retail
GameAction requests (`ClientCommandRequests.BuildIndexChannels`/
`BuildListChannel`/`BuildListAvailableHouses`/`BuildAllegianceInfoRequest`),
but their GameEvent responses (`ChannelIndex 0x0149`, `ChannelList
0x0148`, `AvailableHouses 0x0271`, `AllegianceInfoResponse 0x027C`) are
registered in `GameEventType` with no `GameEventWiring` handler — ACE's
reply is silently dropped. The request itself is correct and verifiable
on the wire; only the response rendering is missing. Register row: TS-70.
**Campaign:** `docs/plans/2026-08-09-chat-parity-campaign.md` (Campaign CH,
slice CH4).
## #363 — Chat refusal/usage call sites are typed ClientLocal 0x00 where retail types several 0x1A
**Status:** OPEN — filed 2026-08-09, CH4 REJECT-review, SHOULD-FIX 9.
@ -1949,39 +1934,6 @@ overlaps the Slice-J ownership work. If it is ever *accepted* rather than
fixed, it needs a divergence-register row; it is filed here as a defect
because the intent is to fix it.
## #329 — The portal wait cue arms five seconds late; retail emits it per tunnel rotation segment, unconditionally
**Status:** OPEN
**Severity:** LOW (cosmetic, but it is a retail divergence on every single
portal, in both directions)
**Filed:** 2026-08-06, #280 retail-conformance review, finding F2.
**Register row:** AP-150.
acdream suppresses `"In Portal Space - Please Wait..."` until the hold has run
five seconds (`RuntimeWorldTransitState.RetailWaitCueDelay`), then re-emits it
per rotation segment only while `_waitCueVisible`
(`PortalTunnelPresentation.TickRotation`).
Retail has no threshold. `gmSmartBoxUI::UseTime` @0x004D6E30 emits
`ECM_UI::SendNotice_DisplayStringInfo(0x1a, …)` in the `else` arm of the
rotation-segment-expiry test at 0x004D6FCD — i.e. every time a segment expires,
whether or not `CellManager::blocking_for_cells` is set. Segment duration is
`RandDouble(0.6, 1.8)` s, byte-decoded at 0x004D6FE6. acdream's own
`RotationDurationMin`/`Max` already match retail exactly, so only the arming is
wrong.
The unrelated 5.0 s constant at VA 0x007991B0 is
`CellManager::CheckPrefetchStatus`'s retry cadence, and was mis-attributed to
the cue by #280's commit message (retracted in the contract doc).
**Consequence:** every portal shorter than 5 s shows a silent tunnel where
retail shows the notice; every portal longer than 5 s shows it 3.2-4.4 s late.
**Fix shape:** delete the delay and emit on the same segment boundary the
rotation already computes. One-line arming change, but it is a user-visible
presentation change and wants the user's eyes before it lands — do not fold it
into an unrelated commit.
## #325 — Gate A's teleport test is narrower than retail's: a ForcePosition carrying a NEWER teleport stamp is misrouted into a full Apply
**Status:** OPEN
@ -14162,6 +14114,84 @@ outdoors at the angle that previously erased it.
# Recently closed
## #362 — [DONE 2026-08-09] Four new CH4 outbound requests have no inbound response handler
**Closed:** 2026-08-09, Campaign CH user-gate round 1, item E.
**Filed:** 2026-08-09, Campaign CH slice CH4.
**Register row:** TS-70, RETIRED in the same commit.
**Resolution:** `@index`, `@clist`, `@hslist`, and `@allegiance info` sent
byte-correct retail GameAction requests
(`ClientCommandRequests.BuildIndexChannels`/`BuildListChannel`/
`BuildListAvailableHouses`/`BuildAllegianceInfoRequest`), but their
GameEvent responses (`ChannelIndex 0x0149`, `ChannelList 0x0148`,
`AvailableHouses 0x0271`, `AllegianceInfoResponse 0x027C`) had no
`GameEventWiring` handler — ACE's reply was silently dropped. New
`ClientCommandResponses.cs` (`src/AcDream.Core.Net/Messages/`) parses all
four wire shapes (cross-checked against ACE's
`GameEventChannelIndex`/`GameEventChannelList`/`GameEventHouseAvailableHouses`/
`GameEventAllegianceInfoResponse` writers) and renders retail-shaped
`LogTextType 0x00` (Default) lines ported verbatim from the named-retail
decomp:
- ChannelIndex/ChannelList: `Handle_Communication__ChannelIndex`/`ChannelList`
@0x0057d0c0/@0x0057d230 — a header line then one line per name.
- AvailableHouses: `Handle_House__Recv_AvailableHouses` +
`DisplayListOfCoords` @0x00585d50/@0x00585c20 — the "There are N <type>
available." summary, then one indented `RadarCoordinates`-formatted
location line per landblock (skipped for apartments, which have no world
location, matching retail's `arg2 != 4` gate), then the >400-locations
truncation notice when `TotalAvailable > 0x190`.
- AllegianceInfoResponse: `Handle_Allegiance__AllegianceInfoResponseEvent`
@0x0056a1d0 — the asterisk-legend note, "Allegiance information for
&lt;name&gt;&lt;* if online&gt;:", an optional "Patron:" line, and an
optional "Vassals:" block, all reconstructed from the wire's flat
parent-tagged record list via ports of retail's own
`GetData`/`GetPatron`/`GetFirstVassal`/`GetNextVassal` walk. A player with
no allegiance record produces NO lines, matching retail's own early
return — this is not a residual bug.
17 new parser/format/routing tests
(`tests/AcDream.Core.Net.Tests/Messages/ClientCommandResponsesTests.cs`)
cover round-trips for all four shapes (including the empty-allegiance and
apartment-skip edge cases) and a `GameEventDispatcher`-level routing test
proving each reaches the `ChatLog` transcript with
`RetailLogTextType.Default`.
## #329 — [DONE 2026-08-09] The portal wait cue arms five seconds late; retail emits it per tunnel rotation segment, unconditionally
**Closed:** 2026-08-09, Campaign CH user-gate round 1, item D.
**Severity:** LOW (cosmetic, but it is a retail divergence on every single
portal, in both directions)
**Filed:** 2026-08-06, #280 retail-conformance review, finding F2.
**Register row:** AP-150, RETIRED in the same commit.
**Resolution:** `PortalTunnelPresentation.TickRotation` now writes
`"In Portal Space - Please Wait..."` directly and unconditionally in the
rotation-segment-expiry branch, on every segment boundary, matching
`gmSmartBoxUI::UseTime`'s `else` arm at 0x004D6FCD verbatim — confirmed
against `docs/research/named-retail/acclient_2013_pseudo_c.txt:219499-219525`
before coding, which shows no hold/threshold test anywhere in that branch.
acdream's own `RotationDurationMin`/`Max` (0.6-1.8 s) already matched
retail's `RandDouble` window byte-for-byte; only the arming — gating the
write on `_waitCueVisible`, which only ever went true after the invented
five-second `RuntimeWorldTransitState.RetailWaitCueDelay` hold — was wrong.
That hold/`ObserveWait`/`SetWaitCue` plumbing remains as
`LocalPlayerTeleportController`'s own telemetry
(`RuntimePortalSnapshot.WaitCueShown`) but no longer gates the on-screen
cue; a dedicated `ClearWaitCueNotice()` now hides the notice unconditionally
on Enter/Exit/Dispose so a line written by the per-segment path can never
survive past the presentation going invisible. The notice text also now
renders in the same bright yellow as an incoming Tell
(`(1, 1, 0.247, 1)`, `PortalWaitNoticeController`), per the user's live
side-by-side observation (round 1 also pinned the SpewBox to the same
colour, AP-178).
**Consequence (fixed):** every portal, regardless of duration, now shows the
notice from the first rotation segment (which expires immediately on entry
since `_rotationDuration` starts at 0), refreshed every 0.6-1.8 s for as
long as the tunnel presentation is visible — matching retail instead of
silently skipping short transits and running 3.2-4.4 s late on long ones.
## #234 — [DONE 2026-07-23] Cancelled close-range Use could strand the busy cursor
**Closed:** 2026-07-23