Skip to content

MoP Classic 5.5.4 (68016) compatibility fixes#70

Open
HydraxSkarrag wants to merge 1 commit into
Nevcairiel:classicfrom
HydraxSkarrag:fix/mop554-classic
Open

MoP Classic 5.5.4 (68016) compatibility fixes#70
HydraxSkarrag wants to merge 1 commit into
Nevcairiel:classicfrom
HydraxSkarrag:fix/mop554-classic

Conversation

@HydraxSkarrag

@HydraxSkarrag HydraxSkarrag commented Jun 21, 2026

Copy link
Copy Markdown

What

WoW MoP Classic 5.5.4 (build 68016) backported several retail API/UI changes that break Shadowed Unit Frames on the classic line. This adds minimal guards/fallbacks so it runs cleanly on 5.5.4.

This targets the classic branch — the line that actually supports MoP Classic. It supersedes #69, which mistakenly targeted master (retail); see that PR for the full testing history.

Fixes

  • DebuffTypeColor: rebuilt from the new DEBUFF_TYPE_*_COLOR globals when the old table is absent, keeping correct per-type debuff border colours instead of hardcoding values.
  • hideBlizzardFrames / basicHideBlizzardFrames: guard nil frames (some class-resource frames don't exist in this build).
  • HideBlizzardFrames: bail if self.db isn't ready yet; use PlayerCastingBarFrame or CastingBarFrame for the cast bar.
  • auras: guard frame.auras.buffs / .debuffs before indexing.
  • incheal / layout / runes: guard widget:GetStatusBarTexture() (nil before a texture is set) and skip empty statusbar texture paths.
  • basecombopoints: guard frame[key].points before iterating.

Download (testers without git)

The raw GitHub source ZIP does not include the bundled libraries (libs/ are externals), which causes a wave of Lua errors on load. Use this pre-packaged build instead — it includes libs/ and both addon folders:

➡️ ShadowedUnitFrames-mop554-classic.zip

Extract into World of Warcraft/_classic_/Interface/AddOns/ (contains ShadowedUnitFrames/ and ShadowedUF_Options/), overwrite if prompted.

Testing

Running on a live MoP Classic 5.5.4 install — raiding on a Warlock with no issues, and verified smooth on a Feral Druid and Elemental Shaman as well.

WoW MoP Classic 5.5.4 backported several retail API/UI changes that broke
SUF on the classic line. Minimal guards/fallbacks:

- DebuffTypeColor: rebuilt from the new DEBUFF_TYPE_*_COLOR globals when the
  old table is absent, keeping correct per-type border colours.
- hideBlizzardFrames/basicHideBlizzardFrames: guard nil frames (some
  class-resource frames don't exist in this build).
- HideBlizzardFrames: bail if self.db not ready; use PlayerCastingBarFrame
  or CastingBarFrame for the cast bar.
- auras: guard frame.auras.buffs/.debuffs before indexing.
- incheal/layout/runes: guard widget:GetStatusBarTexture() (nil before a
  texture is set) and skip empty statusbar texture paths.
- basecombopoints: guard frame[key].points before iterating.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@HydraxSkarrag

Copy link
Copy Markdown
Author

@jbkellen thanks — and to answer your "retail feature or classic issue" question directly: it's a feature gap in the classic line, not a regression from these fixes.

The retail (master) build you tested before has full vehicle support — it swaps the player frame to the vehicle (UnitHasVehicleUIframe.unit = vehicleUnit), shows the vehicle cast bar, and even has a "Disable vehicle swap" option. The upstream classic line never implemented any of that (it was built for Vanilla/TBC/WotLK, where vehicle UI works differently), so on classic the player frame stays player and the vehicle/its cast bar don't show. None of the #70 changes touch this — the capability simply isn't in the classic codebase.

The good news: since the retail vehicle code clearly worked on your live 5.5.4 client, the vehicle APIs exist on MoP Classic, so this should be portable to the classic branch. I'll look into bringing the vehicle-swap (player→vehicle frame + vehicle cast bar) over.

To make sure I reproduce and test the right thing:

  • Which vehicle were you in for the screenshots (a quest/world vehicle, a dungeon/raid vehicle, a turret…)?
  • Is it specifically the player-frame-swap + the vehicle cast bar you're after, or also things like vehicle power/seat indicators?

I'll follow up here once I've ported it. Note it touches secure (combat-protected) frame handling, so it'll need in-combat testing before it's solid.

@jbkellen

Copy link
Copy Markdown

To make sure I reproduce and test the right thing:

  • Which vehicle were you in for the screenshots (a quest/world vehicle, a dungeon/raid vehicle, a turret…)?
  • Is it specifically the player-frame-swap + the vehicle cast bar you're after, or also things like vehicle power/seat indicators?

I'll follow up here once I've ported it. Note it touches secure (combat-protected) frame handling, so it'll need in-combat testing before it's solid.

I was at the Tiller's farm getting into one the wild crops. It casts a "Vine Slam" ability which shows on the cast bar inside the player frame after it switches. One thing that wasn't shown on my screenshots is that the Buff frame at the top right of the screen (next to the minimap) also switches and shows the vehicle's buffs.

@HydraxSkarrag

Copy link
Copy Markdown
Author

Thanks for running those checks @jbkellen — confirmed it's a separate-unit vehicle (UnitHasVehicleUI("player") = true, with a distinct vehicle unit), so the retail build swaps the frame to it and the classic line doesn't. Your observation is correct.

After looking into it: I'm going to leave this out of scope for this PR. Classic-line SUF never implemented vehicle-frame swapping — it's a retail-only feature, not a regression — and this PR is deliberately limited to MoP 5.5.4 compatibility fixes (restoring what broke), not porting retail features into the classic codebase. Vehicle swapping also touches secure/combat-protected frame code, which is a much bigger change than fits a compat fix.

If full vehicle-frame support matters to you, the retail/master build has it (at the cost of the other retail-on-classic issues), or it'd be worth raising as a separate feature request upstream. Really appreciate the thorough testing here either way 🙏

@jbkellen

Copy link
Copy Markdown

No worries. I wouldn't have noticed it at all if it hadn't been for the build posted in #69

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants