sure it could be passed by get variables...
btw, i think it could be interesting to find the assimilation/fluctration that is caused by specified maps.
for that i modified the query as following:
Code:
select
TIME_FORMAT(time, '%H:%i') as time,
DATE_FORMAT(time, '%M %d, %Y') as datum,
time as timestamp,
count,
(SELECT count FROM clientcounter WHERE time < timestamp order by time desc LIMIT 1 ) AS prev_count,
((count) - (SELECT count FROM clientcounter WHERE time < timestamp order by time desc LIMIT 1 ) ) AS dif_count,
map
from clientcounter
order by timestamp desc
limit 0,1700
TIME_FORMAT(time, '%H:%i') as time,
DATE_FORMAT(time, '%M %d, %Y') as datum,
time as timestamp,
count,
(SELECT count FROM clientcounter WHERE time < timestamp order by time desc LIMIT 1 ) AS prev_count,
((count) - (SELECT count FROM clientcounter WHERE time < timestamp order by time desc LIMIT 1 ) ) AS dif_count,
map
from clientcounter
order by timestamp desc
limit 0,1700
it returns me
-the plyercount
-the playercount value "of the row before, sort by datetime"
-the difference between them
the result looks like the following:
Attachment:
prev_count.png [ 8.12 KiB | Viewed 4855 times ]
in the graph ist shown like this:
(allow the graph some seconds to generate...)
dswp_tools/clientcounter/show_asimilation.php
i know, this is a bit mad design.
cumulative numbers for different timeframes (like 1 votecycle) follow sooner or later
ps.
i just checked the numbers...
oildepot ist NOT responsible for the client loss, the machine just draw the line from oildepot to the next (subterra!!!):
th line has still the "oildepot-color"
Attachment:
subterra.png [ 10.45 KiB | Viewed 4855 times ]
so i put oildepot back in and kill subterra instead.
subterra, fucking subterra.
we must take it out from all cycles and just play it manually i think...
propably not. But that particular map is not one of my favourites for sure 
