Fix crashes introduced in MoP 5.5.4 (build 68016)#69
Conversation
- Guard HideBlizzardFrames against nil self.db when called via ADDON_LOADED before PLAYER_LOGIN has run OnInitialize - Skip nil frames in hideBlizzardFrames (old PartyMemberFrame1..N globals no longer exist in 5.5.4) - Skip SetStatusBarTexture when mediaPath.statusbar is empty/nil; the updated API now rejects empty strings with a hard error - Guard frame[key].points before pairs() in Combo:Update; bar-mode combo points (e.g. Soul Shards as bar) only create .blocks, not .points Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Fix was done with Claude Code. 1 Prompt and all was working again. Changes are minimal and I think clear to understand. |
|
I have tested it and found some issues:
Some stack traces that get spammed a lot, thousands of times from just one dungeon run: ShadowedUnitFrames/modules/auras.lua:548: attempt to index a nil value ShadowedUnitFrames/modules/xp.lua:89: attempt to call a nil value |
- auras.lua: DebuffTypeColor.none no longer exists in 5.5.4; add
hard fallback color {r=0.8,g=0,b=0} so typeless debuffs don't crash
- xp.lua: C_Reputation.GetWatchedFactionData is a Retail-only API;
fall back to GetWatchedFactionInfo() on builds that lack it,
building a compatible factionData table from the old return values
- ShadowedUnitFrames.lua: try both PlayerCastingBarFrame (new name)
and CastingBarFrame (MoP name) so cast-bar hiding works on both builds
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Hi, I am not able to test this changes right now. But I provided you what Claude Code did here. See the message below. Hope this will help! Thanks for testing! I've pushed a second commit to address the reported issues:
Cast bar hiding not working Regarding target frame not updating in instances: this sounds like a deeper event-registration or |
New error report (1939x) showed auraType=nil and the lookup still crashing - turns out DebuffTypeColor itself can be nil at the point auras first render (likely loaded lazily by a different system addon in this build), not just the .none entry. Guard both indexing levels and keep the hard fallback color. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
I was trying your latest commit and getting this crash: 17x ShadowedUnitFrames/modules/units.lua:249: attempt to call a nil value Frames are not loading at all anymore. |
GetSpecialization() does not exist in this build, causing all frames to fail loading entirely. Fall back to spec 1 so spec-gated modules behave as if the player is in their primary spec. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Fourth fix pushed — Fixed with a simple guard: Everything is loading and functional again after this fix. Still testing further — will report back if more issues come up. |
|
Also 3x ...aceShadowedUnitFrames/modules/indicators.lua:115: attempt to call a nil value |
UnitIsQuestBoss() no longer exists in this build, crashing the indicators update on any unit frame shown. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Another nil API: Fixed with |
|
Still getting these 2: 112x ...faceShadowedUnitFrames/modules/highlight.lua:137: attempt to index global 'DebuffTypeColor' (a nil value) 83x ...aceShadowedUnitFrames/modules/indicators.lua:115: attempt to call a nil value |
Same issue as auras.lua - DebuffTypeColor global does not exist in this build, crashing the highlight update whenever a unit has a debuff. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Two more fixes:
Tested locally — unit frames are stable. Further in-game testing (dungeons, PvP, etc.) still ongoing. |
- health.lua: guard DebuffTypeColor (nil in this build) when coloring health bar by dispellable debuff type - soulshards.lua: replace all GetSpecialization() calls with local GetSpec() helper that falls back to 1 if the API doesn't exist; prevents crash for any Warlock player - indicators.lua: guard GetArenaOpponentSpec + GetSpecializationInfoByID at both call sites (arena spec icon + LFD role via spec) - units.lua: same guard for ArenaClassToken Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Proactive batch fix for all remaining known-nil APIs in MoP 5.5.4:
|
|
All the debuff coloring is falling back to the default red you added. Is there a way to fix the border colors to match the correct type again? For instance I had a red border around my raid frames for dispel-able debuffs. |
…lors DebuffTypeColor is nil in MoP 5.5.4 causing all debuff borders/highlights to fall back to a hard-coded red. Instead, define the standard WoW debuff type color table once in ShadowedUnitFrames.lua when the global is absent: Magic=blue, Curse=purple, Disease=brown, Poison=green, none/""=red This allows auras.lua, highlight.lua and health.lua to use the correct per-type colors again, and simplifies those guards back to their original readable form. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Fix: debuff border colors restored (Magic=blue, Curse=purple, Disease=brown, Poison=green) The previous approach of falling back to a hard-coded red New download link for testers: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
Blizzard replaced the DebuffTypeColor table with individual globals (DEBUFF_TYPE_MAGIC_COLOR, DEBUFF_TYPE_CURSE_COLOR, etc.) in MoP 5.5.4. Rebuild the table from those where available so the game's own colour values are used. The classic defaults are kept as a last-resort fallback only if those globals are also absent. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Fix: debuff border colors now use Blizzard's own colour values The previous red fallback was a workaround. Root cause: Blizzard replaced the The fix (same approach as WeakAuras/LibDispel) rebuilds Needs testing: raid frames with dispellable debuffs (Magic/Curse/Poison/Disease borders). We don't have a raid frames user on our end to verify. Latest ZIP for testers: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
|
The color is working, but I don't think the filtering for "only show ones I can dispel" is (on raid frames). I was seeing blue magic as a shadow priest. Unless its counting mass dispel now (which it didn't, before) |
|
Follow-up on the Magic-debuff-highlight question for Shadow Priests: The "can cure" detection (`modules/units.lua` ~line 1500) uses `IsPlayerSpell(spellID) or IsSpellKnown(spellID, true)` to decide if the player currently has access to a dispel (e.g. Mass Dispel = 32375 → "Magic" for Priests). Since there were apparently no class/spell changes in 5.5.4, this is more likely an API behavior change: the retail spellbook rework (Class Tree vs Spec Tree, flattened spellbook) may cause `IsPlayerSpell`/`IsSpellKnown` to now return `true` for spells that exist anywhere in the class spellbook, regardless of whether the current spec can actually cast them — whereas previously it returned `false` for spec-locked spells. Could a Shadow Priest run this in-game and report the result? If both return `true` while on Shadow spec (where Mass Dispel shouldn't be usable), that confirms the API change and we'll need a more reliable check (e.g. `IsUsableSpell` or spec-based filtering). |
|
I am an spriest.... /run print("IsPlayerSpell:", IsPlayerSpell(32375), "IsSpellKnown:", IsSpellKnown(32375, true)) Result: |
IsPlayerSpell() now returns true for spells anywhere in the class spellbook regardless of the current spec in MoP 5.5.4 (e.g. a Shadow Priest reports IsPlayerSpell(32375) [Mass Dispel] as true, even though it's not castable in that spec). This caused Magic debuffs to be highlighted as curable for specs that can't actually dispel them. IsSpellKnown(spellID) (player spellbook, no pet flag) correctly reflects spec-gated availability and replaces the unreliable IsPlayerSpell/IsSpellKnown(.., true) combo. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Confirmed and fixed — thanks for testing! `IsPlayerSpell(32375)` (Mass Dispel) returns `true` even on Shadow spec, where it's not actually castable. This is the broken API in 5.5.4 (likely related to the retail spellbook rework where IsPlayerSpell now reflects "exists in class spellbook" rather than "usable in current spec"). Fix: replaced `IsPlayerSpell(spellID) or IsSpellKnown(spellID, true)` with just `IsSpellKnown(spellID)`, which correctly reflects spec-gated availability — this is the standard check other addons use for "can I currently cast this". Magic debuffs should no longer be highlighted as curable for Shadow Priests after this update. Latest ZIP for testers: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
|
hm...
|
|
Pushed another round of fixes for 3 more nil-value errors that have been reported:
Updated ZIP for testers without git: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
|
1631x ...ceShadowedUnitFrames/modules/monkstagger.lua:44: attempt to index global 'STAGGER_STATES' (a nil value) Locals: moduleClass="MONK" moduleHasBar=true moduleKey="staggerBar" moduleSpec= moduleName="Stagger bar" } frame=SUFUnitplayer units.lua:696{ vehicleUnit="vehicle" castBar=Frame cast.lua:68 powerBar=StatusBar units.lua:1425 emptyBar=StatusBar units.lua:1425 unitType="player" staggerBar=StatusBar units.lua:1425 indicators=Frame indicators.lua:326 portraitTexture=Texture portrait.lua:40 unit="player" fontStrings= TopEdge=Texture NineSlice.lua:52 unitOwner="player" fullUpdates= incHeal=StatusBar units.lua:1425 LeftEdge=Texture NineSlice.lua:52 portrait=Texture portrait.lua:40 registeredEvents= TopLeftCorner=Texture NineSlice.lua:52 topFrameLevel=5 visibility= isDead=false unitRealType="player" unitGUID="Player-4728-05BFC5C3" Center=Texture NineSlice.lua:52 RightEdge=Texture NineSlice.lua:52 highFrame=Frame units.lua:718 backdropInfo= BottomEdge=Texture NineSlice.lua:52 incAbsorb=StatusBar units.lua:1425 healthBar=StatusBar units.lua:1425 BottomRightCorner=Texture NineSlice.lua:52 BottomLeftCorner=Texture NineSlice.lua:52 TopRightCorner=Texture NineSlice.lua:52 unitInitialized=true healAbsorb=StatusBar units.lua:1425 altPowerBar=StatusBar units.lua:1425 } stagger=0 percent=0 state=nil (*temporary)=nil (*temporary)=nil (*temporary)=nil (*temporary)=nil (*temporary)=nil (*temporary)=nil (*temporary)="attempt to index global 'STAGGER_STATES' (a nil value)" |
MoP 5.5.4 (68016) doesn't define the retail STAGGER_STATES table, causing a Lua error in Stagger:Update for Brewmaster Monks. Fall back to the older STAGGER_YELLOW_TRANSITION/STAGGER_RED_TRANSITION globals or hardcoded defaults if neither is available.
|
Fixed another nil-API issue reported by a tester (Brewmaster Monk):
MoP 5.5.4 (68016) doesn't define the retail Updated test ZIP: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
|
For Death Knights, the rune bar doesn't show any colors (red, blue, green). It's all gray. |
Can you run this please and post me the results? /run print("GetRuneType:", GetRuneType, "type1:", GetRuneType and GetRuneType(1), "type2:", GetRuneType and GetRuneType(2)) |
17:14:10] GetRuneType: function: 000001E173E3E1A8 type1: 1 type2: 1 |
|
Shadow priests still see magic debuff boarders for dispelling on frames. 
|
|
Addressed the "rune bar is all gray for Death Knights" report. Turns out this branch's Ported the per-type coloring ( Updated ZIP for testers without git: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
|
This is a minor issue but Incoming Heals - Outside bar limit setting is not being recognized. The incoming heal bar still goes over the health bar. 
|
|
Ready check raid indicator was not working me. I wasn't getting anything on my frames. |
|
Pushed two more fixes:
Still investigating the "Shadow priest sees Magic debuff border" report - in MoP, baseline "Dispel Magic" (spell 527) can remove Magic debuffs for any priest spec, so a Magic-type border showing for a Shadow priest may actually be correct MoP behavior (unlike Mass Dispel, which was the earlier issue). @sfhb24 could you confirm:
Updated ZIP for testers without git: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
Same issue with Absorb overlay (e.g. DK anti-magic shell) 
|
|
A couple of follow-ups to narrow down the two remaining open reports: @jbkellen – absorb overlay going outside the bar limit The absorb bars (incoming absorb / heal absorb) actually reuse the exact same layout/cap code as the incoming-heal bar, so the
If it overflows by roughly ~30% that points at a config/default value rather than the texture crash, so #3 is the key one. @sfhb24 – Magic debuff border on Shadow Priest Friendly bump on this one 🙂 — when you get a chance, could you run this and post the result? It tells us whether baseline Dispel Magic (527) is the reason the Magic border shows for Shadow: And: does casting Dispel Magic on that target actually remove the debuff? If it does, the Magic border may actually be correct MoP behaviour (unlike the earlier Mass Dispel case), which is why I don't want to change the curable-spell list until we're sure. |
You cannot cast Dispel magic on friendly targets. It is enemy only. The friendly dispel is a different spell, Purify, which shadow does not have access to. All priests: Only holy/disc: |
|
Thanks for digging into this @sfhb24 — and you're right about Purify: spell 527 (Purify) is the Holy/Disc friendly dispel, and Shadow doesn't have it ( But that's not where the Magic border comes from. The highlight is driven by Mass Dispel (32375), which in MoP is a baseline ability for all priest specs — including Shadow. We confirmed it on a level-85 Shadow priest: So the Magic border is actually correct MoP behaviour, unlike on retail where Mass Dispel isn't baseline for Shadow (which is why you're used to not seeing it). I'd rather not strip it out, since it does reflect a debuff you can act on. That said — if the feeling is that Mass Dispel is too clunky (cast time, cooldown, AoE) to count as a "real" dispel for the highlight, we could drop it from the priest cure list so Shadow stops showing Magic borders (Holy/Disc are unaffected, they keep Purify). Let me know which you'd prefer. |
|
It should not be shown for shadow priests. I'm not used to retail (I don't play spriest in retail) - this is how SUF functioned before 5.5.4 Its typically wrong in raids: 
E.g. this is Sha of Pride's Mark of Arrogance (https://www.wowhead.com/mop-classic/spell=144351/mark-of-arrogance), showing me I can dispel it. Mass dispel does not work on this. At least in mop, several debuffs are coded like this to prevent spriest cheesing healer mechanics. Spriests generally will use a custom WA if they want to track something to dispel. |
Mass Dispel (32375) is baseline for all priest specs in MoP, so IsSpellKnown(32375) is true even on Shadow, which made the dispel highlight flag every Magic debuff as curable. In practice most raid debuffs (e.g. Sha of Pride's Mark of Arrogance) are immune to Mass Dispel by design, so this was a false positive. Single-target Magic dispel is Purify (527), which only Holy/Disc have. Removing 32375 from the priest cure list restores the pre-5.5.4 behaviour; Holy/Disc keep their Magic highlight via Purify. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Good call — that's a solid technical reason, not just a preference, so I've made the change. Fix: Shadow priests no longer get the Magic dispel highlight. Removed Mass Dispel (32375) from the priest cure list. The reasoning matches yours: Mass Dispel is baseline for all priest specs in MoP (so Holy/Disc are unaffected — they keep the Magic highlight via Purify (527), which is the real single-target dispel and which Shadow doesn't have. Updated ZIP for testers without git: https://github.com/HydraxSkarrag/ShadowedUnitFrames/archive/refs/heads/fix/mop554-compat.zip |
|
|
Thanks, that's really helpful — especially #3 and #4. The anti-magic shell is a damage absorb, which is drawn by the Incoming absorbs bar (a separate bar from Incoming heals), so the 100% you set on Incoming heals doesn't apply to it. That it overflows with no Lua error points at a config value rather than the texture crash. Could you run this one line and paste the output? It reads the actual limit values your profile is using: If Also: under the player frame options there should be an "Incoming absorbs" section just below "Incoming heals" — if you genuinely don't see it, let me know, that's a second thing to look at. |
|
|
Closing this in favour of a corrected PR — apologies for the mix-up. This PR was opened against Full transparency on how this happened: the fix was done with AI assistance (Claude Code), and the mix-up came from it effectively working with a kind of split brain — patching my local Classic install on one side, while developing this PR against the retail The new build is the version I'm running myself in-game on live 5.5.4 without any problems — raiding on a Warlock, and smooth on a Feral Druid and Elemental Shaman too. New PR: #70 Huge thanks for all the testing @jbkellen @sfhb24 @almx @100mll 🙏 — could you re-test the classic build instead? You only need to replace the ShadowedUnitFrames folder (your options addon is unchanged). ZIP: |
Getting a bunch of lua errors due to the libs folder missing. I copied libs folder from prior zip and will continue to test. Thanks. |
|
@jbkellen good catch, thanks — and sorry for the hassle. The raw GitHub source ZIP doesn't include the I've put up a pre-packaged build that bundles Just extract into |
I don't know if this is a feature of the retail code or an issue with the classic code, but for the version I was testing before #70 whenever I get onto a vehicle, the Player Frame changes to the Vehicle frame: 
With the latest classic version, the player frame doesn't change, and the cast bar of the vehicle no longer shows. 
|
5 participants
Summary
WoW Mists of Pandaria patch 5.5.4 (build 68016) introduced several Retail-backported API changes that cause the following errors on login/zone change:
attempt to index field 'db' (a nil value)inHideBlizzardFrames— triggered byADDON_LOADED(Blizzard_ArenaUI) firing beforePLAYER_LOGINhas runOnInitialize, soself.dbis not yet setattempt to index local 'frame' (a nil value)inhideBlizzardFrames— the legacyPartyMemberFrame1..Nglobals no longer exist in 5.5.4;_G[name]returns nil and gets passed into the loopbad argument #2 to '?' (Usage: local success = self:SetStatusBarTexture(asset))— 5.5.4 now rejects empty strings inSetStatusBarTexture; guard addedbad argument #1 to 'pairs' (table expected, got nil)inCombo:Update— when a combo-point module (e.g. Soul Shards) is configured as a bar, only.blocksis created, not.points; nil-guard addedFixes
ShadowedUnitFrames.luaHideBlizzardFrameswhenself.dbis nilShadowedUnitFrames.luahideBlizzardFramesloopmodules/layout.luaSetStatusBarTexturewhen path is non-emptymodules/basecombopoints.luaframe[key].pointsbefore iteratingTested on WoW Classic (MoP) 5.5.4.68016.