Go to Page... |
Updated: | 12-02-11 03:04 PM |
Created: | 10-17-10 10:40 AM |
Downloads: | 19,189 |
Favorites: | 116 |
MD5: |
This fixes ItemRack to work with Cataclysm and contains important bug fixes and improvements.
Original version is here: ItemRack
12/9/11: All future updates will be back on the main addon page.
Comment Options |
bikikitty |
View Public Profile |
Send a private message to bikikitty |
Find More Posts by bikikitty |
Add bikikitty to Your Buddy List |
Dusk |
View Public Profile |
Send a private message to Dusk |
Find More Posts by Dusk |
Add Dusk to Your Buddy List |
merneith |
View Public Profile |
Send a private message to merneith |
Find More Posts by merneith |
Add merneith to Your Buddy List |
MaikuMori |
View Public Profile |
Send a private message to MaikuMori |
Find More Posts by MaikuMori |
Add MaikuMori to Your Buddy List |
01-23-11, 12:53 PM | ||
|
|
|
|
Kharthus |
View Public Profile |
Send a private message to Kharthus |
Find More Posts by Kharthus |
Add Kharthus to Your Buddy List |
01-23-11, 07:00 AM | |
|
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.
|
|
MaikuMori |
View Public Profile |
Send a private message to MaikuMori |
Find More Posts by MaikuMori |
Add MaikuMori to Your Buddy List |
01-23-11, 03:00 AM | |||
A Murloc Raider
Forum posts: 6
File comments: 34
Uploads: 0
|
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.
Chris White |
||
|
Yewbacca |
View Public Profile |
Send a private message to Yewbacca |
Find More Posts by Yewbacca |
Add Yewbacca to Your Buddy List |
01-22-11, 08:20 PM | |
|
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.
|
|
shinjuru |
View Public Profile |
Send a private message to shinjuru |
Find More Posts by shinjuru |
Add shinjuru to Your Buddy List |
01-22-11, 06:18 PM | |
|
Great updates Yewbacca.
Added you to the project. |
|
Kharthus |
View Public Profile |
Send a private message to Kharthus |
Find More Posts by Kharthus |
Add Kharthus to Your Buddy List |
01-18-11, 10:21 AM | |
A Murloc Raider
Forum posts: 6
File comments: 34
Uploads: 0
|
ItemRack 2.7
ItemRack 2.7
Internal Functions Added:
Bug Fixes/Improvements:
Net Result:
What about existing users?
Download Link:
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 |
|
Yewbacca |
View Public Profile |
Send a private message to Yewbacca |
Find More Posts by Yewbacca |
Add Yewbacca to Your Buddy List |
01-18-11, 02:56 AM | |
A Murloc Raider
Forum posts: 6
File comments: 34
Uploads: 0
|
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.
Last edited by Yewbacca : 01-18-11 at 09:17 AM.
|
|
Yewbacca |
View Public Profile |
Send a private message to Yewbacca |
Find More Posts by Yewbacca |
Add Yewbacca to Your Buddy List |
12-11-10, 05:21 AM | |
|
Thanks for rescue this Addon .......... and me ^^
Love it and cant play with outfitter or other Addons. ItemRack is the best |
|
Horlin |
View Public Profile |
Send a private message to Horlin |
Find More Posts by Horlin |
Add Horlin to Your Buddy List |
12-06-10, 08:21 PM | |
|
Have you tried just ItemRack and nothing else? Do you have a tooltip shown when the FPS drops? I've seen RatingsBuster kill FPS for some reason.
|
|
Kharthus |
View Public Profile |
Send a private message to Kharthus |
Find More Posts by Kharthus |
Add Kharthus to Your Buddy List |
12-06-10, 12:56 AM | ||
|
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 |
|
|
LonghornsER |
View Public Profile |
Send a private message to LonghornsER |
Find More Posts by LonghornsER |
Add LonghornsER to Your Buddy List |
11-18-10, 07:26 PM | |
A Kobold Labourer
Forum posts: 0
File comments: 1
Uploads: 0
|
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? |
|
GreyOsiris |
View Public Profile |
Send a private message to GreyOsiris |
Find More Posts by GreyOsiris |
Add GreyOsiris to Your Buddy List |