Module for Prat that displays chat with your name in a pop up window
Its initally configured for chatframe1 on. So you will get a little surprise - it has the same option settting method as the timestamps module. So you can disable per frame - so you dont get spam.
I have taken Artak's FuBar plugin, and am going to be adding to it.
Artak's code allows you to track raid DPS/HPS and personal DPS/HPS over a sliding time window.
I did some code cleanup to make it more ace'y, and added support for configuration exchange.
If both you and someone else running SWS and this plugin, you can exchange panel configurations in game (ie you can set your sw stats to look like thiers).
EDIT: Removed reference to Interview - which is now embedded.
Added ChannelColorMemory - Module for Prat that remembers the colors of channels by channel name
Updated the wikki with a short description.
Basically when you set the colors for channel 'foo', this will change the color of the channel to what you set foo to no matter if it is channel 1 or 10.
SW Stats is an awesome tool. Synchronized combat statistics in realtime with a high level of detail.
You should have used the report which shows who that priest healed instead of just complaining about it here.
I use SWS to be able to say things like 'we wiped because' = and have some real numbers to back up my claim. How did people die? from untanked mob's melee damage or some magic aoe or uncleansed debuffs.
Learn to use meters instead of bashing them.
Where did I bash the meters? It's a great tool. But do you really need 20 people in a raid running it?
I gave a good example of why I don't use meters. It's my opinion, and take it as you like. Good communication and observation is better than anything a meter will offer anyway. We cleared Naxx last month without any cheat tips, walkthroughs, or videos. Maybe if I needed them to help my play, I would "learn to use the meters" :)
It seems counterintuitive to run a memory hog when the whole point of this website is to offer efficient, low memory alternative mods.
Hey-
I was wondering can we get the modified version of Sw_statfu found at swstats forum put into the code here or put into the svn? It displays the dps/hps in the actually fubar.
I dropped SW Stats because it kinda defeats the whole purpose of me going to an Ace solution....low memory usage, higher fps etc. Plus, there's usually 10 people in the raid more that are running it. Let them spam it.
I play a priest. There's another priest in my guild who's sole mission in life is to top the healing meter. He'll stop at no end to get up there, overhealing be damned. Who else would stand on the fire pit at Domo and chain heal himself? The moment he tops the meters, he spams it in raid chat. Pretty funny I think.
SW Stats is an awesome tool. Synchronized combat statistics in realtime with a high level of detail.
You should have used the report which shows who that priest healed instead of just complaining about it here.
I use SWS to be able to say things like 'we wiped because' = and have some real numbers to back up my claim. How did people die? from untanked mob's melee damage or some magic aoe or uncleansed debuffs.
I am actually going to be submitting an updated version of Fubar_RegenFu, after talking with its author. It was working as of server shutdown - im developing it in a branch, and have not yet committed in the trunk.
And a second request - a fivesec type mod that could show me the amount of time spent in an out of the fsr in a given battle or whatnot, and maybe show a countdown (be it a visual bar like the original fivesec mod or a text output on fubar) that could show me time till the next full tick of mana regen.
I dont know where you are at today and some of these posts are a month old. But I thought I'd try to join in the discussion.
Here's what I got from reading this thread:
The idea of mapping each parsed string to a unique event is a good one - similar to SAX in concept.
'I hit chicken for 4.'
Lets say that comes in via 2-3 different CHAT_MSG_COMBAT* events(if you are in a raid or party or solo), you would want to just register for one abstracted event, and let an intermediate library keep up to date on which message gets fired for what - abstracting the whole blizzard event system (for combat).
So when I register for Parser_HitSelfOther, the intermediate would register the 2-3 events needed. And I would always get Parser_HitSelfOther.
This would eliminate most of the if/then/else that goes on in e.g. sct.
if (info.type == "environment") then
elseif (info.type == "hit") then
... etc
Since LUA isnt a strongly typed language using separate callbacks rather than one allows you to preserve type inforomation in a sense.
sct has an additional challenge, it processes some of the blizzard events internally. It seems like you could add the abililty to recieve Pre* Events, and allow you to switch off event generation by the parser for that message and that addon ID.
If i register for PreHook__CHAT_MSG_COMBAT_SELF_HITS, i could somehow turn off the event which parserlib generates, but only for my addon. You could use an incremetal counter and assign every event a sequence number, then pass this to the prehook function, and provide it in the subsequent parserlib callback. Basically, in the PreHook the addon would save the sequence number, and then when parserlib generates the registered event, the client could use that to ignore the event. This way you can keep the client decoupled from the actual CHAT_MSG_COMBAT_* event.
The ideal case would have an addon like sct not register to listen to the actual blizzard events at all (at least the ones that parserlib handles) -
EDIT: I just realized that this post is off topic. =)
One other piece of functionality that would be great. The ability to export the addon names and descriptions into a flat text file (grouped if that option if selected between installed and not installed).
I routinely post my mods to my guild and having to retype (or cut & paste from multiple text files) the descriptions is kind of a pain. Since the tool is already parsing the information, I would think it would be simple to provide the export.
Thoughts?
If there was a unique changelog-* you could just easily make one yourself with dir + a regex.
Could WinAceUpdate just delete changelog-* when updating - i have mine set to delete always - but i mean by default always delete at least the old changelog.
0
Module for Prat that displays chat with your name in a pop up window
Its initally configured for chatframe1 on. So you will get a little surprise - it has the same option settting method as the timestamps module. So you can disable per frame - so you dont get spam.
0
In the trunk:
I have taken Artak's FuBar plugin, and am going to be adding to it.
Artak's code allows you to track raid DPS/HPS and personal DPS/HPS over a sliding time window.
I did some code cleanup to make it more ace'y, and added support for configuration exchange.
If both you and someone else running SWS and this plugin, you can exchange panel configurations in game (ie you can set your sw stats to look like thiers).
EDIT: Removed reference to Interview - which is now embedded.
0
0
Updated the wikki with a short description.
Basically when you set the colors for channel 'foo', this will change the color of the channel to what you set foo to no matter if it is channel 1 or 10.
0
Ok thats fine, thanks for sharing.
0
Its added it to a branch if you can access it:
/wowace/branches/FuBar_SWStatsFu/Artack
0
SW Stats is an awesome tool. Synchronized combat statistics in realtime with a high level of detail.
You should have used the report which shows who that priest healed instead of just complaining about it here.
I use SWS to be able to say things like 'we wiped because' = and have some real numbers to back up my claim. How did people die? from untanked mob's melee damage or some magic aoe or uncleansed debuffs.
Learn to use meters instead of bashing them.
0
Might as well wait for 2.0 to do it, but I agree totally.
0
I have added support for the functionality found in the FSRT addon for tracking %of time in the 5 second rule in combat, etc.
The base functionality is there - just needs some tweaking of the interface. My current version was committed to the trunk.
http://www.wowace.com/files/index.php?path=FuBar_RegenFu/
0
http://www.wowace.com/files/index.php?path=FuBar_RegenFu/
0
0
I was using FSRT:
http://www.curse-gaming.com/en/wow/addons-4323-1-fsrt.html
As part of learning about the ACE2 framework I made FSRT into a FuBar plugin. If there is some interest I can import it into the svn.
0
I dont know where you are at today and some of these posts are a month old. But I thought I'd try to join in the discussion.
Here's what I got from reading this thread:
The idea of mapping each parsed string to a unique event is a good one - similar to SAX in concept.
'I hit chicken for 4.'
Lets say that comes in via 2-3 different CHAT_MSG_COMBAT* events(if you are in a raid or party or solo), you would want to just register for one abstracted event, and let an intermediate library keep up to date on which message gets fired for what - abstracting the whole blizzard event system (for combat).
So when I register for Parser_HitSelfOther, the intermediate would register the 2-3 events needed. And I would always get Parser_HitSelfOther.
This would eliminate most of the if/then/else that goes on in e.g. sct.
if (info.type == "environment") then
elseif (info.type == "hit") then
... etc
Since LUA isnt a strongly typed language using separate callbacks rather than one allows you to preserve type inforomation in a sense.
sct has an additional challenge, it processes some of the blizzard events internally. It seems like you could add the abililty to recieve Pre* Events, and allow you to switch off event generation by the parser for that message and that addon ID.
If i register for PreHook__CHAT_MSG_COMBAT_SELF_HITS, i could somehow turn off the event which parserlib generates, but only for my addon. You could use an incremetal counter and assign every event a sequence number, then pass this to the prehook function, and provide it in the subsequent parserlib callback. Basically, in the PreHook the addon would save the sequence number, and then when parserlib generates the registered event, the client could use that to ignore the event. This way you can keep the client decoupled from the actual CHAT_MSG_COMBAT_* event.
The ideal case would have an addon like sct not register to listen to the actual blizzard events at all (at least the ones that parserlib handles) -
EDIT: I just realized that this post is off topic. =)
Cheers!
0
If there was a unique changelog-* you could just easily make one yourself with dir + a regex.
Could WinAceUpdate just delete changelog-* when updating - i have mine set to delete always - but i mean by default always delete at least the old changelog.
0