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.

More to add.

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.

The FrameXML.Log also records a "null" entry where it would appear that an Add-On should be loading on demand.

10/10 16:40:55.390 Loading add-on Baggins
10/10 16:40:55.390 ** Loading table of contents Interface\AddOns\Baggins\Baggins.toc
10/10 16:40:55.390 (null)

Bumping back to page 1. This needs fixed before 3.0 goes live!

Given the widespread use of embedded libraries and LoD addons, I would {hope, expect, think} that this would qualify for a high-priority patch. I remember a Blue saying that the .1 patches were reserved for just such things, so if 3.0 goes live with this bug, perhaps a 3.0.1 could fix it.

---

Q u o t e:
Given the widespread use of embedded libraries and LoD addons, I would {hope, expect, think} that this would qualify for a high-priority patch. I remember a Blue saying that the .1 patches were reserved for just such things, so if 3.0 goes live with this bug, perhaps a 3.0.1 could fix it.

---

The pre-download patch states 3.0.2 already. :P

I'll go ahead and say 3.0.3 will be released before Wrath goes live though (early Nov release), just like 2.0.3 went live right before TBC release date.

---

Q u o t e:
This is fixed for 3.0.3!

---

Thank you Zootfizzle!

---

Q u o t e:
This is fixed for 3.0.3!

---

Hi. we verified that ## OptionalDeps: is indeed fixed for 3.0.3

However, RequiredDeps/Dependencies is not. If AddonA is kept the same as in the zip file (meaning it is still LoD), but AddonB's "OptionalDeps" is changed to either "RequiredDeps" or "Dependencies" to depend on AddonA, then neither A or B will load. That is, the problem in post #0 is fixed, but the problem in post #1 is not.

This is with both A and B enabled of course.