Autostats enhancements to facilitate storage to a db

[killingtime187]

I've currently modified the proquake 3.9 rc1 source, trapping console log calls, and injecting some items that are needed to get a complete picture of a match. I've so far added the following -- match type (eg. 3v3), match length, and map name. Ideally, these should come from the mod generating the autostats. In addition, to prevent "stats watchers" from having to constantly tail the log file looking for autostats indicators, I have also modified the server source to dump these to a separate file with a timestamp in the name indicating the time the match was over.

This might not be the best way to feed statistics to an external party, but without knowing the capabilities (limitations) of mods, I'm not sure if any other solution is feasible or if this really doesn't belong in the mod; in which case, we would then be talking about a "mod plugin" that hooks into the main mod events and does whatever with the data. There are other options such as integrating sqlite into crmod, but again, may not be possible with QuakeC and this forces the db host to be the same as the game host. And yet another option is to enable a REST post (json) to a configured host with game information -- player name, ip (for iplog tracking), and stats. The format and data can be specified by crmod and hosts wanting to receive crmod events would need to build the corresponding API's as specified.

There are possibly a plethora of other data points that can be added that would give an even more in-depth picture of a match and per player performance, but I think the first step is to come up with the infrastructure first and enhance from there. For instance, another cool request would be to somehow have a demo of the match associated with the stats, although I have no idea how this can be accomplished. Other stats pages for possible inspiration, not from a presentation, but a data standpoint -- http://stats.xonotic.org/, https://qlstats.net/. This is why I think the mod should provide as much data as possible and let stats sites with their sql db's present all sorts of different views, graphs, and so on.

Thoughts ?

[killingtime187]

Ok, to keep things simple and for the first step, can we duplicate what I had to do by modifying the server source code ? Here are the requirements:

1. Dump autostats at end of match to a separate file with a timestamp in the name. eg. autostats-yyyymmddhh24miss.log

2. Include the following in autostats (currently not present):

a) Match length b) Match type: 1 (for 1v1), 2 (for 2v2), 3 (for 3v3), and 4 (for 4v4) c) Map name of match d) Player details: name/alias, ip address, ping

There are a lot more stats that have been requested https://drive.google.com/open?id=0B-yo_MtaKUakc0cxcnQ5NVhFMjJlelVWWXd6alp1bWczZmkw but this is what our web page and db are working with right now. We can expand and add to this in updated releases.

[jp-grossman]

QuakeC is very limited. Basically all we can do is print to the console and post-process the log. The only other option would be to have a "stats client" connect to the server (much like qsmack used to stay connected to the server), but it's probably best to just stick with the log.

[killingtime187]

I see. Yea, the stats client won't work with these guys and we can't force a single client since everyone uses whatever they prefer these days - dp, fte, qrack, dq, pq, quakespasm, etc.

Can the mod at least write these values to the log? This way my console.c hack can trigger on start/end of stats marker and write to a file.

[jp-grossman]

Yes, if the mod writes to the console and you're running the server with -condebug then the output gets captured in qconsole.log. So, I can write whatever you want to qconsole.log.

On Sun, Mar 19, 2017 at 10:59 AM, killingtime187 notifications@github.com wrote:

I see. Yea, the stats client won't work with these guys and we can't force a single client since everyone uses whatever they prefer these days - dp, fte, qrack, dq, pq, quakespasm, etc.

Can the mod at least write these values to the log? This way my console.c hack can trigger on start/end of stats marker and write to a file.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jp-grossman/crmod/issues/1#issuecomment-287622288, or mute the thread https://github.com/notifications/unsubscribe-auth/AZIRhOObrtmfvOmz_OxPxfYwGf6lxKs5ks5rnUK2gaJpZM4MbPGl .

[killingtime187]

Ok. So, to get things started, can we beef up the output with those items above along with some marker like autostats start/end? I'll just look for these and send to a separate file. Can switch over to some simple script and leave the server source alone as well. If there's anything else in the attached requests file that can be done easily as well, we can throw in without any change to my log parsing script. The stats parser can ignore until it gets to it.

[jp-grossman]

I've pushed 6.6.1 with the following changes:

• console autostats now contains summary line "## minute #v# match on ###"
• console player stats (included in autostats) now include ping and IP
• better table headings for console stats

Note that you can search for "CRMod Match Statistics" to find the start of the stats dump and "No teams present" to find the end

[killingtime187]

Thanks! Will upload and try and it. We'll close this issue if all works (create new ones for other requests).

[killingtime187]

There are other cfg files in the crmod folder such as autoexec.cfg, ban.cfg, crmod.cfg, and levels.cfg. Do these need to be in the parent dir as well when generating progs.dat ?

[jp-grossman]

No, those are just needed when you run.

On Mar 26, 2017 4:03 PM, "killingtime187" notifications@github.com wrote:

There are other cfg files in the crmod folder such as autoexec.cfg, ban.cfg, crmod.cfg, and levels.cfg. Do these need to be in the parent dir as well when generating progs.dat ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jp-grossman/crmod/issues/1#issuecomment-289310739, or mute the thread https://github.com/notifications/unsubscribe-auth/AZIRhAmEkanRCh66bE7lsXTTWPdIj9xtks5rpsSjgaJpZM4MbPGl .

[turtlevan]

Man this is really great that CRMod is being updated!

[jp-grossman]

It's really great that it's still being used :D

On Mar 30, 2017 12:22 PM, "turtlevan" notifications@github.com wrote:

Man this is really great that CRMod is being updated!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jp-grossman/crmod/issues/1#issuecomment-290463794, or mute the thread https://github.com/notifications/unsubscribe-auth/AZIRhMCdjn7hhOBLP2TSMSlz6NnUvTkzks5rq9atgaJpZM4MbPGl .

[killingtime187]

Verified working!