-- Addon: Relational DKP
-- By: Shazear
-- Shizukana <Veterans of the Phoenix>, Malygos
-- e-mail: firstname.lastname@example.org
-- Code also used from CTRaidTracker
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.
-- 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?
* 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.
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.
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.
-- 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.
Helping with expanding docs.
For assisting with usability issues.
- Update the Interface version for 2.3
- Add content for Zul'Aman.
- Adding bosses for Mt. Hyjal. They were still blank for some reason.
- Update the Interface version for 2.2 patch
- Update for additional performance improvements.
- Update for compatibility issue w/ GuildFu
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- Changed the "Opening the Dark Portal" to "Black Morass" on a hunch.
- Fixed the Escape from Durnholde Keep Instance location issue.
- 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.
- 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.
- Fixes for localization code
- Load order issues.
- 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
- 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.
- Tweaks to get the raiding & RaidUI functionality ready for beta so the officers can start looking at it.
- updated to use Telepathy which is mainly to help w/ table transmissions.
- Additional work for localization support.
- updated my generic sort.
- Updating settings comm codepaths to make it more reliable when generating the hash - still not working.
- 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.
- 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.
- 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).
- Ported most recent 2.0 branch changes.
- Fixed broken XML tags
- Narrowed down some of the problems in my generic table transmission code.
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.