One thing I'd like to say, modules doesn't necessarily imply folders that the user can remove. Most of my code is modularized at least to the extent of seperate files for seperate functionality. I guess really classes is a more appropriate word for that. I honestly believe you should put PT in (I know I've said that a lot eh?), and that it should "just work" if PT is there, don't make it hard on the user. Nonetheless, if it were me I would call the PT code of the addon a class/module and I'd put them in a seperate file. It makes for easier maintenance and debugging, for example I can turn on AceDebug for PT's tradeskill module and I won't get debug messages for the core addon. It's really a design choice there I guess, I wrote PT so that it'll run fine if that module/class/whatever is removed, but it's generally intended to be there in the first place. That's what I try to strive for in the end with all my addons. Users can remove parts if they want and it should work fine, but I personally would want them to install the whole thing.
One thing I'd like to say, modules doesn't necessarily imply folders that the user can remove. Most of my code is modularized at least to the extent of seperate files for seperate functionality. I guess really classes is a more appropriate word for that. I honestly believe you should put PT in (I know I've said that a lot eh?), and that it should "just work" if PT is there, don't make it hard on the user. Nonetheless, if it were me I would call the PT code of the addon a class/module and I'd put them in a seperate file. It makes for easier maintenance and debugging, for example I can turn on AceDebug for PT's tradeskill module and I won't get debug messages for the core addon. It's really a design choice there I guess, I wrote PT so that it'll run fine if that module/class/whatever is removed, but it's generally intended to be there in the first place. That's what I try to strive for in the end with all my addons. Users can remove parts if they want and it should work fine, but I personally would want them to install the whole thing.
Well, every file is observably a memory waste. No idea what Blizzard does, but having two files with the same code makes the same mod significantly more wasteful of memory. At least, that was the case when I tested it. :)
It will work fine without PT, and the entire PT "module," as is right now, is roughly 8 lines of code, so I'm not worried 'bout providing it in a separate file. :) I'll keep you informed. Today'll be a busy day at work and at home for me, so I might not get this next release out 'til early next week. :/
Last I remember someone said there was a 100KiB overhead per addon, not per file. I've seen no significant change in Warmup between a single-file mod and a 10-file mod.
I gave Xelepart a teaser screenshot of all the changes I've been making last night, I suppose I can share it with ya'll too...
There are still several things I'm trying to formalize before I want to release this. It's finals week for me, so that might take a while (or maybe I'll keep putting off studying and keep working on this ::sigh::).
Heh, if you happen to see me when I'm on in the stormwind bank on the test server stop in and say hi.
I gave Xelepart a teaser screenshot of all the changes I've been making last night, I suppose I can share it with ya'll too...
There are still several things I'm trying to formalize before I want to release this. It's finals week for me, so that might take a while (or maybe I'll keep putting off studying and keep working on this ::sigh::).
Heh, if you happen to see me when I'm on in the stormwind bank on the test server stop in and say hi.
please o please put this new version you got for download before i drown in kitty slobber....
I've been working on this, and now that I've got SVN access to the new SVN I've got it put up there. The thing that's been keeping me is I broke Unsorted, and i'd really like to clean up a lot of configuration type stuff and add in a Periodic Table module and perhaps a ItemBar type thing to go with it. But for now, it's functional (I hope).
I opted to remove the AceInventory folder and just drop the addon into InvSort. So if you have an old version of AceInventory, you don't need it any more.
Beautiful! How bout a quick writeup on how to create our own categraies? Also just from a quick look, is there rules for "special" empties (shard bags, ammo bags, etc). Another thought, can the hover tooltip for a set show total item and slot counts as the first option so one could see at a glance, say, how many stacks of ammos they got?
AGain, beautiful. Just first glace it was 4 times more than I had expected...
Bind Types: BoE / BoU / Soulbound / Quest (yes quest items are a bind type!)
Equipment, by equip slot, by color, usable, not usable, by quality
Lockboxs and other "openable" items
Keys, Hearthstone!
Consumables (has "Use: " in the tooltip)
Everything else I can think of off the top of my head can be done with PT sets. I'll help make these rules if you can give me a good definition of a AceInventory.Inv entry... I can't for the life of me figger out what it's laid out like from the code.. damn metatables!
Bind Types: BoE / BoU / Soulbound / Quest (yes quest items are a bind type!)
Equipment, by equip slot, by color, usable, not usable, by quality
Lockboxs and other "openable" items
Keys, Hearthstone!
Consumables (has "Use: " in the tooltip)
The Bag types seem easy enough, keys and healthstone should be trivial. Consumable is a type returned by GetItemInfo, so that's easy as well.
The bind types seems a bit scary to me because it requires a tooltip scan to determine if an item is Soulbound, and that seems expensive. And it's also impossible for the KC_Bank data if you haven't visited the bank yet. I'll keep thinking about it.
Everything else I can think of off the top of my head can be done with PT sets. I'll help make these rules if you can give me a good definition of a AceInventory.Inv entry... I can't for the life of me figger out what it's laid out like from the code.. damn metatables!
Sure. The AceInventory.Inv table is indeed a bit of a nightmare to figure out ::blush::. I really probalby should implement it another way so I can test if it's worth using the crazy meta tables.
Anyways, all PT cares about is the Item ID yes? Each Inv item has Item.ItemID in the form "item:%d+:%d+:%d+:%d+" .
All the other fields are basically the information you can get from GetItemInfo: Name, Link, Rarity, MinLevel, Type, SubType, Stack (max stack size), Equip (location), Icon. In adition, there's also Bag, Slot, and Key, where key is the first number in the ItemID (/item:(%d+):/), and Index, where index is the Key in the Inv table (Inv[1].Index == 1, Inv[1001].Index = 1001). There are also flags for isBank and isEquipped.
The indexes correspond to which slots they're in. 1-16 are the backpack, 101-1XX is the first bag, 1001-1024 is the bank, 1101-11XX is the second bag, and 2001-2019 are equip slots. (I left off the ammo paperdoll slot from the equipment because it don't actually 'hold' the item)
I'll write up a more formal module dev doc soon.
My idea for the PT module was that it would let you register/unregister IS rules from PT groups. Every PT group's rule would be basically the same thing, just a simple check to see if an ItemID is in a PT group.
Bindtypes are twofold actually... Quest can be found from GetItemInfo but BoE/BoU/BoP/Soulbound can only be found out from the tooltip. If you have a hyperlink you can scan the tooltip and get that info there, if IS knows the bank links. I do agree that it is costly, but the information can be cached. The only drawback would be that unverified BoEs in the bank wouldn't show up as bound until the bank had been visited... but then does the mod even know about bank items if it's not visited? It had info for me and I logged in outside, pulls it from KCI doesn't it?
I agree completely on the PT idea. PTset == ISrule, plain and simple.
Yes, you metatable thing is insane, I guess I just need to know all the keys possible in the item that's passed in the rule def, and what possible values there are for each (or what API function they map directly to if that's the case)
Had another thought, the frame needs bag usage numbers somewhere, probably the bottom with the money display. Seperate out by type of course, like a Warlock Enchanter might have:
"Bag: 29/40 Soul: 20/20 Ench: 10/24"
Naturally this 'lock might actually have 25 shards, but since 5 are in a normal bag they add to that count.
Last comment... for the ammo rule can you make sure it sorts in the normal bag order? I think this is already the case but wanna make sure. It's annoying how partial stacks work out as a hunter, if I buy ammo I end up with a partial in what was the last free bagslot, but when I fire a shot it comes off the first stack the game finds (IE tho one at the top of the bag). It's nice to see visually where the partial is so I can move it to the top. EngInv was some random-ass order that was really annoying.... I should write a mod to push hunter ammo to the top on closing the merchant frame.... *ponder* .... no must sleep first!
Bindtypes are twofold actually... Quest can be found from GetItemInfo but BoE/BoU/BoP/Soulbound can only be found out from the tooltip. If you have a hyperlink you can scan the tooltip and get that info there, if IS knows the bank links. I do agree that it is costly, but the information can be cached. The only drawback would be that unverified BoEs in the bank wouldn't show up as bound until the bank had been visited... but then does the mod even know about bank items if it's not visited? It had info for me and I logged in outside, pulls it from KCI doesn't it?
I believe the "Soulbound" won't show up in the tooltip for the hyperlink, only when you call SetContainerItem, right? I did this a while back... AFAIK the only things that you can't get about an item without scanning the tooltip are Bound status, and who made the item if it's a crafted item. (These are things specific to the item, I'm not counting tihngs like armor and weapon stats) Perhaps we can ask for API for getting Soulbound/BoE/BoU/Quest?
The mod has no awareness of Bank items until you've visited the bank. If you visit the bank and leave, it will remember them until you log out. If however you have KC_Items, it loads the KC_Items data at login. (It's also set up so that it should be easy to switch KI_Items characters and view another players inventory,bank, and equipment. I'm hesitant to actually implement this option because I feel like it should also look up the characters InvSort profile and sort their inventory the way you'd see it on that character.
Had another thought, the frame needs bag usage numbers somewhere, probably the bottom with the money display. Seperate out by type of course, like a Warlock Enchanter might have:
"Bag: 29/40 Soul: 20/20 Ench: 10/24"
Naturally this 'lock might actually have 25 shards, but since 5 are in a normal bag they add to that count.
Hrm, interesting. However this seems a bit complicated by the fact that I don't note any real difference in Inventory/Bank Items. I suppose I could have the counts ignore bank slots when not at bank... And as bliz introduces more bag types (wtf is up with Engineering Bags at the AH?), this is gettin more and more complicated because all these items (Ammo, Shards, Herbs, Engineering stuff) can be put in regular bags as well. The bottom of the frame is gonna get filled up real quick.
Last comment... for the ammo rule can you make sure it sorts in the normal bag order? I think this is already the case but wanna make sure. It's annoying how partial stacks work out as a hunter, if I buy ammo I end up with a partial in what was the last free bagslot, but when I fire a shot it comes off the first stack the game finds (IE tho one at the top of the bag). It's nice to see visually where the partial is so I can move it to the top. EngInv was some random-ass order that was really annoying.... I should write a mod to push hunter ammo to the top on closing the merchant frame.... *ponder* .... no must sleep first!
Hrm. I think ammo is sorting in alphabetial order, so no, it's not how you're expecting it to be. I can change that. Something about that idea is bothering me... But I'll look into it. I'll try to get some more work on this by the end of the week, but my IRL responsibities seem to be adding up...
Soulbound could be guessed for bank items (BoP is obviously bound if you have the item) but maybe it's best to just ignore bank items for binding types. Still for the main bag this would be very handy for seperating "my equipment" from "crap I'll sell at the AH"
The summaries at the bottom should be for BAG TYPES not item types. A lock could have a 20-slot soul bag and 40 shards, but the bottom would still say "Soul: 20/20". I don't see this getting cluttered unless the player had a soul bag, a enchant bag, an herb bag, and an ammo bag... which makes no sense. I would wager that 95% of the time the most a player is gonna have is a class bag (ammo/soul) and a trade bag (herb/ench/engin?). Bank slots could be one lump sum "Bank:13/40" if the player wasn't at the bank. You could always give an option to disable the info display if the player think it's too cluttered.
As for the ammo sorting, I'd use PT if it's installed and sort by damage then in bag order, so the weakest ammo is at the top, but within each different kind of ammo it's sorted in the order it falls in the bags.
So I got two metatabley goodnesses for you to use with the PT module, I tihnk you'll like them. I'm using em in the ruleset I'm working on.
-- Allows for direct PT lookup using index
InvSortTek.PTLookup = {}
setmetatable(InvSortTek.PTLookup, {
__index = function(t, key)
return function(this, item)
return PeriodicTable:ItemInSet(item.Key, key)
end
end
})
-- Allows for direct sorting from PT using index
InvSortTek.PTSort = {}
setmetatable(InvSortTek.PTSort, {
__index = function(t, key)
return function(a, b)
return PeriodicTable:ItemInSet(a.Key, key) < PeriodicTable:ItemInSet(b.Key, key)
end
end
})
One thing I'd like to say, modules doesn't necessarily imply folders that the user can remove. Most of my code is modularized at least to the extent of seperate files for seperate functionality. I guess really classes is a more appropriate word for that. I honestly believe you should put PT in (I know I've said that a lot eh?), and that it should "just work" if PT is there, don't make it hard on the user. Nonetheless, if it were me I would call the PT code of the addon a class/module and I'd put them in a seperate file. It makes for easier maintenance and debugging, for example I can turn on AceDebug for PT's tradeskill module and I won't get debug messages for the core addon. It's really a design choice there I guess, I wrote PT so that it'll run fine if that module/class/whatever is removed, but it's generally intended to be there in the first place. That's what I try to strive for in the end with all my addons. Users can remove parts if they want and it should work fine, but I personally would want them to install the whole thing.
Well, every file is observably a memory waste. No idea what Blizzard does, but having two files with the same code makes the same mod significantly more wasteful of memory. At least, that was the case when I tested it. :)
It will work fine without PT, and the entire PT "module," as is right now, is roughly 8 lines of code, so I'm not worried 'bout providing it in a separate file. :) I'll keep you informed. Today'll be a busy day at work and at home for me, so I might not get this next release out 'til early next week. :/
-x
tekkub, I'm sending you a PM (just in case you don't check 'em :))
-x
Ok, I will keep checking back.
There are still several things I'm trying to formalize before I want to release this. It's finals week for me, so that might take a while (or maybe I'll keep putting off studying and keep working on this ::sigh::).
Heh, if you happen to see me when I'm on in the stormwind bank on the test server stop in and say hi.
please o please put this new version you got for download before i drown in kitty slobber....
Xelepart, got any progress on InvSort?
http://svn.wowace.com/dl.php?repname=Ace+SVN&path=%2Ftrunk%2FInvSort%2F&rev=0&isdir=1
I opted to remove the AceInventory folder and just drop the addon into InvSort. So if you have an old version of AceInventory, you don't need it any more.
Also, I have a little MyBags module here:
http://svn.wowace.com/dl.php?repname=Ace+SVN&path=%2Ftrunk%2FInvSortMyBags%2F&rev=0&isdir=1
To use it, type '/is mybags setup' and it will initialize all the rules/categorys etc.
AGain, beautiful. Just first glace it was 4 times more than I had expected...
Special Bags:
AmmoEmpty / EnchantBag / EnchantBagEmpty / HerbBag / HerbBagEmpty / ShardBag / ShardBagEmpty
Bind Types: BoE / BoU / Soulbound / Quest (yes quest items are a bind type!)
Equipment, by equip slot, by color, usable, not usable, by quality
Lockboxs and other "openable" items
Keys, Hearthstone!
Consumables (has "Use: " in the tooltip)
Everything else I can think of off the top of my head can be done with PT sets. I'll help make these rules if you can give me a good definition of a AceInventory.Inv entry... I can't for the life of me figger out what it's laid out like from the code.. damn metatables!
The Bag types seem easy enough, keys and healthstone should be trivial. Consumable is a type returned by GetItemInfo, so that's easy as well.
The bind types seems a bit scary to me because it requires a tooltip scan to determine if an item is Soulbound, and that seems expensive. And it's also impossible for the KC_Bank data if you haven't visited the bank yet. I'll keep thinking about it.
Sure. The AceInventory.Inv table is indeed a bit of a nightmare to figure out ::blush::. I really probalby should implement it another way so I can test if it's worth using the crazy meta tables.
Anyways, all PT cares about is the Item ID yes? Each Inv item has Item.ItemID in the form "item:%d+:%d+:%d+:%d+" .
All the other fields are basically the information you can get from GetItemInfo: Name, Link, Rarity, MinLevel, Type, SubType, Stack (max stack size), Equip (location), Icon. In adition, there's also Bag, Slot, and Key, where key is the first number in the ItemID (/item:(%d+):/), and Index, where index is the Key in the Inv table (Inv[1].Index == 1, Inv[1001].Index = 1001). There are also flags for isBank and isEquipped.
The indexes correspond to which slots they're in. 1-16 are the backpack, 101-1XX is the first bag, 1001-1024 is the bank, 1101-11XX is the second bag, and 2001-2019 are equip slots. (I left off the ammo paperdoll slot from the equipment because it don't actually 'hold' the item)
I'll write up a more formal module dev doc soon.
My idea for the PT module was that it would let you register/unregister IS rules from PT groups. Every PT group's rule would be basically the same thing, just a simple check to see if an ItemID is in a PT group.
I agree completely on the PT idea. PTset == ISrule, plain and simple.
Yes, you metatable thing is insane, I guess I just need to know all the keys possible in the item that's passed in the rule def, and what possible values there are for each (or what API function they map directly to if that's the case)
Had another thought, the frame needs bag usage numbers somewhere, probably the bottom with the money display. Seperate out by type of course, like a Warlock Enchanter might have:
"Bag: 29/40 Soul: 20/20 Ench: 10/24"
Naturally this 'lock might actually have 25 shards, but since 5 are in a normal bag they add to that count.
Last comment... for the ammo rule can you make sure it sorts in the normal bag order? I think this is already the case but wanna make sure. It's annoying how partial stacks work out as a hunter, if I buy ammo I end up with a partial in what was the last free bagslot, but when I fire a shot it comes off the first stack the game finds (IE tho one at the top of the bag). It's nice to see visually where the partial is so I can move it to the top. EngInv was some random-ass order that was really annoying.... I should write a mod to push hunter ammo to the top on closing the merchant frame.... *ponder* .... no must sleep first!
I believe the "Soulbound" won't show up in the tooltip for the hyperlink, only when you call SetContainerItem, right? I did this a while back... AFAIK the only things that you can't get about an item without scanning the tooltip are Bound status, and who made the item if it's a crafted item. (These are things specific to the item, I'm not counting tihngs like armor and weapon stats) Perhaps we can ask for API for getting Soulbound/BoE/BoU/Quest?
The mod has no awareness of Bank items until you've visited the bank. If you visit the bank and leave, it will remember them until you log out. If however you have KC_Items, it loads the KC_Items data at login. (It's also set up so that it should be easy to switch KI_Items characters and view another players inventory,bank, and equipment. I'm hesitant to actually implement this option because I feel like it should also look up the characters InvSort profile and sort their inventory the way you'd see it on that character.
Hrm, interesting. However this seems a bit complicated by the fact that I don't note any real difference in Inventory/Bank Items. I suppose I could have the counts ignore bank slots when not at bank... And as bliz introduces more bag types (wtf is up with Engineering Bags at the AH?), this is gettin more and more complicated because all these items (Ammo, Shards, Herbs, Engineering stuff) can be put in regular bags as well. The bottom of the frame is gonna get filled up real quick.
Hrm. I think ammo is sorting in alphabetial order, so no, it's not how you're expecting it to be. I can change that. Something about that idea is bothering me... But I'll look into it. I'll try to get some more work on this by the end of the week, but my IRL responsibities seem to be adding up...
The summaries at the bottom should be for BAG TYPES not item types. A lock could have a 20-slot soul bag and 40 shards, but the bottom would still say "Soul: 20/20". I don't see this getting cluttered unless the player had a soul bag, a enchant bag, an herb bag, and an ammo bag... which makes no sense. I would wager that 95% of the time the most a player is gonna have is a class bag (ammo/soul) and a trade bag (herb/ench/engin?). Bank slots could be one lump sum "Bank:13/40" if the player wasn't at the bank. You could always give an option to disable the info display if the player think it's too cluttered.
As for the ammo sorting, I'd use PT if it's installed and sort by damage then in bag order, so the weakest ammo is at the top, but within each different kind of ammo it's sorted in the order it falls in the bags.
Absoultely required fields are name and the contains function.
So I got two metatabley goodnesses for you to use with the PT module, I tihnk you'll like them. I'm using em in the ruleset I'm working on.
-- Allows for direct PT lookup using index InvSortTek.PTLookup = {} setmetatable(InvSortTek.PTLookup, { __index = function(t, key) return function(this, item) return PeriodicTable:ItemInSet(item.Key, key) end end }) -- Allows for direct sorting from PT using index InvSortTek.PTSort = {} setmetatable(InvSortTek.PTSort, { __index = function(t, key) return function(a, b) return PeriodicTable:ItemInSet(a.Key, key) < PeriodicTable:ItemInSet(b.Key, key) end end })And a sample set that's using these tables:
{ name = "TekWater", icon ="Interface\\Icons\\INV_Drink_18", sort = InvSortTek.PTSort.waterall, contains = InvSortTek.PTLookup.waterall, },