A library to provide unit-oriented tags to LibDogTag-3.0
Hi just a heads up, for Wow classic I had to change the AddTag function in Misc.lua line 28-32 to remove the Vehicle call (I was trying to use the [Combos] tag):
if wow_600 then
return UnitPower("player", 4)
return GetComboPoints("player", "target")
Doteventril, there is currently an issue with DogTags. I use PitBull as well and as soon as I turned off the DogTag texts and turned the LUA ones back on all of my errors disappeared.
I'm not sure if the library will be updated, although I surely hope so. I had so many things customized using these texts that being forced to not use them is very seriously impacting how much I enjoy a lot of other addons.
Looks like I spoke too soon.
If you download Lib-DogTag-Unit-3.0 (http://www.curse.com/addons/wow/libdogtag-unit-3-0) and Lib-DogTag-3.0 (http://www.curse.com/addons/wow/libdogtag-3-0) that things might just work out. Some of my errors disappeared (although there are still around 100 or so that get thrown by these addons)
I am getting this error when using MSBT and Pitbull together:
2x LibDogTag-3.0\LibDogTag-3.0-90203.lua:306 PitBull4_FontString_8:SetText(): Font not set
<in C code>
LibDogTag-3.0\LibDogTag-3.0-90203.lua:306 in function <LibDogTag-3.0\LibDogTag-3.0.lua:287
LibDogTag-3.0\LibDogTag-3.0-90203.lua:436 in function "AddFontString"
PitBull4_DogTagTexts-v4.0.0-beta32\DogTagTexts.lua:218 in function "AddFontString"
PitBull4-v4.0.0-beta32\ModuleHandling\TextProviderModule.lua:118 in function "UpdateFrame"
PitBull4-v4.0.0-beta32\ModuleHandling\Module.lua:319 in function "Update"
PitBull4-v4.0.0-beta32\UnitFrame.lua:801 in function "Update"
PitBull4-v4.0.0-beta32\UnitFrame.lua:827 in function "UpdateGUID"
PitBull4-v4.0.0-beta32\Main.lua:1385 in function "CheckGUIDForUnitID"
PitBull4-v4.0.0-beta32\Main.lua:1409 in function "?"
Ace3-Release-r1061\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:147 in function <Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147
<string>:"safecall Dispatcher":4: in function <string>:"safecall Dispatcher":4
<in C code>
<string>:"safecall Dispatcher":13: in function "?"
Ace3-Release-r1061\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:92 in function "Fire"
Ace3-Release-r1061\AceEvent-3.0\AceEvent-3.0-3.lua:120 in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119
The Pitbull guys referred me here.
Hi ckknight, looks like there was a change when dual specs rolled out that's affecting the TalentSpec tag. I finally tracked it down after wondering why so many people were coming up 0/0/0 in my cowtip. GetTalentTabInfo() now has a 4th arg to specify which talent group you want to read from, and you can determine which is active by calling GetActiveTalentGroup(). Take a look at the updated blizzard frame code:
Please take a look at the following patch and see if you can roll it into LibDogTag-Unit-3.0/Categories/Talent.lua. It seems to be working for me, people that used to come up with 0/0/0 now come up with their correct talents, and I verified them with the blizzard inspect frame (right click -> Inspect). Thanks so much!
I can't seem to post a code fragment here, here's an offsite link:
Real simple. Hope there are no concurrency issues.
I noticed someone had filed a feature request under cowtip maybe to expire talent entries after a while. With easy respecing now this would be nice to expire them after a few minutes or something.
Stop breaking my pitbull!