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. 
|
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.