• 0

    posted a message on LibTalentQuery-1.0
    Ok, I made copies instead of linked externals. I assume this is to fix some of the errors people were reporting in PitBull and CowTip.
    Posted in: Libraries
  • 0

    posted a message on Grid
    Quote from Phanx »

    GridStatusHealPriority
    GridStatusHealer

    ...The other two Grid plugins, although I personally think they don't need to exist at all, should be updated to use LHC.


    GridStatusHealer was renamed GridStatusHealPriority, so GridStatusHealer shouldn't exist anymore. It has been using LHC even before Grid supported it, but it had backward compatibility (to IHL and HC2) for a while because the Grid on WoWI and Curse didn't have LHC. As of Tuesday morning all references to old libraries were removed and it's now expecting the latest libraries to work.

    BTW, what irks you about it existing? It was only meant to replicate a function that Squishy had. Grid replaced Squishy so for those that miss this functionality, the plugin fits that need.
    Posted in: Grid & Grid2
  • 0

    posted a message on LibTalentQuery-1.0
    What I'm currently thinking is we make a "LibTalentCache" that uses LibTalentQuery. That way people don't have to have a memory hogging library if they don't want it. Something along the lines of how LibMobHealth is working, so that it auto-prunes the info when a max number of units cached is hit.

    If we were to use the blizzard armory style of storage, some addons would have to have static information about the talent trees. If we stored ALL the information (talentname, current rank, max rank, icon, etc), then all data would be available and the addons would still work after a talenttree change patch or expansion. The obvious bad thing would be the data would be extremely bloated with info that most addons don't need.
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    Well, I've had multiple requests to cache the talent information, enough requests that warrants a discussion.

    What would be the ideal cache data structure be? There is a lot of info:

    NumTalentTabs
    TalentTreeName, TalentTreeIconTexturePath, TalentTreePointsSpent, TalentTreeBackgroundImage
    NumTalents
    TalentName, TalentIconTexturePath, TalentTier, TalentColumn, TalentCurrentRank, TalentMaxRank

    The current index into the cache should probably be the unitname(-server). Should it be changed to the GUID in 2.4 (this Tuesday??)

    Would we ever need to re-inspect after the data is cached? (say someone in your raid needs to respec while remaining in the raid)

    Any other thoughts/concerns that we should discuss?
    Posted in: Libraries
  • 0

    posted a message on MoBuffs Official Thread
    LibTalentQuery callback changed. It now returns (event, name, server). This was changed because even raid unitid change quickly, especially during the beginning of a battleground (I test in AV). The result is that the name and server should now be always acurate.

    Change the following in your code:

    function MoBuffs:TalentQuery_Ready(_, unitid)
    	if (unitid) then
    		local unit = RL:GetUnitObjectFromUnit(unitid)


    to:

    function MoBuffs:TalentQuery_Ready(_, name)
    	if (name) then
    		local unit = RL:GetUnitObjectFromName(name)


    RosterLib doesn't store the server yet, so if 2 people have the same name but from different servers then RosterLib is confused. That will be fixed in next version of RosterLib.
    Posted in: General AddOns
  • 0

    posted a message on LibTalentQuery-1.0
    Why are we arguing? This is silly.

    Don't like the library, don't use it. Like the library, use it. Not sure how the existance of the library is of any threat to anyone. It at least serves as an example of how to fix a lot of the problems with Blizzard's talent inspect api.

    On a more important topic... Is it better to Hide/Show the frame like in Shadowed's example or to SetScript OnUpdate to a function when needed (and nil it when unneeded). Seems like both ways do the exact same thing, but I wasn't sure if one had more advantages over the other. I will switch to the hide/show method if there is a case that it would make things more efficient.
    Posted in: Libraries
  • 0

    posted a message on MoBuffs Official Thread
    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.
    Posted in: General AddOns
  • 0

    posted a message on GridLayoutPlus
    I've worked out some problems with the LibTalentQuery library that I think will make Layout Sorting "By Role" more useful to everyone. Please try it out and let me know what you find. Seems to be working fine for me.
    Posted in: Unit Frames
  • 0

    posted a message on LibTalentQuery-1.0
    I will change this tonight. Thanks for the heads up.
    Posted in: Libraries
  • 0

    posted a message on LibTalentQuery-1.0
    You might be right. But allow me to debate for the sake of allowing you to correct me because I may be missing somethings.

    The LibTalentQuery library as it stands is nothing more then a wrapper for a crappy blizzard talent query api. It doesn't do anything really monumental, but it does seem like a lot of addons may need to have similar code in their addons. If we all agreed on what that code would be, why not make it a library? I mean there are a lot of libraries that people use that aren't necessary. I just thought it seemed to fit the "why rebuild the wheel" type philosophy that I assumed libraries are for.

    I am a newb. I don't get on IRC that much. I don't read all the forum debates on "the best way to do things". I'm oblivious to what the current trend is with libraries. If you explain to me why this library is silly, I might go "man, I can't beleive I thought I solved something". Just let me know. I'm not one of those people who thinks everything he does is magic :)
    Posted in: Libraries
  • 0

    posted a message on Overall Item Value
    Two "ace" addons you could look at are:

    ItemValue

    and

    HellbenderDKP

    I don't think either mod fits what you want exactly, but they at least give you something to compare to.

    The problem right now is that various class specs have somewhat accepted stat weights worked out for their class spec, but comparing different class specs to one another is apples and oranges.

    There isn't 1 single stat that has the same value between all class specs. Closest thing I can think of is stamina, but priests don't value it as much as a warrior does.
    Posted in: Addon Ideas
  • 0

    posted a message on GridLayoutPlus
    Please explain. I don't understand what you are asking.
    Posted in: Unit Frames
  • 0

    posted a message on LibTalentQuery-1.0
    Not until 2.4. I believe NotifyInspect currently (on the live servers) only requires that the unit is in "visible" range for friendly units.

    From what people have told me, Blizzard will be limiting the range in 2.4 and removing the ability to inspect hostile units. Do I think this will kill this library, no. I think it will still be useful, but it mean you have to be more careful which units you query because they will stay in the inspectionQueue until stricter conditions are met.

    When 2.4 goes live I will modify the code to reflect blizzard's new restrictions.
    Posted in: Libraries
  • 0

    posted a message on MoBuffs Official Thread
    I haven't looked at your code so I don't know if you are doing this, but here are some things to make sure of...

    Setup some sort of spec cache that lets you know when someone's spec has been found, at some point you should not need to do any more talent queries in a raid. If a warrior was found to be a tank, then you should always remember that that unit is a tank without running another query.

    Also make sure you are only querying classes that need to be queried. No need to check what spec a rogue is or which spec a warlock is. You know what their role is. They usually get the same buffs no matter what. But Warriors, Priests, Druid, Paladins, and Shaman need to be queried and then cached. Again at some point no more talents need to be queried since you should already know.

    As far as what LibTalentQuery does in idle if no queries are in queue... nothing. If there are units who can't be queried (because they are not in the same instance, or are really far away, then they will remain in the queue until they are in "visible" range.

    I recently changed the delay time to check the inspectionQueue from 2 seconds to 1 second (which helped in my testing on unnecessary delays in sorting through the raid). The value is a "constant" variable 9called INSPECTDELAY) and you can change it in the code to see if that is what is causing unnecessary lag for you. If you find it is, let me know and I will look into permenantly changing it in the library source.

    Remember, this is a new lib that has really only been tested by one person (me). So your feedback is important.
    Posted in: General AddOns
  • 0

    posted a message on GridLayoutPlus
    Of course. Get Clique (wowinterface.com) or Click2Cast (wowace.com). I use Clique. You can bind any kind of click to any action. Assist is usually a default action that can be easily bound.

    Most people who use Grid tend to use either Clique or Click2Cast so this is not something really unique.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.