• 0

    posted a message on LibTalentQuery-1.0
    Quote from Shadowed »

    If you're going to review it and say somethings wrong, look it over at least then instead of spending 5 seconds and going "Nope, this is wrong you fail"


    The main flaw I pointed out with inspectSent not being reset (which means it stops working), i think is still valid. :)

    And yes, a lib that caches talents (short term) would be useful.

    And my main point is still valid -- while it may be trivial to someone as talented as you Shadowed, I think it's still something that warrants a library.

    -Pach
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    Quote from Shadowed »

    Yes, shockingly enough thats what happens when you do a 10 minute write up to prove a point, I never said it was functional it's pointing out you don't need it.

    Do you understand how OnUpdate works? When the frame is hidden, it stops calling OnUpdate, theres no CPU leak it only runs when it's needed.


    Yes. Sorry I didn't catch your frame.hide/show. Shockingly enough, that's what happens when you do a 30 second review of code. I never said my review was complete. The review was meant to point out the advantages of having a library like Peragor's. :)

    -Pach
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    Quote from Shadowed »

    Can you actually name me how many addons need to inspect the entire raid for talents? It's fairly obscure, mostly things like Scrub it's not worth making a library out of it.

    You do not need a library for everything the below is 45 lines I did this in 10 minutes, and I don't even need any additional code from LibStub or CallbackHandler-1.0 that adds extra resources or complexity, it's not complicated, and not enough addons are going to actually need something like inspect the entire raid (especially now that you're limited to 30 yards on talents) to make it a worthwhile library.


    Any of the buff checking mods (there are about a dozon -- MoBuffs, XRaidBuffStatus, etc.). Any of the mods for group managment (GridLayoutPlus, etc.). Etc.

    Your code is pretty good. But it could be better. Two things I noticed from a very quick glance. One, you never unhook the OnUpdate event handler, so even though it's small and fairly efficient, your event handler is a constant CPU leak. For another, inspectSent is never reset to false, so after if receives a response for the an inspect, if no other units are queue, it stops working (sendInspect(unit) queues up the units, but NotifyInspect() will never be called.)

    Like I said, the difficulty is in the details, and having a good library like Peragor's really helps so that you don't have to reinvent the wheel each time.

    -Pach
    Posted in: Libraries
  • 0

    posted a message on BigWigs
    \svn\BigWigs\SC\Hydross.lua, line 60.
    "deDE" translation has two different strings for start_trigger:

    start_trigger = "Ich kann nicht zulassen, dass ihr Euch einmischt!",
    and
    start_trigger = "Ich kann nicht zulassen, dass Ihr Euch einmischt!",

    Note the different capitalizations. I don't know which is right.

    -Pach
    Posted in: Raid AddOns
  • 0

    posted a message on LibTalentQuery-1.0
    Quote from Shadowed »

    1) Hook NotifyInspect
    2) Set flag "Inspect request sent, time out at GetTime() + 3"
    3) If INSPECT_TALENT_READY fires, clear flags

    Now when you want to inspect, check if a request was sent, and see if it's timed out yet, if it has then you send your request if it hasn't you wait until the flag is dropped or you see if you can attempt to inspect again on ITR. It's not worth making a library for something as simple as that, reinventing the wheel is fine if you do it smartly.


    It sounds simple enough, but the devil is in the details. For instance "time out at GetTime() + 3" means you need 1) either some event scheduling lib or 2) to hook/unhook the OnUpdate event task as needed. Either way, that's more code you need.

    Suppose you have a group of people to inspect... like I don't know, say a 25 man raid? You then need queueing code to send the requests one by one to the server. Again, not rocket science, but still more code you need.

    You also need to have checks in there to see if some other addon wasn't playing nice and sent a request on top of you.

    Peragor's lib does all of the above, in a nice simple, re-usable package.

    Just my two cents.
    -Pach
    Posted in: Libraries
  • 0

    posted a message on MoBuffs Official Thread
    Quote from Peragor »

    I changed it this morning. The delay time for updates is set to 1 second. It should work a lot better now. Let me know if this fixed the issues you had.


    I'm not able to test it at the moment, but from reviewing the code, your changes look good. Thanks for turning this around so quickly.

    -Pach
    Posted in: General AddOns
  • 0

    posted a message on BigWigs
    \svn\BigWigs\Extras\Test.lua: line 102:
    L:RegisterTranslations("eSES", function() return {


    "eSES" should be "esES" for proper local matching (note the capitalization).
    I committed a fix for this to the SVN.
    Posted in: Raid AddOns
  • 0

    posted a message on MoBuffs Official Thread
    Quote from Phanx »

    Hmm. Well, I'm not sure how the FuBar plugin I wrote a while back updated data inside the tooltip while it was open, then. I don't recall doing any kind of event scheduling...


    I don't update data in the tooltip while it is open.

    Quote from Phanx »

    Either way, it'd still be more efficient to cache the buff data... even if you do it on tooltip generation, only do it if it hasn't been done already in the last 10 seconds. You could actually just cache all of the tooltip text; that would take care of performance issues for people who like to mouseover very frequently.


    I think there'd be more overhead (and more likely something to go wrong) with code to cache the buff data and only scan it every 10 seconds. Until I find a good reason, I'd rather keep it simple.

    The culprit turned out to be the OnUpdate handler in Peragor's LibTalentQuery library. Hopefully, either he can modify his lib or I can work something out in mine.

    -Pach

    Posted in: General AddOns
  • 0

    posted a message on LibTalentQuery-1.0
    I've been investigating spurious CPU usage in my MoBuffs mod.

    It turns out it's caused by the OnUpdate handler in the LibTalentQuery library.

    Even without any units queued to inspect, the OnUpdate handler is being called continuously by the main UI, and the little bit of processing being used by the handler is being wasted.

    I think if no units are queued, you should unregister the OnUpdate handler, and then re-register when work comes in.

    -Pach
    Posted in: Libraries
  • 0

    posted a message on MoBuffs Official Thread
    Quote from Phanx »

    From a quick look at the code, it appears you're rechecking everything in OnTooltipUpdate, which is called not only when you first mouse over the icon, but repeatedly as long as the tooltip is open. It'd be much more efficient to keep the actual data cached and update it separately; as Peragor said, talents really only need to be scanned once per session (with a possible option to manually rescan in case you know someone respecced). For buff scanning, you could either scan at regular intervals, or use the UNIT_AURA event.


    OnTooltipUpdate is only called when the frame is first displayed. It isn't called repeatedly. I verified this by adding a trace statement to the top of OnTooltipUpdate.

    I only scan talent data once per session -- it's already cached.

    I only check for roster updates when RosterLib reports a change.

    I only scan tank data from oRA2 and CT_RA when they report that it's changed.

    Right now, I've narrowed the culprit down to Peragor's talent lib. Without it loaded, my mod uses 0 CPU. With it loaded -- without making any calls to it -- my mod used 0.100 CPU/Sec, according to OptionHouse.

    I'll dig deeper and report my findings to the thread for his mod in the Library forum.

    -Pach
    Posted in: General AddOns
  • 0

    posted a message on MoBuffs Official Thread
    Quote from Zidomo »

    Its likely scanning for everyone's buffs all the time, in order to keep the results text updated (as you need to do nothing to see updated results). This is really not needed and may be why its eating CPU when idle. Change it to do a buff check only when you click the FuBar icon (or similar)? Or something else that will cut the idle usage.


    I verified the CPU problem. It's using less CPU time then any other inactive module I have installed except for Proximo, at less than .100 CPU/Sec according to OptionHouse. For comparison, ItemPriceTooltip (another Ace2 module), with out any items being displayed, was using around .800 CPU/Sec more than 8 times more.

    I placed a debug statement at the top of each of my functions in my MoBuffs.lua module. None of them are being called, yet it's still using close to .100 CPU/Sec -- which means it's in one of the libs I'm using:

    AceAddon-2.0
    AceConsole-2.0
    AceDB-2.0
    AceDebug-2.0
    AceEvent-2.0
    AceHook-2.1
    AceLibrary
    AceLocale-2.2
    AceModuleCore-2.0
    AceOO-2.0
    AceTab-2.0
    CallbackHandler-1.0
    Dewdrop-2.0
    FuBarPlugin-2.0
    Gratuity-2.0
    LibBabble-Spell-3.0
    LibStub
    LibTalentQuery-1.0
    Roster-2.1
    Tablet-2.0

    Any thoughts on how to track this down? Any usual suspects?

    -Pach



    Posted in: General AddOns
  • 0

    posted a message on MoBuffs Official Thread
    I don't think it's the lib itself, but rather like I said, the way I'm using it. I've reviewed my code, and made some tweaks. As soon as the realms are back from maintenance, I'll check this.

    -Pach
    Posted in: General AddOns
  • 0

    posted a message on LibTalentQuery-1.0
    In CheckInspectQueue() where it's looping over the list of units to inspect... the only checks it does on the unit before attempting to inspect it are:

    UnitIsVisible(unit) and UnitIsConnected(unit)


    Should it also do a CheckInteractDistance() and only check those in range?

    -Pach
    Posted in: Libraries
  • 0

    posted a message on MoBuffs Official Thread
    Quote from Zidomo »

    This is probably my favorite implementation of simple raid buff checking among the overflow of buff checking mods on the SVN right now. A quick look in FuBar to see who isn't buffing, instead of having to type out commands/open up Waterfall or embarass people in party/raid/officer chat.

    It has a problem though. Yes...it eats CPU time ;). It does so when you are idle and either solo or in a party/raid, which it shouldn't be doing. It may be the LibTalentQuery-1.0 library doing it, which the only required library for it that I have embedded; every other library I have standalone. Or it may be the mod. Regardless, it would be great if you could cut or eliminate the usage.

    When idle, either in a raid or solo, it continually eats 0.105 CPU/sec median (measured with OptionHouse). Not total CPU, but ongoing consumption. RaidBuffStatus and FuBar_RaidBuffFu (the other two buff checkers I've recently installed) use 0 CPU when idle.

    Its likely scanning for everyone's buffs all the time, in order to keep the results text updated (as you need to do nothing to see updated results). This is really not needed and may be why its eating CPU when idle. Change it to do a buff check only when you click the FuBar icon (or similar)? Or something else that will cut the idle usage.


    I suspect it's the way I'm using LibTalentQuery, as it should only scan the raid (or yourself or party) when you open the window by hovering over the icon (and then only do the scan once). You should notice that the buff list in the window doesn't refresh until you close the window and re-open it. I'll install OptionHouse and see if I can duplicate your results.

    -Pach
    Posted in: General AddOns
  • 0

    posted a message on MoBuffs Official Thread
    Quote from Ellipsis »

    This isn't always true - if the warlock has the Demonic Sacrifice talent, they may not want to have a pet out because they have one of the sacrifice buffs up. Just as a suggestion to improve the heuristic, perhaps you can make sure they have a pet *or* have one of the following buffs: Burning Wish, Fel Stamina, Touch of Shadow, Fel Energy.


    Thanks. I'll add that check.

    -Pach
    Posted in: General AddOns
  • To post a comment, please or register a new account.