| 00:00.17 | Macrosoft | if you want it the easy way, there is the string library |
| 00:00.24 | F687s | easy is good |
| 00:00.32 | Macrosoft | :p |
| 00:01.15 | F687s | okay, PM me the next time you reach for the aspirin. |
| 00:01.20 | Macrosoft | F687s: throw pointers into that mix, and you get real fun :p |
| 00:03.25 | F687s | are you talking strict C, or C++? |
| 00:03.54 | Macrosoft | c++, i think |
| 00:04.17 | F687s | so that wouldn't be AS bad |
| 00:04.27 | F687s | still has to hurt, though |
| 00:12.53 | JeffM | you don't find yourself using unions that much in practice |
| 00:12.55 | JeffM | ram is cheap |
| 00:13.24 | Winny | JeffM: if you look at the thread, you'll see why I didn't do normals :P |
| 00:14.09 | JeffM | why? cus you want the shading to have sharp edges? |
| 00:14.28 | Winny | You can barely even see the edges |
| 00:14.45 | JeffM | it shows worst on the trunk |
| 00:15.11 | Winny | I assume you're looking at: http://bzfusion.net/winny/maps/Crylo/bzfi1012.png ? |
| 00:15.17 | JeffM | 13 |
| 00:15.26 | JeffM | you have this nice soft shaddow for the ground |
| 00:15.32 | JeffM | but the trunk shading is harsh |
| 00:15.38 | JeffM | and in the wrong spot ;) |
| 00:15.43 | Winny | pft :p |
| 00:15.57 | JeffM | if you smothed your normals it would be better |
| 00:16.02 | Winny | alright |
| 00:17.26 | F687s | what? |
| 00:17.48 | JeffM | it's a secret |
| 00:18.03 | JeffM | would involve custom plug-ins :) |
| 00:18.07 | F687s | okay, and if you never do it, we will never know. Cool. |
| 00:18.17 | JeffM | and SCIENCE! |
| 00:18.23 | Winny | uhoh |
| 00:18.42 | AAA_Awright | Stand back I'm gonna try SCIENCE! |
| 00:18.57 | AAA_Awright | ~poof |
| 00:18.58 | ibot | I know, sweetie |
| 00:18.59 | JeffM | excatly |
| 00:19.05 | Macrosoft | huh? |
| 00:19.08 | F687s | like, growing-pea-plants science, or inventing-nitroglycerin science? |
| 00:19.11 | AAA_Awright | ? |
| 00:19.20 | AAA_Awright | pea-plant science |
| 00:19.24 | Macrosoft | AAA_Awright: whats wrong with the poof |
| 00:19.25 | JeffM | COMPUTER SCIENCE! |
| 00:19.26 | Macrosoft | ? |
| 00:19.32 | AAA_Awright | Or cs |
| 00:19.33 | JeffM | someone probalby changed it |
| 00:19.47 | AAA_Awright | ~factinfo poof |
| 00:19.47 | ibot | poof -- created by ryan__ <~ryan@eth195.sa.adsl.internode.on.net> at Wed Aug 27 22:44:27 2003 (1571 days); it has been requested 6 times, last by AAA_Awright, 49s ago. |
| 00:19.59 | F687s | you're making "revenge of the data structures?" |
| 00:21.04 | JeffM | constructive use of the API that is available ;) |
| 00:21.16 | JeffM | well that and maybe some server mods |
| 00:22.12 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 00:22.20 | Macrosoft | if i could tell whats going on in the bz code, i could do a zombie mod, but there are a lot of files i'd have to read through first |
| 00:22.41 | JeffM | there is only so much you can do with the 2.0.x protocoll |
| 00:22.49 | JeffM | 3.0 you'll be able to do more |
| 00:23.41 | Macrosoft | JeffM: is the [p] and [nr] the only things that can be added to the score board in 2.0.x? |
| 00:23.42 | blast007 | and 4.0 will be able to open wormholes between the client and the server to reduce latency |
| 00:23.54 | JeffM | Macrosoft: yes |
| 00:24.05 | JeffM | blast007: no just smart prediction ;) |
| 00:24.11 | F687s | something tells me in 3.0, everything will be done, everything will be done easier, and everything will be done right. |
| 00:24.13 | Macrosoft | crap, i wanted to add a [z] for indicating zombies |
| 00:24.17 | JeffM | I'm hoping that lag will affect the game a lot less in 3.0 |
| 00:24.20 | JeffM | Macrosoft: nope |
| 00:24.23 | blast007 | F687s: then something tells you wrong |
| 00:24.48 | JeffM | that's one thing I want to add to 3.0, server defined score messages |
| 00:26.57 | F687s | well, there are quite a few API questions answered in "in 3.0 this will be done" |
| 00:27.37 | Macrosoft | does santa bring code for christmas? |
| 00:27.40 | Macrosoft | :P |
| 00:28.19 | F687s | santa probably writes BASIC |
| 00:28.25 | KTL | <PROTECTED> |
| 00:29.45 | F687s | the elves write Java/XML |
| 00:29.59 | Macrosoft | screw the milk and cookies, leave santa some c/c++ books |
| 00:30.03 | AAA_Awright | JeffM: The client just needs to recognize it's own MsgScore packet and update it's own score, right? |
| 00:35.22 | JeffM | AAA_Awright: for what? |
| 00:35.38 | AAA_Awright | Updating scores |
| 00:35.59 | JeffM | 2.0.x dosn't accept score updates for itself |
| 00:36.02 | JeffM | 3.0 does |
| 00:36.07 | AAA_Awright | Yeah |
| 00:36.38 | JeffM | I don't understand your "needs to" comment |
| 00:36.41 | JeffM | one does, one dosn't |
| 00:36.45 | JeffM | 2.0.x can't |
| 00:40.00 | AAA_Awright | If 2.0 was to be updated, I mean |
| 00:40.12 | JeffM | it would not be compatable then |
| 00:40.23 | JeffM | so the update went into trunk |
| 00:41.01 | JeffM | compatability is behavor as well as network data protocoll |
| 00:41.55 | JeffM | just like the mesh->box collision problem |
| 00:41.59 | JeffM | we can't fix that in 2.0.x |
| 00:42.21 | JeffM | cus then some 2.0.x clients would drive over soemthing an older one could not, giving one an unfair advantage. |
| 00:42.28 | JeffM | so we fix it on a proto break |
| 00:43.21 | Macrosoft | hmm... how do i apply a patch? |
| 00:43.28 | JeffM | with patch |
| 01:14.25 | Macrosoft | Winny: oh noez, its an army of trees! |
| 01:14.39 | Winny | Macrosoft: that was jut an FPS test :p |
| 01:14.54 | Winny | got about 30.. grr v-sync |
| 01:15.01 | Winny | with v-sync off it went to 50 |
| 01:15.36 | Macrosoft | Winny: what kind of card do you have? |
| 01:15.56 | Winny | 660 |
| 01:16.00 | Winny | err, 6600* |
| 01:16.18 | Winny | 2 1/2 years old >_< |
| 01:16.31 | Winny | planning to upgrade to a 8800 soon I hope |
| 01:16.58 | Macrosoft | Winny: me too, have you seen the new gts that just came out |
| 01:16.59 | Macrosoft | ? |
| 01:17.29 | Winny | too expensive |
| 01:17.45 | Winny | although, it's probably a good idea just to wait for the 9 series |
| 01:17.49 | Winny | probably coming out in a few months |
| 01:18.27 | Macrosoft | Winny: do they release the entire series, or start at 9000, and release a new once every now and then? |
| 01:19.44 | Winny | I really don't know |
| 01:19.56 | Winny | usually the high end cards come first, IIRC. |
| 01:20.03 | Macrosoft | Winny: its almost as powerful as an 8800ultra, but costs about half as much: http://www.newegg.com/Product/Product.aspx?Item=N82E16814130312 |
| 01:20.38 | Winny | no need |
| 01:20.44 | Winny | the GT is also as powerful as that too |
| 01:20.56 | Winny | ...and its 100$ less |
| 01:21.05 | Macrosoft | Winny: you have to wait even longer if the high-end cards come out later than the low-end |
| 01:24.34 | Macrosoft | yep, looks like a high-end 7 series is about the same as a 8 series low-end |
| 01:26.30 | Winny | golly gee sherlock, how did you pull that one out of your hat? |
| 01:27.58 | findlay | with a flourish, naturally |
| 01:29.14 | Macrosoft | Winny: and, yes, they do release the lower end 9 series first. have fun waiting for the better cards to come out :p |
| 01:29.51 | Winny | k |
| 01:30.00 | Winny | they're probably only a couple months apart |
| 01:33.12 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
| 01:35.03 | blast007 | define "high end 8 series" |
| 01:35.29 | TD-Linux | they come out with the high-end-ish ones first |
| 01:35.33 | TD-Linux | like 8800 GT |
| 01:35.41 | blast007 | 7900GTX? |
| 01:35.44 | TD-Linux | but then they come out with things like GTX, and then Ultra |
| 01:37.15 | blast007 | hmm, there must have been a recent drop in the prices for the 7xxx series |
| 01:37.19 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 01:37.31 | blast007 | because it wasn't long ago that the 7900GTX was over $400 |
| 01:37.52 | blast007 | ah, these are open box.. |
| 01:37.55 | blast007 | (on newegg) |
| 01:41.24 | *** join/#bzflag skyler (n=skyler@207-224-41-131.hlrn.qwest.net) |
| 01:47.57 | Winny | anyone in here have crysis? I wouldn't mine a low-res mountain export. |
| 01:50.05 | Macrosoft | Winny: get the demo, it should have it |
| 01:50.40 | Winny | don't wanna download and install a 2gb file for something I can't even run |
| 01:50.47 | Winny | you can't run sandbox OR crysis on a 6600 :p |
| 01:51.31 | Macrosoft | Winny: yes you can, anything that can do dx9 can run it, but it wont be fast |
| 01:52.18 | spldart | crysis crashes on my box for some reason |
| 01:52.34 | Winny | Macrosoft: no.. you can't |
| 01:52.45 | Winny | I had to run it at school, it refused to install here. |
| 01:53.33 | Macrosoft | i dont have a windows install here, but i dont think a 6200 would do much anyway |
| 01:53.53 | spldart | that's what I'm running 6200... dunno if that's why I'm crashing |
| 01:54.29 | Winny | I bet it is |
| 01:54.36 | Macrosoft | spldart: you forgot to set the "dont suck" option |
| 01:54.38 | Macrosoft | :P |
| 01:56.27 | Macrosoft | hmm...when do we have to do our taxes? |
| 01:57.09 | Macrosoft | is it at the beginning of the year or what? |
| 01:58.49 | *** join/#bzflag delusional (n=delusion@pool-71-253-15-185.pitbpa.east.verizon.net) |
| 02:00.19 | Winny | anyways... anyone know of a tool I can use to make this kind of mountain easily? http://www.incrysis.com/incgalleryview.php?file=23.jpg |
| 02:01.11 | blast007 | terragen maybe? |
| 02:02.03 | Winny | hmmm, I didn't think it could export to a filetype blender could import |
| 02:12.57 | *** join/#bzflag whodaman-_ (n=whodaman@pdpc/supporter/student/whodaman-) |
| 02:16.32 | Winny | blast007: rofl |
| 02:16.35 | Winny | 200,000 faces |
| 02:16.36 | Winny | :p |
| 02:16.45 | blast007 | heh |
| 02:16.56 | blast007 | that's like twice as much as 100,000!! |
| 02:17.09 | Winny | shall I export it and see how many FPS I get? :E |
| 02:17.46 | Macrosoft | Winny: brace for impact! |
| 02:18.49 | Macrosoft | definition of limit- as your fps approaches 0, the pobability of your card exploding approaches 1 |
| 02:20.38 | whodaman- | hehe |
| 02:21.16 | Winny | whee |
| 02:21.19 | Winny | we're down to 70,00! |
| 02:21.23 | Winny | fail. |
| 02:22.38 | Winny | yeha |
| 02:22.42 | Winny | no way this is gonna work well |
| 02:22.47 | Winny | the PBJ is 5,000kb |
| 02:22.50 | Winny | OBJ* |
| 02:22.59 | whodaman- | o.0 |
| 02:23.00 | Macrosoft | approaching critical fail! |
| 02:23.40 | Winny | lol.. the BZW is 11mb |
| 02:24.06 | Macrosoft | ...behind a blast-shield |
| 02:34.33 | *** join/#bzflag Tedius (n=Tedius@adsl-76-205-104-216.dsl.bcvloh.sbcglobal.net) |
| 02:35.05 | Winny | yay |
| 02:35.06 | Winny | 3mb |
| 02:35.07 | Winny | :P |
| 02:35.24 | Macrosoft | what?! no explosion? |
| 02:35.30 | Winny | we'll see |
| 02:35.36 | Winny | still something like 50k faces |
| 02:35.51 | Macrosoft | heh |
| 02:37.31 | *** join/#bzflag bier_ (n=bier@p54A549B7.dip.t-dialin.net) |
| 02:38.42 | Winny | yeah, that was pretty much an epic fail |
| 02:39.23 | Macrosoft | Winny: what happened? |
| 02:39.34 | Winny | meshes drew wrong >_< |
| 02:39.40 | *** join/#bzflag nn-server (n=nn@74.94.43.197) |
| 02:39.43 | Macrosoft | heh |
| 02:40.34 | nn-server | my server keeps erroring on this -set _countdownResumeDelay 5 |
| 02:40.40 | nn-server | what am i missing |
| 02:43.12 | Tedius | _countdownResumeTime 5 |
| 02:45.20 | Winny | whee. 5mb :p |
| 02:48.45 | blast007 | nn-server: you have 2.0.10? |
| 02:50.12 | blast007 | that variable is only in 2.0.11 |
| 02:51.36 | pacman87 | Macrosoft: taxes are due april 15 |
| 02:51.46 | pacman87 | Macrosoft: in the US at least |
| 02:51.46 | Macrosoft | pacman87: cool, thanks |
| 02:52.15 | pacman87 | but the sooner you do them, the quicker you get your refund |
| 02:52.41 | blast007 | yeah, I do mine early. I did mine last year. |
| 02:52.48 | pacman87 | there are times i really hate winXP |
| 02:53.08 | pacman87 | i've got it on a 5 GB partition |
| 02:53.20 | pacman87 | make it easier to reinstall |
| 02:53.32 | pacman87 | but it's been slowly growing w/ updates |
| 02:53.47 | pacman87 | and told me i had to compress files to have enough extra room |
| 02:53.54 | pacman87 | so i say ok |
| 02:54.16 | pacman87 | and then it tell me "oops, XP needs those files uncompressed to run properly" |
| 02:54.32 | blast007 | heh |
| 02:54.56 | Macrosoft | pacman87: yeah, bad things happen if you compress ntdetect and reboot....bad things |
| 02:55.05 | pacman87 | lol |
| 02:55.16 | pacman87 | it had to copy them off the xp install cd |
| 02:55.21 | L4m3r | pacman87: have you moved the paging file onto your secondary partition? |
| 02:55.39 | pacman87 | yeah, but i havent' restarted yet :) |
| 02:55.55 | pacman87 | didn't want to kick everyone off my map |
| 02:57.10 | L4m3r | serving on Windows? ick |
| 02:57.46 | pacman87 | yeah. i know |
| 02:58.06 | pacman87 | i dual boot slackware |
| 02:58.18 | pacman87 | but matlab in WINE is a bit too slow |
| 02:58.30 | Macrosoft | *gasp* slackware?!!one!seven |
| 02:58.40 | pacman87 | yeah, why? |
| 02:58.40 | blast007 | Macrosoft: what's wrong with slackware? ;) |
| 02:59.02 | Macrosoft | blast007: had some bad experiences with it *shudders* |
| 02:59.09 | blast007 | okay..? |
| 02:59.11 | pacman87 | like what? |
| 02:59.17 | blast007 | did it involve you screwing it up? |
| 02:59.36 | blast007 | it's not as idiotproof as ubuntu |
| 02:59.44 | Macrosoft | nope, the one time it wasnt my fault |
| 02:59.48 | Winny | hmm, I have an interesting idea |
| 02:59.51 | blast007 | you have to know a little more to use Slackware |
| 02:59.52 | pacman87 | i couldnt' get networking to work in fedora |
| 03:00.02 | pacman87 | and debian hosed my partition table |
| 03:00.21 | pacman87 | and i wanted to learn *real* linux |
| 03:01.43 | pacman87 | any thoughts on the feasability of writing a plugin to enable rogue only for 3-player? |
| 03:01.44 | blast007 | the zipslack thing, since the system refuses to boot from CD |
| 03:01.53 | pacman87 | cool |
| 03:01.54 | blast007 | pacman87: what? |
| 03:02.08 | pacman87 | for 2 team ctf |
| 03:02.12 | blast007 | you can specify a player limit of 3 for rogues |
| 03:02.21 | pacman87 | 2 on 1 is unfair |
| 03:02.29 | pacman87 | but if the third joins rogue |
| 03:02.34 | pacman87 | instead of one of the teams |
| 03:02.37 | pacman87 | it stays fair |
| 03:02.57 | pacman87 | and ideally, it would automatically switch them to a team when the 4th player joins |
| 03:03.04 | pacman87 | but that'd have to wait to 3.0 |
| 03:03.07 | blast007 | that would be a better idea for 3.0, since you could change the rogue to a team when a 4th player joins |
| 03:03.11 | blast007 | ;) |
| 03:03.15 | pacman87 | reading my mind |
| 03:03.47 | pacman87 | Macrosoft: you mean you dont' wear it all the time? |
| 03:04.03 | blast007 | he only wears it when his brain itches |
| 03:04.06 | pacman87 | ah |
| 03:04.13 | pacman87 | well, i was wearing mine |
| 03:04.15 | Macrosoft | bbl |
| 03:04.16 | pacman87 | didnt' work |
| 03:04.27 | pacman87 | perhaps i should upgrade to the gold-plated version :) |
| 03:04.36 | blast007 | tin foil suit here |
| 03:04.46 | pacman87 | for when your body itches? |
| 03:04.57 | blast007 | no, it usually only itches when I wear it |
| 03:05.01 | pacman87 | lol |
| 03:05.58 | pacman87 | what about a plugin that tells you when the last player left if you join an empty server? |
| 03:07.53 | pacman87 | map's empty |
| 03:07.56 | pacman87 | time to reboot |
| 03:08.19 | pacman87 | if i don't come back in 5 min, that means restoring the compressed files off the cd didnt' work ... |
| 03:08.50 | *** part/#bzflag pacman87 (n=Timothy@resnet-46-58.dorm.utexas.edu) |
| 03:13.07 | *** join/#bzflag pacman87 (n=Timothy@resnet-46-58.dorm.utexas.edu) |
| 03:13.23 | pacman87 | i'm back |
| 03:13.29 | AHA | wb |
| 03:19.24 | *** join/#bzflag The_Vaxorcist (n=phillip@209.148.98.173) |
| 03:35.54 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 03:40.33 | spldart | bzflag2.norang.ca fox burrow had a tk'er goin by "I SUCK I SUCK" I think he will be making the rounds... look out for him |
| 03:40.57 | spldart | He hunts specific peeps to tk |
| 03:43.45 | *** join/#bzflag JeffM (n=Jeff@pool-71-109-219-226.lsanca.dsl-w.verizon.net) |
| 03:51.16 | Winny | fun |
| 04:00.59 | spldart | Now he is "I'ma kick U in the nutz |
| 04:01.01 | spldart | " |
| 04:01.06 | Thumper_ | he's toast |
| 04:01.19 | spldart | Can't get enough votes to get him polled banned off |
| 04:01.29 | Thumper_ | 30d ban |
| 04:01.37 | spldart | shweeet |
| 04:02.07 | Thumper_ | is silver surfer |
| 04:02.41 | Thumper_ | and he's only ever used a single IP |
| 04:02.48 | Thumper_ | so the ban will probably stick |
| 04:03.07 | spldart | I love rabbit chase and it's so rarely on first page |
| 04:16.27 | spldart | nighty night |
| 04:34.20 | *** join/#bzflag rob1n (n=rob1n@unaffiliated/rob1n) |
| 04:50.42 | pacman87 | the tk'er stopped by my map too |
| 04:50.53 | pacman87 | autokicked a few times |
| 04:50.55 | pacman87 | then left |
| 04:53.17 | *** join/#bzflag rob1n_ (n=rob1n@unaffiliated/rob1n) |
| 05:16.05 | JeffM | yay, no more direct message buffer and broadcast messages :) |
| 05:24.52 | pacman87 | is there a way to run a .bat without the command window popping up? |
| 05:25.11 | AAA_Awright | I am thinking that could be a security issue |
| 05:26.08 | pacman87 | or to have them close and keep the process running? |
| 05:26.22 | AAA_Awright | idk |
| 05:34.45 | JeffM | bat files run in the shell |
| 05:34.48 | JeffM | and that is the shell |
| 05:34.52 | blast007 | assuming you're talking about bzfs as the "process"? |
| 05:34.55 | JeffM | you could write an app that does it |
| 05:35.25 | JeffM | the windows shell is not made to work like the unix one |
| 05:35.39 | JeffM | a "process" that runs in in the background and has no interface is a service |
| 05:35.47 | JeffM | and bzfs is not writen to be a service |
| 05:38.05 | JeffM | it sounds like what you want is screen and a unix bash shell |
| 05:43.33 | pacman87 | yeah |
| 05:43.49 | pacman87 | it gets annoying having 4 cmd windows on the taskbar |
| 05:43.53 | pacman87 | 2 servers, 2bzadmin |
| 05:48.27 | JeffM | bzfs is not optimised for windows hosting |
| 05:48.39 | pacman87 | probably not a high priority :) |
| 05:48.43 | Winny | hehe |
| 05:49.05 | JeffM | so few servers run windows |
| 05:49.22 | Winny | I don't think any mainstream ones do |
| 05:49.40 | pacman87 | do most use official hosting services? |
| 05:49.50 | JeffM | huh? |
| 05:49.51 | pacman87 | or just run them off linux machines from home? |
| 05:50.01 | JeffM | official? |
| 05:50.08 | pacman87 | ie, pay money |
| 05:50.13 | Winny | yeah |
| 05:50.20 | pacman87 | i suppose i meant 'professional' |
| 05:50.26 | Winny | a home connection really isn't good for over 15-20 players |
| 05:50.28 | JeffM | most are home |
| 05:50.34 | JeffM | the good ones are dedicated |
| 05:50.39 | pacman87 | my connection isn't standard :) |
| 05:50.57 | pacman87 | university network <3 |
| 05:51.50 | pacman87 | hmmm, -ts isn't adding time stamps to the log file... |
| 05:52.02 | JeffM | since bzflag started as an SGI app, the server is setup to run with unix style administratoon |
| 05:52.08 | JeffM | windows service admin is very difrent |
| 05:52.22 | JeffM | it would be a big change to make it work windows style |
| 05:52.33 | pacman87 | i can manage, then |
| 05:52.37 | JeffM | you'd need management consoles, etc.. |
| 05:52.45 | pacman87 | don't want to delay 3.0 ;) |
| 05:52.50 | JeffM | you won't |
| 05:53.09 | JeffM | it would be so big it'd be highly improbable |
| 05:54.41 | pacman87 | any ideas about -ts and logDetail? |
| 05:54.54 | JeffM | ? |
| 05:55.11 | pacman87 | i'm trying to get timestamps |
| 05:55.41 | pacman87 | -ts does nothing |
| 05:55.41 | JeffM | probalby subed on windows |
| 05:55.41 | pacman87 | subed? |
| 05:55.45 | JeffM | stubed |
| 05:56.08 | blast007 | or plugin output doesn't get affected |
| 05:56.17 | blast007 | the normal output from bzfs has timestamps with -ts |
| 05:56.40 | pacman87 | i was reading the log from svn for logDetail.cpp |
| 05:57.07 | pacman87 | Most messages need a timestamp to be useful. Instead of using an external |
| 05:57.07 | pacman87 | program to timestamp records we can now use -ts on the bzfs commandline |
| 05:57.07 | pacman87 | to timestamp logDetail output as with any other bzfs debug message. |
| 05:57.35 | JeffM | so what is the exact problem |
| 05:57.43 | JeffM | assume I can't read your mind |
| 05:57.56 | JeffM | and don't have the full source code in my head for refrence |
| 05:57.59 | blast007 | pacman87: that's in SVN trunk, not 2.0.x |
| 05:58.12 | pacman87 | ah |
| 05:58.41 | blast007 | the same modification could probably be made to 2.0.x's version |
| 05:58.42 | pacman87 | JeffM: adding -ts to the .conf or to the command doesn't add timestamps to the logging output from logDetail |
| 05:58.46 | Winny | Wait, JeffM, you don't? :o |
| 05:58.53 | blast007 | http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/plugins/logDetail/logDetail.cpp?r1=16102&r2=16253 |
| 05:58.57 | JeffM | pacman87: and it does to the other output? |
| 05:59.01 | pacman87 | yes |
| 05:59.13 | pacman87 | nothing changed |
| 05:59.29 | blast007 | JeffM: the plugin uses cout |
| 05:59.36 | JeffM | oh |
| 05:59.39 | JeffM | then yeah that's why |
| 05:59.42 | pacman87 | ok |
| 05:59.44 | JeffM | bad plugin |
| 05:59.49 | pacman87 | so i can just use the one from trunk? |
| 05:59.53 | blast007 | no |
| 05:59.54 | JeffM | no |
| 05:59.58 | JeffM | API changed |
| 05:59.59 | pacman87 | awww |
| 06:00.00 | pacman87 | ok |
| 06:00.02 | blast007 | the one in trunk will not build in 2.0.x |
| 06:00.06 | pacman87 | so look at what changed |
| 06:00.06 | blast007 | so you'll have to mod yourself |
| 06:00.11 | blast007 | look at the link I pasted above |
| 06:00.13 | pacman87 | and apply it myself |
| 06:00.14 | blast007 | shows the differences |
| 06:00.32 | blast007 | probably not 100% accurate (different API) but gives you an idea of what has to change |
| 06:00.41 | JeffM | yeah basicly your plug-in is doing it's own output |
| 06:00.44 | JeffM | to the shell |
| 06:00.58 | JeffM | it has to call the bzflag debugMessage function to get the timestamp features |
| 06:01.07 | pacman87 | ok |
| 06:01.24 | pacman87 | will do |
| 06:01.57 | JeffM | doing a bzfs server would be such a PITA :( |
| 06:02.09 | JeffM | have to write a wraper service that would manage the instance |
| 06:03.04 | pacman87 | ?? |
| 06:03.17 | pacman87 | you still talking about bzfs for windows? |
| 06:03.32 | JeffM | when you want more then one server, you run more then one instance of bzfs |
| 06:03.45 | pacman87 | right |
| 06:03.54 | JeffM | with services, you don't install more then one service manager in the service list |
| 06:04.06 | JeffM | it's up to that manager to spawn all the needed instances |
| 06:04.16 | pacman87 | ah |
| 06:04.55 | JeffM | to do it right, you'd have to add a new entrypoint hook to bzfs |
| 06:05.15 | JeffM | and then write a totaly new service and management console, that would fire off instances of bzfs as needed. |
| 06:08.05 | JeffM | wonder how management consoles connect to service DLLs |
| 06:08.32 | pacman87 | what's the difference between 2.0 and 2.0 cs? |
| 06:08.40 | JeffM | crystal space |
| 06:15.50 | *** part/#bzflag mkzelda (i=mkzelda@unaffiliated/mkzelda) |
| 06:19.52 | *** join/#bzflag RatOmeter (n=chatzill@205.162.226.154) |
| 06:35.22 | Winny | yeah uh.. |
| 06:35.23 | Winny | http://my.bzflag.org/bb/viewtopic.php?t=11938 |
| 06:35.44 | Winny | that guy was banned on quite a few servers for cheating, looks like he's got a new name |
| 06:54.05 | *** join/#bzflag ShadowSpectre (n=Default@24-197-139-149.dhcp.spbg.sc.charter.com) |
| 07:35.00 | pacman87 | success |
| 07:35.41 | pacman87 | although now it seems to be buffering the output when i use >> to direct to a file |
| 07:35.49 | pacman87 | only writes in chunks |
| 07:48.56 | L4m3r | pacman87, that's how >> works, iirc |
| 07:49.26 | pacman87 | it was realtime before i changed it to add time stamps |
| 07:49.32 | pacman87 | when it used cout |
| 07:49.46 | pacman87 | instead of bz_debugMessage |
| 07:50.59 | L4m3r | you changed it to use a debug message? |
| 08:09.39 | *** join/#bzflag QuantumBeep (n=QuantumB@doc-72-47-73-208.leesville.la.cebridge.net) |
| 08:15.27 | pacman87 | yeah |
| 08:15.32 | pacman87 | so i could get the time stamp |
| 11:18.28 | *** join/#bzflag Warinthestar (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 12:14.27 | *** join/#bzflag LongDon (n=LongDon@host-091-097-005-018.ewe-ip-backbone.de) |
| 12:22.57 | *** join/#bzflag KTL (n=KTL@212.71.5.181) |
| 12:33.11 | *** join/#bzflag strayer (n=s-t-r-a-@p54B42DA5.dip0.t-ipconnect.de) |
| 12:40.30 | *** join/#bzflag gsnedders (n=gsnedder@host86-135-224-200.range86-135.btcentralplus.com) |
| 12:44.19 | *** join/#bzflag LongDon (n=LongDon@host-091-097-005-018.ewe-ip-backbone.de) |
| 12:44.28 | *** join/#bzflag SpazzyMcGee (n=Spazzy_M@unaffiliated/spazzymcgee) |
| 12:49.12 | *** join/#bzflag LongDon (n=LongDon@host-091-097-005-018.ewe-ip-backbone.de) |
| 12:57.11 | strayer | blast007 > ping..? |
| 13:05.28 | *** join/#bzflag QuantumBeep (n=QuantumB@doc-72-47-73-208.leesville.la.cebridge.net) |
| 13:10.50 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
| 13:25.14 | *** join/#bzflag LongDon (n=LongDon@host-091-097-067-233.ewe-ip-backbone.de) |
| 13:32.15 | *** join/#bzflag Wits (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 13:32.17 | *** join/#bzflag Wits_ (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 13:34.59 | *** join/#bzflag Wits (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 13:41.49 | *** join/#bzflag delusional (n=delusion@pool-71-253-15-185.pitbpa.east.verizon.net) |
| 14:20.24 | *** join/#bzflag Warinthestar (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 14:49.16 | *** join/#bzflag Suspect (n=Suspect@68-114-69-187.dhcp.plt.ny.charter.com) |
| 15:20.34 | ruskie | well bzflag takes 20VA extra to run on my box :) |
| 15:23.04 | Winny | is it possible to use UV mapping with LOD? |
| 15:28.12 | spldart | Thats pretty good.. being the relationship between VA and watts such that it is |
| 15:28.45 | spldart | Mine consumes a bit more :~/ |
| 15:29.25 | spldart | Speaking of consuming power.... which server this time.... |
| 15:29.54 | Thumper_ | pacman87 / blast007 : I have a -ts patch for logDetail - will commit on v2_0branch |
| 15:33.27 | *** join/#bzflag raila (n=rl@p54AD727D.dip.t-dialin.net) |
| 15:58.42 | *** join/#bzflag QBeep (n=QuantumB@72.47.73.208) |
| 16:10.25 | *** join/#bzflag F687s (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
| 16:26.11 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 16:26.46 | blast007 | strayer: pong |
| 16:28.04 | *** join/#bzflag ShadowSpectre (n=Default@24-197-139-149.dhcp.spbg.sc.charter.com) |
| 16:35.51 | strayer | thanks! :) |
| 16:38.08 | *** join/#bzflag short_circuit (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
| 16:44.08 | *** join/#bzflag Epyon (i=Epyon@host99.180.219.81.magma-net.pl) |
| 16:45.16 | *** join/#bzflag f687s_bzbot95 (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
| 16:45.26 | F687s | yay! |
| 16:50.41 | *** join/#bzflag f687s_bzbot400 (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
| 16:51.46 | F687s | is there a channel that I can do bot testing without being yelled at, or should I just do it during the lack of activity? |
| 16:52.02 | blast007 | F687s: make a new channel |
| 16:52.13 | blast007 | they're on sale right now for $0.00 |
| 16:52.39 | blast007 | (in other words, /join #F687s as an example) |
| 16:52.54 | F687s | okay |
| 16:53.10 | *** join/#bzflag f687s_bzbot926 (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
| 17:05.22 | *** join/#bzflag JeffM (n=Jeff@pool-71-109-219-226.lsanca.dsl-w.verizon.net) |
| 17:10.50 | *** join/#bzflag ViciousM (n=max@adsl-065-013-159-245.sip.rdu.bellsouth.net) |
| 17:15.58 | *** join/#bzflag Winny (n=KyleVE@unaffiliated/winny) |
| 17:17.22 | *** join/#bzflag Winny (n=KyleVE@unaffiliated/winny) |
| 17:18.09 | *** part/#bzflag LongDon (n=LongDon@host-091-097-067-233.ewe-ip-backbone.de) |
| 17:19.38 | *** join/#bzflag ViciousM (n=max@adsl-065-013-159-245.sip.rdu.bellsouth.net) |
| 17:23.32 | *** join/#bzflag Winny (n=KyleVE@unaffiliated/winny) |
| 17:34.24 | brlcad | F687s: there's #botpark for bot testing too |
| 17:35.27 | F687s | ok, I managed to open my own channel, and that works fine |
| 17:35.57 | F687s | soon I will be able to wreak havoc here! (stable, non-intrusive havoc, that is) |
| 17:36.11 | JeffM | huh? |
| 17:36.27 | brlcad | havoc better not chatter unless directly addressed |
| 17:37.15 | JeffM | your bringing another bot here? |
| 17:38.28 | F687s | just that one I proposed that will allow you to chat in-game; doubtful I'll even release it. |
| 17:38.36 | JeffM | don't |
| 17:38.41 | JeffM | we don't need more bots |
| 17:38.59 | JeffM | put those into per server channels, but NOT here. |
| 17:39.06 | JeffM | brlcad: what style? |
| 17:39.11 | brlcad | more frequent |
| 17:39.16 | JeffM | oh\ |
| 17:39.26 | brlcad | smaller chunks |
| 17:39.37 | JeffM | they are nasty probably breaking changes, so I wanted the granularty for easy rollback and detection |
| 17:39.54 | F687s | alrighty then (in that case, it won't speak). |
| 17:39.54 | JeffM | and I want a bigger number then you ;) |
| 17:40.09 | JeffM | F687s: if it won't speak, then it has no point being here |
| 17:40.12 | brlcad | heh, you'll have to keep that rate up for several months to catch up |
| 17:40.14 | JeffM | don't make it join |
| 17:40.20 | brlcad | and that's only if I don't do anything, which isn't likely :) |
| 17:41.09 | JeffM | F687s: don't get me wrong, IRC -> server links are not a bad thing in my mind, they just don't belong in THIS channel |
| 17:41.16 | F687s | it's so that I can keep up on IRC communications in-game, without having to check back frequently. |
| 17:41.28 | JeffM | this is the project channel, and irc -> server link will be server specific, not project global, so it goes elsewhere. |
| 17:41.44 | JeffM | F687s: that's fine, but put it in another channel |
| 17:42.12 | JeffM | we should not have to suffer to make your server admin life easier |
| 17:42.33 | F687s | it's ME-specific, so it shouldn't belong to a server (and if you're saying it's for lighter purposes, maybe #bzchat would be better). |
| 17:42.52 | JeffM | no #bzflag and #bzchat are not server specific |
| 17:43.02 | JeffM | you make your own server specific channel |
| 17:43.03 | JeffM | that's it |
| 17:43.16 | JeffM | make ##myservernamewhatever |
| 17:43.18 | JeffM | and use that |
| 17:43.35 | F687s | it's not for inter-server communication. |
| 17:44.02 | JeffM | I know |
| 17:44.34 | JeffM | basicly , no new bots in #bzflag or #bzchat unless they have very specific uses that are approved. |
| 17:44.39 | JeffM | other then that do whatever you want. |
| 17:44.55 | F687s | crap, er, okay |
| 17:45.10 | brlcad | what would be the purpose of the bot? |
| 17:45.53 | brlcad | if it's to admin various servers from irc, might I suggest a #bzadmin |
| 17:46.33 | F687s | it basically tunnels IRC messages to a bzfs server. |
| 17:46.48 | JeffM | to a specific server or any server? |
| 17:47.03 | F687s | to whatever server you deploy the bot on. |
| 17:47.12 | JeffM | so a specific server |
| 17:47.17 | JeffM | then it should go into a chanel for that server |
| 17:47.19 | brlcad | does it have admin abilities on that server? |
| 17:47.28 | brlcad | or just relays messages? |
| 17:47.29 | F687s | more specifically, it's a plugin for my bzadmin bot that I'm doing for fun |
| 17:47.38 | F687s | no, for the most part it relays messages |
| 17:47.47 | Winny | IIRC, Constitution is also working on an IRC -> BZFlag bridge |
| 17:47.56 | JeffM | a couple people are |
| 17:48.14 | F687s | it has a command to send messages back up the pipe to IRC |
| 17:48.23 | brlcad | L4m3r was working on something similar as well, should talk to him about the direction he was going |
| 17:48.31 | JeffM | sounds VERY server specific |
| 17:48.40 | JeffM | I'd think you'd want one in each channel per server |
| 17:49.08 | JeffM | but fo sho, does not belong here or in #bzchat |
| 17:49.09 | brlcad | the approach L4m3r was/is taking was discussed much more in-depth and would be more useful if you want to collaborate on something more hashed out design-wise |
| 17:49.30 | F687s | I was just making this for a fun project |
| 17:49.40 | F687s | and it is not affiliated with any specific server |
| 17:49.43 | brlcad | so turn the fun into fun and useful ;) |
| 17:49.57 | JeffM | F687s: sure it is, it connects to specific servers |
| 17:50.14 | JeffM | it may be USED with any server, but once you use it, it works with that server |
| 17:50.56 | F687s | JeffM: Yes, in that sense. |
| 17:50.56 | JeffM | and it's uses are server specific ( send messsage to this server ) |
| 17:50.56 | JeffM | the project and servers are seperate |
| 17:50.56 | JeffM | and this channel is for the project |
| 17:51.16 | F687s | if you know perl, and can learn a 65-line API, it is useful. |
| 17:51.19 | JeffM | IRC channels are cheap, so you can just add more channels for whatever needs. |
| 17:51.23 | JeffM | ew |
| 17:51.50 | F687s | okay, I'll write it in C, and you can learn a 565-line API ;-) |
| 17:51.51 | JeffM | C:\Documents and Settings\JeffM>perl |
| 17:51.51 | JeffM | 'perl' is not recognized as an internal or external command, |
| 17:51.51 | JeffM | operable program or batch file. |
| 17:51.51 | JeffM | C:\Documents and Settings\JeffM> |
| 17:51.58 | JeffM | you do whatever you want |
| 17:52.03 | JeffM | it's your project |
| 17:52.40 | JeffM | adding libIRC to bzadmin would be cake |
| 17:53.17 | brlcad | condensed lines of code in perl are highly overrated, imho .. that terseness turns into opaqueness and incomprehensibility after a few years |
| 17:53.22 | F687s | I never intended it to be an enterprise-level hack. |
| 17:53.38 | F687s | and my perl is very readable, thank you. |
| 17:54.05 | brlcad | has nothing to do with "your perl" :) |
| 17:54.15 | brlcad | nature of the language |
| 17:54.22 | brlcad | very powerful, very terse |
| 17:54.43 | F687s | C is quite powerful and terse, also |
| 17:54.48 | F687s | so is hexcode |
| 17:54.51 | brlcad | C's not really terse |
| 17:55.13 | F687s | not if you use it properly |
| 17:55.15 | brlcad | just by that same fact that your 65 lines of perl expand to 500+ lines in C |
| 17:56.04 | JeffM | uggg, 82 uses of pack/unpack string :( |
| 17:56.32 | F687s | don't use pack/unpach, use a module |
| 17:56.45 | JeffM | huh? |
| 17:56.52 | Gnurdux | hes talking about in C |
| 17:56.56 | JeffM | and bzflag |
| 17:57.08 | JeffM | pack/unpack is how we put stuff in network byte order |
| 17:57.25 | JeffM | and I want to get rid of all the pack/unpack strings and replace them with pack/unpack std string |
| 17:57.29 | Gnurdux | it also handles some of the protocol, doesnt it? |
| 17:57.31 | F687s | sorry... |
| 17:57.46 | JeffM | depends what you mean by "handles" |
| 17:57.51 | JeffM | if you mean packs and unpacks, yes |
| 17:57.52 | JeffM | :) |
| 17:58.03 | JeffM | F687s: honeslty I care little about your perl code |
| 17:59.01 | brlcad | JeffM: erm.. why that change? |
| 17:59.03 | F687s | JeffM: the code, the project, sarcasm, what? |
| 17:59.17 | JeffM | brlcad: so we don't have to have fixed size strings anymore |
| 17:59.30 | JeffM | dynamic buffers ftw |
| 17:59.54 | brlcad | it'll have to be more than pack and unpack for that to take effect |
| 18:00.04 | JeffM | F687s: all of them. I have no use for perl code, I have no way to run perl code, I have no intrest or desire to change, write, or do anything with perl code. |
| 18:00.11 | brlcad | otherwise it's just a lot of data marshalling, string copies |
| 18:00.27 | brlcad | the network sends are still fixed size buffers, no? |
| 18:00.27 | JeffM | the strings are copied right now as is |
| 18:00.34 | JeffM | brlcad: nope :) |
| 18:00.46 | JeffM | no more buffer overflows :) |
| 18:00.58 | JeffM | no more manualy counting packet sizes :) |
| 18:01.06 | brlcad | o.O |
| 18:01.23 | JeffM | no more DirectMessageBuffer |
| 18:01.24 | brlcad | it still boils down to send() which takes a buffer and a buffer size.. |
| 18:01.28 | F687s | I have no use for C++, Darwin is one _mean_ development environment, and everything I need to do can be done in Perl. |
| 18:01.31 | F687s | each to his own. |
| 18:01.44 | JeffM | yes, but that all comes from the message manager, that has a buffer for each message now |
| 18:01.48 | JeffM | so they can be threaded |
| 18:02.11 | *** join/#bzflag Wits (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 18:02.19 | JeffM | brlcad: the old strings were fixed size and still did a copy into a SINGLE fixed buffer |
| 18:02.36 | brlcad | into the final send buffer |
| 18:02.43 | JeffM | with this change we still do a copy, but most likely a smaller copy, into a difrent non shared buffer. |
| 18:02.47 | brlcad | but before that, the user buffer was just passed around |
| 18:03.05 | JeffM | yeah, and we had cases where we would blow out that user buffer |
| 18:03.32 | JeffM | such as calling an API function when building a message, and that API callback building it's own method, etc.. |
| 18:03.50 | JeffM | basicly each method gets it's own buffer now, and can be processes async from the other messages |
| 18:04.05 | JeffM | so we can do a thread to send em out at whatever pace, and do throtling, etc.. |
| 18:04.33 | JeffM | and each message buffer is dynamicly resizing ( in chunks for speed ). |
| 18:05.12 | brlcad | sure, the nature of passing fixed buffers around, but that was intentional (and pretty efficient) .. I'd be worried about a full-on conversion to std::string, could be horribly inefficient without a sanity profile |
| 18:05.15 | JeffM | it'll add a little bit of CPU load ( more memory allocation/deallocation ) to our network stuff, but the advantage of being able to thread it out outwieghts that. |
| 18:05.33 | JeffM | brlcad: that's why I'm looking at how they are used. |
| 18:06.34 | brlcad | i mean, dynamic buffers are great -- i like the change -- but would be very worried about the impact of that one |
| 18:06.36 | JeffM | the problem I have with the normal string pack is you have to know how big the string is. |
| 18:07.06 | JeffM | brlcad: yes, it'll need testing |
| 18:07.18 | JeffM | and probalby some optimisation |
| 18:07.18 | brlcad | one of the subtlties that the server is doing millions of times over, inject just one or two new copies in there and the server is doing 2+X the amount of work overall |
| 18:08.09 | JeffM | posibly, but I don't know if we can find out the impact untill we try :) |
| 18:08.32 | JeffM | since its' all cenralised now, if we had to go back to fixed buffers, or maybe a fixed buffer pool, we can, it'd just be done in one place now |
| 18:08.47 | brlcad | would need a profile of a few test-cases before and after |
| 18:09.02 | JeffM | it would be easy to change it from doing an alloc per message to pulling from a buffer pool. the end API would stay the same |
| 18:09.46 | JeffM | so I think we can acomodate ether case ( if the current mechanism is too slow ) |
| 18:09.55 | strayer | JeffM: ...I changed the script so that it permanently filters given names (in an array) and fixed the bugs (I think)... |
| 18:10.03 | JeffM | cool |
| 18:10.53 | strayer | about loading the callsigns that have to be filtered: there are different ways, but actually the names are hardcoded in this file... |
| 18:11.39 | JeffM | brlcad: I could write up a #def option that has it pull from say a round robbin of preallocated buffers, and adds more if needed, if you'd like to compare the methods. |
| 18:11.41 | strayer | it's not a big deal to load them form a db table or from a text file, but as I said, an webinterface just for maintaining these unwanted names isn't worth it |
| 18:12.17 | JeffM | strayer: and as I said, whatever your willing to do. |
| 18:13.11 | strayer | ok...then I'ld say you can use it as it is :o) |
| 18:13.51 | brlcad | JeffM: I don't think that'd be necessary until it was profiled before and after with a regression test to see that it was a problem |
| 18:14.34 | brlcad | but that doing the test before and after is really important, instead of change and see who complains .. that's not something that would be readily caught by simple testing |
| 18:15.14 | brlcad | it'd be a matter of a server that could run 10 bzfs's concurrently would now only handle 3 kind of potential hit |
| 18:15.39 | strayer | blast007 are you still around? |
| 18:15.55 | blast007 | strayer: yup |
| 18:16.08 | JeffM | I don't think it will be that bad |
| 18:16.11 | JeffM | but we can see |
| 18:16.22 | JeffM | as I said, we can change the backend now prety easy |
| 18:16.33 | strayer | could you upload the modified file again with the same name when I send it to you? |
| 18:16.36 | brlcad | the backend isn't the concern |
| 18:16.59 | brlcad | it's all the N calls through all the layers in the server that lead to the back end |
| 18:17.00 | JeffM | the backend is the part that does the allocation |
| 18:17.13 | JeffM | oh it's the same number of fuction calls |
| 18:17.25 | brlcad | not what I'm saying |
| 18:17.49 | strayer | blast007: could you upload the modified file again with the same name when I send it to you? |
| 18:17.51 | brlcad | same N, but now the cost of N is different potentially |
| 18:17.56 | blast007 | sure |
| 18:17.59 | JeffM | if we made it use a static buffer on the back end, it'd be the same CPU use as the old way |
| 18:18.01 | brlcad | passing around std::string's |
| 18:18.01 | strayer | ok :o) |
| 18:18.19 | JeffM | oh i'd not pass around standar strings, no no no |
| 18:18.35 | JeffM | right now we pass in a char * |
| 18:18.39 | JeffM | it's copied to the buffer |
| 18:18.56 | JeffM | I want to pass in a std::string ref, and copy it to the buffer |
| 18:19.01 | brlcad | technically, it's a char[] somewhere higher up, but yeah -- passed around as a pointer to a MessageBufLen buf |
| 18:19.02 | JeffM | with it's len |
| 18:19.15 | JeffM | I'm NOT CHANGING the buffer to a std::string |
| 18:19.20 | JeffM | I think we are out of sync |
| 18:19.37 | JeffM | I'm talking about how we FILL that buffer with string data |
| 18:19.55 | DTRemenak | brlcad: as far as testing, use a packet sniffer to record all the network traffic on a busy server. then you have a pool of data (incoming traffic) and a test baseline (outgoing traffic) all set up. keep track of cpu usage in the middle if that's a concern. |
| 18:20.49 | JeffM | basicly the only change will be that we copy and pack in an extra unit for the lenght |
| 18:21.07 | DTRemenak | also insures that no packets got broken |
| 18:21.24 | JeffM | instead of assuming a fixed size string that we pack into the message buffer |
| 18:21.48 | JeffM | oh it breaks protocoll ;) |
| 18:22.01 | strayer | blast007: email is coming to you..bit by bit ;o) |
| 18:22.25 | DTRemenak | then transform the data before you use it again |
| 18:22.37 | DTRemenak | still catches unintentional changes |
| 18:25.01 | brlcad | DTRemenak: I was thinking something more along the lines of metrics that bzfs could actually keep track of, self-profiling for given usage test cases |
| 18:25.25 | DTRemenak | gprof ;) |
| 18:25.30 | brlcad | similar to the opengl self-checks the client has, but more book-keeping |
| 18:25.48 | DTRemenak | the gl self-checks are just yes/no sorts of things, right? |
| 18:26.00 | DTRemenak | I think we'd need a more comprehensive test |
| 18:26.42 | brlcad | gprof goes too granular, and you have to have a specific compile/run -- i'm thinking something higher level like having the server say "for this run, I used N hours of cputime and N hours of wallclock, received N bytes, transferred N bytes |
| 18:27.11 | brlcad | then you can have automated client connectsions and can start looking after overall overhead problems that might come up |
| 18:27.16 | DTRemenak | we already to recd/txd |
| 18:27.29 | DTRemenak | s/to/do/ |
| 18:27.39 | brlcad | yes, but not the fixed test cases |
| 18:27.46 | brlcad | and not the cpu timings iirc |
| 18:27.52 | DTRemenak | that's why you have a fixed data set |
| 18:28.12 | DTRemenak | essentially provides test coverage for the entire server, instead of just little chunks |
| 18:28.22 | brlcad | what do you mean by "fixed data set"? |
| 18:28.33 | JeffM | I'm still trying to figure out what extra std::string you think I'm shufflin around? |
| 18:29.20 | DTRemenak | see my first comment...use a recorded traffic set from a real server. then you don't need any "automated client connection" or anything, just play it back |
| 18:29.48 | DTRemenak | and the server's behavior can be checked against the original output |
| 18:30.44 | blast007 | DTRemenak: that's assuming the protocol between the two is the same |
| 18:30.45 | blast007 | 12:18:45 < JeffM> oh it breaks protocoll ;) |
| 18:30.53 | DTRemenak | <DTRemenak>then transform the data before you use it again |
| 18:30.58 | JeffM | yeah he said that |
| 18:31.02 | JeffM | the break is minimal |
| 18:31.18 | blast007 | k |
| 18:31.20 | DTRemenak | you know the old packet format, you know the expected new packet format |
| 18:31.26 | DTRemenak | it's pretty trivial to fix it iup |
| 18:31.36 | brlcad | assuming the change was trivial |
| 18:31.46 | JeffM | well as it sits right now, it'll be the same proto if you don't have too many flags ;) |
| 18:31.52 | DTRemenak | correct, if there's new data it won't work to do that ;) |
| 18:31.54 | brlcad | not much harder to have real clients connect, would seem easier to me actually |
| 18:32.08 | DTRemenak | real clients won't give consistent network traffic though |
| 18:32.13 | brlcad | real non-graphical at least, maybe put the bots to work |
| 18:33.11 | brlcad | it won't be consistent latencywise, but it should be pretty close quantity-wise -- if it's not, the RX on the server should reflect a change |
| 18:33.48 | DTRemenak | if you're worried about the server getting slower, you have to make sure the timing is consistent |
| 18:34.39 | DTRemenak | or else manually instrument the server, which I wouldn't want to put the effort into |
| 18:37.05 | brlcad | it wouldn't need to be consistent for the overall-cpu-usage checking I'm thinking of -- i'm concerned about order of magnitude sized changes, given how lightweight the server (still) is |
| 18:37.32 | brlcad | drastic changes to the TX, RX, and cputime mostly |
| 18:37.53 | brlcad | it's going to get heavier, that's a given with more state moving |
| 18:39.07 | brlcad | doesn't have to be packet for packet exact -- if the server were that unstable to simple out-of-orderings, we'd have bigger problems to worry about |
| 18:39.19 | *** join/#bzflag TD-Linux (n=wheeeeee@24-159-201-122.dhcp.roch.mn.charter.com) |
| 18:40.38 | brlcad | JeffM: i'm not sure what you're actually doing now, I've understood you saying two or three different things now, so I'll just wait to see the commits I guess |
| 18:41.16 | JeffM | brlcad: yeah I think we got crossed |
| 18:41.24 | *** join/#bzflag Djpenguin (n=David@adsl-216-102-90-233.dsl.snfc21.pacbell.net) |
| 18:41.38 | JeffM | I'm not going to shuffle around any strings by value or anything |
| 18:41.43 | JeffM | that'd be silly :) |
| 18:41.45 | brlcad | i think it's just an overall desire to be just a little more cautious, uneasy with massive changes particularly to the proto that go untested -- they tend to fester and become hard as hell to debug later |
| 18:42.04 | JeffM | mayhaps |
| 18:42.20 | JeffM | is it our eventual goal to have a networking thread? |
| 18:42.46 | brlcad | wow, is that another major topic or what :) |
| 18:43.41 | JeffM | well part of what I am doing is trying to get us closer to being able to do that |
| 18:43.44 | brlcad | but yeah, I'd like to see the client and server go multithreaded eventually |
| 18:43.45 | JeffM | not that I'm doing that |
| 18:43.47 | JeffM | ok |
| 18:44.04 | JeffM | then what I am doing is hopefully trying to get closer to that goal |
| 18:44.10 | brlcad | async loops for network, graphics, and game simulation loop |
| 18:44.30 | JeffM | yeah I'm trying to get all the network data setup in a nice way that can be processed in an async loop |
| 18:44.52 | JeffM | the string change is basicly just a small change in how we pack strings |
| 18:45.11 | JeffM | instead of packing a fixed chunk of data, I want to pack the actual string data and the lenght |
| 18:45.28 | JeffM | makes the protocoll more adaptive to size changes |
| 18:46.12 | brlcad | that part I got and have little concern with |
| 18:46.20 | JeffM | why? |
| 18:46.29 | JeffM | both are still a copy into a buffer |
| 18:46.38 | brlcad | I mean I'm not really worried about that |
| 18:46.45 | JeffM | ahh ok |
| 18:46.53 | JeffM | then yeah that's all I got |
| 18:47.10 | JeffM | I don't have the network messages growing each time somone adds a byte to them |
| 18:47.21 | brlcad | only concern would be the change from fixed buffer lengths less than the mtu to tcp segments that might potentially get broken up |
| 18:47.22 | JeffM | I do have MORE network messages |
| 18:47.37 | JeffM | ahh |
| 18:47.39 | brlcad | but then that can be managed from this sender |
| 18:47.45 | JeffM | yeah only one message can do that now |
| 18:47.53 | JeffM | the flag send |
| 18:48.00 | JeffM | and yes we can break it up |
| 18:48.11 | brlcad | and chat messages if you make them variable length |
| 18:48.22 | JeffM | didn't change those |
| 18:48.32 | JeffM | wasn't going to, was just gonna change how they are packed |
| 18:49.07 | JeffM | but I must go |
| 18:49.37 | *** join/#bzflag wanda (n=coredump@p54999794.dip0.t-ipconnect.de) |
| 18:50.31 | wanda | rehello brlcad ... |
| 18:51.23 | wanda | do you know wheteer JeffM has finished his changes to the messaging system? |
| 18:51.50 | brlcad | which changes specifically? |
| 18:52.08 | brlcad | the migration to the new buffered message sender? |
| 18:52.19 | DTRemenak | try back next year for that |
| 18:52.23 | wanda | the last changes ..:-) mom ..will have to look for |
| 18:52.25 | rtfm | hehe |
| 18:52.25 | Thumper_ | heh |
| 18:52.35 | DTRemenak | what, that's only like 2 weeks :) |
| 18:53.03 | Thumper_ | wanda: we'll eventually clean up the debug build compile warnings when things settle a bit |
| 18:53.05 | rtfm | moment* |
| 18:53.55 | wanda | changes up from rev 16287 up to current |
| 18:54.55 | DTRemenak | so yeah, buffered net messages. like I said, come back next year :) |
| 18:55.49 | wanda | :-(( .... i dond understand my compiler any more, complaining about classes, potential errors points ... :-(( |
| 18:56.31 | wanda | ok, will wait for a better year :-) |
| 19:00.02 | *** join/#bzflag QuantumBeep (n=QuantumB@doc-72-47-73-208.leesville.la.cebridge.net) |
| 19:14.56 | *** join/#bzflag Wits (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 19:26.01 | *** join/#bzflag rob1n (n=rob1n@unaffiliated/rob1n) |
| 19:57.39 | Winny | hmm |
| 19:57.56 | Winny | I have my bases defined, but BZFS says no red base is defined o.O |
| 19:58.42 | *** join/#bzflag SpazzyMcGee (n=Spazzy_M@unaffiliated/spazzymcgee) |
| 19:59.08 | Thumper_ | Winny: you have red players but no red base? |
| 19:59.44 | Winny | no, they're both there |
| 19:59.58 | Winny | but BZFS errors when I try to start now |
| 20:03.25 | F687s | if you remove red players and red base, does it show blue base? |
| 20:08.07 | Winny | hmm |
| 20:08.17 | Winny | it's something to do with one of my meshes o.O |
| 20:09.53 | SpazzyMcGee | winny: what's your problem? |
| 20:10.10 | Winny | SpazzyMcGee: I think I may have found it |
| 20:10.30 | Winny | for some reason blender exported a few of the normals with "normal INDO INDO INDO" |
| 20:10.35 | SpazzyMcGee | heh |
| 20:13.22 | SpazzyMcGee | hmph. I'm stuck for map ideas. Haven't had a good idea for months. |
| 20:15.42 | blast007 | make a penis map... oh wait, you already did one of those |
| 20:15.50 | blast007 | ~ww |
| 20:15.50 | ibot | Can I get a woot woot? |
| 20:16.56 | Winny | blast007: nice :p |
| 20:17.02 | blast007 | >.< |
| 20:17.20 | blast007 | Edit > Undo isn't working |
| 20:19.34 | whodaman- | lol |
| 20:25.00 | spldart | I've always wondered.... would it be productive to make a way to submit all your server logs in a common log that then allows access to all IP>tankername for the last umpteen months/years... In order to better attach names to troublemakers. |
| 20:25.43 | spldart | Maybe only dev's would have that 'master' information and then could reference it occassionaly when a real problem ip comes up |
| 20:27.57 | F687s | it depends if the data could be quickly searched and identified. |
| 20:33.20 | *** join/#bzflag kick52 (n=kick52-i@91.108.201.244) |
| 20:33.23 | kick52 | hello |
| 20:33.33 | kick52 | anyway to set the time of day? |
| 20:35.02 | catay | kick52: a fixed time in the bzflag client ? |
| 20:35.22 | catay | kick52: so it doesnt get dark anymore? |
| 20:35.48 | blast007 | kick52: you can use the + and - keys at the top of the keyboard to adjust the time of day |
| 20:35.48 | kick52 | so it doesn't get day anymore |
| 20:35.52 | kick52 | ah thanks |
| 20:36.03 | blast007 | but there is probably a way to hard code it as well |
| 20:36.03 | catay | kick52: or put 'set fixedTime 00:00:00' or something in your conf |
| 20:36.04 | kick52 | because i can't see the radar as well in the day |
| 20:36.09 | kick52 | nice thanks |
| 20:38.07 | kick52 | and anyway to turn off the mousebox, but still have the glass crack thing big? |
| 20:39.31 | *** join/#bzflag AAA_Awright (n=AAA_awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 20:41.44 | *** join/#bzflag Warinthestar (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
| 20:47.18 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 20:59.40 | F687s | what do you think the chances are of getting bzflag to work on reactos? |
| 21:05.23 | kick52 | high |
| 21:05.31 | kick52 | i'm really high |
| 21:05.41 | kick52 | and so are your chances |
| 21:06.01 | kick52 | you could always wine it if you can't get it native right? |
| 21:07.43 | kick52 | burb |
| 21:30.43 | *** join/#bzflag Djpenguin (n=David@adsl-216-102-90-233.dsl.snfc21.pacbell.net) |
| 21:50.55 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 21:50.55 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 22:07.11 | *** join/#bzflag JeffM (n=Jeff@pool-71-109-219-226.lsanca.dsl-w.verizon.net) |
| 22:10.13 | *** join/#bzflag kick52 (n=kick52-i@91.108.201.244) |
| 22:42.58 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-063-254.pools.arcor-ip.net) |
| 23:13.31 | *** join/#bzflag sigonasr2 (i=sigonasr@ip72-200-88-154.tc.ph.cox.net) |
| 23:19.41 | *** join/#bzflag sigonasr (i=sigonasr@ip72-200-88-154.tc.ph.cox.net) |
| 23:40.41 | JeffM | L4m3r: have you sent a message to -shadow- ? |
| 23:40.51 | L4m3r | no |
| 23:41.00 | L4m3r | I figure you're the expert in that department |
| 23:41.05 | JeffM | gee thanks :) |
| 23:41.06 | L4m3r | I haven't done anything yet |
| 23:41.10 | L4m3r | :P |
| 23:41.22 | JeffM | how strongly do you feel the info is correct? |
| 23:41.24 | L4m3r | feel free to define a procedure if you like |
| 23:41.36 | JeffM | ban them |
| 23:41.39 | JeffM | ban them into the ground |
| 23:41.42 | JeffM | then ban the ground |
| 23:41.47 | L4m3r | I don't know... wasn't there a previous issue with that person? |
| 23:41.59 | JeffM | checking |
| 23:42.01 | spldart | Oh my |
| 23:42.11 | L4m3r | in the GU section I think |
| 23:42.23 | JeffM | *shadow* i had issues with it |
| 23:42.56 | JeffM | -shadow- has 110 posts :( |
| 23:43.18 | L4m3r | oh, it was *shadow* |
| 23:43.20 | L4m3r | whoops |
| 23:43.36 | JeffM | -shadow- is 11? or *shadow* ? |
| 23:43.38 | L4m3r | hey, I'm glad he had SOME posts- IPs to compare |
| 23:43.38 | JeffM | stupid names |
| 23:43.39 | L4m3r | no matches |
| 23:43.41 | L4m3r | *shadow* |
| 23:43.48 | whodaman- | It's *shadow* L4m3r |
| 23:43.52 | JeffM | you sure? |
| 23:44.02 | L4m3r | yeah, fixing post now |
| 23:44.02 | JeffM | cus I'll belive that *shadow* is |
| 23:44.03 | whodaman- | JeffM, as of 2 months ago he was 11 |
| 23:44.08 | JeffM | ok thanks |
| 23:44.12 | whodaman- | Positive |
| 23:44.23 | JeffM | cus that just makes him AWESOME |
| 23:44.29 | L4m3r | and of those 110 posts, there are no matches between the two |
| 23:44.41 | L4m3r | for IPs, that is |
| 23:44.41 | JeffM | for geting all pissed at me for cacking the account of LOLZ for the same reason |
| 23:44.57 | Winny | oh god |
| 23:45.05 | JeffM | yeah |
| 23:45.06 | Winny | LOLZ/KILLER1/YOUR DEAD is back again? |
| 23:45.10 | JeffM | no |
| 23:45.12 | JeffM | read all words |
| 23:45.24 | Winny | "for cacking the account of LOLZ for the same reason" |
| 23:45.36 | JeffM | yeah lolz was deleted |
| 23:45.41 | L4m3r | YOUR DEAD is older than that... at least I hope so |
| 23:45.41 | JeffM | he got all pissed at me |
| 23:45.52 | JeffM | even after I explained why |
| 23:45.57 | Winny | L4m3r: they're the same person |
| 23:46.17 | L4m3r | we should hit up blast007 to add a registration IP address to BZBB |
| 23:46.28 | L4m3r | it's really irritating to not have an IP for users who don't post |
| 23:46.49 | JeffM | whodaman-: where did you see this info that he is 11? |
| 23:46.59 | whodaman- | Warinthestar, sigonasr2 ping |
| 23:47.09 | whodaman- | JeffM, on the cruelmania forums |
| 23:47.15 | whodaman- | and because he told me so |
| 23:47.26 | whodaman- | and so did 20 other people |
| 23:47.27 | JeffM | ok |
| 23:47.28 | Winny | ..and possibly because he acts like it? :p |
| 23:47.36 | JeffM | that I'll belive :) |
| 23:47.44 | JeffM | but I just have to have all my ducks in a row, ya know |
| 23:47.44 | whodaman- | JeffM, no kidding |
| 23:47.55 | whodaman- | heh |
| 23:48.28 | JeffM | we ARE talking about account deletion here. |
| 23:48.44 | whodaman- | JeffM, IIRC there were other people under 13 on those forums |
| 23:48.56 | JeffM | very possible |
| 23:49.09 | whodaman- | on those forums means also on bzbb |
| 23:49.11 | JeffM | all I care about is the ones that I get told about on bzbb |
| 23:49.24 | JeffM | if no admin knows, we are not liable |
| 23:49.41 | L4m3r | funny thing is, if they're on cruelmania, then CD is probably liable |
| 23:49.47 | JeffM | an admin knows for *shadow* so I have to care :) |
| 23:50.03 | JeffM | it's like shrodengers n00b ;) |
| 23:50.04 | Winny | L4m3r: he has some free board, so, actually, wouldn't the host(er) be liable? |
| 23:50.04 | whodaman- | JeffM, the thread was something like "ages" or something like that |
| 23:50.05 | L4m3r | oh god, it's one of those crappy free forum hosts |
| 23:50.19 | whodaman- | Winny, that's Gnurdux |
| 23:50.29 | whodaman- | err |
| 23:50.30 | Winny | I really don't get why people can't pay 2-5$ for a month for FTP somewhere |
| 23:50.50 | Winny | so much nicer then having 1000 free crappy hosts everywhere |
| 23:51.02 | whodaman- | cause they know their server isn't worth it |
| 23:51.50 | L4m3r | whodaman-: well put, lol |
| 23:52.05 | whodaman- | ;) |
| 23:52.12 | L4m3r | I paid for a cheap webhost for two years... it does everything I need, and then some |
| 23:52.19 | JeffM | he's been notified and yoinked |
| 23:52.41 | Winny | ~boot *shadow* |
| 23:52.42 | ibot | ACTION inconspicously shuffles over to get a straight line across *shadow* to the window above the dumpster, takes aim, and punts *shadow* out to where he belongs! |
| 23:55.22 | Winny | ooh, I just ran into this again http://trepan.bzflag.bz/noshow/varied_fountain.jpg |
| 23:55.36 | Winny | that sure would have been a nice feature :) |
| 23:56.26 | sigonasr2 | wow, nice |
| 23:58.36 | JeffM | gotta love shaders |
| 23:59.05 | Winny | I think you guys should buy the crytek engine for BZ ;) |
| 23:59.27 | JeffM | you want to kill the project that much? |
