Ant Zucaro [Sun, 17 Feb 2013 21:05:33 +0000 (16:05 -0500)]
"Intercept" requests during downtime
This is a Golang utility that allows the stats maintainer to still
accept requests from remote servers while the XonStat server is
down for maintenance. It basically takes the requests and stores
them into a small sqlite3 database for future (re)submission.
When users navigate to the normal stats URL, they'll be greeted
with a downpage informing them of maintenance work instead of the
normal app.
Usage of xs_interceptor:
xs_interceptor [options] <command>
Where <command> is one of the following:
create - create the requests db (sqlite3 db file)
drop - remove the requests db
list - lists the requests in the db
serve - listens for stats requests, storing them if found
resubmit - resubmits the requests to another URL
Where [options] is one or more of the following:
-port - port number (int) to listen on for 'serve' command
-url - url (string) to submit requests
Ant Zucaro [Wed, 6 Feb 2013 02:30:12 +0000 (21:30 -0500)]
Two new utilities written in Go.
xs_parselog parses XonStat log and extracts/recreates requests
into text files, one request per file.
xs_submit takes a XonStat request via a text file and submits it
to a user-specified URL.
Both of these utlities can be run with "go run <filename> [opts]"
after having install the Go programming language on your machine.
Alternatively, one can build executables with "go build <filename>".
Ant Zucaro [Fri, 25 Jan 2013 22:41:38 +0000 (17:41 -0500)]
Allow version-specific gametype support.
It often happens when a gametype can't be supported because of
some random bug in the server code. This presents a problem
for when the bug is fixed, but servers still use the old code. We
can now specify that a game type is supported only after a certain
time by using version number restrictions. For example, CA is
supported, but only if the stats submission version is >= 5. Older
servers still having versions <= 5 won't record CA b/c they would
not pass this restriction.
antzucaro [Fri, 4 Jan 2013 19:14:55 +0000 (14:14 -0500)]
Add request verification parameter in the dev INI.
This was added to the production.ini file without going in here
first. It controls whether or not to verify requests using the
d0_blind_id library provided by Xonotic (not packaged in this
project).
antzucaro [Sun, 30 Dec 2012 16:40:55 +0000 (11:40 -0500)]
Add a plain text hashkey view for menu integration.
This adds a plain text response view at the URL /player/<hashkey>,
where hashkey is the idfp of a given player. The response is quite
lengthy and won't be specified in this message, but suffice to say
that the response roughly corresponds to the player_info JSON view
currently at /player/<player_id>.json.
Ant Zucaro [Mon, 24 Dec 2012 14:38:34 +0000 (09:38 -0500)]
Add a basic game finder view at the /gamefinder URL.
The game finder view is intended to be a better advanced search.
We'll see how it works out, but for now at least I can use this
view to show more of the "recent games" tables for each entity.
Ant Zucaro [Sat, 22 Dec 2012 21:57:46 +0000 (16:57 -0500)]
Refactor the "top <blah>" tables on the front page, cache them.
The main_index view was getting a little long, so I factored out
the "top <blah>" data queries into separate functions. I cached
those functions under an hourly term while I was at it.
Ant Zucaro [Sat, 22 Dec 2012 20:59:17 +0000 (15:59 -0500)]
Simplify the rank table calculations. Woohoo, negative LOC!
Before the main view was running three separate, similar queries
to grab the rank data for the three game types shown on the page.
This was factored out into a separate function that can be called
and cached (currently hourly_term). Also if no ranks are available,
don't show tables filled with '-' characters, but rather an
informative message instead.
Ant Zucaro [Tue, 11 Dec 2012 22:28:02 +0000 (17:28 -0500)]
Add a JSON Elo view to support autobalance.
The view at /elo/<hashkey> will send just Elo info about a player.
This is to facilitate a possible autobalance feature where the
Xonotic server will request Elo values for all of the
players entering the game, then use it (among other things) to
figure out who needs to be switched to make the teams right.
Ant Zucaro [Tue, 4 Dec 2012 02:55:22 +0000 (21:55 -0500)]
Add a hashkey view similar to the player_info JSON one.
This view is driven by hashkey (not player_id) so the Xonotic
server can query for info using something it knows. The response
value is a JSON object containing the things in the player info
page minus the recent weapons and recent games stuff.
The URL pattern is /hashkey/<hashkey value>.
All this is pretty alpha and is subject to change once we truly
determine our needs Think of this as a proof of concept for
communicating between the game server and the webapp.
Ant Zucaro [Sun, 25 Nov 2012 15:15:48 +0000 (10:15 -0500)]
Small copy change for the server info page.
"Recent" isn't exactly recent for some servers. I'll label it
"Most Recent" instead. That makes more sense when servers have
not had any games in a long time.
Ant Zucaro [Mon, 19 Nov 2012 00:27:14 +0000 (19:27 -0500)]
Make the "recent games" section more modular.
The main page was constructing all of the recent games queries
manually before. Now I've moved the query and the associated
class (which would have been a namedtuple if not for the various
transformations needed) into a new "helpers" view. This view is
intended to house query functions and the corresponding classes
for them, so no more grabbing from a query, then looping around
and creating namedtuples to get stuff like nick_html_colors. Now
one can just pass the row returned by the query to a class, which
will "know" how to construct stuff like that. Win!
Ant Zucaro [Wed, 14 Nov 2012 04:02:56 +0000 (23:02 -0500)]
Provide an option to show elo deltas on the game info page.
I was tired of looking at the actual elo deltas by bouncing
between the player_info and game_info pages for several
players just to see their collective elo delta values. This
provides a query parameter "show_elo" to the game info page
to show the extra elo delta column.
As a bonus, the up/down/neutral arrows on the player_info
page will take you to a scoreboard page where those values
are shown.
Ant Zucaro [Fri, 9 Nov 2012 04:42:29 +0000 (23:42 -0500)]
Handle Elos properly when players have big alivetimes.
Due to a bug, the alivetimes for players also include time
spent in warmup. Since elo uses score per second, the
skewed alivetime made players who actually lost look like
they won under certain circumstances (like when their
opponent spent a very long time in warmup).
This change puts a ceiling on the alivetime used by Elo
by limiting the alivetime to be at most the game's
duration.