DBC alignment: core structs → client-verified 1.12 schemas (48 tables)

[MadMaxMangos]

DBC alignment: core structs → client-verified schemas

Aligns the core's DBC representation (DBCStructure.h) with the client-verified 1.12 DBC schemas so every active field carries its provenance name and every server-unused field is documented in place — "commented but correct" and ready to activate if ever needed. Follows the CharStartOutfit pilot (already on master).

Merge order: this PR bumps the src/modules/SD3 and src/modules/Eluna submodule pointers, so it depends on the two companion PRs landing first — mangos/ScriptDev3 and MangosServer/Eluna (both branch enhance/dbc). If those merge as merge/squash commits (changing their master tip SHA), the submodule pointers here are re-pointed to the resulting tips before this merges.

What's in here

48 core DBC tables reconciled. The bulk (46 tables) is mechanical renames + docs; the final two tables (Spell, LiquidType) needed manual adjudication and are the substance of the tail of this branch.

Part	Tables	Renames	Documented (server-unused)
Batches 1–5 (mechanical)	46	125	404
Spell (aggressive rename to .dbd)	1	41	13
LiquidType (field-1 correctness fix)	1	1	—
Total	48	167	417

~1,300 consumer call-sites were updated to the new field names across the game lib, ChatCommands, the SD3 and Eluna submodules, and the playerbot module. Every one was enumerated by the compiler (a rename leaves a stale entry->OldName that won't build), so completeness is guaranteed by the build, not by grep.

Two adjudicated tables (the follow-up)

Spell — aggressive rename to build-exact 1.12 .dbd names. All 41 active SpellEntry fields now carry their Spell.dbd (BUILD 1.12.0.5595-1.12.3.6141) names (e.g. Id→ID, powerType→PowerType, SpellFamilyName→SpellClassSet, SpellFamilyFlags→SpellClassMask, EffectImplicitTargetA/B→ImplicitTargetA/B, EffectApplyAuraName→EffectAura, SpellName→Name_lang). One name-reuse collision the compiler cannot catch — EffectAmplitude(cols 94-96)→EffectAuraPeriod while EffectMultipleValue(97-99)→EffectAmplitude — was handled by snapshotting the original consumer sites before the rename and remapping each by its original column; a dedicated review lens confirmed every reused-token site reads its original column.

LiquidType — a real (latent) correctness fix. Field 1 was mis-read as an int (uint32 LiquidId) but is actually the liquid name string (proven: the real LiquidType.dbc bytes {1,7,13,19,25} are the string-block offsets of Water/Ocean/Magma/Slime/Naxxramas-Slime; the build-exact .dbd agrees). Fixed to char* Name, with the one intentional DBCfmt.h change on this branch: LiquidTypefmt "niii"→"nsii". sizeof(LiquidTypeEntry) and GetFormatRecordSize both go 16→20, so the startup size-assert still holds. The field has 0 consumers, so there is no behavioural change; the extractor sub-system reads LiquidType.dbc through its own reader (fields 0 and 3 only) and is untouched.

Why this is (essentially) zero-runtime-risk

• A rename is compile-time only: same field, same offset, same bytes; sizeof unchanged, so the startup MANGOS_ASSERT(sizeof(T) == GetFormatRecordSize(fmt)) still holds.
• Comment-but-correct touches only already-commented ('x') fields.
• The only functional change is LiquidType field 1 (0 consumers, guarded by the size-assert + an in-game water check).

A branch that compiles and boots is therefore behaviourally identical to before, except the intended LiquidType.Name correction.

For reviewers — shared submodules (SD3 / Eluna) are cross-fork-safe

SD3 (mangos/ScriptDev3) and Eluna (MangosServer/Eluna) are single repositories shared by all five getMangos cores (Zero/One/Two/Three/Four). Because Zero renamed its own SpellEntry while the other cores keep the legacy names, the shared consumer code cannot use either name unconditionally. It is therefore routed through expansion-guarded accessors (extending SD3's existing GetManaCost()/GetPowerType() pattern): sc_creature.h defines SD3_Spell*() helpers that resolve per expansion — CLASSIC→the new .dbd name, TBC/WOTLK→the legacy field, CATA/MISTS→the existing GetXxx() methods — and Eluna guards its sites with ELUNA_EXPANSION == EXP_CLASSIC. So merging the SD3/Eluna enhance/dbc branches upstream leaves One/Two/Three/Four building and behaving exactly as before — each core only ever compiles its own branch. This was verified per-fork against each core's actual SpellEntry struct.

• SD3 → mangos/ScriptDev3 branch enhance/dbc — SpellEntry consumers via guarded accessors (SD3_Spell*). The earlier-batch AreaTrigger id→ID and SpellRange minRange/maxRange→RangeMin/RangeMax renames — which were unguarded — are now routed the same way through SD3_AreaTriggerId / SD3_SpellRangeMin / SD3_SpellRangeMax, so every Zero-side rename that touches shared SD3 code is expansion-guarded.
• Eluna → MangosServer/Eluna branch enhance/dbc — every consumer rename guarded by #if ELUNA_EXPANSION == EXP_CLASSIC (new .dbd name) / #else (legacy token restored verbatim): SpellEntry Id, plus the earlier-batch AreaTrigger id→ID, AreaTable area_name→AreaName_lang, 8× TaxiPathNode fields, SkillLine categoryId/id, and ChrClasses/ChrRaces name→Name_lang — all of which were initially committed unguarded (Eluna is not in the mangosscript target, so those breaks were invisible until a dedicated game-target compile). All four cores' DBCStructure.h were confirmed to share the identical legacy names, so the #else branch is provably correct for One/Two/Three/Four.

Validation (all green)

• Build: every batch and the Spell/LiquidType follow-up compile clean (mangosd links); the compiler is the consumer-completeness net.

• Boot-assert: the deployed build boots and initializes 50 DBC data stores with no size-assert abort, then completes full server startup (spell chains, proc tables, quest/area data — all fed by the renamed SpellEntry).

• Review: adversarial multi-lens reviews (rename-fidelity / consumer-fidelity / collision-correctness), per-finding verified — 0 surviving findings on the Zero side; a dedicated per-fork pass verified the cross-fork accessor branches against every other core's real struct.

• Cross-fork compile proof (real other-fork builds): the SD3 and Eluna enhance/dbc branches were dropped into real One/TBC, Two/WotLK and Three/Cata checkouts and compiled:

  • SD3 → mangosscript on all three: every SpellEntry / AreaTrigger / SpellRange cross-fork guard site compiled to 0 errors, including Cata's distinct accessor branches (GetManaCost() method, powerType/rangeIndex data members, and the consumer sites correctly routing around the Cata-fenced SD3_SpellEffect* accessors). mangosscript.lib links cleanly on all three (and on Classic).
  • Eluna → game on all three: CreatureHooks, ServerHooks and Methods (which pulls in the guarded GlobalMethods/PlayerMethods/UnitMethods headers) all recompiled and game.lib linked with 0 errors — exercising the #else legacy branch under EXP_TBC, EXP_WOTLK and EXP_CATA. The Cata build additionally compiles the string-field sites against Cata's DBCString (char const* const*) representation, confirming the [locale] indexing holds there too. (Four/MoP uses the identical DBCString and legacy names — statically confirmed, not build-cloned.)

  This upgrades the cross-fork guarantee from static struct analysis to real compiles on three other forks.

• In-game smoke: character create + cross-zone run + class trainer + vendor (earlier); plus .learn all_myclass (exercises SpellClassSet/SpellClassMask class-family filtering) and self-cast spells/auras — no issues.

Bonus: fixes a cross-core regression this sweep uncovered

The cross-fork compile sweep surfaced an unrelated, recent regression in SD3 master (commit 005a340f, 2026-06-21): boss_shade_of_aran and boss_deathbringer_saurfang had been changed to #if !defined(MISTS) m_creature->powerType #else GetPowerType(), which assumes every core except MoP carries a Creature::powerType data member. Only Classic does — so mangosscript fails to compile on TBC/WotLK/Cata ('powerType' is not a member of 'Creature'). The bundled SD3 branch drops the guard for plain m_creature->GetPowerType() (present on all cores; behaviourally identical), which is what the code was before the regression and what every fork-pinned SD3 pointer still uses. With this, mangosscript links on TBC/WotLK/Cata (and Classic/MoP are unchanged). It rides along as a one-commit cross-core fix, clearly separated from the DBC-alignment commits.

Deferred / noted (not fixed here)

• EffectDicePerLevel (cols 70-72) reads float in the core struct+fmt but the .dbd declares int32. Server boots (both 4 bytes) and the field name is unchanged; flagged as a candidate type-fix for a separate follow-up (a type change is out of scope for a rename PR).

---

This change is 

[codacy-production]

Not up to standards ⛔

🔴 Issues 50 medium

Alerts:
⚠ 50 issues (≤ 0 issues of at least minor severity)

Results:
50 new issues

Category	Results
UnusedCode	50 medium

View in Codacy

🟢 Metrics 0 complexity · -1 duplication

Metric	Results
Complexity	0
Duplication	-1

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[AppVeyorBot]

✅ Build Mangos ZERO Server 22.04.408-gipsxasv completed (commit d7c6de7a75 by @MadMaxMangos)