ItemPrice-1.1 is a library containing vendor sell prices for items. Using the library is as simple as it can be; there is one method called GetPrice that takes either an itemId or an itemString as argument and returns the price as a number (amount of copper). Prices are mined from Blizzard's Armory and should therefor be fairly complete and accurate. If GetPrice returns 0 (zero), it indicates that the item has no sell price. If GetPrice returns nil, the item is unknown to the library.
ItemPrice-1.1 is a new version of ItemPrice-1.0. It now uses LibStub and has no other dependencies. It uses the same efficient storage technique as the old library.
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.
Is there a reason ItemPrice does not follow the Lib* naming convention?
Is it an agreed upon convention? I think it was only a suggestion that somebody made and was discussed a bit without any conclusions as such. I personally don't agree with such a naming scheme. So unless it has been decided that everybody should follow it, I prefer not to. :)
Anyway, the title shows up in the addon screen as "Lib: ItemPrice-1.1" because I believe that has been an agreed upon convention for some time.
I was just wondering, I don't intend to try and convince you one way or the other. I only noticed because when I went to install the new lib I tried "LibItemPrice-1.1" because I was expecting it to follow the pattern. Not a big deal. :)
I was not part of the discussion, but I assumed that anything using LibStub would follow the Lib* naming format. Best to ask though.
I think that if there is naming convention, it should be listed on www.wowwiki.com/LibStub which I assume is the official home of LibStub. It doesn't mention anything there. In fact, the short example uses a library named MyLibrary-1.0. :)
I don't like the idea of prefixing with Lib but I don't think it's a big deal either. So if a convention is made and everybody seems to follow it, I will do that too. Anyway, to my knowledge nobody uses this library but me. :D
any reason why you are using 9.9.9 for unavailable prices and not 255.255.255?
and wrt the GetSellValue API it's sad but I see the problem that could occure due to the hook chain and maybe ItemPrice-1.0 and such...
any reason why you are using 9.9.9 for unavailable prices and not 255.255.255?
and wrt the GetSellValue API it's sad but I see the problem that could occure due to the hook chain and maybe ItemPrice-1.0 and such...
The "fake price" can be anything really as it has no effect on the way you use the library. By choosing a lower number I cut the size of the file from 274 Kb to 238 Kb. I have a version at home where I used printable chars. This will cut it further down to 220 Kb. It's not really a big issue as it has no effect on the memory used. Still, a 20% file-size reduction with no additional runtime cost makes it worth doing. :P
About the GetSellValue API, remember that I am simply moving the responsibility of implementing this from the library to any addon using it. ItemPriceTooltip now implements that API directly. I think that's the right choice.
Bam, could you add "X-AceLibrary-ItemPrice-1.1: true" to the TOC, so that it will load when another addon needs it if it is disabled? Thanks,
I'm not completely sure what that does. Is it safe to add that considering that it does not use AceLibrary? As long as it has no bad side-effects, I don't mind adding it.
wrt byte size 9.9.9 and 255.255.255 should be of the same size, since you use 3 bytes per price.
and wrt the X-AceLibrary stuff I don't think you should add it. Any addon using th lib should list it as optional dependancy and in case someone has disabled the standalone version it shouldn't be loaded (that is code that should never have made it into Ace2...)
You are welcome. :) Hmm... now I wonder if there is a point to keeping support for ItemPriceTooltip... they are after all very similar.
Also, I should probably make the data-mining and compression code available somewhere again. Just in case I go "missing in action" some day. But I'm afraid it's a bit messy currently. :D
Quote from Elkano »
wrt byte size 9.9.9 and 255.255.255 should be of the same size, since you use 3 bytes per price.
Nah, in the file itself they are represented as "\9\9\9" and "\255\255\255" respectively. So there are 6 characters difference which does add up when it is repeated about 6000 times. :P
Quote from Elkano »
and wrt the X-AceLibrary stuff I don't think you should add it. Any addon using th lib should list it as optional dependancy and in case someone has disabled the standalone version it shouldn't be loaded (that is code that should never have made it into Ace2...)
I think I agree. Hmm... hard to please everybody. :-\
well, ok, ehrn it comes to filesize and loading it is larger but in memory it's the same. Also 9.9.9 corresponds to 59g21s37c, which could be a valid item price while 255.255.255, which would be 1677g72s15c hopefully wont.
well, ok, ehrn it comes to filesize and loading it is larger but in memory it's the same. Also 9.9.9 corresponds to 59g21s37c, which could be a valid item price while 255.255.255, which would be 1677g72s15c hopefully wont.
Yes, it's not a huge issue at all. We are probably talking about milliseconds faster loading time. You don't need to worry about the fake price clashing with a real price. My compression script will report an error if that happens. And then all I need to do is find another value - and there are plenty to choose from. :P
I'm not completely sure what that does. Is it safe to add that considering that it does not use AceLibrary? As long as it has no bad side-effects, I don't mind adding it.
Hmm, I haven't ever researched it.. I'll look into it and get back to you.
Hmm, I haven't ever researched it.. I'll look into it and get back to you.
AceLibrary uses the field to load up loadondemand addons.. That is all that the field does, so since it doesn't use acelibrary, it shouldn't be defined. Perhaps a LoadAddon call in the code of ItemPriceTooltip would be better.
The reason I am requesting this is simply because every week or so, I go back and disable all of the libraries that are listed in my addons, to minimize the memory footprint (I install and uninstall addons frequently to test features and report bugs in addons that I don't regularly use), and so I have a bunch of libraries that don't need to be loaded, because they are never used. ItemPrice-1.1 is used though, and so I would like to have it loaded if it is disabled.
AceLibrary uses the field to load up loadondemand addons.. That is all that the field does, so since it doesn't use acelibrary, it shouldn't be defined. Perhaps a LoadAddon call in the code of ItemPriceTooltip would be better.
Yes, I'd like to keep the library "clean" without any dependencies. Thus, any fancy enabling and loading should take place in the addon using it. I made a little utility function in ItemPriceTooltip that I think can be used to load a LibStub library in a similar way to how AceLibrary does this:
local function AceLibStub(major)
local lib, minor = LibStub:GetLibrary(major, true)
if lib then return lib, minor end
EnableAddOn(major)
LoadAddOn(major)
return LibStub:GetLibrary(major)
end
Pretty simple stuff. It appears to work. I will research a bit more and then add it to ItemPriceTooltip unless I find any issues.
And just so nobody is in doubt. No changes will be made to ItemPrice-1.1 regarding this issue. :)
ItemPrice-1.1 is a new version of ItemPrice-1.0. It now uses LibStub and has no other dependencies. It uses the same efficient storage technique as the old library.
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.
Is it an agreed upon convention? I think it was only a suggestion that somebody made and was discussed a bit without any conclusions as such. I personally don't agree with such a naming scheme. So unless it has been decided that everybody should follow it, I prefer not to. :)
Anyway, the title shows up in the addon screen as "Lib: ItemPrice-1.1" because I believe that has been an agreed upon convention for some time.
I think that if there is naming convention, it should be listed on www.wowwiki.com/LibStub which I assume is the official home of LibStub. It doesn't mention anything there. In fact, the short example uses a library named MyLibrary-1.0. :)
I don't like the idea of prefixing with Lib but I don't think it's a big deal either. So if a convention is made and everybody seems to follow it, I will do that too. Anyway, to my knowledge nobody uses this library but me. :D
and wrt the GetSellValue API it's sad but I see the problem that could occure due to the hook chain and maybe ItemPrice-1.0 and such...
The "fake price" can be anything really as it has no effect on the way you use the library. By choosing a lower number I cut the size of the file from 274 Kb to 238 Kb. I have a version at home where I used printable chars. This will cut it further down to 220 Kb. It's not really a big issue as it has no effect on the memory used. Still, a 20% file-size reduction with no additional runtime cost makes it worth doing. :P
About the GetSellValue API, remember that I am simply moving the responsibility of implementing this from the library to any addon using it. ItemPriceTooltip now implements that API directly. I think that's the right choice.
I'm not completely sure what that does. Is it safe to add that considering that it does not use AceLibrary? As long as it has no bad side-effects, I don't mind adding it.
and wrt the X-AceLibrary stuff I don't think you should add it. Any addon using th lib should list it as optional dependancy and in case someone has disabled the standalone version it shouldn't be loaded (that is code that should never have made it into Ace2...)
You are welcome. :) Hmm... now I wonder if there is a point to keeping support for ItemPriceTooltip... they are after all very similar.
Also, I should probably make the data-mining and compression code available somewhere again. Just in case I go "missing in action" some day. But I'm afraid it's a bit messy currently. :D
Nah, in the file itself they are represented as "\9\9\9" and "\255\255\255" respectively. So there are 6 characters difference which does add up when it is repeated about 6000 times. :P
I think I agree. Hmm... hard to please everybody. :-\
Yes, it's not a huge issue at all. We are probably talking about milliseconds faster loading time. You don't need to worry about the fake price clashing with a real price. My compression script will report an error if that happens. And then all I need to do is find another value - and there are plenty to choose from. :P
Hmm, I haven't ever researched it.. I'll look into it and get back to you.
AceLibrary uses the field to load up loadondemand addons.. That is all that the field does, so since it doesn't use acelibrary, it shouldn't be defined. Perhaps a LoadAddon call in the code of ItemPriceTooltip would be better.
The reason I am requesting this is simply because every week or so, I go back and disable all of the libraries that are listed in my addons, to minimize the memory footprint (I install and uninstall addons frequently to test features and report bugs in addons that I don't regularly use), and so I have a bunch of libraries that don't need to be loaded, because they are never used. ItemPrice-1.1 is used though, and so I would like to have it loaded if it is disabled.
Yes, I'd like to keep the library "clean" without any dependencies. Thus, any fancy enabling and loading should take place in the addon using it. I made a little utility function in ItemPriceTooltip that I think can be used to load a LibStub library in a similar way to how AceLibrary does this:
Pretty simple stuff. It appears to work. I will research a bit more and then add it to ItemPriceTooltip unless I find any issues.
And just so nobody is in doubt. No changes will be made to ItemPrice-1.1 regarding this issue. :)
/agree :P