GetXPRate / GetRestXPRate did raw arithmetic on character.XP / .XPMax /
.lastLogoutTimestamp, which are nil for own alts seen via guild comm but
never fully scanned. Crashed AccountSummary on Vol'jin - CoA Beta.
Re-sync after coa-ace3 9583952 backported WoWUIDev/Ace3 PR #10 which fixes
the AceDB-3.0 simple-value defaults metatable: previously falsy defaults
like ["*"] = false read back as nil because of `k2~=nil and v or nil`
short-circuiting. Now they round-trip correctly.
Re-sync after coa-ace3 3ec2009 added two CoA-compat patches:
- AceGUI-3.0/widgets/AceGUIContainer-BlizOptionsGroup.lua: parent
falls back to UIParent when InterfaceOptionsFramePanelContainer is nil
- AceConfig-3.0/AceConfigDialog-3.0: Settings.* block guarded with
fallback to InterfaceOptions_AddCategory on WotLK-era clients
Without these, every addon registering a Blizzard Interface Options
panel via AceConfigDialog errors on load on the CoA client.
Re-sync after coa-ace3 d422ad3 which converted 42 numeric FileDataIDs in
Set*Texture() calls back to string paths. Upstream Ace3 uses FDIDs which
silently fail on WoW 3.3.5 / CoA, rendering color swatches, checkboxes
and window chrome as solid-red placeholders.
Altoholic's DataStore_Crafts hardcodes a ProfessionSpellID lookup so
the localized profession name received over guild comms can be
resolved back to a canonical English key (see GetProfessionID at
DataStore_Crafts.lua:95). Stock table covers the vanilla 15
professions only.
The Voljin/PTR realm adds two custom tradeskills:
* Woodcutting — base spell 13977860 (single-rank gathering skill,
parallels Mining/Herbalism shape)
* Woodworking — Apprentice 1005008, Journeyman 1005009,
Expert 1005010, Artisan 1005011 (matches the
vanilla 75/150/225/300 rank ladder)
Without this, the local TRADE_SKILL_SHOW data is still captured by
the runtime API path, but the cross-character / cross-locale sync
through GuildBroadcast falls through to the linear scan and never
finds a matching ID — guildmates' Woodcutting/Woodworking ranks
don't propagate.
IDs cross-referenced against coa-professionmenu/ProfessionMenu.lua
:200-206 (the in-house CoA profession panel which enumerates these
exact IDs) and verified against db.exil.es (/spell/13977860 →
"Woodcutting", /spell/1005011 → "Artisan Woodworking").
Vanilla Altoholic hardcodes a 10-entry ChatColor table keyed by the
englishClass tokens MAGE/WARRIOR/.../DEATHKNIGHT. On the CoA Voljin/PTR
realm UnitClass / GetGuildRosterInfo return tokens like BARBARIAN,
WITCHDOCTOR, CHRONOMANCER, … so the lookup falls through:
* Altoholic:GetClassColor (Altoholic.lua:580) returns WHITE for all
21 CoA classes via the `or WHITE` fallback — guild/character/
profession panes lose their per-class colours.
* DataStore_Characters._GetColoredCharacterName had no fallback at
all — `ClassColors[englishClass] .. character.name` hard-crashed
on nil-concat for any CoA-class character.
* Altoholic.lua:710 read CLASS_ICON_TCOORDS[class] for the character
portrait without a fallback; CoA classes aren't in the vanilla
sprite sheet's coord table, so the next line `tc[1]` crashed.
Fix follows the established Exiles addon-port pattern (see
coa-omen/CoAClassColors.lua, coa-shadowedunitframes/.../CoAClassColors.lua,
coa-kui-nameplates/.../CoAClassColors.lua): mirror _G.RAID_CLASS_COLORS
into the addon's private table at load. The CoA client itself ships
the realm-authoritative 32-token palette (10 vanilla + HERO + 21 CoA)
in Interface/SharedXML/SharedConstants.lua inside patch-B.MPQ, which
populates RAID_CLASS_COLORS at FrameXML load time — see
db.exil.es /coa/dev for the full table.
- Altoholic/CoAClassColors.lua: new file, mirrors source palette into
Altoholic.ClassInfo as "|cFFRRGGBB" ChatColor escapes. Never
overwrites — preserves the addon's vanilla defaults and any future
user overrides.
- Altoholic/Altoholic.xml: loads CoAClassColors.lua after Altoholic.lua
so Altoholic.ClassInfo exists.
- Altoholic/Altoholic.lua: defensive CLASS_ICON_TCOORDS lookup with
WARRIOR fallback (wrong icon beats crash; CoA character creation
uses its own sprite sheet which doesn't extend the vanilla table).
- DataStore_Characters/DataStore_Characters.lua: inline mirror after
the local ClassColors table (can't be touched from a sibling file
because the table is file-local), plus `or WHITE` defensive fallback
in _GetColoredCharacterName and _GetClassColor.
Does not touch DataStore_Talents — CoA's MoA system uses
C_CharacterAdvancement, not GetNumTalentTabs/GetTalentInfo, so that
module needs a full API rewrite rather than a data patch.
florian.berthold
telkar-rg
telkar-rg