Minion Beta! - Help us test our new AddOn updater. Get it now!
(150 Kb)
Updated: 11-19-07 11:56 PM
Pictures
File Info

# Relational DKP

Version: 2.1.2.1
by: Shazear [More]

-----------------------------------------
-- By: Shazear
-- Shizukana <Veterans of the Phoenix>, Malygos
-- e-mail: shazear@hotmail.com
-- Code also used from CTRaidTracker
-----------------------------------------

-----------------------------------------
-- Summary:
This addon provides a tool to determine who is most deserving of a given piece of loot based on the work they've done for the guild vs. how they have been rewarded in previous raids. This will eventually work to be an addon/extension of CT_Raidtracker.

-----------------------------------------
-- Dependencies:
Chronos,
Telepathy
Optional:
Khaos

-----------------------------------------
-- Explanation of the problem this Addon is working to help solve:
Problem: Present DKP systems provides disproportionate rewards to people who are able to raid more often. This means that if someone raids less than 1/2 the time of someone else competing for the same gear, that less-often raider will not be able to spend DKP or get that gear until the hardcore player has everything they want. Insert a new hardcore member into the group before that point, and the casual player will never begin getting gear, even potentially after having multiple raids under their casual-belt. Ideally, the ratio of gear to effort should be the same no matter if you raid 3x/week or 1x/month. How do you reward people according to their contribution?

Solution:
* Rewards for attendance. This number will be referred to as DKP.
* Keep gear/loot costs but track them separately. This number will be referred to as GR (gear rewards).
* Change the method for determining priority for loot. New system: Priority (P) = DKP/GR
This new number is what sets priority. Since it is a system that compares the amount of loot you've received with how many times you've gone on a raid, it sets the priority in comparison to the amount of participation. He/She with the highest priority number gets the loot.
So the idea works like this:
1) Priority is established at the start of the raid (or a pre-determined time before - should we ever get to the point that multiple raids could be going on at one time).
2) A piece of loot drops off of a mob in any instance during a raid.
3) Tells to the Raid Leader for who wants it (establish competitive list).
4) Of those on the list, he w/ the highest priority wins.
5) In the case of 2+ people w/ the same & winning priority: Roll.
6) Adjust the GR number of the winner immediately at this point.
7) DKP is added at the end of the raid.
8) Everyone starts w/ a GR value of 1.

Example:
Raid loot of 10GR points drop. Bob and Joe both want it and send tell the RL. RL looks at the priority lists and sees:
Bob: 45dkp/9gr = 5.000 priority
Joe: 100dkp/23gr = 4.348 priority

Because he's the highest priority, based on less gear for the amount of effort he's put in, Bob wins the gear! Bobs new adjusted priority is 45dkp/(9+10)gr = 2.368
It might be a few DKP before Bob tops the loot priority list again.

Complications/Questions:
What about rotting gear, gear that no one wants to spend the priority on but could use?
- If someone gets gear, their GR number increases and their priority drops accordingly.

What about an item that no one wants and is DE'd?
- The item is not acquired by anyone and no GR is spent. The shard is available for rolling on or can be sent to the guildbank.

What if someone goes on a large number of raids and the gear they want just doesn't drop?
- Their dkp continues to increase, putting that player in prime position to get the gear once it does drop.

What if the officers want to reward out-of-raid attendance in the form of raid points?
- They can just increase the DKP in someones roster which will in effect raise their priority for their next loot situation.

What about a player with multiple 60s?
- I believe that attendance and total gear should be tracked on a per-player, not per character basis.

The key things is that GR value raises from items received during the raid; and DKP raises for attendance. Neither value goes negative.

Please, please, please let me know if you think this is total crap, if you have questions, etc. I believe this will make things more fair, but I want your questions/feedback/concerns.

Thank you.

-----------------------------------------
-- Special Thanks:
* My Guild: <Veterans of the Phoenix> & <Your Moms Guild> Malygos-US
For presenting the need to write an addon that distributes loot fairly for both hardcore & casual players. (esp. Gemmy, Plaguel, Skolin & Boomer)
* Sssin: GM <SamasGildae> Kazzak
For assisting with debugging issues in 2.1 before I was able to get into high-level TBC instances.
* thomo_1984:
Helping with expanding docs.
* eloc:
For assisting with usability issues.

-----------------------------------------
-- Changelog:
2.1.2.1:
- Update the Interface version for 2.3
- Adding bosses for Mt. Hyjal. They were still blank for some reason.

2.1.1.2:
- Update the Interface version for 2.2 patch
- Update for additional performance improvements.
- Update for compatibility issue w/ GuildFu
2.1.1.1:
- Adjustment in very basic workflow to improve performance for client machines other than the Raid Leader
- Adding the Purge Raids by Date setting so officers can enter a date into the Khaos UI and then purge all raids prior to that date.
- Adjusted the way debug logging is handled.
- Fixed text bug on the "Show Destroyed Raids" checkbox
2.1.0.20:
- Fix in situations w/ fresh installs in PlayerMapUpdate()
- Update docs.
- Fixed a bug where the Start Recording button would be visible to someone other than the party/raid leader.
- Fixed a bug where the scheduled for time DKP allotment wasn't ending properly.

2.1.0.19:
- Fix for Defect: Reset the Adjustment fields back to 0 so there are not accidental re-allocate of the DKP or GR to people who aren't supposed to be getting those points.
- Attempt to reduce the spamminess of RDKP by putting some locks around particularly noisy code.
Based on feedback from eloc:
- Update CharacterMap to separate out possible collisions for players who have multiple raiding characters on different servers. This refactoring due to some other issues that came up.
- Added option to hide destroyed raids in the raid view. (enabled by default)
- Add button to check all in the character view.

2.1.0.18:
- Updated functionality to clean up the Khaos UI and add extra resiliency for those who don't care about the Old WOW content for DKP and those who don't want to record DKP/GR for 5-mans.

2.1.0.17:
- Error in the way I was determining if we were recording a raid or not, so there were errors during non-recorded raids. (thanks to sag_ich_nicht for reporting this)
- Updated some of the error reports to make this better to spot.

2.1.0.16:
- SetupOnTime scheduling wasn't working as expected. Arguments weren't being passed in when the function was being called, so I re-wrote it.
- Refactored UpdateRaidList() to better handle the differences between Raids and Parties
- Adjusted Hooking of Loot Events to improve performance
- Added Hook for Party Makeup changes
- Fixed party bugs in the Ratio plugin code.
- Fixed bug in the ConvertCode that fires to shift from pre 2.1 to present settings.
- Fixed bug in Khaos Settings code where they were just being set to 0 all the time.
- Fixed bug in filter UI code.
- Added recording of own guild to character map.

2.1.0.15:
- Changed the "Opening the Dark Portal" to "Black Morass" on a hunch.

2.1.0.14:
- Fixed the Escape from Durnholde Keep Instance location issue.

2.1.0.13:
- Fixed bug where the Khaos UI was adjusting all GR sliders for a given Zone regardless of quality of drop.
- Mass manual updates should be working now, finished fleshing out that code
- Fixed typo Mana Tombs should have been Mana-Tombs
- Made progress on supporting DKP/GR for 5-man runs, but still not quite ready.
- Fixed bug in AddZone & AddBoss code areas. Khaos doesn't like return values on it's callbacks.

2.1.0.12:
- Fix for issue on the loot event when iGR was nil at a place I wasn't expecting.
- Moved a couple functions around.
- Did some work to finish implementation of the mass update, not done yet.

2.1.0.11:
- Fixes for localization code

2.1.0.10:
- Moved settings UI to Khaos
- Removed all "defaults" from the DKP & GR settings.
- Added support for 5-man TBC instances
- Added Boss information for TBC instances

2.1.0.9:
- Added feature for recording guild info in the character map.
- Tweaks to Localization implementation
- Streamlined the priority button implementation
- Streamlined the DKP over time implementation
- Implemented the checkboxes before player's names. Next to make that mean something w/ the adjustments.

2.1.0.8:
- Tweaks to get the raiding & RaidUI functionality ready for beta so the officers can start looking at it.

2.1.0.7:
- updated to use Telepathy which is mainly to help w/ table transmissions.
- Additional work for localization support.

2.1.0.6:
- updated my generic sort.
- Updating settings comm codepaths to make it more reliable when generating the hash - still not working.

2.1.0.5:
- Start of localization support.
- Fixed some parsing bugs between the old raids and the new 2.1 version raids.
- Additional TBC data in the settings/maps and such.
- Phase 1 of Settings communication nailing down.
- Scaled back the communication triggered by world events.
- Cleaned up the looting and Disenchanting code to be more reasonable.
- Cleaned up some of the UI code.

2.1.0.4:
- Removed a few unused functions from the previous builds
- Cleaned up Award side bugs
- Pulled out the legacy settings.
- Cleaned up some error messages.
- Modularized some of the functions.
- Made some progress on the Settings UI.

2.1.0.3:
- Alot of changes: Show Raid UI cleaned up and made mostly functional
- Settings UI created and functional.
- Plugin infrastructure created and mostly working.
- Adding comment field to transactions.
- Generic table comm protocol created and mostly working. - There are still some use-case problems.
- Temporarily disabled broadcasting raids (to cut down on some of the work to sort through while debugging).

2.1.0.2:
- Ported most recent 2.0 branch changes.
- Fixed broken XML tags
- Narrowed down some of the problems in my generic table transmission code.

2.1.0.1:
Initial New feature work:
- Feature 1615420: Switched from a hard-coded initial value, to something that is referencing a table in the settings. This initial value will have a system default as well as something stored. Still need to be able to communicate this out to others. Though I expect this to happen during the overall settings re-work.
- Feature 1615422: Initial work for basic fixed price support. Have setting, math function, and logic based on switch. Still need to implement the switch.
- Settings rework: Wrote generic broadcast table function, and have temporary table for holding that info. Needs loads of testing, however, I've stuck it into the Playermap broadcast. If that pans out, then I'll expect/convert all other data broadcasts to use it.

 Comment Options
09-20-07, 11:16 AM
Shazear
A Fallenroot Satyr

Forum posts: 21
 Originally posted by Geboran I love the idea of this addon for DKP management, but see no documentation regarding how you might display information on a guild's website if they so chose to. Any plans of implementing some sort of Export feature (similar to what CT_RaidTracker used to do) for this addon?
Sorry... Yes I have an exporter:

This is the curse location for the addon, and I also have an exporter for the transactions & the guild list. Scroll down to where it has the "additional files" and you'll see an exporter. You pass in the path to the RelationalDKP.lua file in your main character's saved variables folder and it should export it out into a RelationalDKP.html file that will be pretty basic, but should give you something simple to start with, that you can add to if you want to spruce it up a bit.
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

 09-20-07, 08:57 AM Geboran A Rage Talon Dragon Guard Forum posts: 308 File comments: 34 Uploads: 0 I love the idea of this addon for DKP management, but see no documentation regarding how you might display information on a guild's website if they so chose to. Any plans of implementing some sort of Export feature (similar to what CT_RaidTracker used to do) for this addon? __________________ ------------------------------------------ Geboran - Level 70 Paladin Stormreaver (US), Alliance
01-02-07, 02:33 PM
Shazear
A Fallenroot Satyr

Forum posts: 21
Re: Mathematics

 Originally posted by Kaelum Hey Shazear, Over time, your system would suffer from the same issues of other systems as old timers will have huge amounts of DKP and new members will have very low GRs. This will result in new players getting almost anything that they want and old timers getting in very little. However, I think using a zero-based DKP system with your GR, a DKP cap and normalization, might address all issues. For normalization to work, you need to set a DKP cap. Something like the amount of DKP that the average raider would gain in 3 months. You will also need to keep track of 2 additional numbers, normalizedDKP and normalizedGR. They are calculated before each raid and replace the use of DKP and GR durring a raid. Anything added to DKP is also added to normalizedDKP and anything added to GR is also added to normalizedGR. Once the DKP of a player exceeds the 3 month average, then the following calculations would be applied: 1. normalizationRatio = normalizedDKP / <3 month DKP average> 2. New normalizedGR = normalizedGR / normalizationRatio 3. New normalizedDKP = <3 month DKP average> Lets say that the average DKP for 3 months is 10,000 and after the last raid a player has 10,100 normalizedDKP and 2020 normalizedGR. normalizationRatio = 10,100 / 10,000 = 1.01 New normalizedGR = 2020 / 1.01 = 2,000 New normalizedDKP = 10,000 Applying the normalizationRatio into a zero-based DKP system should correct all of the known issues with both systems. You might have to play with what the cap should actually be, as 3 months may either be too long or too short, but once the right number is found everyone should be happy. New members should never have preference over old timers and old timers should not be so far out of reach that new members would never catch up. This hybrid system gives old timers priority until the new members have earned enough DKP to offset the advantage. Once the new member's DKP has reached the cap, they are on fairly equal footing with the old timers and could be considered old timers by then new members. Let me know what you think.
Sorry for the delay, the holidays had me super-busy and away from being able to check posts.

I agree w/ most of what you put here. Infact within my own guild, I've been working on setting up a cap DKP scenario. Rather that this being time-based however, it's threshold based: when a given player reaches the threshold in DKP, their DKP & GR are reduced by a set % (like 1/3). This keeps their Priority ratio the same, but allows for more reasonable level of earning DKP & GR.

The other adjustment is to have new players not start with 1 GR, but rather change it depending on how long we want to see those players be available to compete for the drops. Given the defaults that are presently in the addon, we are looking at 25-50. This gives 2-4 raids depending on velocity of progression.

These changes should be coming in the near future as I work out the kinks for v2.1.x I did make some good progress over the holidays, but there's still some work todo.
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

11-30-06, 02:03 PM
Shazear
A Fallenroot Satyr

Forum posts: 21
Re: More Questions/Suggestions again lol

 Originally posted by Mindleglalaxy 2: Is it possible to have a field like Name etc but one that is Class. I don't know if this is pointless as the above imo should work and I think its just me doing something wrong. But this would still give a quick glimpse to let others see or know who would have priority for their class (more of a where do I stand sought of thing lol). I know it is probably a lot more work as resizing frames and a whole new field but just as they say food for thought.
There's already been a request for this, and I'm looking into ways of doing it w/o havin' to store more data in the RDKP database. And as you mention, it would require a re-design of the UI to accomodate the additional field. However, as I'm making more changes to accomodate the 2.0 features, I'm finding a greater need to possibly do this anyhow. Can't say what the ETA for this is, as there are other features that are a weighing in a bit more heavily, however, it is on the list.

 Anyway apart from that everything is working great no errors etc and points are accurate as well. Thanks again Grodo
My pleasure. I'm glad the bugs have settled down. Performance seems reasonable, and data is working itself out as well.

 PS: Forgot to ask how do you delete someone you don't want on the list anymore. We have had a few pugs come along on raids as we needed numbers but they are not with us anymore or not needed and I cannot find anywhere how to remove/delete them from list pls.
This is coming soon. I've already done the code work for it, and it'll be in the initial builds of 2.0 compatibility next week. I'll probably have beta builds posted over the weekend so that people can have the bits ready when the next patch rolls around.

The feature provides the opportunity to Hide characters from the default view. Only officers will be able to set this bit. And the value will get rolled out to the other users as normal when the addon updates the character mapping. There will be a checkbox to UnHide characters should anyone want to see those people again. However the default will be to keep those hidden.

Unfortunately, there's no way to reliably delete characters from the database, as someone could have info pertaining to that character and the data would just get repopulated or we'd see NIL errors when trying to access that now deleted character (or both LOL).

Shazear
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

 11-29-06, 11:07 PM Mindleglalaxy A Murloc Raider Forum posts: 8 File comments: 59 Uploads: 0 More Questions/Suggestions again lol Hi, Thanks for your quick response its fantastic. 1: For some reason I am rank 1 in the Guild (Guild Leader) and I have others in Rank 2 that use the addon with me till we are 100% confident with it lol. The problem is when I have it set for PST it doesn't list only those that pst me but it does work for anyone in Rank 2 position. I have everything set right was just wondering what is happening and have done fresh install and deleted saved Var files etc but for some reason it just won't work. It said's reset or whatever the words are when I tick it etc but no list of just the people psting me which as you know is annoying. Like I said the other person in rank 2 just ticks the box and the people that pst him are on the list like it should be. This leads me to point 2 lol. Update to above. I am a noob lol forgot to have show raid members ticked before even looking at the pst bit so sorry about that but still would like point 2 considered lol. 2: Is it possible to have a field like Name etc but one that is Class. I don't know if this is pointless as the above imo should work and I think its just me doing something wrong. But this would still give a quick glimpse to let others see or know who would have priority for their class (more of a where do I stand sought of thing lol). I know it is probably a lot more work as resizing frames and a whole new field but just as they say food for thought. Anyway apart from that everything is working great no errors etc and points are accurate as well. Thanks again Grodo PS: Forgot to ask how do you delete someone you don't want on the list anymore. We have had a few pugs come along on raids as we needed numbers but they are not with us anymore or not needed and I cannot find anywhere how to remove/delete them from list pls. Last edited by Mindleglalaxy : 11-30-06 at 01:38 AM.
11-27-06, 02:12 PM
Shazear
A Fallenroot Satyr

Forum posts: 21
Re: More Questions lol

 Originally posted by Mindleglalaxy Hi, Me again lol. Just have some suggestions and questions I would like answered pls. 1: What is TBCD button used for as can't find any info on what it does?

TBD = To be determined. It doesn't actually do anything yet. W/ the next version, it will actually do something for the guild officers/admins, but I haven't written that code yet I just had a button that I didn't want to delete. When I start posting my WoW 2.0 compatible versions, you'll probably see funcationality attached to that button.

 2: When we correct DKP for on time and have adjusted someones Gear Points (for what ever resason) we have to set Gear Points back to zero each time we do DKP changes otherwise it changes both as it remembers Gear Point changes previously made. Was just wondering if it would be easy to default Gear Points value to Zero in its update field once you start on someone elses DKP etc as it also remembers the DKP field which is handy for on time as its the same amount but just very annoying when you forget about Gear Point changes. I know its not a big issue but if you could look at it some time in the future would be appreciated. Also hope this makes sense if not I will try and explain it again . Btw this is the reason we were having issues getting people points back to 0/1 as I stated in a previous post just didn't realise exactly why.
I agree. The problem on my end is that I didn't write that section very well. So there's little nagging issues like that which are still present. I'm working on re-writing that section for the next version, and once I find something that feels right, I'll back-port them to the current in-field version.

 3: When someone is offline/Dissconnected it appears to be still giving them points for raid attendance? Is this supposed to be happening or are we doing something wrong?
Nope, that's correct. When I wrote it, I figured that if someone was disconnected during a moment when the DKP/GR is awarded, that they may have just been forced off for some reason or another that was not necessarily their fault. I can change it to work the otherway, and not award points for those who are D/C'd. I already don't give people who are not in the zone points. So it's not a big adjustment.

I'll add the option to choose to award them or not to the settings for the next version.

 4: Another suggestion lol. Would it be possible to add a field eg square box that can be ticked so that when we manually update someones main toons DKP it also updates their alt. I know people should install the addon and set their main but as you most likely know that isn't easy we have enough trouble getting people using Vent and Ct_raid lol. An example is Grodo is the main toon and Grench is the alt. The person doesn't have the addon installed so cannot set their main. We have to update on time points etc but have to do for both and possibly in some cases they may have 3 toons. If there was a check box we could tick all their toon names and update one which in turn updates all the toons they use and can also be used to set their main etc and add Gear Points to all etc etc. Hope that makes sense I just have a horrible feeling it will cause you a massive amount of work. If it does or isn' worth doing we will just persist as it doesn't appear that anyone else has mentioned this issues like this?
I already have a feature in the works for Admins/officers to be able to set alts for people. IE. If you know that Grodo here doesn't want to use the addon, then you as the officer could set his alts to be Grench and Gromble. Or something along those lines. Also, by default, the addon consolidates awards amongst all the alt characters, so by awarding to all the alts, you're actually awarding the points to that 1 player mulitple times.

 Again hope I am not being a pain in the butt lol. But we really like your addon and hope we can help by contributing a bit. Thanks again for all your support and looking forward to your response. Thanks Grodo
Not a pain at all! I love getting the feedback as it helps me fine-tune the direction I take things in the future, and can fix problems as they arise.
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

 11-25-06, 01:47 AM Mindleglalaxy A Murloc Raider Forum posts: 8 File comments: 59 Uploads: 0 Thanks Will do any issues will try and let you know as this is a great addon and I am pleased to be able to help. Thanks again
11-24-06, 05:45 PM
Shazear
A Fallenroot Satyr

Forum posts: 21

 Originally posted by Mindleglalaxy Hi, I just downloaded the newest version 1.0.1.4 while writing my comments the problem is I keep getting these error constantly and needed to disable the addon :-(. We are raiding this weekend so hope you can help with the error or let me know if I may have done something wrong as trying to reset everyones DKP lol but I think as you suggested easier to get everyone with it to delete their files. RelationalDKP\\RDKP_Data.lua:188: attempt to compare nil with number\nRelationalDKP\\RDKP_Data.lua:188: in function \n: in function `sort'\nRelationalDKP\\RDKP_Data.lua:180: in function `RDKP_SortTableByField'\nRelationalDKP\\RDKP_Data.lua:169: in function `RDKP_SortMasterListbySetting'\nRelationalDKP\\RDKP_Data.lua:154: in function `RDKP_UpdateMasterPlayerList'\nRelationalDKP\\RDKP_main.lua:87: in function `RDKP_OnEvent'\n:\"RelationalDKP_TopFrame:OnEvent\":2: in main chunk\n\n ---", This is printed from Buggrabber so hope it is what you need and I am on enUS client on Oceanic Server. Thanks again for such a quick response and anything I can do to help I will try and do. Take care
Thank you, that was perfectly the information I needed.
I've posted what should fix your problem. Let me know if you find anything else.
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

 11-23-06, 07:55 AM Mindleglalaxy A Murloc Raider Forum posts: 8 File comments: 59 Uploads: 0 Error with newest version Hi, I just downloaded the newest version 1.0.1.4 while writing my comments the problem is I keep getting these error constantly and needed to disable the addon :-(. We are raiding this weekend so hope you can help with the error or let me know if I may have done something wrong as trying to reset everyones DKP lol but I think as you suggested easier to get everyone with it to delete their files. RelationalDKP\\RDKP_Data.lua:188: attempt to compare nil with number\nRelationalDKP\\RDKP_Data.lua:188: in function \n: in function `sort'\nRelationalDKP\\RDKP_Data.lua:180: in function `RDKP_SortTableByField'\nRelationalDKP\\RDKP_Data.lua:169: in function `RDKP_SortMasterListbySetting'\nRelationalDKP\\RDKP_Data.lua:154: in function `RDKP_UpdateMasterPlayerList'\nRelationalDKP\\RDKP_main.lua:87: in function `RDKP_OnEvent'\n:\"RelationalDKP_TopFrame:OnEvent\":2: in main chunk\n\n ---", This is printed from Buggrabber so hope it is what you need and I am on enUS client on Oceanic Server. Thanks again for such a quick response and anything I can do to help I will try and do. Take care
11-23-06, 02:01 AM
Shazear
A Fallenroot Satyr

Forum posts: 21
Re: Questions

 Originally posted by Mindleglalaxy 1: When we do a /rdkp_resetall nothing seems to reset and I am the Guild Leader as well as Raid Leader.
At this time reset all actually just resets all the settings back to the defaults which are hard-coded. There is a function for resetting the transaction register, however I didn't expose it via a slash command. I was afraid people would be deleting data in-advertantly. Whereas deleting the savedvariables files (RelationalDKP.lua) in both the character specific and the general area would accomplish the same thing.

Also, since the storage is distributed/shared amongst each person w/ the addon, getting the register blanked out is not yet possible. You'd have to have each person remove their saved variable files and not run the addon until everyone's data is wiped before starting from scratch.

I have the feature for wiping out raids in-works (tracked on my sourceforge site), but it's still a ways off. I've been focusing on working out bugs that are still being found by users such as yourself, and getting the WoW 2.0 changes implemented.

 2: Is there anyway to have points etc allocated for different instances. We would like to run points seperatly for ZG and MC etc but not sure how to with this addon or if it is even needed/possible? Any feed back is appreciated in regard to this question please.
It's not possible at this time, however, I'll add it to the feature request list. I do not yet have an eta for this feature. However feel free to track/comment: http://sourceforge.net/tracker/index...97&atid=881869

The original goal was to spread PRI out over every instance so that work done in 1 can translate to all future raid instances performed by a guild. However, I can see how that may not work for a quickly advancing guild, that may have newer members gearing in AQ20 or ZG, with older members in NAXX or something similar. So I agree it's a valuable feature.

 3: To change someones points back to lets say 0/1 we can't seem to do it easily. If I had 120/12 I would enter -120 for dkp and then -11 for Gear but don't seem to get 0/1 back it just keeps changing to different values. Obiously I am doing something wrong so any help would be appreciated.
In theory, that's how it's supposed to work. And it works that way for *most* situations. The small scale testing showed no errors, However, there does seem to be a lag/difference between differing members of a given guild/raid alliance on what someone's scores should be. A recent discrepency was reported by a fellow guildie, and I'm researching what I can do to help ensure the accuracy of the values, but I haven't found anything yet.

 4: Is there a way to select an option to award on time points for people who are at the instance on time instead of manually adding them in?
That's also to be implemented. I actually have the place-holder in the settings for that value, but couldn't find the best method on *how* to implement it. I believe I've recently come across a good way, but will require some work to ensure that it works as I intend. I can understand how manually adding 10 DKP for 40 players can be a bit of pain.

 Thanks again for a great addon keep up the great work. [/b]
Thank you for your feedback. I'm always excited when new people find the work useful.
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

11-15-06, 08:04 PM
Shazear
A Fallenroot Satyr

Forum posts: 21
Re: Where does this track its data?

 Originally posted by SifOfSwC More importantly, say we have multiple raid leaders. How can the priority data be shared? Nice, BTW.
Thank you. I'm pleased w/ how it's come around.

Data is stored locally per-character in most cases, however there is some data that is per-account. Then data is shared via the Addon channels. So there is some delay due to syncronization requirements.

The model works thusly:
During the Raid, all attendees of the raid get the information that occurred during their attendance. The member who is actually the RL is the one required to have the addon, and is the "authority/server" of the raid data. The transactions are saved to a table, and then once the raid is over, that data is made available to the entire guild. This method allows for the opportunity for Guild Alliances to work as well, since the Raid Leader can be from either, and the attendees from both guilds will get the data along the Addon RAID channel. Then the data will be distributed along the Addon Guild channel to the members of the individual guilds. The only requirement in this case is that members of both guilds have to have the addon.

Settings and priority data then should be up-to-date for everyone w/ the addon before each raid. In practical experience w/ my guild, the over-lap only needs to be a couple members on at any given time. If you're raid attendance is mostly consistent, then this shouldn't be a problem. If you have separate groups, like all morning and a separate all evening group, then getting 1 group to talk to the other is a bit of a challenge, however, the wider the use of the addon in the guild, the better the data reliablity.

I hope this answers your question, and helps clear things up. If not, feel free to ask away.
__________________
Shazear:
Shizukana (Holy Priest)
UnShiz (UnHoly Death Knight)
Veterans of the Phoenix
Malygos

 11-15-06, 03:45 PM SifOfSwC A Kobold Labourer Forum posts: 0 File comments: 6 Uploads: 0 Where does this track its data? More importantly, say we have multiple raid leaders. How can the priority data be shared? Nice, BTW.

Category Jump: