Authors CurseForge

In patch 3.0 and wrath of the lich king, there is a new bug (or feature depending on how you look at it).

Problem:
A mod that has its name in red at the character login/addon selection screen means that it is LoadOnDemand. These addons marked in red WILL NOT LOAD unless another addon uses LoadAddOn() directly on them. Even if another addon OptDep or ReqDep the LoD addons/libraries, THEY WILL NOT LOAD unless directly instructed to do so in addon code with LoadAddOn().

Refer to:
http://forums.worldofwarcraft.com/th...71929880&sid=1

An addon that is marked LoD with

## LoadOnDemand: 1

in the TOC will not load if another addon has the LoD addon listed in its OptionalDeps. The only way to force a LoD addon to load is via the use of LoadAddOn(). This severely breaks disembedding addon libraries, especially since many libraries depend on other libraries.

As a minimal test case, I've compiled this zip:

http://pachome2.pacific.net.sg/~xinhuan/wow/LoadOnDemandProblem.zip

which consists of 2 addons, AddOnA and AddOnB.

---------------
AddonA.toc:
## Interface: 30000
## Title: AddonA Test
## Notes: AddonA Test
## LoadOnDemand: 1

AddonA.lua
---------------
AddonA.lua:
ChatFrame1:AddMessage("Loading AddonA")
---------------
AddonB.toc:
## Interface: 30000
## Title: AddonB Test
## Notes: AddonB Test
## OptionalDeps: AddonA

AddonB.lua
---------------
AddonB.lua:
ChatFrame1:AddMessage("Loading AddonB")
---------------

If you run these 2 addons, you will see that AddonB will load, AddonA does not. If you then edit AddonA.toc and change its LoD status from 1 to 0 making it not LoD and load WoW again, both A and B will then load as expected. (This can be verified on build 9061)

Currently on live realms, whether AddonA is LoD or not, because AddonB lists it in its OptDeps, AddOnA will load.

Is this a bug or design change? I am currently forced to put LoadAddOn() at the start of my addons to force load all used disembedded libraries, and insert LoadAddOn() statements in disembedded libs that use other LoD libs.

Not only will OptionalDeps not work, RequiredDeps also doesn't work. If AddonB ReqDepped AddonA, then neither A nor B will load, and both A and B will have red text in the addon listing in the character selection screen.

You can then perform
/run LoadAddOn("AddonA") LoadAddOn("AddonB")
in game and both will load.

This post is which is waiting for a blue reply.

This has severe implications because it means no LoD disembedded library will load, only AceLibrary will load them (Ace2 addons). Ace3 does not. Rock addons will work if it doesn't use any non-Rock library, but will break if the Rock libraries are made non-LoD.

---------
There are only 4 workarounds to this problem.

1. Make all libraries non-LoD. Then Optdeps will work properly.

2. Make all libaries LoD. This requires all libraries that use other libraries and all addons to insert additional lines at the top of their first file LoadAddOn() statements that load all of their required libraries. These LoadAddOn() calls must be done before :NewAddon() call in Rock/Ace2/Ace3.

3. Use embedded libraries. The LoadAddOn() calls at the top of the first file in the addon would then just fail silently.

4. Modify LibStub to LoadAddOn() libraries that are requested. This is the easiest fix. compared to everything else.

----------
It is important to note that this bug does not affect anything that relies on the ##LoadWith or LoadAddOn() mechanism, such as the Blizzard internal addons (their launchers are in the default UI code to load them), or a loadmanager such as AddonLoader.

This bug is important enough that it will break thousands of users of their addons if they run disembedded. This thread is to discuss which solution to implement, with the impending patch 3.0. It is unlikely the thread on the official UI forums will get a response (partly due to Blizzcon).

In order to have my Beta UI working with disembedded libs, I have applied the solution (1). All I can say is that any addons using LibRock should be carefully looked at. Those addons rely only on LibRock to LoadAddOn each needed components of LibRock in the good order, i.e. they don't even list them in OptionalDeps. This works pretty well with LoD libraries. But as soon as they become non-LoD, LoadAddOn does not have any effect anymore and loading fails.

Heres my pre-rant vote: #2


<you can stop reading here>

This part is my favorite:

[11 00:26] <Xinhuan> there's a new [bug or feature?] in patch 3.0 where a LoD addon will no longer load whether its optdepped or reqdepped
[11 00:26] <Xinhuan> and the only way to load it is via LoadAddOn()
[11 00:26] <Xinhuan> this actually means that all Ace2 addons will continue to work
[11 00:26] <_Yssaril_> so whats the point of LoD then?
[11 00:26] <Xinhuan> because AceLibrary-2.0 uses LoadAddOn() to force used library to load

Rock should still work too, but having to make standalones non-lod to get them to work with Ace3 and non-framework mods. will probably break rock, and ace2.

The simplest thing would be to put it into libstub (i'm still bitter about why it wasnt). That won't happen, i tried. So now everyone will have to use embedded libraries, or a standalone addon loader, or maybe blizz will fix it. who knows.

Quote from sylvanaar

So now everyone will have to use embedded libraries, or a standalone addon loader, or maybe blizz will fix it. who knows.

.. or a customized local LibStub that LoadAddOns.

Quote from Adirelle

.. or a customized local LibStub that LoadAddOns.

I know, I have thought about it many times. I even had a name: LoDStub

I guess the main argument against LoadAddOn in LibStub was "OptDep does it already". Now that it doesn't anymore, we may discuss this again, don't we ?

Quote from dafire

I suggest using libstub using as an AddonLoader and setting it in all Libraries as AddonLoader.

So libraries will be LoadOnDemand if Libstub is disembedded and will get loaded always otherwise.

While interesting, that will not resolve the issue : if all libraries are managed by LibStub, it will still have to load them with LoadAddOn. So we are basically back to the point where LibStub does not LoadAddOn.

Quote from Adirelle

I guess the main argument against LoadAddOn in LibStub was "OptDep does it already". Now that it doesn't anymore, we may discuss this again, don't we ?

Heres a summary:

My opinions about this have always been that "load on use" was the best way for libraries to be loaded by default. OptDep breaks that, and is really no better than embedded.

Most addons dont use libraries they embed right away. They may never use them, yet they still are loaded. Same goes for optdep, it was just as bad in this respect.

Having the loading be transparent to the code using it is the best all around solution, and is the one ace2 used. ace2 would also prevent addon load failure because you forgot to enable a library rather than give you an error.

I think the model ace2 used should have been improved upon, rather than being thrown out in favor of "embedded only, if you dont like it, leave"

Quote from Nevcairiel

What will happen is, that i'll run a script to remove all LoadOnDemand tags from all Libraries on the WoWAce page. Its the only solution thats simple enough to script-run it in the next day or so ready for 3.0 release.

See, the discussion is already over.

Quote from Nevcairiel

This will not break Rock or Ace2 Libraries like other people claimed (there isn't even a theoretical reason why it would), i already tested it on a big addon set locally, using alot of popular addons from all 3 frameworks.

It will for some LibRock addons.

Look at, say, CowTip ToC file and tell me how it will get LibRockConsole-1.0 to be loaded before itself once LibRockConsole-1.0 becomes non-LoD ? And CowTip isn't a lonely case.

Those addons will have to be fixed too.

Quote from dafire

An other simple solution would be creating a simple "LibraryLoader" addon and changing all tocs to use it.

Course that'd only work if you had the right to change every addon written by anyone so that it used "LibraryLoader".

I suggest not trying to fix this Nev, you'll only shoot yourself, and Curse in the foot changing other authors work without thier permission.

Just remove the no-lib option entirely until Blizzard fixes it. Any heavy handedness on your end will set a bad precident.

Quote from Nevcairiel

- LibraryLoader would have to load before any other addon, not sure we can guarantee that always to happen

What about using "LoadWith: LibStub" in LibraryLoader ?

Given all this should only happen in a disembedded environment, chances are LibStub is standalone and addons optdep it (or don't they ?)