WowAce

Seems like HideOrderHallBar breaks some functionality of C_Garrison and thus also breaks some addons that use the API such as OrderHallCommander.

For example: https://wow.curseforge.com/projects/orderhallcommander/issues/11

My guess would be that Blizzard coded some initialisation stuff when the OrderHallCommandBar is first shown. As the addon interrupts that process, some of the initialisation is not executed.

HideOrderHallBar disabled:

Dump: value=C_Garrison.GetClassSpecCategoryInfo(4)
[1]={
  [1]={
    limit=3,
    description="Low-ranking among the elemental hierarchy, lesser elementals overwhelm their foes with sheer, unending numbers.",
    name="Lesser Elementals",
    count=3,
    icon=1396645,
    classSpec=97
  },
  [2]={
    limit=1,
    description="Proficient air shamans act as a living conduit for the elements, wrapping themselves in the fury of the tempest as they become an Air Ascendant.",
    name="Ascendants",
    count=1,
    icon=1396660,
    classSpec=139
  },
  [3]={
    limit=2,
    description="\"It proves difficult for your enemies to defeat you when you command the very ground on which they stand.\" - Geomancer Jakara",
    name="Earthen Ring Geomancers",
    count=2,
    icon=1401884,
    classSpec=98
  }
}

HideOrderHallBar enabled:

Dump: value=C_Garrison.GetClassSpecCategoryInfo(4)
[1]={
}

@Ketho,

I think it would be a good idea to call the method from your addon.

I guess simply adding the following line to the addon would suffice (right after b:Hide())

b:RequestCategoryInfo()

That way, other potential addons that use C_Garrison won't need to be aware of the existence of your addon.

You are probably right to re-register some of the events, for completeness.

RefreshCategories() seems to be just about refreshing the icons on the OrderHallCommandBar and basically just for visualization. As your addon's goal is to hide it, I don't see a reason to call this method.

Calling RequestCategoryInfo() should indeed be done whenever the data itself changed, and that is when order hall talents change (introduction of a new follower type or added perks on existing ones). However, this happens very rarely and whilst added for completeness, it won't have any significant impact.

So basically these 2 events:

* GARRISON_TALENT_COMPLETE

* GARRISON_TALENT_UPDATE

Why the Blizzard code listens to UNIT_PHASE makes no sense to me unless it is meant as a replacement for PLAYER_ENTERING_WORLD. I don't see a reason to make that call, unless the data of C_Garrison is reset upon entering world (or even upon phasing). Not sure unless we can see the code of C_Garrison. If that's the case (but how can we be sure of that?) I would also listen to UNIT_PHASE.

The more I think about this, the more I feel that C_Garrison's codebase (and internal logic) is flawed and that we should take it up with Blizzard as a bug.

Seems good. Only thing I'd change is to register the UnitEvent instead of event.

self:RegisterUnitEvent("UNIT_PHASE", "player");

see https://github.com/Gethe/wow-ui-source/blob/live/AddOns/Blizzard_OrderHallUI/Blizzard_OrderHallCommandBar.lua#L34