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 <noreply@anthropic.com>
This commit is contained in:
Erik
parent
59f247664a
commit
1b81836747
1 changed files with 27 additions and 27 deletions
|
|
@ -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<Regex> 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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue