| 00:04.05 | *** join/#brlcad madant (n=madant@117.196.132.90) |
| 00:35.04 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 02:51.56 | *** join/#brlcad madant (n=madant@117.196.132.139) |
| 02:53.36 | yukonbob | hello, cadheads |
| 03:34.16 | pacman87 | howdy, yukonbob |
| 03:37.41 | *** join/#brlcad madant (n=madant@117.196.138.147) |
| 03:55.18 | starseeker | is surprised by how much info the gsoc mentor form requires |
| 03:58.26 | yukonbob | hey pacman87 |
| 04:09.48 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 04:31.57 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) |
| 04:33.44 | starseeker | ah, there's pixie's rib parser: http://pixie.svn.sourceforge.net/viewvc/pixie/trunk/src/rndr/rndr.cpp?revision=1193&view=markup |
| 04:37.51 | brlcad | notes that task is listed: http://brlcad.org/~sean/ideas.html |
| 04:39.05 | brlcad | another integration idea was to test out pixie itself as a "shader" or as an rt lighting model |
| 04:41.55 | pacman87 | brlcad: is the "cylindrical wedge" on that list (under primitives) just a cylinder with base/top at an arbitrary angle? |
| 04:43.57 | brlcad | pacman87: http://mathworld.wolfram.com/CylindricalWedge.html |
| 04:44.15 | brlcad | pretty simple primitive |
| 04:44.32 | pacman87 | looks like it |
| 04:45.25 | brlcad | basically a tgc/rcc but sliced through the side and one base at an arbitrary orientation |
| 04:47.35 | brlcad | input params are somewhat different |
| 04:47.55 | pacman87 | yeah, that's what i was thinking about |
| 04:48.12 | pacman87 | same thing with the hyp |
| 04:48.27 | pacman87 | a few different ways to specify dimensions |
| 04:48.41 | brlcad | not sure if it could be easily generalized to a generalized conical wedge instead of right circular |
| 04:49.26 | pacman87 | radius, height vector, and two normal vectors for the surfaces? |
| 04:50.38 | brlcad | cylindrical wedge starts getting down into the weeds of being an interesting starter primitive for someone to learn with |
| 04:51.07 | brlcad | somewhat limited uses though |
| 04:51.23 | pacman87 | yeah, but it being on the TODO list struck me as a "why hasn't it happened yet?" |
| 04:52.32 | brlcad | nah, I'm thinking actually something like tgc where top ij vectors are maybe 2:1 and bottom vectors are 1:2 (looks sorta twisted), then slice through side and base |
| 04:52.58 | brlcad | that's the ideas page, not quite the same as the TODO file |
| 04:53.17 | brlcad | though both contain items that are just "would be nice to have" regardless of priority |
| 04:53.25 | pacman87 | it'd be nice if each primitive had all of its dimensions editable, and the user selects which set are driving, and leaving the rest driven |
| 04:54.25 | brlcad | not necessarily things that we are actively pursuing |
| 04:54.25 | pacman87 | ah, i should read the url and/or the page title |
| 04:54.27 | brlcad | heh, or the big paragraph at the beginning ;) |
| 04:54.29 | *** join/#brlcad dreeves_ (n=IceChat7@67.130.253.14) |
| 04:55.02 | yukonbob | that cylindrical wedge is perdy |
| 04:55.03 | pacman87 | one of my big questions with the sweep is how to manage the 'orientation along the path' |
| 05:04.48 | brlcad | you could limit the orientation to make it piecewise -- make the sweep only have a starting orientation/azimuth and an ending azimuth |
| 05:05.03 | brlcad | then linearly interpolate |
| 05:05.48 | brlcad | or would take the spline input curve and allow the specification of N orientations along that path ranged from 0.0 to 1.0 distance along the sweep curve (and then linearly interpolate) |
| 05:10.45 | brlcad | autocad allows the sketch to be perpendicular or at an angle, along a spline path, with twisting angles (azimuths), and scaling factors |
| 05:11.08 | brlcad | twists and scales are both linearly interp'd, though twists can be more than 360 |
| 05:11.44 | brlcad | http://www.dailyautocad.com/autocad/3d-modeling-8-using-sweep-command/ |
| 05:12.11 | pacman87 | most of my experience is from solidworks |
| 05:13.45 | brlcad | similar flexibility |
| 05:13.49 | brlcad | http://www.solidsmack.com/how-the-heck-is-this-made-creating-solidworks-spirals-sweeps-and-helixes/2008-10-01/ |
| 05:16.17 | brlcad | not sure how they did the hourglass other than by tying multiples together or if solidworks has keypoints |
| 05:18.43 | brlcad | aha, guide curves |
| 05:18.48 | brlcad | http://www.youtube.com/watch?v=3OUCd8Fp0cE |
| 07:54.27 | *** join/#brlcad madant_ (n=madant@117.196.151.246) |
| 08:17.39 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) |
| 08:17.46 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) |
| 08:21.43 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) |
| 08:23.38 | *** join/#brlcad MinuteEl1ctron (n=MinuteEl@bz.bzflag.bz) |
| 08:30.52 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) |
| 08:37.38 | *** join/#brlcad madant_ (n=madant@117.196.138.104) |
| 08:41.01 | madant_ | to anybody interested :) theoretical foundations of geometric constraint solving.. the references are the good part ;) http://www.cs.purdue.edu/homes/cmh/electrobook/theory.html |
| 08:49.17 | CIA-40 | BRL-CAD: 03Homovulgaris 07http://brlcad.org * r1291 10/wiki/Libpc: Basic Structure |
| 08:49.39 | CIA-40 | BRL-CAD: 03Homovulgaris 07http://brlcad.org * r1292 10/wiki/Developer_Documents: /* Development Projects */ |
| 08:50.38 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:53.42 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:55.22 | *** join/#brlcad madant__ (n=madant@117.196.140.211) |
| 09:57.21 | *** join/#brlcad madant (n=madant@117.196.140.211) |
| 11:26.11 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 12:36.00 | mafm | brlcad: any candidate for the GUI framework? |
| 12:37.02 | d-lo | Why are *YOU* so interested, eh? =D |
| 12:37.16 | mafm | because I might have to do some mentoring |
| 12:37.56 | mafm | or hide behind the armchair in the case that s/he embarrases me with his/her skills :) |
| 12:43.03 | mafm | d-lo: are you going to be a mentor this year? does it depend on the projects elected, I guess |
| 12:43.27 | d-lo | mafm: could be one! |
| 12:47.26 | mafm | d-lo: I don't if I should say congrats, or I feel for you :) |
| 12:50.12 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 13:23.44 | *** join/#brlcad madant (n=madant@117.196.144.175) |
| 13:49.25 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 13:50.25 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) |
| 14:04.46 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 14:06.13 | ``Erik_ | "csg ray trace optimisations" sounds insanely vague O.o |
| 14:25.00 | *** join/#brlcad pacman87 (i=500@resnet-46-40.dorm.utexas.edu) |
| 14:53.23 | starseeker | sees the article on the Texas school board and winces |
| 15:07.24 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:24.27 | *** join/#brlcad ``Erik__ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:57.07 | *** join/#brlcad ``Erik___ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:57.10 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 16:00.04 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) |
| 16:07.32 | CIA-40 | BRL-CAD: 03d_rossberg * r34073 10/brlcad/trunk/src/conv/CMakeLists.txt: included g5-g4 downgrade tool |
| 16:11.35 | CIA-40 | BRL-CAD: 03d_rossberg * r34074 10/rt^3/trunk/ (include/brlcad/Object.h src/coreInterface/Object.cpp): the return value of Copy() is always ignored |
| 16:13.43 | CIA-40 | BRL-CAD: 03d_rossberg * r34075 10/rt^3/trunk/ (8 files in 2 dirs): revised error handling |
| 16:52.14 | *** join/#brlcad cad38 (n=c752f34a@bz.bzflag.bz) |
| 17:11.35 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 17:25.05 | CIA-40 | BRL-CAD: 03Adminssmith 07http://brlcad.org * r1293 10/wiki/Main_Page: |
| 17:46.39 | starseeker | brlcad: hmm, the db5.h header has a DB5_MINORTYPE_BRLCAD_COMBINATION entry, but the spec lists combinations as a non-geometry type |
| 18:06.39 | d-lo | www.nbos.com |
| 18:17.31 | ``Erik | nifty, I'm back online |
| 18:17.36 | ``Erik | yay, comcast! |
| 18:17.45 | d-lo | They finally fix your connection? |
| 18:17.50 | ``Erik | no |
| 18:17.53 | ``Erik | yay, they suck. :D |
| 18:22.13 | CIA-40 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Adminssmith]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 18:22.42 | CIA-40 | BRL-CAD: 03Sean 07http://brlcad.org * r1294 10/wiki/Main_Page: Undo revision 1293 by [[Special:Contributions/Adminssmith|Adminssmith]] ([[User talk:Adminssmith|Talk]]) |
| 18:23.23 | ``Erik | huh, nutty, one of their distributors is in bellevue, wa |
| 18:23.36 | ``Erik | drove there to buy cd's and blue hair dye back in the day |
| 18:26.34 | d-lo | blue? heh. heheh.. ....ROFL |
| 18:26.51 | ``Erik | O.o what? :D |
| 18:27.01 | ``Erik | it was the mid 90's in the seattle area |
| 18:27.06 | ``Erik | I was COOL, yo! (or somethin') |
| 18:27.38 | hippieindamakin8 | ``Erik, mid 90s and Seattle woah wat a place to be :) |
| 18:28.17 | hippieindamakin8 | but i would prefer going back to the times of woodstock and me a hippie ;) |
| 18:28.29 | hippieindamakin8 | 68 i meant |
| 18:34.23 | starseeker | mutter mutter... grip and joint have geometry minor types too, despite having minor types in major type 1 |
| 18:36.09 | starseeker | not clean |
| 18:43.50 | starseeker | wishes these geometry minor types could have been assigned in an order based on mathematical grouping... oh, well |
| 18:46.01 | CIA-40 | BRL-CAD: 03starseeker * r34076 10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add in content up to geometry minor types table. |
| 18:55.08 | CIA-40 | BRL-CAD: 03starseeker * r34077 10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add geometry attributes minor type section. |
| 18:55.36 | starseeker | whoops, that was a major type session |
| 19:42.49 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 20:00.13 | *** join/#brlcad ``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 20:40.20 | *** join/#brlcad tina__ (n=tina@f053144017.adsl.alicedsl.de) |
| 20:42.24 | *** part/#brlcad tina__ (n=tina@f053144017.adsl.alicedsl.de) |
| 20:44.35 | *** join/#brlcad BigAToo (n=BigAToo@66.103.88.193) |
| 20:48.45 | *** join/#brlcad BigATo1 (n=BigAToo@66.103.88.193) |
| 21:07.04 | *** join/#brlcad andrecastelo (n=chatzill@189.71.33.19) |
| 21:45.18 | CIA-40 | BRL-CAD: 03starseeker * r34078 10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add spec contents up to Object Length. |
| 21:51.02 | starseeker | <snort> I like the part were it says "detailed specifications of each of these are necessary..." |
| 22:06.19 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-245-172.dclient.hispeed.ch) |
| 22:07.13 | CIA-40 | BRL-CAD: 03Paulcs 07http://brlcad.org * r1295 10/wiki/Animation: /* Compositing an animation */ |
| 22:11.54 | CIA-40 | BRL-CAD: 03Paulcs 07http://brlcad.org * r1296 10/wiki/Animation: /* With Mencoder */ |
| 22:12.20 | *** join/#brlcad csanyipal (n=csanyipa@252-144-85-95.dynamic.stcable.net) |
| 22:12.28 | csanyipal | howdy! |
| 22:13.47 | csanyipal | I want just to say that that I wrote down a small addon to http://brlcad.org/wiki/Animation. |
| 22:14.16 | csanyipal | One can use Mencoder to create an animation from png files. |
| 22:14.33 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 22:53.23 | Ralith | wonders if there are any version control systems that don't suffer horrible lag when dealing with codebases this large |
| 22:55.21 | Ralith | huh, this is weird |
| 22:55.45 | Ralith | 'svn diff' is showing lots of changes that I didn't make; it's like instead of applying some revisions it just skipped them and assumed I'd deleted them. |
| 22:56.43 | Ralith | is tempted to revert his changes, but that'd mean starting over from scratch. |
| 22:56.50 | Ralith | that's what I get for going idle for a long period, I guess |
| 23:07.45 | Ralith | looks like something to do with lineendings. |
| 23:09.03 | Ralith | someone wiped out all the ^Ms and for some reason svn thinks I put them back? |
| 23:17.15 | Ralith | begins making extensive use of revert --recursive |
| 23:20.32 | Ralith | looks like it's mostly in .dsp files. |
| 23:21.39 | Ralith | okay, that halved the diff size. |
| 23:23.56 | Ralith | .dsp files are huge. |
| 23:26.27 | Ralith | hey, I wonder how hard it would be to write a tool to evaluate a single line of cpp syntax in context. |
| 23:27.39 | ``Erik | "cpp syntax in context"? |
| 23:27.39 | Ralith | okay, I'm back down to my actual changes! yay! :D |
| 23:28.08 | Ralith | ``Erik: as in, considering other cpp expressions in the file, such as includes and defines, as would be necessary for useful behavior in most cases. |
| 23:28.21 | Ralith | basically, run cpp on the file and extract the corresponding line. |
| 23:28.47 | Ralith | does cpp offer any way to determine the corresponding line, or would that have to be hacked on? |
| 23:28.52 | ``Erik | ah, I usually just do gcc -E | less and search for something close |
| 23:29.03 | Ralith | yeah, but wouldn't it be awesome to have it bound in emacs? |
| 23:29.30 | Ralith | perhaps a minibuffer message showing the expansion, and a keybind to perform the replacement. |
| 23:30.12 | ``Erik | I'm sure a little elithp could handle that fairly easily, provided you can pull the actual command to compile the object |
| 23:30.54 | Ralith | wouldn't it just be a matter of running cpp on it? |
| 23:31.04 | Ralith | still not sure how to extract the relevant line(s) though. |
| 23:31.16 | ``Erik | post-cpp code has #1234 springled through it to help the compiler get line numbers correct, be a matter of finding the greatest line indicator before your line of interest, then counting (mebbe doing 5 or so lines to help with context) |
| 23:31.29 | Ralith | oo |
| 23:31.31 | Ralith | that's helpful |
| 23:31.44 | ``Erik | gcc -E myprog.c > myprog.cpp ; grep '^#[0-9]' myprog.cpp |
| 23:31.57 | Ralith | is gcc -E perferable to cpp? |
| 23:31.58 | ``Erik | (or .e if you don't want to confuse the more retarded c++ developers) |
| 23:32.07 | Ralith | lol |
| 23:32.09 | ``Erik | um, they should execute the same code |
| 23:32.17 | Ralith | hm, I suppose one problem would be getting the include paths right |
| 23:32.33 | ``Erik | yup, thus my comment about getting the actual command to compile the object :) |
| 23:32.38 | Ralith | ahh, that's what you meant. |
| 23:32.41 | ``Erik | then you could s/-c -o blah.o/-E/ |
| 23:32.47 | Ralith | yeah. |
| 23:32.58 | Ralith | perhaps have it parse Makefiles? |
| 23:33.03 | Ralith | that's getting kind of specialized though |
| 23:33.39 | Ralith | ...weird, I appear to have finished these changes. |
| 23:33.56 | ``Erik | iirc, emacs has the ability to execute make with some combination of 18 keys held down simultaniously |
| 23:34.24 | ``Erik | finding how it does that, and changing it to do "rm thisfile.o && make thisfile.o" to crib it |
| 23:34.31 | Ralith | only three, actually. I used to know it, but I've been using enough arcane toolchains lately that I've just been running a terminal instance in the same desktop and switching to that. |
| 23:34.43 | ``Erik | or, if you use bsd make instead of gnu make, make -V might be able to do it |
| 23:34.55 | Ralith | well, that's unportable |
| 23:35.10 | ``Erik | yeah, but expecting to use gcc is unportable, as well |
| 23:35.46 | ``Erik | would imagine a couple big honkin' (cond) statements |
| 23:35.48 | Ralith | point. |
| 23:35.56 | Ralith | yeah that's just inelegant |
| 23:36.11 | Ralith | at least assuming gcc works across probably 95% of installations |
| 23:36.31 | Ralith | certainly in our case. |
| 23:36.35 | ``Erik | hrm |
| 23:36.45 | ``Erik | 'cept we test compile on like 5 different compilers, dude |
| 23:36.53 | Ralith | but what do we all *use*? |
| 23:36.58 | ``Erik | mipspro, sunw, ... |
| 23:37.04 | ``Erik | a couple msvc's |
| 23:37.28 | ``Erik | mebbe we should use tendra :D |
| 23:37.32 | Ralith | besides, we'd have to assume makefiles to get anywhere |
| 23:37.47 | Ralith | and that's probably less common than gcc in the world at large |
| 23:37.54 | Ralith | well, who knows |
| 23:38.06 | ``Erik | aaanyways, it's all shades of grey, where to draw the line is an engineering decision :) |
| 23:38.10 | Ralith | ultimately I think gcc's a reasonable assumption for the purposes of a convenience tools. |
| 23:38.13 | Ralith | tool* |
| 23:38.21 | ``Erik | primarily developes on FBSD, which has been itching to dump gcc for quite a while |
| 23:38.33 | ``Erik | some argued tendra, now there's another one that's getting attention |
| 23:38.34 | Ralith | pcc does look shiny., |
| 23:38.41 | bjorkintosh | in favor of what? |
| 23:38.44 | Ralith | see above |
| 23:38.49 | ``Erik | izzit pcc? |
| 23:38.52 | Ralith | pretty sure. |
| 23:39.03 | Ralith | that's the one that, iirc, OpenBSD has been giving lots of attention to |
| 23:39.09 | ``Erik | sounds about right *shrug* I d'no, I got tired of all the bikeshedding around that topic |
| 23:39.17 | Ralith | and OpenBSD seems to have a habit of starting trends. |
| 23:39.33 | Ralith | pcc is interesting to me because last I heard of it it was much faster than gcc. |
| 23:39.52 | Ralith | not that that's *too* valuable in the long run, but handy in a dev environment, and on source-based systems. |
| 23:40.05 | ``Erik | fast compiling, or faster generated code? |
| 23:40.08 | Ralith | the former |
| 23:40.22 | Ralith | I'd be surprised if they could match gcc's slew of optimization options. |
| 23:41.04 | ``Erik | the bsd's feed off of eachother a lot, they're all radically different than eachother (far more different than linux distros), but have a lot of community overlap and listen to eachother well, it's neat |
| 23:41.22 | ``Erik | uhm, until recently, gcc was pretty shitty at optimizing, even microsoft was wiping the floor with gcc3 |
| 23:41.22 | Ralith | yeah, BSD's awesome. |
| 23:41.29 | Ralith | right, until recently. |
| 23:41.33 | Ralith | not so anymore. |
| 23:41.36 | Ralith | (or so I hear.) |
| 23:41.42 | ``Erik | the new, uh, TSA code in 4 made gcc40 far slower, but it sped up a lot pretty fast |
| 23:42.01 | Ralith | I have to confess I've installed linux on my desktop, though |
| 23:42.13 | ``Erik | used to have linux machines, now only has them at work :) |
| 23:42.13 | Ralith | sometimes you just gotta run some flash :P |
| 23:42.22 | ``Erik | <-- pets his hackintops |
| 23:42.43 | Ralith | and I've also been toying with graphics stuff lately, and nvidia hasn't released a Cg compiler for FreeBSD yet. |
| 23:43.16 | Ralith | I really wish the hardware industry was more open. |
| 23:43.17 | ``Erik | the first thing I did when I bought my old g3 ibook was watch strongbad email. all of it. :D |
| 23:44.02 | ``Erik | nvidia drags its feet a LOT with the fbsd stuff, I had to email them to get a release to allow a 3 year old card to work :( |
| 23:44.20 | Ralith | I'm just thankful they support it at all. |
| 23:44.37 | ``Erik | that was a fight and a half heh |
| 23:44.47 | Ralith | well, less thankful, more amazed. |
| 23:44.56 | ``Erik | they didn't move until people were reverse engineering their hardware out in public |
| 23:45.09 | Ralith | it's even somewhat more stable than the nvidia/X I have set up on this linux box |
| 23:45.21 | ``Erik | I imagine it was just to throw a carrot to prevent their "vital secrets" from being figured out by angsty fbsd fools |
| 23:45.22 | ``Erik | :) |
| 23:45.25 | Ralith | though that may be more due to FreeBSD than nvidia. |
| 23:45.29 | Ralith | lol |
| 23:45.33 | Ralith | that reminds me |
| 23:45.38 | Ralith | how's ATI doing with that whole releasing the docs thing? |
| 23:45.40 | ``Erik | quickest way to make a fbsd unstable - nvidia driver. :D |
| 23:45.45 | ``Erik | <-- hasn't been following |
| 23:46.28 | Ralith | 'kay |
| 23:46.35 | Ralith | cuz that was really exciting when I first heard about it |
| 23:46.41 | Ralith | but didn't really seem to go anywhere. |
| 23:49.30 | ``Erik | "marylin manson???" "yeah, it's all his or her fault! I'm going to give him or her a piece of my mind or penis" hah |
| 23:51.41 | Ralith | ``Erik: on a more topical subject: I'm a bit unsure what proper procedure is for me with respect to committing code (in this case, a removal of the redundant vecmath.h from lgt). I've got write access, or did last I checked, but I'm uncertain if I should be requesting review (after testing to the best of my ability, of course) before checking changes in. |
| 23:53.23 | Ralith | (said removal is nontrivial as it required swapping out macros with different syntax, and I know of no clear way to verify that it all still works the same once compiled) |
| 23:55.12 | ``Erik | the benchmark suite? :) |
| 23:55.20 | Ralith | covers lgt? |
| 23:55.28 | ``Erik | commits can always be undone, but if you want review, you can always post the patch somewhere |
| 23:55.34 | ``Erik | oh, lgt, um |
| 23:55.37 | ``Erik | d'no |
| 23:56.04 | Ralith | yeah, I'm just wondering if I should make a point of requesting review. |
| 23:57.26 | ``Erik | depends on how confident you are :) it'll get reviewed either way |
| 23:58.13 | ``Erik | the commit bit is the "we trust you enough to do what's right, or suffer the horrible reprecussions" |
| 23:58.28 | Ralith | kk, thanks for clearing that up |
| 23:58.42 | ``Erik | w00t, clear as mud! :D |