CurseForge and Overwolf are joining forces!
Awesome More Information
  • 0

    posted a message on Recount
    Likely a messed up savedvariable file for the characters affected. Delete all Recount.lua files in the WTF directory tree, and especially the ones for affected characters.

    Incidentally this is virtually guaranteed to not be related to the update of to 5.1d as this only contains a minor change to main window number displays and did not touch data storage at all.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Thanks for the heads up there. Not quite sure what is going on, but a few of the used libraries had mismatched UUIDs in my SVN checkout. Not sure if that messed up the packages. Let's see. I tagged another release after a little voodoo dance.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Thanks for the feedback. Tagged for release.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Alpha version r1229 now contains the 1) option for DPS format shortening, per popular vote. If a number format is selected it will now also be applied to per-sec numbers such as DPS or HPS. Once I get some feedback that there is no problem (or with patch 5.2, if it comes first) I'll tag this release.

    http://www.wowace.com/addons/recount/files/1596-r1229/
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Not knowing what errors your are getting and stabbing into the dark: Manually delete more, make sure that your event-based deletion options are set such that you delete frequently. Make sure to start with a clean slate with respect to wtf.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Fixed. Thanks.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    That's a good observation. It used to not be necessary to shorten DPS numbers because the number of digits were low and averaged hence static. The totals grow with the time of play and bounding their representation made sense much earlier.

    Anyone objection to linking the short display also into the DPS numbers? The problem here is that some people may actually like the fine detail of their DPS numbers (though that fine detail is basically worthless) and liking them may not be universally seen as the right move. I'd love to not clutter the config window with a separate option though.

    Perhaps I can think up a mixed solution where DPS numbers are guaranteed to show 4 digits or something, no matter where the rounding point will fall.

    Let me know your preferences, in short:

    1. Link short setting over to DPS numbers (hence shortening them in the same way)
    2. Floating DPS number representation guaranteeing 4 digits to be shows but shortening more digits.
    3. Keep as is, allowing full resolution of DPS numbers
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Thanks!
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Quote from Dridzt
    Just want to chip in that about the limit to execution time (on PC, it might be different for Mac) has been found to be ~200ms in combat, 150ms being considered 'safe' (at this moment, Blizz might change it).

    This is not my work, just remember reading about the testing on some ticket comments (exact ticket escapes me atm, but the numbers stuck in my head)


    Interesting. I'd love to read the actual work. Not so much for deletion but in order to make the config window more robust for in-combat use.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Quote from rowaasr13
    Shouldn't you instead eliminate unnecessary subtables to make wiping out works faster? At least .Details. step is clearly redunant.


    The problem is that we do not know what the performance cut-off is to avoid the script too long error. That is the real problem.

    The minor problem is that all the optimizations are very minor compared to the overall data volume that does need to be deleted. I.e. these are cosmetic at best and don't solve the core issue, which is guaranteeing that the error does not occur.

    Quote from rowaasr13

    It was in the patch I've submitted some time ago, but you've choose to ignore it because "you can't be bothered for every little patch when you work on addon for millons of people". Now Blizzard's own limits come to bite you.


    I don't accept your patch because it does not actually solve the problem in question.

    Quote from rowaasr13

    Another temporary solution would be is to simply de-attach table instead of wiping when you're in battle and attaching new, empty table for new structure instead. Keep link to deatached unprocessed table somewhere and wipe it with your custom methods after end of combat.


    That is cosmetically different from what is the current solution.

    Quote from rowaasr13

    Also, quick review of :GetTable show that you get first table from list and then tremove(Tables,1). This is bad. If you look at implementation of table.remove, it shifts all element one-by-one to new positions. Removing at [1] is the worst case for it. Pick up table at Table[#Tables] instead and then nil that index.


    GetTable is used to reset the data in the actual bar display lines. The cost of the call to the GetTable function in the deletion routine has an upper bound of the number of rows in the main window display. This is trivial and unproblematic and can easily be done in combat. In fact it is routinely done in combat in Recount due to battle display switches.

    That is, the part you are proposing an optimization for here is not what is substantially responsible for causes long script run-time. Deleting combatant data not bar lines is what is costly. And given that combatant data scales with recording time there is no way to construct an upper bound to the data via pruning strategies.

    There are some simple guidelines for how to optimize. The most critical question is: Does it solve the problem? If no, it's a waste of time. If you do want to find tangible optimizations understand what the critical costs are and if possible optimize them. (In some circles this is known as "profile before you optimize"). Don't optimize randomly or small parts that are known to have trivial impact on the overall performance. Doing those may make us feel like we did something. But really we are still only wasting our time.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    The config window already contains a toggle to merge absorbs into heals or not.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Best is to delete all.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Delete your Recount.lua files in your wtf directory tree. Also thanks to the cap on script length in combat it is not advisable to open Recount's config window in combat, especially if you have a lot of textures and fonts. Finally the ticket reports for an older version of Recount, so updating to the latest version is advisible too.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Not planning to use StaticPopupDialogs as long as it is subject to possible taints even with the index hack.

    This is however quite doable taint-free by grabbing the OnKeyDown event.

    But in any case I'm not convinced that this is a worthwhile extension. I suspect that people who want the speed of keystroke access for that dialogue would perhaps be about as well served by simply turning that confirmation off and that feature already exists.
    Posted in: General AddOns
  • 0

    posted a message on Recount
    Recount already uses the SavedVariables mechanism to store recorded data per character. In principle it would be possible to write an off-line program that can read this.

    However it is likely preferable to simply safe the combatlog and use one of the web-pages that construct parses.
    Posted in: General AddOns
  • To post a comment, please or register a new account.