| 00:17.28 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 00:19.26 | *** join/#bzflag me1 (n=ausom@bzflag/player/Me1) |
| 00:47.23 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 00:47.23 | *** mode/#bzflag [+v spldart] by ChanServ |
| 01:19.17 | *** join/#bzflag Ratfink (n=weechat@nc-67-76-227-5.sta.embarqhsd.net) |
| 01:19.41 | Ratfink | is it possible to have colored world weapons? |
| 01:24.35 | me1 | yes |
| 01:24.52 | me1 | Ratfink, add color 0-7 to the weapon, it changes the color, and team |
| 01:25.15 | *** join/#bzflag Ratfink1 (n=weechat@nc-67-76-227-5.sta.embarqhsd.net) |
| 01:25.33 | Ratfink | what do the numbers mean? |
| 01:25.33 | me1 | Ratfink, add color 0-7 to the weapon, it changes the color, and team |
| 01:25.41 | me1 | don't remember |
| 01:25.46 | Ratfink | okay, I'll try them all |
| 01:26.01 | me1 | 0- rouge, 1-red, 2-green etc., though i'm not sure which number is which |
| 01:27.05 | Ratfink | someone really needs to update the BZW manpage |
| 01:27.12 | Ratfink | I guess I could do that sometime |
| 01:27.27 | me1 | do you have the latest one from svn? |
| 01:27.42 | Ratfink | no, the one that came with BZFlag 2.0.12 |
| 01:27.48 | Ratfink | unless that's latest |
| 01:30.42 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 01:31.33 | *** join/#bzflag Ratfink1 (n=weechat@nc-67-76-227-5.sta.embarqhsd.net) |
| 01:37.03 | *** join/#bzflag Ratfink1 (n=weechat@nc-67-76-227-5.sta.embarqhsd.net) |
| 01:41.33 | *** join/#bzflag Ratfink1 (n=weechat@nc-67-76-227-5.sta.embarqhsd.net) |
| 02:18.03 | *** join/#bzflag Abominable (i=Abominab@user-0ce2hpi.cable.mindspring.com) |
| 02:35.23 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 04:05.43 | a_meteorite | I heard someone wants to remove C/C++ from the bzflag plugin api? |
| 04:05.59 | blast007 | we decided against it, at least for now |
| 04:06.43 | a_meteorite | good |
| 04:06.47 | a_meteorite | the removal would be a bad idea |
| 04:07.09 | blast007 | why? |
| 04:07.50 | a_meteorite | it would automatically disqualify a lot of C/C++ programmers for one |
| 04:08.00 | a_meteorite | I know I don't know lua and I don't know anyone beside the devs who do |
| 04:08.48 | a_meteorite | plus (afaik, as I said I don't know lua) you wouldn't be able to use any C/C++ libs.. you'd need lua substitutes, I would imagine in certain instances they don't exist |
| 04:08.54 | blast007 | yup, that was one of the main reasons |
| 04:09.33 | blast007 | lua can load external libraries though, but I imagine it's not the same as it would be for a regular C/C++ app |
| 04:09.51 | a_meteorite | hm, yeah |
| 04:10.53 | a_meteorite | are you not able to make lua a wrapper around the C api so that it's very easy to have features go into both at the same time (if it's not already done that way)? |
| 04:11.21 | blast007 | it already uses a lot of the bz_* functions |
| 04:11.25 | a_meteorite | ah |
| 04:13.01 | a_meteorite | it wouldn't make too much sense to strip the bz_* functions only to re-implement them in lua and then lose C/C++ plugin support to me |
| 04:13.31 | a_meteorite | *wouldn't make much sense to me |
| 04:14.12 | blast007 | the original reasoning was so that there wasn't two APIs to maintain |
| 04:14.26 | blast007 | we'll have both of them, for now |
| 04:14.35 | a_meteorite | that's good :) |
| 04:15.19 | a_meteorite | I imagine the benefits of going with one api probably wouldn't mitigate the loss of both developers and adaptability |
| 04:15.38 | blast007 | the great part about the Lua is that it will always be available in bzfs even if the C API wasn't enabled |
| 04:15.57 | a_meteorite | sounds interesting |
| 04:16.12 | a_meteorite | I should check into the lua for kicks |
| 04:16.15 | blast007 | the client-side stuff is the really neat stuff though :) |
| 04:16.24 | a_meteorite | indeed |
| 04:23.38 | TD-Linux | lua isn't terribly exciting as a language, which is what makes it so great |
| 04:23.49 | TD-Linux | pretty much anyone can pick it up, and it is easily customizable |
| 04:31.27 | *** join/#bzflag nightstrike_ (n=nightstr@mnit.ac.in) |
| 04:36.45 | blast007 | ah, guess extabsettings is in C# |
| 04:37.00 | blast007 | written in* |
| 05:13.57 | nightstrike_ | Hi all! I'm interested in working on modularizing the game logic (libgame) as part of GSoC 2009. I've been going through the code. If understood things right, most of the refactoring is needed in /src/bzflag? |
| 05:47.15 | *** join/#bzflag blast007_ (i=blast@bzflag/developer/Blast) |
| 05:47.21 | *** mode/#bzflag [+v blast007_] by ChanServ |
| 05:50.40 | *** join/#bzflag ThatCorgiDude (n=Pongo@67.207.136.75) |
| 06:02.51 | *** join/#bzflag Carnage00 (n=carnage@dyn216-8-149-95.ADSL.mnsi.net) |
| 06:16.15 | BulletCatcher | nightstrike_: My understanding about the game logic task is that we want to move common (or nearly so) code from bzadmin, bzflag, bzrobots, and bzfs into src/game. |
| 06:16.16 | BulletCatcher | The first 3 are clients and the last is the server, and there are quite a few things they do (e.g., track the location of a shot) that is conceptually the same but has independent implementation. |
| 06:17.11 | nightstrike_ | ok |
| 06:18.11 | nightstrike_ | I notice that version bzflag-2.0.12 does not have a src/bzrobots |
| 06:18.25 | BulletCatcher | Yes. It is new for 2.99.x. |
| 06:18.30 | nightstrike_ | but the version I checked out from SVN does... |
| 06:19.32 | nightstrike_ | ok, so if I'm going to be working on libgame, and I just take the game logic related code from bzadmin,bzflag etc and move them into /src/game, and I leave the OpenGL calls intact? |
| 06:19.45 | nightstrike_ | *working on libgame, I just.... |
| 06:20.12 | BulletCatcher | I think that's basically it. |
| 06:22.12 | BulletCatcher | The bzflag client displays to the user using OpenGL. bzadmin uses curses (just showing chat text and such). I don't think bzrobots displays anything. |
| 06:22.37 | BulletCatcher | But they still have to process relevant game updates from the server. |
| 06:23.18 | BulletCatcher | And if they can share the code to do that then it will simplify future development work as well as make them all work consistently. |
| 06:24.04 | nightstrike_ | hmmm... I see |
| 06:24.57 | CIA-11 | BZFlag: 03trepan * r19459 10/trunk/bzflag/src/other/lua/src/ (lua.h lundump.cxx): |
| 06:24.57 | CIA-11 | BZFlag: * disabled precompiled lua code |
| 06:24.57 | CIA-11 | BZFlag: (the dump/undump functions are not os/arch independent) |
| 06:30.47 | delusional | trepan, in the wings plugin, it appears that import has been disabled, there is no use trying to activate it, is there? |
| 06:31.14 | delusional | there would be too many un-implemented functions. |
| 06:31.58 | Flash | Wow. GSoC already? Where did this year go? |
| 06:40.12 | trepan | delusional: don't think i bothered, especially after having added the /saveworld '-o' feature |
| 06:40.28 | delusional | thats what i thought, thanks |
| 06:42.05 | trepan | on that note, i've tweaked modeltool to speed it up from 2 minutes to 2 seconds ;-) |
| 06:42.54 | trepan | (using std::map<> for the data remapping, amongst other tweaks) |
| 06:46.06 | delusional | gmm, we'll have to recompile and post on the forum. |
| 06:57.32 | *** join/#bzflag Carnage00 (n=carnage@dyn216-8-128-254.ADSL.mnsi.net) |
| 07:47.48 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 08:53.38 | *** join/#bzflag tupone (n=alfredo@gentoo/developer/tupone) |
| 08:53.38 | *** mode/#bzflag [+v tupone] by ChanServ |
| 08:57.57 | brlcad | ciao tupone! |
| 09:01.52 | tupone | hola brlcad |
| 09:13.57 | *** join/#bzflag sniper15_ (n=sniper15@S0106000d88e222e1.gv.shawcable.net) |
| 09:23.25 | *** join/#bzflag noyb_ (n=noyb@pool-71-108-67-113.lsanca.dsl-w.verizon.net) |
| 09:23.39 | noyb_ | how do I report cheaters again? |
| 09:23.49 | noyb_ | on badgerking, "who dat" |
| 09:24.16 | Constitution | good luck finding one who's awake |
| 09:24.21 | Constitution | a_meteorite maybe |
| 09:24.29 | a_meteorite | hi |
| 09:24.35 | a_meteorite | noyb_: be right there |
| 09:24.56 | noyb_ | thx |
| 09:28.37 | *** join/#bzflag s15 (n=sniper15@S0106002191dd19a8.gv.shawcable.net) |
| 09:29.28 | s15 | hates his WiFi |
| 10:08.23 | *** join/#bzflag gab32 (i=gabb@92.86.197.2) |
| 10:37.54 | noyb_ | people hate getting shot over and over and they get all mad. then when one gets a lucky flag pickup just in the nick of time... then it's all finger pointing and screaming, "cheater!" |
| 10:39.44 | noyb_ | so it irked me enuf to say so tonight. sorry. cya! |
| 11:38.43 | *** join/#bzflag TD-Linux (n=wheeeeee@96-42-68-26.dhcp.roch.mn.charter.com) |
| 12:03.46 | *** join/#bzflag temp_dist (n=temp_dis@bzflag/serverop/TemporalDistraction) |
| 12:21.53 | CIA-11 | BZFlag: 03trepan * r19460 10/trunk/bzflag/src/bzflag/ (RadarRenderer.cxx bzflag.cxx playing.cxx): |
| 12:21.53 | CIA-11 | BZFlag: * cleaned up 'bzflag -help' (reformatted, and removed -anonymous) |
| 12:21.53 | CIA-11 | BZFlag: * implemented absolute ranges for displayRadarRange (negative values) |
| 12:36.26 | *** join/#bzflag Upsetter (n=Ups@i577B47D4.versanet.de) |
| 12:54.25 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 13:00.26 | *** join/#bzflag tupone (n=alfredo@gentoo/developer/tupone) |
| 13:00.26 | *** mode/#bzflag [+v tupone] by ChanServ |
| 13:12.54 | *** join/#bzflag IneQuation (n=inequati@aaii251.neoplus.adsl.tpnet.pl) |
| 13:13.34 | IneQuation | hello everyone |
| 13:13.37 | IneQuation | is any of the devs around? |
| 13:14.01 | tupone | I was :) |
| 13:14.02 | IneQuation | I'd like to work for bzflag in gsoc2009 and have a couple of questions |
| 13:14.16 | tupone | brlcad: ping |
| 13:19.48 | IneQuation | ok, I guess I'll start with introducing myself, you guys can read that later |
| 13:20.31 | IneQuation | my name's Leszek, I'm from Poland, I'm in my final year of high school |
| 13:20.53 | IneQuation | going to university next year, hopefully studying computer science at the Silesian University of Technology (www.polsl.pl) |
| 13:21.15 | IneQuation | I'm a FLOSS enthusiast |
| 13:22.22 | IneQuation | done some volunteer work with a Polish free software promotion foundation (www.fwioo.pl) in a campaign to popularize FLOSS at schools |
| 13:23.58 | IneQuation | I'd love to work in game development after university, got some modding background |
| 13:24.24 | IneQuation | so combining these 2 loves of mine my natural choice on gsoc was a game :) |
| 13:24.37 | tupone | It is your first time in gsoc? Is the only org (bzflag ) you contacted? |
| 13:25.02 | IneQuation | yeah it's my first time, I haven't contacted anyone yet since I've been just looking at the organization profiles before |
| 13:25.16 | IneQuation | been thinking of applying to crystal space too, though |
| 13:25.52 | tupone | Have you got some ideas of what particular field you want to work on, I mean for bzflag? |
| 13:26.05 | IneQuation | yeah, one that's on your ideas list :) |
| 13:26.14 | IneQuation | the libgame separation |
| 13:26.34 | IneQuation | I've done lots of work with id software's technology (e.g. quake engines) |
| 13:26.52 | IneQuation | they implemented this kind of architecture in their games |
| 13:27.10 | IneQuation | so I think I have a good understanding of that and could pull it off |
| 13:27.46 | tupone | do you have some insight about bzflag architecture. |
| 13:27.47 | IneQuation | I have also used a similar architecture in my own game engine |
| 13:28.06 | IneQuation | not yet, I've just been skimming through the wiki and am compiling the sources right now |
| 13:28.17 | IneQuation | I know it's divided into bzflag and bzfs |
| 13:28.31 | IneQuation | it's mostly C++ |
| 13:29.21 | tupone | Well, I'm just asking to help you on writing :) Not interested in mentor this year |
| 13:29.24 | IneQuation | I plan to have a good read of it in the next few days |
| 13:30.02 | IneQuation | hehe thanks :) I'm not making an application yet, just trying to make a good impression (?) since that's what's written in the wiki :P |
| 13:30.11 | IneQuation | "get in the irc channel, talk to us" |
| 13:30.13 | IneQuation | so here I am |
| 13:30.30 | IneQuation | :) |
| 13:31.25 | tupone | How we can contact you? You should stick around freenode. crystalspace is on freenode too |
| 13:31.35 | IneQuation | ah, so the BZ in the name comes from battlezone, didn't know that |
| 13:31.47 | IneQuation | it was a cool game :) |
| 13:32.13 | tupone | you should play bzflag a little to understand what is |
| 13:32.24 | tupone | and die a little |
| 13:32.37 | IneQuation | well here's a little problem :S I won't really have the possibility to hang out on IRC for long till mid May |
| 13:32.43 | IneQuation | I certainly aim to do so ;) |
| 13:32.58 | IneQuation | I registered on the forums, not sure if the devs attend it |
| 13:34.35 | tupone | well, just to give hints, brlcad is the guy who drive this gsoc adv. (At least the past years). So he is the main contact, I guess |
| 13:35.02 | IneQuation | cool thanks |
| 13:35.24 | CIA-11 | BZFlag: 03trepan * r19461 10/trunk/bzflag/src/bzflag/CommandsStandard.cxx: * added "cycle <varname> <value1> [value2] [value3] ..." as a standard command |
| 13:37.57 | IneQuation | hmm I'm having problems compiling, for some reason lua isn't being compiled |
| 13:38.31 | trepan | ~pastebin |
| 13:38.32 | ibot | [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste |
| 13:38.47 | tupone | IneQuation: the link is for you |
| 13:38.49 | trepan | for error listings and the such ;-) |
| 13:39.34 | IneQuation | hehe |
| 13:40.07 | IneQuation | I know pastebin ;) besides I'm not going to post the error logs, I'll try to figure out what's going on first |
| 13:41.07 | trepan | 1. why bother noting the compilation problem if not to get assistance fixing it? |
| 13:41.11 | tupone | IneQuation just for you to know: trepan is the lua guy |
| 13:41.37 | trepan | 2. if you paste the error, i can probably have svn updated before i finish this coffee ;-) |
| 13:42.00 | IneQuation | yes you're right |
| 13:42.00 | trepan | (unless it's a windows problem, trepan doesn't do windows...) |
| 13:42.20 | IneQuation | I was just thinking it's a known issue or something |
| 13:42.25 | IneQuation | nah I'm on debian |
| 13:42.33 | trepan | could be a known issue -- what is it? :) |
| 13:42.39 | trepan | ditto on the deb |
| 13:42.40 | IneQuation | k here goes the log |
| 13:43.22 | IneQuation | http://www.pastebin.ca/1366172 |
| 13:43.42 | IneQuation | sorry for having the messages in Polish ;) |
| 13:44.36 | trepan | hehe, got the important part: "libtool: link: cannot find the library" |
| 13:44.46 | trepan | ... `../../../src/other/lua/liblua.la' |
| 13:45.15 | IneQuation | erm I've seen some other libraries being built in the process, I though lua would be built too |
| 13:45.19 | IneQuation | thought* |
| 13:45.28 | trepan | has 'src/other/lua/liblua.la' been generated? |
| 13:45.40 | brlcad | tupone: mentiras! |
| 13:45.44 | brlcad | y hola :) |
| 13:45.55 | IneQuation | well, no, that's exactly the problem, but there hasn't been an error message either |
| 13:46.01 | brlcad | thinks tupone wants to be a mentor this year |
| 13:46.08 | brlcad | hi IneQuation |
| 13:46.13 | IneQuation | hi brlcad |
| 13:46.22 | tupone | nah ... maybe openscenegraph porting? |
| 13:46.26 | *** join/#bzflag Ratfink (n=weechat@nc-67-76-227-5.sta.embarqhsd.net) |
| 13:46.40 | trepan | IneQuation: heh, found the problem |
| 13:46.57 | Ratfink | I'm making the _laserAdVel variable larger, but the laser stays the same length. |
| 13:47.00 | Ratfink | why could this be? |
| 13:47.01 | trepan | it's an ironic one (for me), "if BUILD_PLUGINS" in src/other/Makefile.am |
| 13:47.29 | IneQuation | trepan: I used --enable-shared |
| 13:47.43 | brlcad | tupone: I think the fix this year is going to be "cleanup" projects, refactoring, bug fixing, and not 'new' code so that we can stabilize .. and make it a lot easier for bigger tasks like engine integration |
| 13:48.13 | trepan | IneQuation: grep "result: BZFlag server" config.log |
| 13:48.17 | brlcad | a BUILD_PLUGINS conditional in src/other? that's .. odd |
| 13:48.27 | trepan | brlcad: yup, it's about to die |
| 13:48.58 | IneQuation | trepan: yes, in plugins |
| 13:49.11 | brlcad | IneQuation: what are you thinking of working on |
| 13:49.15 | tupone | brlcad: not having time for that either |
| 13:49.27 | IneQuation | trepan: s/in/with/g |
| 13:49.27 | brlcad | tupone: *cries* |
| 13:50.01 | brlcad | tupone: this whole fb thing is your fault and I don't see any updates from you :) |
| 13:50.28 | IneQuation | brlcad: I was hoping I could get to work on the modularization of game logic |
| 13:50.35 | brlcad | IneQuation: fantastic |
| 13:50.36 | tupone | fb? what is now fb |
| 13:50.45 | CIA-11 | BZFlag: 03trepan * r19462 10/trunk/bzflag/src/other/Makefile.am: * always build the src/other/lua library |
| 13:51.16 | IneQuation | brlcad: I've worked with such stuff before and I *think* I could handle it |
| 13:52.07 | IneQuation | I mean, with engines with such a modular design, like id software's technology |
| 13:52.19 | trepan | IneQuation: would you also be interested in restructuring the network/simulation architecture? (besides just moving code bits about ;-) |
| 13:52.56 | IneQuation | trepan: depends on what do you understand by restructurization... |
| 13:53.02 | trepan | ie: to change to an authoratitive server (currently, the server is little more than a relay) |
| 13:53.32 | trepan | player updates are sent with absolute positions, instead of desired velocities (a la quake) |
| 13:53.32 | IneQuation | well, I guess I could do that |
| 13:53.42 | IneQuation | yeah I see what you mean |
| 13:53.57 | trepan | so you might be looking into using quantized simulation steps, timewarp or tss state management, etc... |
| 13:54.10 | IneQuation | so bzflag is currently the fat client/thin server model? |
| 13:54.15 | trepan | yup |
| 13:54.19 | IneQuation | I see |
| 13:54.24 | brlcad | yeah, I'd pick off one of those, see how horrid it is to move it, then move it, etc |
| 13:54.34 | trepan | IneQuation: cheats galore :) |
| 13:54.39 | brlcad | IneQuation: it's a little worse than that too |
| 13:54.42 | brlcad | there are three clients |
| 13:54.42 | IneQuation | yeah, exactly |
| 13:55.02 | brlcad | one with nearly 90% code duplication with the main client |
| 13:55.16 | brlcad | the other with barely any code duplication but doing almost the same thing.. :) |
| 13:56.53 | IneQuation | you see guys, there's just one little problem I have... I have my "matura" exams (end-of-high-school exams, something like the A-levels, I guess; their results are the main factor in university recruitment processes) in the first half of May |
| 13:57.03 | *** join/#bzflag name3 (n=szkster@catv-89-132-128-184.catv.broadband.hu) |
| 13:57.28 | IneQuation | and I ought to be studying for them, so I don't get on the net much until they're over... |
| 13:57.42 | IneQuation | which means I can't really hang around on irc |
| 13:57.47 | IneQuation | for long, that is |
| 13:58.16 | brlcad | if you can just poke your head in from time to time, or even just stay idle, it'll help keep your nick in mind |
| 13:58.44 | brlcad | usually get about 50 apps, so showing you can be communicative even when you can be interactive would be good |
| 13:58.44 | IneQuation | after these exams are over, it's gonna be fine, with the longest holiday in the lifetime of a Pole in front of me ;) |
| 13:58.54 | brlcad | s/can/can't/ |
| 13:59.00 | brlcad | er |
| 13:59.10 | brlcad | sighs, too much coffee! |
| 13:59.18 | IneQuation | ok, I'll do my best then |
| 13:59.35 | brlcad | basically, most of us "hang out" on irc, even when we're not paying attention |
| 13:59.46 | brlcad | idle for hours or even days on end |
| 13:59.49 | *** join/#bzflag spldart (n=short_ci@bzflag/contributor/spldart) |
| 13:59.49 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:00.00 | brlcad | channel hilights if someone needs my attention and I can respond |
| 14:00.27 | brlcad | so even though i'm "not available" sometimes, I'm still 'available' if that makes sense? |
| 14:00.58 | brlcad | not saying you have to do that, but it'll help if you can at least poke in every few days leading up to the application deadline so we know who you are |
| 14:01.08 | brlcad | and can see how you interact with all the devs |
| 14:01.28 | IneQuation | of course it does ;) |
| 14:01.33 | brlcad | tactful communication skills are often more useful for this project than coding skills :) |
| 14:01.33 | IneQuation | ok |
| 14:01.49 | IneQuation | hehe like in every team effort |
| 14:01.56 | brlcad | as well as a somewhat thick skin ;) |
| 14:02.27 | brlcad | is huggable/lovable, but not a couple of the other guys :) you know who you are! hehe |
| 14:02.27 | IneQuation | too bad my shell host went down |
| 14:02.29 | spldart | w0rd |
| 14:02.48 | tupone | hugs brlcad |
| 14:02.53 | brlcad | hugs tupone |
| 14:03.17 | IneQuation | is embarassed |
| 14:03.22 | brlcad | IneQuation: if you hang around long enough, that can be arranged later on one of our hosts |
| 14:03.27 | brlcad | hugs IneQuation |
| 14:03.31 | IneQuation | lol |
| 14:03.59 | IneQuation | reluctantly hugs brlcad |
| 14:04.20 | trepan | is cantankerous, and values folks who get stuff done more than the well spoken :) |
| 14:04.43 | tupone | !spell cantankerous |
| 14:04.45 | trepan | (filling in part of brlcad's "you know who you are!" :) |
| 14:04.46 | sam | brlcad: howdy |
| 14:04.53 | brlcad | hehe |
| 14:04.56 | IneQuation | guess I'm off to reading the source |
| 14:04.58 | sam | brlcad: I feel like doing a minor FTGL release, what do you think? |
| 14:05.04 | brlcad | likes getting stuff done *and* being well spoken :) |
| 14:05.11 | brlcad | sam: concur |
| 14:05.17 | spldart | cake and eat it? |
| 14:05.17 | brlcad | there's a few changes that need to merge though |
| 14:05.29 | brlcad | trepan made a few mods to disable blending |
| 14:05.59 | sam | ok, I'll have a look |
| 14:06.06 | brlcad | sam: awesome |
| 14:06.21 | brlcad | there may be a few minor things too, it's been a little while since a sync |
| 14:06.34 | brlcad | but that's the only critical issue iirc |
| 14:08.30 | sam | it's been a while, too, I no longer work for the company that used FTGL |
| 14:08.37 | trepan | sam: fwiw, the c api changes for FTFont::ControlBlending() have not been tested |
| 14:08.50 | trepan | nor have any of the renderers save for FTTextureFont |
| 14:08.53 | sam | argh, the API changed? |
| 14:09.05 | trepan | FTFont::ControlBlending() was added |
| 14:09.24 | CIA-11 | BZFlag: 03brlcad * r19463 10/trunk/bzflag/autogen.sh: sync to the latest autogen.sh from upstream, provides better foreign file support and little more extensive backwards compat with old automake |
| 14:09.33 | sam | what does it do? |
| 14:09.47 | trepan | * Enable or disable the use of glBlendFunc inside FTGL |
| 14:10.02 | trepan | let's you setup your own blending modes |
| 14:10.04 | sam | I'm not fond of breaking the API and ABI when what we tried to do last year was stabilise it |
| 14:10.09 | trepan | s/let's/lets |
| 14:10.24 | CIA-11 | BZFlag: 03brlcad * r19464 10/trunk/bzflag/autogen.sh: oop, think we have a subdep in bz that requires 2.58? |
| 14:10.25 | trepan | backwards compatible, just an addition |
| 14:10.31 | brlcad | yeah, should be kosher |
| 14:10.38 | sam | that's not backwards compatible in C++ |
| 14:11.44 | trepan | true, for c++ ABI |
| 14:13.38 | brlcad | sam: hm, ideas on what to do about it then? I was only thinking in terms of it being an extension |
| 14:14.02 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-003-083.ewe-ip-backbone.de) |
| 14:14.07 | brlcad | (was just more concerned with api/header compat than abi compat myself) |
| 14:14.17 | sam | how about a flag to FTFont::Render? |
| 14:14.39 | brlcad | looks |
| 14:15.18 | brlcad | hm, that might do it |
| 14:15.37 | sam | f->Render("foo", FTGL::RENDER_BACK | FTGL::RENDER_NOBLEND); |
| 14:17.37 | trepan | works for me |
| 14:17.44 | sam | excellent :) |
| 14:18.00 | brlcad | yeah, sounds like a good call |
| 14:18.09 | brlcad | might have to accommodate RENDER_ALL |
| 14:18.22 | brlcad | think it's just a mask on the front/back/sides |
| 14:18.23 | sam | oops, right |
| 14:18.35 | *** join/#bzflag Wyk3d (n=middle@c7.campus.utcluj.ro) |
| 14:21.04 | brlcad | ah, cool |
| 14:21.05 | sam | or just use higher bits, I'd feel safer |
| 14:21.08 | trepan | i can change it over tomorrow, if we're all in agreement |
| 14:21.15 | brlcad | doesn't look like RENDER_ALL is actually used directly |
| 14:21.39 | brlcad | just the default setting, then elsewhere uses if (mode&RENDER_FRONT) .. |
| 14:21.54 | sam | but it may be used by the calling application |
| 14:22.04 | sam | or do you mean in bzflag? |
| 14:22.28 | *** join/#bzflag CBG (n=CBG@cpc2-newe2-0-0-cust921.cdif.cable.ntl.com) |
| 14:22.35 | brlcad | no, I mean in ftgl itself |
| 14:22.47 | brlcad | it's not exactly documented as being a bitmaskable value |
| 14:24.15 | brlcad | hm, but then we can't use mode&RENDER_NOBLEND either |
| 14:24.49 | sam | I don't think I understand |
| 14:25.04 | sam | if RENDER_NOBLEND is 0x10000, is there a problem? |
| 14:25.06 | brlcad | just thinking out loud, still a problem |
| 14:27.06 | brlcad | all the modes are default initialized to RENDER_ALL's 0xffff right now, so if we add an if (mode&RENDER_NOBLEND) into FTFont::Render(), then it'll get picked up unless they specify a mode or unless we specifically check (mode == RENDER_ALL) |
| 14:28.05 | brlcad | thinks RENDER_ALL's value should just be RENDER_FRONT&RENDER_BACK&RENDER_SIDE instead of 0xffff |
| 14:28.26 | brlcad | er, | |
| 14:28.32 | sam | RENDER_ALL is only half the bits |
| 14:28.33 | brlcad | heh |
| 14:28.42 | sam | so as I said, RENDER_NOBLEND can be 0x10000 |
| 14:28.46 | brlcad | oh!, i didn't see that extra 0 |
| 14:29.00 | brlcad | poifect |
| 14:31.00 | CIA-11 | BZFlag: 03brlcad * r19465 10/trunk/bzflag/src/other/ftgl/src/FTGL/ftgl.h: stub in a RENDER_NOBLEND, need to tie it to do what ControlBlending() presently does still |
| 14:37.23 | *** join/#bzflag nightstrike_ (n=nightstr@210.212.97.141) |
| 14:40.13 | *** join/#bzflag KTL (n=KTL@213.219.144.221.adsl.dyn.edpnet.net) |
| 14:47.56 | CIA-11 | BZFlag: 03trepan * r19466 10/trunk/bzflag/src/ (9 files in 3 dirs): * replaced FTFont::ControlBlending(bool) with the FTGL::RENDER_NOBLEND bit |
| 14:48.06 | brlcad | aww, basstage |
| 14:48.10 | brlcad | just hit commit! |
| 14:49.04 | trepan | you could still update FTFont.h to say what NOBLEND does :) |
| 14:49.30 | brlcad | interesting, you ripped out the whole rawBlending section? |
| 14:50.01 | brlcad | still can't believe he missed that commit by less than 10 seconds.. fail! |
| 14:52.26 | trepan | text shadows and inversion still work, so it looks like it's all good :) |
| 14:59.31 | CIA-11 | BZFlag: 03trepan * r19467 10/trunk/bzflag/src/3D/FontManager.cxx: * const where you can, precalc where you can |
| 15:02.14 | trepan | heh, text shadows strip out the ANSI reverse codes ... looks silly (well, worse than it should with that blending-mode reverse-text tech.) |
| 15:02.54 | CIA-11 | BZFlag: 03brlcad * r19468 10/trunk/bzflag/src/other/ftgl/src/FTGL/FTFont.h: epic fail on making the blending mod, so at least document the render modes |
| 15:07.46 | CIA-11 | BZFlag: 03trepan * r19469 10/trunk/bzflag/src/bzflag/CommandsStandard.cxx: * that der FIXME has been killed good |
| 15:07.59 | trepan | s/that/dat/ |
| 15:12.40 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 15:21.45 | *** join/#bzflag tj13820 (n=unknown@unaffiliated/tj13820) |
| 15:27.08 | *** part/#bzflag inchworm (n=msimmons@about/essy/GimmeGrubs/inchworm) |
| 15:27.38 | *** join/#bzflag MindstormsKid (n=chatzill@adsl-074-183-055-029.sip.cha.bellsouth.net) |
| 15:41.35 | *** join/#bzflag TimRiker (i=timr@2002:483e:4f2:0:0:0:0:1) |
| 15:41.35 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:46.05 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 15:47.18 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 15:47.45 | *** join/#bzflag Will07c5 (n=Will07c5@63.252.66.252) |
| 15:48.26 | *** join/#bzflag Carnage00 (n=carnage@dyn216-8-128-254.ADSL.mnsi.net) |
| 15:54.49 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 16:36.24 | *** join/#bzflag Carnage00 (n=carnage@dyn216-8-128-254.ADSL.mnsi.net) |
| 16:37.09 | CIA-11 | BZFlag: 03trepan * r19470 10/trunk/bzflag/src/other/lua/README_BZFLAG: * added a note about disabling precompiled chunks |
| 16:44.35 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 16:44.35 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 16:45.17 | CIA-11 | BZFlag: 03trepan * r19471 10/trunk/bzflag/src/other/lua/README_BZFLAG: * cleanup, listed more svn change revs. |
| 16:57.46 | *** join/#bzflag tj13820_ (n=unknown@unaffiliated/tj13820) |
| 17:40.11 | *** join/#bzflag Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 17:40.12 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 17:43.56 | *** join/#bzflag tj13820 (n=unknown@unaffiliated/tj13820) |
| 17:48.47 | blast007 | Erroneous: is lines 155 to 158 of BZAdminClient.cxx even necessary? http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzadmin/BZAdminClient.cxx?view=markup |
| 17:49.33 | blast007 | the change you made in r16943 made it skip processing certain messages when it still should have (such as MsgSetVars) |
| 17:50.18 | JefferyM | if the item isn't in the switch it'll just be skipped |
| 17:50.25 | blast007 | right |
| 17:50.25 | JefferyM | that seems suprurflus |
| 17:50.32 | blast007 | ok |
| 17:50.48 | JefferyM | the only thing I'm concerned about is the message mask part |
| 17:50.54 | JefferyM | is that a callback system or something? |
| 17:51.14 | blast007 | the messageMask just determines what stuff gets displayed |
| 17:51.28 | JefferyM | ahh |
| 17:51.30 | Erroneous | blast007: yeah, I think those are necessary |
| 17:51.34 | JefferyM | well you'd still want to process it |
| 17:51.36 | blast007 | Erroneous: why? |
| 17:51.38 | JefferyM | just not display it :) |
| 17:51.55 | blast007 | I have it set up to now display anything if the message mask says not to |
| 17:51.59 | blast007 | not* |
| 17:52.07 | JefferyM | good |
| 17:52.18 | JefferyM | then it can process all the messages even if it dosn't display them |
| 17:52.18 | blast007 | so how the CursesUI will work properly again |
| 17:52.20 | Erroneous | if the mask is set to false (i.e. you don't want to show, say, MsgSetVar) you still want to process it (set the variable) |
| 17:52.21 | JefferyM | that's as it should be |
| 17:52.40 | blast007 | Erroneous: right, but that's NOT what it's doing now |
| 17:52.55 | blast007 | the way it is, is is skipping the processing of MsgSetVars |
| 17:52.57 | JefferyM | Erroneous, he's got the message mask checking for display on a per message basis |
| 17:53.05 | JefferyM | yeah that's for the entire PROCESSING switch |
| 17:53.10 | JefferyM | it looks like |
| 17:53.14 | blast007 | yeah |
| 17:53.21 | JefferyM | does it work if you take it out ? |
| 17:53.31 | blast007 | let me check again, but I'm pretty sure |
| 17:53.52 | Erroneous | right, the code that's there now skips the switch unless it's A) turned on or B) a "critical" message |
| 17:54.24 | blast007 | MsgSetVars isn't critical? ;) |
| 17:54.33 | blast007 | kinda makes the F2 menu useless |
| 17:54.37 | Erroneous | it is, and it's on line 156 |
| 17:54.57 | Erroneous | if you have it turned off, it should still be processed |
| 17:55.06 | blast007 | right, but it wasn't in the mask because that isn't initialized |
| 17:55.16 | blast007 | only the ones that should be displayed are put in there at first |
| 17:55.28 | Erroneous | all the messages should be in the mask |
| 17:55.35 | blast007 | negative |
| 17:55.37 | Erroneous | only some should be turned on |
| 17:55.50 | blast007 | well, they should be, but they aren't |
| 17:56.52 | Erroneous | if you take that code out, you will need to check the mask inside each and every switch statement |
| 17:56.59 | blast007 | which I did |
| 17:57.05 | brlcad | woo hoo, subversion 1.6 is out |
| 17:57.06 | Erroneous | seems redundant to me |
| 17:57.07 | blast007 | for the act of displaying anything |
| 17:57.18 | Erroneous | since all most of them DO is display something |
| 17:57.27 | blast007 | hmm |
| 17:57.40 | Erroneous | I'd just make sure the mask is getting initialized properly |
| 17:57.45 | blast007 | k |
| 17:57.52 | JefferyM | seems odd to have 2 lists of messages |
| 17:58.08 | JefferyM | votes for display callbacks, then just call them genericly if the callback is in the mask :) |
| 17:58.25 | JefferyM | callback functors even, with display and process methods :) |
| 17:58.32 | JefferyM | then you can remove the switch |
| 17:59.58 | brlcad | votes for a big mess of gotos and setjmp/longjmp's |
| 18:00.20 | JefferyM | hook up the lua system |
| 18:00.30 | JefferyM | then process all the messages in individual lua scripts |
| 18:00.46 | Erroneous | heh |
| 18:00.58 | brlcad | neat 1.6 has the start of tree merging, tree conflict reporting |
| 18:01.31 | Erroneous | blast007: a more serious suggestion: you could split it into two switch statements, one to unconditionally process and the second to conditionally display |
| 18:01.50 | JefferyM | callbacks were serious :) |
| 18:01.56 | JefferyM | then you keep all the data together |
| 18:02.11 | Erroneous | JefferyM: might also be more work than he was looking to get into :) |
| 18:02.26 | blast007 | yeah ;) |
| 18:02.27 | JefferyM | I think it'll be about the same once you get into it :) |
| 18:02.36 | blast007 | I'd have to learn what functors actually are :P |
| 18:02.41 | brlcad | hehe |
| 18:02.57 | JefferyM | you'd make a base class, with 2 virtual methods |
| 18:03.05 | JefferyM | one for process and one for display |
| 18:03.05 | blast007 | think I might have it, but gonna test now |
| 18:03.39 | JefferyM | then you'd have a map of pointers to derived classes with your message type as the key |
| 18:03.48 | JefferyM | then you just find the object for the key, and call process on it |
| 18:03.51 | JefferyM | and display on it |
| 18:03.55 | JefferyM | then it handles it'self :) |
| 18:09.27 | nightstrike_ | hi guys, I've got a few more doubts. When you're talking about the game logic for libgame, are you talking about those aspects of the game like the shots and their positions or are you talking about to the client server interactions and stuff like that? |
| 18:09.47 | nightstrike_ | sorry if I'm being a little vague here! |
| 18:10.45 | CIA-11 | BZFlag: 03blast007 * r19472 10/trunk/bzflag/src/bzadmin/BZAdminClient.cxx: Initialize the message mask. |
| 18:10.55 | JefferyM | nightstrike_, the game logic, not the communications |
| 18:11.09 | nightstrike_ | ok, thanks |
| 18:14.05 | Wyk3d | brlcad: about yesterday's plugin crash, do you generally prefer a solution which solves the exact cause or one that makes the exact cause harder to find but fixes the problem and prevents similar mistakes from causing crashes in future ? |
| 18:15.59 | brlcad | how would a fix make the exact cause harder to find? |
| 18:16.36 | Wyk3d | well the api _allows_ everything to work if used correctly, but it's not |
| 18:17.09 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 18:17.33 | Wyk3d | you could make it work even if it's not used correctly |
| 18:17.33 | Wyk3d | but then you will not know what went wrong |
| 18:17.41 | brlcad | you're not making much sense to me |
| 18:18.36 | brlcad | sounds like you fed it bad input or did something wrong and it crashed, and now you're asking should you just make it good input or accommodate the bad input (by not crashing) |
| 18:19.00 | brlcad | crashing is always bad, I'd prevent the crash at least, then have it sanity check/report if it gets that condition again |
| 18:19.01 | Wyk3d | exactly |
| 18:19.15 | brlcad | then fix the dang inputs :) |
| 18:20.15 | JefferyM | we can't always protect against everything |
| 18:20.37 | JefferyM | you should also produce some kind of warning so plugin devs know they did somethign bad |
| 18:20.51 | JefferyM | or throw an exception :) |
| 18:21.11 | JefferyM | woudl the bad input lead to a fatal condtion? |
| 18:21.23 | JefferyM | or can you just reutrn an error state? |
| 18:21.34 | Wyk3d | in the case of this case it's fatal |
| 18:21.42 | Wyk3d | *of this crash |
| 18:21.44 | Wyk3d | you cannot detect it |
| 18:22.00 | JefferyM | there will always be things in the API that you can do that will crash |
| 18:22.04 | JefferyM | divide by 0 ;) |
| 18:22.07 | JefferyM | so just don't do that |
| 18:22.17 | Wyk3d | yeah but you can check if it's zero or not before dividing |
| 18:22.19 | JefferyM | and document it somewhere |
| 18:22.33 | JefferyM | bzfs can not check to make sure a plugin is dividing by 0 ;) |
| 18:22.34 | Wyk3d | but you cannot check a non NULL pointer if it's deallocated or not |
| 18:22.39 | JefferyM | yeah |
| 18:22.45 | JefferyM | there are just things we can't tell |
| 18:23.03 | JefferyM | you have to remove your events when you unload, that's just one of the rules |
| 18:23.13 | JefferyM | if there is a plugin that isn't then we should fix it |
| 18:23.24 | Wyk3d | yeah so if you don't .. should we allow the system to work i.e the event removes itself ? |
| 18:23.34 | JefferyM | how can we know |
| 18:23.38 | blast007 | and that's not even necessarily the cause of the crash either... I wasn't unload a plugin or shutting down the server yesterday |
| 18:23.41 | JefferyM | an event dosn't know what module it came from? |
| 18:23.54 | blast007 | I was just joining/leaving the game server |
| 18:24.06 | JefferyM | blast007, it could be that there is a bug in one of the plugins that auto deltes |
| 18:24.14 | JefferyM | even auto delters should remove there events |
| 18:24.22 | blast007 | I had a couple HTTP plugins running |
| 18:24.30 | Wyk3d | blast007: either way, the event handler was deleted without removing it from the worldeventmanager, this could be prevented by having the event remove itself in the destructor |
| 18:24.51 | JefferyM | yeah |
| 18:24.53 | blast007 | Wyk3d: right, but like I said, we don't know *why* it was doing that ;) |
| 18:25.02 | JefferyM | tho the event class dosn't know what events it was registered for |
| 18:25.09 | Wyk3d | blast007: which is why i wrote the whole philosophical question above :) |
| 18:25.11 | JefferyM | cus it can be more then one |
| 18:25.39 | Wyk3d | blast007: should we look for why it happened first or prevent it first and then have "someone" try to find the real cause later |
| 18:25.47 | JefferyM | you'd have to have a remove that just took a pointer, scanned all the the event lists and removed all the events that matched |
| 18:25.51 | JefferyM | hmmmmm |
| 18:26.06 | JefferyM | ponders |
| 18:26.40 | JefferyM | I'm not sure the event destructor is called on every OS on an uload tho |
| 18:26.52 | JefferyM | IIRC windows DLLs just get "detatched" |
| 18:27.09 | Wyk3d | JefferyM: it just has to know if it's registered or not, and then the worldeventmanager can just loop all events to find it and delete it |
| 18:27.19 | Wyk3d | assuming there is only one worldeventmanager ? |
| 18:27.23 | JefferyM | there i |
| 18:27.25 | JefferyM | is |
| 18:27.37 | JefferyM | but I'm thinking aobut it from the plugin side |
| 18:27.48 | JefferyM | I'm not a fan of auto delete |
| 18:28.02 | JefferyM | it was a nessisary evil tho |
| 18:28.31 | JefferyM | this would be so much easier if each plugin just registered a class |
| 18:28.36 | JefferyM | then handled it that way |
| 18:28.40 | JefferyM | instead of this C style stuff |
| 18:28.52 | JefferyM | then I'd know where each event came from |
| 18:28.55 | brlcad | Wyk3d: the crash can still usually be prevented -- that's just usually code that's assuming something without checking it |
| 18:29.12 | brlcad | if you can detect it, then have it bitch loudly |
| 18:29.24 | trepan | JefferyM: ironic, EventHandler.h does just that, but I was thinking of doing a C wrapper for dynamic libs ;-) |
| 18:29.34 | JefferyM | brlcad, the prolblem is that this one is hard to detect |
| 18:29.42 | JefferyM | trepan, hence my reasoning behind not having 2 APIs |
| 18:29.48 | JefferyM | we don't need 2 event systems |
| 18:29.53 | JefferyM | one that works is fine |
| 18:29.56 | JefferyM | and yours is better |
| 18:30.10 | trepan | EventHandler is client-side only |
| 18:30.20 | JefferyM | dosn't mean you couldn't move it to be server side too |
| 18:30.39 | JefferyM | no need to have duplicate systems |
| 18:31.10 | brlcad | JefferyM: I don't mean detect the logical condition -- is there something that prevents a code sanity check (like uninitialization detection, null dereference detection, bad iterator detect, bad container, etc)? |
| 18:31.31 | Wyk3d | JefferyM: as a way to find it easier, you could assert(false); if it's registered in the destructor |
| 18:31.48 | Wyk3d | then you get a stack trace which shows you where it was incorrectly deleted from |
| 18:31.53 | brlcad | e.g. if I remember the stack, it crashed on accessing an iterator for a bogus destructor |
| 18:31.56 | JefferyM | brlcad, no, that's the problem the sanity check is not easy |
| 18:34.04 | brlcad | Wyk3d: where in the code was this? |
| 18:34.20 | Wyk3d | there is no standard way of doing it, you can hack it by dynamic_casting but that will only work if it was overwritten after it was deleted i think |
| 18:34.45 | Wyk3d | http://pastebin.bzflag.bz/m2b24589e |
| 18:35.24 | *** join/#bzflag goreckm (i=Michal@user149-26.wireless.utoronto.ca) |
| 18:35.51 | Wyk3d | unless autodelete removes something from the list or there is memory corruption |
| 18:36.11 | Wyk3d | it has to be that the eventHandler got deleted and wasn't removed |
| 18:38.09 | JefferyM | yeah |
| 18:38.18 | JefferyM | I think the bug is in whatever plugin was unloaded |
| 18:38.35 | JefferyM | or autodelete does it in the wrong order or something |
| 18:38.59 | Wyk3d | autodelete is actually a bad name for a function that returns true or false without doing anything usually :) |
| 18:39.03 | JefferyM | too bad we don't have cross module smart pointers :) |
| 18:39.08 | JefferyM | yeah |
| 18:39.15 | JefferyM | like I said, I'm not a fan of it |
| 18:39.24 | JefferyM | I just needed some way to know if it was internal or not |
| 18:41.23 | Wyk3d | would help to name it something like canAutoDelete :) .. first time i read i though autodelete was an action that actually does the deleting / removing :) |
| 18:41.36 | Wyk3d | s/:)/whitespace |
| 18:41.51 | brlcad | autodeletable() |
| 18:41.58 | Wyk3d | or that |
| 18:42.06 | JefferyM | I don't like the term auto |
| 18:42.11 | JefferyM | isInternal() |
| 18:42.26 | JefferyM | that explains more about what it's saying |
| 18:42.35 | JefferyM | that it is IN BZFS not in an external module |
| 18:42.52 | JefferyM | and will basicly NEVER be unloaded |
| 18:46.14 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 18:46.14 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 18:46.20 | Wyk3d | ok so i'll try to write a patch for self remove / assert depending on the policy |
| 18:46.40 | JefferyM | no, just fix the bad plugin for now |
| 18:46.53 | JefferyM | if we are going to redo the event system I'd like to TOTALY redo it right |
| 18:47.27 | Wyk3d | eh .. that'll take a bit longer :D .. i haven't found the exact problem yet |
| 18:47.50 | JefferyM | if you haven't found the exact problem then you shouldn't go rewriting things to try to fix it |
| 18:47.53 | JefferyM | you may be wrong ;) |
| 18:48.12 | brlcad | yeah, that's quite true |
| 18:48.20 | JefferyM | I'm thinking we add more smarts to the event handler base class that handles removing events on destruction |
| 18:48.36 | JefferyM | then get all the plugins to create and delete tehre event classes on load and uload |
| 18:48.59 | JefferyM | then for the internal ones, we won't even need the autodelete flag, cus they will auto unregister on app destruction |
| 18:49.22 | JefferyM | I like that better since it's more "automatic" |
| 18:49.38 | JefferyM | can a plugin can unregister all events it reged just by deleteing it's event handler |
| 18:49.58 | brlcad | sounds smart |
| 18:50.01 | Wyk3d | well i don't think i'm wrong in stating that it is possible to misuse the the event handling calls to reproduce the crash .. but you're right that i cannot really prove that is what caused the crash, it's just the most probable cause.. so ok |
| 18:50.06 | brlcad | where is this "autodelete" function, I'm not finding it ? |
| 18:50.23 | JefferyM | it's a virtual memember on the event handler class |
| 18:50.28 | JefferyM | so it'll be in the API header |
| 18:50.39 | brlcad | I just searched the whole codebase |
| 18:50.43 | brlcad | is it auto_delete or something? |
| 18:50.50 | JefferyM | let me get a tree |
| 18:50.53 | JefferyM | is at work |
| 18:50.58 | brlcad | autoDelete maybe |
| 18:51.19 | JefferyM | probably |
| 18:51.25 | brlcad | yeah, there it is |
| 18:51.27 | brlcad | autoDelete |
| 18:51.29 | JefferyM | is it in the API header as part of the event handler baseclass |
| 18:51.45 | JefferyM | yeah I made that to know if the event was allocated inside bzfs or inside a plugin |
| 18:52.08 | JefferyM | so that bzfs could delete the internal ones on quit |
| 18:52.14 | JefferyM | but I don't like that method |
| 18:52.20 | JefferyM | I'll look at redoing it tonight |
| 18:52.33 | brlcad | Wyk3d: curious, put a break on WorldEventHandler::~WorldEventHandler -- see if it's called more than once |
| 18:53.13 | Wyk3d | doubt it, it's global, but will do |
| 18:53.27 | brlcad | just want to rule that out |
| 18:56.29 | JefferyM | pisses off his IT dept and gets a tree |
| 19:01.20 | Wyk3d | brlcad: nope, only once, though i didn't load any plugins |
| 19:04.20 | blast007 | JefferyM: well, figured out why the custom data doesn't work. It does get send to the client, but it gets sent before a MsgAddPlayer, so the player ID is invalid, and thus it gets ignored. |
| 19:04.38 | JefferyM | ahh |
| 19:04.43 | JefferyM | so just send it after :) |
| 19:04.56 | blast007 | yeah... |
| 19:06.03 | brlcad | Wyk3d: okay thanks |
| 19:07.31 | brlcad | so it is just a nastygram of having a pointer to an object put into the container and it crashing when trying to call it's method |
| 19:08.17 | brlcad | at least that or outright memory corruption |
| 19:08.26 | Wyk3d | shudders |
| 19:08.28 | blast007 | JefferyM: okay, now I'm confused... bzfs sends MsgAddPlayer first, but bzflag receives it after MsgPlayerData |
| 19:09.38 | JefferyM | they both sent TCP? |
| 19:10.22 | blast007 | how would I check? they send with ->broadcast |
| 19:10.46 | JefferyM | inside there should be a check that sets netForSpeed or soemthing |
| 19:10.52 | JefferyM | based on the message |
| 19:11.39 | blast007 | I see that in ServerLink.cxx in bzflag |
| 19:12.04 | blast007 | needForSpeed |
| 19:15.12 | JefferyM | hmmm, I can't find where we set the transfercallback |
| 19:16.10 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@bzflag/contributor/SpazzyMcGee) |
| 19:16.10 | JefferyM | there we go |
| 19:16.16 | JefferyM | it calls pwritebroadcast |
| 19:16.22 | JefferyM | and that calls pwrite for each person |
| 19:16.45 | JefferyM | hmm both should be TCP |
| 19:17.19 | JefferyM | NetHandler.cxx:443 is the list of UDP messags |
| 19:18.07 | blast007 | is our queue being processed in the right direction? |
| 19:18.37 | JefferyM | maybe not |
| 19:23.10 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 19:24.20 | *** join/#bzflag Pimpinella (n=frank@gondolin.pimpi.org) |
| 19:26.16 | CIA-11 | BZFlag: 03JeffM2501 * r19473 10/trunk/bzflag/plugins/HTTPServer/HTTPServer.sln: update to vc9 |
| 19:27.23 | CIA-11 | BZFlag: 03JeffM2501 * r19474 10/trunk/bzflag/ (4 files in 2 dirs): have the destructor for the event handler class, remove all events that use it's pointer. |
| 19:27.26 | *** join/#bzflag temp_work (n=temporal@bzflag/serverop/TemporalDistraction) |
| 19:27.38 | *** join/#bzflag me1 (n=ausom@bzflag/player/Me1) |
| 19:28.26 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 19:33.20 | goreckm | hi everyone. i'm a prospective GSoC applicant and have a few questions. Is there someone in particular I should talk to/email, or can I just post them here? |
| 19:34.22 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-003-083.ewe-ip-backbone.de) |
| 19:34.35 | JefferyM | here |
| 19:34.44 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-003-083.ewe-ip-backbone.de) |
| 19:38.13 | *** join/#bzflag goreckm (i=Michal@user149-26.wireless.utoronto.ca) |
| 19:40.10 | CIA-11 | BZFlag: 03JeffM2501 * r19475 10/trunk/bzflag/ (8 files in 2 dirs): remove autoDelete and just have everyone delete on destory |
| 19:43.47 | *** join/#bzflag bier (n=bier@p54A55391.dip.t-dialin.net) |
| 19:43.48 | brlcad | svn reverts all his changes |
| 19:44.13 | RatOmeter | goreckm: You're in luck, there are several devs listening right now, so ask away. |
| 19:44.18 | RatOmeter | is not one of those devs |
| 19:44.47 | JefferyM | heh |
| 19:44.52 | Erroneous | goreckm: here, or bzflag-dev@lists.sf.net |
| 19:44.57 | goreckm | ok, i guess my last question didn't get sent, irc got disconnected |
| 19:45.02 | JefferyM | you actualy read that Erroneous ? |
| 19:45.07 | Erroneous | JefferyM: yup |
| 19:45.09 | JefferyM | wow |
| 19:45.22 | JefferyM | brlcad, it wasn't that big of a change |
| 19:45.26 | goreckm | <PROTECTED> |
| 19:45.28 | Erroneous | I'm sure I'm not the only one |
| 19:45.41 | brlcad | JefferyM: hehe, yours weren't, but mine was :) |
| 19:45.50 | JefferyM | goreckm, prettymuch from scratch |
| 19:45.51 | brlcad | and they conflicted :) |
| 19:45.53 | Erroneous | goreckm: it exists, but doesn't do what we want it to yet |
| 19:45.56 | brlcad | no biggie |
| 19:46.00 | JefferyM | yeah it's very basic |
| 19:46.17 | JefferyM | brlcad, well I figured minium changes would be good you know.. release and all |
| 19:46.43 | Erroneous | heh |
| 19:47.25 | goreckm | ok, which folder is it in the source? (the current basic impl) |
| 19:47.26 | trepan | libgame seems to be the belle of the ball |
| 19:47.40 | JefferyM | it's always a popular one |
| 19:47.44 | goreckm | a lot of people asking about it? |
| 19:47.48 | JefferyM | yeah |
| 19:48.08 | Erroneous | src/game. could have found that out from DEVINFO too (highly recommended reading) |
| 19:48.10 | JefferyM | may I ask why you picked that one over the otehrs? |
| 19:49.41 | JefferyM | crap that last commit was bad |
| 19:49.44 | JefferyM | my compiler is not happy |
| 19:50.48 | trepan | waits for fixes before testing a contentious feature (stole 2 gameOptions bits for LuaWorld) |
| 19:51.17 | CIA-11 | BZFlag: 03JeffM2501 * r19476 10/trunk/bzflag/include/bzfsAPI.h: things must be defined before they are called because this isn't C# |
| 19:51.56 | blast007 | :) |
| 19:51.59 | brlcad | not highly recommended, goreckm -- if you're applying, DEVINFO is required reading, noted on the wiki |
| 19:52.14 | brlcad | there's a checklist of things you'll need to do as a student spelled out there |
| 19:52.47 | brlcad | yay, conflictless commit |
| 19:52.51 | CIA-11 | BZFlag: 03brlcad * r19478 10/trunk/bzflag/plugins/ (5 files in 5 dirs): kill off the rest of the autoDelete()'s too since they're no longer used. hit up style (auto) while in there where inconsistent. |
| 19:52.53 | CIA-11 | BZFlag: 03JeffM2501 * r19477 10/trunk/bzflag/src/bzfs/WorldEventManager.cxx: bad merge |
| 19:54.16 | *** join/#bzflag goreck (i=Michal@user149-26.wireless.utoronto.ca) |
| 19:54.47 | goreck | sorry guys, got disconnected, and haven't registered my nick on freenode |
| 19:56.22 | CIA-11 | BZFlag: 03JeffM2501 * r19479 10/trunk/bzflag/include/bzfsAPI.h: use a temp def for the event class, so that it compiles better ( really really isn't C#, but should be) |
| 19:56.31 | JefferyM | there, that should be better |
| 19:56.44 | JefferyM | goes to find out why incredebuild hates him |
| 19:58.27 | goreck | anyways, i was looking at possibly modularizing the opengl code too, but I don't have much openGL experience (most of mine is with DirectX) |
| 19:58.55 | JefferyM | then it sounds like it's a perfect time to learn :) |
| 19:58.59 | JefferyM | it's just code moving |
| 19:59.08 | JefferyM | IMHO moving the GL code is simpler then the game code |
| 19:59.19 | JefferyM | cus it's simpler to decide if code does drawing or not |
| 19:59.25 | JefferyM | rather then if it's "game" |
| 19:59.54 | CIA-11 | BZFlag: 03JeffM2501 * r19480 10/trunk/bzflag/MSVC/build/bzfs.sln: bzfs needs lua. |
| 20:00.08 | JefferyM | that should be it trepan |
| 20:00.29 | trepan | yup, going swimmingly |
| 20:00.40 | JefferyM | blast007, is the message que backwards? |
| 20:01.06 | brlcad | goreck: pick one or the other, not both |
| 20:01.21 | JefferyM | brlcad, actualy I'd rather him apply to both ;) |
| 20:01.22 | brlcad | just so you can focus and we can track your progress better |
| 20:01.31 | JefferyM | more applications == good in case of dupes |
| 20:01.50 | brlcad | it's not measurable progress if it's not well-scoped |
| 20:02.08 | brlcad | oh, I only mean in a given application |
| 20:02.15 | brlcad | don't care if he applies 20 times to us |
| 20:02.30 | JefferyM | ahh |
| 20:02.46 | Erroneous | actually, I'd prefer if they tried to keep it down to 4 or less |
| 20:02.51 | brlcad | the few that have said they're interested in doing X and Y thusfar implied there were going to propose it as one |
| 20:02.59 | brlcad | Erroneous: rejections are easy :) |
| 20:03.00 | JefferyM | oh |
| 20:03.03 | JefferyM | that's just stupid |
| 20:03.06 | Erroneous | better to have a few good applications than a bunch of hastily-thrown-together ones |
| 20:03.18 | JefferyM | once application per proposal, thems just the basic RULES |
| 20:03.22 | brlcad | didn't say I *preferred* 20 :) |
| 20:03.31 | brlcad | just don't care (that much) if he does |
| 20:03.32 | Erroneous | and if you have the time to put togther 20 GOOD applications, then I'd rather have some code :) |
| 20:04.22 | JefferyM | actualy if he has time to do that, I'd like to read them, cus I don't think tehre are 20 good ideas for bzflag, and they may be good new ideas :) |
| 20:04.27 | Erroneous | hehe |
| 20:04.29 | brlcad | JefferyM: it's our ideas to encapsulate them like that but it's still their proposal to pitch however they think it makes sense (even if it doesn't make sense) |
| 20:04.54 | JefferyM | I thought that google had the rule, one per proposal |
| 20:05.01 | brlcad | hence why just have to caution them to be sure to break it up |
| 20:05.08 | JefferyM | one per "thing that you will track" nothing with an "or" in it |
| 20:05.24 | brlcad | it is one, "my project is to do _insert_these_things_" |
| 20:05.45 | brlcad | nah, it can have multiple goals |
| 20:05.59 | JefferyM | but they are saying they will hit ALL the goals |
| 20:06.04 | brlcad | I'm going to fix these N bugs, refactor these M files, write them L libs |
| 20:06.04 | JefferyM | not this OR that goal |
| 20:06.28 | brlcad | eh, well yes |
| 20:06.32 | JefferyM | that seems to scaterbrained to me to seem like a good single project |
| 20:06.38 | brlcad | I was speaking about the AND case |
| 20:06.54 | JefferyM | for game and GL, that's too much for one project I think |
| 20:06.58 | JefferyM | in an AND |
| 20:06.59 | *** join/#bzflag Wyk3d (n=middle@c7.campus.utcluj.ro) |
| 20:07.08 | brlcad | completely agree |
| 20:07.10 | brlcad | that's my point |
| 20:07.15 | JefferyM | if you can finish one, then we can put you to work making that one thing BETTER :) |
| 20:07.15 | brlcad | several have thought it's doable |
| 20:07.25 | JefferyM | tell them they are full of crap and move on :) |
| 20:07.30 | brlcad | just have to tell them to pick one, scope it |
| 20:07.38 | goreck | it's too much for one, but if you have two people working on both, they are going to be related in many ways |
| 20:07.49 | JefferyM | goreck, probably |
| 20:07.58 | JefferyM | colaboration is fun :) |
| 20:08.22 | JefferyM | no mater what you are going to have multiple people working on it, since we arn't going to stop work while SoC happens |
| 20:08.52 | brlcad | and your changes can't break stuff, so it'll have to be very well tested in small incremental steps |
| 20:09.03 | brlcad | you should speak to that in your plan (and say more than what I just said) |
| 20:09.04 | goreck | that makes sense |
| 20:09.08 | JefferyM | no code dumps :) |
| 20:09.37 | goreck | how far away is your next major release. when i downloaded bzflag, sf said the last revision was 2007? |
| 20:09.49 | JefferyM | we don't really know |
| 20:09.55 | JefferyM | we'd like to release "soon" |
| 20:10.18 | brlcad | if a sniper plucked you off tomorrow, your project/code has to be in a 'done' state so you'll have to move things very piecewise |
| 20:10.42 | brlcad | goreck: that was our last major release |
| 20:10.48 | brlcad | there have been a few patch releases since |
| 20:11.10 | brlcad | hence the focus this year on cleaning up and stabilizing |
| 20:11.52 | brlcad | plan for some discussion time to talk about how your refactoring might impact that goal too |
| 20:12.32 | brlcad | and specific testing time and bug fixes (possibly introduced by your refactoring, possibly previously there) |
| 20:12.33 | goreck | as a funny note, i have to ask, what's with naming your c++ files as .cxx. i've never seen that before |
| 20:12.47 | JefferyM | it's just what the author choose |
| 20:13.04 | JefferyM | and we've just stuck with that convention |
| 20:13.16 | brlcad | one of many common conventions, see enough code over the decades and you'll find plenty of other projects using various extensions |
| 20:13.58 | brlcad | although, I'd say .cxx is probably the second most common extension after .cpp? dunno, just a feel and probably biased |
| 20:14.21 | JefferyM | brlcad, arn't those the only 2 extensions used? ;) |
| 20:14.54 | JefferyM | tho I've seen "hpp" and that kinda bugs me |
| 20:15.00 | JefferyM | and "hxx" |
| 20:15.02 | trepan | guesses someone at some point wrote hello.c++ |
| 20:15.10 | JefferyM | probaby |
| 20:15.11 | brlcad | I've seen .CC .C++ .c++ .cc .C .CPP .cp |
| 20:15.32 | JefferyM | well .C won't work on windows, so that can't be a big one |
| 20:15.48 | JefferyM | prefers cpp |
| 20:15.51 | brlcad | yeah, all the upper ones sort of died out after the 80's |
| 20:16.18 | brlcad | doesn't care so long as they're all the same |
| 20:16.29 | brlcad | (and so long as the compiler doesn't care, heh) |
| 20:16.44 | JefferyM | yet if I say "BSD style", I think you'd care ;) |
| 20:17.04 | brlcad | that affects productivity, so yup :) |
| 20:17.15 | brlcad | extension doesn't |
| 20:19.09 | brlcad | contrary to familiarity/popularity, I actually think .cxx makes more 'sense' that .cpp just because of the c pre-processor has that name (cpp), less ambiguous |
| 20:19.34 | brlcad | or c++ ftw if some platform wasn't so limited about its names |
| 20:20.32 | JefferyM | just make em all cs files |
| 20:20.42 | brlcad | heh |
| 20:20.58 | brlcad | thinks JefferyM has been drinking too much of the koolaid |
| 20:21.14 | JefferyM | no, antibiotics |
| 20:21.38 | JefferyM | tho I am still not sure C# makes distrobution any simpler |
| 20:21.44 | JefferyM | but I indend to find out |
| 20:21.46 | Winny | did they let you keep the teeth? ;) |
| 20:21.57 | JefferyM | didn't ask |
| 20:22.00 | Winny | ah |
| 20:22.09 | trepan | JefferyM: for lack of mono? |
| 20:22.30 | JefferyM | trepan, mostly for getting third party assemblys to work |
| 20:22.35 | JefferyM | so far mono has been the simplest part |
| 20:22.55 | JefferyM | getting axiom to work on linux is not fun |
| 20:23.19 | JefferyM | I'd probably have a simpler time if I just used Tao and did my own drawing |
| 20:23.38 | JefferyM | getting lidgren to work on linux was cake too |
| 20:24.49 | JefferyM | I may go for raw tao if I can find out if they have an FTGL implementation |
| 20:25.07 | goreck | hey guys, thanks for your answers. i'll be back after i've done a bit more research, compiled the code, etc. just a quick last one, is NeHe still the best place to get a quick crash course in OGL? |
| 20:25.19 | JefferyM | it's a good start |
| 20:29.27 | Wyk3d | so if something is stated as a high priority idea then a medium application for it beats a really good application for a lower priority idea ? |
| 20:32.29 | Winny | say, if I give you my fake ID can I do SoC? |
| 20:32.55 | JefferyM | Wyk3d, I think this year it's going to be mostly based on if we think the person will finish it and do well :) |
| 20:37.40 | Wyk3d | Winny: not really .. |
| 20:37.51 | Winny | aw |
| 20:39.16 | Wyk3d | JefferyM: hmm ok, i was wondering if i should continue BZAuthd or if that's not important enough, cheat prevention sounds awesome for example |
| 20:39.52 | JefferyM | up to you |
| 20:40.14 | JefferyM | perosnaly I'd really like to see BZAuthd finished and implemented live |
| 20:40.17 | JefferyM | that'd be a huge thing |
| 20:40.45 | JefferyM | cheat prevention is going to be a long process and isn't as simple as it sounds. |
| 20:41.14 | JefferyM | it has more to do with authoritive server states and networking then just making chagnes to prevent cehats |
| 20:41.39 | Wyk3d | i know .. |
| 20:41.59 | JefferyM | take god mode for example, to do that right, you need to implement server side tracking of shots and players that is very accurate |
| 20:42.12 | JefferyM | that in itself was a SoC Project |
| 20:42.49 | JefferyM | it's changes also have a larger impact on a possible release |
| 20:43.04 | JefferyM | where auth isn't nessisarly tied to any one release |
| 20:43.24 | JefferyM | since all we'd have to do is provide an HTTP interface to it and BAM old clients work ;) |
| 20:43.52 | Wyk3d | right |
| 20:44.04 | JefferyM | you are more then welcome to propose both |
| 20:44.34 | JefferyM | but I just feel that the cheat stuff has more hooks into our core and will turn out to be a much harder project then we intended |
| 20:44.49 | JefferyM | and I'd really like to see some SOC projects finished and made live |
| 20:45.16 | JefferyM | so far the only live one we have is King Of Camelot's from last year |
| 20:50.36 | Erroneous | bzwgen and bzrobots are both essentially live afaik |
| 20:51.50 | CIA-11 | BZFlag: 03trepan * r19481 10/trunk/bzflag/src/other/ftgl/src/FTGL/FTFont.h: * commented the second Render() method, ws |
| 20:52.14 | Wyk3d | JefferyM: ok thanks .. i'll take a closer look at both and see which one i can do best |
| 20:52.34 | CIA-11 | BZFlag: 03trepan * r19482 10/trunk/bzflag/include/global.h: * added LuaWorldAvailable and LuaWorldRequired gameOptions bits |
| 20:52.56 | L4m3r | may be free this summer as well |
| 20:53.45 | CIA-11 | BZFlag: 03trepan * r19483 10/trunk/bzflag/src/other/lua/README_BZFLAG: * noted __usedindex and __rawset metamethod additions |
| 20:54.59 | CIA-11 | BZFlag: 03trepan * r19484 10/trunk/bzflag/include/BZDBCache.h: * added the BZDB_int, BZDB_bool, BZDB_float, and BZDB_string caching classes |
| 20:55.07 | L4m3r | apparently upper management has decided that it's not entirely ethical to hire students in the summer as they furlough career staff |
| 20:56.11 | *** join/#bzflag awilcox (n=awilcox@awos/maintainer/awilcox) |
| 20:56.51 | CIA-11 | BZFlag: 03trepan * r19485 10/trunk/bzflag/src/bzfs/lua/LuaServer.cxx: * setup the LuaServer lua 'package.path' and 'package.cpath' variables |
| 20:58.28 | CIA-11 | BZFlag: 03trepan * r19486 10/trunk/bzflag/ (9 files in 4 dirs): |
| 20:58.28 | CIA-11 | BZFlag: * added the 'S' indicator for server script |
| 20:58.28 | CIA-11 | BZFlag: dark - no script |
| 20:58.28 | CIA-11 | BZFlag: green - script available and optional |
| 20:58.28 | CIA-11 | BZFlag: red - script available and required |
| 20:58.29 | CIA-11 | BZFlag: (should put something in the info box at the bottom too) |
| 21:00.52 | *** join/#bzflag noyb_ (n=noyb@nat/sun/x-d44e02f26befaef6) |
| 21:04.56 | CIA-11 | BZFlag: 03trepan * r19487 10/trunk/bzflag/src/bzflag/HUDuiServerInfo.cxx: * added the "Script: <none|optional|required>" field |
| 21:15.37 | brlcad | fyi, I'm considering dropping the German server until after release -- feeling is that we're not close to utilizing it (and to try would be a distraction from making the release happen sooner) |
| 21:15.49 | blast007 | JefferyM: sorry, I got sidetracked re: the queue. (getting a vista system set up to build too) Still need to do some further debugging. |
| 21:16.03 | JefferyM | blast007, did you get your motherboard back? |
| 21:16.04 | brlcad | if there's anyone using it now, please do let me know |
| 21:16.08 | blast007 | nope |
| 21:16.11 | JefferyM | :( |
| 21:16.22 | blast007 | using my other laptop |
| 21:16.38 | blast007 | (which is one that had the lack of sound in-game) |
| 21:16.43 | JefferyM | brlcad, DTRemenak and myself have our servers too if something comes up in the meantime |
| 21:17.07 | JefferyM | server, not servers :) |
| 21:17.15 | JefferyM | now with 2 gigiabytes of ram :) |
| 21:17.29 | blast007 | hehe.. that's more than my vista laptop has :P |
| 21:17.37 | brlcad | JefferyM: that was my thoughts as well |
| 21:17.45 | JefferyM | Erroneous keeps using it all :) |
| 21:17.51 | brlcad | even IF we started doing something distributed, there are your resources that can be used |
| 21:17.56 | JefferyM | yeah |
| 21:18.09 | JefferyM | pffff, there is also Erroneous's house, boy has 18 megs down :) |
| 21:18.24 | brlcad | the point where it'd go live to give low-latency to europe, it could be started back up in a matter of about 2 days |
| 21:18.44 | brlcad | so just no point to keep it lingering |
| 21:19.43 | CIA-11 | BZFlag: 03trepan * r19488 10/trunk/bzflag/src/ (4 files in 3 dirs): * replaced the '_forceLuaWorld' BZDB variable with the LuaWorldRequired gameOptions bit |
| 21:19.55 | brlcad | was hoping someone would step up and take the initiative to do something useful with it, but that's not happened and doesn't look likely contrary to chatter throughout the year to the otherwise, so just think it's time to kill it until someone is more seriously working it |
| 21:22.21 | JefferyM | step up?... bzflag... same sentance?..... |
| 21:22.52 | awilcox | *sentence. and I've seen it happen before. just not often. |
| 21:24.17 | Wyk3d | http://paste2.org/p/168245 |
| 21:24.44 | JefferyM | so fix it :) |
| 21:25.55 | Wyk3d | k just wanted to ask if it's know :) |
| 21:26.01 | Wyk3d | *a known bug |
| 21:26.01 | JefferyM | dosn't matter |
| 21:26.05 | JefferyM | still needs to be fixed |
| 21:26.08 | JefferyM | so fix it :) |
| 21:27.48 | CIA-11 | BZFlag: 03trepan * r19489 10/trunk/bzflag/src/lua/LuaClientScripts.cxx: * added a message when '/luaworld disable' is attempted and LuaWorld is required |
| 21:39.44 | *** join/#bzflag arcstech (n=arcstech@206.251.250.215) |
| 21:47.24 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 21:47.25 | *** mode/#bzflag [+v spldart] by ChanServ |
| 21:49.44 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 22:08.17 | JefferyM | blast007, can you make trepan a bzbb admin |
| 22:08.24 | JefferyM | he needs to make some fourms for luaness |
| 22:08.29 | JefferyM | and I can't figure out how to do it |
| 22:09.35 | JefferyM | nm, I may have found it |
| 22:14.36 | *** join/#bzflag KTL (n=KTL@213.219.144.221.adsl.dyn.edpnet.net) |
| 22:24.31 | joevano | brlcad: submitted my request to mentor into the GSoC Melange site (or however you spell it) :P |
| 22:31.37 | *** join/#bzflag Not_Gabe1G23 (n=gabe@s66-76-118-56.eldocmta01.eldoar.lr.sta.suddenlink.net) |
| 22:33.34 | *** join/#bzflag TD-Linux (n=wheeeeee@96-42-68-26.dhcp.roch.mn.charter.com) |
| 22:35.56 | *** join/#bzflag temp_dist (n=temp_dis@bzflag/serverop/TemporalDistraction) |
| 22:45.03 | blast007 | JefferyM: did you get it? |
| 22:45.08 | JefferyM | yeah |
| 22:45.10 | JefferyM | it's a group now |
| 22:45.12 | JefferyM | :) |
| 22:45.13 | blast007 | k |
| 22:57.56 | *** join/#bzflag PrezKennedy (i=Matthew@whitecalf.net) |
| 23:00.01 | spldart | O:\DVD\Star Trek Insurection\RipIt4Me.psl |
| 23:00.32 | blast007 | Error, file not found. Enter root password: |
| 23:01.32 | spldart | 69pAsSwOrD69 |
| 23:01.37 | blast007 | ;) |
| 23:02.33 | spldart | Don't even know how that happened. Xchat was minimized at that moment. |
| 23:03.09 | awilcox | hah. |
| 23:03.17 | awilcox | I've done that too. |
| 23:03.30 | awilcox | so how're you tonight? |
| 23:04.04 | spldart | Who me??? Lementing over a paycheck that is always ever so small ;) |
| 23:06.37 | spldart | Oh wow.. and looky there... My proggie through up a warning box that the .psl was not imported succesfully. LOLz |
| 23:15.17 | *** join/#bzflag tj13820_ (n=unknown@unaffiliated/tj13820) |
| 23:22.36 | *** join/#bzflag Not_Gabe_G23 (n=gabe@s66-76-118-56.eldocmta01.eldoar.lr.sta.suddenlink.net) |
| 23:45.07 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 23:45.07 | *** mode/#bzflag [+v spldart] by ChanServ |