@Kyzrati:
InstallationIf you want to, you can easily integrate this directly into the scoresheets area of gridsagegames.com. This app is super easy to install. You literally just copy the files onto your server and change the scoresheet links and it works. You don't need to build, compile, configure, or enable anything. I think it would make a nice addition. More info in the README.
UpdatesI may update the app when you update the data format on github. I have your cogmind-scoresheet project watched so i will be alerted if you update it.
SuggestionsI have a few suggestions you might work into your next release as time and attention allow:
No JSON file is saved locally on the player's HDD when games are over. This means that 1) players cannot use the Dataminer app offline, and 2) player's that have not elected to upload scores have zero access to JSON structured data and can never use Dataminer for their runs. I'm not sure if outputting.json is easy to do from the cogmind executable, but if it is, that would be a big plus.
Dataminer can be run completely offline by manually "uploading" a JSON scoresheet. The scoresheet is read directly by the browser's javascript, so no server is required. If you can get local JSON output working and elect to ship the game with Dataminer (open source), you can integrate the two very easily with minor adjustments. Players could then view review their games right on their own machine.
The scoresheet hash (the filename used by cogmind-api.gridsagegames.com) is not contained in the file itself. Therefore, the file cannot reference itself using data from within the scoresheet. This creates some problems with locating the file in the first place. It can currently be found at the bottom of the .txt scoresheet output (if uploaded), or in the links on the leaderboards (if uploaded). Ideally, please add `meta.filehash` or similar to .json files.
Scoresheets contain many additional filenames including `header.filename`, `meta.runGuid`, and `meta.runId`. It would be best to standardize these. (This seemingly unimportant detail will be the key to any future database-backed apps in the future). Relational Databases prefer integers for keys, but non-enumerable hashes are better for security if that's important.
The S3 filehash currently being used has no consistent character length. It doesn't NEED to have one, but it would be nice for standardized API usage.
Overall, excellent work on creating all of this wonderful data. Thanks for going the extra mile!