I liken automatic enabling of libraries to those damn iTunes services that keep on getting re enabled. Evil!
I would too, if it weren't _required_ for the addon to work.. But I liken putting a required dep as an optional dep to being in special ed.. If it's required, then the addon requiring it needs to tell you that you have disabled a depend, and if a library framework (ace3/libstub in this case) makes you put the reqdeps as optdeps, then the addon needs to work around it and automatically load the library.
I personally think that a disabled addon, even if it is a library, should never be enabled by another addon inorder to allow loading it.
A library should be defined as load-on-demand in its standalone toc and should be listed as optional dependancy by any addon using it. This way it will only be loaded in case an addon needs it.
I personally think that a disabled addon, even if it is a library, should never be enabled by another addon inorder to allow loading it.
A library should be defined as load-on-demand in its standalone toc and should be listed as optional dependancy by any addon using it. This way it will only be loaded in case an addon needs it.
But that DOESNT work.. ItemPrice-1.1 IS LOD in it's TOC, and IS listed as an optdep in ItemPriceTooltip's TOC, and it WILL NOT load, even if ItemPriceTooltip is enabled.
Speeddymon, for me everything works fine with the current setup.
Make sure that ItemPrice-1.1 isn't disabled and it should be loaded by WoW as soon as ItemPriceTooltip or any other addon listing the lib as OptDep is loaded.
The only difference between required dependencies and optional dependencies is that in the first case WoW will not load the addon if the dependency doesn't exist while it does in the 2nd case. When you run embedded the lib wont be there as seperate addon thus it has to be an optional dependenciy. But as with all dependencies WoW will load it before ItemPriceTooltip as long as it's not loaded yet and not disabled.
Load on demand will simply make WoW not load the addon if no other addon loading is listing it in its dependencies.
Ace2 currently will force enable even disabled Ace2 library standalones if they are requested so some people got used to simply disable all libs and have Ace2 reenable the needed ones thinking that this would safe them something. But that is wat LoD is for...
Speeddymon, for me everything works fine with the current setup.
Make sure that ItemPrice-1.1 isn't disabled and it should be loaded by WoW as soon as ItemPriceTooltip or any other addon listing the lib as OptDep is loaded.
The only difference between required dependencies and optional dependencies is that in the first case WoW will not load the addon if the dependency doesn't exist while it does in the 2nd case. When you run embedded the lib wont be there as seperate addon thus it has to be an optional dependenciy. But as with all dependencies WoW will load it before ItemPriceTooltip as long as it's not loaded yet and not disabled.
Load on demand will simply make WoW not load the addon if no other addon loading is listing it in its dependencies.
Ace2 currently will force enable even disabled Ace2 library standalones if they are requested so some people got used to simply disable all libs and have Ace2 reenable the needed ones thinking that this would safe them something. But that is wat LoD is for...
Ok, but that's just it.
LoD doesn't work properly.. I can disable all libs, and then let ace load the ones that are needed, and they use way less memory than if I keep them all enabled and let LoD do it's thing (about 1mb worth, just so you know)..
The main reason I disable the libs is not to save memory (i have 2gb worth, so it isnt a huge deal), it's because I want to know what libs WAU is saying I need, that I really don't. So far, I have about 15 libs that are not part of a package (ie not babble-* etc) that don't get enabled by ace, that are ace, because I don't need them.
Although FWIW, LoD even if it was working properly would still have to have part of each enabled addon loaded in memory so that it could load the rest of the code if needed, even if that part was just the toc metadata.
LoD doesn't work properly.. I can disable all libs, and then let ace load the ones that are needed, and they use way less memory than if I keep them all enabled and let LoD do it's thing (about 1mb worth, just so you know)..
[me=Tuller]wonders if that result is simply from a developer listing an optional dependency that's not used in the addon[/me]
Note, that unlike the old library ItemPrice-1.1 does not implement the GetSellValue API. I believe that the decision to support this API should be with the addons using the library.
Bad idea, IMO. ItemPrice is single source. Imagine 3 addons each implementing its own GetSellValue with IP as source. You'll have 2 extra links in hook chain that check exactly the same data. IP should provide its own GSV for its static data and addons can add more hooks in chain if they have any kind of dynamics built-in.
I think people looking at only ItemPrice's data is the exception, not the rule.
SellFish's GetSellValue implementation fills in any gaps in ItemPrice's data with items players have, and I'm pretty sure ItemPriceTooltip does this, too. We'd be hooking GetSellValue no matter what.
Yes. So, do you see that 2 addons already check IP data twice in hooks chain? Why not IP handle its own data by itself, leaving other addons to handle their dynamic data as they wish, without having to support exporting IP data as well?
The GetSellValue API demands that the call chain stop once a price is found. So the only situation where multiple checks could occur is when called with an item that none of the hooks know anything about. This should be rare. But even in that situation, nothing bad will happen except the call will take a little longer. Looking up a price is already fast and it's even faster when the price is not known.
Yeah, and using several tooltips or event handlers isn't that slow too, especially on newer PCs. Those miliseconds tends to add when functions are used inside loops. Mix another 100+ addons that are "just a little slower" than they could be and you'll get somewhat noticeable FPS drop.
Another point is that even if user gets ItemPrice, right now to use it along with any addon that uses generic GSV, user have to go and check out what IP using addon provides GSV functionality, even if that addon provides some other, unnecessary or even unwanted functionality. The most logical place for GSV, IMO is in same place where data set is stored/gathered.
Sadly, I have been unable to mine from the armory lately. For some reason the website becomes "busy" shortly after starting to mine prices. I hope this is not some deliberate action by Blizzard to prevent datamining. Anyone have more knowledge, please do share.
Edit: I was able to mine from the EU Armory. Quite strange because that one has always been problematic in the past. I will commit once servers are up and running again.
Ah, never mind. I found out how to mine the armory and reverse engineered the library, and have created a C# script to parse the xml files and generate the string. Can i take over the project and do the update somehow? It's still mining, and i don't think it will be done within the next couple of hours, but I'll be able to do the update by tomorrow.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I would too, if it weren't _required_ for the addon to work.. But I liken putting a required dep as an optional dep to being in special ed.. If it's required, then the addon requiring it needs to tell you that you have disabled a depend, and if a library framework (ace3/libstub in this case) makes you put the reqdeps as optdeps, then the addon needs to work around it and automatically load the library.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorA library should be defined as load-on-demand in its standalone toc and should be listed as optional dependancy by any addon using it. This way it will only be loaded in case an addon needs it.
But that DOESNT work.. ItemPrice-1.1 IS LOD in it's TOC, and IS listed as an optdep in ItemPriceTooltip's TOC, and it WILL NOT load, even if ItemPriceTooltip is enabled.
It has to work both with libraries embedded and standalone. That's why addons use optional dependencies for libraries.
Exactly. That's the unfortunate nature of the beast of using embedded libs. And it's exactly why I don't use embedded
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorMake sure that ItemPrice-1.1 isn't disabled and it should be loaded by WoW as soon as ItemPriceTooltip or any other addon listing the lib as OptDep is loaded.
The only difference between required dependencies and optional dependencies is that in the first case WoW will not load the addon if the dependency doesn't exist while it does in the 2nd case. When you run embedded the lib wont be there as seperate addon thus it has to be an optional dependenciy. But as with all dependencies WoW will load it before ItemPriceTooltip as long as it's not loaded yet and not disabled.
Load on demand will simply make WoW not load the addon if no other addon loading is listing it in its dependencies.
Ace2 currently will force enable even disabled Ace2 library standalones if they are requested so some people got used to simply disable all libs and have Ace2 reenable the needed ones thinking that this would safe them something. But that is wat LoD is for...
Ok, but that's just it.
LoD doesn't work properly.. I can disable all libs, and then let ace load the ones that are needed, and they use way less memory than if I keep them all enabled and let LoD do it's thing (about 1mb worth, just so you know)..
The main reason I disable the libs is not to save memory (i have 2gb worth, so it isnt a huge deal), it's because I want to know what libs WAU is saying I need, that I really don't. So far, I have about 15 libs that are not part of a package (ie not babble-* etc) that don't get enabled by ace, that are ace, because I don't need them.
Although FWIW, LoD even if it was working properly would still have to have part of each enabled addon loaded in memory so that it could load the rest of the code if needed, even if that part was just the toc metadata.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf that were the case, it would be the other way around.. LoD would use less than letting Ace enable the ones that are needed..
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBad idea, IMO. ItemPrice is single source. Imagine 3 addons each implementing its own GetSellValue with IP as source. You'll have 2 extra links in hook chain that check exactly the same data. IP should provide its own GSV for its static data and addons can add more hooks in chain if they have any kind of dynamics built-in.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSellFish's GetSellValue implementation fills in any gaps in ItemPrice's data with items players have, and I'm pretty sure ItemPriceTooltip does this, too. We'd be hooking GetSellValue no matter what.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAnother point is that even if user gets ItemPrice, right now to use it along with any addon that uses generic GSV, user have to go and check out what IP using addon provides GSV functionality, even if that addon provides some other, unnecessary or even unwanted functionality. The most logical place for GSV, IMO is in same place where data set is stored/gathered.
Edit: I was able to mine from the EU Armory. Quite strange because that one has always been problematic in the past. I will commit once servers are up and running again.