How about a WeakAuras Logger?
Causese opened this issue ยท 18 comments
Is your feature request related to a problem? Please describe.
Debugging without actually playing the game is frustrating since users don't provide quality comments on wago.
I kind of hoped that a WA debugger could help solving the issue.
Describe the solution you'd like
An editbox that appears on the specified event and returns the text.
Basically some function that we can add to on init like WeakAuras.Debugger("ENCOUNTER_END")
and another function that adds text to the final output, something short like WA.Add("someText") since it will be used a lot
It should have some base information that the author does not have to include himself like wago link, version...
Something like this but less ugly:
Describe alternatives you've considered
Did consider just coding my own but it kind of bloats the on init with lots of scary looking code.
Additional context
I would probably use a custom option that enables the debugger.
The pedant that lives in my basement would like to tell you that this is a logger, not a debugger.
I think this would be somewhat useful to the "boss mods in wa" custom coders. Could you ask these people, and I guess you know where to find them, in which form it would be most useful.
As to showing the output, I think a button on the information tab would work pretty well.
I summon thee @Reloe @1ps3 @sragia @Translitdk
The copy debug log part is probably not possible since CopyToClipboard() is protected.
Maybe a select all button? I can also see users highlighting it and accidentally erasing it so maybe an "Undo/reset" kinda thing might be useful (unless there is a way to allow users to highlight, copy but not input anything)
Yea just make it so they can't edit it, or if they change anything it just rewrites it again.
I'll answer it under the assumption that:
- per aura means an information tab approach
- global means something like bugsack where all WA's logs are added
not sure if I understood things correctly but a global solution seems better
What's the api to log? Is it always per aura?
not sure about this question but ideally:
- some api to append something to the output (log)
- some api to signalize "if you get here, might aswell stop logging cause it's functioning properly"
- some api to clear log?
Is the some kind of debug flag that needs to be set for logging to be enabled? If there's a flag, is it per aura, global and how do you enable/disable it
per aura: some toggle in information tab or authors do it via custom options and an on init function
global: could be as complicated as having to enable logging in the information tab of each aura, and having a button in wa options that lists all WAs that are currently enabled for logging + the option to disable it there.
without the latter, I can see users enabling logging for multiple auras and finding it hard to disable it again per aura
How is the log cleared? Automatically? Manually? (That also depends if the logging needs to be enabled or not.)
Or is there a size restriction on the log?
Maybe a dropdown?
- Automatically
- Manually
- Keep Best log (check if string length > previous?)
Not sure about size restriction
How does the user show the extracted log?
few ideas here:
per aura:
- ipse's suggestion of show log button in information tab but this requires the user to know how to get there. However, if logging is enabled by default then users kinda need to be "taught" how to find the option that extracts the log, whereas a popup (global solution) is self explanatory
global:
- could be a minimap button interaction or a button somwhere in WA options
- /wa log
- some bugsack alike frame that opens post event (ENCOUNTER_END in my case) and lists all the saved logs for each aura with an option to maybe disable logging for that aura
So, the design considerations I have, and to which you should figure out what the right answer is:
What's the api to log? Is it always per aura?
Is the some kind of debug flag that needs to be set for logging to be enabled? If there's a flag, is it per aura, global and how do you enable/disable it
How is the log cleared? Automatically? Manually? (That also depends if the logging needs to be enabled or not.)
Or is there a size restriction on the log?
How does the user show the extracted log?
The goal on a high level is something like this:
Some coder prepares a aura, some user has some problem with it and as usual the user proclaims that: "IT DOESN'T WORK. HELP ME! WHY DON'T YOU HELP ME?!?!?!".
And for that the coder might ask for a log.
For me, that sounds like it should require as little steps from the user as possible. And especially no hard decisions. So imho this could work:
-
Logging is always enabled and there's no switch to disable it.
-
The api looks like this:
- WA_ClearLog()
- WA_Log(...)
- It's up to the coder to implement clearing the log on e.g. ENCOUNTER_START (or whatever is the right place.)
-
There's a button on the information tab to show the log. (Similar in behaviour to the aura export window.)
-
The log automatically contains the id, version and url meta data.
-
Now automatic showing of logs. The one step the user has to do, is to navigate to the information tab and click on "Show Log".
Another way this could work, is like this:
- Logging is disabled by default
- The user has to enable logging
- Api is:
- WA_Log(...)
- WA_EndLog
- EndLog shows the log. (If in combat, not immediately but after combat drops)
There are many more variants of how this could work. We need to decide how it should work.
I was hoping that you do the work of figuring out how it should work together with others that have similar problems.
I'd prolly want to enable logging by default. It's easier to just tell the user to click on "Show Log" and export the output than to tell him to enable logging and try again next next week.
It's less actions overall since I don't have to wait up to a week for the user to report back.
Do you plan on adding a SavedVariable for it? Cause the user might comment post raid / closing wow
I guess giving the author more options to decide when and if the log should show makes sense, that way it's not as restrictive as a forced dropdown (auto/manual/best log) option.
- Now automatic showing of logs. The one step the user has to do, is to navigate to the information tab and click on "Show Log".
- EndLog shows the log. (If in combat, not immediately but after combat drops)
Having an encounter ID will mess with showing log on ENCOUNTER_END.
could probably still do:
if event == "PLAYER_REGEN_ENABLED" and not IsEncounterInProgress()
... unless ENCOUNTER_END fires second and that api relies on it
Persistency. Oh I was hoping that we don't need that. And I was thinking, no for a first version.
If at all possible, there should not be a setting for different logging behaviours. Keeping it simple is a worth a lot. If it proves useful, we can always extend it.
I'd support having a command to save a snapshot of tables in that log, or just aura_env
I would suggest logging all the events captured by the aura plus whatever gets logged by the code itself:
timestamp EVENT_NAME arg1, arg2, etc
timestamp LOG_MESSAGE "This is a message added in code"
I don't think you'd need a ClearLog function - each time onInit is run, it could start a new "file" aka table entry, and there should be a limit to the number of "files" and maybe also the number of lines per file before overwriting older content. Maybe store it with Archivist?
I think logging everything does make it impossible to enable logging by default.
There could be a default "log" that just had very basic info and the advanced log with all the info needs to be toggled on so most basic issues can be solved without having to enable logging first
It might be worth considering making something very simple built-in and auto-enabled, and having a 2nd addon outside the scope of the main addon with more advanced logging options.
Logger default on sounds like a performance trap. Normally you'd only need logging to do:
- Develop a weak aura (in which case you only want to log stuff from that specific aura
- Find an issue as a WA user (or allowing enough logging to get help) This could be from a specific aura, or all loaded auras.
For #2 it should be easy to point said user to a simple way to enable logging for the purpose of debugging.
Secondly you might consider different log levels, f/e INFO, DEBUG, CRAWL or some such for different layers of logging information to be captured.