Posted this in the main DKPMon thread as that is where Xerophyte last posted the availability of the mod but not sure if he reads that thread or not...
Wondering if anybody can help me. Am trying to use the DKPMon_EPGP/Bidder_EPGP modules with DKPMon and getting the following error when trying to decay points:
Interface\AddOns\DKPmon_EPGP\epgp.lua:629: attempt to call method 'GetTable' (a nil value)
Stack trace:
-----------
...erface\AddOns\FuBar\libs\Dewdrop-2.0\Dewdrop-2.0.lua:710: in function <...erface\AddOns\FuBar\libs\Dewdrop-2.0\Dewdrop-2.0.lua:649>
Anybody have a clue what to do with this to get it working?
Sorry for not getting back to your PM sooner, replied there as well. So, short answer:
My implementation of decay is a crappy hack, which I knew and was secretely very ashamed of. I figured it still worked, which it apparently doesn't. Rewrite pending, I just haven't had time lately.
Edit: Err. Okay, this may have been easier than I thought ... it sorta looks like I need to change all of one line here. *cough*. Let me just make a pretense of professionalism and actually debug first, though.
Bugfix commited, should work (or does for me at least), try it and let me know. Still brutally decays everyone in the database, but that's really prefered behaviour so I'm not very fussed.
Will give this version a try and let you know. Usually the preferred method IS to deduct the points from everybody's EP and GP simultaneously, so that's as you said the preferred behavior so exactly what I'd be looking for!
BTW, since I have your attention...how do I input price values? Do I just edit the custom.lua file and fill it in with the item name and price?
Most EPGP systems use a fixed GP price based upon the itemlevel, slot, and rarity (http://code.google.com/p/epgp/wiki/WhatIsEPGP_v2) so are there ways to implement that as the cost in the addon? Another way could be to use ItemLevelDKP's prices and just refer to that addon...although I've been modifying my ItemLevelDKP LUA towards the actual GP formula above, hehehe.
Yes, just edit custom.lua. What you want to do is basically rename the included example.lua to custom.lua and edit that to reflect your raid group's prefered settings, as well as removing the lines
-- CHECK FOR EXISTING CUSTOMINFO --
if DKPmon.CustomInfo.db["EPGP"] ~= nil then
--Already registered, don't register example settings
return
end
DKPmon:Print("DKPmon_EPGP is using the example.lua file, you should create your own settings in custom.lua")
-- REMOVE ABOVE SECTION IN YOUR CUSTOM.LUA FILE --
There are bits for determining how many different EPGP pools you use, which systems of timed EP you have and, last and largest, how much an item costs in GP and from which pool.
As for implementing the official EPGP formula or ItemLevelDKP as a default value for items not included in a custom file: it's doable, certainly. However I feel both formulae are rather poorly designed and so I've no real desire to include them as programmatic GP. You can edit custom.lua and add loot priced according to them if you prefer, no worries, but that's very likely to be the only way to do it.
If anyone is curious, I do have an algorithm I use to determine the GP costs in example.lua, which is also what my raid group uses regularly. The formula is basically:
itemLvl: Self-explanatory slotFactor: Basically the same as EPGP's, except for weapons. Weapons get dps, feral ap, healing or damage for "free", which is very significant. As such I use factors 3 for 2h and 1-2 for 1h, rather than EPGP's 1 and 0.42. instanceFactor: The "T4" instances are currently using 1, the "T5" instances 1.35. "T6" content will likely be about 1.8. This because me and most of my raid group felt linear scaling with ilvl was a bit too weak: 100 GP for T4 and 111 for T5 - what you get with straight ItemLevelDKP - didn't reflect how we valued drops. qualityFactor: Wholly subjective multiplier based on how close I feel the item is to ideal for its intended role. Perfect stat distribution is a 1, truly ill-designed items an 0.1, with everything else in between.
Obviously, large parts of this is inherently subjective and won't please everyone. However, this is my addon so: everyone, I thumb my nose at thee. :)
first off, this mod is awsome :) This whole EPGP is, and this addon feels like it is going to make it easy.
My guild haven't started using EPGP or the addon yet, have just tried it out with a couple of friends, and some questions arrised.
First off, we are going to try and convert our old DKP into EPGP points, so how can I manually add all my members with their values?
Also, would it be possible to request some sort of visual confirmation when you decay the database? And also some sort of "Do you really want to do this?", because it feels very easy do over do it, and miss double click and get two times decay.
And while I'm at it, might not fit in here, but do you use eqDKP to show your guilds EP/GP/PR? And how does that work, as eqDKP dosen't work with those values. Or do you suggest some other system to show the EPGP on our homepage?
First off, we are going to try and convert our old DKP into EPGP points, so how can I manually add all my members with their values?
There's no particularly simple way. You can use the "append custom" features of the award window to add EP & GP or - which is honestly simpler if you're doing large changes - you can edit dkpmon.lua under saved variables. Importing data from elsewhere isn't something I much intend to support, so I'm afraid it'll take a bit of grunt work to do.
Also, would it be possible to request some sort of visual confirmation when you decay the database? And also some sort of "Do you really want to do this?", because it feels very easy do over do it, and miss double click and get two times decay.
[..]
Would it be possible to make the Greed bid worth 50% of the items GP?
So people can bid Greed on items they want for example PvP and hybris classes.
I've added both these, in the latest revision executing decay has an "are you sure?"-type pop-up and you can also set a percentage in the dkp system options dropdown that's used to determine the relative cost of a greed bid compared to a need bid.
And while I'm at it, might not fit in here, but do you use eqDKP to show your guilds EP/GP/PR? And how does that work, as eqDKP dosen't work with those values. Or do you suggest some other system to show the EPGP on our homepage?
Yeh. eqDKP, like all tracking systems I know of, work on the assumption that priority value is a difference and not a quotient. Which makes them more or less fundamentally incompatible with EPGP, which in turns makes keeping point changes and the reasons for them logged a bit of a chore. What I use is partly hand-kept records for points in and out per raid coupled with a crude PHPBB export plugin, shamelessly hacked the one Astaldo posted in the main DKPmon thread, that exports the database as very, very simple BBcode. I'll attach it, but it's really, really not a finished addon. It only works with single pools, for instance, and although the results are sorted they're very much not pretty. Not to mention that my code - especially the regexps, which I had no prior experience with - is mostly horrible. Heck, I've not even changed the author credit. But it works and it might come in handy; feel absolutely free to hack at it, you can only make it better. :)
Like Mithoron I was using the same DKP tool that appears all but dead. I've been really interested in the simplicity of the EPGP system for a while now but would never touch a mod that stores data in guild and officer notes. Enter your mod for DKPmon and my life now has a bit of hope to it :)
Now for my problem/requests
1. One of the features we have always used in my guild relating to DKP is a seperation of class items vs general use items. Is it possible to have seperate GP pools against the same EP pool? It seems to me that with an EPGP system this should be relatively easy but I'm not sure how badly you had to hack at the core of DKPmon to make it understand EPGP in the first place.
2. Is it possible to add a description to a EP point addition or subtraction? We would like to award EP points to individual members as well as the potential to penalize members when required, but while playing with the mod I couldn't find a way to add a simple description as to why the points were being added. Truth be told, I'm not even sure how added EP points are stored in the tables at this point (probably should've looked first) is each point event stored in the lau as a seperate line?
I'm going to start looking at the code and see what I can accomplish on my own, I've become a pretty good hack when it comes to changing things that already exsist. Anything you can do to point me in the right direction would be apreciated.
1. One of the features we have always used in my guild relating to DKP is a seperation of class items vs general use items. Is it possible to have seperate GP pools against the same EP pool? It seems to me that with an EPGP system this should be relatively easy but I'm not sure how badly you had to hack at the core of DKPmon to make it understand EPGP in the first place.
Short version is that DKPmon tracks 2 basic variables for every character in ever pool: Earned and Spent. My particular ugly hack is that I redefine DKP from DKP = Earned - Spent to DKP = Earned/Spent, and thus there's EPGP instead. Although this is easy, and perhaps even elegant as far as ugly hacks go, it makes what you're suggesting rather tricky to just implement with light changes in DKPmon_EPGP and also somewhat beyond my intended scope for the mod. I'm aiming for a decent implementation of EPGP, not all possible variants and derivatives thereof. :)
If you want to hack it in you'd need to do some rather wonky things with the concept of a "DKP pool". Basically, what "DKPmon_VlornEPGP" (or somesuch) would display to the user as 1 pool would internally have to be handled as 2 pools, with identical values for Earned and different values for Spent. So when the user selects "pool 1" for something on his end, you'd internally be using DKPmon's pools 1 & 2, if the user is on his pool 2 you'd internally be on pools 3 & 4 and so on.
This'd be relatively major surgery. You'd have to modify pretty much every function in DKPmon_EPGP and Bidder_EPGP in some small way to make sure it checks for the right pools and displays the right thing, restructure the on Click-functions in Bidder_EPGP and PlaceBid() in DKPmon_EPGP to make sure the user can place your specific bid types, and probably a number of other things. It's better than starting from scratch, even with my code, but still a relatively significant rewrite.
2. Is it possible to add a description to a EP point addition or subtraction? We would like to award EP points to individual members as well as the potential to penalize members when required, but while playing with the mod I couldn't find a way to add a simple description as to why the points were being added. Truth be told, I'm not even sure how added EP points are stored in the tables at this point (probably should've looked first) is each point event stored in the lau as a seperate line?
Specific descriptions for different point events is supported by DKPmon, the reason all custom changes show up as simply "Custom" is really just me being lazy. I'll see about doing something about it tomorrow.
As it stands penalising someone's EP is something you can't easily do with my current implementation, the inherited Awarding interface only modifies "DKP" and DKPmon_EPGP thus simply treats any input of negative DKP in when awarding points as adding GP; never as subtracting EP. I've been considering decent ways to implement doing specific changes to each point type, but creating a workable interface for it is very much non-trivial given my rather weak lua skills. :)
I'll happily try to help out with any questions you have about _EPGP, if any bits of the code are a bit hard to follow. I'm fairly sure I still remember what all of it does...
So after presenting EPGP and Xero's mod to the guild I got some interesting feedback from some of my guildies who really like playing with numbers and they brought up some valid points/limitations with the EPGP system, particularly with how decay is handled.
The ideal GP value to have is obviously a 1 which makes your priority directly correlate with your EP value, each time you are awarded an item your GP value gets increased by the "GP Cost" of the item. As stated above your priority EPGP is computed by dividing your EP value by your GP value.
An interesting side effect of the system is that new players effectively start with an ideal GP of 1, pretty much putting them at the top of the priority list against almost any player with a GP value higher than 10 (new playerA EP 1000 GP 1 = EPGP of 1000, vs playerB EP 9999 GP 10 = EPGP 999.9) to combat this and make the system a little more balanced, new players must earn a minumum ammount of EP before they may bid on an item. We use a value of 3000 which works out to about 3 raids attended before bidding.
Decay is integral to the system as it provides two main functions.
1. Reduce the ability of players to "hoard" EP points by effectiviely aging out EP, because decay operates on a percentage, the more EP points a player has accumulated the harder he is hit by a percentage reduction. This allows new players to the raid to be able to effectively compete with older raiders in a relative short amount of time. Decay also has the effect of "capping" the total amount of EP a player may have and maintain. If the player earns 2000 EP per week with a 10% per week decay, the maximum EP value a player may realisitically hold is ~18000 EP, the same values with a weekly decay of 30% limits the player to ~4666 EP.
Decaying EP also has the unintended (or intended) effect of reducing a players EP value even if he is not raiding, with an EP decay of 30% a player with max EP(4666) will be reduced to 785 in just 5 decay iterations, More importantly he will fall below the mininmum required EP to bid (3000), in just 2 iterations.
2. The second function of decay is to effectively reduce the amount of GP charged to the player thus "aging out" his GP value from equipment earned in an effort to reduce his charged GP to an ideal value of 1.
By taking a lot of the defaults for the system we ran the numbers;
Using the base item as Tier4 shoulders from gruul's lair, this item is valued at 100GP for all players.
With a default GP decay of 10% it will take 44 weeks to reduce the GP cost of this item to a value of 1.
Now considering that two shoulders drop per weekly run, a balanced system would age out the GP charge in ~13 weeks (this assumes a perfect drop percentage of shoulder types).
In order to decay a value of 100GP in thirteen weeks we would need a weekly decay percentage of 30%.
So have I confused you enough yet?
The problem is that by tieing both the EP and GP value to the same percentage it becomes very difficult to keep the system fair and balanced for all raiders, specifically it heavily wieghts the system to new players entering the raid group and seems to unfairly penalize regular raiders.
The answer to me and my guild seems simple enough however, by allowing EP and GP to decay at separate rates you can effectively fine tune the system to be more balanced by allowing GP to decay faster than EP is lost. This would have the effect of decaying GP at 30% allowing 100 GP to properly age out in 13 weeks, while not placing the EP ceiling so low that it penalizes regular raiders.
I've modded Xero's code to support the following;
1. EP and GP decay rates are uniquely definable within the UI
2. The current decay rates are stored within the database.
3. Changed the decay rate option boxes to use sliders similar to "greed factor"
4. When decaying the database the "are you sure?" dialog displays they rates you are going to decay the database.
The mod supports the previous way of decaying the database simply by setting both sliders to the same rate.
Xero,
Would you look at the changes I made and if they work for you could we add them into your main code branch? If not I'll start my own branch. I've only modified the DKPmon_EPGP epgp.lau and the localization.enUS.lua
Attached are the files I've modified from the DKPmon_EPGP directory.
As for implementing the official EPGP formula or ItemLevelDKP as a default value for items not included in a custom file: it's doable, certainly. However I feel both formulae are rather poorly designed and so I've no real desire to include them as programmatic GP. You can edit custom.lua and add loot priced according to them if you prefer, no worries, but that's very likely to be the only way to do it.
Would this apply to DKPmon_EPGP in the same fashion as was discussed in a FCZS section of the initial DKPmon thread (pg2):
Quote from Daelic »
You could use HoB_DKP... if you go back in the post, you'll see us going back and forth to make dkpmon get the values directly from hob. My final post on the subject is the final function change needed to make it all work. http://www.wowace.com/forums/index.php?topic=4046.msg80356#msg80356
Perhaps HoB's formulae could be altered to use the exact EPGP standard, for those that desire it.
I was under the assumption that the decay was based off the original value of the item looted or the dkp earned on the raid. In other words if you payed 10 GP for an item, I assumed that it would decay to 9 on the first iteration, 8 on the second, etc. Is this the case? If not, is there any reason why it couldn't be programmed as such?
Flynn,
No, decay is based off your total GP value, to handle it any other way would be hugely intensive as you would need to track and decay each item earned seperately. I'm pretty sure that both this mod and the original EPGP mod work the same way in this respect.
We're just getting started working with DKPmon and the epgp module. Love it so far but was wondering if anyone has been doing any work into modding the output format to allow for direct import of the dkp string into the rapid raid system used by Guildlaunch sites? What it produces now tracks attendance fine, but all the custom events and loot seem to be getting lost.
With the new implementation of a minimum base GP much of the decaying problems are resolved...when will the next version support this?
Basically a guild sets a minimum GP which is NON-DECAYING for the tiered instance they are on. We currently are going to implement a 100 base GP as of today. What this means is new people and people under 100 GP have a "virtual" GP of 100...so somebody with 90 GP and 100 GP both have the same GP.
What this does is normalizes new people entering the guild as well as new guilds implementing the features. EVERYBODY basically starts off with x/100 priority...so those who attend more are more likely to get items over somebody new in the guild who just attended one raid and has 100+ priority.
It also alleviates the problem if GP going under 1 and auto-inflating priority.
_________________________________________________
In regards to DkDrunk's comment, you would probably have to work with the Guild Launch folks to come up with a set way to export the points; however, since DKPMon does not track LOOT I still find Guild Launch's modified CTRT better in this regard. Also, the new export feature Guild Launch is releasing today allows you to set the format to export your values...which can then be imported into DKPMon_CSV and imported for your raids. I've personally be alpha testing the export feature for a few weeks now and it makes things INCREDIBLY easier.
This is how we utilize EPGP in our guild:
1. Raid Leaders are running DKPMon, DKPMon_EPGP, DKPMon_CSV and Guild Launch's modified CTRT.
2. EVERYBODY is running Bidder and Bidder_EPGP
3. Prior to a raid, we export the points off Guild Launch's site into DKPMon_CSV. This is then imported in game.
4. Run the raid using DKPMon/Bidder to record bids.
5. Once the raid is over, we upload the CTRT DKP String to Guild Launch and set up the other rewards and whatnot.
Although a bit cumbersome at first, I now have things down to 5 minutes preparation before a raid and about 15 minutes after a raid to get things set up. We also use WWS Stats pages so I can verify who was at each attempt and gets hourly rewards and bosskills...so that serves as my "backup" in case the game crashes or whatnot and the lua files get screwed up, hehehe. The points are imported at the beginning of each raid so they're in synch with the website...this prevents having to do any alt-tabbing out of the game to look up points.
Perhaps HoB's formulae could be altered to use the exact EPGP standard, for those that desire it.
I actually utilize ItemLevelDKP for pricing. I've modified the formulae so it conforms to the EPGP pricing scheme since I like that better and have renamed the addon for my guild so WoWAce Updater does not overwrite it whenever it gets updated, hehehe...
Hob's could also be used but up until recently it had not been updated in MONTHS so I didn't want to use it for fear of it suddenly breaking...
Actually if you look at the logging section of DKPmon, it does indeed track loot as well as individual point awards, which sadly the CT-Raidtracker remains blissfully ignorant of. The DKPmon_eqdkp export module already can be used to generate a string that is very much like the dkp string from CT_Raidtracker and will allow a partial upload of the log into Rapid Raid. Just the syntax is a bit off between the strings and needs some refining. That's why the Loot and custom point award events are being lost in translation.
We are giving periodic awards out for attendance based on specific time periods, generally 1/2 hr or hourly increments, and having to swap back and forth to WWS to check everyones attendance and tweaking it in seems a rather cumbersome way of doing things when the events are already there in the DKP string waiting to be used.
I was just wondering if someone had already started working on a way to do just that rather than learn to program; (where should I begin? I know bubkiss about Lua programming.); and start trying to mod it myself .
And I'm very glad to hear about the direct import to DKPmon_CSV feature working so well, that'll be very handy.
Actually if you look at the logging section of DKPmon, it does indeed track loot as well as individual point awards, which sadly the CT-Raidtracker remains blissfully ignorant of. The DKPmon_eqdkp export module already can be used to generate a string that is very much like the dkp string from CT_Raidtracker and will allow a partial upload of the log into Rapid Raid. Just the syntax is a bit off between the strings and needs some refining. That's why the Loot and custom point award events are being lost in translation.
Could you let me know what parts of the syntax are off? Also, does guild launch use a modified DKP string? i.e. Different syntax than the standard eqDKP import string? If it's a fault in my DKP string syntax that also doesn't work with eqDKP then I can fix that. Otherwise, I can pretty easily add another export option for the guild launch modified DKP strings...
-Eraslin (author of DKPmon)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Wondering if anybody can help me. Am trying to use the DKPMon_EPGP/Bidder_EPGP modules with DKPMon and getting the following error when trying to decay points:
Interface\AddOns\DKPmon_EPGP\epgp.lua:629: attempt to call method 'GetTable' (a nil value)
Stack trace:
-----------
...erface\AddOns\FuBar\libs\Dewdrop-2.0\Dewdrop-2.0.lua:710: in function <...erface\AddOns\FuBar\libs\Dewdrop-2.0\Dewdrop-2.0.lua:649>
Anybody have a clue what to do with this to get it working?
Thanks in advance!
My implementation of decay is a crappy hack, which I knew and was secretely very ashamed of. I figured it still worked, which it apparently doesn't. Rewrite pending, I just haven't had time lately.
Edit: Err. Okay, this may have been easier than I thought ... it sorta looks like I need to change all of one line here. *cough*. Let me just make a pretense of professionalism and actually debug first, though.
Will give this version a try and let you know. Usually the preferred method IS to deduct the points from everybody's EP and GP simultaneously, so that's as you said the preferred behavior so exactly what I'd be looking for!
Will give it a try tonight and let you know!
Thanks you very much!
Most EPGP systems use a fixed GP price based upon the itemlevel, slot, and rarity (http://code.google.com/p/epgp/wiki/WhatIsEPGP_v2) so are there ways to implement that as the cost in the addon? Another way could be to use ItemLevelDKP's prices and just refer to that addon...although I've been modifying my ItemLevelDKP LUA towards the actual GP formula above, hehehe.
Thanks again! Appreciate the work and addon!
-- CHECK FOR EXISTING CUSTOMINFO -- if DKPmon.CustomInfo.db["EPGP"] ~= nil then --Already registered, don't register example settings return end DKPmon:Print("DKPmon_EPGP is using the example.lua file, you should create your own settings in custom.lua") -- REMOVE ABOVE SECTION IN YOUR CUSTOM.LUA FILE --There are bits for determining how many different EPGP pools you use, which systems of timed EP you have and, last and largest, how much an item costs in GP and from which pool.
As for implementing the official EPGP formula or ItemLevelDKP as a default value for items not included in a custom file: it's doable, certainly. However I feel both formulae are rather poorly designed and so I've no real desire to include them as programmatic GP. You can edit custom.lua and add loot priced according to them if you prefer, no worries, but that's very likely to be the only way to do it.
If anyone is curious, I do have an algorithm I use to determine the GP costs in example.lua, which is also what my raid group uses regularly. The formula is basically:
itemLvl * slotFactor * instanceFactor * qualityFactor
itemLvl: Self-explanatory
slotFactor: Basically the same as EPGP's, except for weapons. Weapons get dps, feral ap, healing or damage for "free", which is very significant. As such I use factors 3 for 2h and 1-2 for 1h, rather than EPGP's 1 and 0.42.
instanceFactor: The "T4" instances are currently using 1, the "T5" instances 1.35. "T6" content will likely be about 1.8. This because me and most of my raid group felt linear scaling with ilvl was a bit too weak: 100 GP for T4 and 111 for T5 - what you get with straight ItemLevelDKP - didn't reflect how we valued drops.
qualityFactor: Wholly subjective multiplier based on how close I feel the item is to ideal for its intended role. Perfect stat distribution is a 1, truly ill-designed items an 0.1, with everything else in between.
Obviously, large parts of this is inherently subjective and won't please everyone. However, this is my addon so: everyone, I thumb my nose at thee. :)
first off, this mod is awsome :) This whole EPGP is, and this addon feels like it is going to make it easy.
My guild haven't started using EPGP or the addon yet, have just tried it out with a couple of friends, and some questions arrised.
First off, we are going to try and convert our old DKP into EPGP points, so how can I manually add all my members with their values?
Also, would it be possible to request some sort of visual confirmation when you decay the database? And also some sort of "Do you really want to do this?", because it feels very easy do over do it, and miss double click and get two times decay.
And while I'm at it, might not fit in here, but do you use eqDKP to show your guilds EP/GP/PR? And how does that work, as eqDKP dosen't work with those values. Or do you suggest some other system to show the EPGP on our homepage?
Thank you for your time.
/Thorium
So people can bid Greed on items they want for example PvP and hybris classes.
/Thorium
There's no particularly simple way. You can use the "append custom" features of the award window to add EP & GP or - which is honestly simpler if you're doing large changes - you can edit dkpmon.lua under saved variables. Importing data from elsewhere isn't something I much intend to support, so I'm afraid it'll take a bit of grunt work to do.
I've added both these, in the latest revision executing decay has an "are you sure?"-type pop-up and you can also set a percentage in the dkp system options dropdown that's used to determine the relative cost of a greed bid compared to a need bid.
Yeh. eqDKP, like all tracking systems I know of, work on the assumption that priority value is a difference and not a quotient. Which makes them more or less fundamentally incompatible with EPGP, which in turns makes keeping point changes and the reasons for them logged a bit of a chore. What I use is partly hand-kept records for points in and out per raid coupled with a crude PHPBB export plugin, shamelessly hacked the one Astaldo posted in the main DKPmon thread, that exports the database as very, very simple BBcode. I'll attach it, but it's really, really not a finished addon. It only works with single pools, for instance, and although the results are sorted they're very much not pretty. Not to mention that my code - especially the regexps, which I had no prior experience with - is mostly horrible. Heck, I've not even changed the author credit. But it works and it might come in handy; feel absolutely free to hack at it, you can only make it better. :)
Like Mithoron I was using the same DKP tool that appears all but dead. I've been really interested in the simplicity of the EPGP system for a while now but would never touch a mod that stores data in guild and officer notes. Enter your mod for DKPmon and my life now has a bit of hope to it :)
Now for my problem/requests
1. One of the features we have always used in my guild relating to DKP is a seperation of class items vs general use items. Is it possible to have seperate GP pools against the same EP pool? It seems to me that with an EPGP system this should be relatively easy but I'm not sure how badly you had to hack at the core of DKPmon to make it understand EPGP in the first place.
2. Is it possible to add a description to a EP point addition or subtraction? We would like to award EP points to individual members as well as the potential to penalize members when required, but while playing with the mod I couldn't find a way to add a simple description as to why the points were being added. Truth be told, I'm not even sure how added EP points are stored in the tables at this point (probably should've looked first) is each point event stored in the lau as a seperate line?
I'm going to start looking at the code and see what I can accomplish on my own, I've become a pretty good hack when it comes to changing things that already exsist. Anything you can do to point me in the right direction would be apreciated.
-Vlorn
Short version is that DKPmon tracks 2 basic variables for every character in ever pool: Earned and Spent. My particular ugly hack is that I redefine DKP from DKP = Earned - Spent to DKP = Earned/Spent, and thus there's EPGP instead. Although this is easy, and perhaps even elegant as far as ugly hacks go, it makes what you're suggesting rather tricky to just implement with light changes in DKPmon_EPGP and also somewhat beyond my intended scope for the mod. I'm aiming for a decent implementation of EPGP, not all possible variants and derivatives thereof. :)
If you want to hack it in you'd need to do some rather wonky things with the concept of a "DKP pool". Basically, what "DKPmon_VlornEPGP" (or somesuch) would display to the user as 1 pool would internally have to be handled as 2 pools, with identical values for Earned and different values for Spent. So when the user selects "pool 1" for something on his end, you'd internally be using DKPmon's pools 1 & 2, if the user is on his pool 2 you'd internally be on pools 3 & 4 and so on.
This'd be relatively major surgery. You'd have to modify pretty much every function in DKPmon_EPGP and Bidder_EPGP in some small way to make sure it checks for the right pools and displays the right thing, restructure the on Click-functions in Bidder_EPGP and PlaceBid() in DKPmon_EPGP to make sure the user can place your specific bid types, and probably a number of other things. It's better than starting from scratch, even with my code, but still a relatively significant rewrite.
Specific descriptions for different point events is supported by DKPmon, the reason all custom changes show up as simply "Custom" is really just me being lazy. I'll see about doing something about it tomorrow.
As it stands penalising someone's EP is something you can't easily do with my current implementation, the inherited Awarding interface only modifies "DKP" and DKPmon_EPGP thus simply treats any input of negative DKP in when awarding points as adding GP; never as subtracting EP. I've been considering decent ways to implement doing specific changes to each point type, but creating a workable interface for it is very much non-trivial given my rather weak lua skills. :)
I'll happily try to help out with any questions you have about _EPGP, if any bits of the code are a bit hard to follow. I'm fairly sure I still remember what all of it does...
The ideal GP value to have is obviously a 1 which makes your priority directly correlate with your EP value, each time you are awarded an item your GP value gets increased by the "GP Cost" of the item. As stated above your priority EPGP is computed by dividing your EP value by your GP value.
An interesting side effect of the system is that new players effectively start with an ideal GP of 1, pretty much putting them at the top of the priority list against almost any player with a GP value higher than 10 (new playerA EP 1000 GP 1 = EPGP of 1000, vs playerB EP 9999 GP 10 = EPGP 999.9) to combat this and make the system a little more balanced, new players must earn a minumum ammount of EP before they may bid on an item. We use a value of 3000 which works out to about 3 raids attended before bidding.
Decay is integral to the system as it provides two main functions.
1. Reduce the ability of players to "hoard" EP points by effectiviely aging out EP, because decay operates on a percentage, the more EP points a player has accumulated the harder he is hit by a percentage reduction. This allows new players to the raid to be able to effectively compete with older raiders in a relative short amount of time. Decay also has the effect of "capping" the total amount of EP a player may have and maintain. If the player earns 2000 EP per week with a 10% per week decay, the maximum EP value a player may realisitically hold is ~18000 EP, the same values with a weekly decay of 30% limits the player to ~4666 EP.
Decaying EP also has the unintended (or intended) effect of reducing a players EP value even if he is not raiding, with an EP decay of 30% a player with max EP(4666) will be reduced to 785 in just 5 decay iterations, More importantly he will fall below the mininmum required EP to bid (3000), in just 2 iterations.
2. The second function of decay is to effectively reduce the amount of GP charged to the player thus "aging out" his GP value from equipment earned in an effort to reduce his charged GP to an ideal value of 1.
By taking a lot of the defaults for the system we ran the numbers;
Using the base item as Tier4 shoulders from gruul's lair, this item is valued at 100GP for all players.
With a default GP decay of 10% it will take 44 weeks to reduce the GP cost of this item to a value of 1.
Now considering that two shoulders drop per weekly run, a balanced system would age out the GP charge in ~13 weeks (this assumes a perfect drop percentage of shoulder types).
In order to decay a value of 100GP in thirteen weeks we would need a weekly decay percentage of 30%.
So have I confused you enough yet?
The problem is that by tieing both the EP and GP value to the same percentage it becomes very difficult to keep the system fair and balanced for all raiders, specifically it heavily wieghts the system to new players entering the raid group and seems to unfairly penalize regular raiders.
The answer to me and my guild seems simple enough however, by allowing EP and GP to decay at separate rates you can effectively fine tune the system to be more balanced by allowing GP to decay faster than EP is lost. This would have the effect of decaying GP at 30% allowing 100 GP to properly age out in 13 weeks, while not placing the EP ceiling so low that it penalizes regular raiders.
I've modded Xero's code to support the following;
1. EP and GP decay rates are uniquely definable within the UI
2. The current decay rates are stored within the database.
3. Changed the decay rate option boxes to use sliders similar to "greed factor"
4. When decaying the database the "are you sure?" dialog displays they rates you are going to decay the database.
The mod supports the previous way of decaying the database simply by setting both sliders to the same rate.
Xero,
Would you look at the changes I made and if they work for you could we add them into your main code branch? If not I'll start my own branch. I've only modified the DKPmon_EPGP epgp.lau and the localization.enUS.lua
Attached are the files I've modified from the DKPmon_EPGP directory.
-Vlorn
Would this apply to DKPmon_EPGP in the same fashion as was discussed in a FCZS section of the initial DKPmon thread (pg2):
Perhaps HoB's formulae could be altered to use the exact EPGP standard, for those that desire it.
No, decay is based off your total GP value, to handle it any other way would be hugely intensive as you would need to track and decay each item earned seperately. I'm pretty sure that both this mod and the original EPGP mod work the same way in this respect.
-Vlorn
Drunk
Basically a guild sets a minimum GP which is NON-DECAYING for the tiered instance they are on. We currently are going to implement a 100 base GP as of today. What this means is new people and people under 100 GP have a "virtual" GP of 100...so somebody with 90 GP and 100 GP both have the same GP.
What this does is normalizes new people entering the guild as well as new guilds implementing the features. EVERYBODY basically starts off with x/100 priority...so those who attend more are more likely to get items over somebody new in the guild who just attended one raid and has 100+ priority.
It also alleviates the problem if GP going under 1 and auto-inflating priority.
_________________________________________________
In regards to DkDrunk's comment, you would probably have to work with the Guild Launch folks to come up with a set way to export the points; however, since DKPMon does not track LOOT I still find Guild Launch's modified CTRT better in this regard. Also, the new export feature Guild Launch is releasing today allows you to set the format to export your values...which can then be imported into DKPMon_CSV and imported for your raids. I've personally be alpha testing the export feature for a few weeks now and it makes things INCREDIBLY easier.
This is how we utilize EPGP in our guild:
1. Raid Leaders are running DKPMon, DKPMon_EPGP, DKPMon_CSV and Guild Launch's modified CTRT.
2. EVERYBODY is running Bidder and Bidder_EPGP
3. Prior to a raid, we export the points off Guild Launch's site into DKPMon_CSV. This is then imported in game.
4. Run the raid using DKPMon/Bidder to record bids.
5. Once the raid is over, we upload the CTRT DKP String to Guild Launch and set up the other rewards and whatnot.
Although a bit cumbersome at first, I now have things down to 5 minutes preparation before a raid and about 15 minutes after a raid to get things set up. We also use WWS Stats pages so I can verify who was at each attempt and gets hourly rewards and bosskills...so that serves as my "backup" in case the game crashes or whatnot and the lua files get screwed up, hehehe. The points are imported at the beginning of each raid so they're in synch with the website...this prevents having to do any alt-tabbing out of the game to look up points.
I actually utilize ItemLevelDKP for pricing. I've modified the formulae so it conforms to the EPGP pricing scheme since I like that better and have renamed the addon for my guild so WoWAce Updater does not overwrite it whenever it gets updated, hehehe...
Hob's could also be used but up until recently it had not been updated in MONTHS so I didn't want to use it for fear of it suddenly breaking...
Actually if you look at the logging section of DKPmon, it does indeed track loot as well as individual point awards, which sadly the CT-Raidtracker remains blissfully ignorant of. The DKPmon_eqdkp export module already can be used to generate a string that is very much like the dkp string from CT_Raidtracker and will allow a partial upload of the log into Rapid Raid. Just the syntax is a bit off between the strings and needs some refining. That's why the Loot and custom point award events are being lost in translation.
We are giving periodic awards out for attendance based on specific time periods, generally 1/2 hr or hourly increments, and having to swap back and forth to WWS to check everyones attendance and tweaking it in seems a rather cumbersome way of doing things when the events are already there in the DKP string waiting to be used.
I was just wondering if someone had already started working on a way to do just that rather than learn to program; (where should I begin? I know bubkiss about Lua programming.); and start trying to mod it myself .
And I'm very glad to hear about the direct import to DKPmon_CSV feature working so well, that'll be very handy.
Drunk
Could you let me know what parts of the syntax are off? Also, does guild launch use a modified DKP string? i.e. Different syntax than the standard eqDKP import string? If it's a fault in my DKP string syntax that also doesn't work with eqDKP then I can fix that. Otherwise, I can pretty easily add another export option for the guild launch modified DKP strings...
-Eraslin (author of DKPmon)