The CoA Vol'jin core does not push UnitDetailedThreatSituation data
for party-member units, so vanilla Omen draws only the local
player's bar in 5-mans. The same install on Bronzebeard/classic+
shows the whole party because that core does push the data. The gap
is server-side, not client-side, and there is no Omen flag that
fixes it.
OmenSync layers a tiny SendAddonMessage("OMSYNC", …, "PARTY"|"RAID")
relay on top:
- Each player's Omen broadcasts its own player+pet threat values
(throttled, ~0.4s + 5% delta) every time updatethreat() succeeds
via the API path.
- Receivers store incoming values keyed by senderGUID/mobGUID and
serve them as a fallback in updatethreat() whenever
UnitDetailedThreatSituation returns nil.
When the API does push data (Bronzebeard) the existing path still
wins; sync values are simply unused, so this is a no-op on healthy
realms. Both peers must run a fork that emits the OMSYNC prefix.
Wire format keeps each message under the 255-byte AddonMessage cap:
<subjectGUID>|<mobGUID>|<threatValue>|<isTanking 0|1>
Sender's name comes from CHAT_MSG_ADDON's sender arg. Subject GUID
distinguishes the player and pet broadcasts each Omen instance
emits.
Hook in Omen.lua's local updatethreat():
- After UnitDetailedThreatSituation returns nil for any unit, try
Omen:SyncGetThreat(guid, mobGUID).
- After it returns a value for "player" or "pet", call
Omen:SyncBroadcastThreat to relay it to peers.
The previous file augmented _G.RAID_CLASS_COLORS with hand-picked
placeholder colors. On both the Voljin/CoA and Ascension classic+
clients the table is already populated by FrameXML
(SharedXML/SharedConstants.lua) with all 32 class tokens, so the
augmentation was dead code (only-set-if-nil never triggered) and the
hand-picked palette diverged from what the realm itself ships.
The path that DOES still need fixing is !ClassColors. When that addon
is loaded it injects a separate _G.CUSTOM_CLASS_COLORS populated only
with the vanilla 10, and Omen.lua:914-917 prefers CUSTOM_CLASS_COLORS
over RAID_CLASS_COLORS. So on a !ClassColors-equipped client the 22
CoA tokens silently fall through and the bar reverts to
dbBar.BarColor.
Rewritten to: when CUSTOM_CLASS_COLORS exists, copy missing entries
from RAID_CLASS_COLORS — same nil-only policy. RAID_CLASS_COLORS is
left untouched (the client is authoritative). No more divergence
between Omen and the realm palette.
Adds CoAClassColors.lua which merges 22 entries (HERO + 21 custom) into _G.RAID_CLASS_COLORS at file-load time, before Omen.lua takes its local snapshot. Vanilla 10 are left untouched. !ClassColors is also folded in if loaded.
Fixes: Omen bars rendering generic dbBar.BarColor for all CoA classes because Omen.lua:1629 looks up RAID_CLASS_COLORS[class] keyed on the file_string returned by UnitClass(), and PROPHET / MONK / FLESHWARDEN / etc. don't exist in stock Blizzard tables.
Imported from /srv/add01/wow-ascension/Interface/AddOns/Omen — the
build Ascension's WotLK 3.3.5 client ships.
Single vendored drop: Ascension's build process bundles their custom
patches with the standard CurseForge packager output (62 embedded
Libs/), and the individual patches aren't published separately.
Net delta vs upstream v3.0.9, excluding bundled libs and CRLF
normalization: 11 files, 2284+/34- — Ascension-specific adaptations
for WotLK 3.3.5.
License: All rights reserved (per .toc).
florian.berthold
Xinhuan