acdream/docs/plans/2026-07-29-post-vulkan-work-intake.md
Erik 6077ce4d23 docs: VTank requirements research - the plugin-automation milestone model
User-requested (2026-07-29): the plugin API must eventually support
VTank-class automation state machines written as acdream plugins. The
research decodes the full Virindi Tank surface from wiki archives and
primary source (the meta FSM''s complete condition/action vocabulary and
.met encodings, the expression language''s 67-function catalog, all ten
nav-point types with .nav wire payloads, VTClassic''s loot-rule type ids
and .utl format), derives the implied host API surface, and grounds it
against acdream: the K2 headless-bot triad is already the right
substrate, the VTank-like engine itself belongs in plugin-land, and the
milestone is a 5-step bridge/query/enchantment/transaction/nav sequence
where steps 2-4 ride on landed M3/M4 work. Filed in the post-Vulkan
intake as a C-bucket milestone candidate.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-29 16:29:49 +02:00

6.1 KiB
Raw Permalink Blame History

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 56 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 enumsDONE 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.
Plugin automation milestone (VTank-class) — user-sourced 2026-07-29 The plugin API's north star: users write automation state machines as acdream plugins with Virindi Tank-class power. Requirements research complete: docs/research/2026-07-29-vtank-plugin-automation-requirements.md — full VTank capability inventory (meta FSM condition/action vocabulary, expressions, nav-point types, VTClassic loot-rule encodings), the implied API surface, and a 5-step dependency-ordered milestone shape. Key finding: the K2 headless-bot triad is already the right substrate; step 1 is bridging it into the BCL-only Plugin.Abstractions; the VTank-like engine itself then lives as a plugin (potentially .met/.nav/.utl file-compatible). Steps 24 ride on landed M3/M4 work; only the nav/move-to layer is genuinely new machinery.

Suggested sequencing notes (for the roadmap discussion, not binding)

  1. 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.
  2. 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.
  3. 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.