Request: Bugsack!

[Lichbane]

Can someone please create an equivalent to Bugsack from WoW? For those not familiar with Bugsack, it stopped the UI Error window from appearing, but accumulated them in an error log. It also optionally had an sound play when an error occured. That means that any errors that occur are still show, but don't appear in your face in the middle of the game.

What I'd like to see is another icon appear next to the chat window (along with notification, mail, etc) that shows when a UI error occurs. Clicking on this would show a window that pages through all the UI errors.

Is there anyone who can do this?

[thelegendaryof]

Sounds like a cool idea. Thought Im not sure if we have enought access to the API to do so so it might reqiure a kind of dirty workaround to hide the default window and grab its contents. Ill try if its possible.

[Biki]

Nice idea. I think a PreHook on the UI Error Window should already do the trick, shouldn't it? Try to get the text somehow and never show the window itself. Although a PreHook might be too early for grabbing the text?
Still need the custom elements of the actual addon of course.

[thelegendaryof]

Edit: Retarded name. I'll use something more mature / simple ...

[Lichbane]

So is anyone actively working on this. There is one on Curse called Bug Log, but all it does right now is send the output to the chat log. Ideally it should output to a file or UI for preparation to send an email/bug report to addon authors.

[thelegendaryof]

...

Edit:

Nvm. Well, let me see if I can do something from theory without testing in the meantime. ^^

Edit 2:

You can copy bugs with the COPY button btw.

Edit 3:

Release in ~1 hour.

Edit 4:

Takes a bit longer - release after sleep. Grabbing & Buffering everything already. Need to add Settings & UI-Window for C&P.

Name: LibDebug

Edit 5:

Released see: http://www.esoui.com/downloads/info348-LibDebug.html

[Seerah]

The COPY button isn't in the default UI.

[thelegendaryof]

Originally Posted by Seerah The COPY button isn't in the default UI.

Seriously?!? lol, didnt notice that an addon added that functionality with it being such a basic feature.
Not speaking about why they didnt use an EditBox to begin with ... nvm. Release soon!

[thelegendaryof]

Addon released - im in a ****ign hurry to go eating now XD

http://www.esoui.com/downloads/info348-LibDebug.html

I'll properly update the description and doc later on - have fun in the meantime!

[Seerah]

@thelegendaryof: FYI, d() isn't useful only for debug statements. If you give an option for users to block what you say would be left-over debug statements, they may end up blocking alerts or printouts in chat given by an addon.

[thelegendaryof]

Yes i know that it's used otherwise aswell however

1. its not enabled by default so up to the users choice
2. all of it is still displayed in /debug instead - just centralized and not in the chatwindow.
3. to add to it you can still output it like regular without any surpression applied for important messages with LibDebug.d() which is basically a unmodified copy of the original function - if you plan to add support for LibDebug that is.

I dont think I can do anymore in terms of both user and developer friendliness. Or do you have an idea?

Btw. You can add own Message-Buffers as well. Sight, I'm just back home but I'm done for today and am to lazy to document it properly right now. Use /zgoo LibDebug to display all Public Methods which should give a basic idea what you can do - LibDebug.Buffer.DEBUG and LibDebug.Buffer.ERROR holds all debug/error messages by default.

Edit:

Hm ok, d() seems to be really widley used for Custom-Messages in many Addons as well.
I'll see if I can find an better less intrusive solution for that case.

[thelegendaryof]

How about extending d() with an additional buffer parameter?

d(msg, buffer)

@buffer:string would be optional and default to DEBUG.
However then when suppressing it will only suppress messages of the buffer-type DEBUG (default).

So if you add an own Buffer for you Addon:

LibDebug:AddBuffer("MY_ADDON_OUTPUT")

and then track with

d("Loot dropped: [xyz]", "MY_ADDON_OUTPUT")

it will still get displayed as it isn't considered an Debug-Message (and also won't get logged in the Debug-Log!).

And even in the case LibDebug wouldn't be present the second parameter of d() would just do nothing as in only getting ignored.

[Joviex]

Originally Posted by thelegendaryof Hm ok, d() seems to be really widley used for Custom-Messages in many Addons as well. I'll see if I can find an better less intrusive solution for that case.

THANKS!

This was exactly what I was posting in the addon chat. I definately use d() for messages, and even if 1 person disables it, no useful infos.

I really like the idea of error suppression though. I almost feel there should be a way to hook the chat output with various log levels, just like any standard logger.

log.debug()
log.error()

and in the addon itself, you can individually suppress the level of noise you want to see.

But I think that would require some filter/chat exposure in the API, or a standard applied across all addon authors to use a common "logger" library with the exact idea in your post above.

[thelegendaryof]

Originally Posted by Joviex I definately use d() for messages, and even if 1 person disables it, no useful infos.

You got one thing wrong thought - my Addon / Library has no public method for an Addon to surpress the Debugging Output! That choice is ultimatively up to the User in the Debug Settings and is disabled by Default. No Addon can change that - only the User.

It 's just there in case that you have an faulty Addon installed that doesn't use d() properly and spams the Chat Window with Debug-Messages and you want to disabled that output without disabling the Addon itself or having knowdlege in developing till the Addon-Developer updates his/her Addon. Thats the basic idea behind that Feature.

I really would like to add an option to disable / enable Hooks but there is no way to access the SaveData before the Addon has been completely loaded (and hooking at that point would be to late) .

Originally Posted by Joviex I almost feel there should be a way to hook the chat output with various log levels, just like any standard logger. log.debug() log.error()

Well that 's what I'm trying to do. It 's just called Buffers instead of Log Levels or Filters. I think I'll extend d() like explained above and add an public masked method "LibDebug.log(msg, buffer)". See this example for an explanation or better said usage example:

-- This will create LibDebug.Buffer.LootDrop_Messages
LibDebug.AddBuffer("LootDrop_Messages") 
 
-- This will output it's Message in the ChatWindow and store it in LibDebug.Buffer.LootDropMessages
LibDebug.log("Hello this is my first Message", "LootDrop_Messages") 
 
-- This will just add your Message to your Buffer and not output it
LibDebug.AddMessage("Hello this is my second Message", "LootDrop_Messages") 
 
-- Would be the same a LibDebug.log()
d("Hello this is my second Message", "LootDrop_Messages")
 
 -- This would output it's Message and store it as default in LibDebug.Buffer.DEBUG
d("Hello this is my third Message")
 
-- This would just output it's Message and NOT store it
LibDebug.d("Hello this is my fourth Message")
 
-- This would copy the current buffer of LootDrop_Messages in MyOutput
local MyOutput = LibDebug.GetBuffer("LootDrop_Messages") 
 
-- Which would for example look like this:
MyOutput = {
    "Hello this is my first Message",
    "Hello this is my second Message",
    "Hello this is my third Message"
}
 
-- Or you could just output the Buffer at once if you need no further logic (uses LibDebug.d internally)
LibDebug.PrintMessages("LootDrop_Messages")
 
-- Would output it to the ChatWindow like this:
-- Hello this is my first Message
-- Hello this is my second Message
-- Hello this is my third Message
 
-- This would Flush ( = Clear / Empty ) the Buffer
LibDebug.FlushBuffer("LootDrop_Messages")
 
-- Which would result in this Output:
local MyEmptyOutput = LibDebug.GetBuffer("LootDrop_Messages") 
MyEmptyOutput = { 
    -- completely empty
}

Now the only thing that 's missing is a proper Filter-Logic your custom Buffer. I'm not sure if I can or would like to do such a thing or if it would limit it 's usefulness as a Library or not. I think I would probably ultimatively leave that to the Addon-Author (for example you).

Meaning I'd never surpressing any other Type of Message then those in DEBUG. So if an Addon-Author is lazy and didn't update his Addon yet and just uses d("My Debug Output") it 's output would get surpressed (but still logged and displayed in /debug!) in the Chat Window. And I repeat only if the User decided to hide them!

Simply said - all one would have to do to make it working with LibDebug is adding one additional Line and one Parameter!

LibDebug.AddBuffer("MyAddon_Messages") 
d("My Debug Output", "MyAddon_Messages")

This output wouldn't be surpressed then - even if the User decided to surpress the default "DEBUG" messages via the Debug Settings.

If he doesn't - nothing changes for him. At all, unless that he'd live with his stuff being hidden from the ChatWindow and moved to /debug - and only if the User decides so. I don't think it can be any simpler or more accepting in terms of migration. I repeat - there is no automatic suppression and no Addon implementing LibDebug can change that Setting automatically.

I'm open to suggestions if you believe I'm wrong with that kind of implementation - however please keep in mind that there 's not only the Developer but ultimatively the User. Meaning one needs some kind of choice (like surpressing bad messages) and the other one needs to easily migrate his code with as less modification as possible - or if he has no time / or doesn't care - no modification at all. After all there 's already a big number of Addons out there that are using d(). That is why I believe hooking into d() somewhat non-intrusive is the best way to get the best of both worlds together without just instantly needing to update like 500+ Addons.

[Lichbane]

Thanks so much for your efforts Legendary. I haven't done any programming in well over a decade so I'm kind of out of touch, but I do appreciate the effort involved. I haven't had a chance to try the addon yet as I'm in a different time zone. I will when I get home in about 6 hours.

I'm not sure if I understand the more technical parts of the conversation (I am merely a business analyst now ), so I'll express a few "user requirements".

I'd like to see the addon:
a) Stop the basic debug window from popping up mid game - Critical.
b) Display a log of some kind that can be copied from a debug window into a forum post - Critical.
c) Display an icon and counter on the screen to show that an error has occurred. Click on the icon to get the debug window up - Important.
d) Have the option to display in chat that an error has occured in "XYZ" (addon name?) - Nice to Have.
e) Record the log in a file somewhere - Nice to Have.
f) Send the log as an ingame mail to the developer (assuming you have their in Game ID) - Nice to have.

For the description I'm sure it does a lot of this already. The icon and counter for each error would be a good visual indicator that something has gone wrong, especially if you have the chat options turned off.

I'm having some problems with a couple of addons. Bug Log from Curse was a good start, but it does flood chat occasionally and I can't just hand that info on to addon developers. I can see this addon being pretty much a cornerstone for reporting bugs, much like BugSack in WoW.

[thelegendaryof]

Yep most of that stuff is already done. Try it and report back - I'll sleep in the meantime (it 's 4am here)

Btw. my solution with hooking d() is probably better then just disabling all System-Messages with a Chat-Filter or?
ERWKLJR I really need to sleep now. /brain shutdown

Edit:

Also don't worry about the technical stuff - it 's additional functionality intended for Addon-Developers for more proper Debugging.

[Seerah]

Okay, my OCD is getting the best of me.

"suppress", not "surpress". Night night!

[thelegendaryof]

Originally Posted by Seerah Okay, my OCD is getting the best of me. "suppress", not "surpress". Night night!

Omg lmao hahaha! I made that spelling-misstake like 520 times in a row - corrected some and still continue to write it absolutely completely wrong lmao! There must be something mapped wrong in my brain concerning that word . Whats OCD?

Btw. whats your opinion about the solution with the hook of d()?

[Iyanga]

Originally Posted by thelegendaryof Simply said - all one would have to do to make it working with LibDebug is adding one additional Line and one Parameter! LibDebug.AddBuffer("MyAddon_Messages") d("My Debug Output", "MyAddon_Messages")

Well...not trying to be a party pooper, but...
if the developer made a coding error with d(param1) that spams, then he is also able to make the same coding error with d(param1, param2) that spams.

[thelegendaryof]

@admins:

Lmao, sorry I thought I'd post a reply but I accidentally filled out a report (Screen was automatically zoomed on the Editfield as I was writing from my Phone). Just ignore it!

Reply here:

Yep thats right however those kind of developers usualy have or take the time to implent it to begin with. Which is why they'll most probably still use d(msg) which is fine in itself as its like how the native function in itself is made. It has no impact for them - as it doesnt break anything.

Like Seerah once said to me - in a perfect world ...