| 00:00.56 | blast007 | :) |
| 00:02.48 | TD-Linux | what did you name it instead? |
| 00:04.08 | JeffM2501 | spawned |
| 00:06.51 | JBdiGriz | Shouldn't it have been "iGotSpwned"? |
| 00:11.19 | brlcad | heh, there would be merit to having an iGotPwn3d() |
| 00:11.32 | brlcad | albeit different purpose |
| 00:12.28 | JBdiGriz | Change all of the variable names to l33+ |
| 00:14.03 | a_meteorite | will a compiler accept utf-8 in it's code? |
| 00:14.10 | a_meteorite | O_o |
| 00:27.40 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-141-158-104-202.pitt.east.verizon.net) |
| 00:39.48 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/include/bzfsAPI.h: API command to move a flag ( reset it and set it's spawn point ). |
| 00:40.08 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/src/bzfs/bzfsAPI.cxx: API command to move a flag ( reset it and set it's spawn point ). |
| 00:40.23 | *** join/#bzflag moriah (i=4736ad0e@gateway/web/cgi-irc/zeebrothers.net/x-bf8691decdcca92c) |
| 00:40.53 | CIA-3 | BZFlag: 03jeffm2501 07v2_0branch * 10bzflag/include/bzfsAPI.h: API command to move a flag ( reset it and set it's spawn point ). |
| 00:41.10 | a_meteorite | nice |
| 00:41.11 | CIA-3 | BZFlag: 03jeffm2501 07v2_0branch * 10bzflag/src/bzfs/bzfsAPI.cxx: API command to move a flag ( reset it and set it's spawn point ). |
| 00:42.51 | JeffM2501 | probalby not the best name for the API function, cus it realy zaps the flag and sets the spawn point. |
| 00:43.03 | JeffM2501 | not like you can just make the flag move on it's own. |
| 00:43.23 | blast007 | JeffM2501: hmm, actually you can |
| 00:43.28 | JeffM2501 | how? |
| 00:43.33 | blast007 | I had a server where the flags drifted across the ground |
| 00:43.39 | JeffM2501 | what'd you send? |
| 00:43.43 | JeffM2501 | a flag update? |
| 00:43.44 | blast007 | can't remember |
| 00:43.46 | blast007 | probably |
| 00:43.54 | JeffM2501 | pFlag->resetFlag(pos, true); |
| 00:43.54 | JeffM2501 | sendFlagUpdate(*pFlag); |
| 00:44.42 | JeffM2501 | ya think just set pFlag->flag.position? |
| 00:44.46 | JeffM2501 | and then send the update? |
| 00:44.53 | blast007 | probably better to spawn it anyways |
| 00:45.02 | JeffM2501 | I can make reseting it a paramater |
| 00:45.05 | blast007 | I was just doing it for fun |
| 00:45.16 | blast007 | (not sure if it had any negative effects) |
| 00:45.45 | *** join/#bzflag Blue_Eyes (n=Blue@host26-139-dynamic.60-82-r.retail.telecomitalia.it) |
| 00:45.51 | JeffM2501 | I'llmake it a param for 2.1 :) |
| 00:46.32 | *** join/#bzflag bz65 (n=4669c0bc@bz.bzflag.bz) |
| 00:47.14 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/include/bzfsAPI.h: make reseting the flag on a flag move optional |
| 00:47.30 | bz65 | why wont my name and password work |
| 00:47.30 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/src/bzfs/bzfsAPI.cxx: make reseting the flag on a flag move optional |
| 00:48.12 | bz65 | any one here |
| 00:48.22 | JeffM2501 | yes |
| 00:48.30 | JeffM2501 | where do they not work at? |
| 00:48.39 | bz65 | what would cause my name and password not work in here |
| 00:48.58 | JeffM2501 | in IRC? |
| 00:48.59 | bz65 | my user name is Mac! says its taken |
| 00:49.04 | JeffM2501 | what username are you trying to use? |
| 00:49.09 | JeffM2501 | then the username is taken |
| 00:49.18 | JeffM2501 | by somone else on the network |
| 00:49.28 | JeffM2501 | the IRC network is for more then bzflag players. |
| 00:49.29 | bz65 | thought it was taken by me i logged in with it |
| 00:49.39 | JeffM2501 | this is not just for bzflag |
| 00:49.41 | bz65 | ok isee |
| 00:49.50 | bz65 | thanks |
| 00:49.57 | JeffM2501 | the webpage your using is just an interface to irc.freenode.net |
| 00:50.04 | JeffM2501 | suporting a number of open source projects. |
| 00:50.09 | bz65 | i didnt know that thanks |
| 00:52.14 | *** part/#bzflag bz65 (n=4669c0bc@bz.bzflag.bz) |
| 00:52.32 | JeffM2501 | blast007, make the GM and L flags "jump" away from players that drive right to them when they don't have ID :) |
| 00:54.54 | blast007 | hehe, that was my original goal ;) |
| 00:55.05 | blast007 | never got around to that much though |
| 00:55.56 | JeffM2501 | just iterate the flag postions, and see if they go thru the "goodie" radius of more then one to get to that flag :) |
| 00:58.49 | JBdiGriz | And report it on the admin channel ;) |
| 01:29.12 | Erroneous | there are plenty of legitimate reasons to head straight for a flag :) |
| 01:36.12 | JeffM2501 | true |
| 01:36.16 | JeffM2501 | you could keep a count up tho |
| 01:36.23 | JeffM2501 | or just to be mean :) |
| 01:37.48 | blast007 | or for april 1st ;) |
| 01:38.10 | JeffM2501 | 2.1 shot types can make for a very funny april first |
| 01:38.18 | blast007 | hehe |
| 01:38.35 | blast007 | hmmm... |
| 01:39.01 | JeffM2501 | also if I do the shotID thing Erroneous and I were talking about, then the server can fire shots associated with a player :) |
| 01:39.03 | blast007 | now in 2.1, if you make the laser flag fire a GM, can they lock on? or is that still tied to having the actual GM flag? |
| 01:39.16 | JeffM2501 | I don't remember if I did GM as the flag type or shot type |
| 01:39.24 | JeffM2501 | I "think" it's shot type |
| 01:39.35 | JeffM2501 | if I didn't it should be shot type |
| 01:39.49 | JeffM2501 | I'm realy pondering making geno a shot type too |
| 01:39.54 | JeffM2501 | and giving it it's own graphic |
| 01:40.01 | JeffM2501 | just so people know "say away from that thing" |
| 01:40.12 | blast007 | put a sad face on it |
| 01:40.15 | Erroneous | mm, I like that idea |
| 01:40.15 | JeffM2501 | heh |
| 01:40.23 | JeffM2501 | genoSW is just mean |
| 01:40.35 | Erroneous | should be subtle though |
| 01:40.47 | JeffM2501 | I can make it pulse with an evil power :) |
| 01:40.53 | Erroneous | mm, pulsing :) |
| 01:40.57 | JeffM2501 | and have it be a slightly off collor |
| 01:41.05 | Erroneous | with geo shots you could have it ACTUALLY pulsate |
| 01:41.10 | Erroneous | that would be sweet |
| 01:41.14 | JeffM2501 | not to hard |
| 01:41.29 | JeffM2501 | we have the lifetime, just do a sine on it |
| 01:41.53 | JeffM2501 | give you a nice steady throb |
| 01:41.57 | JeffM2501 | heh |
| 01:42.47 | Erroneous | heh, that's scary. I could tell that you filed this bug report just from reading the title |
| 01:43.08 | JeffM2501 | what was it? |
| 01:43.12 | Erroneous | might have something to do with you being the only person I know who spells message mesage :) |
| 01:43.13 | JeffM2501 | "the shizzle don't fizzle"? |
| 01:43.23 | JeffM2501 | I type too fast |
| 01:43.48 | Erroneous | hitting the same key twice slows you down :) |
| 01:44.02 | JeffM2501 | language compression |
| 01:44.08 | Erroneous | hehe |
| 01:44.11 | Erroneous | compresion? :) |
| 01:44.12 | JeffM2501 | and you decompresed it correctly |
| 01:44.21 | JeffM2501 | yay I've installed jeffZip in your brain |
| 01:44.34 | Erroneous | heh |
| 01:45.22 | Erroneous | if you ever write ransom notes or something, be sure to spellcheck them ;) |
| 01:47.39 | *** join/#bzflag JBdiGriz (n=JBdiGriz@adsl-63-199-246-191.dsl.sndg02.pacbell.net) |
| 01:47.39 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 02:00.25 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 02:17.40 | spldart | bzfs uses c-ares? |
| 02:50.48 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-141-158-104-202.pitt.east.verizon.net) |
| 02:51.29 | *** join/#bzflag shorty114 (n=shorty11@unaffiliated/shorty114) |
| 02:54.33 | JeffM2501 | didn't the vista free beta expire? |
| 02:55.48 | blast007 | nope |
| 02:55.57 | JeffM2501 | when did it realy end? |
| 02:56.02 | blast007 | no idea |
| 02:56.09 | blast007 | have tried RC2 in a while |
| 02:57.11 | blast007 | haven't* |
| 02:57.54 | JeffM2501 | I'm doubting the version of vista that chicken "got off the internet for free" is legit |
| 03:05.56 | TD-Linux | It's like June 1, 2007 |
| 03:06.13 | TD-Linux | I tried RC2 in vmware... it was horrible... freecell ran at 0.5 fps |
| 03:10.24 | blast007 | TD-Linux: what kind of system was that on? |
| 03:10.48 | TD-Linux | 2.4GHz laptop, Pentium 4 (not HT) |
| 03:10.53 | TD-Linux | 1GB ram |
| 03:11.11 | TD-Linux | but vmware doesn't support much opengl and no directx hardware acceleration |
| 03:11.49 | blast007 | isn't it the other way around? no OpenGL and some DirectX? |
| 03:11.51 | TD-Linux | and freecell has hardware accelerated graphics, according to the warning that popped up when I tried to play it "Your system does not have accelerated 3D. Game preformance may be severely comprimised." |
| 03:12.06 | TD-Linux | I don't remember, I thought it only had OpenGL. |
| 03:12.29 | blast007 | and it only has some H/W rendering if you enable it by editing the config |
| 03:12.48 | blast007 | I was running it on my 1.6GHz Pentium M |
| 03:13.10 | blast007 | hmm, or maybe it was on my C2D |
| 03:32.19 | CIA-3 | BZFlag: 03bthansen 07v2_0branch * 10bzflag/plugins/koth/koth.cpp: Cleanup redundant code |
| 03:39.42 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-141-158-104-202.pitt.east.verizon.net) |
| 03:41.30 | a_meteorite | redundancy! |
| 03:43.40 | *** join/#bzflag bz39 (n=51d56cf5@bz.bzflag.bz) |
| 03:44.42 | CIA-3 | BZFlag: 03bthansen * 10bzflag/plugins/koth/koth.cpp: Cleanup redundant code |
| 03:47.48 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 03:47.48 | *** mode/#bzflag [+o ChanServ] by irc.freenode.net |
| 03:49.33 | *** join/#bzflag bz76 (n=44221077@bz.bzflag.bz) |
| 03:49.37 | *** join/#bzflag cosmol (n=dave@71.86.125.165) |
| 04:00.55 | *** join/#bzflag JeffM2501 (n=jeffm@pool-71-109-230-219.lsanca.dsl-w.verizon.net) |
| 04:00.55 | *** mode/#bzflag [+o JeffM2501] by ChanServ |
| 04:55.30 | *** join/#bzflag BB (n=4ba2b3fb@bz.bzflag.bz) |
| 05:37.14 | brlcad | *yawn* |
| 05:42.26 | mbfg | <PROTECTED> |
| 05:42.32 | mbfg | hmm |
| 05:43.36 | mbfg | ha! |
| 05:48.53 | SportChick | brlcad: I'm broken! |
| 05:49.23 | brlcad | SportChick: aww |
| 05:49.26 | brlcad | que pasa chica? |
| 05:49.32 | SportChick | in two places |
| 05:49.37 | brlcad | no te sientes bien? |
| 05:49.38 | SportChick | Someone crashed into me at high speed when I was teaching someone to ski. I now have a separated shoulder (at the acromioclavicular joint), and a glenoid break. I'm having a CTscan to determine if I need surgery. I won't find out until Monday. |
| 05:49.58 | brlcad | aw, ouchie |
| 05:53.09 | SportChick | yeah |
| 05:54.39 | brlcad | now how you managed to get ski's into a boat, I can only imagine |
| 05:59.30 | SportChick | heh |
| 06:23.40 | mbfg | i've always wondered how you find lakes on the side of mountains |
| 06:45.30 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 06:45.31 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 07:22.15 | *** part/#bzflag JeffM2501 (n=jeffm@pdpc/supporter/sustaining/JeffM2501) |
| 07:35.46 | *** join/#bzflag Legoguy (n=Legoguy@adsl-76-213-166-199.dsl.emhril.sbcglobal.net) |
| 08:28.53 | *** join/#bzflag lepoulpe303 (n=LePoulpe@about/essy/MobileTarget/LePoulpe303) |
| 08:41.14 | brlcad | hola Manu |
| 08:41.39 | brlcad | e ciao tupone |
| 08:42.51 | Manu | Hola brlcad :) |
| 08:43.19 | Manu | ya veo.. como siempre trasnochando :) |
| 08:44.45 | brlcad | heh, trasnochando .. ta chevere esa palabra |
| 08:45.07 | Manu | jeje, supongo que sabes lo que significa :) |
| 08:45.34 | brlcad | me imagine` .. un allnighter? |
| 08:46.22 | Manu | pasar la noche o gran parte de ella, velando o sin dormir :) |
| 08:48.43 | brlcad | mm.. velando jej |
| 08:49.01 | Manu | :) |
| 08:49.08 | Manu | sabes que ibunny esta en miami? |
| 08:49.28 | brlcad | no, no lo sabia |
| 08:49.43 | Manu | está cerca de tí, verdad¿ |
| 08:49.46 | Manu | ? |
| 08:49.46 | brlcad | sabia que venia.. pero no exactamente caundo |
| 08:49.50 | brlcad | er, quando |
| 08:49.55 | brlcad | hah, cerca.. no |
| 08:49.55 | Manu | tiene su padre enfermo |
| 08:50.04 | brlcad | aww |
| 08:50.18 | Manu | voló de ecuador a miami |
| 08:52.25 | Manu | Donde estás tú brlcad Delaware? |
| 08:52.46 | Manu | si se puede saber.. :p |
| 08:53.04 | brlcad | es la distancia como de madrid hasta italia |
| 08:53.26 | Manu | dos horas de avion? ;) |
| 08:53.47 | Manu | depende del avion claro.. jeje |
| 08:53.48 | brlcad | jej, con seguridad, nunca ;) |
| 08:53.58 | brlcad | s/con/pasando/ |
| 08:53.59 | Manu | jeje |
| 08:54.13 | Manu | tengo que salir a visitar a un cliente.. nos vemos más tarde :) |
| 08:54.25 | brlcad | estoy cerca a delaware.. y baltimore en maryland |
| 08:54.33 | brlcad | hasta luego |
| 08:54.38 | Manu | si.. lo digo por la ubicación del servidor :) |
| 08:55.26 | brlcad | mm si, .bz esta en miami .. :) |
| 09:28.39 | *** join/#bzflag zee387 (i=47c5e082@gateway/web/cgi-irc/zeebrothers.net/x-54b0cf4f04e6dcc3) |
| 10:28.53 | *** join/#bzflag den_bagus (n=db533f33@bz.bzflag.bz) |
| 10:33.27 | *** join/#bzflag CBG` (n=CBG@about/essy/fan/CBG) |
| 11:16.12 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 13:17.48 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-141-158-104-202.pitt.east.verizon.net) |
| 13:29.05 | *** join/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 14:28.12 | *** join/#bzflag |zongo| (n=zongo@ext-32-52.mobile.unibas.ch) |
| 15:26.16 | *** part/#bzflag A-Delusion (n=A-Delusi@pool-141-158-104-202.pitt.east.verizon.net) |
| 16:08.38 | *** part/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 16:29.45 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 16:33.57 | *** join/#bzflag WarPig (n=c269a04d@bz.bzflag.bz) |
| 17:19.13 | *** join/#bzflag Erroneous (n=dtremena@67-131-219-2.dia.static.qwest.net) |
| 17:36.45 | *** join/#bzflag JeffM2501 (n=JeffM@pdpc/supporter/sustaining/JeffM2501) |
| 17:36.45 | *** mode/#bzflag [+o JeffM2501] by ChanServ |
| 17:43.07 | *** join/#bzflag BenUrban (n=benurban@unaffiliated/benurban) |
| 17:44.36 | *** join/#bzflag JBdiGriz (n=jbdigriz@206-15-67-5.static.twtelecom.net) |
| 17:44.36 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 17:52.23 | *** join/#bzflag bz88 (n=57508a74@bz.bzflag.bz) |
| 17:52.33 | bz88 | yo |
| 17:53.31 | *** join/#bzflag Gork (n=4cb3dd7b@bz.bzflag.bz) |
| 17:53.50 | Gork | hi |
| 17:54.11 | *** join/#bzflag bz88 (n=57508a74@bz.bzflag.bz) |
| 17:54.17 | *** join/#bzflag Gork (n=4cb3dd7b@bz.bzflag.bz) |
| 17:54.23 | Gork | what the? |
| 17:54.51 | Gork | anybody on? |
| 17:55.10 | Gork | shit! |
| 17:56.52 | brlcad | tsk tsk |
| 17:56.56 | JeffM2501 | oooookkkkeeeeyyydoookkkeeee |
| 17:57.19 | brlcad | tee hee, you said doookeeee |
| 17:57.41 | JeffM2501 | "tee hee" you a little girl now? ;) |
| 17:57.50 | brlcad | don't I wish |
| 17:58.46 | JeffM2501 | heh |
| 18:00.53 | *** join/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 18:12.38 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 18:12.38 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 18:31.42 | *** join/#bzflag brad (n=brad@brad.bzexcess.com) |
| 18:52.57 | *** join/#bzflag LePoulpe304 (n=olivier@AMontpellier-251-1-43-87.w81-251.abo.wanadoo.fr) |
| 19:00.00 | *** join/#bzflag Blue_Eyes (n=Blue@87.2.225.132) |
| 19:24.40 | *** part/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 19:37.24 | CIA-3 | BZFlag: 03jeffm2501 07v2_0branch * 10bzflag/src/bzfs/bzfs.cxx: API event for shot ends |
| 19:37.24 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/src/bzfs/bzfsClientMessages.cxx: API event for shot ends |
| 19:37.24 | CIA-3 | BZFlag: 03jeffm2501 07v2_0branch * 10bzflag/include/bzfsAPI.h: API event for shot ends |
| 19:37.25 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/include/bzfsAPI.h: API event for shot ends |
| 19:38.37 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@client-86-31-126-250.hers.adsl.virgin.net) |
| 19:45.43 | SpazzyMcGee | Anybody have any idea what's causing this lighting bug? http://img465.imageshack.us/img465/5844/wierdlightingxs9.jpg |
| 19:45.56 | SpazzyMcGee | I'm trying to fix the mesh to look nicer. |
| 19:48.57 | *** join/#bzflag Flash (n=jwmelto@unaffiliated/flash) |
| 20:00.51 | Flash | at the risk of stepping in the middle of a pile of poo, who is mikeeusa and why did he start the bztournament project? |
| 20:03.32 | SportChick | ohhh that guy |
| 20:07.04 | *** join/#bzflag CBG` (n=CBG@about/essy/fan/CBG) |
| 20:12.57 | Flash | I notice it is very quiet here, so I don't know who is listening, but... |
| 20:13.13 | Flash | what do the devs think about a systemic migration from char* to std::string? |
| 20:14.55 | brlcad | not a bad thing, but also not a "great" thing .. conversion where there are malloc issues are probably worthwhile, an outright elimination is rather fruitless |
| 20:17.52 | brlcad | there are places in the code where performance matters, and willy nilly converting char*'s over to std::string without evaluating that impact would be asinine (and just determining that it seems to run at the same fps on one's own machine wouldn't be sufficient, have to find a slow machine that is cpu-bound) |
| 20:17.57 | Tupone | I disagree on using std::string except where CPU time is not an issue. Otherwise we should check deeply the behaviour on each place is used |
| 20:18.14 | brlcad | there are probably more useful things to work on even code-cleanup-wise |
| 20:18.23 | brlcad | ~tupone++ |
| 20:18.34 | Tupone | ~brlcad++ |
| 20:19.07 | brlcad | tupone, didn't do the migration yet because I noticed in a log that you objected? |
| 20:19.46 | Tupone | yeah, I objected because someone (TM) has said that delivery is the end of January |
| 20:19.59 | Tupone | :) |
| 20:20.03 | brlcad | ah, heh |
| 20:20.20 | brlcad | if that someone was me, I gave up on that goal about mid-december :) |
| 20:20.43 | *** join/#bzflag Birdie (n=Birdie@brad.bzexcess.com) |
| 20:20.55 | brlcad | we're not even a month close at this point imho, lots of major untested changes |
| 20:21.19 | brlcad | so now actually seems like a good time as any |
| 20:21.33 | Tupone | well, I even don't see any advantage on using SVN given the current habit . I see only cons, as people should learn new things. In my case I only use CVS now |
| 20:22.22 | Tupone | I could learn it, but why? Do you think some will do atomic commit, except you? |
| 20:22.52 | Tupone | and maybe DTR |
| 20:23.39 | Tupone | what are the pro, actually? |
| 20:23.42 | brlcad | the biggest advantage from my view is that it also does revision control on directories, which CVS doesn't at all |
| 20:24.01 | brlcad | and file changes, renames are recognized, etc |
| 20:24.18 | brlcad | instead of the CVS delete+readd method |
| 20:24.23 | brlcad | which is merely convention |
| 20:25.13 | brlcad | cvs is well known, and tools are more prevalent than svn, but that mainly impacts mac and windows users for the most part |
| 20:25.59 | Tupone | well, if you think those advantages will affect positively the development, I trust you, and my objection > /dev/null |
| 20:26.00 | brlcad | the command line interface is pretty much identical for the things you do in svn that you used to do in cvs, e.g. you still "svn update" and "svn commit", etc.. all the commands that make sense are still the same |
| 20:26.43 | brlcad | i was planning on writing up a little "summary" of use to help make things easier -- showing how an operation in cvs related to svn (including things like branching) |
| 20:27.24 | Tupone | I have not seen 1 bug for CVS, so I trust it more. But I know something cannot be done, like selecting a date in a branch, for instance |
| 20:28.49 | brlcad | you have to be really careful about how files and directories are named in cvs (which is arguably a very good thing, but to the point of being painful on mistakes) .. in svn, since the names are managed just like everything else, you can rename as easily as you can change a comment in a source file with relative ease -- that is probably the #1 benefit, the rest is mostly gravy |
| 20:30.17 | brlcad | another benefit might be that svn can actually track changes to binary files better than cvs .. it doesn't just necessarily keep whole-file diffs |
| 20:30.47 | Tupone | if planned delivery is mid-year , everything will run smooth and all people involved can adapt to it |
| 20:31.20 | Tupone | any time before, and I foresee problems |
| 20:31.25 | brlcad | i'm not sure it'll stop me from doing frequent commits, but I might be encouraged more towards coherent changesets ;) |
| 20:31.53 | Tupone | likes |
| 20:32.50 | brlcad | since the changes apply to the changeset instead of per-file ala cvs, it makes sense to apply a bulk commit comment statement genericly where in CVS it didn't because of the lack of correlation between files |
| 20:34.20 | Tupone | have you tracked SVN bugs ? |
| 20:34.56 | brlcad | yeah, i've been tracking their releases for actually a couple years now, reading their changelogs |
| 20:35.54 | Tupone | comments? |
| 20:37.06 | brlcad | nothing really alarming, they really seemed to stabilize over a year ago |
| 20:37.43 | brlcad | a few issues in a couple of the administrative commands came up this year (things I wouldn't even think of doing, regardless of cvs or svn) |
| 20:37.57 | brlcad | but nothing from the way we use cvs now in the least |
| 20:38.14 | Tupone | ok. then you have my approval, if that count |
| 20:38.45 | brlcad | i've been using it in a couple other (minor) projects just to be more comfortable with it as well, and so far everything's been faultless |
| 20:39.18 | brlcad | (on sourceforge, that is -- have used it elsewhere for much longer) |
| 20:40.23 | brlcad | now just a question of whether I can get the time this weekend or wait until wed of this coming week ;) |
| 20:50.01 | JeffM2501 | I think the only need for svn right now is a file name change we wanted to do. |
| 20:50.11 | JeffM2501 | and tha'ts not a big need |
| 21:01.58 | Flash | I don't want this to be taken the wrong way, but I'll take a chance |
| 21:02.33 | Flash | on a couple of occasions I've suggested changes in coding standards to conform more with C++ best practices |
| 21:02.51 | Flash | one response is usually : there are portions of the code that are performance critical |
| 21:03.00 | Flash | another is : there are better things to spend time on |
| 21:03.22 | Flash | to the first point: the performance critical sections should be well defined (and commented?) |
| 21:03.40 | Flash | to the second: first the style must be agreed to, then manpower can be managed |
| 21:03.47 | *** join/#bzflag CBG (n=CBG@cpc4-stme1-0-0-cust103.cdif.cable.ntl.com) |
| 21:04.03 | Flash | certainly, with volunteers, there is the potential for labor for easy (if not critical) changes |
| 21:04.20 | Flash | er.. backlash |
| 21:12.06 | brlcad | Flash: "should be" but aren't necessarily, and the code is a rather moving target so it's usually a matter of taking the due diligence at the time of need to verify the impact (or lack thereof) |
| 21:12.52 | Flash | I didn't expect the commented part, but aren't the performance critical parts known? |
| 21:12.53 | brlcad | and "best practices" are very much disputable, not that I'm disputing this one or agreeing, but that's an empty statement -- there are plenty that would argue vehemently that std::strings are the devil |
| 21:13.25 | *** join/#bzflag zee296 (i=3e4de48a@gateway/web/cgi-irc/zeebrothers.net/x-ea4e5362d49d5594) |
| 21:13.34 | JeffM2501 | std::string and DLL interfaces are the devil |
| 21:13.36 | brlcad | they're mostly well known, the code is profiled from time to time |
| 21:13.46 | Flash | would the argue vehemently with valid reasons or religious fervor? |
| 21:13.57 | brlcad | but then the code constantly changes too -- the only real way to be sure is to profile, not guess |
| 21:14.21 | brlcad | Flash: both, most points have validity under various assumptions and value systems |
| 21:15.06 | brlcad | the point was to make the change under a banner of "best practice" is a false pretence at best -- there are technical reasons for and against it that can be quantified |
| 21:15.15 | Flash | as to the code changing.... certainly that's true, but the execution paths through the system should be fairly consistent |
| 21:15.25 | brlcad | not really |
| 21:15.38 | JeffM2501 | have you looked at the code much Flash ? |
| 21:15.41 | brlcad | depends which sections |
| 21:15.47 | Flash | some, not all of it |
| 21:15.55 | brlcad | plugins totally changed the flow |
| 21:15.59 | Flash | graphics scares me ;-) |
| 21:16.04 | brlcad | stuff moving to the server entirely changes processing |
| 21:16.17 | JeffM2501 | personaly I think you'd want to know how the software works before you comment on changes, just for change's sake |
| 21:16.22 | Flash | true, 2.1 will greatly change the (known) flow |
| 21:16.31 | brlcad | mods like language filtering and mesh support made a pretty major impact on the logic flow |
| 21:16.34 | JeffM2501 | Erroneous and I had a nice talk of what all we can move server side last night :) |
| 21:16.57 | JeffM2501 | it even involved a whiteboard |
| 21:17.01 | brlcad | heh |
| 21:17.22 | JeffM2501 | comeon down, you can be a post developer |
| 21:17.29 | Flash | JeffM2501: obviously, there is truth in that, but I have a healthy experience in software development that I *think* should be generally applicable to any project |
| 21:17.48 | brlcad | that's called unfounded religion ;) |
| 21:18.00 | brlcad | apply the practices where they provide a tangible benefit |
| 21:18.15 | brlcad | sometimes/often they do, not always |
| 21:18.16 | JeffM2501 | Flash, your statement tells me you have not done many "real world" projects :) |
| 21:18.27 | Flash | you are totally mistaken |
| 21:19.04 | JeffM2501 | ok |
| 21:19.06 | JeffM2501 | I may be |
| 21:19.08 | Flash | ;-) |
| 21:19.09 | JeffM2501 | and I'm ok with that :0 |
| 21:19.27 | JeffM2501 | personaly I'd just like to rewrite bz from the ground up |
| 21:19.34 | JeffM2501 | not just for a language cleanup |
| 21:19.42 | JeffM2501 | but for an overall logic cleanup |
| 21:19.54 | Flash | I'll help ;-) |
| 21:20.00 | JeffM2501 | there are many concepts and paradigms we could use that have come out since it was made |
| 21:20.05 | JeffM2501 | I'm sure you would |
| 21:20.13 | JeffM2501 | but we'd all have to agree on a desgin |
| 21:20.18 | JeffM2501 | and that's proven dificult |
| 21:20.26 | Flash | I see that .... |
| 21:20.36 | JeffM2501 | given the current "do what you want" work ethic we have |
| 21:20.53 | JeffM2501 | this project is not currently set up on a social level for large colaborative events |
| 21:20.58 | JeffM2501 | trust me I've tried |
| 21:21.07 | brlcad | he has :) |
| 21:21.11 | Erroneous | he has :) |
| 21:21.37 | JeffM2501 | but you'd have to have functional reasons to do the rewrite, not just language reasons |
| 21:21.53 | JeffM2501 | like "it will now do server side state, and support thse features we do not now" |
| 21:21.56 | JeffM2501 | then there is reason |
| 21:22.13 | JeffM2501 | if you just say for the "best use of the language" thent hat is open to so many interpertations. |
| 21:22.23 | JeffM2501 | it's like focusing on grammar when your fighting a war. |
| 21:22.33 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 21:22.42 | brlcad | or even "there was a bug somewhere in here.. couldn't find it so i rewrote the file to use std::strings and the problem seems to have gone away." ;) |
| 21:22.45 | Erroneous | consider bzflag to be a mixed C/C++ project. use each when it is appropriate. |
| 21:22.46 | Flash | but they don't have to be mutually exclusive |
| 21:22.58 | JeffM2501 | no they don't |
| 21:23.09 | JeffM2501 | if we did a functonal rewrite, I'd hope we'd clean up language use at the same time |
| 21:23.11 | Gnurdux | most GOOD C code is also valid C++ |
| 21:23.16 | JeffM2501 | that is totaly feasable |
| 21:23.21 | Flash | Gnurdux: but not vice versa |
| 21:23.32 | JeffM2501 | but I think you have to start with functinal rasons before language. |
| 21:23.34 | *** join/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 21:23.48 | Flash | but you have to agree on the language conventions first |
| 21:23.50 | Gnurdux | Flash, of course, otherwise thered be no point in C++ |
| 21:23.57 | JeffM2501 | you have to agree on it all first |
| 21:24.02 | JeffM2501 | the functonal goal |
| 21:24.05 | JeffM2501 | and the coding standards |
| 21:24.11 | JeffM2501 | and the timeline |
| 21:24.14 | JeffM2501 | etc.. |
| 21:24.20 | Erroneous | Flash: only if you want to have conventions |
| 21:24.21 | JeffM2501 | it's all one part of the design doc |
| 21:24.32 | JeffM2501 | not having conventions is just as valid, but more ugly IMHO |
| 21:24.36 | JeffM2501 | but it is a O |
| 21:24.37 | brlcad | some parts of BZ are just fine, most of the "mess" is either in code that's somewhere in the C->C++ transition or it's something exceptionally popular and keeps changing faster than it has been cleaned up (like adding new commands) |
| 21:24.52 | Erroneous | currently our "conventions" are: does it build correctly on the various systems we support? |
| 21:25.05 | brlcad | and "try not to make things worse" |
| 21:25.18 | Erroneous | worse is relative, though :) |
| 21:25.20 | JeffM2501 | "don't break windows clients" |
| 21:25.24 | Flash | of course, "worse" is just as subjective as "better" |
| 21:25.31 | JeffM2501 | for some things |
| 21:25.36 | brlcad | yep |
| 21:25.37 | JeffM2501 | if the FPS of the client goes down |
| 21:25.40 | JeffM2501 | for the same case |
| 21:25.43 | JeffM2501 | then that is worse |
| 21:25.50 | JeffM2501 | for others, it's arguble |
| 21:26.02 | Erroneous | there are valid reasons to allow an fps drop though |
| 21:26.07 | JeffM2501 | yes |
| 21:26.29 | JeffM2501 | just as there are reasons to not allow it :) |
| 21:26.53 | brlcad | if you alienate or piss off contributing devs, that's generally worse -- if your idea of clean code doesn't match the majority of contributing devs idea it's generally worse -- if you make the code more inconsistent (even through an effort to clean it up), it's generally worse |
| 21:27.09 | Flash | #1 is key ;-) |
| 21:27.18 | JeffM2501 | I think the reason you get such resitance Flash is the fact that your talking about changes with no real benifical features, other then "looking better" |
| 21:27.24 | brlcad | then there are exceptions to just about every "worse case" too |
| 21:27.38 | Flash | JeffM2501: I don't think so |
| 21:27.39 | JeffM2501 | if you tie it into other stuff you'll get better acceptance |
| 21:27.57 | Flash | using pointers is generally evil, because of the resource management implications |
| 21:28.01 | JeffM2501 | why? |
| 21:28.04 | Erroneous | pointers are NOT evil |
| 21:28.06 | Erroneous | get over that |
| 21:28.12 | JeffM2501 | you make statments like that, when it's a valid way to program |
| 21:28.16 | JeffM2501 | you just don't like it |
| 21:28.29 | JeffM2501 | memory management is part of using pointers, sure, but it's still totaly valid |
| 21:28.37 | JeffM2501 | and in some cases a lot faster |
| 21:28.38 | brlcad | they're only even problematic when you don't know how to use them, or otherwise use them under false assertions |
| 21:28.43 | Flash | "valid" simply means it "works" |
| 21:28.49 | JeffM2501 | no |
| 21:28.54 | Gnurdux | and it works well |
| 21:28.56 | JeffM2501 | valid means, acceptable for the task |
| 21:29.01 | JeffM2501 | pointers do very known things |
| 21:29.21 | Gnurdux | any alternative is just a wrapper around em anyways |
| 21:29.34 | JeffM2501 | this is why you get reistance, you make these semingly religous statements. |
| 21:29.49 | Flash | Gnurdux: yes, and the "wrapper" provides management and context that reduces the overall complexity of the code |
| 21:30.00 | Erroneous | no, it reduces the VISIBLE complexity |
| 21:30.01 | Gnurdux | and possibly the efficiency as well |
| 21:30.06 | Erroneous | substituing INVISIBLE complexity |
| 21:30.08 | Gnurdux | the compiler does the same stuff |
| 21:30.09 | Flash | JeffM2501: I'm sorry, I don't see them as religious, but I get shot down before I can offer any reasons |
| 21:30.37 | Gnurdux | but the compiler doesnt know when its needed to keep track and when not, and does needless things |
| 21:30.45 | brlcad | Gnurdux: the compiler doesn't do the same "stuff" in this case |
| 21:31.08 | brlcad | pointers are actually a bit simpler than what goes on under the hood when you use std::strings |
| 21:31.19 | Gnurdux | i like std::strings |
| 21:31.26 | JeffM2501 | they are good for a number of things |
| 21:31.31 | JeffM2501 | they are slow as hell for parsers |
| 21:31.35 | JeffM2501 | as I've found |
| 21:31.42 | JeffM2501 | modeltool is slower then heck cus of them |
| 21:31.56 | brlcad | they're great for some purposes, but they also don't make char *'s deprecateable .. they're not a magic hammer for all use of strings |
| 21:32.00 | JeffM2501 | but modeltool has some prety code cus of them |
| 21:32.05 | Erroneous | there are fast ways to use std::strings |
| 21:32.16 | JeffM2501 | tokenize isn't fast with em :) |
| 21:32.21 | JeffM2501 | that's what kills modeltool |
| 21:32.30 | Flash | how many tokens per parse? |
| 21:32.35 | JeffM2501 | usualy 1 |
| 21:32.46 | Flash | odd |
| 21:32.53 | JeffM2501 | read the file into a string, tok it by newline |
| 21:32.55 | brlcad | and often when you add all of that fast stuff, you end up making the code considerably more complicated than it was .. and mostly only get back to the performance you would have otherwise had with char pointers ;) |
| 21:32.58 | JeffM2501 | then tok each line by space, or whatever |
| 21:33.13 | JeffM2501 | the overhead and methods used in there are just slow |
| 21:33.25 | JeffM2501 | I redid the parser with my own string stuff, way faster |
| 21:33.33 | JeffM2501 | but I like how the code looks with the strings, so I kept it |
| 21:33.38 | JeffM2501 | cus who cares if modeltool is fast |
| 21:33.43 | Gnurdux | lol |
| 21:33.44 | brlcad | the stl is notoriously slow for performance use |
| 21:33.52 | JeffM2501 | indeed |
| 21:34.02 | JeffM2501 | hence why we have bzdb cache |
| 21:34.03 | brlcad | it just "usually" doesn't matter given where time is spent |
| 21:34.10 | brlcad | but often does |
| 21:34.33 | JeffM2501 | bzdb cache was a perfect case where std::string compares were our downfall |
| 21:34.49 | Flash | sorry to stir this up and leave, but I have to go get a kid |
| 21:34.53 | JeffM2501 | and we optimised that out into what I think is a nice system |
| 21:35.03 | JeffM2501 | you have been heard |
| 21:35.08 | Gnurdux | but it uses strings internally |
| 21:35.14 | JeffM2501 | that dosn't mean we'll agree with you |
| 21:35.16 | Gnurdux | it seems sort of ugly |
| 21:35.27 | JeffM2501 | Gnurdux only for the low use lookups |
| 21:35.37 | Gnurdux | oh ok |
| 21:35.38 | JeffM2501 | the high use ones use a callback that sets a real variable when it changes |
| 21:35.40 | JeffM2501 | it's quite nice |
| 21:35.45 | Gnurdux | but what about the /set _tankSpeed :) crash |
| 21:36.00 | Gnurdux | kills server and all clients |
| 21:36.21 | JeffM2501 | that's just bad code |
| 21:36.32 | JeffM2501 | that's not a fault of the stl |
| 21:36.40 | JeffM2501 | that's just a case where 0 is bad |
| 21:36.41 | Gnurdux | im saying its a fault of bzbb |
| 21:36.49 | JeffM2501 | and i'm saying your wrong |
| 21:36.50 | Gnurdux | setting it to 0 doesnt kill it |
| 21:37.02 | JeffM2501 | it's the fault of the seter |
| 21:37.04 | JeffM2501 | gotta go |
| 21:38.05 | brlcad | bzdb has no validation on correct inputs (and it's documented as such somewhere), so it is entirely up to the setter to provide valid values |
| 21:41.33 | *** join/#bzflag L4m3r (n=l4m3r@169.232.122.91) |
| 21:42.17 | *** join/#bzflag TD-Linux (n=TD-Linux@24-159-197-22.dhcp.roch.mn.charter.com) |
| 22:00.20 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 22:03.56 | JeffM2501 | and it's the bug of the setter that sets it' to an invalid number :0 |
| 22:03.57 | JeffM2501 | :) |
| 22:04.05 | JeffM2501 | bzdb just passes values around. |
| 22:04.43 | JeffM2501 | tho didn't i put validation in for speed and all that stuff? |
| 22:07.46 | L4m3r | the only bug I know of is the parentheses parsing one |
| 22:07.56 | L4m3r | <PROTECTED> |
| 22:08.11 | *** part/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 22:12.46 | brlcad | heh |
| 22:24.03 | JeffM2501 | wonder what gets passed to my validator |
| 22:24.23 | Erroneous | null ;) |
| 22:24.33 | JeffM2501 | as a string? |
| 22:24.41 | Erroneous | sure :) |
| 22:24.47 | Erroneous | .length = 0 |
| 22:24.49 | Gnurdux | L4m3r, exactly |
| 22:24.54 | Gnurdux | the same exact one i mentioned |
| 22:25.02 | Gnurdux | i actually discovered that particular one |
| 22:25.20 | Erroneous | discovered it, but didn't report it or fix it? :) |
| 22:25.21 | Gnurdux | L4m3r, you can do it with other variables, but that only crashes clients, not server |
| 22:25.23 | JeffM2501 | got a fix for it? |
| 22:25.28 | Gnurdux | no |
| 22:25.43 | Gnurdux | it might not exist in 2.1 i dunno |
| 22:29.30 | *** join/#bzflag spldart (n=troublem@cpe-24-28-107-184.houston.res.rr.com) |
| 22:31.09 | JeffM2501 | now I have to remember where i put that verify thingy :) |
| 22:33.34 | JeffM2501 | tho it's prety easy to make eval return 0 if val is no length. |
| 22:34.53 | JeffM2501 | or NaN to be consistent |
| 22:37.17 | CIA-3 | BZFlag: 03jeffm2501 07v2_0branch * 10bzflag/src/common/StateDatabase.cxx: return NaN from eval if the value stored in an item has no lenght. |
| 22:37.25 | JeffM2501 | try that out |
| 22:40.23 | CIA-3 | BZFlag: 03jeffm2501 * 10bzflag/src/common/StateDatabase.cxx: return NaN from eval if the value stored in an item has no lenght. |
| 22:47.19 | spldart | bug fix? |
| 22:50.11 | JeffM2501 | yeah |
| 22:50.13 | JeffM2501 | maybe |
| 22:50.14 | JeffM2501 | ish |
| 22:50.15 | JeffM2501 | kinda |
| 22:50.17 | JeffM2501 | sorta |
| 22:50.37 | spldart | umm |
| 22:50.38 | spldart | ok |
| 22:55.14 | *** join/#bzflag SpazzyMcGee- (n=SpazzyMc@client-86-31-126-250.hers.adsl.virgin.net) |
| 22:57.15 | SpazzyMcGee- | I can't work out what's causing this weird lighting: http://img465.imageshack.us/img465/5844/wierdlightingxs9.jpg |
| 22:57.18 | SpazzyMcGee- | any ideas? |
| 23:00.39 | Erroneous | shadows from the thing floating in the sky? |
| 23:00.57 | SpazzyMcGee- | no, it's actual lighting on the mesh, it happens without shadows on, and if i remove all the objects other than the central cake |
| 23:02.20 | TD-Linux | It's becuase it's smooth-shaded |
| 23:02.38 | TD-Linux | set it all, or at least the roof faces, to flat-shading |
| 23:03.02 | TD-Linux | I don't remember the keyword, I think it's either 'flat' or 'flatshading' |
| 23:03.18 | SpazzyMcGee- | is the parameter just 'flatshading' added to the material? |
| 23:03.22 | TD-Linux | yeah. |
| 23:03.25 | TD-Linux | Or to the object. |
| 23:03.28 | SpazzyMcGee- | cheers |
| 23:03.28 | TD-Linux | I can look it up. |
| 23:03.36 | SpazzyMcGee- | i will |
| 23:04.47 | TD-Linux | 'flatshading', in the object |
| 23:04.54 | TD-Linux | it only appears for arcs... are you using arcs? |
| 23:05.00 | SpazzyMcGee- | yeah, i saw |
| 23:05.04 | TD-Linux | I think it works with meshes too, but I'm not sure. |
| 23:05.08 | SpazzyMcGee- | no, i'm using a mesh |
| 23:05.52 | SpazzyMcGee- | it appears in all the mesh objects |
| 23:06.00 | SpazzyMcGee- | arc, cone, sphere etc. |
| 23:06.11 | TD-Linux | okay then flatshading in the faces... or maybe the whole object |
| 23:06.26 | SpazzyMcGee- | yeah |
| 23:09.47 | SpazzyMcGee- | nope |
| 23:10.16 | SpazzyMcGee- | i tried addin it in all the faces, in the main mesh object, and in the mats. |
| 23:10.44 | SpazzyMcGee- | *tried adding |
| 23:14.36 | TD-Linux | hmm... and it is still smoothshading... |
| 23:14.57 | spldart | Ping Jeff |
| 23:15.40 | *** join/#bzflag A_Heart_Attack (n=bzhearta@ool-44c75115.dyn.optonline.net) |
| 23:15.52 | spldart | Just a note... I found the problem for all my linux machines in compiling 2.1.11 whereas 2.1.10 built fine..... c-ares |
| 23:16.29 | A_Heart_Attack | spldart: what distro? |
| 23:16.47 | spldart | All debian stable... 3.1 |
| 23:16.53 | TD-Linux | I could try compiling |
| 23:17.19 | spldart | So I built latest c-ares and boom... I could then build 2.1.11 fine |
| 23:17.56 | spldart | c-ares1.3.2 |
| 23:20.02 | spldart | btw it was bzfs and bzadmin I was trying to build |
| 23:21.34 | JeffM2501 | yeah anything that uses libcurl can use cares |
| 23:22.38 | SpazzyMcGee | Jeff, do you have any idea what causes this strange lighting, or what i can do to fix it? |
| 23:22.41 | spldart | but was a change made intentionally or was it a glitch |
| 23:25.37 | spldart | 2.1.10 built fine --disable-client and 2.1.11 tossed a warning in config of |
| 23:25.44 | spldart | 'no c-ares |
| 23:26.02 | spldart | it was just unexpected |
| 23:26.14 | blast007 | spldart: the warning in ./configure about ares is normal |
| 23:26.27 | blast007 | it just uses the bundled cares then |
| 23:26.37 | blast007 | c-ares* |
| 23:27.17 | spldart | so was the bundled c-ares to old for the transition to ver .11 then? |
| 23:27.25 | spldart | I didn't know the requirment had changed |
| 23:27.39 | spldart | not that there is anything wrong with it :) |
| 23:30.46 | blast007 | no idea |
| 23:30.55 | blast007 | it builds fine in Windows ;) |
| 23:34.49 | JeffM2501 | get vc8 ee |
| 23:34.58 | spldart | does it cost? |
| 23:35.05 | blast007 | it's free |
| 23:35.12 | blast007 | Express Edition |
| 23:35.14 | spldart | And it will build? |
| 23:35.26 | blast007 | supposedly |
| 23:35.27 | spldart | does it require some rigging? |
| 23:35.28 | blast007 | ;) |
| 23:35.41 | blast007 | I use the full Visual Studio versions |
| 23:38.59 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 23:42.20 | spldart | which one do I grab? http://msdn.microsoft.com/vstudio/express/ |
| 23:48.19 | Erroneous | umm...visual c++? :) |
| 23:48.20 | *** join/#bzflag Theme97 (n=437a882f@206.222.19.114) |
| 23:48.51 | *** part/#bzflag Theme97 (n=437a882f@206.222.19.114) |
| 23:49.16 | spldart | Just making sure.... already downloaded hehe |
| 23:50.53 | JeffM2501 | and directX and the platform SDK |
| 23:51.11 | spldart | google those? |
| 23:53.32 | spldart | ah... sdk from ms |
| 23:53.37 | JeffM2501 | yah |
| 23:53.45 | spldart | now directx |
| 23:54.03 | *** join/#bzflag me1 (n=me1@pool-71-174-247-149.bstnma.fios.verizon.net) |
| 23:56.08 | spldart | LOL.... sdk setup.exe after validation is broken link on microsquash LOL |
| 23:57.05 | *** join/#bzflag Legoguy (n=Legoguy@adsl-76-213-166-199.dsl.emhril.sbcglobal.net) |
| 23:57.34 | *** join/#bzflag me1 (n=me1@pool-71-174-247-149.bstnma.fios.verizon.net) |
| 23:57.59 | me1 | Jeff, you alive? |
| 23:58.17 | Erroneous | nope, he's not |
| 23:58.21 | me1 | ok |
| 23:58.48 | *** part/#bzflag me1 (n=me1@pool-71-174-247-149.bstnma.fios.verizon.net) |
| 23:58.56 | Erroneous | wow |
| 23:59.18 | brlcad | you killed jeffy! |
| 23:59.19 | spldart | heh |
| 23:59.26 | Erroneous | hehe |
