From dc91245ba86b8704087a52c03a0e990fafe748e2 Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 6 Sep 2026 20:25:19 +0200 Subject: [PATCH] =?UTF-8?q?docs(vt):=20KB=2005=20second=20citation=20pass?= =?UTF-8?q?=20=E2=80=94=2031=20requirement=20types,=20f0.c=20categories=20?= =?UTF-8?q?and=20dz.o.h=20readers=20resolved?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5.1 --- docs/research/vtank-kb/05-looting-and-utl.md | 32 +++++++++++--------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/docs/research/vtank-kb/05-looting-and-utl.md b/docs/research/vtank-kb/05-looting-and-utl.md index ae0cdbf9..8c28a2db 100644 --- a/docs/research/vtank-kb/05-looting-and-utl.md +++ b/docs/research/vtank-kb/05-looting-and-utl.md @@ -720,19 +720,19 @@ independently re-implements §1's exact grammar: header/version detection (`VtankLootProfileSerializer.cs:92-107`), the length-prefixed v1 payload format and the fixed-line-count v0 legacy table (`LegacyPayloadLineCount`, `VtankLootProfileSerializer.cs:376-388` — -independently verified in this pass against every one of VTClassic's 30 +independently verified in this pass against every one of VTClassic's 31 `Read()` methods, §1.3/§1.2; every bucket matches exactly), the `SalvageCombine` extra block including its optional trailing value-mode section, and preserves any unrecognized block/requirement type verbatim (`VtankLootExtraBlock`/`cUnsupportedRequirement`-equivalent `VtankLootRequirement.Payload`, `VtankLootProfileSerializer.cs:11-15`). -Round-trip fidelity for every one of the 30 known requirement types plus +Round-trip fidelity for every one of the 31 known requirement types plus unknown-block preservation is exercised by `tests/AcDream.Plugins.MossTank.Tests/VtankLootProfileSerializerTests.cs` (all four tests read). `VtankLootRequirementEvaluator.IsMatch` (`src/AcDream.Plugins.MossTank/VtankLootRequirementEvaluator.cs:110-190`) -implements the **entire** 30-entry requirement vocabulary (verified +implements the **entire** 31-entry requirement vocabulary (verified switch-arm-by-switch-arm against §1.3's table, including the deliberately dead `DamagePercentGE` always-`false` and the `DisabledRule` never-matches-when-enabled semantics) plus every `ComputedItemInfo` formula @@ -792,23 +792,27 @@ constants). (`a10.j = A_0.Value("shareLoot") != 0;`, alongside `name`/`level`/ `maxHealth`, `id.cs:212-221`; field declared at `id.cs:30`). MossTank's `member.ShareLoot` mapping (`Looting.cs:1224`) is confirmed correct. -- **`f0.c` enum members `a` and `d`** (`f0.cs:11-17`) — only `b` - (item-needs-ID) and `c` (corpse-needs-ID) were observed at call sites in - this pass; the other two members' purposes are unknown. +- **`f0.c` enum members — RESOLVED** (citation pass 2026-09-06): `f0.c` is the + ID-request category. `a` = the "Set default profile" inventory-scan sweep + (`da.cs:577,581-583,594-599`), `b` = corpse-item ID (`hv.cs:260,293,306`), + `c` = corpse ID (`fo.cs:177`), `d` = door ID for the `OpenDoors` rule, + range-gated by `DoorIDRange` (`b7.cs:99-104`). - **The full write/reset surface of `dz.o.s`/`dz.o.t`/`dz.o.c` and similar single-letter bookkeeping fields** on the large (~1900+ line) `ga`/`s.o` class, which covers combat, nav, and loot state together — only the specific call sites this doc cites were confirmed; there may be additional gating logic on these flags elsewhere in `ga.cs` not surfaced here. -- **Whether anything actually consumes `dz.o.h`** (the table `Keep`/ - `Sell`/`KeepUpTo`/`User1`-`5` decisions land in uniformly after pickup, - §3.7) as a real vendor-sell queue, versus it being purely a bookkeeping/ - report table — no rule class reading it back out was found among the - ~35 rule classes `cLogic.cs` registers (only the loot-relevant ones were - opened in this pass). This makes a direct sell-path comparison against - MossTank's explicit `_sellPendingItem`/`ContinueSell` staging - (`Looting.cs`) inconclusive rather than a confirmed match or gap. +- **`dz.o.h` consumers — RESOLVED** (citation pass 2026-09-06): no internal + rule reads it. Its only readers are two external-plugin API surfaces gated + on `eExternalsPermissionLevel.FullUnderlying` — `GetByAction(eLootAction)` + (`uTank2/PluginCore.cs:274-278` → `PluginCore.a(eLootAction)` at + `:2752-2776`, which also prunes ids no longer in inventory) and + `GetCustomLootActionItems(eLootAction)` (`uTank2/PluginCore.cs:466-478`). + Writes: `hv.cs:184` (add), `hv.cs:73-75` (remove on release). It is a + bookkeeping + third-party query table, NOT a vendor-sell queue, so + MossTank's explicit `_sellPendingItem`/`ContinueSell` staging is a + confirmed MossTank-side addition with no VTank counterpart. - **The exact semantic of network message type `63408`, event `34`** — treated here as "corpse closed/emptied" by contextual inference (it resets the same state as event 82 / a failed event-406), not