Timestamps are in GMT/BST.
| 00:28:07 | raptor | ok back |
| 00:33:04 | | BFLogBot - Commit 0d4c73c5b008 | Author: watusim...@bitfighter.org | Log: Painfully reduce code duplication, experimental rendering change (feel free to further modify) |
| 00:46:21 | | koda has joined |
| 01:01:04 | raptor | time to look at this commit... |
| 01:13:35 | raptor | so you removed my full health bar feedback |
| 01:19:36 | raptor | i guess it isn't needed as much since we can accurately detect panels in range and that need health |
| 01:34:57 | | Watusimoto Quit (Ping timeout: 244 seconds) |
| 04:12:33 | | raptor Quit (Ping timeout: 252 seconds) |
| 05:06:10 | | koda Quit (Quit: I used to be chatting like you. Then I took an arrow in the knee) |
| 06:50:09 | | sam686 Quit (Ping timeout: 245 seconds) |
| 06:55:16 | | zoomber_mbp has joined |
| 07:19:17 | | LordDVG has joined |
| 07:20:14 | | zoomber_mbp Quit (Quit: zoomber_mbp) |
| 09:55:47 | | Watusimoto has joined |
| 10:48:21 | | LordDVG Quit (Remote host closed the connection) |
| 12:02:07 | | LordDVG has joined |
| 13:21:28 | | LordDVG Quit (Remote host closed the connection) |
| 13:23:52 | | LordDVG has joined |
| 13:28:08 | | koda has joined |
| 14:21:15 | | raptor has joined |
| 14:21:15 | | ChanServ sets mode +o raptor |
| 14:21:38 | raptor | good morning |
| 15:34:54 | | koda Quit (Quit: koda) |
| 15:36:51 | raptor | Watusimoto: what do we have left for 017? |
| 16:56:17 | Watusimoto | the running buglist mostly |
| 16:56:34 | raptor | haven't looked in a while.. |
| 16:57:11 | raptor | did you mean to make the panel stakes extend to the panels? |
| 16:57:13 | | sam686 has joined |
| 16:57:13 | | ChanServ sets mode +v sam686 |
| 16:58:53 | Watusimoto | mmmm probably not? |
| 17:00:52 | raptor | ok, i change back |
| 17:02:00 | raptor | so did we fulfill 'make core look good again' ? |
| 17:06:39 | | BFLogBot - Commit d4daa6faaaee | Author: buckyballreaction | Log: Fix rendering panel repair point |
| 17:09:14 | Watusimoto | yes |
| 17:09:22 | Watusimoto | back in a bit |
| 17:09:42 | raptor | there is one anomaly i've noticed since you've consolidated the panel info |
| 17:10:07 | raptor | when repairing, energy will sometimes be used with out the repair ray |
| 18:42:11 | | raptor Quit () |
| 20:06:49 | | sam686 Quit (Ping timeout: 245 seconds) |
| 20:52:34 | | koda has joined |
| 20:55:31 | | sam686 has joined |
| 20:55:31 | | ChanServ sets mode +v sam686 |
| 21:15:05 | | raptor has joined |
| 21:15:05 | | ChanServ sets mode +o raptor |
| 21:15:24 | raptor | hola hola |
| 21:32:49 | raptor | someone brought up the idea of more level information that could be shown when looking throught the 'change level' list |
| 21:33:07 | | LordDVG Quit (Remote host closed the connection) |
| 21:33:26 | raptor | they specifically wanted to know level creation date so they could see newer levels and maybe sort by 'newest' |
| 22:10:32 | Watusimoto | hi |
| 22:10:36 | raptor | hi |
| 22:10:46 | Watusimoto | my fomer boss just offered me a 6 month contract for 250K |
| 22:10:52 | raptor | !! |
| 22:11:01 | Watusimoto | that's what I said |
| 22:11:32 | Watusimoto | then he explained it to me, and I thought I could subcontract it to my wife |
| 22:11:35 | Watusimoto | easy peasy |
| 22:11:51 | raptor | what |
| 22:12:09 | raptor | sounds fishy |
| 22:12:20 | Watusimoto | no, totally legit |
| 22:12:42 | Watusimoto | then I read the actual work description, and told him not to do the project at all |
| 22:13:11 | Watusimoto | I've concluded I am the only person alive who really understands why the project as described is impossible |
| 22:13:16 | Watusimoto | or nearly so |
| 22:13:17 | raptor | ha! |
| 22:13:56 | Watusimoto | so I'm writing him a letter with some ideas of how he can capitalize on the failure of another contractor to accomplish the task |
| 22:14:06 | raptor | ha |
| 22:14:08 | raptor | wow |
| 22:14:13 | Watusimoto | too bad there will be no profit in it for me |
| 22:15:21 | raptor | sad |
| 22:17:03 | Watusimoto | ah well |
| 22:35:41 | Watusimoto | so... back to reality. does the problem with the cores still exist, and how can i experience it? |
| 22:35:57 | raptor | yeah... not sure what is causing it |
| 22:36:04 | raptor | just damage a panel |
| 22:36:45 | raptor | then heal it, you'll see the repair ray disappear and the health bar fill up but you'r energy will still drain for a 1/2 second |
| 22:36:53 | raptor | *your |
| 22:48:38 | Watusimoto | design question: |
| 22:48:48 | Watusimoto | we need to display leaderboard in the game somehow |
| 22:48:56 | Watusimoto | I'm thinking as a page off the main menu |
| 22:48:57 | raptor | hmmm |
| 22:49:07 | Watusimoto | sort of like a help screen |
| 22:49:13 | raptor | 'highscores' menu on the main m enu? |
| 22:49:17 | raptor | then with multiple pages |
| 22:49:18 | Watusimoto | something like that |
| 22:49:25 | Watusimoto | or just wiht one page for now |
| 22:49:34 | Watusimoto | depending on what we want to show |
| 22:49:42 | Watusimoto | I was thinking of the same data from the home page |
| 22:49:49 | Watusimoto | 4 sets of 3 names |
| 22:49:55 | raptor | sure |
| 22:49:58 | Watusimoto | so here is the question |
| 22:50:10 | raptor | althought i'd like to change to a materialized view somehow... |
| 22:50:35 | Watusimoto | do we just have the master send 12 names and 12 scores, and have the client simply know what order things will be coming in? or... |
| 22:51:50 | Watusimoto | or do we send 'category names' in addition, maybe something like "highest scores this week", "most plays this week", etc., along with the names so we can change what stats are displayed wihtout releasing a new client and creating a new m2c method |
| 22:52:11 | Watusimoto | basically, how hardocded should we make it? |
| 22:52:17 | raptor | always less! |
| 22:52:47 | raptor | i like the idea of the categories |
| 22:52:48 | Watusimoto | well, the less hardocded it is, the more we need to do things like auto-calculate where to render things to look good |
| 22:53:06 | Watusimoto | if we decide that there will always be 4 groups of 3, rendering becomes a lot less complex |
| 22:53:10 | raptor | yeah but there would be reduced maintenance in the future |
| 22:53:48 | Watusimoto | so you think we should develop a scheme for displaying n groups of m players, with aribitrary group names? |
| 22:54:11 | raptor | or |
| 22:54:16 | Watusimoto | and laying them out somehow on the page, or distributing them across multiple pages? |
| 22:54:34 | raptor | have a set m and n and overflow to another page |
| 22:55:23 | Watusimoto | I guess I don't understand that |
| 22:56:15 | raptor | so have say 4 columns, 3 rows per page |
| 22:56:25 | raptor | each block will have a title and three players |
| 22:56:31 | raptor | block per category |
| 22:56:42 | raptor | any more than 12 categories will overflow to page 2 |
| 22:56:58 | raptor | those were just random numbers |
| 22:57:13 | raptor | but jus tone idea |
| 22:58:43 | Watusimoto | oh, I see |
| 22:58:51 | Watusimoto | yes, that could work |
| 22:59:06 | Watusimoto | with auto centering vertically or whatever |
| 22:59:14 | raptor | yes |
| 22:59:18 | raptor | or whatever |
| 22:59:29 | Watusimoto | so we would always send the same number of players in each category? |
| 22:59:44 | raptor | i don't know would we? |
| 22:59:48 | raptor | 3 |
| 22:59:49 | Watusimoto | or would we want to send 2 names for one, 5 for another |
| 22:59:58 | raptor | top 3 in any metric? |
| 23:00:13 | Watusimoto | I was thinking of sending the same for all metrics, but perhaps having the master determine what that number is |
| 23:00:20 | Watusimoto | so we could change from top 3 to top 5 |
| 23:00:27 | raptor | sounds good to me |
| 23:00:30 | Watusimoto | but it would be top 5 for everything |
| 23:00:37 | Watusimoto | that doesn't really make it more complex |
| 23:00:55 | raptor | might have to shrink the text accordingly for each blcok |
| 23:01:04 | raptor | clokb |
| 23:01:06 | raptor | argh |
| 23:01:07 | raptor | block |
| 23:01:17 | Watusimoto | maybe |
| 23:01:34 | Watusimoto | We have something similar with the unused team shuffle feature |
| 23:01:44 | raptor | oh yeah, haha |
| 23:01:48 | raptor | i forgot about that... |
| 23:01:54 | Watusimoto | I wonder if any of that code could be leveraged |
| 23:01:58 | raptor | that was never used in the last BBB, i don't think |
| 23:02:09 | Watusimoto | no, good idea, forgotten feature |
| 23:07:48 | Watusimoto | so we send a vector of strings (category names) , followed by a vector of strings (player names, scores) |
| 23:08:16 | raptor | sur |
| 23:08:17 | raptor | sure |
| 23:08:27 | Watusimoto | then the client can simply divide the number of player names by the number of categories to get player names / category |
| 23:08:50 | Watusimoto | and sending scores as strings lets us send ints or floats, depending on what makes sense for the record |
| 23:09:21 | Watusimoto | then the client simply creates the right number of tables and where to display them |
| 23:09:30 | raptor | yes |
| 23:09:58 | Watusimoto | I started on a m2cSendLeaderBoard (or similar), but that may need to be redone |
| 23:10:34 | Watusimoto | when you open the score menu, client will send c2mRequestLeaderboard, and master will respond |
| 23:10:48 | Watusimoto | so every time you open the menu you get the updated values |
| 23:11:01 | raptor | ok |
| 23:11:16 | Watusimoto | yeah, that will work |
| 23:11:32 | Watusimoto | won't give us 100% flexibility, but probably enough |
| 23:12:07 | raptor | on master side i think there should be a cache of sorts for the query data, either with a materialized view (which I'm not sure you can do with mysql) or with a c++ cache that is updated by a thread |
| 23:12:11 | raptor | every so often |
| 23:13:43 | Watusimoto | mysql has no materialized view -- only db I know of that does is sqlserver |
| 23:14:03 | Watusimoto | but people may want to check their scores after every game |
| 23:14:03 | raptor | i don't know that one... i work with oracle at work, they have it |
| 23:14:20 | raptor | so a cache that is triggered by the end of a game? |
| 23:14:26 | Watusimoto | sqlserver = microsoft |
| 23:14:48 | Watusimoto | maybe cache is marked as stale, but not refreshed until someone actually requests it |
| 23:14:53 | raptor | master accepts stats at the end of a game - why don't we trigger the cache update after it receives new stats |
| 23:14:56 | Watusimoto | but yes, I think that makes sense |
| 23:15:09 | raptor | then hold it until next game stats arrive |
| 23:15:11 | Watusimoto | don't update cache until it is requested |
| 23:15:28 | Watusimoto | just mark it as stale, and if someone requests, and cache is stale, refresh it |
| 23:15:55 | Watusimoto | same strategy I used for panelgeometry |
| 23:16:17 | Watusimoto | no sense querying if no one is asking for the data |
| 23:16:30 | raptor | yes i see that... |
| 23:16:33 | raptor | and i like that |
| 23:16:35 | raptor | but |
| 23:16:51 | raptor | i naturally think about load |
| 23:16:58 | raptor | but that probably doesn't matter in our case |
| 23:17:05 | raptor | because our community is so small |
| 23:17:26 | Watusimoto | true |
| 23:17:41 | raptor | so the cache would always be up to date in my scenario and allow for quicker response time |
| 23:17:52 | Watusimoto | sure, ok |
| 23:18:03 | Watusimoto | I think in practice it will be exactly the same |
| 23:18:07 | raptor | yep, me too |
| 23:18:27 | Watusimoto | if you code it we query every time; if I code it, we mark as stale :-) |
| 23:18:47 | raptor | are you talking client or server side? |
| 23:18:55 | Watusimoto | and if sam686 codes it, he'll use his own scheme! |
| 23:18:57 | raptor | maybe our ideas aren't in conflict... |
| 23:19:00 | Watusimoto | server |
| 23:19:12 | raptor | i'm saying server side, the cache is only updated when a games stats arrive |
| 23:19:19 | Watusimoto | understood |
| 23:19:28 | Watusimoto | client is only updated when they open the menu |
| 23:19:30 | raptor | then it sits and can handle as many requests as the clients want, without having to requery the DV |
| 23:19:36 | raptor | DB |
| 23:19:41 | Watusimoto | right |
| 23:19:45 | raptor | ok |
| 23:19:46 | Watusimoto | I was discussing the same thing |
| 23:19:48 | raptor | we do understand each other |
| 23:20:14 | Watusimoto | finally going to try to reproduce the core bug |
| 23:20:21 | Watusimoto | you described many moons ago |
| 23:20:22 | raptor | ok |
| 23:20:41 | Watusimoto | I should at least get one thing done tonight |
| 23:20:58 | raptor | the answer might be to force invalid panel info once a panel is healed all the way |
| 23:21:10 | Watusimoto | I showed my kids how to use bittorrent today... |
| 23:21:13 | Watusimoto | I may regret that |
| 23:21:18 | raptor | ha! |
| 23:21:30 | raptor | and y ou run windows? |
| 23:21:45 | raptor | make sure they download no archives or executables |
| 23:21:46 | Watusimoto | uyes, with microtorrent client |
| 23:21:51 | Watusimoto | yes |
| 23:22:00 | raptor | because you'll be in a lot of hurt fast :) |
| 23:22:18 | Watusimoto | I wanted to watch a nova show with them, but nova is blocked overseas |
| 23:22:24 | raptor | lame |
| 23:22:34 | Watusimoto | I help pay for $%^& nova shows, so I think I should be able to see them |
| 23:23:01 | Watusimoto | but I tried out the mtorrent streaming functino; worked pretty well |
| 23:23:50 | raptor | one day we humans will get distribution of an unlimited resource (digital audio/video) right... |
| 23:29:19 | Watusimoto | how long until a thumbdrive can hold all published music? then the distribution problem will be solved |
| 23:29:44 | raptor | go sneakernet! |
| 23:30:08 | Watusimoto | that's really the endgame |
| 23:30:12 | raptor | yep |
| 23:30:19 | Watusimoto | and it's coming |
| 23:30:23 | raptor | oh yeah |
| 23:30:26 | Watusimoto | 10 years? |
| 23:30:28 | raptor | like a locomotive |
| 23:30:36 | raptor | distribution is unlimited |
| 23:30:40 | raptor | creation is not |
| 23:30:51 | raptor | so how do creators get compensated? |
| 23:31:00 | Watusimoto | concerts & merch |
| 23:31:02 | raptor | problems problems... and i have no solutions |
| 23:31:21 | raptor | i can see that |
| 23:31:36 | Watusimoto | people fundamentally create because they enjoy it |
| 23:32:17 | Watusimoto | they do deserve to get paid |
| 23:32:23 | Watusimoto | if they're good |
| 23:32:28 | raptor | i agree |
| 23:32:35 | raptor | we probably have too many artists right now.. |
| 23:32:36 | Watusimoto | but it just isn;t goinig to happen via music sales |
| 23:32:47 | Watusimoto | that's just a fact |
| 23:33:53 | raptor | need more engineers |
| 23:33:57 | raptor | maybe researchers |
| 23:34:08 | raptor | but definitely fewer artists |
| 23:42:46 | raptor | did you dupe the Core bug? (you have to keep holding down the module button after a panel looks healed all the way) |
| 23:42:57 | raptor | if you do /settime 0, they stop rotating and it's easier |