Rather major bug with adjustments
Brought to you by:
dkppro
Menu
▾
▴
Hello there. I've been fooling around with dkppro recently, and came by an odd bug. When I go to make an adjustment with a decimal in it (0.2, -1.6, etc.) and go back to the player listings their dkp values become massive numbers (for example when I adjusted someone's value of .2 by another .2 it became .4000000000000043712 or something similar). Not only does the new value spaz out on me but it screws up the dates in the raid listings (all the years were changed to 2010).
Ayways, if you wish to reproduce it to look into it yourself simply make a couple dummy players/raids and fool around with the adjustment feature =p
If you can fix this and add that feature to modify existing raids you'll have a pretty damn solid points/attendance tracker.
I fixed this bug by getting into the dkppro db on mySQL and modifying the type of the dkp_earnt and dkp_spent fields on the player table, and adjustment field in the adjustments table to decimal(4,1), meaning you are only allowed 1 decimal place, and a total of 4 places. ie it allows a number +999.9 to -999.9.
For example, at the mysql prompt type:
ALTER TABLE table_name MODIFY field_name DECIMAL(4,1);
Repeat for each table or fieldname within a table that you need to fix.
There may be other places where the type would have to be updated to stop from having a runaway decimal number, but I haven't ran accross one yet.
I am still tracing down the reason for having an incorrect date when you try to register a raid. When you get to addRaid4.jsp, the year is displayed incorrectly as 102 (instead of 2002) with 101 or 103 as options (instead of 2001, 2003). Once the raid is registered the DAY is changed 01,02, or 03 (depending on if you picked 101,102,103) and the year is 2010.
Anyone else experience this?
Thats quite strange with the year being displayed as 102. I get the year value from a javascript Date object which initialises itself according to your computer clock. The year is grabbed from this date object with the getYear() method... is your computer clock definately correct?
I encountered this bug early on but thought I got rid of it when I changed all my values from float to double variables.
Gonna look into it, the year thing is damn wierd too.
Fixed this now. Its due to the fact that decimal numbers can never be truely represented by a series of binary digits. I have to format the number after the calculation to fix the 'fuzz' the variable picks up in the calculation. Or something :)
That year thing is still puzzling me, I cant seem to duplicate it. I really dont understand why that would happen, the object which processes adjustments doesn't touch the raid table at all.
I hope i've caught all the places decimals could possibly screw up... Will release a new version when i've zipped it all up and got it uploaded.