WIP: Frontend and API for entry kill heatmaps - #42
Conversation
| self._handle_historical_entry_kills_heatmap) | ||
| router.add_get('/games/csgo/historical/entry_kills_heatmaps', | ||
| self._handle_historical_entry_kills_heatmap) | ||
| router.add_get('/api/games/csgo/historical/entry_kills', |
There was a problem hiding this comment.
can we replace 'historical' with 'replay' or 'events'? I also think entry_kills_heatmaps is probably too specific, maybe just 'location_events'? I think we want to use GET args to actually filter what kind of events we get. e.g. location_events?ev_types=deaths&custom_filter=first_in_game for getting entry kills
| self._handle_gsi_moneylog) | ||
| router.add_get('/games/csgo/historical/entry_kills_heatmaps', | ||
| self._handle_historical_entry_kills_heatmap) | ||
| router.add_get('/games/csgo/historical/entry_kills_heatmaps', |
There was a problem hiding this comment.
Why is this specified twice?
3a4b294 to
b27542f
Compare
This creates two new routes: /games/csgo/events/entry_kills_heatmaps - a webpage with some configuration buttons allowing the user to drill down and create a heatmap graphic containing exactly what they want /api/games/csgo/location/events - a json api endpoint that returns location data for the event type queried. This is all vaporware at this point but an example query can be found in the template used in the entry_kills_heatmaps endpoint. Right now we're looking at 'ev_types=deaths' and 'custom_filter=first_in_game'.
So far just tables of players and teams, with getters.
b27542f to
02cbb06
Compare
| victim_pos_z real, | ||
| assister integer REFERENCES cs_go_steam_ids (id), | ||
| weapon_original_owner integer REFERENCES cs_go_steam_ids (id), | ||
| penetrated boolean, |
There was a problem hiding this comment.
This is actually a short integer (Postgres type is smallint). It's the number of objects that the shot penetrated before the kill.
| weapon_original_owner integer REFERENCES cs_go_steam_ids (id), | ||
| penetrated boolean, | ||
| weapon text, | ||
| map text |
There was a problem hiding this comment.
Should we also keep track of the game ID and the tick here? That would make it easy to find the first player_death event of any game.
There was a problem hiding this comment.
Yah we need meta information for at least:
match
map (sometimes matches are best of 3 or best of 5)
round
tick
seconds into round?
Autobots, normalize!
And the associated relation tables
The order of table creation is picky because there are multiple tables that refer to keys in other tables.
| id serial PRIMARY KEY, | ||
| steam_id text UNIQUE NOT NULL | ||
| steam_id text UNIQUE NOT NULL, | ||
| print_name text, |
There was a problem hiding this comment.
I dont think we can have this column here as names are changeable. The two options are make this a list (although theres some issues there perf wise) or break this out in to its own table we refer in to (probably best).
| weapon_original_owner integer REFERENCES cs_go_steam_ids (id), | ||
| penetrated smallint, | ||
| weapon text, | ||
| map_name text, |
There was a problem hiding this comment.
Why do we need this if we have the cs_go_map releation?
There was a problem hiding this comment.
We don't. Will remove.
| penetrated smallint, | ||
| weapon text, | ||
| map_name text, | ||
| attacker_team text, |
There was a problem hiding this comment.
shouldnt this be a reference to cs_go_team_ids?
There was a problem hiding this comment.
team as in T or CT
| weapon text, | ||
| map_name text, | ||
| attacker_team text, | ||
| victim_team text, |
There was a problem hiding this comment.
Same, also a reference to cs_go_team_ids
There was a problem hiding this comment.
team as in T or CT
| async def create_schema(conn): | ||
| await conn.execute(''' | ||
| CREATE TABLE cs_go_team_ids( | ||
| id serial PRIMARY KEY |
There was a problem hiding this comment.
This table is going to require some thinking. If we have no information to distinguish a 'team' other than name then wouldnt two differently named teams always be considered different teams (and therefore name for a team would belong in this table)? I suspect the idea is we want to use some other information to correlate events from a team even if the name isnt exatly the same. If so, then we have to figure out what other information we are going to use and that information has to be added as a column in this table.
There was a problem hiding this comment.
Sounds like theres an hltv id which is the main source of truth we should try for disambiguating a team. Lets add a hltv_id column here
| @staticmethod | ||
| async def create_schema(conn): | ||
| await conn.execute(''' | ||
| CREATE TABLE cs_go_team_ids( |
There was a problem hiding this comment.
Lets just call this table cs_go_teams (id isnt an external property here like steamid, its a key were using internally).
| CREATE TABLE cs_go_death_events( | ||
| id serial PRIMARY KEY, | ||
| attacker integer REFERENCES cs_go_steam_ids (id), | ||
| attacker_pos_x real, |
There was a problem hiding this comment.
I get the motivation with adding all of these properties, but I would recommend starting with the minimal set. The idea of the separate hltv events table is it should be trivial for us to add in properties later on and if we start huge like this then theres just going to be a lot of initial work before getting an end-to-end demo working.
There was a problem hiding this comment.
Yah I agree that anything not directly needed should be dropped. All of these are pulled directly from the example paste ryan put together of what's already in the death event. If any of these values give us trouble, drop them then?
| @staticmethod | ||
| async def create_schema(conn): | ||
| await conn.execute(''' | ||
| CREATE TABLE cs_go_team_names( |
There was a problem hiding this comment.
For now we can probably remove this table in the name of simplicity and add a column in the main teams table called hltv_name which is probably what well want to use for team names.
3 participants
This is an example.
Do not merge