![](//www.lotrointerface.com/images/style_mmoi_lotroi/layout/clear.gif) |
Category: Raiding & InstancesParty Debuff Tracker |
Interface Information |
|
Name: |
Party Debuff Tracker ![Popular!](//www.lotrointerface.com/images/style_mmoi_lotroi/downloads/popular.gif) |
Author: |
|
Date: |
06-04-2013 04:04 PM |
Size: |
9.50 Kb |
Version: |
1.3 |
Rate File: |
|
Options for Party Debuff Tracker
|
|
PDT chat output.
|
|
Party Debuff Tracker (PDT) is an experimental plugin used primarily to identify specific debuffs (though you can also find buffs) on any member of a players fellowship/raid.
For example, a main concern as a raid leader during any given fight is knowing who has what on them and being able to quickly respond. During Phase 2,3, and 5 of the Saruman fight it can be the difference between success and failure knowing whether someone needs an Overheal, needs to cure a Wound/Fear/Poison/Disease, or is about to be punted off into oblivion. During phase 2 and 5 this can be difficult if you don't run with all buffs showing, which I feel most people don't anyway, because the Acid debuff and Impending Pull do not show up on people's debuff bars.
I currently use this plugin extensively for the Smaug fight. Setting up trackers for the four valve debuffs allows me to see when people are using the valves. In combination with SuperChrono (the timer plugin), I can see when a valve should reopen next (not 100% perfect as the timer plugin has to assume the valves are fully shut when they open at the 5% morale thresholds, and that they are actually being fully closed each round, after fire-tenders, etc).
This plugin tracks every party members effects, and then searches for matches. When a match is found, it writes to chat "<PlayerName>: " and then the user specified chat response. In the picture shown, when the captain buff Focus is found on a player, the plugin writes to chat "<PlayerName>: Has received Focus!"
This plugin supplies a few examples, mostly the ones from Saruman.
Finally, using other plugins (such as Alerter), these messages can then be brought to the attention of the player in a more noticeable fashion.
Limitations:
Since multiple effects can contain the same words, it might throw a few false positives if the effect name is really short. For example, the Disease stun in Fire&Frost is simply called "Disease" and I know of at least 5 other Diseases that start with or contain the word Disease (including the Honor Guard disease in BFE).
This is an experimental plugin which I have decided to provide to the community, in hopes that someday Turbine will fix their problems and also give some inspiration to those that can write much more effective LUA code than I. I make no claim as to its overall workability (though I have tested it in a limited regard), and I will not be providing very much support for it.
Due to the nature of the problems with Turbine's Party API, this plugin has to force a reload every time a party member joins, leaves, or you personally join or leave a party. I spit out a bit of chat spam each time this happens (to indicate the plugin is reloading, and to show how many people the plugin believes is in the party), so if you happen to see any problems (such as a changed party not causing a reload of the plugin, or the plugin saying there are a different number of party members than what there actually are), please let me know. I have tested this plugin for about a week (mostly in Smaug and BFE) and it seems to work just fine, but every now and then I get a crash when logging out or sometimes on a reload of the plugin. However, I feel this was caused from me testing it and I haven't had a problem since I stopped debugging. With this in mind, it wouldn't hurt to simply not load the plugin until the fellowship/raid is set up, to reduce the amount of times reload has to be called.
In version 1.3 I feel I have finally eliminated the crashes that can be caused from the reloading of the plugin. However, there still seems to be a memory leak (which I believe is on Turbine's end) with the Party API. Extensive use of this plugin without a reload of the plugin can cause severe lag. I have added a /pdt reload command that allows you to force a reload if you feel like your game is lagging.
I have also eliminated all dependencies of this plugin in version 1.3.
Future plans:
Possibly add more examples.
Add the ability to sort trackers into groups so that only certain trackers are being used at any given time. This would allow you to sort trackers into raids, for example, so that trackers that aren't needed aren't called (which should reduce lag if you have a lot of trackers).
Add visuals (who am I kidding...).
Any bugs found can be posted, please try to paste the in-game error message, and I will attempt to fix them. Please contact me if you have any questions or would like to expand on this plugin.
Inspirations include Aura (which is what I would like the plugin to eventually look like in some fashion), Buffbars, EffectWarn, and Alerter. Many thanks to Equendil for Here Be Dragons and Galuhad for the API Table Dump plugins.
Enjoy!
|
Archive List (Old Versions) |
File Name |
Version |
Size |
Author |
Date |
|
1.1 |
5.78 Kb |
Stever1388 |
05-04-2013 03:25 PM |
File Statistics |
User Rating: |
|
Downloads: |
35757 |
Views: |
77970 |
Favorites: |
7 |
Uploaded By: |
|
Last Modified: |
N/A |
|
| ![](//www.lotrointerface.com/images/style_mmoi_lotroi/misc/clear.gif) |
|
![Post A Reply](//www.lotrointerface.com/images/style_mmoi_lotroi/buttons/reply.gif) |
|
06-04-2013, 04:07 PM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
Update 1.3
Updated the plugin to reduce crashing issues caused from reloading the plugin. Also added a "/pdt reload" command that can force a reload of the plugin, as extended use of the plugin without a reload can cause lag. I'd recommend reloading the plugin at least once an hour, if no other event causes the reload to happen (anyone leaving/joining the raid will cause a reload, logging off and back on also will work).
|
|
|
04-28-2013, 12:35 PM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
Re: New Update info
It seems the local player method "getParty()" stops working just as much as the events for members joining and leaving the fellowship/raid, which throws off the plugin even after I updated the plugin to watch chat spam for members being added or removed. At this point I will have to implement some sort of reloader for the plugin to work properly, which I'm not sure will actually work because every now and then I get a crash on reload the plugin after unloading the script state the plugin is in. So who knows.
|
|
|
04-26-2013, 01:58 PM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
New Update info
I ran into some hiccups while testing the changes I have made, most notably the continual problem of the party events not firing correct which means if you load the plugin before you join a raid or many people join/leave after you load the plugin it can cause it to not work properly. Also, it seems that if they stop working and you unload/reload the plugin (using the apartment instead of unloading all plugins) and then reloading the plugin can cause crashes. I also experienced a situation where my game sort of froze after someone left the raid but it didn't crash my game completely (I could still hear people talking in voice chat).
I'm currently working on a way to remove the dependence on the party event functions (which I believe is what is causing the crashes on reload) so that it can work regardless of when the plugin is loaded and reduce these other problems that have surfaced. Expect the update to come closer to the end of next week as I will need more time to test it.
As a side note, it works wonderfully to keep track of when the valves can be closed in Smaug and how long until they reopen when you use it to active timers with the SuperChrono timer plugin.
|
|
|
04-21-2013, 03:41 PM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
New Update coming
I have gone back and looked at this plugin recently, and have added some fixes that should make it more reliable and eliminate false positives. I have been using it to track the timers in the Smaug Fight (basically following the debuffs the valves cause on players and then throwing that to chat, which is then picked up by the SuperChrono timer plugin) and it seems to be working pretty well. Some fixes went in to address when you join/leave groups and then join another, but I can't say I have tested it all that thoroughly to know if works 100% of the time.
Expect an update towards the end of this week if I don't run into any problems.
Edit: I know it was a while ago, but I haven't experienced any crashes with this plugin from unloading it, which I have done a ton over the last week while testing and debugging. So hopefully that problem is behind us.
Last edited by Stever1388 : 04-21-2013 at 03:42 PM.
|
|
|
12-10-2012, 08:23 AM
|
|
The Wary
Forum posts: 2
File comments: 10
Uploads: 2
|
After Rohan, it seems to crash Lotro when you use /plugins unload command. It happened twice to me already.
|
|
|
10-26-2012, 11:11 AM
|
|
The Undying
Forum posts: 121
File comments: 344
Uploads: 11
|
Added it to LPC. Thank you for supporting.
|
|
|
10-26-2012, 09:16 AM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
Code:
I am looking at adding PDT to the Lotro Plugin Compendium (LPC). Before I can do so, I noticed the zip file contained the .plugin file in the root folder instead of SDRPlugins. To support you plugin, it must contain this folder to install correctly.
Also, does PDT require any dependencies? (i.e. Turbine Utility Libraries)
I did not realize I had uploaded that way, it has been fixed. Also, it does not have any dependencies.
|
|
|
10-16-2012, 04:32 PM
|
|
The Undying
Forum posts: 121
File comments: 344
Uploads: 11
|
I am looking at adding PDT to the Lotro Plugin Compendium (LPC). Before I can do so, I noticed the zip file contained the .plugin file in the root folder instead of SDRPlugins. To support you plugin, it must contain this folder to install correctly.
Also, does PDT require any dependencies? (i.e. Turbine Utility Libraries)
|
|
|
10-06-2012, 03:09 PM
|
|
The Undying
Forum posts: 51
File comments: 44
Uploads: 15
|
Quote:
Ah ok well then yes that would work quiet nicely. I was under the impression the IDs were specific to whatever the effect was.
|
Nope, it's per effect instance. That's how PartyFrame keeps track of effects - it uses the effect IDs to determine if the newly added effect really is new, polls the existing effects when it knows they're all current and uses the IDs to identify effects that no longer exist, and loads/unloads a secondary plugin that passes along a list of effect IDs that are known to exist.
Quote:
I tried out PartyFrames and I really liked the ability to customize it, the ability to watch for specific buffs and whatnot, but I couldn't get over the fact that it (on no fault of yours) would eventually stop working if I played too long and joined/changed groups too much. For example it once failed to notice a raid member was added and so I didn't get their vitals at all. Every now and then RaidAssistant seems to have the same problem, but I usually don't with it on until I need it. So I feel it is this lack of a working API that is preventing someone from developing a working raid vitals plugin.
|
It's technically not my fault, but I could fix it. Just rig up an overseer that looks for join messages and forces PartyFrame to reload every time it happens. I just haven't bothered implementing it.
Honestly, there's bugs in the Party implementation, but all of the ones that I've found (and care about) can be coded around.
|
|
|
10-06-2012, 12:02 PM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
Quote:
IDs are unique per instance of the effect, not per effect type. If you've never seen the ID before, it's a new effect being applied. If you've seen it before, it's an old effect getting another EffectAdded update.
|
Ah ok well then yes that would work quiet nicely. I was under the impression the IDs were specific to whatever the effect was.
Quote:
No, no, I understand why you're saying it's experimental and the motivation behind hoping that providing an code example will inspire others - it's just - seven months ago, I uploaded PartyFrame to this site. And at the time, I was thinking the same thing - well, less that the code was experimental, but more that there's no way that anyone will be interested in it, and that quite frankly it'll probably be more useful as a code example of how to replace the party vitals, and hopefully someone who actually knows what they're doing with regards to designing UIs (for example, I think WoW's Raid Frames (probably the most popular group vitals display) is, well, badly designed) would use it to write something more generally useful. And, of course, it tracks effects on party members, and of course, I don't think it's actually managed to inspire any plugins whatsoever.
Well, it's funny to me.
|
I tried out PartyFrames and I really liked the ability to customize it, the ability to watch for specific buffs and whatnot, but I couldn't get over the fact that it (on no fault of yours) would eventually stop working if I played too long and joined/changed groups too much. For example it once failed to notice a raid member was added and so I didn't get their vitals at all. Every now and then RaidAssistant seems to have the same problem, but I usually don't with it on until I need it. So I feel it is this lack of a working API that is preventing someone from developing a working raid vitals plugin.
Perhaps if Turbine really does fix some of these problems with the API I will sit down and make a large effort to create a raid vitals plugin, but at present it doesn't seem worth it, considering I don't even really mind the in-game ones other than the space they take up.
I'm not holding my breath that Turbine will fix it or that my plugin will spawn some amazing plugin. But I can hope!
|
|
|
10-06-2012, 11:53 AM
|
|
The Undying
Forum posts: 51
File comments: 44
Uploads: 15
|
IDs are unique per instance of the effect, not per effect type. If you've never seen the ID before, it's a new effect being applied. If you've seen it before, it's an old effect getting another EffectAdded update.
Quote:
It's experimental because I cannot honestly say for sure if it works 100% of the time or if it even can work, considering the problems and limitations of Turbine's API. Plus I'm not the best with LUA, so part of learning LUA is to try my hand at a few plugins and see what I can come up with. Considering plugins like Alerter, MinstrelBuff, RaidAssistant, Buffbars, Bevy o' Bars, CombatAnalysis, Aura, and VBar (to name a few), already do much of what I'd like to see plugins do, a Party Debuff Tracker-like plugin is one I'd really like to see, so that's the one I started with first.
|
No, no, I understand why you're saying it's experimental and the motivation behind hoping that providing an code example will inspire others - it's just - seven months ago, I uploaded PartyFrame to this site. And at the time, I was thinking the same thing - well, less that the code was experimental, but more that there's no way that anyone will be interested in it, and that quite frankly it'll probably be more useful as a code example of how to replace the party vitals, and hopefully someone who actually knows what they're doing with regards to designing UIs (for example, I think WoW's Raid Frames (probably the most popular group vitals display) is, well, badly designed) would use it to write something more generally useful. And, of course, it tracks effects on party members, and of course, I don't think it's actually managed to inspire any plugins whatsoever.
Well, it's funny to me.
Edit: Forgot to note - you can defect effect removals - the key trick here is the fact that the effect lists are always accurate on plugin load.
Last edited by moebius92 : 10-06-2012 at 11:57 AM.
|
|
|
10-06-2012, 09:53 AM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
Quote:
Did you try checking the start time of the effect to determine whether or not the effect is really a recent add? As far as I know, the start time is accurate - otherwise you wouldn't be able to track what percent of the effect's duration is left.
|
Hmmm that could probably work. I will mess around with that and see what happens.
Quote:
Also, you can probably track effects using the unique ID they're assigned, and only considering it a new effect if it's an ID you've never seen before.
|
This would probably add more to the code than I would care to do, considering the start time method might work out better, and I would like to know each time a person receives a debuff, not just the first time. You'd have to keep a table of the IDs you've seen but also remove IDs once the debuff is gone, and it doesn't seem like the EffectRemoved or EffectsCleared events fire for party members, so that would be difficult. Thanks for the suggestions!
Quote:
Edit: The irony of the "This is an experimental plugin.." part of the description just hit me. Definitely amusing. Well, to me.
|
It's experimental because I cannot honestly say for sure if it works 100% of the time or if it even can work, considering the problems and limitations of Turbine's API. Plus I'm not the best with LUA, so part of learning LUA is to try my hand at a few plugins and see what I can come up with. Considering plugins like Alerter, MinstrelBuff, RaidAssistant, Buffbars, Bevy o' Bars, CombatAnalysis, Aura, and VBar (to name a few), already do much of what I'd like to see plugins do, a Party Debuff Tracker-like plugin is one I'd really like to see, so that's the one I started with first. ![Smile](//www.lotrointerface.com/images/style_mmoi_lotroi/smilies/smile.gif)
|
|
|
10-06-2012, 01:44 AM
|
|
The Undying
Forum posts: 51
File comments: 44
Uploads: 15
|
Did you try checking the start time of the effect to determine whether or not the effect is really a recent add? As far as I know, the start time is accurate - otherwise you wouldn't be able to track what percent of the effect's duration is left.
Also, you can probably track effects using the unique ID they're assigned, and only considering it a new effect if it's an ID you've never seen before.
Edit: The irony of the "This is an experimental plugin.." part of the description just hit me. Definitely amusing. Well, to me.
Last edited by moebius92 : 10-06-2012 at 02:16 AM.
|
|
|
10-05-2012, 05:04 PM
|
|
The Undying
Forum posts: 33
File comments: 122
Uploads: 10
|
Re: Channel Option
Quote:
One addition that would be useful is the ability to set the chat channel this outputs to. Posting the message to /raidshout would display the debuffs prominently.
|
That would be a great feature, unfortunately we can only programmically write out to the General chat channel. Any other channel would require a user to click a button, which would defeat part of the purpose of the plugin. Maybe someday they will give us that ability!
|
|
|
10-05-2012, 04:31 PM
|
|
The Undying
Forum posts: 22
File comments: 54
Uploads: 0
|
Channel Option
One addition that would be useful is the ability to set the chat channel this outputs to. Posting the message to /raidshout would display the debuffs prominently.
|
|
|
All times are GMT -5. The time now is 06:22 PM.
|
![](//www.lotrointerface.com/images/style_mmoi_lotroi/layout/clear.gif) |