Timestamps are in GMT/BST.
| 00:02:36 | raptor | question for anyone: given (const Vector<Point> *points, const Point &offset), will the following update each point in place?: |
| 00:02:45 | raptor | for(S32 i = 0; i < points->size(); i++) |
| 00:02:46 | raptor | (points->points->get(i) += offset); |
| 00:04:52 | | koda Quit (Quit: you can't say 'hello' without saying 'hell') |
| 00:05:28 | Watusimoto_ | does it compile? |
| 00:05:45 | Watusimoto_ | if so, it probably will |
| 00:05:47 | Watusimoto_ | work |
| 00:07:38 | raptor | everything needs to be turned into a vertex array... |
| 00:07:46 | raptor | tedious |
| 00:08:03 | Watusimoto_ | can you use a clever macro? |
| 00:09:37 | raptor | not really, the biggest hiccup is with glVertex2f - it can't be standalone anymore |
| 00:10:08 | raptor | but that's OK, everything will be drawn faster |
| 00:29:09 | Watusimoto_ | yes, I suspect this will be good overall |
| 00:31:57 | raptor | can you tell me if this looks correct? http://pastie.org/4217944 |
| 00:32:09 | raptor | the top commented-out part is the original |
| 00:33:41 | raptor | or even if there is a more efficient way to build an array |
| 00:41:19 | Watusimoto_ | looking |
| 00:42:21 | Watusimoto_ | what is this from, anyway? |
| 00:42:40 | raptor | the render health bar method in gameObjectRender |
| 00:42:48 | raptor | renderHealthBar |
| 00:43:22 | Watusimoto_ | looks ok, though I would have done it slightly differently |
| 00:43:30 | Watusimoto_ | maybe |
| 00:43:51 | Watusimoto_ | Point vertexArray[2*hatchCount]; |
| 00:44:04 | Watusimoto_ | instead of a vector |
| 00:44:07 | raptor | ok |
| 00:44:11 | Watusimoto_ | but the difference is very marginal |
| 00:44:12 | raptor | good idea |
| 00:44:20 | Watusimoto_ | but since you want an array in the end... |
| 00:44:29 | Watusimoto_ | and you know the size... |
| 00:44:41 | raptor | i need an F32 array in the end |
| 00:44:59 | raptor | is there a quick way to convert Point[] to F32[]? |
| 00:45:05 | Watusimoto_ | not yet :-) |
| 00:45:11 | Watusimoto_ | although... |
| 00:45:18 | Watusimoto_ | maybe you can just cast it |
| 00:45:32 | Watusimoto_ | you want x1,y1,x2,y2,... |
| 00:45:35 | Watusimoto_ | right? |
| 00:45:48 | raptor | correct |
| 00:46:02 | raptor | where all x's and y's are dynamically generated in the loop.. |
| 00:46:20 | Watusimoto_ | try casting it to F32[] and see what happens |
| 00:46:29 | Watusimoto_ | that would save some work! |
| 00:46:57 | Watusimoto_ | you might need to use one of the unusual casts (reinterpret_cast, perhaps?) |
| 00:47:29 | raptor | hmmm |
| 00:47:32 | Watusimoto_ | actually, why not start with an F32 array |
| 00:47:34 | raptor | not a sloiw down? |
| 00:47:40 | Watusimoto_ | and forgo point altogether? |
| 00:47:54 | Watusimoto_ | oh, I see why |
| 00:47:59 | Watusimoto_ | points are a lot easier here |
| 00:48:06 | raptor | yes |
| 00:48:38 | Watusimoto_ | well, I've never done it quite this way, but the only data members of point are x, y |
| 00:49:02 | Watusimoto_ | so if classes really are structs, then it *should* be convertable |
| 00:49:12 | raptor | yes, using address() was something i saw else where in gameObjectRender, and it works |
| 00:50:17 | Watusimoto_ | oh, and there they want F32s, right? |
| 00:50:22 | Watusimoto_ | so yes, it should work fine |
| 00:50:26 | raptor | yes |
| 00:50:34 | raptor | ok, so maybe just leave the Vector? |
| 00:50:50 | Watusimoto_ | it's fine; I was just saying *I* would use an array |
| 00:51:07 | Watusimoto_ | it is probably 1% more efficient |
| 00:51:16 | Watusimoto_ | in a non-critical portion of the code |
| 00:51:24 | raptor | if the cast works, you mean |
| 00:51:27 | Watusimoto_ | yes |
| 00:51:42 | Watusimoto_ | if not, vector is better than reconstructing a F32 array manually |
| 00:51:45 | Watusimoto_ | much better |
| 00:51:57 | Watusimoto_ | but if this works, leave it and move on |
| 00:54:33 | raptor | hmm... how to cast... |
| 00:59:54 | Watusimoto_ | you could do reinterpret cast |
| 01:00:03 | raptor | this works: (F32*)(vertexArray) |
| 01:00:08 | Watusimoto_ | or perhaps do a F32 *arr..... |
| 01:00:10 | Watusimoto_ | yes, that |
| 01:00:31 | raptor | reinterpret_cast works too, but everywhere i read says to try and avoid it.. |
| 01:00:35 | Watusimoto_ | yes |
| 01:00:44 | Watusimoto_ | but they also say to avoid c-style casts :-) |
| 01:00:50 | raptor | very true... |
| 01:00:59 | Watusimoto_ | but I prefer the C style, I think |
| 01:02:39 | raptor | looks like C style will just pick any of the ones that work (besides dynamic) |
| 01:07:01 | Watusimoto_ | really... I thought it was just brute force. that probably explains why it doesn't always work |
| 01:07:21 | raptor | one of the best posts on the topic: http://stackoverflow.com/a/332086 |
| 01:08:57 | raptor | i can't seem to be able to set a Point to a Point[] with array[0] = Point |
| 01:15:06 | raptor | oh man... the teleporter method is a beast... |
| 01:16:40 | Watusimoto_ | get my latest before you work on teleporter |
| 01:16:54 | raptor | did you touch it in gameObjectRender? |
| 01:17:13 | Watusimoto_ | not much |
| 01:17:39 | raptor | if(any 'yes' at all) iUpdateFirst(); |
| 01:17:42 | Watusimoto_ | ok, bed time. 3:17AM |
| 01:17:48 | raptor | good night! |
| 01:18:14 | Watusimoto_ | try compiling my latest at your convenience. I want to know if it will break gcc before I go further |
| 01:18:22 | Watusimoto_ | send me an email |
| 01:18:23 | raptor | ok, puched? |
| 01:18:26 | raptor | pushed |
| 01:18:27 | Watusimoto_ | yes |
| 01:18:31 | | BFLogBot - Commit 83583c12bddd | Author: watusim...@bitfighter.org | Log: formatting |
| 01:18:32 | | BFLogBot - Commit 67c780f9ba74 | Author: watusim...@bitfighter.org | Log: One fewer magic number! |
| 01:18:34 | | BFLogBot - Commit 5d86c055048d | Author: watusim...@bitfighter.org | Log: Make first cut at centralized error checking for lua function params. Will allow auto-documentation as well. Still a couple of transitional things. |
| 01:18:35 | | BFLogBot - Commit 1dbc84baf88d | Author: watusim...@bitfighter.org | Log: Merge |
| 01:18:36 | Watusimoto_ | there we go |
| 01:18:49 | raptor | compiling... |
| 01:18:51 | Watusimoto_ | there's some new stuff in there |
| 01:19:00 | Watusimoto_ | varadic macros |
| 01:19:33 | raptor | what on earth does that mean? |
| 01:20:05 | Watusimoto_ | macros with variable number of params |
| 01:20:55 | Watusimoto_ | compile? |
| 01:21:09 | raptor | almost |
| 01:21:17 | raptor | now it does.. |
| 01:21:20 | raptor | so yes! |
| 01:21:22 | Watusimoto_ | great |
| 01:21:24 | Watusimoto_ | later! |
| 01:21:26 | raptor | i'll check in my minor changes |
| 01:21:27 | raptor | night |
| 01:23:54 | raptor | ok pushed change |
| 01:28:37 | | BFLogBot - Commit c9a23e1fe94f | Author: buckyballreaction | Log: Fix compile error and warning in Linux |
| 01:36:12 | | Watusimoto_ Quit (Ping timeout: 265 seconds) |
| 04:18:35 | raptor | ho hum |
| 04:18:51 | raptor | ES 1.1 conversion is about 1/4 done I think |
| 04:27:12 | sam686 | A dead monitor i have, HP vs17e, starts working again after changing out 3 dead capacitors with working one in the monitor-s electronics... I have 3 working monitors now 1 CRT and 2 LCD (both LCD native is 1280 x 1024 at 60 or 75 Hertz) |
| 04:27:43 | raptor | wow, you changed the capacitors yourself? |
| 04:28:53 | sam686 | yes, i almost burned my hand duing it.. heating up the metal connectors to melt the silver connectors.. |
| 04:29:03 | raptor | ouch |
| 04:29:42 | sam686 | the tools used is about 25 dollers, 3 capactors totals about 4 dollers |
| 04:30:01 | sam686 | cheaper then a new monitor (about 100 to 200 dollers) |
| 04:31:21 | raptor | much |
| 04:31:41 | sam686 | also the monitor I just fixed have a working built-in speakers, none of my other monitor have speakers ( i have separate speakers though). |
| 04:37:29 | raptor | is that your large monitor? |
| 04:39:30 | sam686 | both LCD screen i have is almost exactly same size, My CRT is a little smaller. |
| 04:41:20 | sam686 | my LCD screen height (1280 x 1024) is about 0.5 inch short of full length paper height in portrait paper and landscape screen |
| 04:47:57 | raptor | ok |
| 04:48:07 | raptor | don't you have another CRT that is 2048 wide? |
| 04:58:37 | sam686 | I used to have another CRT, but its very old and can only do 1024 x 768 at 60 hertz (or maybe 2048 x 1536 at 30i but too tiny blurry, and flickery interlace), not flat (round), and smaller then my current CRT |
| 04:59:05 | raptor | ah ok |
| 05:03:18 | sam686 | the most flickery problem about interlace CRT is when viewing this image without rescaling and withoug deflicker: http://sam686.maxhushahn.com/upload/bw_horizontal_lines.gif |
| 05:04:04 | raptor | interesting |
| 05:04:32 | sam686 | I can still use some interlace mode on my CRT, but not on LCD (trying on LCD only displayes black screen with "invalid mode") |
| 05:09:32 | sam686 | I do notice some differences between all of my monitors about the colors... my old LCD is a little red / pink, the LCD I jsut fixed is a little green, my CRT is in between when using 6500K and max contract |
| 05:10:53 | raptor | do you have all three set up on one OS? |
| 05:11:02 | sam686 | maybe pink screen might be a sigh the tiny florescent bulb behind LCD might be more then half way end of life |
| 05:11:19 | sam686 | Yes, i hooked up all 3 monitors into one computer |
| 05:12:20 | sam686 | with windows xp, Radeon 9200 AGP (VGA used, DVI-D, S-Video), and Radeon 9250 PCI (VGA used, DVI-I used as VGA adapter, S_Video TV out) |
| 05:13:03 | raptor | i know some people at work who use 3 monitors... it seems really big |
| 05:13:13 | raptor | i usually have 8 virtual desktops on one monitor instead |
| 05:14:42 | sam686 | Since I have 2 desktop computers, and 3 monitor, and only 4 power cord (all use same power cord), I should get a power cord from somewhere, probably from a store... |
| 05:16:12 | sam686 | problem with virtual desktop is, you can't watch video on one fullscreen virtual desktop, and play or program stuff on another virtual disktop at the same time, like you can on 2 real desktops.. |
| 05:16:54 | raptor | that's true |
| 06:02:48 | sam686 | found a problem, like hostile zone energy recharge being shaky, slipzone is also shaky - might want to fix that.. |
| 06:03:35 | sam686 | that is, shaky if you are not hosting |
| 06:25:58 | raptor | ok, getting sleepy |
| 06:26:00 | raptor | time for bed |
| 06:26:02 | raptor | good night! |
| 06:28:49 | sam686 | ok, night |
| 06:57:46 | | raptor Quit () |
| 08:13:29 | | sam686 Quit (Ping timeout: 245 seconds) |
| 08:14:07 | | Watusimoto has joined |
| 09:15:33 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 09:49:41 | | Watusimoto has joined |
| 11:02:47 | | LordDVG has joined |
| 11:06:08 | | LordDVG Quit (Remote host closed the connection) |
| 13:33:09 | | raptor has joined |
| 13:33:10 | | ChanServ sets mode +o raptor |
| 13:38:01 | raptor | good day |
| 13:52:39 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 15:40:31 | | Watusimoto has joined |
| 15:41:42 | Watusimoto | hi |
| 15:41:46 | raptor | hi |
| 15:41:52 | raptor | no more GL_POLYGON |
| 15:42:02 | raptor | everything must be GL_TRIANGLE_FAN |
| 15:42:22 | Watusimoto | really? |
| 15:42:40 | raptor | yes - so far it's just been drop-and-replace, though, which has been good |
| 15:42:47 | Watusimoto | interesting |
| 15:42:58 | Watusimoto | we already triangulate most of our fills |
| 15:43:09 | raptor | yes - basically the new paradigm is: OpenGL isn't allowed to do any math |
| 15:43:15 | Watusimoto | I see |
| 15:43:31 | raptor | so practically everything is vertex arrays |
| 15:43:53 | Watusimoto | in some cases we may be able to cache those and reuse them |
| 15:44:05 | Watusimoto | like when we draw the same thing over and over |
| 15:44:23 | Watusimoto | an asteroid, for example, or perhaps parts of the ship |
| 15:44:45 | Watusimoto | though I'm not sure if that makes sense in practice |
| 15:45:18 | Watusimoto | can we still use opengl to do rotation and scaling and the such? |
| 15:45:21 | raptor | yes - you'll have to look over the code when i'm done - i'm sure there are plenty of practices that would increase performance |
| 15:45:43 | raptor | so far, yes |
| 15:46:01 | raptor | well, at least translation works ok |
| 15:46:27 | Watusimoto | most of those improvements i make as I find, rather than scouring the code for opportunities for trivial improvement |
| 15:46:49 | Watusimoto | I converted robot.cpp over to the new centralized param checking |
| 15:47:03 | Watusimoto | I figured if that would work, everything else will as well |
| 15:47:16 | Watusimoto | it compiles; trying to figure out a good way to systematically test |
| 15:49:31 | Watusimoto | I *really* want to use nested #defines, but it appears to be impossible :-( |
| 15:50:15 | raptor | ha |
| 15:50:25 | raptor | it's funny that we're all going back to C |
| 15:50:51 | raptor | question: one of the things that i don't feel good about is something like this: http://pastie.org/4220843 |
| 15:51:22 | raptor | the top version works, no problems, but is less performant (at least in my head); the bottom would be faster, but i'm doing something fundamentally wrong |
| 15:51:26 | raptor | any ideas? |
| 15:55:25 | raptor | oops, made a typo - i updated the pastie |
| 15:55:57 | Watusimoto | looking |
| 15:56:49 | Watusimoto | why not do it even faster? |
| 15:56:55 | raptor | ok |
| 15:57:14 | raptor | i eagerly await your idea |
| 15:57:26 | Watusimoto | could we structure it so that we just do a glScale() and use the data already stored in AsteroidCoords[design][i]? |
| 15:57:49 | Watusimoto | then skip the whole data manipulation stage? |
| 15:57:55 | raptor | probably |
| 15:58:02 | raptor | however, i wanted this to be a general case |
| 15:58:29 | raptor | with asteroids we have a predefined static array, many other functions to not and require math in the for loop |
| 15:58:37 | Watusimoto | ok, so what are the weird artifacts? |
| 15:58:53 | raptor | lines go everywhere |
| 15:59:14 | raptor | usually to random far edges of the screen |
| 15:59:38 | raptor | i've tried to use normal C arrays in many, many cases thinking i could get it correct for once |
| 15:59:38 | Watusimoto | ok |
| 15:59:42 | Watusimoto | well, it *looks* right |
| 15:59:44 | raptor | it always ends in disaster |
| 16:00:09 | Watusimoto | what I would do is dump the points before rendering and make sure they are what you expect |
| 16:00:17 | raptor | ah good idea |
| 16:01:46 | Watusimoto | because it looks right |
| 16:02:38 | Watusimoto | might you need to pass a pointer to the array or something? |
| 16:03:03 | raptor | ? |
| 16:03:38 | raptor | renderVertexArray takes an array just like that - it works in several other cases where the array starts as static |
| 16:03:52 | raptor | err.. predefined |
| 16:03:59 | Watusimoto | just guessing: &vertexArray? probably not. |
| 16:04:04 | raptor | nope |
| 16:04:09 | Watusimoto | or *vertexArray? |
| 16:04:20 | Watusimoto | (when weird stuff happens, I usually try those :-) |
| 16:04:49 | raptor | passing in something like this (but filled out) is what the default takes: F32 vertices[] = { }; |
| 16:05:06 | raptor | but i will try... |
| 16:06:18 | raptor | yeah doesn't compile |
| 16:06:20 | Watusimoto | what you have is probably right |
| 16:08:05 | raptor | huh |
| 16:08:11 | raptor | i just got it to work... |
| 16:08:35 | raptor | ok side question: i just came across renderTurretRanges() |
| 16:08:44 | raptor | i've never seen that before - does that currently work? |
| 16:13:04 | Watusimoto | I think we removed it at some point |
| 16:13:14 | Watusimoto | it used to work in the editor, I believe |
| 16:13:27 | Watusimoto | but we had too much stuff going on |
| 16:13:37 | Watusimoto | it *might* still work if the turret is selected |
| 16:13:56 | raptor | ok, well i changed it to GL_TRIANGLE_FAN |
| 16:14:01 | Watusimoto | still works |
| 16:14:04 | raptor | i'll just leave it be... |
| 16:14:09 | raptor | how do i get it to work? |
| 16:14:11 | Watusimoto | even when turret not selected |
| 16:14:14 | Watusimoto | go into editor |
| 16:14:16 | Watusimoto | add a turret |
| 16:14:20 | Watusimoto | press tab |
| 16:14:36 | Watusimoto | ok, you DO need to select the turret |
| 16:14:47 | raptor | oh hey... it draws a square |
| 16:14:56 | Watusimoto | right! |
| 16:14:57 | raptor | cool |
| 16:17:11 | raptor | curious |
| 16:17:25 | raptor | if you drag a barrier in the editor, does the rendering go flying off the screen? |
| 16:18:46 | Watusimoto | ah, I didn't |
| 16:19:00 | Watusimoto | rebuilding now, will check |
| 16:20:00 | Watusimoto | dragging walls in editor works fine |
| 16:20:12 | raptor | i must have done something horrible somewhere... |
| 16:20:38 | Watusimoto | probably... |
| 16:20:39 | raptor | yep... found the problem, too |
| 16:21:06 | Watusimoto | what was the problem with the code you pastied? |
| 16:21:47 | raptor | just a moment - i'm not there yet (again) |
| 16:21:57 | Watusimoto | ok, dinner time |
| 16:21:59 | Watusimoto | back later |
| 16:22:51 | raptor | ok |
| 16:26:59 | | Watusimoto Quit (Ping timeout: 265 seconds) |
| 17:09:24 | raptor | kaen: do you know how to convert a 2D C-style array to one dimension? |
| 17:10:10 | | Watusimoto has joined |
| 17:23:08 | kaen | raptor, do you mean like http://pastebin.com/mYDyjn50 ? |
| 17:24:22 | kaen | you can use an index counter instead of [i * w + j] and increment in the inside loop, as well |
| 17:24:50 | raptor | well... i was thinking more like: *array1D = (array2D[i]); |
| 17:25:01 | raptor | i mean without copying the array |
| 17:25:32 | raptor | it might not be possible - i did get that to compile, but stuff was really messed up |
| 17:28:22 | raptor | so a 4x2, 2D array of ints into a 1x8 array of ints... |
| 17:28:30 | raptor | err 8x1 |
| 17:30:43 | raptor | i have 1 error left in gameObjectRender to be GLES compatible! |
| 17:30:55 | raptor | but it's with rendering the teleporter.. :/ |
| 17:35:43 | kaen | this doesn't work for you? |
| 17:35:43 | kaen | int *arr1d = (int *) arr2d |
| 17:35:55 | raptor | hmm... |
| 17:35:58 | raptor | trying |
| 17:36:28 | kaen | ohhh |
| 17:36:36 | kaen | it references the elements out of order I believe |
| 17:36:51 | kaen | sounds like you will have to copy it :/ |
| 17:37:03 | raptor | really? |
| 17:37:05 | raptor | sadness |
| 17:37:29 | raptor | where did you find the out-of-order info? |
| 17:37:59 | kaen | actually I screwed up in my test code :P |
| 17:38:01 | kaen | it works fine |
| 17:38:21 | kaen | (swapped the order of '/' and '%' while dereferencing) |
| 17:38:41 | raptor | what works fine? |
| 17:39:55 | kaen | <kaen> int *arr1d = (int *) arr2d |
| 17:39:57 | kaen | works fine |
| 17:40:04 | raptor | that is a reinterpret_cast |
| 17:40:05 | kaen | disregard <kaen> it references the elements out of order I believe |
| 17:40:11 | kaen | ah I see |
| 17:40:40 | raptor | let me try a static |
| 17:43:10 | raptor | yeah, so yours compiles |
| 17:43:21 | raptor | but all the data is messed up |
| 17:44:56 | raptor | ah well |
| 17:45:03 | raptor | it's probably out of order data |
| 17:49:00 | kaen | sounds like it was filled as { { 0, 2 }, { 1, 3 } } rather than { { 0, 1}, { 1, 2} } ? |
| 17:49:08 | | raptor Quit (Read error: Connection reset by peer) |
| 17:49:23 | | raptor has joined |
| 17:49:23 | | ChanServ sets mode +o raptor |
| 17:49:54 | kaen | erm, { { 0, 1}, { 2, 3} } |
| 17:50:03 | raptor | i'm going to just have to copy - i want to move on, i think :( |
| 17:50:12 | kaen | blech |
| 17:50:22 | raptor | my current problem: http://sam686.maxhushahn.com/upload/11111111screenshot_1.png |
| 17:50:45 | kaen | :o |
| 17:50:56 | raptor | it's the last thing i need to get to draw with GLES |
| 17:51:08 | raptor | and it's the most complicated... |
| 17:52:17 | raptor | what do y ou think Watusimoto?: http://sam686.maxhushahn.com/upload/11111111screenshot_1.png |
| 17:52:25 | raptor | progress? :) |
| 17:58:35 | raptor | progress!: http://sam686.maxhushahn.com/upload/11111111screenshot_2.png |
| 17:58:43 | raptor | (see if you can spot the difference) |
| 18:17:24 | raptor | gameObjectRender is fully converted! |
| 18:17:33 | raptor | yay, i'd say i''m lik 60% done now |
| 18:18:00 | kaen | \o/ |
| 18:19:14 | kaen | I can't believe how quickly you're moving through this. I wouldn't even know where to start. |
| 18:29:07 | raptor | it's because i'm sacrificing sanity |
| 18:32:33 | raptor | ok, have to go for a few hours... maybe i'll finish up the GLES conversion today.. |
| 18:36:04 | | raptor Quit () |
| 19:19:50 | | sam686 has joined |
| 19:19:50 | | ChanServ sets mode +v sam686 |
| 19:30:45 | Watusimoto | I'm very excited to see if this runs on Android |
| 20:16:54 | | sam686 Quit (Read error: Connection reset by peer) |
| 20:21:08 | | sam686 has joined |
| 20:21:08 | | ChanServ sets mode +v sam686 |
| 20:30:09 | | sam686 Quit (Ping timeout: 245 seconds) |
| 20:48:38 | | koda has joined |
| 20:54:20 | Watusimoto | ok, signing off for the evening. good progress on the lua front today! |
| 20:55:01 | | BFLogBot - Commit 172aecbd4720 | Author: watusim...@bitfighter.org | Log: Variable name |
| 20:55:02 | | BFLogBot - Commit b4dff76a0be9 | Author: watusim...@bitfighter.org | Log: Add Loadout type to Lua param checking, fix compile problem |
| 20:55:04 | | BFLogBot - Commit e25cbe15feb7 | Author: watusim...@bitfighter.org | Log: Convert Robot to new centralized type checking -- introduce several new parameter types, remove duplicate error checking from Lua methods, remove unused functions, rearrange code order in Robot.cpp, and probably a few other things. This compiles but is as of yet untested. |
| 20:55:05 | | BFLogBot - Commit a9b0b3d1d46f | Author: watusim...@bitfighter.org | Log: Move table def closer to where it is actually used, for better understandibility |
| 20:55:07 | | BFLogBot - Commit 37180b0b0e46 | Author: watusim...@bitfighter.org | Log: Formatting |
| 20:55:08 | | BFLogBot - Commit 02131888f15a | Author: watusim...@bitfighter.org | Log: Remove debugging line |
| 20:55:10 | | BFLogBot - Commit c667e68fc54a | Author: watusim...@bitfighter.org | Log: Simplify and fix centralized param checking |
| 20:55:11 | | BFLogBot - Commit 60d40784ac33 | Author: watusim...@bitfighter.org | Log: Remove unneeded args from several robot methods -- luaW made these unnecessary. Also remove lua code that supported this. Depending on your test environment, you may need to copy robot_helper_functions into your test folder. |
| 20:55:13 | | BFLogBot - Commit 1354a6e74cb0 | Author: watusim...@bitfighter.org | Log: Formatting |
| 20:55:14 | | BFLogBot - Commit 929d5126496d | Author: watusim...@bitfighter.org | Log: Convert C cast to static_cast |
| 20:55:16 | | BFLogBot - Commit 027cb8d64458 | Author: watusim...@bitfighter.org | Log: Forgot to remove parameter! |
| 20:55:17 | | BFLogBot - Commit 76e398676fc4 | Author: watusim...@bitfighter.org | Log: More readable code |
| 20:55:19 | | BFLogBot - Commit d970a6c68199 | Author: watusim...@bitfighter.org | Log: Whitespace |
| 20:55:20 | | BFLogBot - Commit 16bf774b4b9c | Author: watusim...@bitfighter.org | Log: Comments |
| 20:55:22 | | BFLogBot - Commit e808051e9ba7 | Author: watusim...@bitfighter.org | Log: Fix bug preventing bots from aiming properly |
| 20:55:23 | | BFLogBot - Commit b084ba9f4c45 | Author: watusim...@bitfighter.org | Log: Comment |
| 20:55:25 | | BFLogBot - Commit f575da6409b0 | Author: watusim...@bitfighter.org | Log: Change -luaclasses cmd line option to -luadocs, formatting |
| 20:55:26 | | BFLogBot - Commit 304c45924316 | Author: watusim...@bitfighter.org | Log: Change help string |
| 20:55:28 | | BFLogBot - Commit 10933b8f73f9 | Author: watusim...@bitfighter.org | Log: Slightly nicer formatting |
| 20:55:29 | | BFLogBot - Commit 4fa569328979 | Author: watusim...@bitfighter.org | Log: Whitespace |
| 21:18:26 | | Watusimoto Quit (Ping timeout: 244 seconds) |
| 22:20:57 | kaen | awesome. suddenly some player's shots aren't registering -.- |
| 22:21:08 | kaen | players' |
| 22:22:00 | | raptor has joined |
| 22:22:00 | | ChanServ sets mode +o raptor |
| 22:31:29 | raptor | 28 changes! |
| 23:13:51 | raptor | i'm sorry... i'm ripping out the ogl console from android |
| 23:14:01 | raptor | (and I can't seem to fix the errors...) |
| 23:16:03 | | sam686 has joined |
| 23:16:03 | | ChanServ sets mode +v sam686 |
| 23:30:09 | | koda Quit (Quit: you can't say 'hello' without saying 'hell') |
