Three fixes addressing the reported 'auras silently vanish on next save'
bug, plus collateral robustness in the same code path:
1. WeakAuras.lua PLAYER_LOGIN handler (~L1297-1308): the downgrade branch
fired StaticPopup_Show('WEAKAURAS_CONFIRM_REPAIR', ...) synchronously
inside the event handler. On the CoA reworked StaticPopup system this
fires too early and silently fails to show the dialog, which means
neither OnAccept nor OnCancel ever runs, so Private.Login() is never
called. With no displays loaded, the next PLAYER_LOGOUT serializes an
empty table over WeakAurasSaved and the user loses all their auras.
Wrap the call in C_Timer.After(0, ...) so it fires after the event
frame stack has unwound and the popup system is ready.
This is the most likely root cause of the user report 'my auras don't
save anymore' that surfaced on the PTR last week.
2. WeakAuras.lua WEAKAURAS_CONFIRM_REPAIR popup (~L2263-2277): OnShow and
OnCancel both unconditionally dereferenced self.data.reason. If the
popup is ever fired with nil or malformed data this throws and blocks
Private.Login() from running via the OnCancel fallback. Guard with a
nil check and default reason to 'unknown' (treated as the automatic /
downgrade path, which is the safe default that still invokes Login).
3. Types.lua WeakAuras.class_types (~L1187): only populated from
CLASS_SORT_ORDER, which on CoA contains only the 11 vanilla classes.
The 21 custom CoA classes were silently missing from every class
filter dropdown in the options UI. Add a fallback loop over
LOCALIZED_CLASS_NAMES_MALE for anything CLASS_SORT_ORDER didn't
already register, mirroring the pattern the spec builder uses at
~L3829.
Switches frame level assignment to depth-based ordering to avoid overflow
and ensure deterministic ordering. WeakAurasFrame now correctly lives on
FrameStrata MEDIUM without interfering with Blizzard UI elements.
(cherry picked from commit e92edf5700ad70587a71c3a403e5cc672dbc9e8e)
#85
Implemented a hard cap for frame level assignments (max 126) across multiple modules, including WeakAuras core logic and AceGUI widget prototypes.
The WotLK engine utilizes a signed 8-bit integer for frame levels. Values exceeding 127 cause an overflow. Previously, many frames were inadvertently stacked at or beyond 128, which remained largely unnoticed but caused significant rendering overhead. This got introduced on WeakAuras 4.0 with nested groups, years ago. On newer Clients the FrameLevels are capped at 10000 which makes this system operate smoothly on those clients. A larger fix will be needed in the future.
This change prevents the renderer from becoming overwhelmed at maximum depth, particularly when Blizzard UI frames with SetTopLevel(true) are toggled. Capping the values at 126 ensures that there is always a 1-bit buffer before the overflow point, allowing high-priority frames to render smoothly without depth conflicts.
(cherry picked from commit 629a45095b10b801573b2cc84d64b6b5a6c1a890)
- Closes#37
Due to an error in the implementation of Class & Spec in Load Conditions and Triggers (Unit Characteristics, Power, Health, Class/Spec, BT2 actualSpec), the system now also applies Retail logic.
As a result of this issue, all data has been erased and must be reselected.
Add methods to the states/allstates table that helps with creating,
updating or remove states in an optimized way
## Advantage of using this function instead of doing a states[key] = {
... }
- If already created, update existing state, and return true if any
value was changed, this can help reduce amount of resources an aura use
- Automatically `return true` when using these functions and any change
was made
## Examples
```Lua
function(states, event, ...)
if event == "PLAYER_TARGET_CHANGED" then
if UnitExists("target") then
-- if state exists it's updated, not replaced
-- show & changed fields can be skipped
states:Update("", {
name = UnitName("target"),
duration = 5,
expirationTime = GetTime() + 5,
progressType = "timed",
autoHide = true
})
else
-- wipe
states:RemoveAll()
end
end
-- no need to return true
end
```
with clones
```Lua
function(states, event, ...)
local currentEssence = UnitPower("player", Enum.PowerType.Essence)
local maxEssence = UnitPowerMax("player", Enum.PowerType.Essence)
for i = 1, 6 do
if i > maxEssence then
states:Remove(i) -- wipe allstates[6]
else
local value = currentEssence >= i and 1 or 0
local newState = {
progressType = "static",
value = value,
total = 1
}
states:Update(i, newState)
end
end
-- no need to return true
end
```
The login message was triggered incorrectly due to the "Beta" tag in the version string. This has been fixed.
Almost completely removed due to impracticality with the 3.3.5a API.
When RAID_ROSTER_UPDATE or PARTY_MEMBERS_CHANGED fires, data is unavailable for ~1.5 seconds.
If these events fire again within that time, the timer needs to be restarted, leading to excessive code complexity and requiring handling for every edge case.
Instead, we now simply check if the unit has changed when the library fires its callback.
- **WeakAuras.SpecForUnit(unit)** = Returns: `classFileName..spec`, `Dominant Tree`, `spent1`, `spent2`, `spent3`
- **WeakAuras.GetUnitRole(unit)** = Returns one of: `"melee"`, `"caster"`, `"healer"`, `"tank"`
- **WeakAuras.SpecRolePositionForUnit(unit)** = Returns: `Dominant Tree`, `spent1`, `spent2`, `spent3`
- **WeakAuras.CheckTalentForUnit(unit, talentId)** = Returns: `"Points spent"` in talent or `nil`
- **WeakAuras.CheckGlyphForUnit(unit, glyphId)** = Returns: `true` if the player has the glyph associated with `spellID` or `spellName`, we can only see the glyphs of players running `LibGroupTalents-1.0`
florian.berthold
NoM0Re
andrew6180
NoM0Re