Suggestions and Issues/Bugs

This has been a while coming, to be honest I can be incredibly busy during the semester and lazy on holidays around Christmas/New Year. Here’s a list of issues I can remember that I would like to see updated on DKPSystem.com websites. I've tried to keep an eye on the DKPSystem.com forums for updates to the below, but my apologies if things here have already been covered or slated.

If anything is unclear or could use further explanation, please point it out, I'll try to keep an eye on this thread. Apologies in advance for any extraneous information.

Full background details of the DKP system I have responsibility for maintaining are available here.

The following is primarily addressed to Chops, DKPSystem.com Administrator.




OK I’ve reviewed your original decay implementation described as a square root function, which I presume applies to the currently implemented decay for all websites and DKP systems created on dkpsystem.com. For one DKP in the scenario you describe, the point’s value over time (X) is approximately defined by:



Obviously the time to decay (and indirectly the rate of decay) and final value decayed to can be varied as needed.

I suppose all mathematical functions fundamentally tell us a story. The story told above to me is:

• Points have a full fixed value, for 0 <= X <= 45
• Points decay according to a square root function – slowly at first and more quickly towards the end, for 45 <= X <= 145. In reality because your implementation recalculates decay every night this is only approximately true.
• Points attain a final value of 0, for X >= 145

I understand many users are quite possibly very satisfied with this existing decay implementation.

However that stated, I believe the following needs to be said somewhere. It hopefully explains the limitations and shortcomings I feel exist with the current solution and offers some context as to why I would appreciate seeing my alternative proposal implemented on DKPSystem.com, after all you are advertising:

1. Lack of transparency for the system's ultimate users - the guild's raiders. The main problem with this system from my perspective is that member points are always going to be in flux. Different items are decaying at different rates all the time. For most people this is far too complex, it is such that a member can never (with dozens of items per member and 4 raid events per week comprising dozens of raids) know until just before a raid what their standing is going to be, and must inherently trust DKPSystem.com’s calculations.
2. Hard to be sure the GM/officers with control aren't gaming the system. The system's inherent complexity means it is almost impossible for members to verify manually their DKP for themselves, much less keep an eye on any one else's DKP.
3. Poorly or incompletely documented.
   • The current decay implementation is not fully explained from the Building Your DKP System article, it requires the PIAS DKP Decay post and as stated I’m not even sure if that’s your actual final implementation (I actually initially was under the impression it was linear decay for some reason).
   • Absence of a full tutorial/sandbox to play around with or at least a proper in-depth example explanation of a fully featured experiment/simulation. There is no possibility of reproducing results in an article that doesn't exist.
     There are no simple permutations as part of such a tutorial to illustrate the depth of the implementation and some other testable results from its application, much less a full exploration of known extreme simulation/boundary cases.
   • Where's the traceability? I don’t know what feedback for the raiding members the current decay implementation supports, does it only give the users their final number like a black box? Or does it at least give more useful statistics on what items are currently decaying, and projections for the next few days, or similar decay information for the past few days? If not these would need to be planned for our guild to even consider such a solution - I would like to know on Thursday after the raid what my new position is so I can plan and prioritise what I want out of Sunday's raid.
4. This system is effectively untestable at this time. I can’t try something, see it’s effects and then try something else, at least without waiting for a periodic recalculation (or asking you apparently) which considering the event/user-driven age we live in is almost ludicrous – honestly it just fails the User in Control idea central to modern applications and cloud computing services. I hear hushed whispers of the days when you'd submit a program to the central Unix box which would crunch away for a week only to come back with results that proved your program had some syntax and/or logic errors. It just feels like a monolithic solution that uses a sledgehammer to swat a fly. A solution in search of a problem. Apologies for the rant (3rd year Bachelor of Computing Science student).
5. I should highlight another criticism resulting from the above - it's so computationally intensive (i.e. expensive in terms of computing resources, and thus ultimately monetary costs) for DKPSystem.com to support that it requires an additional, arguably artificial contraint - that it can only be recalculated once daily. i.e. the continuous square root function becomes a stepped discontinuous one anyway.
6. This system has the potential for negative DKP – we’ve had the situation of almost no Protector raid tokens drop for 6 weeks, allowing a stockpile of DKP to build up for those on that raid token. Having members go all out for it when it finally drops, might well under the above system set up possible negative DKP when the points earned go through their more rapid decay but the items have only just started decaying. Not exactly a problem but certainly an undesirable possibility for many members.
7. Adding the "lock" concept as described and recommended below would be essentially pointless computationally - there are likely to be items or earnt points still decaying so there is no easy optimisation possible. The only reason I can think of to add it is for additional overall system integrity - it would be harder for the DKP Admin to accidentally change something.

These all feel like fundamental results of the algorithm chosen – to decay all items independently when in reality 95% of people only care about their final number and their position in line for the next loot item(s). And the only reason they care about their final number is it determines their position in line for the next loot item(s) (well apparently that and e-peen so I hear, though there's the points "Earned" section for that so /shrug).

In short, the system’s shortcomings of a lack of transparency, complete insightful documentation, and user testability, make it much more difficult to understand it's dynamics. How am I going to explain to my raiders what to expect with their DKP? How do I know they won’t leave over the sheer complexity and apparent opaqueness of it all? How would I even keep track of my (and my close competitor's) DKP manually? How could I possibly justify something that is going to be inherently variable when applied to our DKP system?

(In all fairness, I don't know what PIAS or other DKP systems have done, I'm ultimately just pointing out my criticisms of why I believe this system just will not work in the long run)


I would like to tell a different DKP story, a different proposed use case if you will. I like the benefits of decay generally in terms of controlling inflation within the system. But I would also like my guild’s members to always maintain the same relative rank for loot when decay is applied, position should only be affected by attending raids, purchasing loot or doing good/bad things requiring adjustments.

In another sense - if decay is going to require or result in discrete mathematics due to computational limitations, why not build it into the formula governing implementation from the beginning? Especially if the functional outcomes for some (if not perhaps most) users are actually better?

The initial reaction when discussing the decay implementation illustrated below with Exiztence’s officers was quite positive, it appears likely to solve many more problems than it may generate.

I propose a system that at specified time intervals (like once per week, or at the start of the next “Raid Event”) reduces all members “Current DKP” by a fixed percentage (say 20% for World of Warcraft).

Such a proposal is also far from new, it's just not available on DKPSystem.com in the elegant fashion described.

Such a system may be in the works currently as a “DKP tax” according to a five month old post on the DKP revamp. However, critical design and implementation details are missing.


What does this system ultimately do? Let me try and explain some real detail of what I believe it should do.

Conceptually, if I take the above proposed solution, it will make DKP diminish according to:

     f(x) = (1 – 0.2) ^ floor(x)

where x is the number of times the “decay event” occurs and 0.2 = the decay rate of 20% in this example.

So for weekly decay with no points earned or spent:

Decay period, (x weeks)	Point value, f(x)
0-1	100%
1-2	80%
2-3	64%
3-4	51.2%
4-5	40.96%
5-6	~32.77%
6-7	~26.21%

i.e. in theory each unspent point of DKP follows a discrete approximation to an exponential decay curve. It is going to penalise the raiders with the most “Current DKP” the most, and those with the least DKP the least. However, because it is applied to all raiders at an equal rate on their Current DKP it will not affect the rank of raiders after raids.

It doesn’t affect DKP already spent on items – that is “untaxed”, so there is a clear incentive to spend DKP as you earn it rather than hoarding it. Of course if you really do want to hoard it there is still a small incentive in that you should maintain top DKP position reliably, however it is unlikely you can hoard enough DKP for 2 or 3 major items (like those that only seem to drop once off the last boss in the raid instance), while taking all remaining items for minimum price.

This solves my problems so far, but initially it looks like isn’t going to be nicely scalable (for large scale implementation on DKPSystem.com’s servers of course) – exponential decay doesn’t theoretically have an endpoint like the current system does. (Of course the current decay implementation has an artificial periodic recalculation constraint, and there is no known user limit on the endpoints for that decay so no universal or easy optimisations seem possible anyway)

Let’s extend and flesh out my use case.

1. I can forsee a very extensive perpetual DKP system comprised of say:
   (18 bosses + 8 on time/end raid DKPs) * up to 45 raiders online or on standby per week * 52 weeks a year = possibly 60840 individual DKP events per year, add some if progression is hard and DKP minuses rack up, take some away if they aren’t recorded, content is cleared early – some nights off, raiders come/go, etc
2. I would like the system to accurately recalculate any decay adjustments in real-time (or close to it) if I make an adjustment to a raider's DKP, so I need it to be fast and efficient.
3. I need to be able to specify a frequency, date and time determining when the decay should occur. For me once every server reset would be good, four times a week according to our raiding schedule would be better.
   However if it was say set up to automatically recur based on raid events, I would also need to be able to manually stop decay events occurring or remove them from the schedule, in the event of off-nights or weeks (say before a major content patch) when raids may be called.
4. I would also like to be able to “lock” all DKP events before say 2 weeks ago, most of the time, but also have the ability to “unlock” them if I do need to make an adjustment before 2 weeks ago.
5. As stated I would like the average raider to understand what’s going on so they can know how much DKP they will have at any given time, how much they can earn, and can reasonably keep an eye on their close competitors too (another important part of helping ensure transparency and equitability in the system).
6. Ideally final implementation would be before the date the Ulduar content patch (WoW v3.1) comes out, when we are expecting to “reset DKP”, i.e. move everyone to a new DKP system and hide the old one. It’s too early to really say, though considering past major content patches are about 4-6 months apart the next should come anywhere from 6 weeks to 3 months from now.

I believe that the ability to “lock” all transactions/DKP events with a date more than 2 weeks before the system date, will be a good starting point to optimise from. Unfortunately it’s not a universal one but should be able to be applicable to all DKP systems.

It means if you can maintain a current totals list which could say be updated daily unless the two-week (or user-specified) “lock” is deliberately removed, any changes would only require recalculation of the standings from that point to the present, a far simpler task. With this relative simplicity comes my desired speed and efficiency. Depending on DKPSystem.com, it may well be fast enough to enable the real-time recalculation of DKP standings. It’s a similar concept to taking a database checkpoint.

In addition, the "lock" concept if properly enforced would make any accidental changes or mistakes (like entering a raid associated with a raid event in the middle of last year by accident, or clicking edit on the wrong adjustment a long time ago) much less likely to be entered into the system.

The other items I think look like just additional user-in-control settings, things like specifying how often the decay occurs. Perhaps this should be extended to choice of decay - linear, square root and exponential decay rates; and choice of decay application – just the final total or (as in the current implementation) every transaction ever made. I haven’t thought these combinations through fully, should for example every transaction ever made be allowed to decay exponentially? (that could be a nasty one computationally if people don’t periodically change DKP systems, and items would again be simultaneously decaying at different rates which wouldn’t guarantee preservation of the same rank order for loot items)

Would this level of user customisation actually be useful in terms of the stories it could allow those DKP Admins to tell for their raiders/users? I don't know, all I can say is my story of discrete exponential decay is associated with the "DKP tax" story, and I'd be happy if that aspect of customisation stopped there.

Nevertheless, I doubt all users who do currently use the existing decay implementation would be likely to transition away from it, even if it becomes legacy functionality – so if this proposal is implemented there would need to still be both solutions.

For the ultimate end-users (the raiders), I’d personally like to see a simple addition to the interface like another section below the current adjustments for members, perhaps like the following:



This should also be added to the columns selectable for sorting/display on the main "Check Your DKP" page.

Hopefully that’s outlined my problems and some of the requirements and details for possible solutions to integrate all the existing and proposed new decay functionality.

Fundamentally I believe decay was designed as a solution to encourage spending of DKP, reduce the impact of certain raiders hoarding it, encourage consistent raider attendance, and thus control inflation and allow newer members to rise to the top more quickly (without zero sum).

I sincerely hope you have been convinced as I have of the merits of the above alternative decay solution enough that it should be implemented. Whether it goes by the name of exponential decay, "DKP Tax" decay or perhaps something else entirely I believe the core concept, main user customisations and reasons why should have been illustrated. However, as stated, I will try to keep an eye on this thread if more information is desired.

Frankly given it's presence in such an authoritative post on the WoW Forums, I'm surprised it isn't already implemented. Though of course in retrospect it isn't linked on the guides to Planning/Building Your DKP System. BTW the link to the wikipedia page at the bottom of Planning Your Loot System appears to have been deleted 18 months ago, though I could have sworn I looked at it more recently.

P.S. I’m sure some ridiculous boundary cases like decaying every 0.000 01 days (about once a second) would be excluded, who would need say a discrete exponential decay on the total more frequently than once per day, or linear decay on all items recalculated every second?
On the topic of boundary cases, there should be user determined rounding options in the decay too, say restricting it to automatic integer adjustments rounded down, though there should be a “use-defaults” option for simplicity too.


On a somewhat related topic, there is another proposal I would really love to see.

Fundamentally all “raid destinations” or bosses are currently either independent or associated with a “Raid Event”. I would love to not have to go in and change every single “Raid” for a given raid event when I find out I missed a raider on standby for some reason (15 Naxx bosses, on-time and end-raid DKP means (Click Edit -> Scroll down, Check Box -> Click Save), i.e. >51 user actions and >17 pages loaded for something that should be at most 20 clicks and a couple of page loads, less if there’s a “Select All” checkbox for each Raid, see next section).

I’d rather choose a character on the raiding roster and modify their attendance at individual raids or better yet raid events.

This might be something like the following, though I'd like to see it with more awareness of the raids, raid events and raid days to sort the raids associated with the raiding character by. Perhaps this could be done by accessing different links in the menu but there could be a better way (that menu system really is starting to feel ridiculously cluttered).



This should work out nicely for the proposed decay system (well it should just apply generally) too – only that raider’s DKP needs to be recalculated rather than potentially the entire system needing a recalculation each time a raid or raid event is changed, depending on the implementation (I guess it could just be an SQL query generated for every user request on a RDBMS).

I also only considered a DKP System-wide lock in the proposal for decay, perhaps the locking system could be more fine-grained and be liftable for particular raiders rather than the entire system? In my case this would be perfectly fine - I've never forgotten to record a raid event but I've occasionally had to go back beyond 2 weeks to change adjustments or attendance, but only ever for individual raiders.


This was a bigger issue when the guild transferred from GSDKP.com to DKPSystem.com and maintained the "real-time raid" style of DKP updates, which we have in WotLK been more or less forced to transition away from – Naxx leaves an average of 1 minute between finishing loot off and pulling the next boss, just too short a window to /reloadui twice, upload GRSS snapshots and download the new numbers. Even so it's likely a better, more transparent system because of it.

That aside, I’d like to see a “Select/Deselect All” Checkbox applied DKP site wide as in the following two suggestions. It would be especially useful when you forgot to delete or for some reason couldn’t purge the GRSS snapshot for the previous night (or upload event).






Arguably the most useful part of the raid analysis for me is attendance checks. But when it doesn’t pick up the null case, for example “Whatastunna” doesn’t show up in the following query (because he wasn’t yet on trial), I need to cross reference my guild’s roster and the generated list to determine attendance. It should show raiders with no attendance at any raids in the period – in fact those are the most important because if they’re on extended holidays or MIA and slipped through the net, we’d like to know so we can consider recruiting replacements.

If there's a good reason these are being excluded from the results, I'd love to hear it and have the option of turning it on/off.

 http://exiztence.dkpsystem.com/raidanalysis.php?dkpsystemid=3&sort=&daterange=on&startdate=1%2F13%2F09&enddate=1%2F27%2F09&sub=Do+It

Would be nice if clicking again sorted the list in the opposite order, starting with the lowest percentage or raid total at the top (currently the attendance sort is only available in the default order highest percentage or raid total at the top).

http://exiztence.dkpsystem.com/raidanalysis.php?dkpsystemid=3&sort=percenttotal&daterange=on&startdate=1%2F13%2F09&enddate=1%2F27%2F09

I would also really love to see the addition of “Raid Events” (“Events” and/or “Event %” as visible on the main “Check Your DKP”, it’s all the same to me) to the “Raid Analysis” page – though ideally it should just be customisable in the same way the main page is. Perhaps all we ultimately need though is one sufficiently powerful user-customisable raider, raid and raid event query tool, I haven’t really considered my data needs, much less everyone else's in enough depth to answer that question.

UPDATE: Just saw the "Custom Age Sets" in the DKP Admin menu - that should cover our attendance checking requirements as long as I remember to generate the guild attendance reports on the right night and screenshot it.



The “&” character shows up as “&amp;” in the title of forum posts in both Firefox 3.0.1 and IE7. Could affects others, haven't looked.




This issue appears to have been fixed

Put the following in a forum post “Treebäne” and “Cafè” (special characters are Alt-132 and Alt-138 on the numpad respectively).

Clearly this would be a major impediment to any Asian/European guilds or others who really require the full Unicode set, I rarely use it and it can be frustrating enough.

After two edits (imagine after 10-15 like I've seen before):



Should work properly with these special characters, so our spriest, holy paladin, resto shammy and death knight with special characters no longer need to whisper me "!dkpclass Death Knight" style queries instead of !dkp.

It seems to also have been mentioned recently as being an issue here. Since the GRSS is still at 0.993 hopefully this one is already in the works.

It's also noted as being an issue in waitlists here so bump for that.


I’d like a setting somewhere to by default run the “Raid-Event Associator” when uploading GRSS snapshots, manually adding a raid, loot item or DKP adjustment.

Only because it seems to guess right 99% of the time (though it's never 100% clear what changes it actually made, a list of changes would be much more user-friendly). And because selecting from a combobox of about 1000 raid events takes a little longer than I'd like, perhaps showing the raid events +/- 1 week of the system date near the top of the list would make this less painful.

If it's there and I missed it, please point it out


Comparing for example many wiki/wowwiki articles, such as this one on DKP, with the automatically generated "Contents" section on for example this post leaves something to be desired. How am I supposed to link to a particular title/section? Why should I have to click twice if some one directs me to just this section (once for the page, once in the contents for the page section)?

Why can't the automatically generated source code look something like:

Instead of from the example (which without endlines is considerably harder to read too):


Or however it should go - I don't understand the reasoning behind the 'javascript:void(0)' over some kind of link; though I don't know a huge amount about coding websites - whether there needs to be more done in the Add/Edit post code or something.

Basically, I'd like to be able to work out how to link to a particular title or subtitle in the post, rather than having to post as many separate posts in order to link precisely to each individual section (with my signature wasting screen real estate space at the end of all of them too).

If this is actually somewhere in my site's current CSS/Layout/Menu files please point it out so I can start playing with them again.


I’d like to take this opportunity to say thank you. We’re overall very happy with the extensive, customisable guild solution DKPSystem.com has provided, and intend to continue using it in future.

It’s great to see features being actively developed like the GRSS Death Knight support, and hiding DKP Systems which are hidden on the website. It’s also great to see things like full WotLK support, and WoWHead items, spells, achievements, quests and talents load on mouse-over when you put the URL in correctly.

Cheers and keep it up



Disclaimer: The above is not intended to be a http://en.wikipedia.org/wiki/Software_Requirements_Specification">Software Requirements Specification, just a more complete outline of current issues I and my guild’s members have experienced with DKPSystem.com. Any progress towards resolving any or all of these would be greatly appreciated.

The above link that isn't a link as you'd expect also points out what I think are parsing errors which seem to result from stuff in quotes or code not being properly encapsulated. Basically the characters inside quotes or code unexpectedly becomes part of the formatting of the generated web page. Another minor issue, no idea if this is ultimately a browser limitation.

Wow, that's a lot to chew on. I'll start: Thank you for the detailed analysis and constructive criticisms of the site. And I'm glad to hear you're pleased with the system.

I'll address most of your concerns, though not necessarily in the same order you've presented them.

GRSS

The new GRSS as it's in the works will be shipping essentially as an almost complete in-game DKP manager. In addition to charging loot, it'll have in-game adjustments and award points for snapshots. And while this is going to happen, it's still going to be designed around nightly uploading - it still needs to be grounded to the site, simply because it would be unnecessary to reproduce in-game every DKP feature on the site. Indeed, the GRSS has always been a supplement to the site, an will remain as such.

Fixes for the waitlist will also be done.

Decay

As for Decay (Which was the largest section of your site), I understand the criticisms, and sans the locking stuff, the addition of decay in the form you mention will ultimately be added (periodic percentage of current, and linear decay).

Though without getting too deep into it, the ultimate logic behind the current "independent" decay system (which I've always planned on adding a linear decay option, just never did) was this: old events are less important than current ones. Some might disagree with that reason, but that was the reason it was implemented on the PiaS site. The fact that it can decay into the negative is actually intended - the system needs to enter equillbrium, and it wouldn't be fair if someone could spend everything, get down to zero, and then effectively never get their earnings decayed, while the rest of the guild decays away. Ultimately, it's like this:

Undecayed, if someone earned 100 points and spent 125 points, they would be -50. With the system's decay implementation, at the end, they would be at -12.5 (with everything being weighed as 25% of it's original).

The system in it's current form is fully intentional. (Though I understand why it can be confusing to members.) I'm willing to accept that it may be more complex than it needs to be for certain guilds.

Live updates to decay remain planned, though as you mentioned, the process is indeed computation intensive, but it's going to be updated so that one can actually test decay and switch back if they don't like it.

By Character
The idea for DKP by character is interesting. I don't think that's yet been suggested, and it's something I will give some serious thought to.

Select All|None
Definitely needed and definitely planned.

&amp; in the forum title
This one bugs me too. The short of it is that a fix is in the works, and long overdue.

Raid Analysis Null Case
So that I understand your request here, you want the Raid Analysis to show all Raiders to show even if they don't have any attendance during the selected range?

If that's the case, that should honestly be no problem. The reason they were left out initially, is that they're simply not in the query. The question wasn't even considered. But that's no problem.

If you know SQL, the query is currently something like this:

select * from attendance where date between X and Y

.

If the character isn't in that range, it's just not showed.


Not using Anchors (<a name="whatever" inside the contents menu

Semi-interesting story with that (I had actually forgotten about it, and was wondering the same thing when I first read it on your post). The short of it is this: it doesn't need to be that way any more. The long of it is a bit more technical. If you remember back to Sept 1st, 2008, I deployed a massive update to the forum system, where pretty much everything was does via ajax. That change didn't last terribly long, and was ultimately changed back to a more traditional approach, but most of the updated functionality stuck around, just the look was changed back to what it was. But the problem was with a mixing of Ajax, Anchors, and Hash query strings (commonly used on Ajax pages for determining what to show, for example if you look at gmail, they use hash query strings extensively). The solution was to have the browser jump to the appropriate part with javascript.

As for the void(0) part, some browsers (IE6, I believe) have issues with certain links of the form javascript:dosomething('gfhfgh','hhgh'), and if there's a singlequote in it, try to treat it as an actual url, and redirect the page to a blank page. So an easy solution is to call javascript:void(0) in the "href" attribute (which just means, do nothing), and then add the real javascript in the onClick event of the same tag.

The truth is now, though, because the ajax part was disabled, it can be changed back to use hash marks (like they originally were doing in testing before the hash query strings were used).


You've definitely won the award not just for longest post here, I'm almost positive

Thanks again!

Cheers, great to hear our issues getting heard, responded to and worked on. Fun to hear there's a "Semi-interesting story" behind many such things.

I'm currently thinking the Raid Analysis code might be something related to grouping by character after selecting all character attendance in raids (SQL-2003 apparently specifies NULLs are grouped into their own category), but that's just the way I'd do it and there are usually so many ways to implement the behind the scenes code in SQL, and each DBMS often has its own subtle variations; one really couldn't say without seeing what code is being called and what the schema for the database tables is.
I realised perhaps a reason for not considering the null might be large guilds with say 200+ members on the roster, not having a separate roster for DKP and not really caring about the 150+ retired/inactive members/alts at the bottom, not really sure what other user feedback you've had on the Raid Analysis tool though.

And fair enough, it is a lot to chew on, hopefully not too much for the time being

Nulls would be in their own category, but this is unrelated to that (also, the database used is MySQL). It's not a matter of nulls being selected and filtered, but just that it's only selecting the attendance records in the date range. If there are no attendance records for that date range for a particular member, the database won't include it in the recordset at all.

I can see how it could be confused, though.