ItemRack - Cataclysm 

It works fine except one question: if I create a new character, he would be unable to use the slot key binding function(the option grey out).

While cooking I got this:

I was wearing the chef's hat (though it's not part of a set) and I'm using Quartz to consolidate profession crafting.

Thanks for continuing the good work on this project! It's still my favorite EQ mod.

Feature request: Would you consider adding native LDB support, please, for swapping the sets?

Just switching between sets doesn't seem to use that option as in the helmet/cloak state doesn't change. It remains as it was before.

Maybe it's some other addon interfering (Using MadHatter), I'll try to debug it when I have time. It could also be something with corrupt saved data. I haven't cleared WTF for ages and I'm long time ItemRack user.

A very minor bug, the auto hide/show helm and cloak when switching sets doesn't seem to work. I haven't checked out the newest upgrade, but I figured I drop this down before I forget about it again.

Thanks Khartus.

Now either of us can release fixes when needed. Good stuff. This is definitely the type of addon that requires maintainers with some insight into it. I spent 4 hours coding the update, where 3 hours and 40 minutes of that was just reading and backtracking through all the old, messy code to analyze what it does, and I'm NOT exaggerating, that is really what happened. I first did a broad sweep based on functions like string.match/gsub/find to locate points that needed changing right away, then I did a slow pass through every single file, making sure I understood the amazingly messy code and all its interlinked dependencies and lack of consistent function/variable naming for related concepts, and that way I caught the remaining places that needed updating, and cleaned up some other code in the process. That was the bulk of the time it took to implement the fixes.

ItemRack could do with a complete rewrite into a modularized, object oriented format, but heck no, that'll take way too much time and the time such a rewrite would save in future ease of maintainability is not worth the initial investment of countless hours doing the rewrite. It works now, it's been updated to fix all serious bugs, and we'll be able to quite easily fix other things if problems arise. The hardest part, ItemString handling, has been modularized and will never plague us again since the two conversion handlers have been so isolated that they can be rewritten and made to do any magic we want without ever having to touch code outside of those two functions.

I'll be ready to jump in and fix things if I start seeing Lua errors pop up during some future WoW patch, since I depend on ItemRack for all my set-handling needs. It'll depend on which one of us is active first at the time that happens.


Ditto. ItemRack is easily the best equipment set handling program. The event-based swapping (with smart queue in case you were in combat when swapping), the beautiful and easy-to-use GUI, the LDB/Fubar support - it's superb. As for your request... I agree, it's non-standard to have the actual addon folders under a parent folder, and can easily confuse the people that will just drop in the parent folder without ever seeing that it has subfolders. Let's change that to the standard way of having the addon folders directly under the zip file. I'll upload a modified 2.7 zip now, with the real addon folders moved out to top-level, so that they can just be dropped into your AddOns folder without issue.


Chris White

I love this add-on and have for a long time. Thank you to those of you involved in this project. Just a minor detail, but perhaps the parent folder containing ItemRack and ItemRackOptions should be removed.

ItemRack 2.7

Internal Functions Added:

• ItemRack.GetIRString(): Handles various conversions from itemlink/itemstring to itemrackID, and from either of those two formats (itemlink/itemstring OR itemrackID) into baseID, using consolidated patterns
• ItemRack.UpdateIRString(): Takes an itemrackID and updates the player LEVEL in it, which ensures that outdated itemrackIDs created when the player was lower level can be kept fully up to date in a breeze
• ItemRack.IRStringToItemString(): Converts an itemrackID back into a regular itemstring, for when we need to create tooltips or look up item data using the WoW API and so on

Bug Fixes/Improvements:

• Created new consolidated patterns for ItemLink/ItemString-to-ItemRackStyleID, ItemRackStyleID-to-BaseID, ItemLink/ItemString-to-BaseID
• Created new functions that use those patterns, and various other new helper functions, in order to consolidate all ItemString-handling in one place
• Replaced all old-style handling of itemIDs (string.gsub/find/match) and made everything use the new functions instead, for more robust handling as well as easy updates in the future
• Replaced GUI drawing code with references to new functions, to get icons and tooltips to work in the GUI
• Updated the GUI code so that it always draws item tooltips using the player's current level, which ensures that mousing over heirlooms in saved sets will actually show their stats for your CURRENT level (the old code set all levels to 0 which made it so the stats were shown incorrectly as level 1)
• Improved the two functions that actually LOCATE the stored equipment set items inside the player's inventory/equipment/bank (whether it's for equipping, or simply displaying a tooltip), by making sure those functions pass the INCOMING ID through the new level updater (UpdateIRString) to ensure all old Item IDs are up to date, thus fixing the bug where leveling up would cause ItemRack to fail strict item search on all saved sets and resort to any-item-with-the-same-baseID; this injection point was chosen because it fixes the problem completely throughout the board, since everything that locates items relies on the item finding functions
• Updated the functions for getting info for an item (GetInfoByID), posting an itemlink to the chatbox when shift clicking an item in ItemRack's GUI (ChatLinkID), and the function for showing an item in a tooltip, so that they all pass the incoming ID through the level updater (UpdateIRString) in order to work with up-to-date information, since it's important that stats are correct whether it's for posting chat links or looking at a tooltip's stats
• Commented and cleaned up terrible code here and there, as I untangled the messy code (minor changes)

Net Result:

• VERY easy to update itemstring format in the future, if Blizzard ever adds more fields to their ItemString format, as ALL of the heavy work has been done and updating the format is now as simple as changing the behavior of two easy-to-understand functions that convert into and out of ItemRack ID format.
• Will actually ACCURATELY match items REGARDLESS of what level your player was when saving the set, instead of working with an outdated saved ID which would lead to it failing to find an exact match and resorting to loose baseID matching (which was terrible if you had duplicates of an item, as loose matching meant it could just as easily match a duplicate rather than the item you really wanted to equip)
• Now supports REFORGED ITEMS, meaning you can have several duplicates of an item, all reforged in different ways, and it will know the difference between them and equip the proper ones for each saved set
• Tooltips for stored sets now show item stats using your current level rather than the level you were when you saved the set, this means all your heirlooms will show proper, up-to-date stats at last
• Smaller under the hood fixes and cleanups

What about existing users?

• No problem! Your old ItemRack sets are readable by this new release, but it will read the old sets in baseID mode (loose matching) since the old, stored ItemStrings use a bad, bugged ItemString format. All you have to do is install the update and keep using your sets as usual. In case you had multiple duplicate items of the same base item you'll have to make sure each set points to the correct copy of the item and then re-save the sets. From this point on they will always point to the EXACT item, instead of the old bugged behavior, as the stored item references will be updated.

Download Link:

• http://www.pulseforce.com/node/ItemRack-2.7.zip (contains 2.65, 2.7 and the updates between 2.65 and 2.7; users should use the version in the folder called "2.7 Full", the others are there for the benefit of Khartus)

Khartus:
Grab 2.7 above and upload it to this addon's repository. Add me as co-maintainer of this addon if possible. You'll also want to improve the description from "ItemRack - 4.0.1 patch: This fixes ItemRack to work with WoW 4.0.1 until Gello returns." to something like "ItemRack - Cataclysm: This fixes ItemRack to work with Cataclysm and contains important bug fixes and improvements.", since Gello shows zero signs of coming back.


This fixes all serious bugs and breathes new life into ItemRack with a much more robust item storage system.

Chris White

Found a super annoying bug:

ItemRack stores the itemString for each item you add to a set, but the Lua pattern it uses to match the itemString captures all fields EXCEPT the newly added reforgeId field:

http://www.wowwiki.com/ItemString

As you see, the reforgeId was tacked onto the end, but since ItemRack hardcodes its item matching to a grabbing every field EXCEPT the last one (which USED to be player level), it will store references WITHOUT the reforgeId, so if you have 2 unenchanted/ungemmed items, and reforge both in different ways, it will not see the difference between them. This is a real problem if you have 2 copies of an item, each reforged for a different spec. Upon equip, it will not be able to distinguish between them and you will not be guaranteed that it has equipped the correct one.

Example, Gift of Nadun Neck in DPS set (reforged for Hit):
"62447:0:0:0:0:0:0:0:85"
Gift of Nadun in Tank set (reforged for Expertise):
"62447:0:0:0:0:0:0:0:85"

Let me try to find the lines that need to be changed, hold on...

Edit: Okay. This is going to require an extensive rewrite of how itemLinks are handled and parsed for itemStrings:

An example is line 447 of ItemRack.lua:
return string.match(itemLink or "","item.+):%-?%d+") or 0

This pattern captures "62447:0:0:0:0:0:0:0:85" out of an itemString that is "62447:0:0:0:0:0:0:0:85:153".

There are MULTIPLE problem areas with this pattern, it is very bad:
First off, it includes the LEVEL of the person viewing the item (in this case 85), which will cause "strict" matching to fail for saved sets WHENEVER the set owner levels up. Example: Let's say I am level 84, I have two nearly identical items with different GEMS. I save a set with one of them, let's say the itemLink is THEITEM:THEGEM:84. I ding 85. If I then try to equip that STORED set, it will first try the STRICT matching and of course will no longer find THEITEM:THEGEM:84 since I am now level 85. It then resorts to LOOSE matching which may get the wrong item. This bug is NEWLY caused by Blizzard tacking on reforgeId at the END of the itemString, which is a VERY stupid thing they did... they should have tacked it on BEFORE the player level. Due to the itemString no longer ending in playerLevel, what happens is that itemRack will now INCLUDE playerLevel in comparison, but SKIP reforgeID since the latter is at the end and gets thrown away. Sigh.

Secondly, of course, it misses the reforgeId completely, for the reason above (throwing away the last field).

However, it is NOT as simple as just rewriting THAT pattern. ItemRack is stupidly PEPPERED with VARIATIONS of that pattern. Search the code for "string.match" and you will see what I mean. There are a large amount of variations.

What needs to be done:
- Write 2 patterns. 1: One STRICT pattern that grabs an item and takes everything EXCEPT the level of the observer, in order to not break strict matching after the owner levels up. 2: One LOOSE pattern that only looks at the itemId.
- Save those 2 patterns as variables under the ItemRack table so they can be reused everywhere, instead of having loads of ascii copies of the pattern in loads of places, since that leads to bugs (if you forget to change some of them) as well as more work when the patterns need changing.
- Update EVERY location that USED to match using directly typed patterns, and make them use either the STRICT or the LOOSE pattern based on the need of that particular function/feature.

I will now get on writing the patterns, hold on...

Edit: ItemRack has some of the worst, least maintainable code I have ever seen, with code blocks repeated everywhere instead of being reusable, almost zero modularization, laughably inconsistently named functions and variable names (for instance, the same concept used in multiple places, such as the concept of a baseID, may be named: id, baseid, linkid, itemid, etc etc etc, there is ZERO consistency among related concepts), and a fucking rats nest of interlinked code. Bad, bad stuff. I initially wrote a pattern and a couple of itemLink-to-itemRackID and comparison functions, which generated a new type of itemString in this format:
"i:62384:0:4041:4041:0:0:0:0:146", or in other words "i:itemID:enchantID:jewelID1:jewelID2:jewelID3:jewelID4:suffixID:uniqueID:reforgeID" (basically itemString as of Cataclysm, with the 9th field containing :XX playerlevel completely removed, and the prefix "i:" instead of "item:", to distinguish them from normal itemStrings)

Well. Due to the god-awful and unmaintainable code of ItemRack, integration of the above would require massive changes to the ItemRack Display GUI; it needs normal itemStrings everywhere that it displays items from a set, which is EASY to get from the above specialized itemString, but would involve LOTS of work hunting down WHERE we need to implement conversion in the huge nest of source files and interlinked functions.

There are now two paths to take:

The lazy path would be to implement some pattern updates to catch the reforgeId AND level and just call it a day, despite this causing the BIG bug of "oops, I dinged, I guess itemRack can't find ANY of my items using strict matching anymore".
Pros:
* reforged items will be properly saved
Cons:
* item sets are crippled and may break every time you level up, as stored itemStrings will contain an outdated player level, which in turn blows up all comparisons and forces ItemRack item finding to resort to LOOSE comparison (which cares ONLY about item ID and ignores EVERYTHING else like enchants, gems, suffix "of the X", reforge, etc).
* when hovering over items in a stored set, if you hover over heirlooms they will show stats relative to the level you were when you SAVED the set, for instance if you were level 69 and saved a set with a heirloom in it, then later ding 85 and look at that same item set (if you have not re-saved it since then), it will actually show level 69 stats for that item in the tooltip due to the outdated stored level.

I have an idea for a different workaround though... one that says "screw that" to fixing the MESS of old code, while still implementing reforge support AND making sure it matches level changes from stored sets properly.

Edit: Made good progress on the update.

I wrote a strict pattern which grabs the ENTIRE WoW-style itemString minus the "item:" part, and two LOOSE patterns meant to be used on ItemRack-style itemStrings (meaning ones lacking "item:") and regular regular itemStrings/itemLinks, which returns the itemIDs from said links (for loose comparison).

I put these three patterns in a SINGLE function which takes an itemLink/WoW-style itemString and returns an ItemRack-style itemString (lacking "item:") or takes an ItemRack-style itemString or a regular itemLink/itemString and returns a LOOSE itemID (just the baseID).

I also wrote a function that takes an ItemRack-style itemString and UPDATES the STORED level, so for instance, let's say you stored a set when you were level 69 and ended up with:
62447:0:0:0:0:0:0:0:69:153
Passing that through the Update function would return:
62447:0:0:0:0:0:0:0:85:153
This makes it possible to look in the player's inventory/bank/equipped gear for items using STRICT matching, WHILE originally having stored an OUTDATED strict itemLink (with an outdated level). This was not possible using the old, broken code, and resulted in it resorting to LOOSE baseID matching.

The third new function is one that converts an ItemRack-style itemString into a regular ItemString, so that there is only a single place to update in case the format has to change more drastically in the future.

What needs to be done now to implement these functions:
* everywhere that itemrack uses fixed strings to process itemlinks/itemstrings will have to be changed to instead use the function that consolidates all the work for you
* all code that processes SAVED itemrack IDs will have to be updated to run EVERY stored ID through the Update function, before using them, so that the IDs will be brought up to date even if the player is loading an old set. this will fix STRICT item searching.

What this fixes:
* reforge IDs will now properly be found, so your reforged items will actually be differentiated
* as little as possible of ItemRack's code will have to be changed
* while investigating how ItemRack handles tooltips (to see if it appends level or something else to create proper tooltips), I noticed that it has bad tooltip handling, which will need rewriting to properly show reforged items, stats on heirlooms relative to current player level, etc. I will fix this as well.
* if you store a set and later ding, you will no longer screw up your itemrack sets.

I was going to submit the patch as a comment, but since ItemRack is so mindboggingly badly coded it will require extensive surgery. This means I will instead use the latest release version from this page, make all changes, and hand you the changed files in their entirety. You can use your own diff tools if you want to see changes.

Thanks for rescue this Addon .......... and me ^^

Love it and cant play with outfitter or other Addons. ItemRack is the best

`

Sorry for this late reaction : Your FPS hase to do with your Video Setup, unless it's a UI Addon, addons has nothing to do with your FPS.
Check your settings mate, they changed a lot of that by Blizz.

The FPS can only drop maybe if you show the setup pannel, but from 30 to 9 is a BIT high change.

Regards

I'm just now getting back into wow, and i used to love itemrack. so much better than the equipment manager. But i'm having a bit of a hiccup with it now. If i have itemrack disabled, i get well over 30fps. If i enable it, i drop to around 9fps, and the action bars will stop working.

I extracted the patch into the interface folder. Any ideas as to what is causing these problems?