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

docs(vt): owner decision — metas/ and navs/ subfolders, no nav_ prefix

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-09-07 06:20:16 +02:00
parent 8080a99eef
commit aafa66c821
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/2026-09-06-campaign-vt-vtank-oracle.md
View file

@ -17,7 +17,7 @@ catalog.
|---|---|
| Decompile set | VTank (`utank2-i.dll`), VirindiViewService, VTank Classic Looter (`VTClassic.dll`). UtilityBelt and Mag-Tools are read from their open source, not decompiled. No Decal core. |
| UI | Our own native retained UI (retail chrome, DAT fonts). VVS is NOT ported. VTank's own view XML is the layout truth (control inventory, grouping, density per tab); pixel-matching the VVS theme is not required. **Sharpened by the owner 2026-09-06: "I don't care if the UI is constructed the same way, just as long as it looks basically the same" — the acceptance bar for every tab is visual resemblance plus the same interactions from the player's seat, never VVS control internals (padding constants, hit-test rules, scrollbar mechanics).** |
| Files | Drop-in compatibility for `.usd` profiles and `.utl` loot profiles (load unchanged; settings keep VTank's names). **Metas and navs use metaf `.af` (owner, 2026-09-06 amendment):** MossTank reads and writes the human-readable metaf format for both metas and nav routes and does NOT implement binary `.met` or author `.nav`; MossTank keeps the byte-exact binary `.met`/`.nav` READERS for one-shot import only (owner confirmed 2026-09-07: "keep them for consistency and just convert them if the user imports in the plugin") — an imported binary is parsed once, saved as `.af`, and never rewritten; the binary writers are deleted and nothing in the plugin can produce a `.met` or `.nav`. Batch conversion outside the client is the metaf tool's job. Reference parser: `C:\Users\erikn\source\repos\metas\metaf_monolithic.py` (port of `metaf.cs`, GPLv3 — read, never paste), with 148 real `.af`, 25 `.met`, 130 `.nav` files beside it. Memory: `claude-memory/reference_metaf_af_format.md`. |
| Files | Drop-in compatibility for `.usd` profiles and `.utl` loot profiles (load unchanged; settings keep VTank's names). **Metas and navs use metaf `.af` (owner, 2026-09-06 amendment):** MossTank reads and writes the human-readable metaf format for both metas and nav routes and does NOT implement binary `.met` or author `.nav`; MossTank keeps the byte-exact binary `.met`/`.nav` READERS for one-shot import only (owner confirmed 2026-09-07: "keep them for consistency and just convert them if the user imports in the plugin") — an imported binary is parsed once, saved as `.af`, and never rewritten; the binary writers are deleted and nothing in the plugin can produce a `.met` or `.nav`. Batch conversion outside the client is the metaf tool's job. **Folder layout (owner, 2026-09-07): metas and routes live in two subfolders of the profile directory, `metas/` and `navs/`, with no name prefix** (the `nav_` prefix was only how the owner named files in the metas repo); per-character auto files are `--Name_Server.af` inside each folder. Reference parser: `C:\Users\erikn\source\repos\metas\metaf_monolithic.py` (port of `metaf.cs`, GPLv3 — read, never paste), with 148 real `.af`, 25 `.met`, 130 `.nav` files beside it. Memory: `claude-memory/reference_metaf_af_format.md`. |
| Knowledge base | Full catalog with decompile citations BEFORE implementation. |
| Platform | Linux is a first-class target: no `System.Drawing`, no GDI+/Windows fonts, no Windows-only paths or registry, no COM. The plugin stays BCL-only per `AcDream.Plugin.Abstractions`. |
| Interop | **NONE (owner, 2026-09-06): "We should not do any interops. All plugins will have to get rewritten for acdream." VTank relies on Decal hooking/injecting the client; acdream controls the client through its own API.** No VTank export-API surface, no Decal-shaped relay, no compatibility layer for existing Decal plugins (MosswartMassacre, UtilityBelt, Mag-Tools are rewritten as acdream plugins when wanted). KB doc 09's interop sections stay as historical context only. VTank has no real API — what KB 09 calls its "export API" is a reflection relay behind a signed handshake that every real consumer bypassed. If acdream plugins ever need to talk to each other, acdream creates its own plugin API later, on its own terms ("we can of course create one later on"). |