| 00:41.55 | *** join/#bzflag Marzipan (~Marzipan@sign-4d091a88.pool.mediaWays.net) |
| 01:04.30 | Constitution | bizarrefish: okay, I didn't realize it only did it in CTF mode. We probably want to keep that behavior strictly to CTF mode in that case. |
| 01:35.22 | bizarrefish | Constitution: Cool. Would that likely be a client modification? (auto respawning without asking) |
| 01:35.48 | JeffM | if it has to be a client mod it would need to wait for the next breaking release |
| 01:35.57 | JeffM | otherwise you can't ensure all players have that behavor |
| 01:37.07 | bizarrefish | Indeed. He either was talking about the ability to respawn without asking, or forcing all players to respawn on the base, which I thought happened anyway in CTF. It's 1 in the morn - My disambiguation isn't all that grand :-) |
| 01:37.30 | JeffM | if it's not CTF there arn't any bases ether |
| 01:37.50 | JeffM | and we can respawn them with out asking, it's called "killing them" :) |
| 01:37.53 | JeffM | boom |
| 01:38.12 | bizarrefish | But they have to then hit 'i'. I was under the impression that's what he was suggesting to get rid of |
| 01:38.23 | bizarrefish | actually.....after further thought, I believe he meant the second thing |
| 01:38.26 | JeffM | oh I don't think that's what he was talking about |
| 01:38.32 | bizarrefish | After a countdown, the player doesn't get put back on the base. |
| 01:38.35 | JeffM | that's a much larger change and I don't think that's a good idea |
| 01:38.38 | bizarrefish | understands now :) |
| 01:38.55 | JeffM | we should just flag the next spawn as being on the base |
| 01:38.57 | bizarrefish | Yeah, sounded a bit wrong |
| 01:39.15 | JeffM | then when the game blows them up, they will spawn at base |
| 01:39.57 | bizarrefish | Sounds like a plan. I'll take a look at that in the next couple of days. |
| 01:43.43 | bizarrefish | It's funny, I found something really quite intimidating about contributing to a project. Haven't done it before. Bzflag is a pretty good starting point. The code's good enough that you're probably not going to break something massive by doing something seemingly trivial, but bad enough to be...fun :D |
| 01:44.19 | JeffM | I don't think the code is that great personaly, but it's good you feel that way |
| 01:44.33 | JeffM | just start with small changes and it makes it easer |
| 01:45.08 | bizarrefish | It's far nicer than the VB6/C# mess where I work :). It's amazing how smart people can write appalling code. |
| 01:45.29 | JeffM | well the VB6 limits what you can do |
| 01:45.38 | JeffM | you can write some very nice code in C# |
| 01:46.43 | bizarrefish | The limits force you to do Stupid Shit(TM). And yes, I agree, C# is promising. I can't see microsoft supporting it with any great enthusiasm in 5 years though. At least, not C#/.NET . Not since WinRT and all that confusion. |
| 01:47.20 | JeffM | not all apps will work with metro so they will keep .net going |
| 01:47.25 | JeffM | a LOT of people are based on it now |
| 01:47.30 | bizarrefish | The guys need to back up and make .NET better, imho. Not just shift their focus from buzzword to buzzword |
| 01:47.52 | JeffM | the winRT and .net teams are not the same group |
| 01:49.12 | bizarrefish | I hope they will indeed keep .NET going. There's that itch in the back of my mind, though... The way they just threw all the poor VB6 devs to the lions with no migration tools whatsoever. |
| 01:49.37 | JeffM | VB was so poorly writen that there wasn't much to do |
| 01:49.57 | JeffM | and the .net stuff is better defined, using standards and stuff |
| 01:50.32 | JeffM | from what I understand moving from VB6 to VB.net is dooable it's just not automatic |
| 01:51.10 | JeffM | has to do that for one of our components at work since we told him no VB6 runtimes anymore |
| 01:51.15 | bizarrefish | VB is atrocious in some respects. One of my first tasks in my latest job was to set up a build server(dev team was growing from just 3-4 people) |
| 01:51.32 | bizarrefish | Absolute nightmare getting VB6.exe to behave with respect to COM |
| 01:51.37 | JeffM | FinalBuilderPro |
| 01:52.23 | JeffM | also don't forget there is an open source implmentation of .net |
| 01:52.52 | bizarrefish | The VB6 to VB.NET probably works quite well for some simple apps. From what i've seen, the crazy things people do in VB6 make a rewrite-by-hand more efficient/preferable. |
| 01:53.10 | JeffM | that is true |
| 01:53.48 | bizarrefish | The object model is completely different. A lot of crap is no longer allowed. Not just syntactically, conceptually. I tried writing a VB6 yacc grammar a while back. Didn't get very far before admitting my sanity was more important :P |
| 01:54.23 | JeffM | it was never intended for that kindat stuff |
| 01:54.38 | bizarrefish | And yeah, I completely support .NET. I just home MS keep pushing with the standardization. |
| 01:54.38 | JeffM | like bzflag and internet play :) |
| 01:54.44 | bizarrefish | *hope |
| 01:54.58 | bizarrefish | Haha, It wasn't meant for internets? |
| 01:55.02 | JeffM | oh god no |
| 01:55.05 | JeffM | it's a lan game |
| 01:55.06 | bizarrefish | Oh, you mean as opposed to LAN |
| 01:55.08 | bizarrefish | riight |
| 01:55.14 | JeffM | thats why it's so easy to cheat |
| 01:55.16 | bizarrefish | Hence the bug about enormous message sizes |
| 01:55.23 | bizarrefish | oh, and that. |
| 01:55.35 | JeffM | the client does all the game logic and every client trusts every other client |
| 01:55.37 | JeffM | the server does nothing |
| 01:55.51 | JeffM | it allso assumes that packets take no time to send |
| 01:56.00 | bizarrefish | It's slowly doing more as far as I can tell |
| 01:56.08 | JeffM | very slowly |
| 01:56.12 | JeffM | all it does now is flags and spawns |
| 01:56.20 | JeffM | it dosn't know where tanks are, it dosn't have shots |
| 01:56.37 | JeffM | it can't authenticate any action a player makes |
| 01:56.43 | JeffM | othe then flag grabs now |
| 01:56.45 | JeffM | and caps |
| 01:56.59 | JeffM | we only did those because they were easy |
| 01:57.06 | bizarrefish | Shame about 2.99. Wasn't that moving shots to server side? |
| 01:57.11 | JeffM | nopr |
| 01:57.20 | JeffM | everyone thought it was, it wasn't |
| 01:57.31 | bizarrefish | Good to know everyone thought it was, too |
| 01:57.48 | bizarrefish | I do notice some stuff about a...CollisionManager |
| 01:57.53 | bizarrefish | and octrees and such |
| 01:58.00 | JeffM | that's been there forever |
| 01:58.02 | bizarrefish | (in bzfs) |
| 01:58.04 | JeffM | for a decade or so |
| 01:58.08 | JeffM | sure it has it for spawns |
| 01:58.16 | bizarrefish | Ahh, right. |
| 01:58.31 | JeffM | it has the world now, but the shot logic is tied to the client |
| 01:58.40 | JeffM | breaking it out was not a trivial task |
| 01:58.53 | JeffM | I tried it once, and a full summer of code was spent on it |
| 01:59.19 | JeffM | I think the next thing would be GM updates on the server |
| 01:59.30 | JeffM | those should be doable in the current protocol |
| 02:00.06 | bizarrefish | Any particular reason GM? (apart from the point about protocol) |
| 02:00.26 | JeffM | because it is small and modular |
| 02:00.27 | bizarrefish | Doing laser collisions server side shouldn't be too hard. |
| 02:00.27 | JeffM | and has no rico |
| 02:00.32 | JeffM | they bounce |
| 02:00.45 | bizarrefish | Ah, right. |
| 02:00.54 | JeffM | rico means you have to get the shot pos to be correct on the server and match every client |
| 02:01.13 | JeffM | off by a small degree and clients won't match the server |
| 02:01.24 | JeffM | GM sends constant updates so the deviation would be small |
| 02:02.02 | JeffM | thats what became hard, to get shots right you need to get the short origins right, and to get the origins right, you have to have the tanks right |
| 02:02.52 | JeffM | the simplest way to get the origins right is to have the server force all clients to use the same origin, even the shooter and that needs some bigger changes |
| 02:03.12 | JeffM | the client ignores the server for many of the things it localy generates |
| 02:03.40 | bizarrefish | So at the moment, the shooter decides if the other player gets hit? |
| 02:03.48 | JeffM | no |
| 02:03.53 | JeffM | the shooter adds a shot |
| 02:04.04 | JeffM | other players add that shot where they think the shooter is |
| 02:04.18 | JeffM | if they detect that they hit the shooter's bullet they say "I died" |
| 02:04.50 | JeffM | one common cheat is to send an update that your postion is inside or near to another player, then send the shot, then send an update that say you are back were you started |
| 02:05.13 | JeffM | the remote player would see a shot appear inside of them, they'd blow up, but when they look they see the shooter far away |
| 02:05.38 | JeffM | thats why we can't trust the client with postions |
| 02:05.52 | JeffM | we need to change over to just accepting input like "drive forward", or "turn left" |
| 02:06.08 | JeffM | then timestamp it all and make sure that it all makes sense |
| 02:06.16 | JeffM | and send back updated postions |
| 02:06.45 | JeffM | then the client is a dumb terminal with a small amount of movement predition to make it not jump |
| 02:07.16 | bizarrefish | That's quite a jump indeed. In fact, you're gonna need a WG flag... |
| 02:07.27 | JeffM | it's how most modern games do it |
| 02:08.05 | JeffM | once the server has all the input from each player in a timestream it can recreate postions as it needs to check and see who hit who |
| 02:09.05 | bizarrefish | Are shots currently timestamped? I noticed you said the victim works from where it 'thinks' the player is. If there is a when, where, and in-what-direction, why would there be any difference in opinion? |
| 02:09.17 | JeffM | nope |
| 02:09.26 | JeffM | it just assumes that there was 0 lag from when it was sent |
| 02:09.28 | bizarrefish | Ah...damn. |
| 02:09.33 | JeffM | so everyone has a different state |
| 02:09.39 | bizarrefish | Surprising effective, somehow |
| 02:09.42 | JeffM | thats why you have to lead your shots by expected lag |
| 02:09.44 | JeffM | it isn't |
| 02:09.56 | JeffM | just the tanks and shots move so slow it often looks like it works |
| 02:09.57 | blast007 | it just gets lucky sometimes :P |
| 02:10.02 | JeffM | yeah |
| 02:10.12 | bizarrefish | I suppose it's never really possible to hit a tank moving quickly.. |
| 02:10.19 | JeffM | it is hard |
| 02:10.48 | bizarrefish | There's a concept of game time already, would there be an issue adding timestamps to the shots? |
| 02:11.21 | JeffM | we actualy want to add timestamps to the player updates and make shots just be "I shot" |
| 02:11.26 | JeffM | then you send an update with the shot |
| 02:11.36 | JeffM | because a shot can't come from anywhere else other then your tank |
| 02:12.04 | JeffM | and it may be more then just timestamps and doing predition, that can cause people to jump on screen if they change direction quickly |
| 02:12.33 | JeffM | that and the input storing method are the two lag compensation methods that need to be evaluated |
| 02:12.50 | JeffM | 2.99 has some lag compensation by using timestamps |
| 02:12.52 | blast007 | the hard part is keeping it biased towards players with lower lag. You don't want a laggy client to have an advantage simply because their lag is higher, and thus their shots all of a sudden 'appear' half a second ahead of where they were when they shot. |
| 02:13.04 | blast007 | which could happen with lag comp'd shots |
| 02:13.09 | JeffM | yeah |
| 02:13.18 | JeffM | you have to banlce it and see what works for the gameplay |
| 02:13.27 | JeffM | and it's a lot of work to change it over |
| 02:14.01 | blast007 | many popular multiplayer games start to break down once you start going too far past 100ms latency |
| 02:14.59 | JeffM | yeah they also move a lot faster then bz |
| 02:15.01 | blast007 | and in those cases, the laggy users generally suffer (inability to move, enemies move in busts of speed, etc) |
| 02:15.35 | JeffM | there is a relationship to how fast a player can move across a screen compared with how fast they can change direction and latency |
| 02:15.58 | JeffM | also compared to the size of the avatar, etc.. |
| 02:16.43 | JeffM | it's all solveable in bzflag's case it's just not easy to do in little bits and peices. |
| 02:16.52 | JeffM | and our development has always been little bits and peices |
| 02:19.15 | bizarrefish | For bugs and such, it seems to work ok. I see bugs getting fixed and such. Is there a particular go-to-guy for big architectural changes that can't easily be done in bits-and-pieces? |
| 02:19.55 | bizarrefish | is saying "and such" too often. it's 02:19. Should probably get a-snoozin' before long./ |
| 02:22.13 | JeffM | there isn't |
| 02:22.22 | JeffM | the maintainer has ignored the project for a while |
| 02:22.47 | JeffM | we have kept a list of feature desins on the wiki in the roadmap |
| 02:22.55 | JeffM | some of them are modular |
| 02:23.16 | JeffM | wonders if he can get Tim to sell bzflag ;) |
| 02:23.58 | *** join/#bzflag jeffmOSX (~jeffm@cpe-76-167-236-199.socal.res.rr.com) |
| 02:24.13 | bizarrefish | I can't see an android port being too difficult. Could have a non-free version of that. |
| 02:24.27 | bizarrefish | Converting to GL ES would be a pig. |
| 02:24.56 | JeffM | it would not play the same, from a game design standpoint you'd want to change how it worked |
| 02:25.25 | bizarrefish | As in UI? |
| 02:25.26 | JeffM | the touchscreen would not be as efficent an input device since your hand would be covering a lot of the screen |
| 02:25.34 | JeffM | yeah and I'd take some of the flags out |
| 02:25.48 | JeffM | bassicly make a game inspired by bzflag for mobile |
| 02:25.50 | blast007 | BZFlag Pocket Edition |
| 02:25.51 | bizarrefish | I'd use accelerometer for steering (tilt) |
| 02:25.52 | JeffM | yeah |
| 02:26.06 | bizarrefish | DroidFlag? |
| 02:26.09 | JeffM | sure but then you need to tap for fire and jump and that gets hard |
| 02:26.14 | Notify | 03BZFlag:bullet_catcher * 22581 (trunk/bzflag/MSVC/bzflag.rc trunk/bzflag/Xcode/BZFlag-Info.plist and 4 others): Update copyright notices to 2013 in oddball files. |
| 02:26.15 | JeffM | most tilters don't fire too |
| 02:26.25 | JeffM | tilters tend to use 2 hands |
| 02:26.36 | JeffM | BulletCatcher, why didn't the script get those? |
| 02:27.03 | BulletCatcher | They didn't have strings that match what the script looks for. |
| 02:27.10 | blast007 | voice commands. Yell 'fire' to shoot! |
| 02:27.23 | JeffM | better with kenect! |
| 02:27.39 | JeffM | bizarrefish, bassicly it would not be fair to have mobile players compete against PC players |
| 02:27.46 | JeffM | the fun would be diminished |
| 02:27.47 | BulletCatcher | Some of them will be caught next time, but there are a couple of files that say 2003-2013 instead of 1993-2013. |
| 02:27.58 | JeffM | 2003 why? |
| 02:28.05 | bizarrefish | I agree on that point(about mobile vs PC players) |
| 02:28.14 | BulletCatcher | I didn't look at the history. |
| 02:28.27 | JeffM | yeah so then we'd be maintaining 2 seperate games |
| 02:28.36 | JeffM | and we are having trouble maintaining one already |
| 02:28.56 | JeffM | thats why we arn't really interested in ports right now |
| 02:28.57 | BulletCatcher | See tools/TextTool-W32/TextTool.rc for example. |
| 02:28.58 | bizarrefish | It's still a very fun game, visually. Some new frontend stuff would have to be written to make it an experience worth having, certainly. |
| 02:29.30 | blast007 | bizarrefish: it'd be pretty much a full rewrite to get any usable version of the game for mobile |
| 02:29.39 | JeffM | someone was doing an android port, I wish them the best of luck but I'd not want the project taking on that codebase |
| 02:30.04 | JeffM | BulletCatcher, probably just when I made it, I think we can backdate them all to 93 and be ok |
| 02:30.24 | blast007 | we probably have too much inefficient code that would run like garbage on an ARM chip |
| 02:30.43 | JeffM | the arm chips are pretty good these days |
| 02:30.52 | JeffM | it's the java that we'd probably run poorly under |
| 02:30.57 | blast007 | kinda.. |
| 02:30.58 | bizarrefish | The arm chips aren't bad |
| 02:31.15 | BulletCatcher | Also, the files in misc/stats say they are copyrighted by both Tucker McLean and Tim Riker. |
| 02:31.21 | blast007 | they generally have faster GPU cores than CPU cores |
| 02:31.22 | bizarrefish | Android NDK would help out in that regard, wouldn't it? |
| 02:32.04 | bizarrefish | (the java regard) |
| 02:32.09 | jeffmOSX | BulletCatcher, the tucker should be removed |
| 02:32.30 | jeffmOSX | bizarrefish, does it make java suck less? |
| 02:32.40 | blast007 | NDK lets you use C/C++ |
| 02:32.47 | bizarrefish | jeffmOSX: It makes java irrelevant tot he application |
| 02:32.48 | blast007 | for parts of the app, at least |
| 02:33.14 | blast007 | "Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity." |
| 02:33.55 | blast007 | so not really all that useful |
| 02:34.03 | *** join/#bzflag JeffM (~jeffm@unaffiliated/jeffm2501) |
| 02:34.03 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 02:34.28 | JeffM | if someone wants to make it, more power to them |
| 02:34.45 | JeffM | I don't think we should waste time on it IMHO |
| 02:34.57 | blast007 | or at least not waste time on it right now |
| 02:35.03 | blast007 | there are far more pressing issues |
| 02:35.26 | bizarrefish | I don't know much about dalvik from a performance standpoint(or any other standpoint). I'd be more confident about the performance if we were talking about hotspot. It's pretty good. |
| 02:36.16 | bizarrefish | Indeed, more pressing issues. Not least my bed time. Gotta go, chaps :) |
| 02:36.25 | JeffM | have fun |
| 02:38.05 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 03:44.38 | *** join/#bzflag JeffM (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 03:44.39 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 03:44.39 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 05:14.19 | *** join/#bzflag mdskpr_ (~mdskpr@pool-108-25-132-135.atclnj.east.verizon.net) |
| 06:41.52 | *** join/#bzflag Gnurdux (~gnurdux@pool-70-108-34-27.res.east.verizon.net) |
| 07:54.15 | *** join/#bzflag jcp (~quassel@vps1.opengroove.org) |
| 07:54.15 | *** join/#bzflag jcp (~quassel@bzflag/contributor/javawizard2539) |
| 09:49.49 | *** join/#bzflag bizarrefish (~lee@host-89-240-248-78.as13285.net) |
| 10:01.30 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 10:18.10 | bizarrefish | Is it just me, or is shooting broken in bzflag trunk? |
| 10:18.22 | bizarrefish | I get a segfault when I try to fire |
| 10:39.34 | jcp | bizarrefish: Sound unavilable? |
| 10:39.53 | jcp | (Because I was having a segfault earlier that I fixed by starting my pulseaudio back up, might be related) |
| 10:40.29 | jcp | heads to bed |
| 10:41.30 | bizarrefish | Yeah, something going wrong with audio allocation |
| 10:41.45 | bizarrefish | Seems wrong |
| 10:41.51 | bizarrefish | Shouldn't bomb out just because of that |
| 10:55.08 | bizarrefish | Submitted patch. A check was a bit wrong. |
| 11:09.24 | blast007 | bizarrefish: is your client being built with SDL support? |
| 12:22.59 | alezakos | Why doesn't the /flag give command trigger a flag grabbed event? |
| 13:21.41 | blast007 | alezakos: because the code is inconsistent? ;) |
| 13:41.16 | blast007 | src/bzfs/commands.cxx does it's own code for telling the player to grab a flag |
| 13:42.13 | blast007 | it doesn't use the grabFlag function from bzfs.cxx, since it presently can't (as grabFlag does some checks, such as distance to the flag) |
| 13:43.38 | blast007 | it probably also doesn't trigger a flag drop event if the player already has a flag |
| 13:47.03 | blast007 | (nor does it probably do that for /flag take) |
| 14:21.51 | *** join/#bzflag swigg_ (~swigg@nsc69.38.101-238.newsouth.net) |
| 15:28.56 | *** join/#bzflag swigg (~swigg@bzflag/player/Swigg) |
| 15:53.10 | *** join/#bzflag spldart (~spldart2@c-98-199-190-28.hsd1.tx.comcast.net) |
| 15:53.10 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 15:53.10 | *** mode/#bzflag [+v spldart] by ChanServ |
| 16:08.20 | *** join/#bzflag DarkCalf (~DarkCalf@173.231.40.98) |
| 16:34.37 | *** join/#bzflag Gnurdux (~gnurdux@129-2-129-147.wireless.umd.edu) |
| 16:47.33 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 16:47.33 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 17:10.13 | *** join/#bzflag mdskpr (~mdskpr@pool-108-25-132-135.atclnj.east.verizon.net) |
| 18:29.01 | *** join/#bzflag swigg_ (~swigg@nsc69.38.101-238.newsouth.net) |
| 18:52.12 | *** join/#bzflag McYukon (~McYukon@69.162.80.34) |
| 19:11.59 | alezakos | Shouldn't be players disallowed from sending messages containing spaces only? |
| 19:13.25 | alezakos | to send* |
| 19:29.21 | blast007 | alezakos: why? |
| 19:31.28 | blast007 | <PROTECTED> |
| 19:32.44 | blast007 | we've already copied a bunch of stuff from IRC, so why not whitespace only messages as well? ;) |
| 19:33.05 | alezakos | Ok then |
| 19:33.24 | alezakos | Even though my client doesn't allow me to send such messages (only on /me commands) |
| 19:33.37 | blast007 | is there a specific reason why you're wondering about this? |
| 19:33.58 | alezakos | Good question |
| 19:35.05 | blast007 | and perhaps I'm misunderstanding your question.. thought you were asking if players should be disallowed from sending whitespace only messages. But then you just said you can't send such messages when doing normal messages, but only when using /me. |
| 19:35.34 | alezakos | I meant my IRC client |
| 19:35.42 | blast007 | oh |
| 19:36.27 | blast007 | so in bzflag you can send whitespace only messages regardless of how you do it? |
| 19:36.58 | alezakos | Yes, even with /me or /msg |
| 20:57.47 | *** join/#bzflag Fira (artix@unaffiliated/fira) |
| 21:26.53 | *** join/#bzflag bizarrefish (~lee@host-89-240-248-78.as13285.net) |
| 21:34.20 | Notify | 03BZFlag:blast007 * 22582 (trunk/bzflag/man/bzfs.6.in trunk/bzflag/package/win32/README.win32.html and 4 others): Get rid forum and wiki links still pointing to my.bzflag.org |
| 22:02.35 | alezakos | Should I submit a patch for the issue with the flags mentioned above? |
| 22:13.56 | blast007 | sure |
| 22:15.00 | blast007 | JeffM: and just in case you didn't check the file itself, he did add a license to the header of the file |
| 22:15.12 | JeffM | ahh ok |
| 22:15.17 | blast007 | I think the first map he posted he had it in there initially, but probably just forgot for this one |
| 22:15.22 | JeffM | cus I looked at the file before I posted the first time |
| 22:15.31 | JeffM | it did not in his first post |
| 22:15.55 | blast007 | I mean, this is his second map release |
| 22:16.36 | blast007 | the first map he released had the license from the beginning |
| 22:16.37 | JeffM | ahh |
| 22:30.28 | alezakos | I'll submit the patch tomorrow - a few bugs have to be solved :) |
| 22:31.09 | alezakos | There were pieces of the same code on many different places, so I changed the dropFlag() function and made checking for the flag position optional |
| 22:57.26 | *** join/#bzflag Guest508 (4e33e116@gateway/web/freenode/ip.78.51.225.22) |
| 22:57.41 | Guest508 | hi all |
| 22:58.07 | *** part/#bzflag Guest508 (4e33e116@gateway/web/freenode/ip.78.51.225.22) |
| 22:58.58 | blast007 | bye |
| 23:09.07 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 23:55.37 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |