| 00:00.00 | fiberchunks | lol :) |
| 00:00.03 | doughecka | see? |
| 00:00.09 | learner | beer and cohesive thought, they do not |
| 00:00.11 | learner | :) |
| 00:00.43 | doughecka | You clever are not drunk you! when |
| 00:00.45 | fiberchunks | what? the flarn morphised upon the twaddle -- but by outright dendrition, several floogmasties did spindle |
| 00:02.05 | fiberchunks | if anyone is irritated by my shenanigans, or lack of coherent topic, tell me to shut up, and I'll oblige :) |
| 00:02.06 | captain_proton | hrm |
| 00:02.09 | JBDiGriz | Here's a web site that has a wonderful title for learner and fiberchunks, but the content doesn't apply. http://www.fys.uio.no/~eaker/thesis/node10.html |
| 00:02.11 | captain_proton | caligari's web site is being cranky |
| 00:02.22 | captain_proton | ah, there we go |
| 00:03.54 | fiberchunks | JBDiGriz> lol -- I exhibit "imbibition at low injection rate" and my pores are being invaded :) |
| 00:04.19 | captain_proton | hmm |
| 00:04.26 | captain_proton | i had forgotten how damn cool the caligari interface is |
| 00:04.32 | learner | cap make it home? |
| 00:04.33 | fiberchunks | truespace? |
| 00:05.17 | captain_proton | fiberchunks: yep |
| 00:05.55 | fiberchunks | those are some gorgeous images -- wow |
| 00:06.26 | captain_proton | scanline got me wanting to not use any real widgets at all |
| 00:06.32 | captain_proton | and make the interface completely 3d |
| 00:06.48 | fiberchunks | how? without widgets? |
| 00:06.49 | Mayhem | captain_proton: that would be cool |
| 00:07.04 | captain_proton | fiberchunks: all the "widgets" are in the scene |
| 00:07.17 | Mayhem | like the cube 3d shooter, you can edit the levels in-game |
| 00:07.18 | captain_proton | there would of course be -some- text output |
| 00:07.50 | fiberchunks | later on JBDiGriz |
| 00:07.55 | learner | later jb |
| 00:08.20 | fiberchunks | mmm, weird to me -- example linkage? |
| 00:08.24 | captain_proton | plus it would give me a nifty area of interest to maybe get paid as a research assitant at the viz center >:) |
| 00:08.37 | captain_proton | http://caligari.com/Help/Tutorials/Saul_Greenberg/default.asp?Cate=HTutorials <-- read about the world navigation "widget" |
| 00:08.44 | captain_proton | image 4+ |
| 00:08.49 | fiberchunks | thx |
| 00:09.08 | fiberchunks | ah, ic now |
| 00:09.38 | captain_proton | its such a neat interface |
| 00:10.05 | fiberchunks | yes, it is -- now do images 10-13 qualify as 'widgets'? |
| 00:10.21 | captain_proton | so completely unlike everything else, but usable immediately with a little experiementation |
| 00:10.27 | captain_proton | yes, those would |
| 00:10.41 | captain_proton | we'd be taking it a bit further |
| 00:10.58 | fiberchunks | that would be very cool -- I like it -- never used anything like it, that's for sure |
| 00:10.59 | captain_proton | where even things like the save button are part of the scene somehow |
| 00:11.21 | *** join/#bzflag Patlabor221 (~jeffm@adsl-64-172-197-186.dsl.lsan03.pacbell.net) |
| 00:11.21 | *** mode/#bzflag [+o Patlabor221] by ChanServ |
| 00:11.30 | fiberchunks | ssshhhhhh, he's here ;) |
| 00:11.35 | captain_proton | hehe |
| 00:11.40 | captain_proton | don't worry, it'll run on windows |
| 00:11.42 | captain_proton | >:) |
| 00:11.45 | fiberchunks | lol |
| 00:11.58 | Patlabor221 | ohh good, does this mean I don't have to update it anymore? |
| 00:12.02 | Patlabor221 | cus that would be cool |
| 00:12.12 | fiberchunks | heh, the trepan 'fixes'? |
| 00:12.18 | captain_proton | well - this one probably won't appeal to people who don't like unfamiliar UIs |
| 00:12.30 | Patlabor221 | is it ugly? |
| 00:12.44 | captain_proton | well nothing is written yet |
| 00:12.52 | captain_proton | and it probably will look really good |
| 00:12.53 | Patlabor221 | will it be ugly? |
| 00:13.01 | captain_proton | it'll just be strange |
| 00:13.02 | Patlabor221 | will it be more sexy then usefull? |
| 00:13.11 | captain_proton | perhaps |
| 00:13.13 | Mayhem | captain_proton: you could make an in-game editor |
| 00:13.28 | Patlabor221 | see that's why students should not design apps :) |
| 00:13.32 | captain_proton | Mayhem: eh - i don't want to deal with bzflag's existing rendering engine |
| 00:13.37 | Patlabor221 | code it up mayhem :) |
| 00:13.49 | Mayhem | captain_proton: but it will at least look right :) |
| 00:14.07 | Patlabor221 | the current stuff in the windows editor should "look right" |
| 00:14.07 | captain_proton | i can make it look right without a painful architecture |
| 00:14.28 | Patlabor221 | cap when is your target date? after pybz is rendering stuff? |
| 00:15.14 | captain_proton | ideal would be that i'd have something usable (but certainly nowhere-near feature complete) in a week and a half or so |
| 00:15.24 | captain_proton | so i can play with it at the viz-center open house |
| 00:15.25 | Patlabor221 | ahh cool |
| 00:15.40 | fiberchunks | is this for bzedit.py? |
| 00:15.40 | Patlabor221 | fun |
| 00:15.41 | *** join/#bzflag Legolas (~Legolas@adsl-68-73-89-127.dsl.emhril.ameritech.net) |
| 00:15.53 | captain_proton | yyyyep |
| 00:15.57 | Patlabor221 | I'm gonna add one more feature to BZEdit then probably call it quits |
| 00:15.58 | fiberchunks | neat |
| 00:16.35 | captain_proton | Patlabor221: yeah, i'm well past that point |
| 00:16.46 | fiberchunks | my kid is giving me a dissertation on Basilisks ;) |
| 00:16.46 | captain_proton | but this gives me a chance to play with nifty interfaces |
| 00:16.47 | Patlabor221 | I know |
| 00:16.51 | Patlabor221 | yes |
| 00:16.55 | captain_proton | without having to answer to users |
| 00:17.09 | Patlabor221 | I thought about making a scrawl editor for BZ |
| 00:17.29 | Patlabor221 | this last one is so that all those people out there that have there little mini apps can put them into the editor |
| 00:17.35 | *** join/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 00:18.09 | Patlabor221 | then if they want something they can write it :) |
| 00:18.26 | Patlabor221 | and not have to touch MFC if they don't wana |
| 00:18.59 | fiberchunks | oh, the plugin interface? |
| 00:19.32 | Patlabor221 | yeah |
| 00:20.26 | Patlabor221 | what ya drinkin? |
| 00:20.39 | sussudio | video head cleaner fluid? |
| 00:20.41 | fiberchunks | beer -- but tequila may be in order soon |
| 00:20.54 | fiberchunks | and if I run out of tequila, vhs cleaner fluid |
| 00:21.13 | Patlabor221 | how large should I make a linux swap partition? |
| 00:21.17 | sussudio | the tape that comes with it actually is better than most tv programs |
| 00:21.39 | fiberchunks | Patlabor221> 2x RAM used to be the norm |
| 00:21.45 | sussudio | Patlabor221: 1 MILLION MEGABYTES! |
| 00:22.05 | Patlabor221 | so 2 gigs? |
| 00:22.23 | fiberchunks | sure -- if you got a Gig, I highly doubt you'll ever need swap |
| 00:22.27 | sussudio | hell, mine is 128MB and i don't ever see swap being used. |
| 00:22.34 | Patlabor221 | I'll do a gig |
| 00:22.37 | Patlabor221 | it's a 27 gig drive |
| 00:22.43 | fiberchunks | nor I -- I've 1G for 1G |
| 00:23.10 | learner | heck 64k ram was cool |
| 00:23.22 | fiberchunks | hence the _used to be the norm_ I've no idea what it is now that everyone has 1G ram or so |
| 00:23.37 | Patlabor221 | it is only for the lin machine, I'll leave the win machiene at a gig and a half |
| 00:23.53 | learner | uh oh.. outta beer |
| 00:23.57 | fiberchunks | win is a different animal entirely, and I am unqualified to judge |
| 00:24.00 | fiberchunks | oooo |
| 00:24.22 | fiberchunks | and shuffles off to get another himself |
| 00:24.51 | Patlabor221 | I got an aditional 30 gig drive for BFOJ if we need it too |
| 00:24.57 | fiberchunks | sweet |
| 00:25.15 | fiberchunks | I've gotta get more upload -- 128 k just don't cut it anymore :\ |
| 00:25.53 | Patlabor221 | you look at the speakeasy stuff? |
| 00:26.07 | *** join/#bzflag bzgirl (~brat@toronto-hs-64-26-176-100.s-ip.magma.ca) |
| 00:28.23 | fiberchunks | Patlabor221> no, not yet -- been a hellish week thus far, hence the drunkenness |
| 00:29.31 | Patlabor221 | at least your not the anit-linux |
| 00:30.39 | fiberchunks | dammit, why do people feel the need to tell you something in flash that could very easily be done in text, fer chrissakes :\ (i.e. speakeasy service locator) |
| 00:31.19 | bzgirl | Patlabor221: no luck? |
| 00:31.36 | Patlabor221 | it's just hanging at a gray screen |
| 00:33.47 | sussudio | fiberchunks: because they're assholes? |
| 00:34.24 | fiberchunks | sussudio> *nod* -- thank you for inciting my anger :) |
| 00:34.46 | bzgirl | you guys all getting drunk? |
| 00:35.00 | doughecka | bzgirl: join in |
| 00:35.03 | bzgirl | this should be interesting |
| 00:35.06 | learner | hehe, :) |
| 00:35.06 | fiberchunks | I am, and learner as well, it seems :) |
| 00:35.49 | bzgirl | doughecka:no thanks :) |
| 00:36.00 | fiberchunks | ha! and now the movie won't play -- isn't that special |
| 00:36.11 | learner | movie? |
| 00:36.27 | Patlabor221 | special? |
| 00:36.28 | fiberchunks | for this speakeasy 'check' to see if their service is avail in my area |
| 00:36.40 | doughecka | this is annoy-fiberchunks-week isnt it? |
| 00:37.02 | fiberchunks | no, just fiberchunks-gets-annoyed-with-stupid-websites day, it seems |
| 00:37.10 | doughecka | ah |
| 00:37.45 | fiberchunks | ah, my child has informed me that the basilisk is dead -- due to Potters superior sword skills ;) |
| 00:38.19 | doughecka | Wheres potters Tube? |
| 00:42.50 | captain_proton | sheesh |
| 00:42.55 | captain_proton | pybzflag is almost rediculously simple |
| 00:43.10 | learner | heh, hidden black box |
| 00:45.48 | *** join/#bzflag bryjen (1000@ky-owensboro1a-242.owboky.adelphia.net) |
| 00:47.09 | *** join/#bzflag JBDiGriz (~JBDiGriz@adsl-63-204-118-6.dsl.sndg02.pacbell.net) |
| 00:47.26 | fiberchunks | lol |
| 00:47.38 | learner | my ear! |
| 00:47.50 | sussudio | just one ear? |
| 00:47.57 | learner | I was scratching the other |
| 00:48.13 | sussudio | how do you start pybzflag? just ./observer.py ? |
| 00:48.24 | learner | iirc, sussudio, yes |
| 00:48.31 | sussudio | it wants a server |
| 00:48.40 | fiberchunks | -ssomeserver:port |
| 00:48.42 | captain_proton | so give it a server |
| 00:48.44 | learner | well you have to feed it the right args |
| 00:48.47 | captain_proton | --help is your friend |
| 00:49.03 | sussudio | i thought --version was |
| 00:49.09 | learner | nope |
| 00:49.17 | sussudio | hm no available video device |
| 00:49.18 | fiberchunks | ooooo, I am hoping that the feeling for a rabbit hunt will develop throughout the evening ;) |
| 00:49.27 | sussudio | i thought it ran from console |
| 00:49.44 | fiberchunks | are there X hooks? |
| 00:50.14 | captain_proton | sussudio: umm...observer implies that you can observe the game |
| 00:50.16 | captain_proton | therefore it has a UI |
| 00:50.32 | sussudio | curses? |
| 00:50.37 | captain_proton | no |
| 00:50.38 | captain_proton | 2d overhead |
| 00:50.52 | fiberchunks | learner> you're listening to a pie? ;) |
| 00:50.54 | sussudio | wants X? |
| 00:50.59 | captain_proton | yes |
| 00:51.03 | sussudio | snort. |
| 00:51.06 | learner | no, hispanic music :) |
| 00:51.15 | fiberchunks | hehe, I know |
| 00:51.27 | captain_proton | there are programs in there that don't require X |
| 00:51.31 | captain_proton | but observer does |
| 00:53.33 | fiberchunks | must emerge pygame |
| 00:53.41 | learner | so, cap.. I don't have X yet I could run it.. |
| 00:53.57 | fiberchunks | were you running some non-X module? |
| 00:54.08 | learner | yea.. something like that |
| 00:54.12 | learner | os x |
| 00:54.16 | learner | :) |
| 00:54.19 | fiberchunks | heh |
| 00:54.40 | learner | had to install a custom python module, though |
| 00:54.52 | learner | scanline insists on using a lot of modules and recent code :) |
| 00:54.53 | captain_proton | well everyone does |
| 00:54.59 | captain_proton | because it uses pygame |
| 00:55.11 | fiberchunks | yes, that's what I'm having to emerge now |
| 00:56.14 | fiberchunks | ./chat.py -sbrlcad.org -v <<<< this is not liked |
| 00:56.29 | learner | I'm not running on 5155 |
| 00:56.35 | learner | try brlcad.org:4242 |
| 00:56.36 | fiberchunks | ah, port spec |
| 00:57.06 | fiberchunks | ./chat.py -sbrlcad.org:4242 -v <<<< dies as well |
| 00:57.30 | sussudio | learner: it's called "summer" |
| 00:57.33 | fiberchunks | ah, it's working now |
| 00:58.02 | fiberchunks | someone join brlcad:4242 and tell me if they see my messages |
| 00:58.33 | fiberchunks | wow -- this is very cool work scanline has done |
| 00:58.54 | learner | don't tell him, he's already got a big head for his python work ;) |
| 00:59.05 | fiberchunks | :) he does good work though :) |
| 00:59.19 | captain_proton | hehe |
| 00:59.37 | captain_proton | scanline has a tendency to pump out very good code |
| 00:59.48 | captain_proton | and a lot of it =) |
| 01:00.20 | captain_proton | you're not doing --view, are you? |
| 01:00.29 | fiberchunks | oh that is very cool |
| 01:00.42 | learner | ah, got it to work, eh? |
| 01:00.45 | fiberchunks | yessir |
| 01:00.54 | fiberchunks | with the above mentioned line too |
| 01:01.04 | fiberchunks | @PyBzflag: FOO! |
| 01:01.07 | fiberchunks | :) |
| 01:01.14 | learner | fiber: http://brlcad.org/tmp/observer.png |
| 01:01.28 | sussudio | i did -v |
| 01:01.33 | fiberchunks | well, how the hell do I stop the thing now :) |
| 01:01.50 | fiberchunks | prob shouldn't chat as root though :\ |
| 01:01.51 | learner | heheh, scanline needs to add better control code :) |
| 01:02.17 | fiberchunks | what WM is that learner |
| 01:02.18 | learner | my processors end up way over-utilized |
| 01:02.27 | learner | os x |
| 01:02.34 | fiberchunks | heh, duh ;) |
| 01:02.56 | captain_proton | sussudio: well that was silly |
| 01:03.01 | captain_proton | sussudio: -v tells it to use an interface |
| 01:03.04 | fiberchunks | ModeWhacker? |
| 01:03.15 | sussudio | captain_proton: well it gave me a crapload of errors with -v |
| 01:03.19 | sussudio | likeTypeError: file() argument 1 must be (encoded string without NULL bytes), not str |
| 01:03.36 | learner | hehe, I send a link to fiber, yet 4 download :) |
| 01:03.48 | captain_proton | sussudio: what was your command line? |
| 01:03.52 | learner | 5 |
| 01:04.10 | bryjen | learner: announce a link in channel.... |
| 01:04.24 | learner | hrm? |
| 01:04.41 | learner | I don't mind, just humorous |
| 01:04.41 | bryjen | you didn't just "I send a link to fiber |
| 01:05.27 | bryjen | bah. I cut-n-paste like a 5 yr old |
| 01:05.42 | learner | it's like the "look, John, an AIRPLANE" syndrome -- everyone looks |
| 01:05.48 | sussudio | captain_proton: just -sbrlcad.org:4242... it will eventually work if you retry it a few times |
| 01:06.49 | captain_proton | hah, the opengl python binding looks exactly like C code except sans semicolons |
| 01:06.59 | learner | heh |
| 01:08.41 | learner | please don't make me hungry again! |
| 01:08.50 | learner | you wouldn't like me when I'm hungry.. |
| 01:09.49 | learner | damaged goods |
| 01:10.08 | fiberchunks | ahhhhh, amstel time |
| 01:10.16 | scanline | oh my, what have I done |
| 01:10.25 | fiberchunks | created a monster |
| 01:10.36 | learner | he's back! |
| 01:10.37 | scanline | apparently.... |
| 01:10.39 | sussudio | scanline: killed kenny? |
| 01:10.50 | scanline | it's weird how everyone starts trying this stuff out all of a sudden |
| 01:11.04 | fiberchunks | it's amazingly fun, and very cool |
| 01:11.07 | fiberchunks | imho |
| 01:11.14 | scanline | captain_proton: I got to thinking how it would be a lot nicer to make a bzflag-plugin-thingy for Blender than to make an editor from scratch |
| 01:11.21 | scanline | fiberchunks: hehe |
| 01:11.25 | captain_proton | scanline: but but but! |
| 01:11.33 | scanline | :) |
| 01:11.33 | learner | scanline, that would be an excellent idea |
| 01:11.34 | captain_proton | then i can't play with 3d uis |
| 01:11.41 | fiberchunks | oooo, none of that -- editors from scratch only! ;) |
| 01:11.41 | scanline | captain_proton: sure you can |
| 01:11.45 | learner | why reinvent -- interface with _something_ |
| 01:11.53 | JBDiGriz | Who added code to save the directory in the config file? |
| 01:12.14 | scanline | I haven't looked at how capable the python scripting for blender is, but all I would need is the ability to add a few import/export scripts, and add some menu items to create bzflag primitives |
| 01:12.30 | captain_proton | scanline: do you have -any- idea how massively painful getting blender to run on irix would be? |
| 01:12.31 | scanline | then you could use the same tool to do high quality renderings of bzflag worlds, and export to other modeling formats :) |
| 01:12.46 | scanline | captain_proton: hrmm... why do we need editing on irix? |
| 01:12.46 | learner | It's pretty trivial. I wrote a small one that dumped triangles a while back |
| 01:12.57 | captain_proton | scanline: for a true 3d UI ;-) |
| 01:13.01 | fiberchunks | tim uses irix, don't he? |
| 01:13.11 | captain_proton | fiberchunks: not really |
| 01:13.17 | learner | cap, it runs on linux |
| 01:13.24 | fiberchunks | hrm, thought he did, whatever |
| 01:13.29 | learner | it was first written for irix |
| 01:13.35 | scanline | learner: well, I've heard good things about it. The main issue will be modifying the list of items in the 'add' menu to include bz primitives, then preventing modifications to those primitives that bz doesn't allow |
| 01:13.46 | scanline | learner: can probably do that with constraints |
| 01:14.07 | scanline | captain_proton: hmm, scary.... |
| 01:14.13 | learner | if you want a blender "expert", I can hook you up |
| 01:14.23 | captain_proton | learner: runs on linux != runs on irix |
| 01:14.26 | learner | they are on this irc network too |
| 01:14.38 | captain_proton | i've had to jump through very high hoops to get even silly things to run on irix |
| 01:14.43 | captain_proton | because they were full of linuxisms |
| 01:14.47 | learner | cap, I know -- it should run on irix with no problems |
| 01:14.56 | captain_proton | besides, thats not as much fun |
| 01:14.56 | fiberchunks | does that mean that a requirement for editing maps would be blender? |
| 01:15.06 | scanline | learner: maybe.. though I'd mostly rather just experiment with it myself until I run into a snag. I already know how to use blender and how to use python, just need to learn the interface :) |
| 01:15.13 | *** join/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 01:15.16 | scanline | fiberchunks: yes |
| 01:15.25 | scanline | fiberchunks: shouldn't be an issue.. blender is small and portable |
| 01:15.27 | learner | scanline: sounds good. lemme know if you have trouble |
| 01:15.44 | scanline | only possible problem is people that are scared of its UI... but for them I could put together a "bz mapping with blender for dummies" document or something |
| 01:15.47 | fiberchunks | hrm -- methinks that is not such a good idea then ... learning curves and all |
| 01:15.57 | scanline | why would you have to learn curves? |
| 01:15.59 | fiberchunks | ah, well, that might do it |
| 01:16.01 | fiberchunks | :) |
| 01:16.04 | *** part/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 01:16.19 | scanline | sure you could create curves to duplicate boxes along and such... |
| 01:16.31 | scanline | but the basic usage would be adding bz primitives from the 'add' menu and positioning them |
| 01:16.48 | fiberchunks | no no, I meant blender learning curves UI |
| 01:16.52 | learner | blender's UI is rather nasty, IMO, but it's certainly full-fledged for bz's needs |
| 01:16.54 | fiberchunks | -- UI |
| 01:16.57 | fiberchunks | rather |
| 01:17.06 | scanline | bah. I love blender's UI |
| 01:17.09 | scanline | it's just nontraditional |
| 01:17.15 | fiberchunks | yes, but you are not normal ;) |
| 01:17.25 | scanline | well, true... |
| 01:17.44 | learner | it'd be okay if it were intuitive and non-traditional.... :) |
| 01:17.59 | learner | you hare to learn so much apriori, though |
| 01:18.09 | fiberchunks | hey, if spiff and derv can understand it, then I'm cool with it -- cause that means I'll certainly be able to handle it |
| 01:18.11 | learner | key X == asd;fklasjd |
| 01:18.28 | scanline | well... for the kind of simple modeling you'd need for bz, you wouldn't have to learn much |
| 01:18.34 | learner | true |
| 01:18.44 | scanline | really just how to move, rotate, and scale objects, and a tiny bit about the views |
| 01:19.00 | learner | so it's settled, bzflag will now be a script module to blender |
| 01:19.08 | scanline | sure the buttons and such are confusing, but you can mostly ignore those for bzflag work |
| 01:19.08 | learner | J/K! |
| 01:19.15 | scanline | j/k? |
| 01:19.15 | fiberchunks | _all_ of bzflag :) |
| 01:19.16 | scanline | bah |
| 01:19.24 | *** join/#bzflag SGI (~sgi-tank@pcp01642968pcs.sothfd01.mi.comcast.net) |
| 01:19.27 | scanline | that would have to wait until the open source release has a working game engine... |
| 01:19.32 | SGI | hi |
| 01:19.37 | scanline | they had to disable that when it went GPL because the physics code was closed |
| 01:19.37 | fiberchunks | lo SGI |
| 01:19.42 | learner | hehe, yes, I meant "all" of bzflag |
| 01:20.38 | fiberchunks | the gf has returned, and is now molesting a watermelon -- it will be a strange evening, I feel ;) |
| 01:20.48 | captain_proton | with the side-effect that pybzflag will get a 3d view |
| 01:20.55 | learner | I'm jealous, fiber |
| 01:20.59 | scanline | captain_proton: well, that works too |
| 01:21.03 | learner | you _have_ a watermelon |
| 01:21.04 | learner | :) |
| 01:21.20 | scanline | captain_proton: the nice thing about pybzflag is it's easy to do multiple editor frontends that share the same world code |
| 01:21.25 | fiberchunks | personally, I would prefer not to add another major app to the mix, but whatever floats yer boat, so long as me (a linuxer) can edit / make maps, I don't care |
| 01:21.34 | SGI | I just bought a watermeon |
| 01:21.45 | JBDiGriz | I'll tell you about the watermelon later. |
| 01:21.46 | learner | see, even SGI has a watermelon |
| 01:21.53 | captain_proton | well |
| 01:21.56 | SGI | tomorrow....wodka injection |
| 01:22.00 | captain_proton | the editor could just subclass ThreeDView |
| 01:22.02 | fiberchunks | learner> you are a deprived soul |
| 01:22.14 | sussudio | tomorrow also: emergency room |
| 01:22.17 | learner | in many ways.. in oh so many ways |
| 01:22.34 | SGI | summer time...cold watermelon with wodka |
| 01:22.35 | scanline | captain_proton: I'm just saying that it could be easy to have both a simple editor, and a blender plugin for nuts like me |
| 01:22.41 | sussudio | if you're fond of sanddunes and salty air........ |
| 01:22.42 | captain_proton | indeed |
| 01:22.44 | fiberchunks | SGI: yum! good stuff |
| 01:22.50 | sussudio | ....quaint little villages here and there |
| 01:22.59 | learner | with his rate, cap, he'll be done tomorrow -- no worries |
| 01:23.06 | captain_proton | although the interfaces i'm starting to ponder aren't exactly traditional either |
| 01:23.22 | fiberchunks | scanline> oh, you were implying _both_ a simple editor _and_ a blender plugin? I misread, it seems |
| 01:23.43 | scanline | fiberchunks: I wasn't implying anything, nor was I ruling out anything :) |
| 01:23.49 | fiberchunks | my woman is feeding me cherries, life is good :) |
| 01:23.59 | JBDiGriz | captain_proton: The BZDB saves the directory, but doesn't save the email that I explicitly put in. |
| 01:24.04 | scanline | captain_proton: I was having visions of objects surrounded in dotted circles lined with icons :) |
| 01:24.17 | fiberchunks | scanline> i dig it :) |
| 01:24.39 | sussudio | fiberchunks: just talkin' bout shaft? |
| 01:24.39 | captain_proton | scanline: i still want to know what you were thinking about with a "3d tree view" |
| 01:24.57 | SGI | if you inject the wodka...with a huge syringe |
| 01:24.58 | fiberchunks | damn straight -- |
| 01:25.08 | SGI | one night in the refrigerator |
| 01:25.15 | fiberchunks | 'shut yo mouth' --- shaft! |
| 01:26.28 | scanline | captain_proton: me too |
| 01:26.28 | sussudio | @mp3 (Isaac_Hayes)_Theme_From_Shaft.mp3 (6,668,620 bytes 192kbps Stereo 4mins 38secs Genre:Soul Year:1971 Album:Shaft OST |
| 01:26.54 | SGI | wow |
| 01:27.26 | iLLf8d | stupidass noctf playing teamates |
| 01:27.29 | iLLf8d | heh |
| 01:27.35 | iLLf8d | got back there and the cheat was gone |
| 01:27.41 | iLLf8d | didn't notice anything else |
| 01:28.10 | scanline | captain_proton: mainly I was thinking about a good way to hierarchially represent groups of objects in 3D |
| 01:28.17 | iLLf8d | anyone know if theres any real ctf patches |
| 01:28.25 | iLLf8d | ie |
| 01:28.32 | iLLf8d | uhm you get like 10 points if you capture a flag |
| 01:28.43 | iLLf8d | something to make ctf worthwile |
| 01:28.47 | iLLf8d | while even |
| 01:29.14 | SGI | 10pts |
| 01:29.57 | iLLf8d | cool |
| 01:30.08 | iLLf8d | would be better if I could whistle it in the game |
| 01:30.15 | SGI | what the 10 pts of the whistle |
| 01:30.27 | iLLf8d | yeah 10 pts |
| 01:30.31 | sussudio | yes, with actual samples of a plastic whistle to really annoy the other players |
| 01:30.37 | iLLf8d | alot of hosers join xmission and never touch a flag |
| 01:30.40 | iLLf8d | tho its a ctf field |
| 01:30.46 | iLLf8d | when the ctf is on the fields a blast |
| 01:30.51 | doughecka | a patch! so when ever someone goes /whistle it whistles :P |
| 01:30.54 | iLLf8d | when the hosers are there its boring |
| 01:31.13 | iLLf8d | maybe one of those factory ones a really loud one |
| 01:31.16 | iLLf8d | whoooooooooooooooooooooooo |
| 01:31.16 | iLLf8d | heh |
| 01:31.24 | doughecka | fog horn |
| 01:31.30 | doughecka | and a kazoo :) |
| 01:31.42 | SGI | when you have a good players ...is hard to touch the flags |
| 01:31.50 | iLLf8d | I still think the tanks need that startrek squeaky dashboard patch |
| 01:32.00 | iLLf8d | de dit de dit de dit de dit |
| 01:32.01 | sussudio | don't forget the cap'n'crunch 2600 whistle |
| 01:32.06 | doughecka | haha |
| 01:32.51 | iLLf8d | s/show/shown |
| 01:33.02 | iLLf8d | or blatantly obvious cheats at least |
| 01:33.15 | iLLf8d | tho before it was like daily |
| 01:33.27 | doughecka | the role of the admin is not to kick, but to moderate the game :) |
| 01:33.33 | iLLf8d | someone put some cheats there so I can kick/ban them damnit! |
| 01:33.34 | iLLf8d | heh |
| 01:33.36 | sussudio | iLLf8d: want me to compile a cheat client? |
| 01:33.40 | captain_proton | harumph, there aren't |
| 01:34.04 | iLLf8d | yeah its been totally uneventful |
| 01:34.06 | doughecka | iLLf8d: what sort of connection do ya have? |
| 01:34.15 | iLLf8d | tho I am happy to say most ppls have been playing ctf lately |
| 01:34.27 | iLLf8d | some of the games have been a blast |
| 01:34.34 | iLLf8d | cable modem |
| 01:34.44 | iLLf8d | I just like to do away with cheaters |
| 01:35.00 | iLLf8d | bz is fun when its on the level |
| 01:35.25 | iLLf8d | when its not its fun too usually tho with ctf its a bit tougher |
| 01:35.34 | sussudio | iLLf8d: ok you had your chance. i logged off again. |
| 01:35.53 | iLLf8d | you cheat? |
| 01:35.56 | iLLf8d | sheesh |
| 01:36.01 | sussudio | yup |
| 01:36.17 | sussudio | global.h cheat-o-rama |
| 01:36.23 | iLLf8d | its too funny those russian posermen come on do 0 ctf and usually 3 to 1 or 3 to 2 people |
| 01:36.28 | iLLf8d | then they insult them |
| 01:36.40 | iLLf8d | lately i've been just shooting them up and insulting them back =) |
| 01:36.53 | captain_proton | sounds like the old days ;) |
| 01:37.05 | iLLf8d | yeah I love shooting up cheaters |
| 01:37.08 | fiberchunks | scanline, captain_proton> if you need a guinea pig for this editor, let me know -- I'll be happy to help out |
| 01:37.11 | iLLf8d | must piss them off when they lose even with the cheats |
| 01:37.16 | fiberchunks | s/this/these |
| 01:37.29 | iLLf8d | editor? |
| 01:37.39 | iLLf8d | this for bz or the other proj? |
| 01:37.45 | fiberchunks | bz |
| 01:37.50 | iLLf8d | could never get that other one working right |
| 01:38.02 | iLLf8d | that wierdass makefile setup doesn't work as billed |
| 01:38.05 | fiberchunks | new joy for us *nix folk (and prob. windoze too) |
| 01:38.18 | iLLf8d | what about it fiber? |
| 01:38.21 | iLLf8d | what are they changing? |
| 01:38.30 | fiberchunks | whole new bag, baby |
| 01:38.40 | iLLf8d | yeah howso and why? |
| 01:38.48 | fiberchunks | blender plug-ins (perhaps) bzedit.py (perhaps) -- new shebang |
| 01:39.03 | fiberchunks | just got 'started' this eve (slap me if I'm wrong you 2) |
| 01:39.11 | iLLf8d | why tho? |
| 01:39.14 | iLLf8d | bzedits are ok |
| 01:39.20 | iLLf8d | just need a few basic features |
| 01:39.27 | captain_proton | who knows why... |
| 01:39.37 | iLLf8d | bze in windows needs hotkeys for mode switching |
| 01:39.41 | fiberchunks | because there is no 'decent' editor for *nix -- there's a good one for 'doze |
| 01:39.47 | iLLf8d | and bze in linux needs mode switching and hotkeys |
| 01:39.50 | iLLf8d | then they're be decent |
| 01:39.52 | captain_proton | there's a decent one! |
| 01:40.02 | iLLf8d | yeah its decent tho annoying at times |
| 01:40.07 | fiberchunks | I didn't mean it that way captain_proton, you know that :) |
| 01:40.12 | iLLf8d | how hard would it be to patch in the movements |
| 01:40.42 | fiberchunks | and 3D! :) |
| 01:40.44 | iLLf8d | it needs hotkey mouse resize, positioning, duplication, and ctrl click grouping or something similar then its about all you'd ever need |
| 01:41.11 | iLLf8d | theres not much to a bz field |
| 01:41.12 | iLLf8d | sorry to say |
| 01:41.31 | captain_proton | just to let you guys know |
| 01:41.37 | captain_proton | i'm not going to be doing user support for this |
| 01:41.38 | iLLf8d | fiberchunks: whose working on it cap and scanline? |
| 01:41.48 | iLLf8d | for what? |
| 01:42.01 | fiberchunks | yessir |
| 01:42.12 | fiberchunks | captain_proton> if you keep me informed, I'll do my best for it |
| 01:42.33 | iLLf8d | so using pygl or something else? |
| 01:43.06 | fiberchunks | it is -- a mystery -- right now -- there are 2 different ideas in the loop |
| 01:43.25 | iLLf8d | do tell I can kinda code python =P |
| 01:43.59 | fiberchunks | talk to the good capt. and herr scanline |
| 01:44.13 | iLLf8d | ehh caps not overly forthcoming ever |
| 01:44.18 | iLLf8d | so we'll cross him off the list |
| 01:44.21 | iLLf8d | no offense cap |
| 01:44.27 | iLLf8d | scanline you alive? |
| 01:45.13 | fiberchunks | take it easy turbo -- things just got started tonight -- I'm sure both captain_proton and scanline have more pressing issues at the moment |
| 01:45.29 | iLLf8d | oh kissass |
| 01:45.34 | iLLf8d | pucker up |
| 01:45.38 | iLLf8d | heh |
| 01:45.42 | iLLf8d | offense intended =) |
| 01:45.44 | iLLf8d | muwahahha |
| 01:45.46 | fiberchunks | bah |
| 01:45.59 | iLLf8d | chunks you make any fields? |
| 01:46.15 | iLLf8d | I send most of mine to someone tho I dunno what they did withem |
| 01:46.19 | iLLf8d | haven't seen many ofem |
| 01:47.00 | fiberchunks | no -- reason why being that it would have to be a vi'd thing for me -- since caps bzedit doesn't quite cut it, and bze for win won't run on my boxen |
| 01:47.10 | sussudio | iLLf8d: i made like 40 maps |
| 01:47.22 | iLLf8d | cool |
| 01:47.24 | iLLf8d | me too |
| 01:47.40 | sussudio | about 25 were up at jzaun's till he quiet |
| 01:47.43 | iLLf8d | I really like one guys maps wonder if its you |
| 01:47.44 | sussudio | quit even |
| 01:47.45 | fiberchunks | as a matter of fact, bze linux has just tonight decided it was going to compile for me -- but there is goofiness |
| 01:47.47 | iLLf8d | lemm esee |
| 01:47.59 | fiberchunks | I can't code a lick, so I still highly respect those who can ;) |
| 01:49.14 | iLLf8d | dutchrai has 2 I like |
| 01:49.21 | iLLf8d | gatefive and queen of the castle |
| 01:49.46 | sussudio | there's only 1 map of mine out there now, it's running on dragon.org |
| 01:51.02 | iLLf8d | don't like to admit that I like those tho |
| 01:51.29 | iLLf8d | he had some map contest and declared himself the winner (and from what I can see he wasn't objective enough cause he shouldn't have won with his entry) |
| 01:51.43 | captain_proton | yay for girls with cute voices singing "i have no choice but to destroy you" |
| 01:52.02 | sussudio | captain_proton: mmmmkay |
| 01:53.36 | fiberchunks | dutchrai declared himself winner? when? |
| 01:54.08 | iLLf8d | uhm some map contest |
| 01:54.28 | bzgirl | i think dervs map won |
| 01:54.56 | iLLf8d | well whoever the site owner was won it iirc |
| 01:55.07 | iLLf8d | not that it wasn't a good map |
| 01:55.11 | bzgirl | but they wernet very supportive of the other entries "overall this isnt a very good map at all" |
| 01:55.13 | fiberchunks | ah |
| 01:55.16 | learner | ah, the 2nd map contest on shell shock.. |
| 01:55.28 | iLLf8d | not sure which map contest it was |
| 01:55.35 | iLLf8d | they weren't objective thats all I know |
| 01:57.04 | learner | lol.. "the woman" .. "the kid" .. heheh |
| 01:57.10 | fiberchunks | heh |
| 01:57.14 | sussudio | scanline: you're supposed to go "You wanna see something really scary?" |
| 01:58.22 | fiberchunks | I'm being harassed by humans -- help |
| 01:58.59 | sussudio | hoomaans? |
| 02:00.42 | scanline | The following are all valid world names to pass to bzfs.py, worldviewer.py, or whereever: |
| 02:00.50 | scanline | foo.bzw |
| 02:00.58 | scanline | http://somewhere/foo.bzw |
| 02:01.09 | scanline | text:foo.bzw,size=1200 |
| 02:01.17 | scanline | random |
| 02:01.18 | iLLf8d | bzfs.py? |
| 02:01.19 | *** join/#bzflag DB7654321 (~DB7654321@chcgil2-ar7-4-3-184-165.chcgil2.dsl-verizon.net) |
| 02:01.20 | iLLf8d | wheres that |
| 02:01.44 | scanline | random:boxBase=20,wallHeight=50 |
| 02:01.49 | scanline | empty |
| 02:01.52 | scanline | Empty() |
| 02:02.06 | scanline | binary:foo.bwc |
| 02:02.13 | scanline | heightmap:foo.png |
| 02:02.19 | scanline | =) |
| 02:02.53 | scanline | iLLf8d: pybzflag |
| 02:03.06 | iLLf8d | hmm |
| 02:03.22 | iLLf8d | doesn't show up in google |
| 02:03.32 | scanline | the 'binary' world generator is especially cute.. you can pull worlds out of your bzflag cache and view them or serve them |
| 02:03.40 | scanline | iLLf8d: it's in CVS |
| 02:03.43 | iLLf8d | ah |
| 02:04.19 | iLLf8d | does it use something retarded like twisted |
| 02:04.33 | scanline | uh.. first of all, twisted is nothing close to retarded |
| 02:04.35 | scanline | second of all, no |
| 02:04.40 | iLLf8d | heh |
| 02:05.48 | iLLf8d | man sourceforge is a pig |
| 02:08.52 | CIA | 03micahjd * 12pybzflag/BZFlag/Client (Stateful.py): Fix loading uncached binary worlds in StatefulClient |
| 02:09.36 | sussudio | iLLf8d: ,pig |
| 02:10.21 | captain_proton | scanline: explain me this |
| 02:10.23 | captain_proton | i create a directory |
| 02:10.28 | captain_proton | stick an __init__.py in there |
| 02:10.33 | captain_proton | create a file |
| 02:10.35 | iLLf8d | dunno what thats supposed to mean, not that I care much heh |
| 02:10.53 | captain_proton | from Directory import File |
| 02:11.00 | captain_proton | File.Class gets an error |
| 02:11.01 | sussudio | iLLf8d: it's like Npig, but personally to sourceforge |
| 02:11.37 | scanline | captain_proton: hmm.. sounds like it should work, maybe there's something simple you're doing wrong? you could commit what you have and I could try it |
| 02:12.34 | CIA | 03dbw192 * 12bzflag/src/platform/MacOSX/BZFlag.pbproj (project.pbxproj): Add recent changes to the project file. |
| 02:12.37 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/UI/Objects (3 files): Directory /cvsroot/bzflag/pybzflag/BZFlag/UI/Objects added to the repository |
| 02:13.24 | *** join/#bzflag snyke (~snyke@eros.bingo-ev.de) [NETSPLIT VICTIM] |
| 02:13.24 | *** join/#bzflag fiberchunks (~frobozzpf@237.14.252.64.snet.net) [NETSPLIT VICTIM] |
| 02:13.28 | CIA | 03davidtrowbridge * 12pybzflag/ (4 files in 3 dirs): add a bunch of crufty code |
| 02:13.35 | scanline | ha |
| 02:13.43 | fiberchunks | ah, netsplit |
| 02:13.53 | CIA | 03dbw192 * 12bzflag/src/bzflag (bzflag.cxx): Fix Mac resource directory |
| 02:14.04 | captain_proton | erg |
| 02:14.18 | captain_proton | i change things back to the way i had it (had messed with things trying to fix it) and it works |
| 02:14.38 | scanline | hmm |
| 02:14.54 | scanline | strange that it would give an error on accessing a module's attribute, rather than on import |
| 02:15.05 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/UI (ThreeDView.py): unbreak it a bit |
| 02:18.28 | captain_proton | hrm |
| 02:18.35 | captain_proton | <PROTECTED> |
| 02:18.35 | captain_proton | <PROTECTED> |
| 02:18.35 | captain_proton | <PROTECTED> |
| 02:18.35 | captain_proton | <PROTECTED> |
| 02:18.35 | captain_proton | <PROTECTED> |
| 02:18.36 | captain_proton | <PROTECTED> |
| 02:18.38 | captain_proton | any clues? |
| 02:18.42 | captain_proton | SystemError: unknown raw mode |
| 02:20.39 | scanline | hmm, the docs show tostring taking no parameters |
| 02:21.40 | scanline | odd |
| 02:32.16 | *** join/#bzflag JBDiGriz (~JBDiGriz@adsl-63-204-118-6.dsl.sndg02.pacbell.net) |
| 02:33.24 | *** join/#bzflag SGI (~sgi-tank@pcp01642968pcs.sothfd01.mi.comcast.net) |
| 02:35.42 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/UI (2 files in 2 dirs): comment out imageload and get the ground to draw as an OMG HOT HOT white quad |
| 02:36.08 | scanline | I'm adding some code that will let us switch UIs easily from the command line |
| 02:36.28 | scanline | like... "bzfs.py -u 3D" or "bzfs.py -u overhead" |
| 02:40.00 | scanline | <PROTECTED> |
| 02:40.02 | scanline | <PROTECTED> |
| 02:41.54 | *** join/#bzflag Terry (Terry@host-11-76-220-24.midco.net) |
| 02:42.24 | *** join/#bzflag Terry (Terry@host-11-76-220-24.midco.net) |
| 02:43.56 | *** join/#bzflag creeperz (creeperz@host-11-76-220-24.midco.net) |
| 02:49.20 | captain_proton | hrm |
| 02:49.24 | CIA | 03micahjd * 12pybzflag/ (5 files in 3 dirs): Spiffy little UI.Any class to make it easy to automatically pick a UI. Implemented in bzfs.py so far. |
| 02:49.34 | captain_proton | so the issue is that PIL thinks the image isn't the right depth |
| 02:49.42 | sussudio | http://us.news2.yimg.com/us.yimg.com/p/ap/20030709/capt.1057766823.georgia_giant_preschoolers_mosb111.jpg |
| 02:49.46 | sussudio | dervish's baby picture |
| 02:49.48 | scanline | whee... "/bzfs.py -u overhead" works |
| 02:49.59 | scanline | "./bzfs.py -u 3D" can't find ground.png :) |
| 02:50.49 | scanline | hmm |
| 02:50.50 | scanline | micah@yoshi pybzflag $ file ground.png |
| 02:50.50 | scanline | ground.png: PNG image data, 64 x 64, 8-bit grayscale, non-interlaced |
| 02:51.08 | captain_proton | hmm, indeed |
| 02:51.13 | bryjen | grey ground ? |
| 02:51.16 | scanline | ah.. and gimp shows it as grayscale |
| 02:51.20 | scanline | I guess the green is added later |
| 02:51.31 | Patlabor221 | the green is added in Code |
| 02:51.40 | Patlabor221 | cus it's purple when you are in the phantom zone |
| 02:51.50 | Patlabor221 | it just calls glColor3f() for it |
| 02:52.08 | Patlabor221 | pyramids are done the same way |
| 02:52.10 | scanline | captain_proton: I think our grass from jetstream was better anyway :) |
| 02:52.35 | Patlabor221 | any grass is better then that stuff |
| 02:53.20 | captain_proton | hehe |
| 02:53.46 | captain_proton | scanline: i get an error 500 trying to wget the file |
| 02:53.49 | scanline | captain_proton: you probably want to use .convert("RGB") to ungrayscaleify the image |
| 02:54.03 | bryjen | grass in the python. or meebee the udder way 'round. hehe |
| 02:54.22 | scanline | oh, hmm... |
| 02:54.26 | scanline | the repository appears poofed |
| 02:54.47 | *** join/#bzflag creeperz (creeperz@host-11-76-220-24.midco.net) |
| 02:55.00 | scanline | oh wait |
| 02:55.05 | scanline | never mind, I was using the wrong path |
| 02:55.06 | scanline | it looks fine |
| 02:55.23 | scanline | http://navi.picogui.org/svn/misc/trunk/jetstream/media_src/marsh.png |
| 02:55.24 | scanline | works for me |
| 02:55.26 | captain_proton | http://jupiter.babylonia.flatirons.org/fugly.png |
| 02:55.28 | *** part/#bzflag creeperz (creeperz@host-11-76-220-24.midco.net) |
| 02:55.40 | scanline | hehehe |
| 02:55.56 | scanline | and then there was the original grass: |
| 02:55.58 | scanline | http://navi.picogui.org/svn/misc/trunk/jetstream/extra_media/grass.png |
| 02:56.32 | scanline | http://navi.picogui.org/svn/misc/trunk/jetstream/media_src/ship.png <--- our replacement bzflag tank! |
| 02:56.59 | captain_proton | hehe |
| 02:57.34 | bryjen | looks like a startrek communicator badge |
| 02:57.48 | scanline | hehe |
| 02:58.48 | scanline | bah, I never claimed to be an artist |
| 02:58.52 | scanline | though I try to be one far too often |
| 02:58.56 | bryjen | I'm lucky to draw breath ;) |
| 02:58.57 | Patlabor221 | ohh god not that thing |
| 03:01.52 | captain_proton | hmm |
| 03:01.56 | scanline | http://navi.picogui.org/svn/misc/trunk/blender/characters/kirby_walking.png <-- my masterpiece! |
| 03:02.15 | captain_proton | Patlabor221: the whole model manager thing in bzedit is so much easier in python =) |
| 03:02.22 | CIA | 03micahjd * 12pybzflag/ (3 files): Convert all the examples that had been using OverheadView directly to use UI.Any via CommandLine.parser() |
| 03:02.53 | scanline | so, "./worldviewer.py -u 3D random" will run your 3D view with a randomly generated world, when it works :) |
| 03:03.08 | scanline | or you could do fun things like random:size=2000 |
| 03:03.35 | scanline | at least we won't have problems compiling bzedit itself :) |
| 03:03.38 | learner | cap, I do! |
| 03:04.33 | bryjen | pretty blue, but where's the heads? |
| 03:05.11 | scanline | there's not a lot SMP would do for bzflag |
| 03:05.16 | captain_proton | well, true |
| 03:05.21 | captain_proton | bz could have some of itself split up |
| 03:05.31 | learner | yes there is -- I can peg both my processors |
| 03:05.33 | scanline | go MVC paradigm! |
| 03:06.01 | fiberchunks | oh my -- what's that captain_proton? |
| 03:06.03 | scanline | learner: it spends most of its time waiting on the GPU.. you only have one of those per monitor I presume |
| 03:06.21 | bryjen | big iron isn't much fun to look at. unless its got a big spiffy display somewheres. |
| 03:06.29 | learner | not according to my cpu usage.. plenty of time is spent in the cpu still |
| 03:06.49 | captain_proton | fiberchunks: that would be a modern graphics supercomputer |
| 03:06.49 | scanline | learner: that's probably because the CPU spins waiting on the GPU |
| 03:06.58 | captain_proton | <server> You were kicked because of idling too long <-- :( |
| 03:07.10 | scanline | captain_proton: hehe.. using observer.py? |
| 03:07.17 | captain_proton | yeah |
| 03:07.41 | captain_proton | har |
| 03:07.47 | captain_proton | all this flexibility |
| 03:07.49 | scanline | or you could use a callsign starting with an @ |
| 03:07.50 | captain_proton | it scares me |
| 03:07.55 | scanline | or you could run bzfs with a UI |
| 03:08.00 | scanline | :) |
| 03:08.18 | learner | most apps can benefit from careful placement of smp code. |
| 03:08.33 | learner | most people don't think about it, unfortunatley, until they sit at an smp machine! |
| 03:08.45 | fiberchunks | captain_proton> that thing is nasty loooking |
| 03:08.48 | fiberchunks | :) |
| 03:09.02 | scanline | learner: well, if bzflag is all MVC'ified it would be easy to have one thread for updating the game view from the network, one for updating it from local controls, one for rendering it |
| 03:09.03 | captain_proton | scanline: hah! bzfs with a ui is supah-neat |
| 03:09.11 | scanline | captain_proton: =) |
| 03:09.23 | scanline | if only it actually worked as a bzfs... |
| 03:09.38 | scanline | it can update its internal game state just enough to draw the players moving around, doesn't send out any updates yet |
| 03:10.10 | scanline | learner: hey, I had a SMP machine for a while |
| 03:10.17 | scanline | then its motherboard got cranky and became a non-SMP machine |
| 03:10.30 | learner | eek.. cheap smp :) |
| 03:10.35 | scanline | yep |
| 03:10.38 | scanline | bargain basement AMD |
| 03:10.41 | learner | sounds like PC stuff :) |
| 03:10.45 | learner | ah yes |
| 03:10.53 | scanline | but I paid... maybe $300 |
| 03:10.59 | scanline | you can't get an apple toaster for that |
| 03:11.03 | sussudio | scanline: have you tried yelling at it? |
| 03:11.14 | scanline | sussudio: tried that, in between the alcohol swabbings |
| 03:11.35 | learner | give me a 32-way SP4 any day ;) |
| 03:11.43 | sussudio | service pack 4? |
| 03:11.45 | scanline | hey, I'll take one while you're at it |
| 03:12.04 | captain_proton | learner: like the intellistations? |
| 03:12.24 | captain_proton | oh wait |
| 03:12.26 | captain_proton | you said sp4 |
| 03:12.37 | scanline | learner: mine? |
| 03:12.45 | scanline | that was pig-boy over there |
| 03:12.50 | captain_proton | scanline: one of clay's friends took the sp2 from the boneyard |
| 03:12.51 | learner | and cap's intellistation ref! |
| 03:12.53 | learner | :) |
| 03:13.09 | scanline | captain_proton: hehe.. got a place to put it? |
| 03:13.16 | captain_proton | and learner... IBM clusters are not smp |
| 03:13.32 | fiberchunks | or this for 'big iron': http://www.bikerchicks4u.com/bw2003/girls/imagepages/image.html |
| 03:13.33 | learner | individual nodes are |
| 03:13.41 | captain_proton | they're sort of a weird unholy merging between numa, smp, multi-core and a cluster |
| 03:13.46 | captain_proton | learner: eh, sort of |
| 03:13.47 | learner | they go up to 32-way,cap |
| 03:14.07 | captain_proton | learner: the memory architecture isn't smp - its more like hyperthreading |
| 03:14.23 | learner | they are completely.. you can completely turn off the cheesy hack they did for clustering |
| 03:14.56 | learner | how so, all banks are shared at least 4-way in 2 hops? |
| 03:15.19 | learner | 32-way jumping down main memory |
| 03:15.38 | learner | shared l1 and l2 caches per 4-cpu set |
| 03:15.53 | captain_proton | the individual processors don't have individual fetch units |
| 03:16.05 | learner | eh?? |
| 03:16.19 | learner | well, per cpu module.. yes |
| 03:16.27 | captain_proton | thats what i mean |
| 03:16.38 | learner | I think I see what you mean -- just a differnt way to look at it, I think |
| 03:16.42 | captain_proton | yeah |
| 03:17.01 | captain_proton | its like smp, where each processor in the system is actually 4-core |
| 03:17.25 | learner | that's one helluva 4-way hyperthread beast though.. I'm not sure I'd compare it to a xeon's hyperthreading |
| 03:17.37 | captain_proton | but i feel kind of sorry for the kid who took this sp2...he said he wants to learn AIX & clustering |
| 03:17.40 | captain_proton | poor bastage |
| 03:17.45 | captain_proton | learner: heh, true |
| 03:17.49 | learner | ha |
| 03:18.11 | captain_proton | each node is 2-way 150MHz or something |
| 03:18.14 | captain_proton | pretty silly :) |
| 03:18.35 | learner | they're still the best :) |
| 03:18.54 | captain_proton | eh |
| 03:18.56 | captain_proton | i'm fond of sgi |
| 03:19.12 | captain_proton | numa makes me happy |
| 03:19.22 | sussudio | numa lub you long time |
| 03:19.33 | learner | I love sgi, but per single cpu, they are really behind -- sgi's amazing because you can single image 768 of them :) |
| 03:19.45 | captain_proton | well - yeah |
| 03:20.04 | captain_proton | even the r16k (which is a SEXY BEAST) is only 700MHz |
| 03:20.28 | learner | yess... |
| 03:20.35 | learner | have you seen the altix? |
| 03:20.36 | sussudio | my precioussss? |
| 03:20.51 | captain_proton | only on their web page |
| 03:21.18 | learner | amazing single image performance |
| 03:21.59 | learner | and quite an interesting 64-bit linux hack to get that to happen.. |
| 03:22.05 | captain_proton | i'm pretty sure eventually sgi will hack up liinux to the point where you can image a huge number of processors |
| 03:22.29 | sussudio | scanline: mandy moore? |
| 03:22.41 | scanline | no, my favorite |
| 03:22.46 | fiberchunks | lol |
| 03:22.50 | captain_proton | =} |
| 03:22.57 | learner | basically strapped the numa architecture and their fiber backplane onto a bunch of itaniums running linux |
| 03:23.06 | fiberchunks | hrm? fiber? |
| 03:23.10 | fiberchunks | :) |
| 03:24.00 | captain_proton | well...they've been hacking at numa for a while on linux |
| 03:24.13 | fiberchunks | she keeps complaining about my 'backplane' ;) |
| 03:24.14 | learner | when they scale over 256, they're going to start pushing their mips products out of the market |
| 03:24.25 | learner | lol, fiber |
| 03:24.46 | scanline | SGI's linux stuff isn't mips! heresy! |
| 03:24.49 | captain_proton | learner: eh - we'll see |
| 03:24.58 | captain_proton | the itanium stuff isn't directed at graphics at all |
| 03:25.21 | captain_proton | so scanline, did you see the news yesterday? |
| 03:25.26 | captain_proton | diablo's folly hit 100 commits |
| 03:25.31 | scanline | oooh |
| 03:25.43 | scanline | does it have a menu now? |
| 03:25.52 | fiberchunks | who is diablo, and what's this about folly? |
| 03:26.03 | captain_proton | diablo = my stalker |
| 03:26.08 | captain_proton | his folly = his crappy game |
| 03:26.13 | scanline | hehe |
| 03:26.20 | fiberchunks | oooo, cap has a stalker :) |
| 03:26.35 | learner | cap, I agree, they'll be pushing their own customers that use the big irons for non-graphics apps over to this new box (like us) |
| 03:26.36 | fiberchunks | you must feel like letterman, cept different |
| 03:27.06 | learner | they are focusing almost all of their energy on stuff related to the altix, though (this comes from an sgi vp) |
| 03:27.19 | captain_proton | makes sense to me |
| 03:27.43 | learner | upsets me quite a bit, though |
| 03:27.45 | captain_proton | the current generation of graphics stuff is quite a bit faster than is needed at the moment, but people can always use more cycles |
| 03:27.46 | learner | I love mips |
| 03:27.57 | learner | quite |
| 03:28.14 | fiberchunks | scanline> what was the name of the group that had the lead singer (female), with the uber-sexy voice? |
| 03:28.52 | scanline | that's a bit vague... |
| 03:28.56 | scanline | but how about Nightwish? |
| 03:28.57 | scanline | :) |
| 03:29.23 | fiberchunks | we talked about it one night on IRC -- but I don't feel like grepping logs -- I lost the d/l file :\ |
| 03:29.24 | captain_proton | trespassers william, nightwish, ... |
| 03:29.28 | captain_proton | any of lisa gerrard's groups |
| 03:29.38 | fiberchunks | scanline> <<<< heh :) |
| 03:29.43 | learner | scanline> why? :) |
| 03:29.48 | fiberchunks | lol |
| 03:30.04 | fiberchunks | captain_proton> that's it -- trespassers william -- thx |
| 03:30.06 | scanline | (-learner-)> no idea |
| 03:30.07 | fiberchunks | :) |
| 03:30.18 | learner | hehe |
| 03:31.41 | fiberchunks | ModelAgent? |
| 03:31.45 | fiberchunks | WaifMonger? |
| 03:31.46 | scanline | what's it do exactly? |
| 03:32.26 | *** join/#bzflag MrApathyCream (dbrosius@balt-209-163-100-170.qis-dynamic-dialup.coretel.net) |
| 03:32.28 | captain_proton | scanline: keeps a list of functions given to it by the objects in a scene, and draws them sorted by texture |
| 03:32.52 | scanline | that should probably be folded into the World.Scene class |
| 03:32.54 | learner | ModelPimp |
| 03:33.06 | fiberchunks | WaifPimp |
| 03:33.14 | *** join/#bzflag Michaelh (Mouse@172-150.dynamic.visi.com) |
| 03:33.19 | captain_proton | hrm, World.Scene? |
| 03:33.26 | scanline | also, I'm not really sure what to do about objects that need drawing but aren't in the world |
| 03:33.52 | learner | modify the world so they are real objects.. |
| 03:34.01 | scanline | captain_proton: yep.. it's where all the objects in the world get stored. the idea was you could ask it for iterators to traverse the objects in sorted order, traverse a subset of them, etc. |
| 03:34.23 | scanline | learner: well, that's one option.. you can stick them in Scene but not in World |
| 03:34.24 | captain_proton | scanline: well - an object may potentially have several "models" |
| 03:34.29 | captain_proton | one model per texture used |
| 03:35.05 | scanline | I guess the concern I have is keeping the definition of objects in the bzflag world in one central place |
| 03:35.19 | captain_proton | thats a good concern |
| 03:35.31 | scanline | in overheadview for example, it uses a method on the WorldObject it gets to convert the object into a polygon without knowing anything about it |
| 03:35.41 | scanline | then it only uses the object name to look up a color in its color scheme dict |
| 03:36.16 | scanline | I was thinking in 3D there would be a similar function to return a polyhedron type representation, then texturing would be decided based on a 'texture scheme' map or something |
| 03:37.05 | scanline | the WorldObject could return a list of vertices and a list of triangles, keeping the object representation and the API-specific rendering code completely separate |
| 03:38.32 | Michaelh | woof |
| 03:38.49 | scanline | captain_proton: display lists are your friend |
| 03:38.52 | Michaelh | would this make hard coding models "Not a good thing" ? |
| 03:39.29 | scanline | Michaelh: well, in the plan I'm suggesting, models would be hardcoded in only one place.. and it would be the same place both the binary and text representations of the object are defined |
| 03:39.50 | Michaelh | so you can do whatever funky object oriented stuff you want as long as you encase them in gl_list thingees? |
| 03:39.59 | scanline | one of my primary goals in designing a system like this is that when you add a new object type (world object, protocol message, etc.) you only have to make changes in one place |
| 03:40.12 | Michaelh | what a concept :) |
| 03:40.31 | scanline | Michaelh: you'd be surprised how few systems actually do that |
| 03:40.51 | Michaelh | if it's a bit slow 1 time, but sped up every other time it all evens out.... |
| 03:40.57 | scanline | especially in compiled languages, where you could have to add a source file, a header file, a makefile entry, a pointer in a function table... |
| 03:41.12 | scanline | Michaelh: oh, right. I already mentioned display lists |
| 03:41.29 | scanline | it's the obvious solution when your GL library is substantially faster than your app code |
| 03:41.30 | Michaelh | you're the python dude right? |
| 03:41.35 | scanline | I guess so |
| 03:41.36 | Michaelh | :) |
| 03:42.28 | *** join/#bzflag trepan (~trepan@CPE0040f42db082-CM00e06f15f704.cpe.net.cable.rogers.com) |
| 03:42.42 | scanline | captain_proton: Protocol.WorldObjects |
| 03:42.52 | Michaelh | so how huge is the exe going to get? It's already over 1 meg now for windows .... |
| 03:42.54 | captain_proton | ooh, thats intuitive :P |
| 03:43.23 | scanline | feh |
| 03:43.54 | captain_proton | soo |
| 03:44.08 | captain_proton | including how they should be drawn? |
| 03:44.09 | captain_proton | :P |
| 03:44.12 | Michaelh | so are you guys considering actually centralizing the network code? ... |
| 03:44.12 | scanline | yes |
| 03:44.15 | Michaelh | heh..... |
| 03:44.28 | CIA | 03dbrosius * 12bzflag/win32 (bzflag.dsp): remove resources.cxx/h and Keymap.cxx/h from dsp |
| 03:44.30 | Michaelh | or object orientizing it? |
| 03:45.00 | scanline | captain_proton: you can think of the protocol as just a more compact representation of a triangle model. This also is like it is to support my change-it-in-only-one-place philosophy |
| 03:45.27 | scanline | if the protocol changes, you shouldn't have to change that, then go change the code in each UI that tries to render that object |
| 03:45.46 | MrApathyCream | now your talking crazy |
| 03:45.52 | MrApathyCream | we'd be out of jobs if it were that easy |
| 03:46.54 | sussudio | MrApathyCream: look at a baby picture of Dervish: http://us.news2.yimg.com/us.yimg.com/p/ap/20030709/capt.1057766823.georgia_giant_preschoolers_mosb111.jpg |
| 03:48.18 | MrApathyCream | i'm scaired to |
| 03:48.35 | sussudio | it's a striking resemblance. |
| 03:48.59 | MrApathyCream | it is actually |
| 03:49.17 | sussudio | uh huh. |
| 03:49.43 | MrApathyCream | captain_proton: are we done getting it back into shape, yet? |
| 03:49.48 | MrApathyCream | :) |
| 03:50.37 | captain_proton | getting what? |
| 03:51.02 | sussudio | MrApathyCream: do you think it's possible to get "Horse with no name" out of your head within a week? |
| 03:51.13 | MrApathyCream | <captain_proton>: I think Tim doesn't want to add anything else so that we can get the current code back into shape |
| 03:51.26 | captain_proton | MrApathyCream: looking at BUGS, i'd say no |
| 03:51.37 | MrApathyCream | is there much? |
| 03:52.31 | captain_proton | scanline: is there any way to set a dirty flag on the world? |
| 03:53.18 | scanline | captain_proton: the game has an onLoadWorld event... for editing though it would be good to have a real dirty flag |
| 03:53.44 | captain_proton | well, there's a reason for that |
| 03:53.52 | captain_proton | i've been fixing bugs in other code and hacking up my own |
| 03:54.02 | MrApathyCream | heh, poor captain_proton |
| 03:54.13 | captain_proton | so all the other bugs get fixed, but not mine ;) |
| 03:54.22 | scanline | captain_proton: All the existing code that loads a new world creates a new object in the process, so if you add a new attribute for a dirty flag, you will be able to tell when the other code reloads the world |
| 03:54.31 | scanline | captain_proton: nothing modifies the world without completely reloading it yet |
| 03:54.58 | MrApathyCream | bbi2 |
| 03:55.14 | scanline | it would make lots of sense to add a dirty flag to the scene |
| 03:55.41 | captain_proton | hm, i do mean the scene |
| 03:55.47 | Michaelh | the flags could use some dirt |
| 03:55.49 | scanline | but the problem with dirty flags is that you need one for everything that could consider the scene dirty |
| 03:56.02 | Michaelh | I mean we have grass right? |
| 03:56.09 | scanline | better to have onAddObject and onChangeObject events and use those to change your own dirty flag |
| 03:56.26 | Patlabor221 | the ground needs flair |
| 03:57.24 | scanline | 15 pieces of flair I think |
| 03:57.41 | scanline | or you could put on 37 pieces like that pretty-boy Screamers over there |
| 03:57.47 | sussudio | you're only wearing the minimal amount of flair? |
| 03:57.49 | fiberchunks | lol |
| 03:58.01 | *** join/#bzflag MrApathyCream (dbrosius@balt-209-163-100-209.qis-dynamic-dialup.coretel.net) |
| 03:58.23 | sussudio | i hope your TPS reports are done..... |
| 03:59.38 | Michaelh | tps? |
| 03:59.48 | sussudio | ~google for tps reports |
| 04:00.00 | sussudio | snort. |
| 04:00.26 | Michaelh | ~snort |
| 04:00.26 | | Libpcap packet sniffer/logger/lightweight IDS. URL: http://www.clark.net/~roesch/security.html |
| 04:00.35 | sussudio | ~barf |
| 04:00.36 | MrApathyCream | heh, i lost all my settings |
| 04:00.39 | *** join/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 04:01.01 | sussudio | my capillaries are shrinking |
| 04:01.25 | *** part/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 04:06.35 | scanline | hehe |
| 04:06.41 | scanline | it's really quite simple |
| 04:07.18 | scanline | in your __init__ or similar, call Event.attach(self, 'onFoo', 'onBar') etc |
| 04:07.34 | scanline | each of the functions you named, whether they exist yet or not, are now instances of the Event class |
| 04:08.01 | scanline | if there was already a function of that name, it's still called as normal because it's been registered as an event observer |
| 04:08.08 | scanline | if not, calling the event has no effect |
| 04:08.17 | scanline | you can add additional event observers with the observe() method |
| 04:08.49 | scanline | you can have it print some info when an event is called using the trace() method.. it either takes a format string or a function |
| 04:08.59 | scanline | there are comments in the Event module, you should read them :) |
| 04:09.08 | captain_proton | i've been :P |
| 04:09.13 | scanline | yay |
| 04:09.15 | MrApathyCream | ctfc |
| 04:09.36 | captain_proton | how do the events get triggered? :P |
| 04:10.13 | scanline | you call them |
| 04:10.17 | scanline | the event class is callable |
| 04:10.30 | scanline | that's the cool part.. you can turn a function into an event and it's completely transparent |
| 04:11.16 | captain_proton | so... |
| 04:11.29 | captain_proton | in SceneList, i'd create two events |
| 04:11.48 | scanline | probably better to do it in Scene, since that's the base class |
| 04:11.54 | captain_proton | then the viewer widget would pass it a callback? |
| 04:11.55 | CIA | 03micahjd * 12pybzflag/ (3 files in 2 dirs): Finished implemeting the '-w help' option so people can see how totally overkill the world name format is |
| 04:12.20 | scanline | the viewer would call the event's observe method with the callback |
| 04:12.27 | captain_proton | right |
| 04:12.40 | scanline | yep |
| 04:12.57 | scanline | then the observer gets called with the same args as the event |
| 04:14.38 | scanline | hooray for being able to view world files from the cache |
| 04:14.43 | scanline | ./worldviewer.py binary:~/.bzflag-cache/pbba2bd62bbf61eca1adb52b95697858e.bwc |
| 04:17.28 | captain_proton | erg! |
| 04:17.37 | captain_proton | AttributeError: SceneList instance has no attribute 'onAddObject' |
| 04:18.01 | scanline | you passed self as the first param to Event.attach()? |
| 04:18.06 | captain_proton | yep |
| 04:18.13 | scanline | commit and I'll take a look |
| 04:22.20 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (3 files in 3 dirs): eventage |
| 04:22.59 | scanline | ha |
| 04:23.18 | Patlabor221 | ok cap, I have a leenox question |
| 04:23.26 | Patlabor221 | BZ says it can't find -lX11 |
| 04:23.29 | scanline | captain_proton: so, what would I do to trigger the problem? |
| 04:23.44 | captain_proton | try running something |
| 04:23.45 | scanline | er wait, I should cvs up first |
| 04:23.47 | captain_proton | like...worldviewer |
| 04:24.00 | scanline | ran stuff and it worked... didn't realize I forgot cvs up :) |
| 04:24.25 | scanline | oh |
| 04:24.31 | scanline | SceneList isn't calling Scene's __init__ |
| 04:24.47 | bryjen | Patlabor221: compiling or running? |
| 04:25.53 | CIA | 03micahjd * 12pybzflag/BZFlag/World (Scene.py): Fix scene events |
| 04:26.47 | CIA | 03micahjd * 12pybzflag/BZFlag/UI/Objects (.cvsignore): Keep CVS quiet |
| 04:26.59 | Patlabor221 | compiling |
| 04:27.09 | Patlabor221 | it says /usr/bin/ld: cannot find -lX11 |
| 04:27.27 | sussudio | so install da devlibs. |
| 04:27.39 | Patlabor221 | no shit there manard, I did |
| 04:27.46 | bryjen | linking. where's your libX11.so ? |
| 04:27.51 | Patlabor221 | or least I think I did |
| 04:27.57 | Patlabor221 | that I don't know |
| 04:28.01 | Patlabor221 | where should it be? |
| 04:28.12 | bryjen | probly /usr/X11R6/lib |
| 04:28.38 | scanline | well, that's fine too |
| 04:28.55 | captain_proton | Patlabor221: check to see that /usr/X11R6/lib is in /etc/ld.so.conf |
| 04:29.15 | sussudio | you're not running debian, are you? |
| 04:29.28 | bryjen | part of X. really suprised if its not there. was there an -L/usr/X11R6/lib the gcc command ? |
| 04:29.37 | Patlabor221 | it's in there |
| 04:29.48 | Patlabor221 | in /user/X11R6/lib |
| 04:30.39 | Patlabor221 | yeah cap it's in the conf |
| 04:30.47 | Patlabor221 | it's the only line in the conf |
| 04:31.54 | sussudio | Patlabor221: do you have xlibmesa-gl-dev xlibmesa-glu-dev and xlibs-dev installed? |
| 04:32.59 | Patlabor221 | yeah I did all those |
| 04:33.43 | Patlabor221 | it was geeking on the gl headers so I put all those in |
| 04:33.49 | scanline | captain_proton: hmm.. on the outside, shadow conflict doesn't appear to have changed |
| 04:34.01 | captain_proton | scanline: nope! |
| 04:34.24 | Patlabor221 | and when I got this error X11 error I did the xlibs |
| 04:34.30 | Patlabor221 | and it said they were allready in |
| 04:35.22 | bryjen | Patlabor221: in the last gcc/g++ statment before the error, is there an -L/usr/X11R6/lib ? |
| 04:37.22 | *** join/#bzflag Patlabordeb (~jeffm@adsl-64-172-197-186.dsl.lsan03.pacbell.net) |
| 04:37.28 | Patlabordeb | in some text |
| 04:37.31 | *** join/#bzflag darkmilk (~chatzilla@1Cust246.tnt2.cbr2.da.uu.net) |
| 04:37.31 | Patlabordeb | c++ -fno-exceptions -O2 -ffast-math -fomit-frame-pointer -fexpensive-optimizations -o bzflag MainWindow.o ControlPanel.o World.o SceneBuilder.o SceneRenderer.o BackgroundRenderer.o RadarRenderer.o HUDRenderer.o HUDui.o ShotPath.o ShotStrategy.o Region.o RenderNode.o Player.o playing.o LocalPlayer.o RemotePlayer.o RobotPlayer.o DeadPlayer.o ServerLink.o PlayerLink.o KeyMap.o daylight.o texture.o resources.o sound.o bzflag.o |
| 04:37.32 | Patlabordeb | <PROTECTED> |
| 04:37.32 | Patlabordeb | /usr/bin/ld: cannot find -lX11 |
| 04:37.34 | Patlabordeb | collect2: ld returned 1 exit status |
| 04:39.32 | learner | you're mmissing your include dirs.. |
| 04:39.47 | bryjen | no -I or -L . hmm |
| 04:39.50 | Patlabor221 | I just ran the autoconf thing |
| 04:39.57 | learner | looks like autoconf borked |
| 04:40.22 | learner | I can tell you the one-time fix.. |
| 04:40.37 | Patlabor221 | I'm rerunning the auto stuff |
| 04:40.45 | CIA | 03micahjd * 12pybzflag/ (README): Update info on dependencies and command line options |
| 04:40.51 | learner | and ./configure ... |
| 04:40.58 | Patlabor221 | yeah all of them |
| 04:41.02 | Patlabor221 | it's making now |
| 04:41.18 | learner | someone had a problem with a stray "C" in the configure file earlier |
| 04:41.23 | learner | make sure it's not dying on you |
| 04:41.48 | Patlabor221 | I didn't see any errors in configure |
| 04:42.47 | Patlabor221 | this is 1.7 |
| 04:42.54 | learner | eek |
| 04:43.08 | Patlabor221 | is 1.7 borked? |
| 04:43.46 | learner | um.. aren't you on windows and isn't there an msvs project?? |
| 04:44.47 | Patlabor221 | this is not on windows |
| 04:45.13 | learner | heh, silly me.. clearly -- now that I read the previous.. |
| 04:46.39 | scanline | captain_proton: I think to get a decent looking (filtered with alpha) overhead view I might need to use PIL and do that oversampling hack I use for my disk pie charts :) |
| 04:46.58 | captain_proton | evil |
| 04:47.06 | captain_proton | but PIL would be good |
| 04:47.12 | captain_proton | so that you could do web-page type things |
| 04:47.26 | iLLf8d | I bbl |
| 04:47.47 | captain_proton | hrmph |
| 04:48.45 | Patlabor221 | 1.9 won't make the bzfs executable |
| 04:49.08 | Patlabor221 | well at least nothing is crashing |
| 04:49.10 | Patlabor221 | or restarting |
| 04:51.01 | scanline | captain_proton: yep.. will probably have module to generate an overhead view with PIL, then that could be used on the web or used as a background image in pygame |
| 04:51.24 | scanline | though I hope there's a better way to get images from PIL to pygame than exporting to BMP and importing |
| 04:54.40 | scanline | aha, pygame has fromstring/tostring stuff like PIL does |
| 04:55.06 | bzgirl | goodnight |
| 04:55.13 | Patlabor221 | night |
| 04:55.16 | scanline | hm, this could also benefit by using textures for boxes, pyramids, and grass |
| 04:55.28 | scanline | shall I set up some sort of a data directory? |
| 04:55.32 | Patlabor221 | am I just suposed to do a "make" after I config an all that? |
| 04:56.19 | captain_proton | scanline: would you be super-opposed to me subclassing scene within the 3d view? |
| 04:56.45 | scanline | captain_proton: should be fine.. the World gives you a way to override the scene class, right? |
| 04:57.08 | bryjen | Patlabor221: yes. after configure completes. make |
| 04:57.16 | captain_proton | scanline: err |
| 04:57.19 | scanline | oh |
| 04:57.22 | scanline | can I nuke 3dobserver.py? |
| 04:57.27 | captain_proton | yeah, go ahead |
| 04:57.46 | captain_proton | scanline: i need something that covers more than just the world |
| 04:58.09 | Patlabor221 | it says "nothing to be done for 'all'." for the src/bzflag forlder |
| 04:58.16 | scanline | you can't just stick other objects like the ground and UI-thingies into the scene? |
| 04:58.25 | captain_proton | hrm... |
| 04:58.30 | scanline | hmm... |
| 04:58.39 | scanline | this scene/world stuff needs rearchitecting |
| 04:58.58 | scanline | how about separating scene from world, and instead of world loading data into a scene, you can ask a world to add its contents to a scene? |
| 04:59.10 | captain_proton | that sounds ideal |
| 04:59.24 | *** join/#bzflag DB7654322 (~DB7654321@chcgil2-ar7-4-3-184-165.chcgil2.dsl-verizon.net) |
| 04:59.28 | scanline | that means each view would have its own scene, which it would load on onLoadWorld() |
| 04:59.36 | captain_proton | i'd also like a way for every object to have a unique identifier |
| 04:59.50 | bryjen | Patlabor221: make clean and then make |
| 04:59.52 | scanline | problem is, you'd need something special to run two views off of one scene so that they update each other |
| 04:59.54 | captain_proton | so if the world changes, the scene can update only the objects that changed |
| 05:00.10 | scanline | all python objects already have a unique identifier |
| 05:00.18 | scanline | id(object) |
| 05:00.30 | captain_proton | hmm |
| 05:00.39 | scanline | plus you can test whether two objects are the same instance with the 'is' operator |
| 05:00.40 | Patlabor221 | I have done that like 3 times bryjen :( |
| 05:02.36 | scanline | so what if you want two views that see the same scene, so changes from one show up in the other? |
| 05:02.39 | Patlabor221 | it says lots of "Nothing to be done for 'all-am'." |
| 05:03.26 | captain_proton | scanline: i think most of those situations are actually changes in the underlying world |
| 05:03.44 | scanline | captain_proton: right, but that brings up the question of how often you would update the world from the scene |
| 05:03.50 | MrApathyCream | Patlabor221: the bz dev platform of choice loves you |
| 05:04.03 | captain_proton | i would say never |
| 05:04.33 | Patlabor221 | I do know I am the anti-linux |
| 05:04.33 | scanline | so multiple views wouldn't work? |
| 05:04.39 | Patlabor221 | but it's getting better |
| 05:04.52 | Patlabor221 | least the OS dosn't crash now when I compile an app |
| 05:05.06 | bryjen | in the top level, the one with the Changelog and README, do ./autogen.sh && ./configure && make |
| 05:05.10 | captain_proton | they would |
| 05:05.22 | captain_proton | the view would update the world, which would trigger scene changes in both |
| 05:05.23 | scanline | captain_proton: or.. we could keep the scene the way it is and you could add your own objects to it and add handlers to everything |
| 05:05.58 | scanline | I guess my big question is, what do you see the point of the scene being? |
| 05:06.13 | scanline | I originally added it to provide efficient methods for traversing the world, assuming I'd do an octree later |
| 05:06.25 | captain_proton | view-specific data storage |
| 05:06.42 | scanline | ok. What data exactly? |
| 05:06.57 | captain_proton | in my case, it would have a bunch of drawables, sorted by texture |
| 05:07.41 | scanline | hmm.. and there's no good way to do the texture sort in a way that's both Scene-independant and View-independant |
| 05:08.05 | captain_proton | well what i'm saying is that the texture sort would be the scene's job |
| 05:08.15 | scanline | ok, so let's say you update the world, then it's the view's responsibility to use a scene if it wants to. I suppose we'd just have onAddObject, onRemove, onChange, etc. on the world then? |
| 05:08.18 | scanline | right |
| 05:08.42 | scanline | hehe |
| 05:08.43 | captain_proton | yes, the world would notify any listening scenes |
| 05:09.00 | scanline | so, really simple views like OverheadView could just skip the scene |
| 05:09.08 | captain_proton | as would any other drawing objects, such as flags, players, etc |
| 05:09.11 | scanline | just register a handler for any world change that redraws the view |
| 05:09.16 | captain_proton | yep |
| 05:09.24 | scanline | that works |
| 05:09.36 | scanline | so I'll just nuke Scene and add those events to World |
| 05:09.55 | captain_proton | and then i can have multi-paned 3d viewers in the editor, each with its own set of editing "widgets" |
| 05:10.01 | scanline | :) |
| 05:10.12 | scanline | and the message packets |
| 05:10.16 | scanline | ooh.. UDP widgets! |
| 05:10.22 | captain_proton | yep! |
| 05:10.28 | captain_proton | quick, lets hit #gtk+ |
| 05:10.39 | scanline | :) |
| 05:10.46 | scanline | so.. about these events... |
| 05:10.50 | captain_proton | ooh, that'd piss ' |
| 05:10.53 | captain_proton | em off good |
| 05:10.59 | captain_proton | udp is NOT A WIDGET DAMNIT! |
| 05:11.02 | scanline | I suppose they would only be sent during editor-type operations, not during world loading? |
| 05:11.08 | scanline | there would be a separate event for completing a world load |
| 05:11.13 | scanline | oh hm.... |
| 05:11.41 | captain_proton | world loads usually happen before a viewer is attached, no? |
| 05:11.49 | scanline | if the world gets useful events, I should change things so the world object doesn't get thrown away whenever the world is reloaded, instead the world just gets loaded into the existing object |
| 05:11.58 | captain_proton | what could happen is that when the view/scene subscribes to those events, they get sent a load event |
| 05:12.16 | scanline | well, right now the views load right away, and the world will load after it's downloaded and such |
| 05:12.29 | scanline | so in overheadview for example, you see a blank world until the real one loads |
| 05:12.46 | captain_proton | ah |
| 05:12.50 | scanline | right, I'd just add another event for loading... the issue was that the world object gets discarded |
| 05:12.55 | scanline | so I'll just have to change that |
| 05:12.58 | captain_proton | there needs to be some sort of 'drawable list' |
| 05:13.12 | captain_proton | so that its easy for a view to subscribe to all the things it wants to display |
| 05:13.34 | scanline | how about just onLoad, onAdd, onRemove, onModify handlers? |
| 05:13.48 | scanline | where add, remove, and modify wouldn't be sent during loading |
| 05:14.12 | captain_proton | so the scene has to individually query players, world, flags to get notified for everything? |
| 05:14.53 | scanline | well, yes. We could have a way of combining those in the Game object |
| 05:15.22 | Patlabordeb | bahh configure says GL insn't installed but I've put in ever package I can find |
| 05:15.35 | scanline | you wouldn't have an event for each player/worldobject/flag, but for each player list, flag list, world |
| 05:16.14 | captain_proton | well |
| 05:16.30 | captain_proton | each update call should be for a single drawable item, and include that item's id |
| 05:16.38 | scanline | right |
| 05:16.42 | MrApathyCream | Heh, Bad flags are immediately dropped when you shoot... oops |
| 05:16.45 | MrApathyCream | checkin... |
| 05:16.49 | scanline | so here's another world issue.... |
| 05:17.01 | scanline | the world keeps objects in a flat list in the order they were stored in on disk or whatever |
| 05:17.20 | scanline | I think the world shouldn't even attempt to separate objects out based on type, but that should be the scene's job |
| 05:17.37 | scanline | so the world's events point to WorldObjects in the blocks list |
| 05:18.12 | bryjen | Patlabordeb: is your libGL.so also in /usr/X11R6/lib ? |
| 05:19.26 | Patlabor221 | no it does not look like it is |
| 05:19.31 | MrApathyCream | flagLimits again |
| 05:21.53 | CIA | 03micahjd * 12pybzflag/ (5 files in 3 dirs): Remove Scene and SceneList, add some world events that won't work right until I fix it so game.world doen't get nuked on world load |
| 05:22.25 | bryjen | Patlabor221: libGL.so should be in a lib dir somewhere and gl.h should be under an include |
| 05:22.29 | captain_proton | scanline: as long as i can force the object in question to give me its geometry |
| 05:23.18 | Patlabordeb | I have a ligGL.so.1 in /usr/lib |
| 05:23.27 | scanline | captain_proton: yep |
| 05:24.02 | bryjen | gl.h is probly in /usr/include or /usr/include/GL |
| 05:25.32 | Patlabordeb | it's not |
| 05:25.39 | Patlabordeb | damn I must be missing a package |
| 05:25.44 | Patlabordeb | I just don't know what it's name is |
| 05:25.58 | MrApathyCream | wow, what happened to my clOptions fix |
| 05:26.03 | MrApathyCream | did someone roll that back? |
| 05:26.07 | bryjen | try locate /gl.h |
| 05:26.25 | Patlabordeb | no suck file or dir |
| 05:27.06 | bryjen | heh. I wonder how you got all the way to linking bzflag before..... |
| 05:27.15 | Patlabor221 | I don't know |
| 05:28.20 | MrApathyCream | scanline borked my checkin |
| 05:28.23 | MrApathyCream | bad, bad, scanline |
| 05:28.24 | MrApathyCream | :) |
| 05:28.28 | scanline | oh no! |
| 05:28.31 | scanline | what'd I do? |
| 05:28.40 | MrApathyCream | you didn't merge your changes |
| 05:28.55 | CIA | 03micahjd * 12pybzflag/ (6 files in 5 dirs): Fix world loading events |
| 05:28.57 | scanline | hmm. which? |
| 05:28.58 | MrApathyCream | i changed clOptions to a pointer, to avoid global init problems, and you undid it |
| 05:29.02 | MrApathyCream | fixing |
| 05:29.26 | scanline | oh? I don't think I committed anything in bzfs since the little overnight hackfest |
| 05:30.11 | captain_proton | ... |
| 05:30.19 | captain_proton | cvs will warn if your files aren't up to date when you commit |
| 05:30.54 | scanline | well, if you have an old file open in an editor and don't reload it when you cvs up, that could cause it |
| 05:30.55 | MrApathyCream | Update of /cvsroot/bzflag/bzflag/src/bzfs |
| 05:30.57 | MrApathyCream | In directory sc8-pr-cvs1:/tmp/cvs-serv12837 |
| 05:30.57 | MrApathyCream | Modified Files: |
| 05:30.57 | MrApathyCream | bzfs.cxx |
| 05:30.57 | MrApathyCream | Log Message: |
| 05:30.57 | MrApathyCream | Removing code to disable UDP link in addPlayer. This would break UDP if a client enabled its UDP connection, but then didn't send any more UDP messages after etnering the game. |
| 05:30.59 | MrApathyCream | Index: bzfs.cxx |
| 05:31.01 | MrApathyCream | =================================================================== |
| 05:31.03 | captain_proton | scanline: perhaps... |
| 05:31.04 | MrApathyCream | RCS file: /cvsroot/bzflag/bzflag/src/bzfs/bzfs.cxx,v |
| 05:31.06 | MrApathyCream | retrieving revision 1.226 |
| 05:31.07 | MrApathyCream | retrieving revision 1.227 |
| 05:31.08 | scanline | ah |
| 05:31.10 | MrApathyCream | diff -w -u -r1.226 -r1.227 |
| 05:31.11 | MrApathyCream | --- bzfs.cxx 11 Jul 2003 02:57:38 -0000 1.226 |
| 05:31.13 | MrApathyCream | +++ bzfs.cxx 11 Jul 2003 04:31:02 -0000 1.227 |
| 05:31.15 | MrApathyCream | @@ -17,10 +17,10 @@ |
| 05:31.17 | scanline | I see... |
| 05:31.18 | MrApathyCream | <PROTECTED> |
| 05:31.19 | MrApathyCream | <PROTECTED> |
| 05:31.23 | captain_proton | some of us have editors that warn when the file changed underneith you |
| 05:31.24 | MrApathyCream | <PROTECTED> |
| 05:31.25 | MrApathyCream | -#define DEBUG1 if (clOptions->debug >= 1) printf |
| 05:31.27 | MrApathyCream | -#define DEBUG2 if (clOptions->debug >= 2) printf |
| 05:31.29 | MrApathyCream | -#define DEBUG3 if (clOptions->debug >= 3) printf |
| 05:31.32 | MrApathyCream | -#define DEBUG4 if (clOptions->debug >= 4) printf |
| 05:31.33 | MrApathyCream | +#define DEBUG1 if (clOptions.debug >= 1) printf |
| 05:31.35 | scanline | captain_proton: well, emacs does that too... so I dunno how it could have happened |
| 05:31.36 | MrApathyCream | +#define DEBUG2 if (clOptions.debug >= 2) printf |
| 05:31.38 | MrApathyCream | +#define DEBUG3 if (clOptions.debug >= 3) printf |
| 05:31.39 | MrApathyCream | +#define DEBUG4 if (clOptions.debug >= 4) printf |
| 05:31.41 | MrApathyCream | [...1190 lines suppressed...] |
| 05:31.49 | scanline | MrApathyCream: this isn't #commits |
| 05:32.07 | MrApathyCream | heh |
| 05:33.30 | scanline | captain_proton: so, that last commit should have put the events and such into a reasonable state... game.world will not go poof on load any more, it has an onLoad event, and Scene is dead |
| 05:33.54 | scanline | it also has onAdd, onModify, and onRemove events, but since nothing edits the map after loading yet they aren't wired to anything |
| 05:35.45 | captain_proton | yay for hawaiian shirt day |
| 05:36.04 | scanline | darnit captain_proton, I'm gonna have to watch office space now |
| 05:36.19 | captain_proton | hehe |
| 05:36.50 | CIA | 03dbrosius * 12bzflag/src/bzfs (bzfs.cxx): recheck in the global init order bug fix (make clOptions a ptr) fix got lost in a later checkin |
| 05:36.54 | scanline | using up valuable space on my video card that doesn't screw up my sound card when it has activity |
| 05:36.58 | captain_proton | there's far too much in the cs dept thats similar to office space |
| 05:37.13 | scanline | spacegrant has TPS reports for DINO |
| 05:37.25 | captain_proton | they do? :) |
| 05:37.39 | scanline | yep... Tradoff Performance Somethings or something like that |
| 05:38.07 | scanline | 100% purebred backronym |
| 05:59.05 | *** join/#bzflag NinjaSocks (~jeffm@adsl-64-172-197-186.dsl.lsan03.pacbell.net) |
| 05:59.29 | *** mode/#bzflag [+o Patlabor221] by ChanServ |
| 06:02.01 | *** join/#bzflag spanky1 (~weaver@pppoe1368.ka.centurytel.net) |
| 06:02.54 | MrApathyCream | c |
| 06:04.05 | spanky1 | mmm....quiet |
| 06:04.20 | MrApathyCream | yup |
| 06:04.50 | Patlabor221 | yay, BZEdit now has plugins |
| 06:05.46 | MrApathyCream | xmission has a 3500 second bad flag timeout, wonder if thats a bug, or riker is loopy (or perhaps both) |
| 06:06.58 | scanline | whee |
| 06:07.05 | scanline | this looks so much better with PIL + oversampling |
| 06:07.25 | scanline | now it just needs antialiasing and some color scheme tweakage |
| 06:07.26 | spanky1 | I was going to say I Like your site MrApathyCream but I see its no longer there?? |
| 06:07.29 | scanline | er |
| 06:07.32 | scanline | s/antialiasing/alpha/ |
| 06:07.40 | MrApathyCream | spanky1: bzflag.mebigfatguy.com |
| 06:07.55 | spanky1 | LOL thanks |
| 06:08.44 | CIA | 03jeffm2501 * 12bzeditw32/BZEdit32 (15 files): Update for Plugins |
| 06:09.18 | CIA | 03jeffm2501 * 12bzeditw32/_test/plugins (3 files): Directory /cvsroot/bzflag/bzeditw32/_test/plugins added to the repository |
| 06:11.09 | CIA | 03jeffm2501 * 12bzeditw32/samplePlugin (3 files): Directory /cvsroot/bzflag/bzeditw32/samplePlugin added to the repository |
| 06:11.41 | CIA | 03jeffm2501 * 12bzeditw32/samplePlugin/res (3 files): Directory /cvsroot/bzflag/bzeditw32/samplePlugin/res added to the repository |
| 06:12.26 | CIA | 03jeffm2501 * 12bzeditw32/ (11 files in 3 dirs): sample plugin stuff |
| 06:12.30 | Patlabor221 | well now MAC you can make your REAL dupe and rotate function :) |
| 06:13.04 | learner | ah.. that was good |
| 06:13.46 | learner | 200 kills, on top almost the entire time :) |
| 06:14.02 | MrApathyCream | w00t |
| 06:14.22 | learner | poor newbies on jb and head's team :) |
| 06:14.22 | MrApathyCream | learner: 1.9? |
| 06:14.41 | learner | no, mac, ducati-style |
| 06:14.50 | learner | what's up with ducati? |
| 06:14.56 | learner | seems down |
| 06:15.04 | learner | ~d |
| 06:15.13 | learner | hrm |
| 06:15.26 | learner | maybe just isn't in the list |
| 06:15.44 | learner | or maybe I've just had too much -OH |
| 06:15.52 | JBDiGriz | not a bad game at all! over 100 kills, and I almost kept up with learner |
| 06:16.03 | learner | heheh you did :) |
| 06:16.17 | learner | you did seem a bit slower tonight, though ;) |
| 06:16.41 | JBDiGriz | Riker showed up for a while, as well as bzg. The arrogant newbies were a bit annoying! |
| 06:16.48 | scanline | ooh |
| 06:16.53 | learner | ooo.. tomorrows the network chat thing isn't it |
| 06:16.56 | learner | Riker?! |
| 06:17.00 | learner | aw man |
| 06:17.03 | scanline | the maps actually look really nice with about a 1/2 pixel black border on all objects |
| 06:17.06 | JBDiGriz | Playing as kode |
| 06:17.17 | learner | never played "the man" afaik |
| 06:17.44 | learner | was he there after I joined, jb? |
| 06:17.46 | JBDiGriz | Tomorrow at 1900UTC, 1200PDT, and 1500 EDT |
| 06:17.59 | learner | it's burnt into me brainy |
| 06:18.03 | JBDiGriz | You would have noticed that his email was tim@riker.org |
| 06:18.05 | learner | here, yes? |
| 06:18.15 | JBDiGriz | this bat channel! |
| 06:18.18 | learner | hehe, a giveaway |
| 06:18.48 | JBDiGriz | He was at xmission last night, and I played on his team for a while. |
| 06:18.54 | learner | maybe later we'll see henry@rikers.org :) |
| 06:19.07 | JBDiGriz | I'm waiting to see will@riker.org |
| 06:19.21 | learner | did you get him good on that last server? :) |
| 06:19.41 | JBDiGriz | Occasionally, and he did the same to me! |
| 06:20.26 | learner | Head's certainly getting better.. |
| 06:20.36 | learner | I remember showing him some moves months ago.. |
| 06:20.43 | learner | now he uses them against me! |
| 06:21.03 | JBDiGriz | He used to push me around a lot, now we're just about even most of the time. |
| 06:21.42 | learner | heh |
| 06:21.51 | scanline | http://navi.picogui.org/~micah/tmp/world_thumb.png |
| 06:22.56 | learner | cute |
| 06:23.09 | learner | perhaps some depth color? |
| 06:23.27 | scanline | yep.. I was hoping to do depth alpha, but PIL doesn't seem to be alpha-friendly yet |
| 06:23.45 | scanline | I also need to get it to Z sort before drawing |
| 06:24.12 | learner | you could just do the color delta yourself |
| 06:24.34 | scanline | how is that alpha? |
| 06:24.36 | learner | not that you didn't know that already.. :) |
| 06:25.11 | learner | eh? it wouldn't be an alpha blend, per se |
| 06:25.29 | scanline | right.. I was hoping to do real alpha, for the same effect as the radar |
| 06:25.36 | learner | you could just color lighter as you box tops are higher |
| 06:25.43 | scanline | yep |
| 06:25.50 | scanline | that's the fallback :) |
| 06:26.09 | learner | it's opengl, then, I take it? |
| 06:26.36 | scanline | no, I'm doing this in PIL |
| 06:26.43 | scanline | if it was OpenGL I'd have no problem with alpha |
| 06:26.59 | learner | hmm |
| 06:27.07 | scanline | I'm working on the non-OpenGL overhead view, captain_protons |
| 06:27.13 | scanline | er, captain_proton's doing an OpenGL 3D view |
| 06:27.35 | learner | ah |
| 06:31.58 | scanline | hrmph... mediocre |
| 06:32.10 | scanline | http://navi.picogui.org/~micah/tmp/world_thumb.png |
| 06:33.58 | learner | hrm.. dark should probably be far, light is close |
| 06:34.09 | scanline | right, I've been playing with that |
| 06:34.12 | scanline | still doesn't look good |
| 06:34.44 | scanline | hmm.. this one's not as bad |
| 06:34.52 | scanline | http://navi.picogui.org/~micah/tmp/world_thumb.png |
| 06:35.20 | Patlabor221 | hows this for a cluttered map, http://www.bakadigital.com/clutter.jpg |
| 06:35.25 | learner | better.. what's the black? |
| 06:35.44 | scanline | learner: short boxes, apparently |
| 06:36.09 | scanline | it's a bit fidgety just scaling RGB colors like this |
| 06:36.29 | learner | probably would look better if nothing was darker than the ground.. |
| 06:36.43 | learner | intensity-wise at least |
| 06:36.53 | learner | that is a cluttermap, pat.. :) |
| 06:36.54 | scanline | Patlabor221: heheh... in pybzflag I implemented the bzfs random world generator algorithm, but made all the parameters tweakable, so you can have the same algorithm automatically make a map like that |
| 06:37.16 | captain_proton | scanline: thats...beautiful |
| 06:37.19 | Patlabor221 | I did automaticly make a world like that :) |
| 06:37.24 | scanline | captain_proton: haha |
| 06:37.27 | Patlabor221 | that's from the random boxes plugin |
| 06:39.11 | CIA | 03micahjd * 12pybzflag/ (2 files in 2 dirs): Some PIL-based overhead mappystuff. Still needs color tweaking, and need to make the pygame overhead view use this as a background. |
| 06:42.00 | captain_proton | oog |
| 06:42.05 | captain_proton | i actually have to get up in the morning tomorrow |
| 06:42.21 | scanline | doh |
| 06:51.27 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/World (World.py): get rid of the fargin trailing whitespace |
| 06:52.22 | captain_proton | so i want to iterate on world.blocks? |
| 06:52.26 | scanline | yes |
| 06:54.26 | captain_proton | how do i get the type of a variable? |
| 06:54.40 | scanline | type(foo) |
| 06:56.05 | captain_proton | hrm - block 137289884 is a <type 'instance'> |
| 06:56.22 | scanline | you probably want foo.__class__ |
| 06:56.28 | captain_proton | likely |
| 06:56.30 | scanline | or foo.__class__.__name__ |
| 06:56.44 | captain_proton | ooh sexy |
| 06:56.55 | captain_proton | block 137288684 is a BZFlag.Protocol.WorldObjects.Teleporter |
| 06:57.45 | scanline | hrm.. |
| 06:59.03 | captain_proton | i think a dict from the id to the object in question |
| 06:59.48 | scanline | why dict from the id when you can dict from one object to the other? |
| 06:59.56 | captain_proton | hmm |
| 06:59.58 | captain_proton | thats a good point |
| 07:00.12 | captain_proton | so dict from the object straight to a list of its drawables? |
| 07:00.28 | scanline | yep |
| 07:01.08 | scanline | er, TCP sockets and UDP addresses |
| 07:01.22 | captain_proton | and then i can build another dict mapping texture id to drawable |
| 07:02.31 | scanline | texture id? |
| 07:02.38 | captain_proton | yep |
| 07:02.57 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (OverheadView.py): Z sorting, and automatic coloring that might suck a little less |
| 07:03.09 | scanline | how are you determining which texture to use for each object.. a dict from the object's class to a texture instance? |
| 07:03.28 | scanline | that would make it really easy to assign one texture for walls, one for boxes, etc. |
| 07:03.48 | captain_proton | thats what i was a'thinkin |
| 07:04.02 | captain_proton | or more exactly |
| 07:04.02 | scanline | Normally this is the sort of thing you'd just store as attributes of the object, but this method keeps things happy with multiple views :) |
| 07:04.17 | captain_proton | a dict from a specific drawable type to a texture instance |
| 07:04.32 | learner | er.. quick question: are we main () { |
| 07:04.34 | learner | or main() |
| 07:04.35 | learner | { |
| 07:04.40 | captain_proton | main() |
| 07:04.40 | captain_proton | { |
| 07:04.42 | learner | thx |
| 07:04.45 | captain_proton | its all in DEVINFO |
| 07:04.47 | scanline | so how about texture coordinates? I guess they're always done the same way in bz... |
| 07:04.51 | captain_proton | if you would choose to read it ;) |
| 07:04.53 | learner | you were quicker :) |
| 07:04.55 | learner | thx |
| 07:05.08 | learner | I've read it twice too :P |
| 07:05.29 | captain_proton | scanline: a drawable mostly consists of a function to generate the display list & the list id |
| 07:05.45 | captain_proton | err |
| 07:05.52 | captain_proton | rather, the world object generates the list |
| 07:06.11 | scanline | captain_proton: I saw something while I was looking through pygame stuff about a higher level python module for managing opengl state |
| 07:06.11 | captain_proton | then provides a function that calls the list |
| 07:06.36 | captain_proton | eh - not really necessary |
| 07:06.51 | captain_proton | so long as every drawable cleans up after itself, it'll be find |
| 07:06.54 | captain_proton | fine* |
| 07:07.01 | scanline | http://pyopengl.sourceforge.net/pydoc/OpenGLContext.html |
| 07:07.13 | scanline | looks like glut-type stuff |
| 07:07.21 | scanline | hmm |
| 07:07.24 | scanline | quaternion module :) |
| 07:07.34 | scanline | renderpass, rendervisitor, scenegraph, shadow... |
| 07:07.36 | scanline | interesting |
| 07:07.44 | captain_proton | quaternion is part of pyopengl, rather than openglcontext |
| 07:12.14 | captain_proton | hrm |
| 07:12.21 | captain_proton | does python cache importings? |
| 07:12.26 | scanline | yes |
| 07:12.34 | captain_proton | good, good |
| 07:12.51 | scanline | there's a list in sys that has all modules, it checks there before trying to load it |
| 07:13.06 | *** join/#bzflag DB7654321 (~DB7654321@chcgil2-ar7-4-3-184-165.chcgil2.dsl-verizon.net) |
| 07:14.48 | CIA | 03micahjd * 12pybzflag/ (2 files in 2 dirs): Tweak the map coloring algorithm to use the mean height as a reference. Seems to work far better |
| 07:17.16 | captain_proton | erg, python.org is down |
| 07:17.29 | scanline | file:///usr/share/doc/python-docs-2.2.2/html/index.html |
| 07:17.34 | captain_proton | heh |
| 07:18.02 | captain_proton | heeey, lookie there |
| 07:22.40 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (OverheadView.py): Fix OverheadView to use worldToImage |
| 07:23.42 | CIA | 03micahjd * 12pybzflag/ (worldthumbnail.py): Generate thumbnails that are actually thumbnail size |
| 07:25.07 | scanline | hmm, brlcad.org has a :4243 now |
| 07:25.20 | *** join/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 07:25.20 | scanline | taking a while to download the world... |
| 07:25.22 | captain_proton | AttributeError: OverheadView instance has no attribute 'worldToView' |
| 07:25.34 | captain_proton | pops up the world correctly then dies |
| 07:25.36 | scanline | I just fixed that, lemme commit |
| 07:26.10 | *** part/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 07:26.24 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (OverheadView.py): Fix worldToView in OverheadView |
| 07:27.27 | captain_proton | sexy =) |
| 07:27.38 | scanline | the colors still could use tweaking though |
| 07:27.49 | captain_proton | care to connect to xmission with a real client? |
| 07:28.02 | scanline | k |
| 07:28.49 | captain_proton | wow |
| 07:28.51 | captain_proton | thats one ugly tank |
| 07:29.29 | captain_proton | erg |
| 07:29.32 | captain_proton | idlekick |
| 07:29.38 | captain_proton | oh well, the world is pretty =) |
| 07:29.41 | scanline | stick the @ in your nick |
| 07:30.10 | scanline | I want to see the pretty world and ugly tank too! |
| 07:30.44 | scanline | or were you talking about my overhead view? :) |
| 07:30.52 | captain_proton | your overhead view |
| 07:30.56 | scanline | hehe |
| 07:31.01 | scanline | I should get a better tank in there |
| 07:31.24 | scanline | though to make it look good I'd have to prerender stuff... pygame doesn't do anything antialiased |
| 07:31.36 | scanline | and PIL only has a filtered resize |
| 07:32.40 | scanline | yaknow, maybe I should make that coffee I talked about ages ago... |
| 07:36.30 | scanline | methinks... radar view |
| 07:37.53 | scanline | have you thought about how to indicate to the view which player is being followed? |
| 07:38.45 | scanline | perhaps they could default to some neutral state, like the radar unrotated, and the 3D view showing an aerial view.. then you could call a follow() method that would target it. |
| 07:38.55 | scanline | follow(None) and you get the neutral view again |
| 07:39.20 | scanline | so you could do cool following-other-players thingies when an observer |
| 07:39.40 | scanline | hm |
| 07:39.59 | captain_proton | is there a way to find out if an object inherits from another? |
| 07:40.22 | scanline | isinstance(child, parent) |
| 07:41.15 | scanline | or if you have classes not an instance and a class, there's issubclass() |
| 07:42.59 | captain_proton | i've got all instances |
| 07:43.08 | captain_proton | needed to check whether a block was a WorldObject |
| 07:43.21 | scanline | k |
| 07:43.34 | scanline | wow.. excluding optik, this is 5464 lines |
| 07:43.41 | captain_proton | heh |
| 07:43.43 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (2 files in 2 dirs): stuff |
| 07:44.01 | captain_proton | some 69k lines |
| 07:44.05 | captain_proton | iirc |
| 07:44.38 | scanline | 86526 according to wc |
| 07:44.47 | captain_proton | ah |
| 07:45.03 | scanline | 73880 according to sloccount |
| 07:45.14 | captain_proton | i bet we've added 10k recently with all the 1.8 sucking |
| 07:45.16 | captain_proton | or more |
| 07:45.25 | scanline | yay |
| 07:45.43 | scanline | what is BZDB exactly? just a map you can keep parameters in? |
| 07:46.29 | captain_proton | at its most basic level, yes |
| 07:46.42 | scanline | ah, but of course it's not that basic :) |
| 07:47.07 | captain_proton | its like a really fancy map that you can keep parameters in |
| 07:47.14 | captain_proton | really really fancy |
| 07:47.36 | scanline | so I assume it's all persistent... what else makes it fancy? |
| 07:47.57 | scanline | SQL? :) |
| 07:48.06 | captain_proton | it can evaluate expressions (and pull $variables from itself), keep track of which variables are supposed to be persistent (writted to config), has access control (which isn't quite so important at the moment, since we don't have a console or server access) |
| 07:48.09 | captain_proton | lets see, what else... |
| 07:48.23 | scanline | ooh, fancy |
| 07:48.43 | captain_proton | you can set callbacks for a value, so when it changes parts of the program that care about it will be notified... |
| 07:49.29 | scanline | fancy indeed |
| 07:49.30 | captain_proton | in python, two underscores means "private" ? |
| 07:50.01 | captain_proton | eh, i don't need it private |
| 07:50.03 | scanline | yes.. it does this name mangling stuff.. I hardly ever see it as worthwhile though |
| 07:50.23 | scanline | one underscore is traditional for private stuff though it doesn't actually affect anything in the interpeter |
| 07:50.31 | scanline | I still hardly ever use that... |
| 07:50.31 | captain_proton | what is the destructor? |
| 07:51.05 | scanline | well... python technically has a destructor, __del__, but you probably don't want to use it since it's uncertain when or if objects get garbage collected |
| 07:51.10 | scanline | what are you trying to use it for? |
| 07:51.51 | captain_proton | i need to check to see if its necessary, but for deleting old display list ids |
| 07:52.04 | scanline | ahh |
| 07:52.20 | captain_proton | yep, need to delete them |
| 07:52.21 | scanline | I'd think pyopengl would have a note about that.. |
| 07:52.31 | captain_proton | pyopengl is pretty much straight swig |
| 07:52.51 | scanline | it's still probably bad to use __del__ though |
| 07:53.24 | scanline | but, eh.. try it and find out :) |
| 07:53.26 | captain_proton | so... |
| 07:54.05 | scanline | the issue with __del__ is that you don't know when it will be called, since it gets called by the garbage collector.. and that objects left over at the end of execution usually don't get del'ed at all |
| 07:54.13 | scanline | but with display lists that shouldn't be an issue I suppose |
| 07:55.21 | *** join/#bzflag [TeA|TrEE] (~[TeA|TrEE@pD9E967C5.dip.t-dialin.net) |
| 07:55.24 | captain_proton | looks like the documentation warns against a bunch of things that don't matter for me |
| 07:55.42 | scanline | ok |
| 07:56.07 | captain_proton | opengl provides a freaking huge number of list ids, but it still made me feel naughty |
| 07:56.33 | scanline | I'd stick a print in there at first to see if it actually frees anything |
| 07:59.03 | captain_proton | at the moment its going to be a while before i ever destroy a drawable (that will happen during editing, but not otherwise) |
| 07:59.21 | scanline | or when the world is reloaded |
| 08:00.23 | captain_proton | what are the two values of wall.size? |
| 08:00.49 | scanline | it's the same vector used in the protocol.. X and Z I believe |
| 08:01.24 | scanline | I should make it unpack to a 3-tuple with a zero in the middle instead, that would remove some of this special case cruft... |
| 08:03.01 | *** join/#bzflag Chikorita (Chikorita@ACACFDFA.ipt.aol.com) |
| 08:03.34 | Chikorita | hey |
| 08:03.38 | Chikorita | all |
| 08:03.40 | scanline | helo |
| 08:03.54 | Chikorita | hi :) |
| 08:03.59 | Chikorita | +l |
| 08:04.18 | scanline | no no, you're supposed to say "501 syntactically invalid HELO argument(s)" |
| 08:04.36 | Chikorita | lol syntax error.. |
| 08:04.43 | Chikorita | reminds mee of basic |
| 08:04.45 | Chikorita | :P |
| 08:04.54 | scanline | or SMTP |
| 08:05.10 | Chikorita | u program 2 much |
| 08:05.17 | Chikorita | u need ums to go outside |
| 08:05.20 | scanline | SMTP isn't a programming language |
| 08:05.22 | Chikorita | an play in da sandbox |
| 08:05.32 | Chikorita | ok im jus sayin tho |
| 08:05.50 | Chikorita | where r u from scanlone? |
| 08:05.53 | Chikorita | line* |
| 08:05.57 | Chikorita | lol ty |
| 08:06.02 | Chikorita | i jus wondering... |
| 08:06.15 | Chikorita | o i luv sand |
| 08:06.21 | scanline | deep in the dungeon of darkness, where the coffee drips quietly on the desk |
| 08:06.24 | Chikorita | i was jus at da beach last week |
| 08:06.35 | Chikorita | umm okkaaayy |
| 08:06.42 | Chikorita | decaff? |
| 08:06.54 | scanline | BANISHMENT! |
| 08:06.58 | Chikorita | noo |
| 08:07.03 | Chikorita | ok i take dat back |
| 08:07.10 | Chikorita | sowee |
| 08:07.16 | Chikorita | i sed da d-werd |
| 08:07.19 | Chikorita | :x |
| 08:07.19 | scanline | mmmyep |
| 08:07.56 | Chikorita | so umm i guess u r like dis all da time >>> O.O |
| 08:08.00 | Chikorita | heehe |
| 08:08.10 | Chikorita | i gettin kinda sleepy meeself... |
| 08:08.10 | scanline | ^_^ |
| 08:08.13 | Chikorita | -.- |
| 08:08.19 | Chikorita | itz like 4am here |
| 08:08.44 | Chikorita | so wut time zone iz da dungeon ur in ? |
| 08:08.59 | scanline | UTC -0600 |
| 08:09.28 | Chikorita | grr |
| 08:10.08 | Chikorita | o.O |
| 08:10.13 | Chikorita | O.o |
| 08:11.04 | Chikorita | how could u b in -0600? dat would put u in da middle of da atlantic ocean?? |
| 08:11.24 | Chikorita | wait ...r u in brazil? |
| 08:11.26 | scanline | or in the middle of the rocky mountains |
| 08:11.40 | scanline | I live in about the same place as captain_proton, if that helps |
| 08:11.50 | Chikorita | o okies |
| 08:12.05 | Chikorita | no it doesnt help , buh o okies |
| 08:12.40 | Chikorita | do u ski by chance? |
| 08:12.45 | Chikorita | i luv skiing |
| 08:13.03 | Chikorita | i almost broke mee leg at breckenridge once like 5 years ago |
| 08:13.18 | scanline | I tried cross-country skiing a couple times, never did downhill |
| 08:13.25 | Chikorita | i remember cuz brecken sounds almost like broken , LoL |
| 08:13.39 | Chikorita | o i c |
| 08:13.46 | scanline | das breckenhausen ist kaput! |
| 08:13.54 | Chikorita | haha |
| 08:13.58 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (2 files in 2 dirs): more progress toward real drawable drawables |
| 08:14.02 | Chikorita | ja woh! |
| 08:14.12 | scanline | ach das schprechenziefoo |
| 08:14.43 | captain_proton | scanline: can 'None' be used as a dictionary key? =) |
| 08:14.50 | scanline | yep |
| 08:14.56 | scanline | almost any object |
| 08:16.18 | Chikorita | sprechen zie langzam bitte meinen deutsh ist nicht gut |
| 08:16.31 | Chikorita | varum ist herr teatree? |
| 08:16.39 | scanline | nicht gut ist deutsh, varuum boingboing? |
| 08:16.47 | Chikorita | LoL |
| 08:17.28 | scanline | sprechen zie blinkenhausen ach ist gutenbroken |
| 08:17.29 | Chikorita | ich toten zie boingboing ;) |
| 08:18.52 | captain_proton | scanline: so...how does one tell if a key is already in a dictionary or not? |
| 08:18.54 | Chikorita | ja das ist richtig , sprechen blinkhausen |
| 08:19.12 | scanline | captain_proton: dict.has_key(key), or try using the key and catch KeyError |
| 08:19.40 | scanline | blinkenhausen nicht ist richtig, das ist varuum boingboing |
| 08:20.20 | scanline | oh boy, more lambda abuse! |
| 08:20.37 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (2 files in 2 dirs): create lists of drawables associated with their texid |
| 08:21.10 | Chikorita | cross country skiin iz wut da old folks do here wen we get snow ova 4 inches an dey hafta go to da 7-11 to buy da newspaper an sum rolaids cuz da paperboy got snowed in an slept late cuz he knew he got no skool taday |
| 08:21.41 | Chikorita | lambda lambda an omega mu |
| 08:21.46 | Chikorita | heehe |
| 08:21.56 | scanline | lambda v2: (v2[0], 0, v2[1]) |
| 08:24.04 | Chikorita | can i say a bad werd? |
| 08:24.16 | scanline | good question |
| 08:24.29 | Chikorita | please |
| 08:24.33 | Chikorita | jus 1 |
| 08:24.58 | Chikorita | no 1 wil c cept u an mee |
| 08:25.08 | Chikorita | da rest r jus loiterin in here anywayz |
| 08:25.37 | Chikorita | wel can i can i can i huh huh huh |
| 08:26.22 | scanline | hooray |
| 08:26.24 | scanline | # This is a Vector3 packed into a Vector2 by assuming X is always zero |
| 08:26.24 | scanline | VectorYZ = MappedEntry(Vector2, |
| 08:26.24 | scanline | <PROTECTED> |
| 08:26.24 | scanline | <PROTECTED> |
| 08:26.26 | scanline | :) |
| 08:27.56 | Chikorita | iz dat calculus? |
| 08:28.05 | scanline | somewhat |
| 08:28.11 | Chikorita | o okies |
| 08:28.15 | scanline | it's python code, but it's based on calculus |
| 08:28.26 | Chikorita | so can i say a bad werd now? |
| 08:28.38 | scanline | you'll have to ask The Fist (tm) |
| 08:28.59 | Chikorita | fist can i cuss a lil bit |
| 08:29.00 | scanline | hrm... up to date check failed |
| 08:29.17 | Chikorita | dang dat failure... |
| 08:29.59 | Chikorita | so umm Mr. Fist can i say a cuss werd jus dis 1 time? |
| 08:30.56 | Chikorita | :\ |
| 08:31.10 | Chikorita | ok how bout i do a substitution... |
| 08:31.25 | CIA | 03micahjd * 12pybzflag/BZFlag (5 files in 3 dirs): Unpack the Wall object more intelligently to avoid having to worry about special cases elsewhere |
| 08:31.27 | scanline | captain_proton: hmm, looks like you'll want to update the WallDrawable stuff now that wall takes a normal size vector |
| 08:32.13 | Chikorita | well itz weally fooking late so i betta get sum fooking sleep b4 i fooking turn into a walkin fookin zombie in da fookin mornin' |
| 08:32.22 | Chikorita | heehe |
| 08:32.29 | scanline | it's so cute having the protocol, 2D representation, and OpenGL representation all in the same file =) |
| 08:32.30 | Chikorita | :x |
| 08:32.46 | Chikorita | aww cutie |
| 08:33.34 | Chikorita | i tink wen tanks pick up da tiny flag an get all teenie dats kinda cute :) |
| 08:33.52 | captain_proton | it puts the size into x and z? |
| 08:34.27 | scanline | captain_proton: turns out it's Y and Z actually, but yeah |
| 08:34.33 | scanline | X is always zero, since the wall has no width |
| 08:35.57 | scanline | captain_proton: ./worldviewer.py heightmap:../bzflag/data/title.png |
| 08:36.14 | Chikorita | >:( |
| 08:36.26 | captain_proton | is the Y length the full length of the field or not? |
| 08:36.50 | scanline | it's half, just like boxen and pyamids |
| 08:36.52 | captain_proton | scanline: sick, in a damn cool sort of way |
| 08:37.06 | scanline | captain_proton: indeed.. you should see the help text for that command |
| 08:37.07 | Chikorita | sic |
| 08:37.16 | scanline | <PROTECTED> |
| 08:37.17 | scanline | <PROTECTED> |
| 08:37.17 | scanline | <PROTECTED> |
| 08:37.17 | scanline | <PROTECTED> |
| 08:37.17 | scanline | <PROTECTED> |
| 08:37.44 | Chikorita | ~dict phat |
| 08:37.56 | Chikorita | ~dict sic |
| 08:38.34 | scanline | captain_proton: yikes it runs slow :) |
| 08:38.43 | Chikorita | ~d |
| 08:38.52 | Chikorita | *sigh* |
| 08:39.07 | scanline | captain_proton: I thought about researching algorithms for filling the space with the fewest boxes possible, but decided I would rather just hope nobody uses it :) |
| 08:40.02 | Chikorita | dey should make movable boxes |
| 08:40.17 | Chikorita | like if ur tank runs into one it can move it a lil |
| 08:40.22 | Chikorita | heehe |
| 08:40.39 | Chikorita | or maybee movable pyramids |
| 08:41.59 | Chikorita | ok yall ignorin mee so imma go .. |
| 08:42.19 | scanline | captain_proton: haha.. if you can jump on top of the words, the radar has about the same shading as the original logo |
| 08:42.56 | Chikorita | foo |
| 08:45.01 | CIA | 03micahjd * 12pybzflag/BZFlag/World (Generator.py): Flip the image vertically in Heightmap so it appears right side up in the overhead view |
| 08:47.34 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (2 files in 2 dirs): commit somewhat broken so scanline can look at it |
| 08:47.40 | captain_proton | ok |
| 08:47.41 | captain_proton | scanline: |
| 08:47.46 | scanline | mmyep? |
| 08:47.56 | captain_proton | it draws one wall |
| 08:47.58 | captain_proton | but not all 4 |
| 08:49.11 | scanline | hmm.. how are you testing it? I'm running "./worldviewer.py random -u 3D" and I get blackness |
| 08:49.19 | scanline | oh, I suppose I need those image files? |
| 08:49.31 | captain_proton | image? it doesn't do textures right now |
| 08:49.41 | captain_proton | i have a random server running |
| 08:49.46 | captain_proton | then using observer.py |
| 08:50.29 | scanline | ah, got a wall that time |
| 08:50.36 | scanline | wonder why it didn't work with worldviewer... |
| 08:51.20 | captain_proton | looks like it wasn't getting a loadworld callback? |
| 08:51.37 | captain_proton | ThreeDView.py:68 |
| 08:51.39 | scanline | hm |
| 08:51.48 | scanline | ahh |
| 08:51.54 | scanline | worldviewer still loads the world the Bad Way |
| 08:53.03 | CIA | 03micahjd * 12pybzflag/ (worldviewer.py): Worldviewer needs to clone the loaded world into the existing world instance rather than replacing it, to preserve event instances. |
| 08:53.35 | scanline | ah |
| 08:53.37 | captain_proton | another oddity is that the wall its drawing isn't starting in the center of the screen |
| 08:53.48 | captain_proton | which is how my camera angle should show it |
| 08:54.06 | scanline | the view should still function if you attach it after loading the world, but just for now I'm changing the order that worldviewer does things in |
| 08:54.11 | CIA | 03micahjd * 12pybzflag/ (worldviewer.py): Load the world after attaching the UI |
| 08:54.23 | scanline | now it gives the same 1-wall result in worldviewer |
| 08:54.59 | captain_proton | yep |
| 08:56.35 | captain_proton | http://jupiter.babylonia.flatirons.org/bze-ss/20021001---editing-name.png <-- same camera angle as that, but further pulled back |
| 08:56.53 | scanline | ah, cute |
| 08:57.08 | scanline | the 'grass' is a bit eye-poking though :) |
| 08:57.14 | captain_proton | heh |
| 08:57.20 | captain_proton | like the mipmap? |
| 08:57.29 | scanline | and the color |
| 08:57.37 | scanline | it's like.. blurry neon sludge on a stick :) |
| 08:57.52 | captain_proton | any ideas about the walls? |
| 08:57.52 | scanline | the antialiasing makes up for it though |
| 08:57.57 | scanline | lookin |
| 08:58.24 | captain_proton | yep - antialiased widgets, antialiased scene |
| 08:58.37 | captain_proton | though my font hinting was quite broken at that point |
| 09:00.35 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/Protocol (WorldObjects.py): pop what we push |
| 09:00.37 | scanline | hm.. so WallDrawable.draw() is definitely getting caled with distinct self, self.center, and self.list four times per frame |
| 09:00.45 | captain_proton | that doesn't help there |
| 09:00.59 | scanline | hm? |
| 09:01.07 | captain_proton | the pop |
| 09:01.11 | scanline | oh |
| 09:02.51 | scanline | hm |
| 09:03.04 | scanline | could this just be because you're not clearing the z-buffer maybe? |
| 09:03.10 | scanline | it gets a different wall each time for me |
| 09:03.22 | scanline | then if I drag the window off the edge of the screen and back, it doesn't update it |
| 09:04.05 | captain_proton | hmm, could be |
| 09:04.20 | captain_proton | err, nope |
| 09:04.24 | scanline | there's a glClear, and there's a pygame.display.flip.. but it doesn't seem to be working |
| 09:04.45 | scanline | I know the nvidia drivers like to draw random bits of the scene if you make their usual event loop unhappy |
| 09:05.28 | captain_proton | hm, nope |
| 09:05.36 | captain_proton | calling glFinish before flipping doesn't help |
| 09:10.59 | scanline | ah |
| 09:11.03 | scanline | you have a glEnd commented out |
| 09:11.11 | scanline | WorldObjects.py:235 |
| 09:13.11 | captain_proton | oofa :) |
| 09:13.24 | scanline | now we get four parallel walls :) |
| 09:14.04 | captain_proton | almost parallel |
| 09:14.20 | scanline | hm.. does glRotatef take radians or degrees? |
| 09:14.25 | captain_proton | degrees |
| 09:14.25 | scanline | self.angle is radians |
| 09:14.28 | scanline | ahh |
| 09:15.08 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/Protocol (WorldObjects.py): make the walls work |
| 09:15.58 | scanline | hooray |
| 09:16.00 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/UI (ThreeDView.py): stick camera closer |
| 09:18.28 | CIA | 03micahjd * 12pybzflag/BZFlag/Protocol (WorldObjects.py): Whitespace changes |
| 09:18.39 | scanline | I'm surprised diablo-d3 didn't say anything about the commit where you mentioned me :) |
| 09:21.01 | captain_proton | me too |
| 09:21.17 | captain_proton | must not be paying attention |
| 09:21.22 | CIA | 03micahjd * 12pybzflag/BZFlag/Protocol (WorldObjects.py): Oop, missed a few whitespaces! |
| 09:21.31 | scanline | yeah.. he would have at least noticed we're both working on the same files |
| 09:24.01 | captain_proton | naptime |
| 09:24.15 | scanline | g'night |
| 09:39.17 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (4 files): Misc cleanups, started a radar UI module |
| 09:46.38 | *** join/#bzflag mmu_man (~revol@ALyon-209-1-4-81.w217-128.abo.wanadoo.fr) |
| 10:01.18 | CIA | 03micahjd * 12pybzflag/BZFlag (2 files in 2 dirs): Implemented the same alpha blending algorithm bzflag's enhanced radar uses |
| 10:05.11 | fiberchunks | seems I may have to pony up beer quicker than I thought :) |
| 10:11.48 | scanline | :) |
| 10:11.50 | scanline | http://navi.pic |
| 10:11.51 | scanline | er |
| 10:11.54 | scanline | http://navi.picogui.org/~micah/tmp/pybzflag_radar.png |
| 10:13.21 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (RadarView.py): Added color scheme dict, so far with one color for teleporters and one default color |
| 10:14.04 | fiberchunks | man, it is amazing how much you can do with python, and how quickly :) |
| 10:14.17 | scanline | :) |
| 10:14.18 | fiberchunks | python/pygame/pyfoo |
| 10:14.28 | scanline | only about 5k lines of code here so far, and it does a lot |
| 10:15.00 | fiberchunks | recommendation for coding twit concerning 'starting points' for python learning? |
| 10:15.03 | scanline | hehe |
| 10:15.08 | fiberchunks | twit == me |
| 10:15.13 | scanline | hmm... the online python docs are pretty good |
| 10:15.25 | scanline | though some o'reilly treeware couldn't hurt |
| 10:15.28 | fiberchunks | goody, then I'll start there |
| 10:15.42 | fiberchunks | o'reilly makes the best treeware there is |
| 10:15.46 | fiberchunks | imho |
| 10:15.52 | scanline | yep |
| 10:16.11 | fiberchunks | are you documenting this stuff as you go along with the """ pydoc """ method? |
| 10:16.22 | scanline | yep |
| 10:16.39 | fiberchunks | cool |
| 10:16.43 | scanline | I really just got into the habit of putting information about functions and classes into doc strings rather than into comments |
| 10:17.20 | fiberchunks | seems to me that it's the easiest / quickest way to generate relatively full-featured docs |
| 10:18.05 | scanline | well, it serves much the same purpose as doxygen.. not really a replacement for a manual type doc though |
| 10:18.26 | scanline | hmm, maybe when captain_proton wakes up we could poke him to make sfsnap work for pybzflag too |
| 10:18.38 | scanline | anyway, I think I need some sleep too |
| 10:18.42 | fiberchunks | true -- but it allows you coder gurus to do what you do best -- AND comment the code at the same time -- with very little wasted effort |
| 10:18.45 | scanline | haven't had any in far too long |
| 10:18.49 | scanline | yep |
| 10:18.56 | fiberchunks | ah -- coolio -- see you in the afternoon or so :) |
| 10:19.02 | scanline | ok, see ya |
| 10:19.06 | fiberchunks | ciao |
| 10:37.09 | *** join/#bzflag Wildebras (~kat@164.53-136-217.adsl.skynet.be) |
| 10:37.52 | *** part/#bzflag Wildebras (~kat@164.53-136-217.adsl.skynet.be) |
| 10:43.18 | *** join/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 11:10.47 | [TeA|TrEE] | hello |
| 11:38.35 | *** join/#bzflag Quol (~QuolSimo@modemcable052.11-203-24.mtl.mc.videotron.ca) |
| 12:10.50 | *** join/#bzflag MrApathyCream (dbrosius@balt-209-163-100-203.qis-dynamic-dialup.coretel.net) |
| 12:31.02 | *** join/#bzflag guest11111 (~Joe@adsl-68-133.lou.bluegrass.net) |
| 12:34.33 | *** join/#bzflag larsl_56k (~larsl@md4690ad1.utfors.se) |
| 13:07.59 | *** join/#bzflag Mayhem (~Mayhem@dsl-217-155-141-174.zen.co.uk) |
| 13:43.37 | Chestal | tag |
| 13:52.14 | learner | am I "it"? |
| 14:25.15 | guest11111 | but coerent? |
| 14:25.18 | guest11111 | hm |
| 14:25.42 | learner | coherency?? bah! |
| 14:26.06 | doughecka | yea, dats it |
| 14:27.18 | *** join/#bzflag sussudio (Suss@81.68.132.217) |
| 14:54.16 | *** join/#bzflag larsl_56k (~larsl@md469072c.utfors.se) |
| 15:08.11 | *** join/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 15:55.37 | *** join/#bzflag Patlabor221 (~jeffm@adsl-64-172-199-174.dsl.lsan03.pacbell.net) |
| 15:55.37 | *** mode/#bzflag [+o Patlabor221] by ChanServ |
| 15:58.27 | *** join/#bzflag guest11111 (~Joe@adsl-68-133.lou.bluegrass.net) |
| 15:59.07 | *** join/#bzflag doughecjka (~Joe@adsl-68-133.lou.bluegrass.net) |
| 16:25.24 | *** join/#bzflag FantaZee (~trillian@p508F23B4.dip.t-dialin.net) |
| 16:25.24 | *** join/#bzflag JBDiGriz (~JBDiGriz@adsl-63-204-118-6.dsl.sndg02.pacbell.net) |
| 16:25.29 | *** part/#bzflag FantaZee (~trillian@p508F23B4.dip.t-dialin.net) |
| 16:26.30 | *** part/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 16:36.01 | larsl_56k | Ooh, pizza. |
| 16:36.41 | *** join/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 16:39.11 | learner | guess you missed :) |
| 16:40.45 | sussudio | ~dict mailbox |
| 16:41.09 | sussudio | mkaaay creeperz? |
| 16:41.23 | *** part/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 16:41.34 | *** join/#bzflag terryc (~creeperz@host-11-76-220-24.midco.net) |
| 16:42.07 | learner | 2 hours and 20 minutes pending... |
| 16:42.24 | terryc | sussudio* |
| 16:42.31 | sussudio | *creeperz* Through what now? |
| 16:42.46 | terryc | Through what? |
| 16:42.51 | sussudio | that reminds me of the kid in primary school who asked me what catfood is..... |
| 16:43.20 | terryc | :-) |
| 16:43.51 | sussudio | learner: you bent my wookeee. |
| 16:43.59 | learner | lol :) yup |
| 16:52.42 | larsl_56k | New bzadmin with some more command line options and two scripts in the patch tracker, one bz<->irc chat gateway and one bz<->bz. |
| 17:00.52 | captain_proton | umm |
| 17:00.54 | captain_proton | so guys |
| 17:01.21 | Chestal | hi proton |
| 17:01.36 | captain_proton | where is everyone? |
| 17:01.54 | learner | you're two hours early, cap :P |
| 17:02.06 | captain_proton | i am? fargin hell |
| 17:02.19 | learner | lol! |
| 17:02.34 | captain_proton | i got up in the morning just for this, and its two hours early? |
| 17:03.20 | captain_proton | bah! |
| 17:03.42 | learner | 10am early? |
| 17:03.52 | learner | yay, pizza arrived! |
| 17:04.01 | terryc | Mmmm, pizza |
| 17:05.54 | learner | yum yum |
| 17:06.25 | terryc | E-Mail me a peice!! :-) |
| 17:06.38 | sussudio | ~spell peice |
| 17:06.40 | | possible spellings for peice: piece Peirce Peace peace piecer puce Pierce pierce Perice Price price Pearce Pace pace pence deice |
| 17:07.01 | terryc | Haha. The new RadioShack commercial says "You've got questions, we've got actors" :-) |
| 17:07.11 | learner | I'll e-mail you a peace right away |
| 17:08.44 | captain_proton | 11am early |
| 17:12.49 | Chestal | I need a remote controlled CD changer or something |
| 17:13.25 | sussudio | why don't you just get a cdplayer that plays mp3 cds |
| 17:14.10 | Chestal | no, I'd like to burn a coupel CDs |
| 17:14.15 | Chestal | but I'm not at home |
| 17:14.50 | Chestal | so I'd need somethign which would put the next CD-R into my burner and remove it later |
| 17:15.01 | sussudio | get more than 1 burner? |
| 17:15.04 | terryc | :-/ |
| 17:15.09 | sussudio | they cost about 50 euro each now |
| 17:15.10 | Patlabor221 | they make burner loaders |
| 17:15.12 | Patlabor221 | for dupe stuff |
| 17:15.21 | Patlabor221 | or use the power of legos |
| 17:15.24 | Chestal | sussudio: I am not buying 10 of them :-) |
| 17:15.47 | sussudio | ok then wait half an hour to burn 10 :-P |
| 17:16.12 | Chestal | it's more like waiting 8 hours until I return home |
| 17:16.19 | Patlabor221 | http://www.acronova.com/product2f.htm |
| 17:16.32 | sussudio | get an external burner and take it with you? |
| 17:16.59 | Patlabor221 | I don't think you understand the conecpt of "labor saving device" sussudio. |
| 17:17.01 | Chestal | sussudio: no, the data is on my home computer |
| 17:17.09 | Chestal | sussudio: I just want to work on it remotely |
| 17:17.24 | sussudio | Chestal: vpn? |
| 17:17.42 | Chestal | sussudio: that's not the problem, I'm using ssh, and can do everythign from here. I just cannot change CDs |
| 17:17.57 | Patlabor221 | you can ssh to the lego mind storms |
| 17:18.02 | captain_proton | heh Patlabor221 |
| 17:18.08 | captain_proton | that was exactly what i was about to suggest |
| 17:18.23 | Patlabor221 | yeah, it's even got a "C ish" compiler |
| 17:18.27 | Chestal | Patlabor: do they have some device to grab CDs? Maybe working with underpressure? |
| 17:18.47 | Patlabor221 | I've seen a couple people who have done the CD thing with the mindstorms |
| 17:19.03 | Patlabor221 | I've seen a couple |
| 17:19.10 | Chestal | bruenr should come with a simpel stack where you canfill in like 10-20 CD-Rs |
| 17:19.43 | Chestal | I wonder if there is such a device. If not, there should be one |
| 17:19.47 | Patlabor221 | I've seen ones that use sucktion, and some that use an arm that picks up in the middle of the CD |
| 17:19.53 | Chestal | I must file a patent I guess :-) |
| 17:20.09 | Chestal | I'm gonna be rich |
| 17:20.28 | Patlabor221 | There are, it's common to do that with CDR duplication |
| 17:20.29 | Patlabor221 | low run |
| 17:20.54 | Chestal | but I don't want to duplicate CD-Rs, I want it with a normal burner |
| 17:21.04 | Patlabor221 | yeah |
| 17:21.11 | Chestal | I guess I duplciate like 1 CD-R a year or so |
| 17:21.17 | Patlabor221 | they have devices that sit in front of a computer and load up a normal drive |
| 17:21.26 | Patlabor221 | it's not a copyer |
| 17:21.29 | Chestal | Patlabor: devices called 'slaves'? |
| 17:21.31 | Patlabor221 | it's just a loader |
| 17:21.37 | sussudio | you could get a dvd burner |
| 17:21.48 | Patlabor221 | wow he realy dosn't get it does he? |
| 17:22.08 | Chestal | well, a DVD burner would at leat alleviate the problem a little |
| 17:22.16 | Chestal | hmm, is that a word |
| 17:22.22 | Chestal | ~dict alleviate |
| 17:22.30 | sussudio | Patlabor221: or maybe you don't |
| 17:22.44 | Chestal | the famous lesbian? |
| 17:22.52 | Patlabor221 | how would that make more more audio CDs |
| 17:22.58 | Patlabor221 | unless you make audio DVDs |
| 17:23.04 | Chestal | it's not audio |
| 17:23.08 | Patlabor221 | ohh |
| 17:23.13 | Chestal | I burnt exactly one audio CD in my life |
| 17:23.19 | Patlabor221 | well we have dvd-rs for 180 |
| 17:23.20 | sussudio | yes, Chestal never said -audio-. |
| 17:23.27 | captain_proton | Patlabor221: you would not believe how easy the texture manager/model manager is in python |
| 17:23.40 | Patlabor221 | I'm sure I can |
| 17:24.18 | sussudio | captain_proton: incestual programming? |
| 17:24.36 | Patlabor221 | ahh yeah I thouhgt about using the this |
| 17:25.39 | captain_proton | sussudio: what did i say about being allowed to speak only when you have something constructive? |
| 17:26.06 | Chestal | what's 'set startcode bfaaaaabaaacaa'? |
| 17:26.20 | captain_proton | Chestal: server menu |
| 17:26.36 | sussudio | captain_proton: are you awake when chikorita is here? |
| 17:28.39 | captain_proton | sussudio: its a lot more annoying when people are both off topic -and- offsensive in everything they say |
| 17:30.55 | sussudio | i don't think anything is more annoying than the flood of AOL diarrhea she spews into the channel. |
| 17:31.33 | learner | ugh, is that really necessary? |
| 17:32.53 | Patlabor221 | I wonder if you could modify one of those old NES robots into changing CDs |
| 17:35.14 | sussudio | Chestal: http://www.sentex.net/~mwandel/tech/changer.html |
| 17:35.31 | Patlabor221 | that's the one I was looking for |
| 17:35.55 | Patlabor221 | probalby do it a lot easyer with the legos |
| 17:36.38 | CIA | 03brlcad * 12bzflag/include (WordFilter.h): constified and cleaned up interface, added utility methods |
| 17:39.12 | captain_proton | <PROTECTED> |
| 17:39.12 | captain_proton | <PROTECTED> |
| 17:39.12 | captain_proton | OpenGL.GL.GLerror: [Errno 1280] invalid enumerant |
| 17:39.17 | captain_proton | how what is wrong with that |
| 17:39.27 | captain_proton | now* |
| 17:39.42 | captain_proton | oh wait |
| 17:39.54 | captain_proton | hmm, no, thats not the issue |
| 17:40.45 | JBDiGriz | ~dict constified |
| 17:41.25 | JBDiGriz | ~spell constified |
| 17:41.26 | | possible spellings for constified: construed justified countrified notified citified codified considered constitute constituted quantified continued consorted constipate constipated constrained certified consisted mystified testified conceited confide conspired conceived confided conserved coincided constitutes |
| 17:42.26 | JBDiGriz | learner: is the interface certified constipated? |
| 17:45.47 | learner | heh |
| 17:45.59 | learner | fleas? |
| 17:46.08 | captain_proton | hah |
| 17:46.22 | sussudio | lice more probable. i don't think fleas will get on your head |
| 17:47.44 | learner | perhaps pygame doesn't support it.. |
| 17:48.18 | captain_proton | this isn't pygame's fault, it could be pyopengl's fault, but pyopengl is an auto-generated binding |
| 17:48.19 | captain_proton | =/ |
| 17:48.51 | learner | hrm |
| 17:49.49 | learner | does nearest work? |
| 17:50.02 | learner | GL_LINEAR_MIPMAP_NEAREST |
| 17:50.19 | learner | or GL_NEAREST_MIPMAP_NEAREST |
| 17:51.11 | captain_proton | LINEAR does |
| 17:51.18 | captain_proton | seems it doesn't like the mipmap defs for mag |
| 17:51.24 | captain_proton | which makes sense, i guess |
| 17:52.27 | learner | hrm, how about GL_LINEAR_MIPMAP_LINEAR, GL_LINEAR together |
| 17:52.36 | captain_proton | ...together? |
| 17:52.40 | learner | yes |
| 17:52.48 | captain_proton | i'm LINEAR_MIPMAP_LINEAR for the min filter |
| 17:53.15 | learner | ah |
| 17:54.35 | learner | ah.. it's not available for mag, like you guessed |
| 17:54.47 | learner | http://www.opend.org/dig/classGLtexture.html |
| 17:55.29 | captain_proton | the C binding silently fails back to linear, so i wasn't noticing :) |
| 17:55.34 | learner | or http://www.opengl.org/developers/documentation/Specs/glspec1.1/node84.html from the horses mouth |
| 17:57.54 | captain_proton | http://jupiter.babylonia.flatirons.org/texturedwalls.png |
| 17:58.13 | learner | sweeeeeet |
| 17:58.26 | learner | cept your texturing sucks :) |
| 17:58.49 | captain_proton | heh, its the bzflag wall texture |
| 17:59.04 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (2 files in 2 dirs): texture them walls! |
| 17:59.08 | *** join/#bzflag fiberchunks (~frobozzpf@237.14.252.64.snet.net) |
| 17:59.18 | CIA | 03davidtrowbridge * 12pybzflag/data (3 files): Directory /cvsroot/bzflag/pybzflag/data added to the repository |
| 17:59.18 | learner | one hour to go |
| 17:59.43 | fiberchunks | mornin! :) |
| 17:59.45 | CIA | 03davidtrowbridge * 12pybzflag/ (2 files in 2 dirs): add all the stuff it requires |
| 18:01.47 | learner | hehe, fiber .. "mornin'" to you too ;) |
| 18:02.30 | fiberchunks | heh, i woke up @ 0530, fiddled on the puter for bout 5 hours, then went back to sleep :) |
| 18:03.50 | CIA | 03davidtrowbridge * 12pybzflag/ (2 files in 2 dirs): removing the image to readd it as a binary file |
| 18:03.55 | captain_proton | 2 files...? |
| 18:04.11 | CIA | 03davidtrowbridge * 12pybzflag/data (wall.png): fixinate |
| 18:05.15 | learner | one to remove, one to add ? |
| 18:05.34 | learner | ah, nvr mind |
| 18:05.40 | captain_proton | no...i think i had a miscellaneous change in a source file |
| 18:07.48 | *** join/#bzflag TD (~mike@81.6.221.126) |
| 18:07.56 | learner | eekers |
| 18:07.57 | TD | are you guys really rewriting bzflag in python? |
| 18:08.03 | captain_proton | TD: not really |
| 18:08.20 | TD | ok |
| 18:08.27 | captain_proton | we'll probably have bots in python |
| 18:08.29 | captain_proton | and world editors |
| 18:08.32 | learner | they're rewriting it in vax assembly, it'll only run on a vax now |
| 18:08.55 | TD | cool |
| 18:09.06 | learner | I jest, of course, but the python stuff is progressing nicely |
| 18:09.22 | TD | yeah, i saw it got texturing just now :) |
| 18:09.37 | TD | why not go rewrite the game in python? would make it easier to hack. maybe a bit slow, but pygame could sort that out |
| 18:09.55 | Chestal | the amount of $$ I can earn in these scam mails is still increasing |
| 18:10.30 | learner | and think of how big of a "friend" you could have by now, Ches |
| 18:10.44 | captain_proton | TD: well - eventually it'll be possible to play with it |
| 18:11.01 | captain_proton | but i doubt it would displace the c++ client |
| 18:11.11 | Chestal | pybzflag might be a good place to experiment with different design choices |
| 18:11.27 | captain_proton | bzfs.py might end up displacing bzfs though >:) |
| 18:11.30 | Chestal | if some work well, they could make it into the main (c++) branch |
| 18:11.42 | captain_proton | Chestal: actually - thats something scanline has been doing a lot |
| 18:11.57 | captain_proton | pybzflag has a lot of really nifty design choices |
| 18:12.05 | Chestal | after all, a toy language (pun intended :-) as python is good for rapid prototyping |
| 18:12.16 | captain_proton | though several of them take advantage of flexibilities that python has which C++ does not |
| 18:12.30 | Chestal | I wonder which those are |
| 18:12.35 | Chestal | introspection? meta classs? |
| 18:12.41 | captain_proton | runtime dynamism |
| 18:12.59 | Chestal | of what kind? loading modules/plugins? |
| 18:13.02 | captain_proton | flags look at their own class name to assemble help strings |
| 18:13.07 | Chestal | uah |
| 18:13.14 | Chestal | I don't like it |
| 18:13.21 | learner | ah.. sounds like obj-c |
| 18:13.23 | Chestal | same thing as reflection in Java, most abused feature ever |
| 18:13.32 | captain_proton | eh - sort of |
| 18:13.34 | Chestal | the name of a class should never ever appear during runtime |
| 18:13.37 | learner | reflection is a bastard variant |
| 18:14.02 | Chestal | I'm not a fun of coupling names in the source with the applicatin logic |
| 18:14.05 | Chestal | eh, a fan |
| 18:14.21 | captain_proton | the event interface automatically generates callback functions |
| 18:14.26 | captain_proton | etc |
| 18:14.46 | Chestal | I really liek things like these to be explicit |
| 18:15.04 | Chestal | might be ok for a quick prototype but IMHO things like that don't work out very well in big provjects |
| 18:15.26 | captain_proton | it generates it at runtime |
| 18:15.41 | captain_proton | call the event attach(), if the function doesn't exist in the object you pass it, it will create it |
| 18:15.53 | captain_proton | then you post the event by calling that function |
| 18:16.38 | Chestal | your description does not parse in my brain :-) |
| 18:17.46 | captain_proton | heh |
| 18:17.53 | captain_proton | it took me a while to wrap my head around it too |
| 18:18.43 | Chestal | what about vorbis, btw.? |
| 18:18.57 | captain_proton | the audiofile stuff needs to be hooked up |
| 18:19.11 | captain_proton | i'd suggest pulling in the SoundManager from 1.8, but it needs to be decoupled from MPLATFORM |
| 18:19.14 | Chestal | isn't it already? at least bzflag gets linked with libvorbis |
| 18:20.18 | Chestal | or is it only that we can read vorbis files, but not play them yet? The whole media stuff is a part of the soruce I have no clue about |
| 18:21.06 | Chestal | did 1.8 decode vorbis in real time? or decode once and store raw data in memory and play that? |
| 18:22.14 | captain_proton | decode once, store raw data |
| 18:22.31 | captain_proton | decoding has too high a latency for sound effects |
| 18:22.47 | captain_proton | AudioFile is in the build, but its not actually hooked into the system |
| 18:23.23 | Chestal | so we require people to have libvorbis (and libvorbis-dev) installed just like with gl? |
| 18:23.31 | CIA | 03davidtrowbridge * 12pybzflag/ (3 files in 3 dirs): draw the ground too |
| 18:23.33 | captain_proton | yeah |
| 18:24.06 | Chestal | should probably make it easy for peopel to get and install it then. Minimum would be an easy to access link |
| 18:24.12 | Chestal | don't think too many windows people have it |
| 18:24.23 | captain_proton | yeah |
| 18:24.32 | captain_proton | i'm gonna let Patlabor221/MAC write up how to do it on windows |
| 18:24.42 | Patlabor221 | there is a nice prebuilt bin package |
| 18:24.50 | Chestal | maybe bzflag should silenty start a thread and convert all mp3s it finds to .ogg ;-) |
| 18:25.02 | fiberchunks | yeessssssssss :) |
| 18:25.04 | Patlabor221 | I have an edited readme that tells how to do it. |
| 18:25.30 | fiberchunks | .mp3 is .ogg's biatch |
| 18:25.43 | captain_proton | Chestal: hehe |
| 18:27.11 | CIA | 03davidtrowbridge * 12pybzflag/data (ground.png): freakin' hell, i did it again |
| 18:27.36 | CIA | 03davidtrowbridge * 12pybzflag/data (ground.png): -kb, -kb, -kb, *smack* |
| 18:30.47 | *** join/#bzflag HenryRiker (~HenryRike@c-67-163-110-59.client.comcast.net) |
| 18:30.55 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/UI (ThreeDView.py): add a second light, to make it not so dark |
| 18:30.56 | captain_proton | hi henry! |
| 18:31.38 | *** part/#bzflag TD (~mike@81.6.221.126) |
| 18:33.10 | *** join/#bzflag TimRiker (~timr@c-67-163-110-59.client.comcast.net) |
| 18:33.25 | Quol | hello all |
| 18:33.37 | fiberchunks | lo quol |
| 18:33.37 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 18:33.39 | TimRiker | HenryRiker: hey henry! |
| 18:33.52 | fiberchunks | lo Rikers :) |
| 18:34.15 | Quol | hello fiberchunks. |
| 18:34.29 | fiberchunks | is it not past time for the networking shindig? |
| 18:34.30 | Quol | Hey guys - I have a first draft of the chroot HOWTO. |
| 18:34.38 | captain_proton | fiberchunks: apparently not |
| 18:34.44 | captain_proton | 25 minutes |
| 18:34.55 | learner | what's the preferred behavior for a failed memory allocation? |
| 18:35.05 | fiberchunks | ah, then I will get un-dirty |
| 18:35.13 | Quol | anyone want to look it over and give their opinions? any ideas in where to post it to make it available? |
| 18:35.13 | learner | (and I read devinfo first, cap ;) |
| 18:35.21 | Chestal | learner: preferred is that it's not happening at all :-) |
| 18:35.36 | fiberchunks | Quol> wiki site, and the forums would be nice as well |
| 18:36.04 | Quol | OK- I will get started with wiki and post it to bzbb... |
| 18:36.50 | HenryRiker | hi captain-proton |
| 18:37.21 | Chestal | wow, I'm full now, but still hungry |
| 18:37.35 | Chestal | learner: mayeb rephrase your question, what do you mean exactly? |
| 18:39.15 | learner | if a new/malloc fails, what's the proper behavior? call perror() and exit(), throw an exception(), "let it be" :), or something else? |
| 18:39.45 | captain_proton | ...we check allocs to see if they failed? :) |
| 18:40.10 | Chestal | learner: depends. When you think you can do something about it, then do that |
| 18:40.11 | learner | heh, I do |
| 18:40.32 | Chestal | learner: in case of new, you'd have to catch the badalloc exception first, or program will terminate anyway |
| 18:40.39 | learner | right |
| 18:41.09 | learner | then once caught, and assuming I can't recover.. what's the general practice? |
| 18:41.12 | HenryRiker | haha funny chestal |
| 18:41.40 | learner | it sounds .. like .. there is no .. general .. practice.. :) |
| 18:41.52 | Chestal | learner: throw an exception which produces some meaningful output for the user for example |
| 18:42.06 | Chestal | learner: general practice is to ignore it :-) |
| 18:42.17 | learner | throw exception("your computer is hosed, please reboot"); |
| 18:42.32 | Chestal | would be nice too know, whether memory for the application ran out or if it's a system wide problem |
| 18:42.35 | learner | ah .. the "let it be" answer :) |
| 18:43.13 | Chestal | an application coudl reserve some memory on startup and free that as soon as it gets a bad alloc error, thus hoping to have freed enough memory to at least be able to somewhat continue |
| 18:43.15 | HenryRiker | ok |
| 18:43.35 | Chestal | the OS might even decide to kill you, then you're hosed anyway |
| 18:44.00 | HenryRiker | no |
| 18:44.03 | Chestal | would be nice to at least do a clean emergency cleanup and exit |
| 18:44.10 | learner | that would imply some sort of nicely contained application controller that would eventually catch the thrown exception.. which I wasn't aware of such cleanliness.. |
| 18:44.28 | learner | in bz, that is, of course |
| 18:44.37 | Chestal | bz is not using exceptions so far anyway |
| 18:44.43 | learner | there's a few |
| 18:44.51 | Chestal | there are? that's new tome |
| 18:45.01 | TimRiker | HenryRiker: what is "no" about? |
| 18:45.04 | Chestal | they are not onthe list of approved c++ features for bz so far |
| 18:45.40 | TimRiker | learner: there are not. I compile on Linux with no-exceptions |
| 18:45.44 | learner | bzwtransform uses exceptions |
| 18:45.44 | Chestal | if I am not mistaken, we are still using -fno-excpetions with g++ |
| 18:46.06 | TimRiker | learner: ahh.. not a "part of bzflag". It can use them if it likes. |
| 18:46.10 | learner | whether they actually get compiled, no not I do |
| 18:46.20 | learner | ah, mkay |
| 18:46.29 | HenryRiker | yeas |
| 18:47.16 | TimRiker | HenryRiker: how old are you? |
| 18:47.45 | learner | so, I'm unrestrained from making some glorious exception heirarchy handler .. |
| 18:48.00 | HenryRiker | 4 |
| 18:48.03 | TimRiker | learner: nice job on restraint. ;-) |
| 18:48.21 | learner | Hi Henry :) |
| 18:49.11 | captain_proton | pybzflag uses exceptions >:) |
| 18:49.14 | learner | I think Henry should design the new network layer, it'd probably be better than what we'll come up with here |
| 18:50.48 | Chestal | what exactly are we supposed to discuss anyway? what should be changed right now or what the bright future of bzflag networking should look like? Or all of it? |
| 18:51.10 | Chestal | I have some proposals which are not directly related to networking btw. The first is to get rid of all the robot code for now |
| 18:51.11 | learner | basically the WIP page, afaik |
| 18:51.18 | learner | and anything related |
| 18:52.03 | captain_proton | i think the biggest point is what kind of public interface the network layer should have |
| 18:53.02 | captain_proton | i believe the goal is to come up with something where bzflag can expose a library that allows bots/etc to be written using the same protocol code |
| 18:53.12 | Chestal | proton: well, one easy replacement would be some wrapper structs which would automatically do the (un)packing |
| 18:53.58 | captain_proton | so who called this meeting again? ;) |
| 18:53.59 | Chestal | we could make the channel moderated :-) |
| 18:54.11 | captain_proton | Chestal: eh - if it becomes a problem, we can |
| 18:54.31 | captain_proton | if we actually end up with a topic, i'd like anybody to be able to offer their input |
| 18:55.46 | fiberchunks | JBDiGriz> called the meeting, iirc |
| 18:56.15 | fiberchunks | ah, clean-ness |
| 18:57.08 | fiberchunks | *ahem* hear ye hear ye -- the right honorable barrister Lord viceroy comte de JBDiGriz has da floor |
| 18:57.11 | fiberchunks | :) |
| 18:57.12 | *** join/#bzflag larsl_56k (~larsl@md4690acb.utfors.se) |
| 18:57.18 | HenryRiker | yes |
| 18:57.53 | JBDiGriz | We're supposed to be discussing the repackaging of the network interface to clean things up, the addition of some capabilities for the future, and the implications before we start coding it. |
| 18:58.18 | JBDiGriz | Questions about bot code should be addressed |
| 18:58.35 | JBDiGriz | Questions of protocol changes are also important |
| 18:58.45 | learner | the infamous crs is supposed to show up? I've yet to see him.. |
| 18:58.52 | CIA | 03davidtrowbridge * 12pybzflag/ (3 files in 3 dirs): |
| 18:58.52 | CIA | yes! -kb on the first try! |
| 18:58.53 | CIA | oh yeah, draw the box sides |
| 18:59.11 | TimRiker | learner: I've not heard from him in a while, so I doubt it. |
| 18:59.13 | JBDiGriz | And we'll listen to CIA for the important messages of the day |
| 18:59.18 | TimRiker | hehe |
| 18:59.39 | TimRiker | JBDiGriz: there are already some protocol issues in the TODO, perhaps we should list them here? |
| 18:59.50 | JBDiGriz | Does everyone have the sticky wiki wipi available in a window somewhere? |
| 18:59.59 | captain_proton | http://jupiter.babylonia.flatirons.org/cute.png |
| 19:00.01 | TimRiker | wipi? |
| 19:00.02 | learner | GO! |
| 19:00.17 | TimRiker | learner: hehe |
| 19:00.21 | JBDiGriz | http://www.bzflag.org/wiki/WorkInProgress |
| 19:00.21 | captain_proton | TimRiker: WorkInProgress |
| 19:00.37 | TimRiker | that's wip, no? ;-) |
| 19:01.04 | learner | :) |
| 19:01.24 | learner | so is networking first on the list? |
| 19:01.32 | learner | or other WIP items? |
| 19:01.34 | Chestal | someone still missing who wanted to show up? |
| 19:01.39 | JBDiGriz | For this meeting, it's first on the list |
| 19:02.16 | JBDiGriz | We're missing MAC and CobraA1 |
| 19:02.21 | TimRiker | it's time, so whoever is not here, please say something. (in other words let's start) |
| 19:02.44 | JBDiGriz | Ben Baker, the guy who wrote the patch doesn't have a machine on Saturday |
| 19:03.01 | JBDiGriz | Encapsulation! |
| 19:03.28 | Chestal | I never looked at the patch, can someone paraphrase it? Or is it best to look at the explanation whichgoes along with it? |
| 19:04.03 | learner | how about one of the existing network-layer experts (i.e. not me) give a description of changes that need to happen to the current code? |
| 19:04.13 | JBDiGriz | From the TODO, encapsulate stuff requiring platform #ifdef's: |
| 19:04.13 | JBDiGriz | <PROTECTED> |
| 19:04.44 | JBDiGriz | The patch provided this type of encapsulation, but at the expense of the bot code. |
| 19:04.44 | Chestal | learner: there's a lot of different things which should change |
| 19:04.59 | learner | such as? |
| 19:05.08 | Chestal | as I said before, I vote to eliminate the bot code |
| 19:05.30 | learner | I would second that vote, it's certainly a hairy integration as it exists now |
| 19:05.35 | captain_proton | there are really two aspects to the netcode |
| 19:05.41 | captain_proton | platform & protocol |
| 19:06.26 | captain_proton | we should move the platform-specific calls into the platform lib ;) |
| 19:06.40 | Chestal | didn't know there was much of it outside of libnet |
| 19:07.00 | TimRiker | Chestal: seems to merge playerlink and serverlink stuff and change the api a bit. |
| 19:07.02 | learner | is there anything platform specific in libnet? |
| 19:07.03 | Chestal | "platform specific" probably means unix-like vs. windows here? |
| 19:07.22 | Chestal | TimRiker: that's good, Playerlink does not make sense any more withotu multicasting anyway |
| 19:07.27 | captain_proton | Chestal: yes |
| 19:07.30 | JBDiGriz | for the purpose of networking, MacOS is Unix |
| 19:07.47 | TimRiker | Chestal: I vote to keep the bot code till Somebody(tm) writes new bot code. |
| 19:08.16 | Chestal | TimRiker: well, the new bot code should be totally different, i.e. not woven into the client code |
| 19:08.20 | TimRiker | I had intended it to be C code that shared libNet.a but perhaps python bots could meet the need. |
| 19:08.28 | JBDiGriz | I think we should drop current bot support, and look towards the python bot as an interim solution. |
| 19:08.48 | Chestal | I don't see new bots in the near future |
| 19:08.55 | larsl_56k | Drop bot support entirely? Does that mean no 'client' library? |
| 19:08.59 | Chestal | bots would take a meeting of its own |
| 19:09.00 | learner | I'm working on stuff that is C code that links with both existing libraries and uses python for scripting interface |
| 19:09.05 | captain_proton | before bots are -really- feasable in C, we need to have more libs from the client then just net |
| 19:09.17 | captain_proton | things like dead reckoning should be done by shared code |
| 19:09.29 | Chestal | and a lot more,too |
| 19:09.48 | Chestal | but that's another issue |
| 19:10.01 | captain_proton | right |
| 19:10.12 | Chestal | I just think that the current bot code is not well-understood or maintained anymore and bound to make problems |
| 19:10.18 | Chestal | and it's a dead end |
| 19:10.22 | TimRiker | we probably need to create a libBZFnet or something that curses-bzflag and bot-bzflag and gl-bzflag can all share. |
| 19:10.35 | JBDiGriz | We'll have several projects branching from this one meeting, and we just have to find people who are interested in taking them on. |
| 19:10.37 | TimRiker | maybe just libBZF |
| 19:10.39 | learner | in making the mac frameworks, where all symbols must be resolved at link time, I noticed that there were quite a few unfortunate interdependencies between libcommon and libnet -- these should be decoupled better |
| 19:10.51 | learner | ended up making a libcommonnet |
| 19:11.11 | Chestal | for the next release, I do not see a major refactoring of bzflag which would be necessary for the abstractions in a libbzflag |
| 19:11.34 | learner | problem is libnet calls libcommon and libcommon calls libnet |
| 19:11.48 | TimRiker | Chestal: certainly not if nobody starts on it. |
| 19:11.55 | Chestal | I for my part would be happy to have a 1.9 release without any bots at all |
| 19:12.09 | Chestal | IMHO we should concentrate on the small steps with the network code first |
| 19:12.11 | TimRiker | learner: yep. got a proposal to fix it? |
| 19:12.18 | JBDiGriz | What's the likelihood of having python bot available for 1.9? |
| 19:12.26 | Chestal | which is: 1) betetr interface instead of having pack/unpack everywhere |
| 19:12.32 | learner | they bots as they currently exist are rather useless completely |
| 19:12.45 | Chestal | 2) decide what to do about multicast and pings |
| 19:12.55 | TimRiker | Chestal: I'm not willing to give up on bots. They are very useful for testing even if that's the only use. |
| 19:13.02 | captain_proton | JBDiGriz: if somebody wants to work on it, very high |
| 19:13.05 | Chestal | 3) get an understanding on how the current udp code works and think about how to imrpove that |
| 19:13.18 | TimRiker | can we talk about bzadmin (ie: curses-bzflag) integration? |
| 19:13.38 | TimRiker | that seems to be working on removing the GL stuff which bots need to do too. |
| 19:13.55 | learner | Tim: I would expect either 1) they get munged into one libCommonNet (which is what I did for os x) or 2) have libcommon not call libnet (move those routines into libnet) |
| 19:14.03 | TimRiker | multicast is dead. kill it off. |
| 19:14.09 | Chestal | TimRiker: that's not so easy |
| 19:14.16 | Chestal | TimRiker: we have to decide on what to do with the pings |
| 19:14.29 | Chestal | TimRiker: where pings can be multicast, broadcast or from bzfls right now |
| 19:14.33 | TimRiker | why not? I killed it off completely in 1.8 |
| 19:14.47 | Chestal | TimRiker: we can, but we must decide what we want to have in the first place |
| 19:14.48 | TimRiker | "pings" can't be from bzfls |
| 19:15.02 | Chestal | TimRiker: it's the same kind of mesasge / data structure |
| 19:15.02 | learner | we really need to get rid of one of the Ping.cxx's regardless.. |
| 19:15.14 | Chestal | TimRiker: there's ping.cxx, which is used to real pings and bzfls pseudo-pings |
| 19:15.26 | captain_proton | iirc, src/common/Ping.cxx isn't used |
| 19:15.29 | TimRiker | we should require udp on the server (or at least start if without the option of not starting it) |
| 19:15.32 | Chestal | proton: it is used |
| 19:15.49 | captain_proton | Chestal: its not in the build... |
| 19:15.51 | TimRiker | and be ready to handle "ping" broadcasts on the servers udp port. |
| 19:16.15 | TimRiker | this means that servers on non-standard ports cannot be found on a LAN. that's ok with me. |
| 19:16.17 | Chestal | captain_proton: uh? 4 days ago I tried to rip off multicast (ditched some 100 lines of code), and I had to keep some parts of ping.cxx tomake it compile |
| 19:16.28 | Chestal | protonl: maybe it's only the class/struct definition in the header file then |
| 19:16.33 | captain_proton | Chestal: there are two Ping.cxx's |
| 19:16.40 | Chestal | captain_proton: oh? |
| 19:16.51 | captain_proton | src/common/Ping.cxx & src/net/Ping.cxx |
| 19:17.08 | TimRiker | there needs to be a new "get server/game info" msg that can be answered in one go without logging in. |
| 19:17.22 | TimRiker | then bzfls should ask for those and accept them as replies. |
| 19:17.35 | learner | Cap: so it can be removed today, then |
| 19:17.38 | Chestal | proton:that looks liek an error |
| 19:17.39 | JBDiGriz | Is it useful to bring up enet as a connection layer, which already maintains the "liveness" of the connection? |
| 19:17.41 | TimRiker | should work over udp for servers that can be reached that way and over tcp if they cannot. |
| 19:18.03 | Mayhem | Can enet be used by python? |
| 19:18.04 | learner | src/common/Ping.cxx does not appear to be used |
| 19:18.10 | Chestal | TimRiker: yes,I second that UDP message to query servers |
| 19:18.35 | TimRiker | the new server/game info packet should include servermsg/gametype/playerlimits/currentplayers/currentscores/etc. |
| 19:18.41 | JBDiGriz | Mayhem: It's a standard Unix library, so it should be able to be linked from python |
| 19:18.55 | TimRiker | we need to add admin-email to that. |
| 19:19.05 | learner | an automatic message class would be useful to automatically pack and unpack network messages, per Chestals comment |
| 19:19.08 | Chestal | TimRiker: but it coudl exceed typical MTU |
| 19:19.20 | captain_proton | Mayhem: yes |
| 19:20.00 | TimRiker | Chestal: nod. need to test the limits and decide what to do with msgs that are "too big". |
| 19:20.01 | captain_proton | the big issue with enet is that it makes a few things a bit harder - http proxy, using it from non-C/python languages (all the perl stuff breaks) |
| 19:20.37 | Chestal | I'd like to finish discussing multicast/pings first |
| 19:20.46 | larsl_56k | captain_proton: Couldn't SWIG or something similar be used to generate script interfaces? |
| 19:21.01 | Chestal | so, we want to keep the server dicsovery by pings in local network, i.e. broadcasting? |
| 19:27.01 | *** join/#bzflag TimRiker (~timr@c-67-163-110-59.client.comcast.net) |
| 19:27.01 | *** join/#bzflag larsl_56k (~larsl@md4690acb.utfors.se) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag HenryRiker (~HenryRike@c-67-163-110-59.client.comcast.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag fiberchunks (~frobozzpf@237.14.252.64.snet.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag terryc (~creeperz@host-11-76-220-24.midco.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag JBDiGriz (~JBDiGriz@adsl-63-204-118-6.dsl.sndg02.pacbell.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag doughecjka (~Joe@adsl-68-133.lou.bluegrass.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag sussudio (Suss@81.68.132.217) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag Mayhem (~Mayhem@dsl-217-155-141-174.zen.co.uk) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag Quol (~QuolSimo@modemcable052.11-203-24.mtl.mc.videotron.ca) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag DB7654321 (~DB7654321@chcgil2-ar7-4-3-184-165.chcgil2.dsl-verizon.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag trepan (~trepan@CPE0040f42db082-CM00e06f15f704.cpe.net.cable.rogers.com) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag snyke (~snyke@eros.bingo-ev.de) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag learner (sean@chr160dhcp1675.chrchv01.md.comcast.net) [NETSPLIT VICTIM] |
| 19:27.01 | *** join/#bzflag prot-work (~jupiter@161.97.199.99) [NETSPLIT VICTIM] |
| 19:27.02 | *** join/#bzflag Nidhoggr (mandrake@tiphareth.net) [NETSPLIT VICTIM] |
| 19:27.02 | *** join/#bzflag MrCooper (~daenzer@dclient80-218-118-173.hispeed.ch) [NETSPLIT VICTIM] |
| 19:27.02 | *** join/#bzflag captain_proton (~blardebla@12-203-245-57.client.attbi.com) [NETSPLIT VICTIM] |
| 19:27.02 | *** join/#bzflag nikt (nikt@nikt.org) [NETSPLIT VICTIM] |
| 19:27.02 | *** join/#bzflag Chestal (thilo@vmax.unix-ag.uni-siegen.de) [NETSPLIT VICTIM] |
| 19:27.02 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 19:27.02 | *** mode/#bzflag [+oooo TimRiker captain_proton Chestal ChanServ] by orwell.freenode.net |
| 19:27.03 | captain_proton | TimRiker: same as game port... |
| 19:27.18 | Chestal | proton: but the client doesn't know the game port |
| 19:27.20 | TimRiker | that does mean that you can't find servers on non-standard ports and so you can't find more than one server per host. |
| 19:27.26 | captain_proton | true |
| 19:27.49 | captain_proton | we could make it so if you want multiple servers on a machine, you have to alias your interface ;-) |
| 19:27.54 | Chestal | I am not sure all this broadcast discovery is worth the hassle |
| 19:27.55 | TimRiker | where the mcast (if it works) can handle that cause each instance should be able to open the same mcast port. |
| 19:27.55 | captain_proton | then it could always be 5155 |
| 19:28.04 | TimRiker | Chestal: it is. |
| 19:28.09 | Chestal | TimRiker: it's not :-) |
| 19:28.29 | Mayhem | Chestal: It is, from experience running LAN parties |
| 19:28.29 | TimRiker | Chestal: you'd me amazed at how many people I hear running game servers at companies where they have no net access. |
| 19:28.35 | TimRiker | s/me/be/ |
| 19:28.48 | Chestal | but it would only work in the local net anyway |
| 19:29.01 | Chestal | for example, here in the university, only very few peopel would be able todiscover ducati |
| 19:29.11 | TimRiker | Chestal: yep. and that seems to generally be enough for them. |
| 19:29.30 | Mayhem | A pseudo-listserver could listen on a known port, to nominate all the local servers |
| 19:29.56 | TimRiker | perhaps bzfls should listen and respond to the same type of packets on the same port? Then you could bring up bzfls internally? |
| 19:30.21 | captain_proton | the icky issue is that even though a company may have a class A network, they very rarely actually treat it as a /8, so we can only broadcast as /24 |
| 19:30.25 | TimRiker | course it would need to have proxies on the other lans... hmm. not likely. |
| 19:30.42 | Chestal | I wonder whetehr the bzfs<->bzfls protocol shouldn't be changed to use UDP |
| 19:30.46 | *** join/#bzflag Michaelh (Mouse@171-222.dynamic.visi.com) |
| 19:30.54 | Chestal | same for bzflag<->bzfls |
| 19:31.01 | Chestal | althouh, hmm |
| 19:31.04 | captain_proton | if anybody cares to look away from this scintillating discussion for the moment, http://jupiter.babylonia.flatirons.org/sexy.png |
| 19:31.07 | Chestal | maybe not for the latter, will get toobig |
| 19:31.08 | TimRiker | again, the mcast discovery is supposed to handle that, but how many corporate lans have mcast routing? not any I've seen. |
| 19:31.31 | captain_proton | indeed |
| 19:31.32 | learner | it really sounds like there needs to be a clean way for servers to intercommunication and inter-broadcast what other servers they know about |
| 19:31.39 | captain_proton | we've got multicast on some of our stuff at the uni |
| 19:31.45 | captain_proton | not too much though |
| 19:31.56 | TimRiker | learner: the servers would have the same routing issue. |
| 19:32.03 | Mayhem | learner: thats what the list server is for. |
| 19:32.16 | Chestal | how do other LAN games handle this? |
| 19:32.22 | learner | it would be a redundant backup |
| 19:32.39 | Chestal | do they support more than one server/host? |
| 19:32.47 | Mayhem | Half-life used to use a known port, if you had multiple server you had to kludge a script to return multiple address:ports |
| 19:32.57 | TimRiker | Chestal: some only do a list server. some do bcast on standard ports. I don't know of any that do mcast, but there might be some. |
| 19:32.58 | learner | I could run several servers on a school lan, for example, that might not be able to reach the list server from all but 1-2 places, but everyone would get the info from the few that could |
| 19:33.57 | learner | likewise, they may not be able to receive broadcast, but if enough bzfs's are close enough and chainable, everyone shares |
| 19:34.05 | Mayhem | learner: an internal list server for lan hosts... |
| 19:34.10 | TimRiker | we could have a server on a standard port be ready to accept/announce other servers. then servers on the same host could talk to the server on the standard port. |
| 19:34.49 | learner | as a user, I'd want to be able to reach ducati, even if I can't directly receive the annoncement of it from bzfls |
| 19:34.53 | TimRiker | and clients would then find each server on that host with one bcast. |
| 19:35.23 | learner | Tim, me likes |
| 19:35.26 | TimRiker | learner: we are not preventing that. you can still specify a server:port |
| 19:35.35 | learner | if you know it |
| 19:35.48 | Michaelh | what is this email about? |
| 19:35.48 | Michaelh | Ìû ðàäû ïðåäëîæèòü âàì íîâûé áåñïëàòíûé ïî÷òîâûé ñåðâèñ |
| 19:35.49 | Michaelh | http://www.mail15.com. Åãî îòëè÷èòåëüíûå îñîáåííîñòè: |
| 19:35.57 | learner | I'm thinking of joeshmoe who doesn't know of ducati, but would like to play on ducati |
| 19:36.02 | sussudio | Michaelh: extended ascii bunny terror? |
| 19:36.28 | Michaelh | How long is the meeting ? :) |
| 19:36.33 | learner | 4 days |
| 19:36.36 | Mayhem | Michaelh: till its done |
| 19:36.42 | Chestal | so, bzfs tried to bind to udp:5154 to receive broadcast pings |
| 19:36.46 | TimRiker | probably an hour. 23 minutes to go. |
| 19:36.59 | Chestal | if it cannot, it assumes that another server has already done so and will try to run in slave mode |
| 19:37.03 | TimRiker | Chestal: mcast pings, yeah. |
| 19:37.16 | Chestal | TimRiker: mcast? I thought simple broadcast? |
| 19:37.21 | TimRiker | oh. in the future... |
| 19:37.34 | learner | Mmm. mbone |
| 19:37.41 | Chestal | maybe mcast will work with ipv6, so in 5-10 years |
| 19:37.41 | TimRiker | just the standard udp port. probably 5155 still? |
| 19:37.52 | captain_proton | mcast will work much better with ipv6 |
| 19:37.55 | captain_proton | for a number of reasons |
| 19:38.15 | TimRiker | that's one reason I/we killed the old playerid. I plan to add ipv6 support. |
| 19:38.20 | Chestal | TimRiker: that would make the demultiplexing more dififcult for bzfs, I thinkit curently works on source ip/port? |
| 19:38.37 | Chestal | hmm, or mayeb when there's an easy way to see that it is a broadcast |
| 19:39.15 | Chestal | so, in a first version we could make it work with only 1 server/host |
| 19:39.21 | TimRiker | Chestal: trivial code. the recieve get's the IP and saves it. if it's a bcast discovery, just send it back without checking against player IPs |
| 19:39.24 | Chestal | than add master/slave logic later |
| 19:40.06 | TimRiker | could be a unicast discovery for all we care. |
| 19:40.23 | TimRiker | ie: bzfls would unicast to get the same info from the same port. |
| 19:40.36 | Chestal | uhm? |
| 19:40.43 | Chestal | unicast when? to whom? |
| 19:41.10 | TimRiker | ucp packet comes in on bzfs. it's a "discover", bzfs replies to the src address with game info. |
| 19:41.15 | TimRiker | er udp... |
| 19:41.43 | Chestal | yes, for client initiated discovery |
| 19:41.48 | Chestal | which would be a broadcast |
| 19:41.55 | TimRiker | or the bzfls server confirmation. |
| 19:42.07 | larsl_56k | Or a bzfquery. |
| 19:42.14 | Chestal | confirmation? |
| 19:42.19 | TimRiker | or a stats server collecting info, etc. |
| 19:42.39 | Chestal | bzfls doesn't poll, it just tries a half connect to the server to check if it's working |
| 19:42.45 | TimRiker | bzfs announces to bzfls but entries to not get added till bzfls can confirm back to bzfs. |
| 19:42.59 | Chestal | yes, but it tries a "real" connect over TCP |
| 19:43.10 | TimRiker | right. no reason why that could not be a "discovery" packet. |
| 19:43.25 | Chestal | TCP or UDP? |
| 19:43.35 | TimRiker | yeah. I'd change it to try udp first, and then revert to tcp and add that info to the list. |
| 19:44.10 | Chestal | bzfs->bzfls updates should then be the same type of packets |
| 19:44.18 | scanline | captain_proton: I wrote a radar view before I went to bed :) |
| 19:44.21 | scanline | captain_proton: http://navi.picogui.org/~micah/tmp/pybzflag_radar.png |
| 19:44.32 | Chestal | except for the lsit of players, everythign should fit nicely into a single udp packet |
| 19:45.14 | Chestal | let's assume we agree on some things in this meeting |
| 19:45.22 | Chestal | somebody should write those down then |
| 19:45.29 | fiberchunks | I am taking notes |
| 19:45.34 | Chestal | good :-) |
| 19:45.38 | fiberchunks | in a rambling sort of way |
| 19:45.39 | fiberchunks | :) |
| 19:46.03 | fiberchunks | if you could all agree on something, then list it out, it'll make life much easier :) |
| 19:46.29 | Chestal | so, client broadcast discovery, bzfs->bzfls is sorted out more or less |
| 19:46.35 | Chestal | what about client<->bzfls? |
| 19:46.49 | TimRiker | Chestal: then there would likely be a (unicast) getplayerlist and any others we need. same handling, send reply to requester without cheing against player IPs |
| 19:47.29 | Chestal | TimRiker: yes, but with lots of players, the reply will not fit. We could simply prune it of course |
| 19:47.43 | fiberchunks | Chestal: sum up client broadcast, bzfs->bzfls |
| 19:47.55 | TimRiker | seems that if you can http to the list server but not to any game servers, that's not useful. so I'd propose changeing the bzflag<->bzfls to be the same as the local bcast. |
| 19:47.56 | Chestal | fiber: not yet... |
| 19:48.00 | fiberchunks | k |
| 19:48.28 | Chestal | TimRiker: hmm, so udp? and bzfls replies with one udp "ping" reply for each server? |
| 19:48.38 | Chestal | because the full list will never fit |
| 19:48.52 | TimRiker | what happens when the bzfls or a bzfs reply includes more than one server? we likely want to say "this is reply x" and "there are [not] more" |
| 19:49.14 | TimRiker | then have the player do another request? that get's ugly for 30 servers.... |
| 19:49.27 | Chestal | Tim: if one of those gets lost, it doesn't matter, would just mean a server is missing inthe lsit the client displays |
| 19:49.31 | captain_proton | sounds like the world database :P |
| 19:49.37 | Chestal | TimRiker: jsut blast them over the netr |
| 19:49.46 | Chestal | without handshaking |
| 19:49.46 | TimRiker | multiple unrequested udp packets will have a high likelyhood of getting some dropped. |
| 19:49.49 | Mayhem | TCP sounds much more suitable for that sort of info |
| 19:49.50 | captain_proton | and if the "there are not more" one gets lost, its bad |
| 19:50.09 | Chestal | client doesn't need to know it's the last |
| 19:50.20 | Chestal | it already handlkes the sit dynamically while info is arriving |
| 19:50.24 | Chestal | eh, the list |
| 19:50.28 | scanline | mornin captain_proton. I see you added box walls to the 3D view :) |
| 19:50.31 | JBDiGriz | Or we use enet to do reliable transport over UDP |
| 19:50.40 | Chestal | with broadcast discovery,it does not know when allservers have respodned either |
| 19:51.04 | Chestal | and if we do not include the player list we should be able to get a couple servers into a single packet |
| 19:51.07 | TimRiker | Chestal: agreed, but it's much less likely to loose packets on a LAN. |
| 19:51.39 | Chestal | we coudl stick with TCP for client<->bzfls of course |
| 19:51.46 | TimRiker | perhaps the same "msg" but allow it over udp or tcp and reply in kind. |
| 19:51.49 | Chestal | but transmit the same packet format |
| 19:52.12 | captain_proton | scanline: well...a bit more than that, but yes |
| 19:52.14 | captain_proton | =} |
| 19:52.59 | Chestal | makes bzfls more complex of course because it has to multiplex a lot, orit would block until communcation is finished, don't know how it handles that right now |
| 19:52.59 | TimRiker | Chestal: so I think we have a plan. |
| 19:53.15 | Chestal | the master/slave ist not quite clear yet |
| 19:53.32 | TimRiker | add/modify gameinfo packets to contain what we want. use the same format for bcast and bzfls replies. |
| 19:53.54 | captain_proton | first server to run binds to a known port, then the other servers send add msgs to that port? |
| 19:53.58 | TimRiker | bzfs does unicast replies to bcast queries. bzfls does it over tcp. |
| 19:54.00 | Chestal | and maybe have two type of packets. One for 'type of server' and one for 'player info' |
| 19:54.16 | TimRiker | well bzfs does tcp to bzflag, but udp to servers if it can? |
| 19:54.46 | Mayhem | captain_proton: what if the first server goes down? then you have something like the MS master-browser wars? |
| 19:55.01 | TimRiker | Chestal: yes. clients that want both should be able to put both msgs in one udp packet. |
| 19:55.32 | TimRiker | captain_proton: nope. server on standard game port is master. |
| 19:55.47 | captain_proton | what about the point that Mayhem just brought up |
| 19:55.47 | scanline | Chestal: I already have a big glob of 100% nonblocking network code in python we could use for a bzfls :) |
| 19:56.07 | TimRiker | no wars. only one can run on the standard port. |
| 19:56.10 | Chestal | maybe bzfls should be a 100% rewrite anyway |
| 19:57.01 | scanline | hooray for rewrites! |
| 19:57.15 | Mayhem | TimRiker: other hosts may have notified the server os 5155 that is no longer there. What is the fallback? |
| 19:57.36 | TimRiker | Mayhem: they all go away. |
| 19:57.47 | Chestal | other hosts? |
| 19:57.55 | Chestal | the master is per host, isn't it? |
| 19:58.04 | TimRiker | Mayhem: the list. same as bzfls now. if you kill it, there is no list. |
| 19:58.19 | *** join/#bzflag bzgirl (~brat@toronto-hs-64-26-176-100.s-ip.magma.ca) |
| 19:58.23 | Mayhem | yes. so we are basically talking about bzfls on a LAN |
| 19:58.28 | TimRiker | bzfs would default to offering to be "master" for local IPs only probably. |
| 19:58.56 | TimRiker | but the central (0 player?) bzfs would be master for any IP. |
| 19:59.16 | Chestal | hmm |
| 19:59.24 | Chestal | then we add an option liek -master <ip>? |
| 19:59.32 | Chestal | because the other servers cannot know automatically |
| 19:59.48 | Chestal | I don't see what this should be good for |
| 20:00.04 | TimRiker | probably an option like -openmaster |
| 20:00.07 | Mayhem | whats wrong with -publiclist? |
| 20:00.31 | Chestal | I would go with a default discovery port, liek 5154 |
| 20:00.33 | TimRiker | Mayhem: still needed. that's the address of the server to inform. |
| 20:00.42 | Chestal | and only use local master forwarding |
| 20:01.03 | Chestal | servers would be able to automatically agree on which of the loacl servers is master |
| 20:01.21 | TimRiker | no agreement needed. the one on the standard port is master. |
| 20:01.24 | Chestal | could even handle failure of master automatically |
| 20:01.48 | TimRiker | Chestal: nope. that requires sharing list info, which I'm NOT proposing. |
| 20:01.58 | Chestal | discovery would only work when you use defautl port then |
| 20:02.03 | Chestal | which isok, but could be confusing |
| 20:02.12 | Chestal | sharing list info? |
| 20:02.20 | learner | why not, Tim? |
| 20:02.25 | Chestal | that would not be necessary |
| 20:02.28 | TimRiker | Chestal: yes. there needs to be a standard port server someplace. |
| 20:02.38 | Chestal | TimRiker: or we could use 5154 as it is now |
| 20:02.43 | TimRiker | learner: cause it's a mess. think it through. |
| 20:02.53 | Chestal | sharign is not needed in either case |
| 20:03.10 | TimRiker | Chestal: true. but that's the registered port for the mcast discovery of the old protocol. |
| 20:03.40 | Chestal | when we just use 5155 we cannot gracefully recover frommaster failure. But that might be ok |
| 20:03.47 | *** part/#bzflag Quol (~QuolSimo@modemcable052.11-203-24.mtl.mc.videotron.ca) |
| 20:03.49 | TimRiker | I'm talking to iana now about port numbers. |
| 20:04.31 | TimRiker | Chestal: yep. |
| 20:04.31 | captain_proton | =) |
| 20:04.41 | learner | :) |
| 20:04.48 | Chestal | ok, one server used -p 5155 and is local master |
| 20:04.55 | TimRiker | at some point we should work on having 2 masters. but I'm not too worried about it. |
| 20:05.16 | Chestal | second server (-p 5789) sends update pings to bzfls and local master if configured so? |
| 20:05.21 | TimRiker | others impressions? how stable/problematic has the single list server been? |
| 20:05.40 | captain_proton | it seems to be pretty stable |
| 20:05.45 | Chestal | bzfls sometimes shows wrong player counts |
| 20:05.47 | captain_proton | when its not being DoSed |
| 20:05.51 | learner | it's been fine, but it is a single point of failure |
| 20:05.55 | TimRiker | Chestal: no. each server can talk to bzfls. does not need to be master to do that. |
| 20:06.01 | JBDiGriz | I haven't had many problems connecting to the single list server, only occasional failures. Often wrong player counts. |
| 20:06.13 | TimRiker | Chestal: that's cause the servers _send_ the wrong counts. |
| 20:06.28 | Chestal | Tim: that's not what I meant. but slave server sends update packets to bzfls and local master (or none, or only one of those) |
| 20:07.29 | TimRiker | Chestal: ahh... hmm. yeah I guess. bzfs looks for one listserver on publiclist and then one on standardport if it's not on standard port itself. |
| 20:08.04 | Chestal | and master replies with one udp packets for every server it manages when it receives a broadcast ping |
| 20:08.21 | TimRiker | so I guess we would have a list of "bzfls" servers anyway. might as well add the ability to have more on the list. |
| 20:08.41 | TimRiker | Chestal: yep. |
| 20:09.05 | Chestal | ok, I think this topic is more or less finished then |
| 20:09.11 | TimRiker | but master does _not_ send slave info directly to bzfls |
| 20:09.12 | Chestal | fiber: are you with us? :-) |
| 20:09.17 | fiberchunks | indeed |
| 20:09.22 | fiberchunks | sum up :) |
| 20:09.59 | TimRiker | oh, server reply should include version, platform, admin email, uptime. any others? |
| 20:10.20 | larsl_56k | Short comment? |
| 20:10.23 | Chestal | TimRiker: server settings? jumping, # shots etc |
| 20:10.25 | fiberchunks | game info? |
| 20:10.26 | larsl_56k | Or description. |
| 20:10.29 | TimRiker | yes srvmsg |
| 20:10.34 | Chestal | player counts |
| 20:10.44 | TimRiker | yes, all the current stuff, plus those. |
| 20:10.50 | Chestal | ok |
| 20:11.05 | learner | not just short-1-liners, but honest 2 god motd's would be desireable |
| 20:11.08 | Chestal | and the other reply contains lsit of players with callsigns, team, score |
| 20:11.21 | TimRiker | learner: no. just 1 liners. |
| 20:11.30 | Chestal | basically what the current MsgQueryGame or wahtever it is called is sending |
| 20:11.43 | TimRiker | perhaps an optional server-web-page-url ? |
| 20:12.04 | learner | perhaps as part of the additional data where player info and rules are obtained, then? |
| 20:12.50 | TimRiker | learner: and what would be the size limit? I can't think of much that's useful that I want to have sent over the wire to every single player that asks for a server list. |
| 20:12.53 | Chestal | fiber: define new 'ping' packet types: a) serverinfo b) playerlist. server replies with UDP unicast when it receives such a UDP packet |
| 20:13.04 | TimRiker | this should be a "locator" not a advertising channel. |
| 20:13.06 | Chestal | fiber: might come from client, then it's a broadcastr to discover servers |
| 20:13.30 | Chestal | fiber: or from bzfls to check server after it announced itself (this part is maybe a bit fuzzy right now) |
| 20:13.37 | learner | As a server admin, there are details about my server that I'd like to announce that don't fit on one line and is too much once they are in the game |
| 20:13.50 | Chestal | fiber: client<->bzfls will be TCP but use the same packet types |
| 20:14.09 | larsl_56k | learner: We could use a server-web-page-url for that. |
| 20:14.15 | Chestal | fiber: to make local discovery work with more than one server per host, server with default port 5155 will be master for other local servers |
| 20:14.18 | TimRiker | Chestal: yeah, a msgsendme("this test text") might be what bzfls sends to check the connection. |
| 20:14.31 | learner | then the user would have to leave bz to find out about a server |
| 20:14.39 | learner | if Im' running fullscreen, that's not acceptable |
| 20:14.53 | learner | it means I have to quit bz |
| 20:14.55 | TimRiker | learner: hence the url. put whatever you like there. |
| 20:15.13 | TimRiker | learner: and you can send more raw text when they connect. |
| 20:15.16 | scanline | learner: bz just needs one of those jetstream consoles then that you can run vim and links inside :) |
| 20:15.18 | JBDiGriz | learner: Most user's don't really care enough, and the ones that do will check it. |
| 20:15.51 | learner | so then I'd be left to scribble down a url, quit bz, dig up a browser, and then read? that seems awefully user unfriendly when a few lines of description would solve the problem |
| 20:16.00 | TimRiker | learner: and you can send more raw text when they connect. |
| 20:16.16 | Chestal | bzflag could make use of Gecko ;-) |
| 20:16.22 | learner | again, that usually too much for in-game, unless server's could have a splash screen |
| 20:16.36 | learner | splash screen motd would be a perfect alternative |
| 20:16.50 | JBDiGriz | We definitely need to be able to copy and paste out of bzflag, but that's another topic for another day. |
| 20:17.09 | JBDiGriz | I like the idea of a server splash screen, write that one down as well. |
| 20:17.14 | TimRiker | learner: I'd be willing to include that. patches welcome. "end player license agreement......" "type \"yes\" to play here" |
| 20:17.20 | larsl_56k | Yes, splash screen would be nice. |
| 20:17.37 | larsl_56k | With server logos and stuff if we get content management going. =) |
| 20:17.50 | JBDiGriz | shh, don't tell learner he just volunteered himself! |
| 20:17.51 | learner | server logs is another pet peave |
| 20:18.02 | TimRiker | learner: patches welcome |
| 20:18.06 | learner | heh, I heard that jb :) |
| 20:18.09 | learner | and tim :) |
| 20:18.09 | Chestal | to discuss something small: does anyoen know how the current UDP 'connection' establishment works? |
| 20:18.14 | Chestal | I know it has been changed |
| 20:18.25 | scanline | Chestal: yes, I'm the one that changed it |
| 20:18.41 | Chestal | I assume client sends a special message to server over UDP |
| 20:18.44 | scanline | I just removed an unused field in MsgUDPLinkEstablished and moved it from TCP to UDP |
| 20:18.50 | Chestal | and server learns port nuber from that message |
| 20:18.51 | scanline | no major change |
| 20:19.02 | Chestal | does this mesage include the player id? |
| 20:19.03 | TimRiker | in the new world, player should send udp hello over udp, server replies with ack, player replies with 2nd ack. |
| 20:19.26 | TimRiker | that's more or less how it works now, except that the server offers first. let's kill that. |
| 20:19.28 | scanline | Chestal: I didn't change that part.. no player id, just port number, but it's a TCP message |
| 20:19.44 | JBDiGriz | fiberchunks: Did you get enough to feel comfortable writing the notes on bzfls? |
| 20:20.01 | fiberchunks | heh, from a code twit perspective -- yes |
| 20:20.06 | fiberchunks | lemme flood a minute: |
| 20:20.20 | TimRiker | we should not be sending port number or ip addresses. the server/client should get that info from the transport layer. |
| 20:20.33 | fiberchunks | <PROTECTED> |
| 20:20.33 | fiberchunks | <PROTECTED> |
| 20:20.33 | fiberchunks | <PROTECTED> |
| 20:20.33 | fiberchunks | <PROTECTED> |
| 20:20.33 | fiberchunks | <PROTECTED> |
| 20:20.33 | fiberchunks | <PROTECTED> |
| 20:20.37 | Chestal | hmm, I think c->s udprequest (player id) s->c udpcheck(player id) c->s udpack would be best |
| 20:20.38 | fiberchunks | <PROTECTED> |
| 20:20.40 | fiberchunks | <PROTECTED> |
| 20:20.42 | fiberchunks | <PROTECTED> |
| 20:20.43 | *** join/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 20:20.44 | fiberchunks | <PROTECTED> |
| 20:20.46 | fiberchunks | <PROTECTED> |
| 20:20.48 | fiberchunks | <PROTECTED> |
| 20:20.50 | fiberchunks | <PROTECTED> |
| 20:20.52 | fiberchunks | <PROTECTED> |
| 20:20.56 | fiberchunks | <PROTECTED> |
| 20:21.13 | fiberchunks | bzfs->bzfls: |
| 20:21.13 | fiberchunks | <PROTECTED> |
| 20:21.13 | fiberchunks | <PROTECTED> |
| 20:21.13 | fiberchunks | <PROTECTED> |
| 20:21.14 | fiberchunks | <PROTECTED> |
| 20:21.18 | fiberchunks | <PROTECTED> |
| 20:21.20 | fiberchunks | <PROTECTED> |
| 20:21.22 | fiberchunks | that's it thus far |
| 20:21.24 | TimRiker | fiberchunks: update a wiki and send the url. |
| 20:21.34 | fiberchunks | ah, :) good idea :) |
| 20:21.36 | Chestal | we already have a list of list servers |
| 20:21.44 | JBDiGriz | fiberchunks: Put it in the WIP wiki |
| 20:21.44 | Chestal | only that this list is of size one usually |
| 20:22.09 | Chestal | at least we have thislist for the client |
| 20:22.14 | Chestal | not sure whetehr the server can use it, too |
| 20:22.16 | TimRiker | k, other refrain from editing WIP. comment to fiberchunks here (during this meeting) |
| 20:22.30 | fiberchunks | TimRiker> yes, that would be nice |
| 20:22.38 | captain_proton | sooo |
| 20:22.48 | fiberchunks | if you want me to write it: please fiberchunks: me |
| 20:22.59 | Chestal | the bad thing about the new player id is, that it is not unique |
| 20:23.06 | fiberchunks | so I can sort it from regular chatter |
| 20:23.36 | Chestal | this might cause some trouble for the UDP traffic when we have bad luck |
| 20:23.37 | TimRiker | Chestal: there is code in both client and server to handle multiple list servers, but afaik nobody has ever tested it. |
| 20:24.05 | TimRiker | Chestal: huh? not unique? |
| 20:24.40 | Chestal | TimRiker: not on the network layer |
| 20:25.16 | Chestal | TimRiker: but I think it's extremely improbable to receive a UDP packet from th same ip/port that got extremely delayed later |
| 20:25.53 | Chestal | the UDP demultiplexer uses IP+port |
| 20:25.58 | Chestal | which gets reused pretty fast |
| 20:26.00 | TimRiker | Chestal: huh? I'm still lost. |
| 20:26.06 | Chestal | so, I fire up bzflagf |
| 20:26.13 | Chestal | then reconnect to same server |
| 20:26.17 | Chestal | client uses same IP+port |
| 20:26.29 | Chestal | server cannot distingusih between old and new udp packets from that client |
| 20:26.39 | TimRiker | udp server info packets do not have plyer numbers, just IPs. server replies right away and does not add to any list. |
| 20:26.46 | Chestal | bad luck: old UDP packet travels to moon and back, then hits server after new client connected :-) |
| 20:26.56 | JBDiGriz | What's the implications for two clients behind a NAT? |
| 20:27.07 | Chestal | TimRiker: no, I'm talking about normal game communication |
| 20:27.17 | captain_proton | JBDiGriz: at the moment, it could associate wrongly if they both start up udp at about the same time |
| 20:27.19 | Chestal | TimRiker: but I think we can ignore the problem, it shouldn't really happen |
| 20:27.38 | TimRiker | Chestal: when you reconnect you should have a new port number. |
| 20:27.47 | Chestal | TimRiker: client tries to use 17200 |
| 20:28.01 | TimRiker | client should use the same port for udp as it uses for tcp. that needs to get fixed. |
| 20:28.46 | JBDiGriz | Let's discuss the possibility of using enet to get rid of TCP entirely. |
| 20:28.57 | Chestal | I think the curent UDP 'handshake' is happy with receiving any kind of UDP packet, i.e. is learns port from the first message it receives |
| 20:29.03 | TimRiker | (the server may not see them as the same port.... due to NAT. but it will see a different port than the last game you were in. |
| 20:29.11 | Chestal | when we put the real handshake in, it should only use the special messages |
| 20:29.30 | TimRiker | Chestal: yes. that should change. udprequest should include a player number. |
| 20:29.31 | Chestal | and include the slot player id in the message fromthe player |
| 20:29.39 | Chestal | so server does not have to make wild guesses for NAT |
| 20:29.58 | TimRiker | in the new world, we should always have the server assigned player number first. |
| 20:30.19 | Chestal | k, that sounds good |
| 20:30.26 | JBDiGriz | Definitely, nothing else can arbitrate. |
| 20:30.27 | TimRiker | k. summarize for fiberchunks? |
| 20:31.00 | TimRiker | bzfs always listens on udp |
| 20:31.16 | TimRiker | player requests udp handling (always) |
| 20:31.30 | TimRiker | that request includes the server supplied player number. |
| 20:31.51 | TimRiker | server acks (probably also with player number) |
| 20:32.03 | TimRiker | that's all yes? |
| 20:32.22 | Chestal | no client ack after that? |
| 20:32.24 | fiberchunks | is there not a player ACK as well? |
| 20:32.30 | Chestal | so server can be sure that comm. is ok? |
| 20:32.48 | TimRiker | oh, yeah. server needs to ack to confirm backpipe. |
| 20:33.07 | TimRiker | uh scratch that... /me thinks... |
| 20:33.13 | Chestal | of course, any of these 3 messages might get lost |
| 20:33.19 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (2 files): Add player dots to radar |
| 20:33.31 | fiberchunks | Chestal: in which case? ... |
| 20:33.33 | TimRiker | yeah. Chestal is right... |
| 20:33.52 | TimRiker | fiberchunks: player acks the server ack - so server knows to start using the udp pipe. |
| 20:34.05 | Mayhem | We're doing a 3-way handshake in udp :) |
| 20:34.17 | Chestal | if one of the first two messages gets lost, both will stick with tcp only |
| 20:34.20 | TimRiker | Chestal: player could restart that request if we want. |
| 20:34.21 | Chestal | problem is when the finalack gets lost |
| 20:34.37 | Chestal | in that case client is happy, but server is not |
| 20:35.19 | TimRiker | Chestal: but then any future udp msg player->server could replace the ack. in fact we might not need a separate ack here? |
| 20:35.34 | scanline | how about the client pings the server a few times to see whether a UDP connection would work, then does the actual UDP negotiation over TCP? |
| 20:35.51 | scanline | not necessarily in that order... |
| 20:36.09 | TimRiker | scanline: nope. there is no other negotiation other than making sure traffic can get back and forth. |
| 20:36.29 | Chestal | well, there is the player id |
| 20:36.41 | TimRiker | Chestal: that comes first over tcp |
| 20:36.46 | *** part/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 20:36.56 | scanline | TimRiker: if that's the goal, it would make sense to send multiple players back and forth so there's less chance the player gets unlucky and the negotiation packets get lost |
| 20:36.58 | Chestal | yes, but would it be possible, that server still learns the wrong port? |
| 20:37.05 | scanline | s/players/packets/ |
| 20:37.13 | Chestal | seems to be improbable because we include the playerid in the initial message |
| 20:37.41 | TimRiker | Chestal: well you can hack it, but the server does not register the player port till it gets the udprequest which includes the right playerid. |
| 20:38.33 | TimRiker | scanline: that's what I said... the player might want to restart things a few times. but there are no more packet types. |
| 20:38.52 | scanline | ah, ok |
| 20:39.39 | *** join/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 20:39.39 | TimRiker | might want to disallow server udp acks to IPs other than the tcp IP. yes? |
| 20:39.56 | TimRiker | fiberchunks: how's the pay? |
| 20:40.02 | fiberchunks | TimRiker> you tell me :) |
| 20:40.14 | Chestal | Tim: uhm? don't underdstand that? how could it be a different ip? |
| 20:40.15 | TimRiker | fiberchunks: lousy. ;-) |
| 20:40.28 | TimRiker | Chestal: NAT boxes or other hackers. |
| 20:40.43 | Chestal | TimRiker: the curernt code assumes the IP is the same |
| 20:40.50 | Chestal | TimRiker: we could keep that part |
| 20:40.59 | TimRiker | server is full, I spam udp packets claiming to be each player at my address. non-udp players now don't get game info. |
| 20:41.24 | Chestal | so, a MsgRequestUdp(playerid) would have to match player[playerid[.ip |
| 20:42.06 | TimRiker | Chestal: yes. this means that some oddball network where the udp gets NATted differently than the tcp packets will not be able to udp play. tough I say. |
| 20:42.29 | Chestal | never seen such a thing, which doesn't mean that such a beast doesn't exist of course |
| 20:42.40 | TimRiker | allowing the above DoS is a worse issue. so let's check the IP. |
| 20:42.48 | TimRiker | I've seen it. ugh. |
| 20:42.51 | JBDiGriz | Or we combine all traffic into a single UDP stream and avoid the issue. |
| 20:43.14 | Chestal | maybe in a later version :-) |
| 20:43.28 | Chestal | enet is udp only, yes? |
| 20:43.35 | JBDiGriz | yes. |
| 20:43.49 | CIA | 03davidtrowbridge * 12pybzflag/ (3 files in 3 dirs): lots of nifty drawing |
| 20:45.03 | Chestal | UDP packets are now 'raw', i.e. without any additional header? |
| 20:45.04 | fiberchunks | have we resolved the case where final ACK (client->server) is lost, or if it is even necessary? |
| 20:45.06 | TimRiker | so we are almost at 2 hours. what else do we want to talk about? |
| 20:45.16 | scanline | Chestal: yes |
| 20:45.31 | fiberchunks | all: here's the agenda as it was discussed initially: |
| 20:45.35 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (RadarView.py): Add zoom, center, and angle attributes for the radar |
| 20:45.39 | CIA | 03brlcad * 12bzflag/include (WordFilter.h): yet another utility method to perform the character swapping |
| 20:45.40 | fiberchunks | Agenda: |
| 20:45.40 | fiberchunks | 1. Network Interface: |
| 20:45.40 | fiberchunks | <PROTECTED> |
| 20:45.40 | fiberchunks | <PROTECTED> |
| 20:45.40 | fiberchunks | 2. Additional Capabilities: |
| 20:45.41 | fiberchunks | <PROTECTED> |
| 20:45.43 | fiberchunks | 3. Implications before implementation of additional capabilities |
| 20:45.45 | fiberchunks | 4. Bot Code |
| 20:45.47 | fiberchunks | 5. Miscellanea |
| 20:45.51 | scanline | Chestal: the only functionality that header gave was allowing multiple messages per packet.. that functionaliry wasn't used, and when it is reimplemented it can be done without an extra header |
| 20:45.59 | TimRiker | hmm requiring the ack could save resetting "got udp" for each incoming udp packet on the server, bit means that the packet might get lost. |
| 20:46.12 | captain_proton | i'd like to suggest an architecture for the protocol separation |
| 20:46.23 | Chestal | scanline: so all code stubs handling this in bzfs were removed also? |
| 20:46.26 | fiberchunks | captain_proton> added to agenda |
| 20:46.28 | captain_proton | functions to send each message that take the data required as arguments |
| 20:46.39 | Chestal | scanline; I saw some things liek udp queues etc. in there |
| 20:46.44 | scanline | Chestal: yes.. it was a mess, when it's reimplemented it could be done much better |
| 20:46.50 | scanline | Chestal: yes, all the udp queues are gone |
| 20:46.55 | captain_proton | then register callbacks for each message type (2-char id) |
| 20:47.03 | scanline | Chestal: we can use the STL now, no need for all that code that managed linked lists itself |
| 20:47.04 | TimRiker | fiberchunks: for the moment... server sets "have udp" on the next received udp packet regardless of type. |
| 20:47.04 | larsl_56k | captain_proton: That sounds very nice. |
| 20:47.23 | fiberchunks | TimRiker> got it |
| 20:47.51 | scanline | captain_proton: why 2-char id? bzflag already has the MsgFoo constants, I like them a lot better than the 2-char IDs :) |
| 20:48.04 | captain_proton | scanline: well - yes, it would use the constants |
| 20:48.09 | scanline | k |
| 20:48.32 | scanline | ooh, boxes have tops now |
| 20:48.43 | TimRiker | captain_proton: the issue with that is that the pack/unpack need to know every struct in every msg type so it ends up depending on the world and having the world depend on it. |
| 20:48.46 | scanline | and are those teleporters? |
| 20:49.07 | captain_proton | teleporter fields, no borders yet |
| 20:49.15 | *** join/#bzflag Legolas (~Legolas@adsl-68-73-89-127.dsl.emhril.ameritech.net) |
| 20:49.15 | scanline | ah, ok |
| 20:50.00 | TimRiker | captain_proton: comments? |
| 20:50.37 | captain_proton | TimRiker: well the pack gets that information from the arguments passed to it |
| 20:50.52 | TimRiker | again, it need to know all of them |
| 20:51.04 | captain_proton | but you need to know the protocol to send a message anyway |
| 20:51.07 | TimRiker | er needs... |
| 20:51.27 | Chestal | ehm, what would be passed to the callbacks? |
| 20:51.31 | TimRiker | yes, but at present all the code needs to know network stuff, but network stuff does not need to know all the code. |
| 20:51.48 | captain_proton | the only real "network" stuff that would need to know the code are the callbacks |
| 20:52.02 | captain_proton | and even then, its a much more concentrated handling of it |
| 20:52.02 | scanline | network and protocol can be separate |
| 20:52.10 | captain_proton | (the callbacks themselves would not be in libnet) |
| 20:52.34 | TimRiker | all the callbacks? so libnet would now depend on bzflag/ stuff? |
| 20:53.13 | captain_proton | one thing this would require is adding length fields to the messages that don't have them |
| 20:53.21 | captain_proton | so the network layer could send the callback only the data that was applicable |
| 20:53.26 | Chestal | length is in the header? |
| 20:53.28 | TimRiker | yes. all packets should have length. |
| 20:53.33 | captain_proton | most have length :) |
| 20:53.46 | Chestal | are there mesasges which do not have the common header? |
| 20:53.56 | TimRiker | this includes adding length to the sub packets in worlds. I think all others have them now except server id initial crap. |
| 20:54.20 | Chestal | again: what is passed to the callbacks? raw buffer? |
| 20:54.32 | TimRiker | initial handshake should be standard headers too. |
| 20:54.34 | captain_proton | Chestal: raw buffer, but only the part of the raw buffer from that message |
| 20:54.47 | scanline | why raw buffer rather than unpacked message contents? |
| 20:54.49 | Chestal | hmm, wouldn't it be nicer to additpnally have wraper structs for messages? |
| 20:54.56 | *** part/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 20:54.59 | Chestal | structs could have ctors and automatic pack/unpack |
| 20:55.21 | scanline | actually... |
| 20:55.38 | Chestal | mabe there are somemesasges which are difficuly tohandle this way, i.e. with dynamic structure? |
| 20:55.38 | scanline | captain_proton: you've seen the protocol goop for pybzflag.. think it would be possible to do something similar in C++ using templates? |
| 20:55.41 | TimRiker | a msg should probably also have address info with is. and server added player info. |
| 20:56.22 | captain_proton | scanline: eh - maybe with a common base class |
| 20:56.42 | TimRiker | I suppose player number _or_ address info would suffice. |
| 20:56.46 | scanline | captain_proton: I'm referring to how you list a bunch of StructEntry instances and it automatically packs and unpacks |
| 20:57.02 | captain_proton | ah |
| 20:57.19 | TimRiker | captain_proton: yeah, common msg class that include unpacked header info and player src info would be a Good Thing. |
| 20:57.23 | scanline | I really love the flexibility that format gives me :) |
| 20:57.41 | captain_proton | and then the subclasses would unpack the rest of themselves |
| 20:57.53 | Chestal | two ctors |
| 20:57.58 | Chestal | one for unpacking, one for packing |
| 20:58.09 | captain_proton | and a callback would take a Msg* |
| 20:58.11 | Chestal | or maybe do it in a seperate function if it's better to add some info later |
| 20:58.31 | scanline | so what about receiving messages, where you need to grab the header, figure out what message class to use, then grab the rest? |
| 20:58.51 | scanline | methinks it would be better to make the header separate rather than a base class |
| 20:59.12 | scanline | when you pack a message, it would use a header instance to pack its header |
| 20:59.21 | captain_proton | well - the issue is that we want to be able to register a callback using a single function |
| 20:59.24 | scanline | when you unpack a message, you'd need a way of selecting a message class |
| 20:59.25 | Chestal | a factory would look at the header on decide on the type |
| 20:59.27 | captain_proton | addCallback(message, function) |
| 20:59.37 | captain_proton | rather than addMsgMessageCallback(function) etc |
| 20:59.42 | larsl_56k | captain_proton: Could be a template. |
| 20:59.51 | larsl_56k | Although it might be messy. |
| 20:59.54 | scanline | Chestal: right. but it means the message class needs a way to unpack the header, then the rest of the message |
| 21:00.13 | scanline | unless you unpack the header by hand, stick it back on the front of the message, and unpack the whole thing |
| 21:00.44 | Chestal | scanline: yep, so header would not be base class, but a member |
| 21:00.50 | scanline | yep |
| 21:00.59 | scanline | then you could use that header class on its own to decide what message type it is |
| 21:01.01 | Chestal | if we need to store it at all |
| 21:01.38 | TimRiker | 2 hours folks... I need to watch the kids for a while... back later. |
| 21:01.43 | Chestal | hmm, actually it could still be derived me thinks |
| 21:01.47 | Chestal | bye Tim |
| 21:01.59 | captain_proton | how about this: |
| 21:02.01 | JBDiGriz | What's your final word on bots TimRiker? |
| 21:02.17 | captain_proton | protocol loop keeps a msgid->class mapping |
| 21:02.27 | Chestal | scanline: factory would create MsgHeader object and pass this to ctor of MsgBeginShot |
| 21:02.32 | TimRiker | sounds like you're headed in the right direction. summarise all this on the wiki and email it out? might want to wait till tomorrow and point to the ibot log as well. |
| 21:02.34 | captain_proton | when it gets a msg, it uses that to ctor the class, then sends it off to the callback |
| 21:03.02 | TimRiker | JBDiGriz: they stay. clean them up or rework them at will, but do NOT remove them. |
| 21:03.13 | scanline | captain_proton: sounds good |
| 21:03.15 | Chestal | question is, do we ned to trigger different callbacks for the same mesasge types? |
| 21:03.18 | JBDiGriz | I'll post the log on centrum along with a list of participant. fiberchunks is well on the way to adding in the wipi stuff. |
| 21:03.19 | captain_proton | TimRiker: what about if we write a bot in python? can we eliminate the bots then? :) |
| 21:03.37 | learner | heh |
| 21:03.42 | TimRiker | captain_proton: perhaps. give me a python bot to look at. ;-) |
| 21:03.48 | captain_proton | heh |
| 21:04.10 | JBDiGriz | scanline: How long would it take to come up with a python bot which is like current bots? |
| 21:04.11 | Chestal | when joining the game, there's a loop handling different kind of messages |
| 21:04.18 | Chestal | before we enter the main game loop |
| 21:04.29 | fiberchunks | captain_proton> you wanna sum up architecture decision for me? |
| 21:04.39 | captain_proton | fiberchunks: i don't think we're quite decided yet |
| 21:04.43 | fiberchunks | k |
| 21:04.57 | captain_proton | Chestal: thats up to whatever client happens to be using it |
| 21:05.08 | captain_proton | if the client wants to remove one callback and add another for a message, thats fine |
| 21:05.31 | Chestal | during the join process, it seems to be wrong to use callbacks at all I think |
| 21:05.38 | Chestal | sounds more confusing to me |
| 21:06.24 | captain_proton | eh - not really |
| 21:06.24 | captain_proton | just requires a state machine, which is sort of what we have anyways |
| 21:06.30 | scanline | would be good to start moving everything toward callbacks so maybe eventually everything can be async |
| 21:06.47 | captain_proton | yes |
| 21:06.55 | Chestal | how are keyboard events handled rightg now? |
| 21:06.59 | captain_proton | i really want to get the main network loop separate from everything, so async is easy |
| 21:07.08 | captain_proton | same way they were handled before |
| 21:07.18 | captain_proton | the keybinding is different |
| 21:07.38 | captain_proton | remember commands from 1.8? |
| 21:08.28 | Chestal | somewhat |
| 21:09.22 | captain_proton | what happens is that a key gets pressed, it handles hard-coded keybindings (like esc), then checks the keymanager to see if its bound |
| 21:09.34 | captain_proton | if it is, it tells the command manager to execute whatever the keymgr returns |
| 21:11.16 | Chestal | hmm |
| 21:11.29 | Chestal | wasjust wondering whether key events and message events should be the same thing |
| 21:11.44 | captain_proton | i don't think so |
| 21:11.50 | captain_proton | the way they're handled is very different |
| 21:12.08 | sussudio | can someone kick a cheater off xmission? |
| 21:12.31 | *** join/#bzflag [TLZ]Ginku (~Gehm@pD958E663.dip.t-dialin.net) |
| 21:12.53 | sussudio | ~xmission |
| 21:13.20 | [TLZ]Ginku | hallo |
| 21:13.31 | learner | hi |
| 21:13.35 | scanline | can someone join brlcad.org and wander around a bit? |
| 21:13.35 | *** join/#bzflag Legolas (~Legolas@adsl-68-73-89-127.dsl.emhril.ameritech.net) |
| 21:13.38 | Chestal | well, I don't really see the difference between using callbacks and the currenty way in handling network mesasgea anyway |
| 21:13.49 | Legolas | anybody seen spiff? |
| 21:14.11 | captain_proton | current way uses a huge switch statement |
| 21:14.15 | Chestal | it's all inside one big switch now anyway, so it's the same thing basically |
| 21:14.18 | captain_proton | actually i think it uses about 4 switch statements |
| 21:14.29 | Chestal | messages only happen in there |
| 21:14.33 | Chestal | and will so in the future |
| 21:14.44 | Chestal | there are some excpetins though |
| 21:14.45 | captain_proton | if we do callbacks, we can have the message structures automatically unpack themselves |
| 21:14.49 | Chestal | joing server and list sevrer handling |
| 21:15.03 | Chestal | we can do that right now already |
| 21:15.08 | Chestal | it will be done before the callbacks happen |
| 21:15.14 | [TLZ]Ginku | don't understand anything :-( |
| 21:15.17 | Chestal | factory creates struct wrappers |
| 21:15.28 | Chestal | structs unpack/pack themselves |
| 21:15.40 | Chestal | then this info can get passed to a function which handles the mesasge |
| 21:15.47 | Chestal | call it a callback if you want so :-) |
| 21:15.48 | captain_proton | and it keeps us from having 1000-line functions |
| 21:15.58 | [TLZ]Ginku | hmmmm |
| 21:16.02 | [TLZ]Ginku | ncu |
| 21:16.22 | Chestal | so, how do we handle server discovery |
| 21:16.23 | scanline | whee |
| 21:16.32 | Chestal | right now there's some scary code in Ping.cxx and menus.cxx I think |
| 21:16.34 | scanline | learner: thanks. I have a radar tracking you :) |
| 21:16.56 | captain_proton | scanline: care to look at my resize code to see why things are funky? |
| 21:17.21 | sussudio | someone's been committing, aye? |
| 21:17.35 | scanline | captain_proton: sure.. lemme just test this real quick |
| 21:17.42 | sussudio | 5 tar.gz's in 2 mins..... |
| 21:18.19 | scanline | whoa, I'm getting dizzy |
| 21:18.28 | sussudio | scanline: need a bucket? |
| 21:18.34 | JBDiGriz | captain_proton: so are we ready to summarize the header/length issues? |
| 21:18.58 | captain_proton | well - for header/length issues, all messages should have the same header |
| 21:19.07 | captain_proton | [length][msgid] - total 4 bytes |
| 21:19.14 | captain_proton | right now there are some that don't have it |
| 21:19.15 | JBDiGriz | fiberchunks: Getting this |
| 21:19.23 | captain_proton | like world objects |
| 21:19.53 | scanline | whoa... bzflag just killed my window manager |
| 21:19.55 | Chestal | what about those ping messages? |
| 21:20.00 | Chestal | also use the same format? |
| 21:20.08 | scanline | and my focus is stuck in xchat... |
| 21:20.11 | scanline | thank goodness for /exec |
| 21:20.59 | JBDiGriz | scanline: Do you have any estimate for doing a python bot to replace current bots? |
| 21:21.22 | scanline | no |
| 21:21.26 | captain_proton | -everything- should use them |
| 21:21.50 | fiberchunks | JBDiGriz> yessir -- but I need a sum up to decide what is, and is not - relevant |
| 21:22.02 | Chestal | the question is whether these messages can be handled by the normal infrastructure as well |
| 21:22.15 | captain_proton | i believe they can |
| 21:22.26 | fiberchunks | ah, sorry, yes JBDiGriz, I've got captain_proton's sum up aboe |
| 21:22.31 | Chestal | they are using a different transport |
| 21:23.12 | captain_proton | so the network core checks that in its select loop |
| 21:23.30 | Chestal | we might at least need to provide the callbacks with additional information coming from the transport layer then |
| 21:23.52 | Chestal | for example; in case of the server, the server might have to know that it has been a broadcast, not quite sure |
| 21:24.15 | captain_proton | the message structure it sends to the callback should have all the transport information that the callback might need (source address, etc) |
| 21:24.31 | Chestal | I still think this is the problem |
| 21:24.35 | Chestal | because we are mixing layers here |
| 21:24.51 | Chestal | server is doing demultiplexing for players based on ip+port |
| 21:25.06 | Chestal | callbacks don't want to handle that themselves, they want the player |
| 21:25.17 | captain_proton | most of that information is auxiliary |
| 21:25.19 | Chestal | but not all messages are coming from a player (pings are not) |
| 21:25.53 | fiberchunks | JBDiGriz> I will also parse the entire log when this is 'officially' over for things I may have missed |
| 21:26.18 | *** join/#bzflag creeperz (~creeperz@host-11-76-220-24.midco.net) |
| 21:26.58 | Chestal | maybe these details will resolve themselves once we look closer |
| 21:27.22 | captain_proton | the network layer will demultiplex when something comes in on a player socket, but doesn't attempt to if its on the broadcast socket, etc |
| 21:27.34 | JBDiGriz | it looks like we're at people's endurance levels around here. Are there any more discussions that need to occur before we close? |
| 21:27.52 | captain_proton | JBDiGriz: yeah...true |
| 21:27.54 | Chestal | lots more, but we can do those on another day |
| 21:28.14 | JBDiGriz | I think we have enough to get started. |
| 21:28.15 | learner | sounds like a wrap to me |
| 21:28.20 | Chestal | I guess we worked out the udp handshake and ping stuff to a level that we can try and implement it |
| 21:28.38 | learner | gd |
| 21:29.01 | JBDiGriz | Meeting over, thanks all, especially to fiberchunks who volunteered to summarize! |
| 21:29.01 | Chestal | the issue of interfacing the network code is more difficult |
| 21:29.23 | learner | heh, seems like it, cap |
| 21:29.26 | scanline | captain_proton: that wasn't the only problem.. I think it's something funky with the X server too |
| 21:29.40 | learner | it brings it down hard, scanline |
| 21:29.41 | scanline | captain_proton: after the odd crash, X was using 100% CPU |
| 21:29.42 | JBDiGriz | Chestal: We can decide if we need another meeting, or work it out while playing with the code. |
| 21:30.24 | captain_proton | strange |
| 21:32.59 | captain_proton | yay for efficient rendering engines written in python |
| 21:34.04 | *** topic/#bzflag by JBDiGriz -> http://BZFlag.org/ || http://list.BZFlag.org/ || http://stats.BZFlag.org/ || forums http://bzbb.bzflag.org || put javadoc-style /** comments */ in headers! || cvs snapshots: http://sfsnap.babylonia.flatirons.org/ || http://brlcad.org/bzflag/source |
| 21:34.29 | scanline | captain_proton: I'm going to refactor this attach() code into a utility module that provides init and main loop code for pygame, pygame+opengl, etc. |
| 21:34.41 | captain_proton | scanline: okees |
| 21:35.05 | JBDiGriz | If people would leave some indication of whether the meeting was useful, I will summarize. |
| 21:35.20 | JBDiGriz | Either here, or centrum email, or centrum forum. |
| 21:35.28 | learner | wait, scanline.. that crash was from python?? |
| 21:35.32 | Chestal | I think it was useful |
| 21:35.35 | scanline | learner: no |
| 21:35.43 | Chestal | but things take longer as one would assume (as always :-) |
| 21:35.50 | learner | bzflag client? |
| 21:35.56 | scanline | learner: I had bzflag proper open too, for testing |
| 21:35.59 | scanline | yes |
| 21:36.06 | scanline | and I was using -geometry, to get a really tiny window :) |
| 21:36.07 | learner | mkaey, that's what I thought |
| 21:36.29 | learner | and all options on, yes? |
| 21:36.55 | learner | gui options, that is |
| 21:37.12 | captain_proton | for some reason, -geometry is causing the window manager to perform a div0 |
| 21:37.12 | scanline | huh? |
| 21:37.25 | captain_proton | which is really weird, because i only moved it to bzdb, i didn't change any of the actual code |
| 21:37.51 | learner | ah, perhaps an unrelated bug, cap |
| 21:38.02 | learner | I'm thinking of the opengl-options related bug |
| 21:38.08 | learner | brings X down |
| 21:38.36 | learner | or in the case of os x, locks up with window server |
| 21:39.22 | learner | <PROTECTED> |
| 21:39.32 | learner | like every time |
| 21:39.48 | doughecjka | hmm, hotel internet connections are slow :) |
| 21:40.34 | captain_proton | learner: yes |
| 21:40.46 | captain_proton | i spent about a half hour trying to figure out why it was happening |
| 21:40.48 | captain_proton | no love |
| 21:41.09 | learner | I can't run -geometry or I'd check, but can you even get to the menu options? |
| 21:41.51 | captain_proton | oh - it runs fine for me, just my window manager pops up an error |
| 21:41.55 | captain_proton | scanline's window manager dies hard |
| 21:42.09 | captain_proton | (yay for lisp) |
| 21:42.21 | learner | right.. but can you get to the gui menu? :) |
| 21:42.32 | scanline | but the weird thing is that I use -geometry a lot, and this has only happened twice |
| 21:42.37 | learner | or is the error immediate |
| 21:42.43 | JBDiGriz | fiberchunks: looks good, although I'll probably change times to UTC for consistency |
| 21:43.06 | CIA | 03micahjd * 12pybzflag/BZFlag (4 files in 3 dirs): Fixed converting of team bases from text to binary, added some simple player-following code to radar |
| 21:43.09 | captain_proton | error is immediate on start up |
| 21:43.18 | learner | anyhow, something to try, scanline/cap is to disable blending and see if the error still occurs |
| 21:43.32 | learner | there is an obscure bug in there somewhere directly related to blending and lighting |
| 21:43.58 | learner | er, perhaps not "directly", but it is related |
| 21:44.19 | captain_proton | nope, same error |
| 21:44.27 | scanline | hmm.. anyone care to join xmission or brlcad.org so I can watch them poing around? :) |
| 21:44.33 | learner | mkay, good to know cap |
| 21:44.42 | captain_proton | the thing is that it only started getting this div0 error after i moved it to bzdb |
| 21:44.55 | learner | different problem, then, altogether |
| 21:45.04 | scanline | different problem, then |
| 21:45.15 | learner | I was just hoping the move suddenly provoked the bug better.. |
| 21:45.18 | scanline | aww.. |
| 21:45.23 | JBDiGriz | learner: Holy cow, I tried brlcad, and when I shot I held my flag! |
| 21:45.36 | learner | I know JB! me too |
| 21:45.42 | learner | someone fixed something |
| 21:46.07 | learner | and if I suicide, I don't lose being bunny! |
| 21:46.18 | learner | s/lose/stop/ |
| 21:46.29 | scanline | hm, nobody's on brlcad.org right now? |
| 21:46.37 | learner | which is good -- it would lose control of who's the bunny |
| 21:47.02 | learner | 10 sec, scanline |
| 21:47.14 | scanline | thanks |
| 21:48.21 | scanline | hmm, I'm not seeing anyone |
| 21:48.28 | scanline | did the protocol change while I was asleep? :P |
| 21:49.43 | learner | yes, we rewrote it in python |
| 21:50.24 | scanline | ah, got something |
| 21:51.11 | scanline | http://navi.picogui.org/~micah/tmp/radar_following.png |
| 21:53.24 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (RadarView.py): Fix stuff, mmkay |
| 21:55.14 | fiberchunks | JBDiGriz> my sum up is here: http://www.bzflag.org/wiki/WorkInProgress#preview << in section 1.8 |
| 21:56.02 | fiberchunks | will have to wait for tomorrow for log link to be useful -- but it's in there already |
| 21:56.52 | fiberchunks | captain_proton> can you add this link to the topic? 'Meeting notes link: http://www.bzflag.org/wiki/NetMeeting' |
| 21:57.22 | captain_proton | add it yourself |
| 21:57.37 | captain_proton | and the dates should be 1500 EDT - 1750 EDT |
| 21:57.58 | fiberchunks | ah yes |
| 21:58.09 | fiberchunks | captain_proton> how do I add to the topic? I know not how |
| 21:58.27 | captain_proton | what client? |
| 21:58.30 | fiberchunks | xchat |
| 21:58.38 | captain_proton | type into the topic box and press enter |
| 21:59.00 | *** topic/#bzflag by fiberchunks -> http://BZFlag.org/ || http://list.BZFlag.org/ || http://stats.BZFlag.org/ || forums http://bzbb.bzflag.org || put javadoc-style /** comments */ in headers! || cvs snapshots: http://sfsnap.babylonia.flatirons.org/ || http://brlcad.org/bzflag/source || Network Meeting Notes @ http://www.bzflag.org/wiki/NetMeeting |
| 21:59.11 | fiberchunks | heh, of course I didn't think it'd be that easy :) |
| 21:59.54 | fiberchunks | alrighty -- must do things for fireworks tonight -- see you all later |
| 22:00.05 | scanline | "capt_proton: dead reckoning before bots are feasible in C (different issue)" <-- what's that? |
| 22:00.32 | fiberchunks | something he mentioned at the beginning of the thing -- delete if not applicable |
| 22:02.28 | captain_proton | scanline: if we're exporting a library, we can't expect bot writers to really be able to do stuff before things like dead reckoning are done for them |
| 22:04.02 | scanline | ah |
| 22:04.10 | scanline | http://navi.picogui.org/~micah/tmp/radar2.png <-- ooh, cute :) |
| 22:05.06 | scanline | although it really needs something better than an axis-aligned square for the players |
| 22:05.49 | scanline | captain_proton: maybe I should go back to protocol/gamestate stuff and see if I can get a bot going in python while you hack on views? |
| 22:06.04 | scanline | a bot that drives around in circles at least would make testing views easier |
| 22:11.13 | learner | this is about a year old and has other flaws but .... |
| 22:11.18 | captain_proton | scanline: eh, ok |
| 22:11.23 | learner | nvr mind |
| 22:11.26 | captain_proton | event loop stuff would be nice, but isn't necessary at the moment |
| 22:11.34 | scanline | oh, right |
| 22:11.42 | scanline | I should do that first |
| 22:11.51 | captain_proton | would be nice if the event loop was in the main program rather than the view |
| 22:12.13 | scanline | well, I think it should be in neither |
| 22:13.27 | captain_proton | harumph |
| 22:13.31 | captain_proton | zbuffer artifacts in decks |
| 22:17.48 | captain_proton | jimmy |
| 22:17.59 | scanline | hooray |
| 22:23.00 | scanline | it can spin now? |
| 22:24.15 | *** join/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 22:24.33 | captain_proton | i added some code to the main loop that + 0.1 to camera.rotation |
| 22:24.39 | scanline | :) |
| 22:24.56 | captain_proton | and set the camera focus to a teleporter in decks |
| 22:24.58 | captain_proton | =) |
| 22:25.08 | captain_proton | and added zooming with the scroll wheel, so i can zoom in on it |
| 22:25.08 | scanline | where can I get a copy of decks? |
| 22:26.45 | captain_proton | jupiter.babylonia.flatirons.org/decks |
| 22:27.03 | scanline | thanks |
| 22:27.31 | scanline | hehe, looks cute in worldviewer |
| 22:28.07 | *** join/#bzflag MrApathyCream (dbrosius@balt-209-163-100-117.qis-dynamic-dialup.coretel.net) |
| 22:29.16 | scanline | hey, waitaminute |
| 22:29.27 | scanline | this world file has comments in it that weren't computer-generated |
| 22:29.30 | JBDiGriz | MrApathyCream: you missed the meeting. |
| 22:29.32 | scanline | oldskool |
| 22:29.38 | Chestal | hi MAC |
| 22:29.43 | captain_proton | scanline: right |
| 22:29.52 | captain_proton | decks was made while i was first writing bzedit |
| 22:29.58 | scanline | cool |
| 22:31.13 | scanline | http://navi.picogui.org/~micah/tmp/decks_radar.png |
| 22:32.31 | captain_proton | looks familiar |
| 22:36.19 | scanline | can't just define vertex and triangle lists somewhere? |
| 22:36.33 | captain_proton | eh, not really |
| 22:36.39 | captain_proton | unless you want the textures to look like crap |
| 22:36.44 | scanline | ah |
| 22:36.55 | captain_proton | notice how on the teleporter model all the textures line up =) |
| 22:37.01 | scanline | btw, I found a bunch of code with semicolons at the end last night :) |
| 22:39.37 | captain_proton | heh |
| 22:40.15 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/Protocol (WorldObjects.py): another side of the teleporter |
| 22:40.15 | CIA | 03davidtrowbridge * 12pybzflag/ (3 files in 3 dirs): bunch of neato stuff! |
| 22:40.15 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/Protocol (WorldObjects.py): yay, teleporters are done! |
| 22:42.06 | captain_proton | hm, cia lagging |
| 22:42.55 | captain_proton | scanline: does python have a vector implementation or should i just write my own cross product function? |
| 22:43.21 | scanline | captain_proton: python itself doesn't. Numeric does, but if all you need is a cross product it's not worth requiring Numeric |
| 22:44.42 | scanline | should probably go in a BZFlag.Vector module or something, since I'm sure we'll need more when it comes collision detection time |
| 22:45.30 | scanline | k |
| 22:45.31 | captain_proton | we can do a full vector when the time comes |
| 22:46.00 | scanline | yep.. and if we find some other compelling reason to use numeric we can do so |
| 22:51.06 | CIA | 03davidtrowbridge * 12pybzflag/data (pyrwall.png): add pyramid texture |
| 23:02.46 | captain_proton | http://jupiter.babylonia.flatirons.org/decks.png |
| 23:03.03 | scanline | =) |
| 23:03.21 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag/Protocol (WorldObjects.py): drawl the pyramids |
| 23:03.36 | scanline | spiffy. though I think it would look better if the grass texture was scaled smallerly |
| 23:05.23 | captain_proton | feel free to try to get that working ;) |
| 23:05.25 | captain_proton | err |
| 23:05.30 | captain_proton | s/working/looking better/ |
| 23:05.39 | scanline | after this Viewport Class of Doom |
| 23:11.26 | CIA | 03micahjd * 12pybzflag/BZFlag/UI (2 files): Make OverheadView the guinea pig for some Viewport tests |
| 23:12.23 | scanline | wow, the 3D view spins now |
| 23:12.24 | scanline | cool |
| 23:12.45 | captain_proton | try yer scroll wheel |
| 23:12.47 | captain_proton | =) |
| 23:12.53 | scanline | whee! |
| 23:13.08 | scanline | I Can't Believe It's Not BZFlag (tm) |
| 23:13.39 | scanline | hm. how does bzflag avoid those z-buffer artifacts? |
| 23:13.51 | *** join/#bzflag david_v (~david_v@c213-200-135-241.cm-upc.chello.se) |
| 23:15.35 | learner | scanline, better and worse event handling now :) |
| 23:15.50 | learner | it now will take focus, which it didn't before |
| 23:16.01 | learner | and it'll minimize, which it also did not |
| 23:16.08 | scanline | eh? |
| 23:16.14 | learner | yet it will not respond to a closewindow/quit event |
| 23:16.17 | scanline | oh.. talking about pybzflag... |
| 23:16.35 | scanline | yeah, once everything uses this Viewport class that will be fixed |
| 23:16.49 | scanline | and once it dispatches events properly |
| 23:16.54 | learner | it's still incredibly cpu hungry |
| 23:17.05 | scanline | well yeah, it's rendering continuously |
| 23:17.35 | learner | it shows up as cpu-bound, not i/o bound though |
| 23:17.46 | learner | more like it's in a tight loop polling for events |
| 23:17.56 | scanline | overheadview should eventually use dirty rectangles to keep CPU load down, the radar and 3D views will always be pretty hungry |
| 23:18.13 | learner | hrm |
| 23:18.19 | scanline | learner: it wouldn't show up as I/O bound if it was rendering continuously |
| 23:18.28 | scanline | overheadview is all software rendering |
| 23:19.03 | learner | eek |
| 23:19.22 | scanline | if you want opengl, try the radar view |
| 23:19.27 | learner | okay |
| 23:19.47 | captain_proton | or...the 3d view |
| 23:19.47 | captain_proton | =D |
| 23:19.55 | scanline | indeed! |
| 23:20.02 | scanline | the 3D view is looking good so far |
| 23:20.17 | learner | bash-2.05a$ /usr/local/bin/python ./worldviewer.py |
| 23:20.17 | learner | Traceback (most recent call last): |
| 23:20.17 | learner | <PROTECTED> |
| 23:20.17 | learner | <PROTECTED> |
| 23:20.18 | learner | IndexError: list index out of range |
| 23:20.34 | scanline | learner: there's no help yet, just read the few lines at the beginning of the file |
| 23:20.49 | scanline | it needs a world name on the command line |
| 23:21.22 | scanline | the world names can actually be pretty complicated, use a world name of 'help' to get an explanation |
| 23:22.47 | scanline | hmmm... |
| 23:22.49 | scanline | ./worldviewer.py random:randomHeights=1,boxHeight=100 random -u 3D |
| 23:22.54 | scanline | er |
| 23:23.07 | scanline | ./worldviewer.py random:randomHeights=1,boxHeight=100 -u 3D |
| 23:23.15 | scanline | skyscraper boxes :) |
| 23:30.10 | learner | heh.. scanline, I did a little checkbash-2.05a$ /usr/local/bin/python ./worldviewer.py random:randomHeights=1,boxHeight=100 -u 3D and it is polling repeatedly |
| 23:30.10 | learner | Traceback (most recent call last): |
| 23:30.11 | learner | <PROTECTED> |
| 23:30.11 | learner | <PROTECTED> |
| 23:30.11 | learner | <PROTECTED> |
| 23:30.12 | learner | <PROTECTED> |
| 23:30.14 | learner | <PROTECTED> |
| 23:30.16 | learner | <PROTECTED> |
| 23:30.18 | learner | AttributeError: 'module' object has no attribute 'attach' |
| 23:30.57 | learner | two statements intermixed on that first line, sry |
| 23:31.41 | scanline | of course it's polling repeatedly, it's rendering continuously... that's how almost all 3D games work |
| 23:32.01 | learner | I see I'm not getting anywhere with you.. :) |
| 23:32.16 | scanline | I don't understand what you want |
| 23:32.22 | learner | that's okay |
| 23:32.25 | learner | never mind |
| 23:32.40 | scanline | heh |
| 23:35.41 | captain_proton | eventually i plan to make the 3d renderer capable of either looping or being triggered |
| 23:35.47 | captain_proton | because an editor doesn't need to busy loop |
| 23:37.00 | learner | oh sure.. now you nod :) |
| 23:37.21 | scanline | learner: is that what you were talking about? |
| 23:39.30 | scanline | learner: I told you it was rendering continuously... you seemed to think it shouldn't be using up all your CPU if it was |
| 23:40.06 | scanline | that's where I got confused about what you were talking about |
| 23:40.10 | learner | no.. just that it "shouldn't" |
| 23:40.42 | scanline | right, you were saying that it shouldn't be rendering continuously, not that it shouldn't use up CPU if it was... |
| 23:40.56 | scanline | I understand now, at the time I didn't |
| 23:41.23 | learner | hehe, I think at least one of us has to remain confused, cap -- tag, you're it |
| 23:41.30 | scanline | hmm... this should eventually work kind of like picogui's opengl VBL :) |
| 23:44.41 | *** join/#bzflag bzgirl (~brat@toronto-hs-64-26-176-100.s-ip.magma.ca) |
| 23:44.51 | captain_proton | i think i'll need to add a second level of rendering passes |
| 23:45.09 | captain_proton | so it goes through and renders everything with the same texture per pass, but also goes through after and does anything that happens to be blended |
| 23:46.50 | scanline | ah, for teleporters? |
| 23:47.59 | captain_proton | yep |
| 23:48.01 | captain_proton | NameError: global name 'BZFlag' is not defined |
| 23:48.03 | captain_proton | heh? |
| 23:48.26 | scanline | heh? |
| 23:48.39 | captain_proton | ohh wait |
| 23:50.22 | captain_proton | how do i test to see if its flipZ in ObjectOptions? |
| 23:50.25 | *** join/#bzflag daBomb (dalskdjald@215-bem-10.acn.waw.pl) |
| 23:50.36 | scanline | if 'flipZ' in object.options: |
| 23:52.03 | captain_proton | return [BZFlag.Drawable.PyramidDrawable(self.center, self.angle, self.size, 'flipZ' in self.options)] <-- that just looks weird =) |
| 23:52.16 | CIA | 03davidtrowbridge * 12pybzflag/BZFlag (3 files in 3 dirs): metric boatload of changes |
| 23:52.17 | scanline | haha |
| 23:53.18 | captain_proton | hmm, i can probably get rid of 'Drawable' in the names there |
| 23:53.33 | scanline | yep |
| 23:54.54 | scanline | this new viewport stuff will make it much easier to stick multiple views in the same window |
| 23:55.11 | *** join/#bzflag learner (sean@chr160dhcp1675.chrchv01.md.comcast.net) |
| 23:57.12 | captain_proton | nifty |
| 23:59.14 | captain_proton | <PROTECTED> |
| 23:59.14 | captain_proton | <PROTECTED> |
| 23:59.26 | captain_proton | OpenGL.GL.GLerror: [Errno 1282] invalid operation |
| 23:59.31 | captain_proton | seems to be occurring with team bases :P |
| 23:59.56 | scanline | hmm.. zero height maybe? |
