Item D (slice-1 fix round). CreateNew built ONLY a bespoke 4-column
Settings table (empty Description, hardcoded SettingType=1/Bool for
every row regardless of the setting's real declared type) and had no
representation of the other nine tables VTank ships at all (MyMonsters,
GemFoodItems, ExtraBuffSpells, AntiExtraBuffSpells, ItemUseSpecifiers,
SettingsCategories, SettingsEnumInfo, AssistItems, BuffedItems).
Separately, VitalSettings.RechargeHandlerRows defaulted to an empty
list, so a freshly-constructed VitalSettings (not loaded from a real
.usd) always fell back to VitalRechargePlanner's own hand-ported
handler-order switch instead of VTank's real 26-row table.
- VtankDefaultSettings.usd: the real uTank2.Resources.defaultsettings.usd
(already committed as a test fixture) copied into the plugin project as
an EmbeddedResource, following the existing VtankCraftRecipes.tsv/
VtankAmmunitionOptions.tsv pattern.
- New VtankDefaultSettingsDatabase: loads the embedded text once (Lazy),
exposes Parse() (a fresh, independently mutable VtankDatabase per call)
and DefaultRechargeHandlerRows (the real RechargeHandlerSet table,
parsed once via VtankSettingsProfileSerializer.ParseRechargeHandlerSet).
- VtankSettingsProfileSerializer.CreateNew now parses the embedded
document and calls the existing Save(document, source) against it —
every table, every row's real Description/SettingType survive
untouched; only the Settings table's Value cells get overwritten from
the live source, exactly as re-saving an existing profile would.
DefaultCell (the hand-typed per-catalog-kind cell builder CreateNew
used before) is deleted as dead code.
- VitalSettings.RechargeHandlerRows now defaults to
VtankDefaultSettingsDatabase.DefaultRechargeHandlerRows instead of [].
VitalRechargePlanner.Handlers' hardcoded switch-based defaults are kept
(not deleted) as a documented, genuinely defensive fallback for the
case where a caller explicitly clears the row list or an
(vital, stance, percent) combination the real table happens not to
cover — no longer the primary source of truth it used to be, and the
doc comment says so.
- RenderRechargeHandlerSet (a write-back helper for the RechargeHandlerSet
table, never called anywhere) is deleted rather than wired into
Capture(): docs/research/vtank-kb/01-settings-and-profiles.md section 2
row 137 confirms real VTank has NO save path for this table at all
(tCustom has no case in the Advanced Options editor or "/vt opt set";
it's owned by a dedicated cRechargeManager object). Wiring a write-back
would be a MossTank invention, not a retail port, so Capture() keeps
deliberately leaving this row untouched.
New CreateNewHasTheSameTableSetAsTheDefaultFixture test: asserts
CreateNew's table set matches defaultsettings.usd's own table set
exactly, and that Settings rows carry real (non-empty) Description and a
real (non-Bool-for-everything) SettingType. Verified failing against the
prior 4-column-only implementation (temporarily restored, ran, reverted):
"Expected: [AntiExtraBuffSpells, AssistItems, ...] / Actual: [Settings]".
Full MossTank suite: 570/570 passing (569 -> 570, one new test).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
e1d0c703f9