memory usage is to the roof again
using AtlasLoot 5.08.06 and AL Reverse memory usage is almost 10 MB

please update for zhTW!! thanks a lot!!

Hi! Nice addon xD
Could you make it so that tier items show who drops the token they're changed for? Thanks.

Edit: It seems t7 and forward do this already. Any chance to be fixed for older tiers?

Hi,

On my shaman I'm getting this errors in taint.log when I try to change the totems in my totem-bar, while in combat:

Could you please take a look when you have some time (if you need me to generate some more logs, please let me know).

Edit: please ignore did a new set of tests today (after posting the message ) and can't reproduce it anymore.

Any update for this UI coming anytime soon? There are many wrong locations for items from the last patch that have not been corrected. I was wondering if anything was in the works to be released soon?

Wow, good to know I'm not the only one AnrDaemon likes to pick fights with in addon comment sections lol.

<3 BugSack

Your opinion. My experience--in 4 years of extensive mod testing--is that "conflicts with other mods" is a cause of a small minority of bugs I have seen overall. But if you personally want an addons list (which I've already mentioned) in addition to the stack trace regardless, fine.

"Suppressing consecutive errors"--what? Do you mean "Each error will only be displayed once per session, so that the interface will not be clouded by continual notifications if one error continually occurs." (from this page)? Same thing that BugSack/!BugGrabber does; it reports the error once and adds additional copies of the error to its ongoing tally without further alerts.

It also allows you to throttle identical errors that flood (i.e. 100 repeats of the same error in 1 second, etc.), which Swatter doesn't allow. As well, it provides more flexible display options; it provides a tally of errors in a LDB display or minimap icon that can be accessed through there, as opposed to command line commands. Its "error window"--similar to Swatter's--can be accessed on demand there. You can have sounds happen when errors occur. And finally you can limit the number of errors it records in !BugGrabber's saved variables file.

Again, if you choose to use BugSack/!BugGrabber instead of !Swatter, there is really no need to insist to use the other one instead. Whatever floats your boat; the AtlasLootReverse comments isn't the place to debate the merits of the two.

Swatter does the same with an added advantage of suppressing consecutive errors and providing additional information related to error, such as addons list, which in many cases more useful in traching error origin than backtrace itself.

The visible issue is the bug(s) thrown up. And...seeing as I use BugSack/!BugGrabber for testing so I don't have to use Swatter, your last "advice" is going to be a bit tough . As they offer very similar error stack traces, you aren't missing anything (other than the list of mods running at the same time) using BugSack/!BugGrabber.

It is known, yet unresolved issue with newest versions of LibExtra.
That not causing any visible issues as I can tell so far.

P.S.
It's advisable to copy error directly from Swatter frame (and use it instead of BugSack or any other error-catching addon)

Received this error disenchanting something with AtlasLootReverse (ALR) v1.6, AtlasLoot v5.07.05, Auctioneer Suite v5.6.4399a, USEnglish client/server, WoW 3.2.0a live:

["message"] = "Enchantrix-5.6.4399.4389\\EnxTooltip.lua:694: attempt to index local 'link' (a nil value)\n...ns\\AtlasLootReverse\\libs\\LibExtraTip\\LibExtraTip.lua:95: in function <...ns\\AtlasLootReverse\\libs\\LibExtraTip\\LibExtraTip.lua:80>:\n...ns\\AtlasLootReverse\\libs\\LibExtraTip\\LibExtraTip.lua:167: in function `h':\n...ns\\AtlasLootReverse\\libs\\LibExtraTip\\LibExtraTip.lua:322: in function <...ns\\AtlasLootReverse\\libs\\LibExtraTip\\LibExtraTip.lua:318>:\n<in C code>: ?\nAceHook-3.0-5 (Ace3):92: in function <Interface\\AddOns\\Ace3\\AceHook-3.0\\AceHook-3.0.lua:84>\n<in C code>: ?\n<in C code>: in function `SetAction'\nInterface\\FrameXML\\ActionButton.lua:430: in function `ActionButton_SetTooltip':\n<string>:\"*:OnEnter\":1: in function <[string \"*:OnEnter\"]:1>\n\n ---",
["type"] = "error",
["session"] = 1347,
["counter"] = 5

The version of LibExtraTip used in that version of Auctioneer (its a beta, yet is on the site here as a release) that was put out after v1.6 of ALR is "1, 224". You include LibExtraTip "1, 218". I have only "1, 224" loading here; replaced what was included in ALR's ZIP with the Auctioneer one.

Before replacing ALR's LibExtraTip with the latest v224, I left its original v218 alone and used v224 in Auctioneer only. Here is the error thrown in that situation:

["message"] = "...ns\\AtlasLootReverse\\libs\\LibExtraTip\\LibExtraTip.lua:579: attempt to call a table value:\nAuc-Advanced-5.6.4399 (KangaII)\\Libs\\LibExtraTip\\LibExtraTip.lua:38: in main chunk\n\n ---",
["type"] = "error",
["session"] = 1282,
["counter"] = 1

No errors with the earlier Auctioneer release v5.5.4293 that included LibExtraTip "1, 208". Other options besides ALR modifications to accommodate the new LibExtraTip include changing to LibTipHooker-1.1. Or--much better--put the ALR info directly in the tooltip without a hooking library, like Tekkub's Engravings (and other mods) do.

I thought it seemed like ALR used an unreasonable amount of memory for what it actually did. Thanks for the update.