- Registered User
Member for 11 years, 3 months, and 14 days
Last active Fri, Oct, 4 2013 14:31:58
- 0 Followers
- 226 Total Posts
- 0 Thanks
Mar 26, 2008Posted in: Grid & Grid2Quote from Phanx »
...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.
Mar 24, 2008What 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.Posted in: Libraries
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.
Mar 23, 2008Well, I've had multiple requests to cache the talent information, enough requests that warrants a discussion.Posted in: Libraries
What would be the ideal cache data structure be? There is a lot of info:
TalentTreeName, TalentTreeIconTexturePath, TalentTreePointsSpent, TalentTreeBackgroundImage
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?
Mar 22, 2008LibTalentQuery 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.Posted in: General AddOns
Change the following in your code:
function MoBuffs:TalentQuery_Ready(_, unitid) if (unitid) then local unit = RL:GetUnitObjectFromUnit(unitid)
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.
Mar 20, 2008Why are we arguing? This is silly.Posted in: Libraries
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.
Mar 19, 2008I'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
Mar 18, 2008You might be right. But allow me to debate for the sake of allowing you to correct me because I may be missing somethings.Posted in: Libraries
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 :)
Mar 18, 2008Two "ace" addons you could look at are:Posted in: Addon Ideas
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.
Mar 18, 2008Not until 2.4. I believe NotifyInspect currently (on the live servers) only requires that the unit is in "visible" range for friendly units.Posted in: Libraries
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.
Mar 18, 2008I 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...Posted in: General AddOns
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.
Mar 17, 2008Of 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.Posted in: Unit Frames
Most people who use Grid tend to use either Clique or Click2Cast so this is not something really unique.
- To post a comment, please login or register a new account.