Logged Out
Create an Account

Forgot your password?
DKP seems to not add correctly

DKP seems to not add correctly
[Back to Index]
Thread Tags
Primary: [Tickets]
Secondary: None

DKP seems to not add correctly
Go To This Ticket's Page
Creator Acono
Public or Private Public
Private tickets are only accessible to you and to DKPSystem.com staff
Public Tickets are visible to everyone)
Status Open
Type Bug
Section of the Site DKP
Urgency (1 votes)
Rating (0 votes)

On my site, invictus.dkpsystem.com if you look at one of my guilds characters, Docker. It appears that he has 6 more EP than he should.

At last decay, which was Apr 19th. He had 163.9 which was decays 16.39 to be 146.87 (with rounding).

Since then we have had two raids, at which he received 6 points for each. So he should be at 158, instead his page shows him at 164.87.

I can't see where the extra 6 points has come from. This appears to be affecting other people also (rythhem) I have only checked those two..

If you could look into this I would appreciate it. Thanks.

Official DKPSystem.com Comments
No official comments yet
Any chance someone could take a look at this?
Thank you for the bump. I will be having a look at this soon.

It's all in the reflexes.
Here are my thoughts on this particular issue.

In looking at the data, my guess would be that you had recorded the results from the 4/18 X2's raid after the decay had been calculated. That would be consistent with the numbers seen on Docker's DKP audit page, since the decay 3 days ago was correct given the results and the current value.

How does that fit?

It's all in the reflexes.
I don't think that is the case, I went through and recreated it in a spreadsheet to add in the numers, and the numbers for decay match the numbers in the DKP tracking, until this last week, where 6 points more than should have been decayed were decayed...

Here's the numbers:
Date Total Points pre decay
5-Apr 143.3241 159.249
6-Apr 6
10-Apr 6
11-Apr 6
12-Apr 145.19169 161.3241
13-Apr 6
17-Apr 6
18-Apr 6
19-Apr 146.872521 163.19169
20-Apr 6
24-Apr 6
26-Apr 6
26-Apr 148.3852689 164.872521

where pre-decay indicates what the total points were before decay, these are listed match what is listed in the website in the " EP Decay (10% of 161.324 = 16.1324)" sections..

All of these numbers match by week, except for the last week, where the website decayed 170, when it should have decayed 164. If what you were saying was true, it seems like one of these weeks should have been 6 short, and none of them were.

I'm working on a more elaborate audit system for you here. It's something that's pretty desperately needed, and will help with this.

My hunch here, given the current standings and the last decay is that there is definitely a stray 6 points added between the decay on the 19th and the 26th - it's no coincidence that the descrepancy is 6 points and that is how many points are given per raid.

The key is finding where it came from. I might have to search through some backups of your database to find the culprit.

It's all in the reflexes.
Thanks, is it possible a raid got double saved? I frequently save raid attendance multiple times.
Alrighty, I checked the backups for the past 2 weeks and the results were consistent with my initial guess.

I've attached the relevant CSVs.

Note, all times are in Central Time, so there's a slight day shift here.

Also Note, that all files are named after their backup date (ie 20.csv = April 20th Backup)

For the backup from April 20th, you'll see that the Decay had calculated at and recorded the data it had available at that time.

Between the 20th and the 21st Backup, the X2 raid from a few days prior was added recorded, hence the apparent disconnect between the cumulative total used to decay, and the current cumulative total. The raid was recorded after decay ran.

By contrast, if you compare the 27th and 28th raids, you'll see that the X2 raid from and the decay were both missing in the 27th, but present in the 28th, and the numbers are consistent meaning the raid was recorded before decay ran.

The takeaways from this are as follows:

1) For you: Tax-based and EPGP-type decay, in it's current form is not forgiving of late data entry.
2) For me: Perhaps it's time for me to revisit decay and make it attempt to run the tax-based/EPGP decays retroactively. That way, if you were to enter a raid late, it wouldn't matter - the previously processed decay would adjust itself to the totals at the time. I'll ponder on this

Also, the code that I used to export these CSVs isn't ready for production use, but I've got a whole big CSV system in the works for exporting things for various reasons, mostly analysis.

Finally, thank you for bringing this to my attention.

It's all in the reflexes.
Thank you for looking into this.

I think I am going to change the decay day to something further from our last raid of the week so I can be sure to get items updated in time for the decay.

I can't wait to have an export function so we can pull this information offline and play with it in Excel.

In the meantime, perhaps adding a column to the DKP history page that reflects the 'entered date' of the raid would be helpful?

In the meantime, perhaps adding a column to the DKP history page that reflects the 'entered date' of the raid would be helpful?

That's one of the things I'm considering.

Probably at least "First recorded" and "Last Updated" would be pertinent.

It's all in the reflexes.
Those would both be awesome things to see

Also.. while I'm being needy..

The full DKP transfer from one character to another would be handy.

Thanks for your help sorting this out.


[Back to Index]