• 0

    posted a message on Baggins - Official Thread
    Quote from Oddible
    Just updated to 425 and all my bank bags appear collapsed as if empty. A forced a full refresh makes them come back but every time I log back in the same problem comes up and i have to do a full refresh again.


    This just baffles me. Which rev before 425 does NOT do this for you?
    Posted in: General AddOns
  • 0

    posted a message on get widgets back from :AddToBlizOptions?
    AceConfigDialog will wipe all widgets out of the container when repainting. And add them back again.

    So, yes, you would indeed have to re-add your custom widgets every time it gets updated. Which AceConfigDialog does not support.

    Aren't you going about this the wrong way though? Just create your own container and have AceConfigDialog paint inside that. Tadaa.


    Edit: Hrmmm is that possible though? If not, perhaps it should be?
    Posted in: Ace3
  • 0

    posted a message on AceConfigDialog and relative ordering of negative 'order's
    Quote from Nevcairiel
    Lower order, higher in the tree, i don't remember it ever being designed to be -1 = first, wonder where the comment comes from =P


    Ace2 was always like this. It seemed like a good idea to have Ace3 do the same when I put together the v3 spec:

    Quote from AceConfig3 »


    • order (number|methodname|function) - relative position of item (default = 100, 0=first, -1=last)
    Posted in: Ace3
  • 0

    posted a message on AceConfigDialog and relative ordering of negative 'order's
    The intent of the spec was always to have -1 mean "last", and -2 mean "2nd last"

    If AceConfigDialog does not do this, it's doing something wrong. And judging from your testing where negative numbers randomly end up ANYWHERE, it's simply broken with respect to negative numbers.

    I'd say your fix is the right one (without having tested what offsetting things from math.huge actually does :) )
    Posted in: Ace3
  • 0

    posted a message on Plugin for Baggins to Vendor Trash Items
    No, Baggins_Scrap is the other way around. The idea HERE was to create the VT list using baggins categories, and then have a plugin that vendors everything in that section. Not just have baggins show info from another addon, which had already been done with e.g. Baggins_GarbageFu ages ago.
    Posted in: Addon Ideas
  • 0

    posted a message on Baggins - Official Thread
    Quote from gamemaster128
    I just updated to the newest revision and now I'm getting several variations of this error on login.
    *snip acelocale errors*


    That should be fixed now in r421


    Edit: no i don't follow this thread. hunterz notified me about it, luckily.
    Posted in: General AddOns
  • 0

    posted a message on AceTimer extension for "inexact" timers - spreading workloads!
    Quote from watchout
    What if I can make sure there is no time drifting? any other reason?


    You can't. I thought I could. Then I started testing and ran into "Whoops, didn't think about what happens when you zone... " so the fix then was to listen to P_E_W and re-poll. ... and then I failed to zone into an instance (too many instances alive)... and then it was off again, but this time you don't even get a P_E_W ..

    At that point I just said fuck it and decided to go with GetTime() calls to avoid more unforeseen nastiness. They're really really cheap - try statting them. (Remember to local GetTime=GetTime)
    Posted in: Ace3
  • 0

    posted a message on AceTimer extension for "inexact" timers - spreading workloads!
    Well... no, I haven't done a lot of testing, which is why I'm tossing it up here for discussion in the first place.

    The only thing I have to present is .. well.. what we've all seen... Disable all addons in a 25man raid fight -> tadaa double FPS.
    Posted in: Ace3
  • 0

    posted a message on AceTimer extension for "inexact" timers - spreading workloads!
    Myeah I'm not sure how big the problem is. I've just happened to be digging around in addons that do things on timers lately where the exact timing isn't really important.

    Scanning through my addons folder, which I'd guess is about medium size...

    ag_UF: Rangecheck every 0.7s (for every UF?)
    ag_UF: Something that gets run every 0.1s or 0.25s (for every UF?)
    ag_UF: In-combat polling every 1s (for every UF?)
    AllPlayed: Refresh its entire list every 1s or 20s depending on settings
    Bigwigs: Proximity updating every 0.5s
    BigWigs Yogg-Saron: Scan for "empower" target every 0.1s
    GridStatusRange: Every (configurable... 1?) seconds
    SpecialEvents-Aura: Refresh player's own auras every 1s
    SpecialEvents-Aura: Refresh item buffs every 0.2s
    GridStatusHots: Scan the whole raid every (configurable: default 0.5s) seconds
    IceHUD: Global Cooldown tracker every 0.05s
    IceHUD: Scan target/focus/pet/own buffs every 1s
    IceHUD: Range check every 0.1s
    IceHUD: ToT change scan every 0.2s
    IceHUD: ToT castbar every 0.1s
    IceHUD: ToT health every 0.1s
    IceHUD: ToT mana every 0.1s
    IceHUD: Threat update every 0.2s
    PallyPower: Scan for reagents every 60s
    PallyPower: Update raid buffs every 1s
    Violation: DPS: Check for party/raid members being in combat every 1s
    Violation: HPS: Check for party/raid members being in combat every 1s
    Violation: Update display every 2s

    These are just the ones that I could immediately tell were being run repeatedly.
    Posted in: Ace3
  • 0

    posted a message on AceTimer extension for "inexact" timers - spreading workloads!
    Actually, having just typed that up, I realized that you could have two APIs doing it all, without being so narrow in definitions:

    :ScheduleInexactTimer(3,7)
    - A timer that will run anywhere between 3 and 7 seconds depending on load

    :ScheduleNocombatTimer(10,30)
    - A timer that will run anywhere between 10 and 30 seconds depending on load, but never during combat.


    For a "roughly once a second, but not at the same time as anything else" timer, you'd then just do
    :ScheduleInexactTimer(1,1)


    Maybe "Inexact" isn't the right phrase to use; feel free to come up with something better.


    There'd obviously also be "ScheduleRepeatingInexactTimer" and "ScheduleRepeatingNocombatTimer".
    Posted in: Ace3
  • 0

    posted a message on AceTimer extension for "inexact" timers - spreading workloads!
    So.. I've been looking at a bunch of addons.. and it's pretty common practice to have e.g. a timer firing once a second for various housekeeping tasks like keeping displays updated, refreshing lists, whatnot..

    It strikes me that there's going to be loads of addons doing pretty much the exact same thing - and that those timers will all be firing at the exact same time, since, well, all the addons start up at the same time!


    So, how about some AceTimer extensions for things that don't necessarily need to run e.g. EXACTLY once a second? But "often enough"?


    I don't really have the whole picture yet, but I'm THINKING something along the lines of three "timers" that you can register for:

    1. One with a resolution of roughly once per second, give or take a few tenths.
    Example: Updating DPS meters

    2. One with a resolution of .. .what... 1-5 seconds that will fire more slowly if there's lots happening (probably measured by current framerate)
    Example: Raid buff managers

    3. One "I'm idling" event. Pretty much guaranteed to never fire during combat. And when nothing is happening, a few times per minute.
    Example: Polling the guild roster for player names, levels, alts/mains, to use in chatframe addons


    The ONE MAIN thing that would set this apart from real timers would be the fact that they "never" fire on the same frame. The system would do its best to space the events out once per frame. (This is where the inexactness can be noticeable for the ~1 per second one)


    I realize that addons can be smart this way too and try to not do work when not needed. But seriously, who can be arsed to do that for every little job? It also has drawbacks:
    1. Lots of addons sitting around statting performance to see if they should run, all adding to the cpu load
    2. Code duplication
    3. You still can't guarantee that several of them won't run on the same frame




    So, er.. input?
    Posted in: Ace3
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from xbeeps
    The plan was that the information that could be gathered by buff scanning alone would be amended by addon communication (by the library).


    Something just struck me. To cut down on addon comms, couldn't it make sense to keep a list of Known Caster:Spell(Rank) = strength, and when you find an unknown hot strength, you temporarily start listening to combatlog events until you learn it?

    Though I guess that could be affected by temporary trinkets and stuff.. Hrm..
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from xbeeps
    I'm thinking about adding it as part of the buff scanning (which is already taking place on UNIT_AURA events) to avoid listening to the combat log (which it currently doesn't).


    Hm, yeah, scanning the buffs should be an excellent way of determining what's up and its timers. But it doesn't really say anything about the HoT's strength :<

    (Unless something's changed radically since I last looked)


    As for visual display... well.. the only one I use personally is the one in grid - i.e. a bar showing incoming heals tacked onto the current health of the target, so personally I'd be less confused rather than more :>
    Posted in: Libraries
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    I was wondering...

    I'm thinking it would be useful to also track HoTs, and basically count the next tick about to happen as the "incoming heal"... That's at most 3 seconds away (regrowth ticks), and more commonly at most 1-2 seconds away, which is in the same time frame as your average healing cast time.

    Am I off my rockers? =)


    Edit: for lifebloom you'd probably only want to look at the tick, not the bloom. it tends to be refreshed before the bloom.
    Posted in: Libraries
  • 0

    posted a message on Load on Demand via OptDep/ReqDep is BROKEN for 3.0.2
    Can someone (whose account is not broken *nudge curse staff*) unsticky this now?

    /Mikk
    Posted in: Libraries
  • To post a comment, please or register a new account.