Add CoAClassSpecData.lua (copied from coa-db/data) and wire
GetPlayerCoARole() into TankMode so CoA tokens resolve TANK/HEALER/DAMAGER
from their active spec instead of defaulting to DAMAGER.
- CoAClassSpecData.lua: defines CoAClassSpec keyed by UnitClass token,
loaded in .toc before Core.xml/Modules.xml
- GetPlayerCoARole(): pcall-guarded helper that calls
SpecializationUtil.GetActiveSpecialization() (1-based index) to look up
the current spec in CoAClassSpec[token].specs; TANK > HEALER > DAMAGER
precedence when a spec carries multiple roles; returns nil for vanilla
classes so the existing IsTank/IsHealer path is unchanged
- mod:Update(): try GetPlayerCoARole() first; fall through to vanilla
logic only when nil (vanilla class or unresolvable spec)
- Re-evaluation on spec change already covered: PLAYER_TALENT_UPDATE
fires on both spec and talent changes, driving mod:Update()
luac -p: TankMode.lua OK, CoAClassSpecData.lua OK
Marks this fork as carrying the CoAClassColors.lua patch, so users can
tell at a glance (e.g. via /reload addon list) that they are running the
guild-patched build. Suffix follows the coa-omen convention
(3.0.9-coa1).
Kui_Nameplates picks its colour source table once at load
(Modules/ClassColours.lua:90 and Libs/Kui/Kui.lua:56-60):
cc_table = CUSTOM_CLASS_COLORS or RAID_CLASS_COLORS
with no per-key fallback. When the !ClassColors addon is loaded it
injects a vanilla-10-only CUSTOM_CLASS_COLORS, so the 22 CoA tokens
silently fall through and class-coloured friendly names disappear
(plus a nil-arg in kui.GetClassColour for the str path).
New file mirrors any RAID_CLASS_COLORS entry that CUSTOM_CLASS_COLORS
is missing, when !ClassColors is loaded. Idempotent — only fills nil
keys, so user customisations win. RAID_CLASS_COLORS itself is left
untouched (the Voljin/CoA client populates it from
patch-B.MPQ → SharedXML/SharedConstants.lua).
Same pattern as coa-omen and coa-shadowedunitframes' fixes.
florian.berthold
andrew6180