#bitfighter IRC Log

Index Search ←Prev date Next date→

IRC Log for 2012-06-22

Timestamps are in GMT/BST.

00:51:38BFLogBot - Commit ad238b849627 | Author: watusim...@bitfighter.org | Log: Experiment with organizing enum values in Lua... logprint(Weapons.Triple) now prints "2"... exciting, I know!
00:52:04Watusimoto Quit (Ping timeout: 246 seconds)
01:09:14raptor has joined
01:09:14ChanServ sets mode +o raptor
01:17:00kaenhello hello
01:17:23kaenI've been reading some old threads regarding stats. I didn't realize it was such a hot topic
02:22:59raptorhi
02:23:15raptori still have one kid to get to bed...
02:23:40raptoryes, lots of discussion about stats... most of it is gone in my memory - but we definitely need to do more
02:23:47raptorbrb
02:24:00kaengotcha
02:29:43raptorok, newbork isn't ready to sleep yet...
02:29:54raptorany questions regarding stats?
02:44:23kaenwould you be adverse to keeping an aggregate userdata table? perhaps with a chron job or similar?
02:46:19kaenthe table of stats entries for players is already pretty long. you could keep per-game data for some time period, and then just drop them.
02:47:06kaen*after aggregating them
02:51:03raptor Quit (Ping timeout: 246 seconds)
02:56:51raptor has joined
02:56:51ChanServ sets mode +o raptor
02:58:39raptorhi again
02:58:49kaenahoy
02:59:09raptorwell
02:59:23raptorwe have timestamps and lots of indexes on our data
02:59:38raptorwe can always create views that filter for a time...
03:01:43raptorare you thinking something along the lines of: after a year we move all the data to an archive, then start over with the stats?
03:03:07kaenoh, no. I just meant keeping a table of running total stats, and updating that record from the table of individual reports (stats_player) rather than searching all records for 'kaen' and summing the values.
03:03:12kaenwhat you said works fine, too
03:03:28raptorwe've started creating 'views'
03:03:28kaenbut for something like-alltime stats we'd still be doing the above
03:03:33kaennice.
03:03:41kaenas in MVC views?
03:03:51raptorno no: a database view
03:03:57kaensure.
03:04:12raptorare you familiar with database views?
03:04:22kaenapparently not
03:04:30kaenthe term isn't familiar at least
03:04:50raptorthere are two types: views and materialized views (which mysql doesn't really have)
03:05:01raptorbasically it's a stored query forced to look like a new table
03:05:16raptorso you'd make some complex query, then store it as a view
03:05:23kaenoh!
03:05:29raptorthen all you have to do in the future is 'select * from some_dumb_view'
03:05:41raptorinstead of redoing the query all over again
03:05:58kaenalright.
03:06:08raptorwe do that for the highscores
03:10:55kaendude you just blew my mind
03:21:34raptor:)
03:37:27raptori think in the database dump i gave you, the views are 'tables' that start with v_
03:37:38kaenyes indeed
03:38:18raptorok
03:38:19raptortonight
03:38:31raptori'm going to finally finish this teleport problem of mine
03:40:09raptor... after i do an assignment..
03:40:13raptorsigh
03:40:33kaenheh. you can play when your homework is done
04:23:31raptorok time to play!
04:37:07BFLogBot - Commit 9de5d62b7f0b | Author: buckyballreaction | Log: Remove dead code
06:15:26kaen Quit (Ping timeout: 246 seconds)
06:16:20raptor Quit ()
06:16:28kaen has joined
07:08:04sam686 Quit (Ping timeout: 245 seconds)
07:11:09raptor has joined
07:11:09ChanServ sets mode +o raptor
07:14:11raptor Quit (Client Quit)
07:17:43BFLogBot - Commit ec2659a963d1 | Author: buckyballreaction | Log: Client-side feedback that another player is engineering a teleport. Still needs work
07:28:25watusimoto has joined
07:28:25ChanServ sets mode +o watusimoto
09:37:21LordDVG has joined
12:31:59watusimoto1 has joined
12:34:47watusimoto Quit (Ping timeout: 246 seconds)
14:09:59watusimoto1 Quit (Read error: Operation timed out)
14:26:18watusimoto has joined
14:26:18ChanServ sets mode +o watusimoto
14:37:15raptor has joined
14:37:16ChanServ sets mode +o raptor
14:37:21raptorgood day!
14:43:19raptorok, let's see what damage I did with my half-awake commit last night...
14:43:59Watusimoto_ has joined
14:52:30watusimotoI know the feeling
14:52:50raptorwell, it compiles...
15:05:55Watusimoto_ Quit (Ping timeout: 260 seconds)
15:20:24ppedruzzi has joined
15:27:10raptorhi ppedruzzi
15:27:36ppedruzzihi!
15:28:00raptorwelcome to #bitfighter
15:28:41ppedruzzithanks
15:30:50watusimotohi
15:31:39raptorwatusimoto: if i cancel (using ESCAPE) placing a teleport exit, what should happen?
15:31:48raptorteleport explode?
15:32:07raptorright now you just get stuck with the inability to use weapons and modules... :)
15:56:45watusimotoif you cancel (is escape the right key for that? what about js users?), the teleport should probably expode, since that's the only way we have to exit objects from the game. Or perhaps it could do the collapsy effect withtout the sfx and sparks
15:57:20raptorso destruction..
16:04:44watusimotoby fire or by ice
16:05:14raptorfirey ice?
16:09:32kaenmorning
16:11:14kaenI was thinking more about views and storing player stats last night. what if we used a faux materialized view and an update trigger on stats_player? that way queries will be updated instantly and we won't have to run an aggregating query each time we need a player's stats
16:14:01kaenalternatively, we could use real views and query caching, but then we'd have either process the query in php each time, or only support a defined set of queries. additionally, the query cache is intelligently invalidated on inserts, so the queries would still be re-run after every game
16:14:28kaenhave to either*
16:22:38watusimotoI'm too fried to comment intelligently on what you just wrote! I'm off to watch my kids march in a parade in front of the heir to the throne here in Luxembourg.
16:22:53kaenhave fun :)
16:23:08watusimotobut I will say that materialized views aren't an option (unfortunately, as they combine performance with ease of use)
16:23:19watusimotonot an option because our database doesn't support them
16:23:26watusimotoraptor can confirm
16:23:26kaenwe can make our own :)
16:23:27watusimotolater
16:23:32watusimotoyes
16:23:34watusimoto:-)
16:23:38kaenthat's what I meant
16:23:41watusimotoI'll defer to the expert
16:23:47watusimoto(i.e. you, apparently :-)
16:23:51kaendefinitely raptor
16:23:51kaenlol
16:23:53watusimotociao
16:23:56kaenbb
16:28:37watusimoto Quit (Ping timeout: 276 seconds)
16:36:54raptorsomeone said my name
16:37:33raptorkaen: you're suggesting to use the trigger hack to fake a materialized view in mysql since they don't exist?
16:38:25kaenjust brainstorming, really
16:38:27kaenbut yes
16:38:31raptorwhich data do you suggest to put into such a view?
16:38:51kaenthe aggregated data for player stats, kills, deaths, shots, etc.
16:39:15kaenI guess my assumption is that aggregating that on each query won't scale well when/if bitfighter becomes popular.
16:39:22raptoryou've sure done your research...
16:39:26raptoryour assumption is correct
16:39:31kaenI'm a research kind of guy
16:42:23raptorwhen you say aggregate data, do you mean the data that is built for gamereports/ ?
16:43:37kaenI think so. Specifically, I mean the data in stats_player and stats_player_shots
16:44:12kaenhonestly I'm new to the whole dba thing, so feel free to shoot me down if I'm being silly :)
16:44:16kaenI won't take it hard
16:44:42raptorheh - you've actually come up with all the right ideas
16:45:08raptorthe next step is to build a query that makes most sense to have cached
16:46:03raptorone thing to remember: a caching table that is updated with a trigger will take up as much space as the tables it's pulling from
16:48:21kaenthe way I imagined it is that it would have one row for each unique player, so all entries for player x get condensed into one. wouldn't that make it a fraction of the combined sizes of stats_player and stats_player_shots?
16:49:53raptormaybe... would it still be per-player-per-game?
16:50:01kaenso we'd aggregate it manually once for a baseline, then add the appropriate data to each row every time there's an insertion on either of those
16:50:05kaenoh, no
16:50:22raptoreven if the row count diminishes, the column count increases, so memory usage stays roughly the same..
16:50:24raptoroh
16:51:51kaenthat data is already accessible from stats_player, so I figured that could be used as-is for stats by game
16:52:00kaensince it is well-indexed
16:53:24raptori think i'd have to see the query put together that you're thinking about...
16:53:32kaenI thought so
16:55:51raptori have to to a meeting - be back in an hour or so
16:55:56raptor*to go to
16:56:01kaenhave fun!
16:56:05raptorugh
16:56:12kaen:P
17:31:52raptorok back
18:32:30Watusimoto has joined
19:49:57sam686 has joined
19:49:57ChanServ sets mode +v sam686
20:14:08Watusimoto Quit (Ping timeout: 240 seconds)
20:17:04ppedruzzi Quit (Quit: Page closed)
20:35:01kaenraptor, whenever you get time I wrote a query for the cache tabel/material view/whatever I'm thinking of
20:35:03kaenhttp://pastie.org/4134328
20:35:14kaentable, even
20:35:53kaenand then it would need insert triggers, too
20:39:38raptorhi
20:39:39raptorlooking...
20:44:25raptorit works!
20:45:20raptorare you thinking of having specific views set up for different time intervals? also how do you envision using the data?
20:45:56raptorI'm thinking we could easily pull 'top 3 with the most XXX in the last 30 days'
20:51:23kaenI envision using the data sort of like this: http://ladder.tearyoudown.com/
20:52:18kaenbuilding different views for different time intervals is a great idea, too. admittedly, I hadn't thought of that.
20:52:38kaenI just used a time filter so the query ran in a sane amount of time during testing
21:16:44LordDVG Quit (Remote host closed the connection)
21:20:40raptormaybe
21:21:12raptormaybe we could put up another page at /playerreports/ and somehow organize the data
21:21:59raptorwe could probably display the raw data in some client-side JS library so any sorting and stuff could be done client-side
21:29:11kaenhmm, that might be feasible, depending on how we encoded the data
21:30:02kaenit would be sizable even as json
21:30:20raptoryeah, it would have to be json
21:31:13kaenset it as { player: [array,of,stats] } ?
21:31:22kaenwould be the most compact form I can think of.
21:31:43raptoryep
21:32:09raptorso are you more of a web programmer than utilty programmer?
21:32:13kaenwell, I'd bet with the time filter that would be pretty manageable
21:32:16kaendefinitely.
21:32:39raptorI program web apps for work, but at heart i love the utility/automation side of things...
21:32:58raptori reserver a special hatred for web programming...
21:33:06kaenthat's the same way I feel about web programming :)
21:33:10raptorwell, maybe that's too strong...
21:33:12raptorhaha
21:33:21kaenwhen I grow up I want to be an embedded systems developer
21:33:22kaenno joke.
21:33:36kaenbut I'm pragmatic and know that I have a better change at a web job :/
21:33:46raptorcool
21:33:59kaenchance*
21:34:18raptori think some day i might want to make my favorite programming language a soldering iron...
21:34:34raptor(I heard someone say that somewhere..)
21:34:42kaenit's a good one
21:35:06kaenI have a set of PIC chips still in their static sleves
21:36:02kaenwhen I ordered my programmer they sent me an old-school parallel port one instead of usb, so I'm waiting for it to come
21:36:12raptoryeah - i have some lying around somewhere from the hardware intro i got in the IT department..
21:36:19raptorha!
21:37:48raptorok, well, i'm heading out for a campfire dinner
21:37:56kaenoh nice
21:38:00raptori'll be back late...
21:38:08kaenlater
21:38:13raptorbye
21:38:29raptor Quit ()
22:06:12Watusimoto has joined
22:16:22koda has joined
22:25:05sam686 has left
22:30:55koda Quit (Ping timeout: 265 seconds)
22:36:58koda has joined

Index Search ←Prev date Next date→

These logs were automatically created by BFLogBot on irc.freenode.net.