stats.php which outputs JSON player/server numbers over time

[Mailaender]

So we can render it with JavaScript libraries like http://www.flotcharts.org/ in the way http://cncnet.org/statistics does it.

[Mailaender]

Currently @xaionaro does keep an external database using http://rrdtool.org at http://openra.ipdx.ru/graphs.html

[ihptru]

This tools gathers statistics other way.
To be clear, master server does not really store data since #16 merged.
It removes game from database if it sends 'state 3'

I could suggest to make rrd script open source and database publicly accessed.

[xaionaro]

@ihptru, there wasn't enough information even before the pull merging. I restored the statistics about players count (2012 year) using this way:

• I assumed that every game takes the same time.
• I calculated the average duration using my replays collection at that moment.
• I calculated a number of players at every minute using the average game duration and information from the master server.
• I normalized the end of this history on real values (I was collecting them from using "list_json.php"), that gave to me a correction factor.
• I multiplied players count to the correction factor through all "restored" statistics to get more precise approximation.

So, as you can see this's very rude approximation, just because master server have never saved enough information to directly restore such statistics.

[xaionaro]

FYI, the script of the "https://openra.ipdx.ru/graphs.html" stores data not only to RRD, but also it stores every obtained value to special log file (just in case). So we can restore all statistics since "openra.ipdx.ru" was been upped (excluding periods of hardware problems in Hetzner).

So, you still can render the graphs using another tools. I can provide you the statistics.

[xaionaro]

d[15:57:51] [root@titan:openra /var/www/openra.ipdx.ru/root/db]# wc -l log
1240067 log

[Mailaender]

Maybe something more modern looking, but still using RRD as backend like http://www.urtstats.net/players.php would be nice.

[ihptru]

so to make clear what we have now:
games.log on master server: IP:port,map_hash,version
log file updated by rrd tool: date_in_unix_format:players_playing:players_waiting

#23 will improve map stats.

---

I also suggest to make sql table where all games will be actually saved on state=3.

date, players_waiting, players_playing -- this fields are mandatory, others can be empty. This will allow extending amount of fields in future and it should be permitted by non-written policy.

Extending amount of fields is the reason why SQL instead of log file.

[xaionaro]

I also suggest to make sql table where all games will be actually saved on state=3.

I think you should add an SQL table with games state/players history. I mean a history of all "state" and "players" changing.

An example of fields set:
| timestamp | state_old | state_new | players |

This allows to restore almost any statistics.

[ihptru]

one game changes state 1 or 2 times( from 1 to 2 and from 2 to 3), you can't tell how many players jumped in&out and were online while it was waiting for players. Or maybe last your message was not clear for me?
It can work for average stats though

This way we already want 3 tables to represent all stats we want, I guess it's ok because they are not updated that often. 1 table will be updated once game is started and finished, other 2 tables will be updated when game has finished.

[xaionaro]

one game changes state 1 or 2 times( from 1 to 2 and from 2 to 3), you can't tell how many players jumped in&out and were online while it was waiting for players. Or maybe last your message was not clear for me?

Sorry for my lame English. I mean save any ("state" OR/AND "players") change event. For example:
#. timestamp, game_id, state_old, state_new, players
0. ?, 0, NULL, 1, 0

1. ?, 0, 1, 1, 1
2. ?, 0, 1, 1, 2
3. ?, 0, 1, 1, 3
4. ?, 0, 1, 2, 3
5. ?, 1, NULL, 1, 0
6. ?, 1, 1, 1, 1
7. ?, 0, 2, 3, 3
   And so on.

I can explain on Russian to be more clear. But I think people here won't like that :)

[xaionaro]

BTW, IMHO, we should also keep a number of spectators in a runned game :)

[ihptru]

As about stats, I got you now. 3 tables should give us any stat possibilities we want!
Also see #14 we already have OpenRA sending fields not used by master server output.

[ihptru]

what is game_id in here and could it be replaced with address:port? I want it for server stats too to get an average and the highest activity.

[ihptru]

wrong commit, meant: fix #14;