20 - Please bring back filtering of taint errors. As well as a larger maximum saved bug LUA limit.

What is the enhancement in mind? How should it look and feel?

Don't know if these were temporary omissions after the rewrite, but wanted to bring it up before it goes to release.

First request is to bring back the "Filter Addon Mistakes" option of r247 & earlier. For those who use Blizzard's built in taint logging, having this record taint errors by default (with no way of changing it) is a really serious crimp in usability. So much so that for many, it will eliminate further usage of the mod.

First problem is trying to find actual mod errors spread among recorded taint. The more serious problem is the historical nature of taint errors. More often than not, something tainting spews a large number of such errors. Up to hundreds at a single time. Something much better left to Blizzard's built in taint.log rather than filling up the BugGrabber saved variables.

Certainly there may be some that prefer having taint errors recorded along with mod errors in the BugGrabber LUA. Leave the option for them. But for others (and I've talked to a few others as well), please have the option to disable taint recording put back in.

Second request is to put back the variable option of how many maximum errors to record in the BugGrabber saved variables before the oldest ones are deleted. In the new rewritten version, it seems to be hardcoded at 50 (based on a single usage). If it is actually 50, that's not enough. The former r247 maximum of 1000 was fabulous if you wanted a historical record of the bugginess of a particular mod. And when bugs happened to what. And so on.

User When Change
funkydude Oct 29, 2013 at 00:04 UTC Changed status from New to Invalid
Zidomo Mar 27, 2011 at 13:51 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of Rabbit Rabbit Aug 21, 2011 at 08:10 UTC - 0 likes

    Yeah, yeah. This has been changed back to 1000 in the latest alpha since almost the day he filed the ticket.

  • Avatar of Zista Zista Aug 21, 2011 at 04:24 UTC - 0 likes

    I would have to agree with Zidomo about the number of bugs. Sometimes when testing some changes I made to my addon, I can easily get a few hundred errors because the first error occurred in a file that handles things for the rest. Having it start to overwrite errors after 50 causes the first error to be removed and I have to disable BugSack to see what the error was and where it occurred.


  • Avatar of marblex marblex Aug 20, 2011 at 16:52 UTC - 0 likes

    Using the August release, of bug grabber! when I click on BugSack now it fails to open, although the grabber is definitely reporting errors.

    Should I be using an earlier version of both? Thanks for the great addon :D

  • Avatar of Ant1dotE Ant1dotE May 27, 2011 at 21:57 UTC - 0 likes

    here is bugsack report: :)

    1x BugSack-r253\sack.lua:141: attempt to call method "GetName" (a nil value)
    BugSack-r253\sack.lua:141: in function <BugSack\sack.lua:131>
    BugSack-r253\sack.lua:146: in function <BugSack\sack.lua:145>
    setActiveMethod = <func> @BugSack\sack.lua:131
  • Avatar of Rabbit Rabbit Mar 28, 2011 at 07:12 UTC - 0 likes

    I think you just convinced me to add search capabilities to BugSack, much like Bagnon has. Don't have time to discuss more now, but thank you for being thorough!

  • Avatar of Zidomo Zidomo Mar 28, 2011 at 02:28 UTC - 0 likes

    You mean the one about BigWigs long in the past? You misunderstand my intention, sorry. Its not a if-you-don't-do-this "threat". Its to emphasize the scale of the problem.

    Its not just my desire, its a matter-of-fact forwarding of information after consulting here. Consulting with a couple other authors I know and several tester personal friends. I ask what they think of the change(s) in a particular build, combined with what I think of them. If its either a unanimous decision or a large majority, I bring it forward (i.e. "...for many...", etc.). As can then extend that to the rest of the user base if you choose to. Its not a "threat", as I know authors don't care about that...heh.

    In terms of choosing bug numbers to keep, a few things. First its much (much) more convenient tracking the historical bugginess of a particular mod doing searches on a limited number of saved variables vs. a giant number of them. The smaller the maximum number of bugs saved is, the more files you have to search. And depending how you save them (ZIP/GZIP, etc.) and the tools you prefer to use, you may have to open the files to get the bug details. The more files you have to open in an editor and/or have to look through, the more increasing hassle & time consuming it is.

    Related to that, you may want to see if a mod has been buggy in the past before testing new versions of that mod. The hassle/time consumption of picking out individual bug reports is also increased substantially when you have a low maximum number.

    And if you are ongoing testing a particular mod, its important - - if a particular error comes up - - whether that error has been seen in the past with that mod. As above, the more files you have to search with a low number of saved bugs, the more time consuming & hassle it is. The time spent increases geometrically.

    Finally, it appears that providing a selectable bugs-saved slider is only 12 lines of code or so. Not a lot. Then again, its not something that is changed often. So for even less code to handle it if you don't want the slider, make it a command line option instead?

    On the other hand, I very rarely send or receive bugs using the AceComm communication feature (as I do most of my main mod testing on a secondary server). So here, that feature wouldn't be a problem to be eliminated. But I know some do make use of it. So no problems at all keeping it in. Keeping options open for things that add convenience to a number of users.

    So hope some method of adjusting saved bug numbers can be implemented.

    Last edited Mar 28, 2011 by Zidomo
  • Avatar of Rabbit Rabbit Mar 27, 2011 at 21:23 UTC - 0 likes

    If I remember correctly, this is the 3rd ticket I've seen where you threaten to stop using an addon if I don't fix something.

    Are you mediterranean or eastern european?

    Like you pointed out, it's alpha and being rewritten heavily, and there is a major issue I need to address with regards to how external displays are handled. After I've done that I can take a look, and maybe we can just eliminate these taint errors completely, and the maximum stored bugs can be set to a sane default.

    I really fail to see the value in keeping 1000 bugs around, and I am one of the main developers of BigWigs, which has a very long history. Please convince me how >50 stored errors makes sense.



Last updated
Oct 29, 2013
Mar 27, 2011
Invalid - This was not a valid report.
Enhancement - A change which is intended to better the project in some way
Medium - Normal priority.

Reported by

Possible assignees