acdream/docs/research/2026-08-24-campaign-ct-dat-ground-truth.md

Campaign CT slice CT1 — DAT ground truth for the character panel (0x2100002E)

Status: RESEARCH COMPLETE 2026-08-24. No production code changed in this slice. Findings feed CT2–CT6 (docs/plans/2026-08-24-character-panel-parity-campaign.md).

Method: temporary Assert.Fail probe tests (deleted before commit; the pattern is preserved in tests/AcDream.App.Tests/UI/Layout/ScrollbarSkinLiveDatTests.cs and its sibling CharacterPanelLiveDatTests.cs written by this slice) against the installed DAT set (%USERPROFILE%\Documents\Asheron's Call), driven through LayoutImporter.ImportInfos / ElementInfo (src/AcDream.App/UI/Layout/ElementReader.cs, src/AcDream.App/UI/Layout/LayoutImporter.cs).

1. Header elements (gmStatManagementUI content, sub-layout under 0x2100002E)

All header elements are DUPLICATED — the imported 0x2100002E tree carries two structurally identical copies of the whole header block, one reached through the Attributes page chain (0x10000227 > 0x1000022B > 0x10000226 > 0x10000230) and one through the Skills page chain (... > 0x1000022C > ...). The two copies are geometrically and stylistically IDENTICAL — this is the "duplicated stat-management branches" quirk documented on PrepareSkillScrollbar in CharacterStatController.cs, confirmed here to be a harmless duplicate (not a divergent one) for every header id checked.

Element	Id	X,Y	W×H	HJustify	VJustify	FontDid	FontColor	Outline	Margins
Name	0x10000231	0,0	230×20	Center	Center	0x40000001	white (1,1,1,1)	false	0
Heritage line	0x10000232	0,20	230×15	Center	Center	0x40000002	white (1,1,1,1)	false	L5 R5
PK line	0x10000233	0,35	230×15	Center	Center	0x40000002	white (1,1,1,1)	false	0
Level	0x1000023B	235,35	65×50	Center	Center	0x40000010	(1, 0.9490196, 0.49803922, 1)	true	0
Total XP	0x10000235	130,70	100×18	Right	Center	0x40000000	white	false	0
XP meter	0x10000236 (Type 7)	0,88	230×17	—	—	—	—	—	—
XP-next label (child of meter)	0x10000237	0,0	130×17	Left	Center	0x40000000	white	false	0
XP-to-level value (child of meter)	0x10000238	130,0	100×17	Right	Center	0x40000000	white	false	0
Luminance label	0x100005C5	0,52	110×18	Left	Center	0x40000000	white	false	0
Luminance value	0x100005C6	110,52	120×18	Right	Center	0x40000000	white	false	0

Header block container (0x10000230) is 300×110 inside the shared prototype layout 0x21000045 — the character content column itself is only 230px wide (name/heritage/PK/XP all live in that 230px column), with a 5px vertical divider (0x10000239, X=230, W=5) separating it from the level box (X=235..300, matching the plan's "Level area (65,50)" spec).

Confirmations vs. the owner report / plan:

• Item 4 (PK line pure white): CONFIRMED — 0x10000233 FontColor is exactly white, not the "color off" state the owner reported. The bug is purely in CharacterStatController.Bind's runtime color choice (Body = parchment (0.92,0.90,0.82,1)), not a DAT-reading gap. CT4 must switch the PK-line color to Vector4.One.
• Item 5 (level color): CONFIRMED DIVERGENT. DAT-authored level color is (1, 0.9490196, 0.49803922, 1) (a pale gold, ~RGB 255/242/127) with Outline=true. CharacterStatController.Gold is currently (1, 0.82, 0.36, 1) (a deeper orange-gold) with no outline applied. CT4 should read the DAT FontColor + Outline directly instead of hand-picking a runtime color, matching how LevelId's dat FontDid is already honored.

2. Stat list (0x1000023D) + row templates

0x1000023D (Type 5 ListBox) is duplicated the same harmless way as the header (once per Attributes/Skills page chain, identical geometry both times): X=0 Y=112 W=300 H=160, ScrollbarElementId=0x1000023E (scrollbar at X=281 W=16 H=160, i.e. always reserved, whether or not it's shown). Its authored TemplateList (dat property 0x64) names FIVE same-layout-family entries, all in LayoutDesc 0x21000045:

0x10000248, 0x10000249, 0x1000024A, 0x1000024B, 0x1000024C

These are NOT reachable by walking ImportInfos(dats, 0x21000045u)'s built tree — LayoutImporter.ImportInfos intentionally filters out same-layout template-list targets (the #375 fix documented in LayoutImporter.ImportInfos's own comment: "retail never instantiates a template-list element as a live widget… building them here parked two live prototype rows… over and outside the framed panel"). The correct read path — and the one CT5 must use — is the targeted single-root overload: LayoutImporter.ImportInfos(dats, 0x21000045u, templateElementId), the same seam UiTemplateListBox's TemplateResolver already uses for other authored row templates.

Dumping all five with that overload:

0x10000248 — the ONE shared data-row template (icon + name + value)

Id=0x10000248 Type=3 (container)  X=0 Y=0 W=282 H=20
  StateMedia[Normal]    File=0x06004CC2 DrawMode=1
  StateMedia[Highlight] File=0x06000F93 DrawMode=1
  Id=0x10000129 Type=3 (icon slot)   X=0   Y=0 W=20 H=20   (no own media — set per-row at runtime)
  Id=0x1000012A Type=0xC (name text) X=25  Y=0 W=150 H=20  HJustify=Left  FontDid=0x40000001 white
  Id=0x1000012B Type=0xC (value text)X=175 Y=0 W=100 H=20  HJustify=Right FontDid=0x40000001 white

This is the single row template used for BOTH the attribute rows AND the skill rows (retail's gmAttributeUI/gmSkillUI share it). Ground truth for item 1 (icon alignment) and item 2 (value-column gutter):

• Icon: 20×20, flush at the row's left edge (X=0), full row height. Current code (CharacterStatController.IconSize = 16f, RowPadX = 4f) draws a 16×16 icon at X=4 — smaller AND offset from retail's flush-left 20×20. This is the "icons misaligned" bug (item 1).
• Name column: X=25, W=150 (fixed pixel widths, not a width fraction). Current code computes nameX = RowPadX + IconSize + IconGap (4+16+6=26, off by one from retail's 25) and nameW = width * 0.60 (a content-relative fraction retail does not use at all — retail's name column is a FIXED 150px regardless of the 282px row width).
• Value column: X=175, W=100, right-justified. Value's right edge sits at X=275. The row template itself is 282px wide, so there is a 7px gap between the value's right edge and the row's own right edge — this is the "authored margin between the value column and the border" the owner reported (item 2), confirmed as exactly 7px at the row-template level.
• The row (282px) is already inset from the ListBox's full width (300px) by 18px to clear the always-reserved scrollbar gutter (scrollbar at X=281, W=16) — so the TOTAL space between the value text's right edge and the ListBox's outer right edge is 300 - 275 = 25px, of which 18px is the permanent scrollbar gutter and 7px is the row template's own inset. Both numbers matter for CT5: the row width (282, confirmed correct — matches the existing SkillContentWidth = 282f constant already in the code) and the internal 175/100 value-column placement (not currently matched).
• Row background: Normal state file 0x06004CC2 (the same generic panel-chrome fill used elsewhere client-wide), Highlight state file 0x06000F93. CharacterStatController.RowHighlightSprite is currently 0x06001397u — this is a divergent constant; CT5 should either confirm 0x06001397 is deliberately used for a DIFFERENT highlight surface (e.g. the vitals/skill list uses a shared sprite elsewhere) or correct it to 0x06000F93 for the attribute/skill row highlight specifically. Flagged, not fixed, in this slice.

0x10000249 / 0x1000024A / 0x1000024B / 0x1000024C — skill SECTION HEADER captions

Id=0x10000249 Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F90
Id=0x1000024A Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F86
Id=0x1000024B Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F98
Id=0x1000024C Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F89

These are single full-width caption bars (no icon/name/value split), 280px wide (2px narrower than the data row — no scrollbar-gutter inset needed since they never scroll independently). Their sprites are an EXACT match for the existing constants already in CharacterStatController.cs:

Constant	Value	Probe file	Match
SkillHeaderSpecializedSprite	0x06000F90	0x10000249	YES
SkillHeaderTrainedSprite	0x06000F86	0x1000024A	YES
SkillHeaderUntrainedSprite	0x06000F98	0x1000024B	YES
SkillHeaderUnusableSprite	0x06000F89	0x1000024C	YES

These four are correctly ported already; no CT5 work needed here.

3. Titles page (0x10000539 subtree, imported as part of 0x2100002E)

0x10000539 (Type 0x10000046, the Titles page container) is NOT duplicated like the Attributes/Skills content — it appears once, as a direct child of the tab-control root 0x10000227 (siblings with the Attributes/Skills tab buttons and the Titles tab button 0x10000538). Geometry: X=0 Y=25 W=300 H=575 (fills the window below the 25px tab bar).

Element	Id	X,Y	W×H	Notes
(unlabeled caption)	0x1000052E	8,20	270×18	Left, margin L6, FontDid 0x40000001 white — likely "Current Title:" caption
Current display title text	0x1000052F	8,40	270×18	Center, margins L5 R5, FontDid 0x40000001 white
divider	0x10000530	0,60	300×9	sprite 0x06001420
(unlabeled caption)	0x10000531	8,70	270×18	Left, margin L6 — likely "Titles Earned:" caption
Title ListBox	0x10000532	8,90	270×455	ScrollbarElementId=0x10000533; TemplateList: LayoutDid=0x2100005E, ElementId=0x10000536
Title scrollbar	0x10000533	280,90	16×455	shared RetailScrollbarChrome media (thumb/up/down ids identical to the base skin pinned by ScrollbarSkinLiveDatTests)
divider	0x10000534	0,550	300×9	sprite 0x06001420
"Set as Display Title" button	0x10000535	53,560	200×32	MinWidth=65, margins L7 R7, FontDid 0x40000001 white, DefaultState=Ghosted (matches the plan's UpdateButtons ghost-when-current contract); three-slice chrome children 0x100002CE/CF/D0 with Normal/Normal_rollover/Normal_pressed/Ghosted states each

Title row template — LayoutDesc 0x2100005E, element 0x10000536

Id=0x10000536 Type=3 (container)  X=0 Y=0 W=270 H=24
  StateMedia[DirectState, key ""]  File=0x06004CCA DrawMode=3
  StateMedia[Highlight]            File=0x06001AAF DrawMode=1
  Id=0x10000537 Type=0xC (text)  X=0 Y=0 W=270 H=24  HJustify=Left  Margins L6 R6  FontDid=0x40000001 white

A single-line text row, no icon column (titles have no per-row icon in retail) — 24px tall vs. the stat rows' 20px. Row width 270 matches the ListBox content width exactly (0x10000532 is 270 wide, with its scrollbar 0x10000533 living OUTSIDE that width at X=280 — unlike the stat list, the title row template does NOT need its own internal scrollbar-gutter inset because the ListBox width itself already excludes the scrollbar column).

Same targeted-root import gotcha as the stat templates applies here: LayoutImporter.ImportInfos(dats, 0x2100005Eu) (the whole-layout overload) returns the SAME element (0x1000052D, root of a throwaway container) but does NOT surface 0x10000536 as a reachable child — use LayoutImporter.ImportInfos(dats, 0x2100005Eu, 0x10000536u) instead.

4. Window min/max constraints

Character window (0x2100002E) root

LayoutImporter.ImportInfos(dats, 0x2100002Eu) returns element 0x10000227 (Type 0x8, TabControl) as the tree root — this IS the top-level element retail's RetailUiRuntime.MountCharacter() mounts via RetailWindowFrame.Mount(..., layout.Root, ...). It authors NO MinWidth/MinHeight/MaxWidth/MaxHeight properties (dat properties 0x3F/0x3E/0x3D/0x3C all absent — probe shows every one of MinW/MinH/MaxW/MaxH blank for 0x10000227 and every element under it, including the footer, header, and Titles page).

Chat window (0x2100006F) root, for comparison

LayoutImporter.ImportInfos(dats, 0x2100006Fu) returns element 0x10000600 (Type 0x10000050, a self-contained "window" element that directly includes its own dragbar (Type 2), border frame (Type 3), and FOUR resize-grip corners (Type 9) as children — none of which the character layout's root has). It DOES author constraints: MinWidth=300, MinHeight=100, MaxWidth=2000, MaxHeight=2000.

Correction to the plan

The plan's "Already in-tree" section states: "The character window registers with DatConstraintSource — authored min/max plumbing exists in RetailWindowFrame; Y-resize for this window and the list-scrollbar contract do not." Read literally this implies the character window's RetailWindowFrame.Mount call already sets DatConstraintSource. It does not. RetailUiRuntime.MountCharacter() (src/AcDream.App/UI/RetailUiRuntime.cs, ~line 4043) constructs RetailWindowFrame.Options with ResizeY = true, ResizableEdges = ResizeEdges.Bottom, ConstrainResizeToParent = true — but no DatConstraintSource, MinHeight, or MaxHeight field at all, unlike e.g. MountSideVitals() (~line 1474) which explicitly sets DatConstraintSource = info from its own imported root. This is consistent with what CT1 also found in the DAT itself: 0x2100002E's root authors no size constraints to plumb through in the first place — chat's window-frame elements are its own self-contained LayoutDesc, while 0x2100002E is CONTENT ONLY (tab bar + pages), with retail's window chrome supplied by a separate mechanism.

Implication for CT6: the character window's authored minimum height (if one exists in retail) is not going to fall out of 0x2100002E's own MinHeight/MaxHeight properties — those are simply absent. CT6 needs to find where retail's gmStatManagementUI/its owning window-frame class enforces a minimum window size (likely a hardcoded ResizeTo/SetMinSize call in that class's C++, or a shared base window-frame behavior applied uniformly — see the plan's own CT6 wording, "verified as the STANDARD path for every registered window"). This is NOT a simple "read the DAT property" fix like MountSideVitals was; treat the "Already in-tree" plan bullet as inaccurate and start CT6 from the decomp for the window-frame class instead of assuming the wiring is already 90% done.

5. The title-string table (DAT ground truth for CharacterTitleTable::GetCharacterTitleFromID)

Decomp chain (named-retail, docs/research/named-retail/acclient_2013_pseudo_c.txt)

CharacterTitleTable::GetCharacterTitleFromID @0x005c6ed0 does not read a StringTable directly. It goes through TWO independent enum-mapper indirections:

1. EnumMapper::GetString(0x10000006, titleId, &rawName) (the static 3-arg overload @0x0041ac40) — internally calls DBObj::GetDIDByEnum(&did, 0x10000006, /*category*/1) to resolve the title EnumMapper object's DID, then dispatches on MasterDBMap::DivineType (0x24 = EnumMapper) to call EnumMapper::GetString(titleId, &rawName) on it, giving a raw canonical string name (NOT yet localized/hashed).
2. compute_str_hash(rawName) (ELF-style hash, already ported byte-exact as DatStringResolver.ComputeHash — see its own citation of compute_str_hash @ 0x00413110).
3. StringInfo::SetStringIDandTableEnum(&info, hash, 0x10000007) (@0x0042c760) — internally calls DBObj::GetDIDByEnum(&did, 0x10000007, /*category*/4) to resolve the title StringTable's DID.
4. StringInfo::GetString(&info) (@0x0042e760 → InqString → StringTableMetaLanguage::UnescapeString) resolves the final localized text — the same StringTable.Strings[hash] lookup DatStringResolver.Resolve(tableId, stringId) already performs.

DBObj::GetDIDByEnum(enumValue, category) (@0x004153a0 → DBCache::GetDIDFromEnum @0x00413940) is itself a two-level indirection through a master map object (this->m_MasterMapID): look up category in the master map to get an intermediate category-map DID, then look up enumValue in THAT map to get the final DID. This is the exact same mechanism already ported (empirically, not by name) as RetailKeyNames' 0x2300000A/0x2300000B/0x23000007 constants (src/AcDream.App/UI/Layout/RetailKeyNames.cs, citing "DBCache::GetDIDFromEnumStatic category 4") — this slice confirms those three constants ARE exactly the category-4 (STRINGTABLE) map's enum 4/5/3 entries (see table below), so the existing RetailKeyNames port is independently cross-validated by this investigation.

Live-DAT resolution (verified end-to-end this session)

DatReaderWriter.DBObjs.EnumIDMap (ACE's historical name: DidMapper, file-type byte 0x25) is the object type both master and category maps use; DatReaderWriter.DBObjs.EnumMapper (file-type byte 0x22 on the installed dat) is the flat id→string table type.

Master map, DID 0x25000000 (ClientEnumToID/ClientEnumToName, 22 entries) — the categories relevant here:

category enum	name	category-map DID
1	EMAPPER	0x25000001
4	STRINGTABLE	0x25000004

Category 1 (EMAPPER) map, DID 0x25000001 — relevant entry:

enum	name	DID
0x10000006	CharacterTitle	0x22000041

Category 4 (STRINGTABLE) map, DID 0x25000004 — full dump (12 entries), confirming the RetailKeyNames constants along the way:

enum	name	DID	cross-check
0x00000003	KeyMap	0x23000007	= RetailKeyNames.DelimiterTableId ✓
0x00000004	KeyNameOverride	0x2300000A	= RetailKeyNames.KeyNameTableId ✓
0x00000005	MetakeyNameOverride	0x2300000B	= RetailKeyNames.MetaKeyNameTableId ✓
0x10000007	CharacterTitle	0x2300000E	(this slice's target)
0x10000001	UI	0x23000001
0x10000002	UI_Pregame	0x23000002
0x10000003	Preference	0x23000003
0x10000004	UI_Options	0x23000004
0x10000006	Options	0x2300000D
0x00000002	Calendar	0x23000006
0x00000006	CommandSetup	0x2300000C
0x00000007	ActionDescription	0x23000005
0x00000008	ServerEngine	0x23000010

So: the title EnumMapper is DID 0x22000041; the title StringTable is DID 0x2300000E.

End-to-end verification (ACE's CharacterTitle enum, WarMage = 13)

EnumMapper(0x22000041).IdToStringMap has 873 entries, including:
  titleId 0  -> ID_CharacterTitle_Invalid
  titleId 1  -> ID_CharacterTitle_Adventurer
  titleId 5  -> ID_CharacterTitle_Life_Mage
  titleId 13 -> ID_CharacterTitle_War_Mage
  titleId 14 -> ID_CharacterTitle_Wayfarer

ComputeHash("ID_CharacterTitle_War_Mage") = 0x0543AF05
DatStringResolver(dats).Resolve(0x2300000E, 0x0543AF05) = "War Mage"

Byte-exact confirmation the chain is understood correctly end to end — titleId 13 round-trips through the EnumMapper canonical-name lookup, the retail hash function, and the StringTable localization lookup to produce exactly "War Mage".

What CT2 needs to port

1. Two GetDIDByEnum-shaped lookups (master map 0x25000000 → category map → target DID) — CT2 can either hardcode the two resolved DIDs (0x22000041 for the EnumMapper, 0x2300000E for the StringTable, the way RetailKeyNames hardcodes its three) or port the two-level indirection generically. Given RetailKeyNames already established the "just hardcode the resolved DIDs, cite the probe" precedent for this exact category-4 family, CT2 should follow the same precedent unless a THIRD consumer of GetDIDByEnum appears that would justify factoring out a shared helper.
2. EnumMapper.IdToStringMap[titleId] → raw canonical name (already readable via dats.Portal.TryGet<DatReaderWriter.DBObjs.EnumMapper>).
3. DatStringResolver.ComputeHash(rawName) (already exists, no new code).
4. DatStringResolver.Resolve(0x2300000Eu, hash) (already exists, no new code) for the final localized display string.

No new DAT-reading primitives are required — EnumMapper/EnumIDMap are already exposed by DatReaderWriter.DBObjs, and DatStringResolver already does steps 3–4 for other consumers.

Corrections to the plan (summary)

1. Window constraints are NOT already 90% wired. The plan's "Already in-tree" bullet claims DatConstraintSource registration for the character window; the actual MountCharacter() call sets no such field, and the DAT layout itself authors no MinHeight/MaxHeight on its root to source one from even if it were wired. CT6 needs decomp research into where retail's authored minimum for this specific window actually lives (likely a class-level constant/behavior, not a per-window DAT property) before it can port anything.
2. The row-template elements are not walkable via the normal ImportInfos(dats, layoutId) overload. #375's prototype-skip logic deliberately excludes same-layout template-list targets from the built tree. CT5 must use ImportInfos(dats, layoutId, elementId) (the targeted single-root overload) to read 0x10000248 (LayoutDesc 0x21000045) and 0x10000536 (LayoutDesc 0x2100005E) — documented here so CT5 doesn't waste a cycle rediscovering the same "NOT FOUND" dead end this slice hit first.
3. RowHighlightSprite may already be wrong. The DAT's row-template Highlight state uses 0x06000F93; the current constant in CharacterStatController.cs is 0x06001397. Not fixed in this slice (no production changes); flagged for CT5's review.
4. Everything else in the plan's "Retail recon" section (the Titles page element roster, the header element ids, the PostInit binding order) checks out exactly against the live DAT — no other corrections.