From 1b81836747e21c93b72a13bb005d16d2dfeaf6bb Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 6 Sep 2026 19:59:25 +0200 Subject: [PATCH] docs(vt): fold the citation-pass corrections into KB 03 (DebuffScheduler.cs path, DebuffScope, six-member l enum, offhand enum, pet comparison owed) Co-Authored-By: Claude Fable 5.1 --- docs/research/vtank-kb/03-combat.md | 54 ++++++++++++++--------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/research/vtank-kb/03-combat.md b/docs/research/vtank-kb/03-combat.md index c7b095f4..a01ac2fb 100644 --- a/docs/research/vtank-kb/03-combat.md +++ b/docs/research/vtank-kb/03-combat.md @@ -163,9 +163,10 @@ candidates by max priority, then gives `TargetLock` (line 1740) and the previously-attacked target (line 1757, explicitly commented as modelling `ga.e`) **unconditional first refusal** ahead of any ranking — i.e. steps 4 and 6 above are promoted ahead of steps 2–3 -instead of following them. Steps 2 (`DebuffEachFirst`) and 3 -(debuff-urgency score) have no equivalent in `CombatController.cs` at -all. See §8 gap #1. +instead of following them. `DebuffEachFirst` IS implemented as a debuff *scope* filter +(`CombatController.DebuffScope()`, `CombatController.cs:1618-1658`) but is +never consulted during target selection; only the debuff-urgency score +(`f7.g`) has no equivalent anywhere (citation pass 2026-09-06). See §8 gap #1. **The three `TargetSelectMethod` values**, read once per scan as `f3.f("TargetSelectMethod")` (`dz.cs:722`), decide only the final tie @@ -182,7 +183,7 @@ above ties: Despite its name, `TargetSelectAngleRange` is compared directly against the **distance** field `f7.e`, never against `f7.f` (the angle) — this is a real quirk of the retail setting, not a -misreading; MossTank's `CombatController.cs:1774` reproduces this +misreading; MossTank's `CombatController.cs:1766-1767` reproduces this correctly (`candidate.Target.Distance <= _settings.TargetSelectAngleRange`). ## 3. Monster rules @@ -215,7 +216,7 @@ names in `refs/vtank/decompiled/da.cs:280-322`: | 16 | Corrosion | `r` | bool | Cast Corrosion I | | 17 | Streak | `s` | bool | Prefer streak-shape attack spells | | 18 | SecondaryVuln ("Ex. Vuln") | `c` | `eDamageElement` | Extra Vuln element beyond the natural one | -| 19 | SecondaryEquip ("Offhand") | `e` | `eSecondaryEquipTypeOrObjectID` | Offhand item selection mode/id (exact enum values not recovered, §9) | +| 19 | SecondaryEquip ("Offhand") | `e` | `eSecondaryEquipTypeOrObjectID` | Offhand item selection mode/id; members `Auto, AutoShield, AutoWeapon, None, LISTEDTYPES_END` (`uTank2/eSecondaryEquipTypeOrObjectID.cs:3-10`) | | 20 | PetDamageType | `d` | `eDamageElement` (default `PAuto`) | Preferred pet damage element for this monster | **Matching semantics.** `d1.a(fu)` walks the table top-to-bottom, @@ -282,10 +283,10 @@ inventory via `bv.b(fi, element, 1, ePrismaticDamageBehavior.Any)` element to be used, logging a warning and refusing otherwise (`ga.cs:1211-1241`); a mirrored `b(fi,eDamageElement)` exists immediately after (only partially read; not confirmed identical). -Launcher/projectile shape is carried as a 4-value enum `l` -(`l.a/b/c/d`) attached to debuff items and spells (`dz.cs:250,264,296`; -`f7.cs:122-146`) but its four case names could not be recovered from -the available source (§9). +Launcher/projectile shape is carried as a six-value enum `l` (`l.a`–`l.f`, +declared at `l.cs:1-8`) attached to debuff items and spells (`dz.cs:250,264,296`; +`f7.cs:122-146`); the member names are obfuscated, so the semantic mapping +is unrecovered (§9). **Offhand / re-wield.** The Monster Rule's `SecondaryEquip` column (`eSecondaryEquipTypeOrObjectID`) selects the offhand item; the target @@ -429,7 +430,7 @@ change) before casting, then restores afterward (`dz.cs:486-508`). **MossTank disagreement (highest-impact finding in this document):** -`DebuffSpellCatalog.cs`'s `OrderedFlags` (lines 21-34) declares the +`DebuffScheduler.cs` (class `DebuffSpellCatalog`)'s `OrderedFlags` (lines 21-34) declares the order `Fester, Broadside, GravityWell, Imperil, Yield, Vulnerability, WeakeningCurse, FesteringCurse, Corruption, DestructiveCurse, Corrosion` — almost the **reverse** of retail's real order above @@ -439,7 +440,7 @@ kind per tick, first due wins" model at all: it gathers **every** due debuff into a candidate set and sorts it by `DebuffSelectionMethod` (Skill/SpellLevel) then spell Tier/Difficulty, with `ActionOrder` (the wrong-order array above) only as the final tiebreak -(`DebuffSpellCatalog.cs:93-118`). Retail's `DebuffSelectionMethod` +(`DebuffScheduler.cs:93-118`). Retail's `DebuffSelectionMethod` comparer (`dz.b`, §6 above) is a *per-kind item/spell choice* mechanism in the real client, never a *cross-kind debuff-choice* ranking — MossTank has repurposed it for a role retail never gives it. @@ -484,17 +485,18 @@ semantics were not traced further): The `h1` rule's `Running(true)` handler simply calls `f9.p(petId)` — use/summon that item (`h1.cs:74-81`). No MossTank pet-selection code -was located in this pass to compare against (`CombatController.cs` -was not searched exhaustively for a pet feature — flagged in §9). +exists — `PetAutomation.cs` (`PetAutomationChoice`: device/target/element pick) +and `PetDeviceCatalog.cs` — but was not compared step-by-step against +`ga.j()`; that comparison is owed (§9). ## 8. MossTank gap ranking (highest player impact first) 1. **Debuff-kind ordering and selection model is structurally different, not just re-ordered.** `DebuffSpellCatalog.OrderedFlags` - (`DebuffSpellCatalog.cs:21-34`) is close to the reverse of retail's + (`DebuffScheduler.cs:21-34`) is close to the reverse of retail's real fixed 12-step order (`hi.cs:123-206`), and MossTank scores across debuff *kinds* using a comparer retail only ever uses to - choose *within* one kind (`DebuffSpellCatalog.cs:93-118` vs. + choose *within* one kind (`DebuffScheduler.cs:93-118` vs. `dz.b`, `dz.cs:11-91`). Effect: a MossTank character debuffs targets in a different sequence than retail VTank ever would, which changes which debuff is up when an attack lands and can @@ -506,8 +508,9 @@ was not searched exhaustively for a pet feature — flagged in §9). *low*-priority tiebreaks near the bottom of the chain; MossTank (`CombatController.cs:1707-1798`) gives `TargetLock` and the sticky-last-target unconditional first refusal within the top - priority tier and has no debuff-need or debuff-urgency signal at - all. Effect: MossTank can get "stuck" defending a locked/sticky + priority tier; `DebuffEachFirst` exists only as a scope filter + (`DebuffScope()`, :1618-1658) and is never consulted here, and there is + no debuff-urgency signal at all. Effect: MossTank can get "stuck" defending a locked/sticky target far more rigidly than retail, and never re-prioritizes a same-priority target that urgently needs a re-debuff. 3. **Arc vs. Bolt is chosen by `UseArcs`/range before spell quality, @@ -552,11 +555,8 @@ detail and found to be faithful, well-cited ports with no material gap. schema needed to tell them apart was not available in this pass. The *names* and *semantic meaning* of every setting cited above are independently confirmed via call sites, not via this file. -- `eSecondaryEquipTypeOrObjectID`'s enum members (offhand selection - modes) — only its column position and type name were recovered. -- The `l` enum's four case names (`l.a/b/c/d`, launcher/projectile - shape attached to debuff items and ammo checks) — used but never - declared in the files read. +- The `l` enum (`l.cs:1-8`, six members `a`–`f`) is declared but obfuscated; + which member is which launcher/projectile shape is unrecovered. - `CombatState`'s enum declaration and full name — only inferred from the numeric casts `(CombatState)2/4/8` at every call site (`ga.cs:1596-1615` and callers); no explicit `enum CombatState { ... }` @@ -569,11 +569,11 @@ detail and found to be faithful, well-cited ports with no material gap. - `bm.a()` and the `-32555` cooldown check gating the `h1` SummonPet rule — not traced beyond their call site. - The four cast-result regex families referenced as `l.g.a/b/c/d` in - `gj.cs` — their defining file was not located in this pass. -- Whether MossTank has any pet-selection logic at all; - `CombatController.cs` (2059 lines) was searched for combat-loop, - target-selection, and attack-execution code but not exhaustively for - a pet feature. + `gj.cs` are the `MyList a/b/c/d` fields of `d3.cs:5-13` (the only + class holding four regex lists); the `l` holder itself was not located, + so the type link is strong but not proven. +- The step-by-step comparison of MossTank`s `PetAutomation.cs` against + retail`s `ga.j()` (§7) is owed. - `VtankAmmunitionDatabase.cs` and the full `ga.a`/`ga.b` ammo-availability pair (`ga.cs` beyond line ~1245) were not compared against retail in detail.