39c1737bda
SoundId was not a subset of retail's table, the way its comment claimed. It was an invention: 23 acdream-local names on acdream-local values, and the values were wrong in the way that matters. FootstepDefault = 0x02 is retail's Random. SwingSword = 0x10 is retail's Death2. Death = 0x60 is retail's Explode. Anyone who reached for one of those names to compare against a wire or dat value would have got a different sound. Nothing referenced any of them by name -- grep for `SoundId.` across src and tests returns nothing -- so this was a trap rather than a live defect, the same shape the enum campaign found in DamageType. All 22 invented names are deleted and retail's 205 replace them. Three oracles agree exactly, on every name and every value: retail acclient.h:4569 enum SoundType, ACE's Sound, and DatReaderWriter's Sound. The third matters most. AudioHookSink already resolves SoundTable lookups through DatReaderWriter.Enums.Sound, so that is the enum acdream actually reads at runtime; our catalog now agrees with the values already flowing through the dat path, and a conformance test pins the two so they cannot drift apart. On the "206 sounds" figure: retail's block holds 207 entries, being 205 sounds followed by NUM_SOUND_TYPES = 0xCD and FORCE_SoundType_32_BIT. The first is a count and the second a width pin. Counting the former is where 206 came from. Neither is a member here, matching how the campaign treated NUM_ATTACK_HEIGHTS and Num_HoldKeys -- a count is not a value the wire can carry. Behaviour is unchanged and could not be otherwise: the enum had no consumers. IAudioEngine's three SoundId overloads are no-op stubs and the live path takes wave ids and DatReaderWriter values. The user's separate report that sound is "not working that good" is a triggering, selection and attenuation question rather than a catalog one, and is filed as its own Bucket B row in the post-Vulkan intake. Also in this commit, by user decision: AC2D is retired as a reference. Its clone and directory are gone and it must not be re-cloned. Everything we took from it still stands and is written down -- the FSplitNESW terrain split constants, the 0xF61C movement packet layout, the finding that a client need not compute terrain Z itself -- so CLAUDE.md's reference list, its hierarchy table, and the architecture doc's protocol row now point at docs/research/2026-04-12-movement-deep-dive.md rather than erasing the history. The reference count drops from six to five. Core tests 3907 passed / 2 skipped. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
5.2 KiB
5.2 KiB
Post-Campaign-V work intake — 2026-07-29
User-provided forward list, captured during Campaign V's V11 closeout, sorted into three buckets by what already exists for each item. This is an intake ledger, not a work order: sequencing into milestones happens in the roadmap once Campaign V closes.
A. Already planned — lands on staged work; do not double-plan
| Item | Where it already lives |
|---|---|
| Selecting wielded weapons / items players wield | Slice 4 of the active world-interaction completion program (2026-07-23-world-interaction-completion.md) — "equipped-child world picking" is the program's named resume point, paused for Campaign V. |
| Vendor management | Slices 5–6 of the same program: vendor browsing, then server-authoritative transactions. |
| Settings tab in GUI | The retained-UI dev-panels follow-up filed at V11 (ImGui Settings panel was deleted with the dev stack). Re-home onto the retained retail UI via a new IPanelRenderer; panels themselves need no rewrite. Until then keybinds fall back to keybinds.json. |
B. Verification campaigns — research already exists; work is adoption/audit
| Item | Existing foundation | Shape of the work |
|---|---|---|
VERIFY all enums — DONE 2026-07-29, see docs/research/2026-07-29-enum-verification-campaign.md |
The 2026-06-04 divergence note turned out to be missing from the repo entirely (open question 1 in the successor), so the sweep was regenerated from scratch. | Seven Property* tables created (864 members); DamageType and ItemType value bugs fixed; equipment/physics/item families closed against retail. Twelve open questions remain, headed by five empty references/ repos. |
| Verify networking stack | docs/research/2026-06-04-wire-message-catalog.md: 256 opcodes catalogued, 114 parsed. |
Audit parsed-vs-stub-vs-missing against the catalog; prioritize by what live servers actually send (Coldeve session logs are now a real corpus); holtburger remains the client-side oracle. |
| Physics review — retail landing bounce et al. | The named-retail decomp workflow; carried debt #116 (slide response), TS-50/51/53 in the divergence register. | A focused fidelity pass: start with the user's observed case — long-jump landing should bounce/recoil as retail does (grep named-retail for the landing/impact path in MovementManager/SetMotion land states before writing anything). Each fix follows grep→decompile→pseudocode→port→conformance. |
| Audio fidelity review — user-sourced, 2026-07-29 | User reports sound "not working that good" generally. AudioHookSink + OpenAlAudioEngine are the current path; SoundId now carries retail's full 205-entry SoundType table (adopted 2026-07-29), so the catalog is no longer the gap. |
Scope: sound triggering, selection, and attenuation versus retail — which hooks fire, how a SoundTable entry is chosen among its probability-weighted alternatives, and the falloff/pan curve. Separate from the SoundId catalog adoption, which was naming only. Oracles: named-retail's sound path, ACE, and the DAT SoundTable. |
C. New feature bodies — milestone candidates, no existing spec
| Item | Notes |
|---|---|
| Login flow + character creation | Today: env-var auto-login, auto-enter first character. Retail flow = server select → account login UI → character list → creation screens (heritage/attributes/skills/appearance) → enter. Big body; touches wire (char-creation ops), retained UI, and the D.2b LayoutDesc import path. The Coldeve session proves multi-character accounts already half-work (it picked Barris). |
| Implement summoning | Post-M3 magic school: summon wire ops, pet entity lifecycle (spawn/follow/combat), CombatPet UI. Depends on enum + wire verification above for the summon-specific messages. |
| Fellowship and allegiance tabs | Two retained-UI panels + their wire surfaces (fellowship create/join/share; allegiance tree/pledges). Wire catalog marks the op families; parser status needs the B-bucket audit first. |
| In-game map button | Dereth map UI from DAT map art + player-position overlay; retail's MapView panel via LayoutDesc. |
| Chatbox cleanup — colors and text | memory/reference_retail_chat_colors.md holds exact retail RGBA values captured via cdb from live retail memory — the color half is research-done, implementation-pending. Text half: font/wrapping/timestamp fidelity vs retail. |
| Missing commands (/ah and more) | Inventory the retail slash-command surface (named-retail has the command table), diff against LiveCommandBus's registered set, implement by demand-order from the user's play. |
Suggested sequencing notes (for the roadmap discussion, not binding)
- Bucket A resumes first — it was the active program before Campaign V and two of the user's twelve items are literally its next slices.
- The B-bucket verifications de-risk everything in C (summoning, fellowship, char creation all sit on unverified wire surfaces); the enum+wire audits are also the cheapest to run as background subagent campaigns.
- C-bucket items should each get a brainstormed spec before code, per the roadmap rules; login/char-creation is the largest and most player-visible.