Yeah, addons have no access to other players' data. They need to run it to. Either that data would be sent over an invisible addon channel when requested, or it could be stored in Officer notes (which would make browsing the data quicker because no querying would need to be done, but you'd lose Officer notes).
Delete the file ViperWarn.xml, open the ViperWarn.toc file and change 'ViperWarn.xml' to 'ViperWarn.lua', then change the full contents of the ViperWarn.lua file to:
local has = false
local e = CreateFrame('Frame')
e:RegisterEvent('PLAYER_AURAS_CHANGED')
e:SetScript('OnEvent',function()
if GetPlayerDebuffName('Viper Sting') then
if not has then
has = true
ZoneTextString:SetText('Viper Sting!')
ZoneTextFrame.startTime = GetTime()
ZoneTextFrame.fadeInTime = 0
ZoneTextFrame.holdTime = 2
ZoneTextFrame.fadeOutTime = 3
ZoneTextString:SetTextColor(1,0,0)
PVPInfoTextString:SetText('')
ZoneTextFrame:Show()
PlaySoundFile('Interface\\AddOns\\ViperWarn\\Sounds\\Viper Sting.wma')
end
else
has = false
end
end)
(Note: you can open all the files in Windows Notepad.)
One thing I have found is that everyone has their own preferred short talent tree names. Is it BM or Beast spec? Is it Destro or Destruct spec? Is it Demo or Demon spec? The use of replace tags will let you make it how you prefer it to be.
I haven't updated DogTag or played with it in a while, because I've been off the game for a good 2 weeks, but I'm guessing that :Replace() uses :gsub(). If so, using my current tag (which simple does an '=' check for each possible replacement) is going to be much more efficient.
We have been intending to add a shortened talent spec tag, unfortunately it's rather low priority at the moment because of the more pressing issues related to 2.4 and the new version of DogTag. I promise it will make it in eventually, though! :)
Ah, cool.
Quote from Seerah »
Have you tried TalentSpec:Truncate(5, ellipses=false) ?
edit:
That would get you Resto, Feral, Beast, Marks, etc. Sure, they wouldn't all look perfect... Comba, Eleme, etc.
I'd just rather use the tag that looks for each specific text to abbreviate, and provide the abbreviated text for that, so I can have "BM" and "Ele", and such.
Jncl, where do you stand on other authors updating this mod? Because in my free time I may be able to fix a couple of the broken addon skins, if you'd like. (Not making a promise though!)
Pet peeve alert! If "Restoration" becomes "Restro" instead of "Resto" I will cry. Otherwise great idea :D
Woops!
But yeah, I'm using a huge workaround for it, that checks for every single spec to abbreviate before falling back on the full spec. The entirety of which uses 604 characters (not including the rest of the string)! It makes the whole string very hard to modify quickly.
There doesn't seem to be an option to disable emotes..? With MikSBT set as my output frame I'm getting enemy NPC emotes sent to the WitchHunt message frame.
[2008/03/27 09:12:59-940-x15]: Skinner-2.3\Skinner.lua:864: attempt to concatenate a nil value
Skinner-2.3\UIElements2.lua:182: in function <Interface\AddOns\Skinner\UIElements2.lua:178>
(tail call): ?:
<in C code>: in function `InterfaceOptionsList_DisplayFrame'
Interface\FrameXML\UIOptionsFrame.lua:451: in function `InterfaceOptionsListButton_OnClick':
<string>:"*:OnClick":1: in function <[string "*:OnClick"]:1>
Happened while browsing the new UI options. Not sure how or why, I noticed the bug after closing the options.
LibDogTag-3.0\Compiler.lua:2080: in function <Interface\AddOns\LibDogTag-3.0\Compiler.lua:2075>
(tail call): ?:
CowTip-r66258\Text\Text.lua:254: in function `RefixLines'
CowTip-r66258\Text\Text.lua:344: in function <Interface\AddOns\CowTip\Text\Text.lua:318>
<in C code>: ?
LibRockModuleCore-1.0-1118 (LibRockModuleCore-1.0):398: in function `CallMethodOnAllModules'
CowTip-r66258\CowTip.lua:214: in function <Interface\AddOns\CowTip\CowTip.lua:204>
CowTip-r66258\CowTip.lua:228: in function <Interface\AddOns\CowTip\CowTip.lua:221>
(tail call): ?:
<in C code>: in function `SetUnit'
Interface\FrameXML\UnitFrame.lua:93: in function `UnitFrame_UpdateTooltip':
Interface\FrameXML\UnitFrame.lua:77: in function <Interface\FrameXML\UnitFrame.lua:57>:
[2008/03/26 13:36:16-1425-x1]: Skinner-2.3\UIElements1.lua:700: attempt to index global 'InspectPVPFrameCloseButton' (a nil value)
<in C code>: ?
AceEvent-2.0-63812 (Ace2):367: in function <Interface\AddOns\Ace2\AceEvent-2.0\AceEvent-2.0.lua:345>
---
When inspecting and inspect window skin is buggy.
To anyone getting this issue: Open up the file UIElements1.lua in the Skinner folder and Ctrl-F "InspectPVPFrameCloseButton:Hide()" (line 700). Change it to: "--InspectPVPFrameCloseButton:Hide()".
I assume you're busy right now, but when you get the chance, would be it possible to have a [ShortTalentSpec] tag implemented? It would basically abbreviate all the current specs ("Elemental" becomes "Ele", "Restoration" becomes "Restro", "Feral Combat" becomes "Feral", etc), without the complex tag workarounds, or modifying the files (which appears to be tricky business now that DogTag uses LibTalentQuery-1.0).
The InspectUI has changed a bit and Skinner is now erroring trying to skin it. It also appears... messed up. Edit: So you don't go through the trouble of figuring it out, it seems the InspectUI issues can all be fixed by commenting out line 700 of UIElements1.lua, because InspectPVPFrameCloseButton doesn't seem to exist anymore. From there, it works flawlessly.
LightHeaded got reworked and the current skin for it isn't compatible. I get an error and nothing changes when opening the quest log now because of this.
The interface options panel, though reworked, seems to have reused all its old frames names. The current skin is totally compatible. The only thing though, multiple inner panels in the right column show the default border, that being the tooltip border, and not the one Skinner is set to display (because obviously they are new).
And I know you're probably busy, but Bongos3 is out. Any chance of skinning it's options?
I just began toying with LibBanzai-2.0 a little in a front-end I made for aggro notification in combat text and I noticed the throttle rate on 2.0's polling is way too high. .5 doesn't seem like a lot when you think about it, but I had times when I've been hit 2 times by a mob before I was told I have aggro, and that was off just one mob. Multi-mob aggro in a party could be devastating to squishy classes if you're relying on this lib's notification.
For now, just an annoyance to me honestly. But I hope it gets fixed before I begin using it more heavily.
Edit: Oh, one other issue, is there any reason the unit's name is sent to the callback and not the unit-ID? I think the unit-ID would be a lot more useful, and easier to use. After all if I want the name I'll call a UnitName on it.
Stick to the PIL. The best you're going to get here is some sparse information, which you can never guarantee is accurate, from the few people who want to take the time to recite sections of the book you should be reading instead. (Edit: I'm not suggesting OrionShock's information is inaccurate. He knows what he's talking about.)
It may seem like a lot to read, and it is all for one session. But read a little at a time, front to back, and you won't have to ask these questions--instead you'll be the one smart enough to answer them.
0
0
local has = false local e = CreateFrame('Frame') e:RegisterEvent('PLAYER_AURAS_CHANGED') e:SetScript('OnEvent',function() if GetPlayerDebuffName('Viper Sting') then if not has then has = true ZoneTextString:SetText('Viper Sting!') ZoneTextFrame.startTime = GetTime() ZoneTextFrame.fadeInTime = 0 ZoneTextFrame.holdTime = 2 ZoneTextFrame.fadeOutTime = 3 ZoneTextString:SetTextColor(1,0,0) PVPInfoTextString:SetText('') ZoneTextFrame:Show() PlaySoundFile('Interface\\AddOns\\ViperWarn\\Sounds\\Viper Sting.wma') end else has = false end end)(Note: you can open all the files in Windows Notepad.)
0
I haven't updated DogTag or played with it in a while, because I've been off the game for a good 2 weeks, but I'm guessing that :Replace() uses :gsub(). If so, using my current tag (which simple does an '=' check for each possible replacement) is going to be much more efficient.
0
Ah, cool.
I'd just rather use the tag that looks for each specific text to abbreviate, and provide the abbreviated text for that, so I can have "BM" and "Ele", and such.
0
Ah, my mistake. I guess 5.1 didn't import those settings either.
0
0
Woops!
But yeah, I'm using a huge workaround for it, that checks for every single spec to abbreviate before falling back on the full spec. The entirety of which uses 604 characters (not including the rest of the string)! It makes the whole string very hard to modify quickly.
0
Very nice work though.
0
Happened while browsing the new UI options. Not sure how or why, I noticed the bug after closing the options.
I guess it doesn't work as-is.
0
0
To anyone getting this issue: Open up the file UIElements1.lua in the Skinner folder and Ctrl-F "InspectPVPFrameCloseButton:Hide()" (line 700). Change it to: "--InspectPVPFrameCloseButton:Hide()".
0
0
The InspectUI has changed a bit and Skinner is now erroring trying to skin it. It also appears... messed up.
Edit: So you don't go through the trouble of figuring it out, it seems the InspectUI issues can all be fixed by commenting out line 700 of UIElements1.lua, because InspectPVPFrameCloseButton doesn't seem to exist anymore. From there, it works flawlessly.
LightHeaded got reworked and the current skin for it isn't compatible. I get an error and nothing changes when opening the quest log now because of this.
The interface options panel, though reworked, seems to have reused all its old frames names. The current skin is totally compatible. The only thing though, multiple inner panels in the right column show the default border, that being the tooltip border, and not the one Skinner is set to display (because obviously they are new).
And I know you're probably busy, but Bongos3 is out. Any chance of skinning it's options?
0
For now, just an annoyance to me honestly. But I hope it gets fixed before I begin using it more heavily.
Edit: Oh, one other issue, is there any reason the unit's name is sent to the callback and not the unit-ID? I think the unit-ID would be a lot more useful, and easier to use. After all if I want the name I'll call a UnitName on it.
0
That wouldn't be smart at all.
http://www.lua.org/pil/2.5.html
http://www.lua.org/pil/11.html
Stick to the PIL. The best you're going to get here is some sparse information, which you can never guarantee is accurate, from the few people who want to take the time to recite sections of the book you should be reading instead. (Edit: I'm not suggesting OrionShock's information is inaccurate. He knows what he's talking about.)
It may seem like a lot to read, and it is all for one session. But read a little at a time, front to back, and you won't have to ask these questions--instead you'll be the one smart enough to answer them.