25.12.2009, 16:09
the % is the "modulo" operator, the remaining amount of the division: 5/2 = 2 remaining 1 (the mod value 5%2=1).
so each 10 minutes (or minutes dividable thru 10 w/o any remaining value, gets 0: 10/10=1 remain 0, 20/10=2 remain 0, etc) - the result (dividable /10) is true.
if you set the seconds back to 0 (-=60), after reaching >59 (=60 and more hehe), the condition also is true, coz 0/10=0 remain 0.
the reason i script it this way has one simple reason:
if you start syncing the seconds with a real clock, then the seconds skip 1 sometimes. so there is a 1.67% chance of skipping one vital second for calling a minutely "payday", and you maybe would "lag" 1 whole more minute in hope to hit the 60th second next time...
if you check for >59 seconds, the 61st second will fit the condition check too, and will subtract 60 from the seconds-timer to second 1 instead of 0, AND will call your minute-loop, adding minutes, until the minutes %10 ==0.
1 more advantage: you get your 1 lagged second back for free
so each 10 minutes (or minutes dividable thru 10 w/o any remaining value, gets 0: 10/10=1 remain 0, 20/10=2 remain 0, etc) - the result (dividable /10) is true.
if you set the seconds back to 0 (-=60), after reaching >59 (=60 and more hehe), the condition also is true, coz 0/10=0 remain 0.
the reason i script it this way has one simple reason:
if you start syncing the seconds with a real clock, then the seconds skip 1 sometimes. so there is a 1.67% chance of skipping one vital second for calling a minutely "payday", and you maybe would "lag" 1 whole more minute in hope to hit the 60th second next time...
if you check for >59 seconds, the 61st second will fit the condition check too, and will subtract 60 from the seconds-timer to second 1 instead of 0, AND will call your minute-loop, adding minutes, until the minutes %10 ==0.
1 more advantage: you get your 1 lagged second back for free