I would consider dumping the local functions that build up class tables once it's determined they're not needed. LHC3 had some conditional code that only ran per class in the main body, whereas LHC4 has local functions which live for the duration of your WoW session. Once you have a valid UnitClass("player"), you can nil them and save some space.
It's designed to remove the need for mods to deal with the whole ask/answer queueing, timeing rescans, watching respecs and so on. It deals with all of it, and provides simple update events when something changes. With Blizzard API functions mapped into library which accept a unit ID argument. Plus some helpful functions to directly query talents by name.
Latest incarnation (r69) should be pretty stable now. I've not had a single invalid talent read since the last update. No crossed classes, no missing info.
Is it possible to use click casting addons for a right mouse click in X-perl raid frames? Each time I try to this binding, the right mouse click continues to bring up an options menu rather than a bound cast. Works fine for other mouse clicks and other frames with the right mouse click, but not the raid frame.
As people have asked a few times, is it likely that you're going to add vehicle buffs/debuffs to the big (de)buffs feature? I'd assume that when you enter a vehicle you could just get the GUID for the vehicle unit and then use that to determine which ones to make big.
This would be a really helpful feature not only for malygos, but also for flame leviathan now, trying to roll Pyrite stacks.
That should be working for the 3.0.3c release. It should have worked before, and indeed it did on PTR when I initially wrote it because the UnitBuff functions were giving the vehicle units as 'pet', but they changed it ofc ;)
Ok. Posted r57 just now. Can some please test it and make sure it's not going to fail for any reason. If it's working out, I'll get one of the admins to bump it to beta version.
I'm trying to use LibTalentQuery for a pet project of mine and I have difficulties making it work. Basically I've setup the callback and, on RAID_ROSTER_UPDATE, I am sending the query (TalentQuery:Query(unit)) on all units in raid for whom I don't have any information. The problem is that for a given flurry of talent queries all I ever get back is the talent information for one and only one of these units...
I've temporarily made it work by not relying on RAID_ROSTER_UPDATE but by firing my flurry of queries every second, it gets the job done but it's ugly and should not be necessary if I understand LibTalentQuery correctly...
Any idea ? Any limitations I should know about LibTalentQuery ?
Testing some re-hashing of the queuing code. Managed to improve the speed of talent collection from a couple of minutes to around 15 seconds for a 25 man group. Also that it won't purge it's queue if it can't read someone, but rather keep it and assume you really did want their talents.
I'm having trouble with the X-perl range finder settings.
I'm currently running 3.0.3 (WoW 3.1.0 Release)
I simply can't get my raid frames to show ranged players using any of the options provided.
I've even found a new 'range finder' setting in the default Blizzard raid frames, but using that or not does not seem to help x-perl raid frames.
Is this a known issue? Do others have this same problem? or is it some issue with my particular set of addons? I did ask another healer in my guild and he said that his range finder for x-perl was also broken. All the frames are grey, if range finder is enabled.
The problem is, I fixed the debuff checking option of the range finder to work independantly of the health checking option. Previously it would do both. So, it's quite possible you have the debuff check option enabled which is thus not fading frames cos the people don't need curing. Just turn it off :)
r55 and prior of ZOMGBuffs did not have any such "Attempt to access a recycled table" errors.
Yeh, they wouldn't. I put in the validation code on the tables, so now they give this error rather than failing silently and blowing up later. There's a table being discarded somewhere and I'm later using it, and this is to help me find that.
However, your errors here are the first usable ones I've seen. All mine so far have had no stack traceback, so have been useless to me. So thanks :)
0
No, it can't and nor should it. ZOMG sends that message so that other copies of ZOMGBuffs can ignore the PP comms and just focus on the ZOMG comms.
0
There was an issue with ZOMG which the latest versions have fixed. Shouldn't be any problems with newer versions.
0
0
It's designed to remove the need for mods to deal with the whole ask/answer queueing, timeing rescans, watching respecs and so on. It deals with all of it, and provides simple update events when something changes. With Blizzard API functions mapped into library which accept a unit ID argument. Plus some helpful functions to directly query talents by name.
0
0
0
Yeh, I use Clique for that. Works lovely.
0
That should be working for the 3.0.3c release. It should have worked before, and indeed it did on PTR when I initially wrote it because the UnitBuff functions were giving the vehicle units as 'pet', but they changed it ofc ;)
0
0
Yeh, saw those issues myself. I'll commit what I have shortly. The code can be made simpler by using GUIDs to match them up.
0
Testing some re-hashing of the queuing code. Managed to improve the speed of talent collection from a couple of minutes to around 15 seconds for a 25 man group. Also that it won't purge it's queue if it can't read someone, but rather keep it and assume you really did want their talents.
0
See previous reply ;)
0
The problem is, I fixed the debuff checking option of the range finder to work independantly of the health checking option. Previously it would do both. So, it's quite possible you have the debuff check option enabled which is thus not fading frames cos the people don't need curing. Just turn it off :)
0
However, your errors here are the first usable ones I've seen. All mine so far have had no stack traceback, so have been useless to me. So thanks :)
0
Yeh. Like I'm not happy about people making demands like this, which is why I gave up visiting these forums. I don't get paid for this.