| 00:03.04 | *** join/#bzflag Constitution (n=const@unaffiliated/macsforme) |
| 00:20.41 | *** join/#bzflag Spartan (n=47baa12c@bz.bzflag.bz) |
| 00:20.46 | Spartan | hmm |
| 00:21.00 | JeffM | ? |
| 00:21.45 | Constitution | now *that* was profound |
| 00:22.06 | Lukstr | "I wonder what this button does..." |
| 01:18.35 | *** join/#bzflag whodaman (n=whodaman@pdpc/supporter/student/whodaman-) |
| 01:29.55 | *** join/#bzflag lol_u (n=4c5d8bae@bz.bzflag.bz) |
| 01:30.03 | lol_u | Hi people I need help someone hacked my map |
| 01:30.12 | lol_u | is there a way to reset the /set? |
| 01:30.29 | lol_u | reset to default? |
| 01:30.38 | lol_u | please really need your help |
| 01:32.01 | lol_u | hELLO? |
| 01:32.06 | lol_u | is anyone there? |
| 01:32.46 | Suspect | If I knew how I'd help you |
| 01:33.06 | lol_u | so there is no way I can reset the /set |
| 01:33.09 | lol_u | ? |
| 01:33.17 | Suspect | I'm sure there is a way but I don't know how |
| 01:33.28 | Thumper_ | try /reset _varName |
| 01:33.32 | lol_u | ok |
| 01:34.02 | Thumper_ | /diff should also show you want has been modified |
| 01:34.33 | lol_u | it says does not exsist |
| 01:34.57 | Thumper_ | well use the right variable name (see the output of /set) |
| 01:35.01 | *** join/#bzflag FusionDude (n=jwmelto@unaffiliated/flash) |
| 01:35.27 | Thumper_ | but it's possible to get the server confused so you can't fix it without a restart |
| 01:35.54 | lol_u | i dont get what you mean by variable name...really confusing |
| 01:36.20 | Thumper_ | e.g. /reset _wingsJumpCount |
| 01:36.32 | Thumper_ | will reset the _wingsJumpCount variable to the default |
| 01:36.36 | lol_u | OH |
| 01:36.38 | lol_u | ok |
| 01:38.37 | lol_u | ok thanks guys. |
| 01:38.40 | lol_u | bye |
| 01:38.41 | *** join/#bzflag JeffM (n=JeffM@adsl-76-243-140-190.dsl.lsan03.sbcglobal.net) |
| 01:39.14 | *** join/#bzflag BenUrban (n=benurban@unaffiliated/benurban) |
| 01:40.48 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-239-111.pools.arcor-ip.net) |
| 01:48.00 | *** join/#bzflag Joss (n=josiah@203-173-228-137.dsl.dyn.ihug.co.nz) |
| 02:13.43 | blast007 | Thumper_: typically a /reset * will fix more severe problems |
| 02:14.24 | *** join/#bzflag eTangenT (i=etangent@inge069019.halls.colostate.edu) |
| 02:50.21 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 03:07.38 | *** join/#bzflag Quol (n=ian@modemcable199.71-57-74.mc.videotron.ca) |
| 03:15.56 | *** join/#bzflag JeffM (n=JeffM@pool-71-109-218-124.lsanca.dsl-w.verizon.net) |
| 03:24.55 | *** join/#bzflag Flash (n=jwmelto@unaffiliated/flash) |
| 03:38.29 | Flash | catay: why is a SIGPIPE an issue? it's what is supposed to happen when one end of a connected socket is closed and you try to write to it |
| 03:43.07 | *** join/#bzflag Flash (n=jwmelto@unaffiliated/flash) |
| 03:45.05 | CIA-32 | FTGL: 03brlcad * r1006 10/trunk/: don't ignore COPYING now that there is one |
| 03:52.20 | CIA-32 | FTGL: 03brlcad * r1007 10/trunk/AUTHORS: add a utf-8 coding line for emacs, attribute full name with e-mail |
| 04:17.15 | CIA-32 | FTGL: 03brlcad * r1008 10/trunk/mac/FTGL.pbproj/: remove the obsolete 10.3 project builder project for mac, it's now pretty far out of date and is without maintainer |
| 04:56.57 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 05:49.25 | *** join/#bzflag Lukstr (n=Lukstr@CPE0080c6efd3fb-CM00195efb656e.cpe.net.cable.rogers.com) |
| 06:46.01 | *** join/#bzflag Gilly (n=btw@83.146.211.140) |
| 06:49.37 | *** join/#bzflag jftsang (n=jftsang@88-108-143-164.dynamic.dsl.as9105.com) |
| 07:18.02 | *** join/#bzflag brad (n=brad@89.149.224.44) [NETSPLIT VICTIM] |
| 07:18.02 | *** join/#bzflag retro (n=ksumrall@wall.danger.com) [NETSPLIT VICTIM] |
| 07:20.54 | CIA-32 | FTGL: 03sammy * r1009 10/trunk/src/ (3 files in 3 dirs): * Fix a small memory leak in the C bindings destructors. |
| 07:21.21 | CIA-32 | FTGL: 03sammy * r1010 10/trunk/src/FTGL/FTPoint.h: |
| 07:21.21 | CIA-32 | FTGL: * Fix brown-paper-bag bug in the vector product computation: the indices |
| 07:21.21 | CIA-32 | FTGL: were completely messed up. Thanks to valgrind for spotting it for me. |
| 07:21.44 | CIA-32 | FTGL: 03sammy * r1011 10/trunk/test/ (7 files): |
| 07:21.44 | CIA-32 | FTGL: * Fix memory leaks in the font tests due to temporary variables not being |
| 07:21.44 | CIA-32 | FTGL: deleted. |
| 07:21.44 | CIA-32 | FTGL: * Add a few method calls to the C test program. |
| 07:21.59 | CIA-32 | FTGL: 03sammy * r1012 10/trunk/src/FTGlyph/FTExtrudeGlyph.cpp: |
| 07:21.59 | CIA-32 | FTGL: * Fix a memory leak in ~FTExtrudeGlyph: only one of the three display lists |
| 07:21.59 | CIA-32 | FTGL: was being freed. |
| 07:37.04 | *** join/#bzflag noyb (n=noyb@pool-71-119-173-104.lsanca.dsl-w.verizon.net) |
| 07:44.48 | *** join/#bzflag think_tank (n=think_ta@unaffiliated/thinktank/x-168245) |
| 07:57.49 | *** join/#bzflag Erroneous (i=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 07:57.49 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 07:59.06 | *** join/#bzflag DTRemenak (i=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 07:59.06 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 08:58.07 | *** join/#bzflag Upsetter (n=Ups@i577B728D.versanet.de) |
| 09:14.45 | CIA-32 | FTGL: 03sammy * r1013 10/trunk/src/FTGL/ftgl.h: |
| 09:14.45 | CIA-32 | FTGL: * Add RENDER_ALL to the enum used in Font::Render() so that client |
| 09:14.45 | CIA-32 | FTGL: applications need not worry about future extensions. |
| 09:16.20 | CIA-32 | FTGL: 03sammy * r1014 10/trunk/ (9 files in 3 dirs): |
| 09:16.20 | CIA-32 | FTGL: * Change a few function names in the FTFont C bindings to avoid confusion |
| 09:16.20 | CIA-32 | FTGL: with other classes. |
| 09:16.20 | CIA-32 | FTGL: * Document the C bindings. Since it's almost copypasta from the C++ |
| 09:16.20 | CIA-32 | FTGL: documentation, I put the constructors back in their original files. |
| 09:16.46 | CIA-32 | BZFlag: 03t-s * r17103 10/trunk/bzflag/BUGS: builds fail in ares |
| 09:17.01 | CIA-32 | FTGL: 03sammy * r1015 10/trunk/docs/doxygen.cfg.in: |
| 09:17.01 | CIA-32 | FTGL: * Activate macro expansion in Doxygen to hide useless macros such as |
| 09:17.01 | CIA-32 | FTGL: FTGL_EXPORT in the documentation. |
| 09:17.47 | CIA-32 | FTGL: 03sammy * r1016 10/trunk/ftgl.pc.in: (log message trimmed) |
| 09:17.47 | CIA-32 | FTGL: * Fixes and enhancements to ftgl.pc: |
| 09:17.47 | CIA-32 | FTGL: + Add -I${includedir}/FTGL to Cflags because we want to support legacy |
| 09:17.47 | CIA-32 | FTGL: application that still #include <FTGLBitmapFont.h>. |
| 09:17.48 | CIA-32 | FTGL: + Remove @GL_CFLAGS@ from Cflags because our public headers do not use |
| 09:17.50 | CIA-32 | FTGL: GL headers. |
| 09:17.52 | CIA-32 | FTGL: + Add freetype2 to Requires.private since it ships its own .pc file. Not |
| 09:24.09 | *** join/#bzflag Dessy (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 09:58.32 | CIA-32 | FTGL: 03sammy * r1017 10/trunk/docs/ (FTGL.html Makefile.am doxygen.cfg.in ftgl.dox): |
| 09:58.32 | CIA-32 | FTGL: * Converted the HTML documentation to Doxygen so that everything ends up |
| 09:58.32 | CIA-32 | FTGL: in the same document. Plus, Doxygen's C++ pretty-printer is very nice for |
| 09:58.33 | CIA-32 | FTGL: code examples. |
| 10:00.28 | *** join/#bzflag ViciousM (n=max@cpe-024-211-248-161.nc.res.rr.com) |
| 10:13.40 | *** join/#bzflag Suspect (n=Suspect@68-113-163-117.dhcp.plt.ny.charter.com) |
| 10:36.06 | *** join/#bzflag Wyk3d (i=Wyk3d@cl-86-125-183-131.cablelink.mures.rdsnet.ro) |
| 11:08.00 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-084-035.pools.arcor-ip.net) |
| 12:03.18 | whodaman | lol |
| 12:33.06 | Thumper_ | blast007: yeah I forgot about that... thx |
| 12:35.15 | *** join/#bzflag hamburger (n=4c1f24d8@bz.bzflag.bz) |
| 12:40.47 | *** join/#bzflag bz64 (n=d5bec369@bz.bzflag.bz) |
| 12:40.48 | *** join/#bzflag Upsette1 (n=Ups@i577B4D6E.versanet.de) |
| 12:41.08 | bz64 | HAHA |
| 12:41.31 | whodaman | . |
| 12:41.35 | spldart | .. |
| 12:41.35 | whodaman | Can we help you? |
| 12:41.38 | whodaman | ... |
| 12:43.24 | CIA-32 | FTGL: 03sammy * r1018 10/trunk/src/FTGlyph/FTGlyphGlue.cpp: * Fix a potential memory leak in the FTGlyph C bindings error handler. |
| 12:43.52 | spldart | _ _ _ _ . _ ..__.. |
| 12:44.01 | CIA-32 | FTGL: 03sammy * r1019 10/trunk/src/ (12 files in 3 dirs): * Document the C bindings for FTGlyph. |
| 12:45.23 | CIA-32 | FTGL: 03sammy * r1020 10/trunk/ (5 files in 3 dirs): * Use a smaller logo on the User Guide's front page. |
| 13:10.26 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-084-035.pools.arcor-ip.net) |
| 13:15.05 | *** join/#bzflag Upsetter (n=Ups@i577B7830.versanet.de) |
| 13:17.51 | CIA-32 | FTGL: 03sammy * r1021 10/trunk/ (.gitignore configure.ac docs/Makefile.am docs/doxygen.cfg.in): * Generate PDF documentation if a proper LaTeX installation can be found. |
| 13:18.20 | CIA-32 | FTGL: 03sammy * r1022 10/trunk/src/ (3 files in 2 dirs): * Started documenting the FTLayout C bindings. |
| 13:28.14 | CIA-32 | FTGL: 03sammy * r1023 10/trunk/src/FTLayout/FTLayoutGlue.cpp: |
| 13:28.14 | CIA-32 | FTGL: * Add an implicit cast to FTGL::TextAlignment in the FTLayout::SetAlignment |
| 13:28.14 | CIA-32 | FTGL: C wrapper. |
| 13:28.56 | CIA-32 | FTGL: 03sammy * r1024 10/trunk/docs/Makefile.am: * Fix inconsistencies in the documentation install paths. |
| 13:29.45 | sam | I feel alone today. |
| 13:32.18 | *** join/#bzflag chammiya (n=chamms@ip-208-109-254-83.ip.secureserver.net) |
| 13:35.18 | Thumper_ | sam: you're not alone (except for maybe in making commits...) |
| 13:36.14 | sam | I was referring to commits, yeah :) |
| 13:36.25 | whodaman | [11:16] <CIA-32> BZFlag: t-s * r17103 /trunk/bzflag/BUGS: builds fail in ares |
| 13:36.26 | whodaman | \ |
| 13:36.29 | whodaman | You're not! :p |
| 13:46.18 | brlcad | hehe |
| 13:51.04 | *** join/#bzflag spldart (n=short_ci@adsl-70-240-186-13.dsl.hstntx.swbell.net) |
| 13:51.04 | *** mode/#bzflag [+v spldart] by ChanServ |
| 13:56.00 | CIA-32 | BZFlag: 03brlcad * r17104 10/trunk/bzflag/src/other/ares/ (ares_process.c configure.ac): try a little harder for TCP_NODELAY even though we shouldn't have to. be sure types.h is included, check for xti.h, and failing those, just set it ourselves |
| 13:58.58 | CIA-32 | BZFlag: 03brlcad * r17105 10/trunk/bzflag/BUGS: build failures are NOT bugs. if you're the one with the failure then fix it, don't just document it. |
| 14:01.26 | CIA-32 | BZFlag: 03brlcad * r17106 10/trunk/bzflag/BUGS: remove all of the listed build system "issues" .. they are not bugs. they could possibly go into the TODO file if someone intends to work on them, but otherwise it is misleading to list them as bugs. |
| 14:03.13 | CIA-32 | BZFlag: 03brlcad * r17107 10/trunk/bzflag/BUGS: appearing in front of bad bugs isn't a bug, it can happen. it 'should' not happen, but it can -- especially with the random spawn policy, but even with the default policy. |
| 14:09.02 | CIA-32 | BZFlag: 03brlcad * r17108 10/trunk/bzflag/BUGS: works for me. can toggle fullscreen to windowed without a problem (on os x). |
| 14:10.29 | *** join/#bzflag hobbsc (n=hobbsc@ip70-178-55-100.ks.ks.cox.net) |
| 14:22.34 | CIA-32 | BZFlag: 03brlcad * r17109 10/trunk/bzflag/BUGS: |
| 14:22.34 | CIA-32 | BZFlag: include a preamble that explains the purpose of this file. it's basically just |
| 14:22.34 | CIA-32 | BZFlag: developer notes on known bug issues. user-reported bugs or bugs that require |
| 14:22.34 | CIA-32 | BZFlag: in-depth tracking/discussion should go to the sourceforge bug tracker. this |
| 14:22.34 | CIA-32 | BZFlag: isn't a change in use, but should hopefully make the intent clear for everyone |
| 14:22.36 | CIA-32 | BZFlag: that reads the file as to what it's for. quick dev scratchpad. |
| 14:33.46 | CIA-32 | BZFlag: 03brlcad * r17110 10/trunk/bzflag/BUGS: |
| 14:33.46 | CIA-32 | BZFlag: reformat the bugs file to use asterisks instead of bullets so that you can tell |
| 14:33.46 | CIA-32 | BZFlag: what's actually changing more easily in a commit diff. consistently format the |
| 14:33.46 | CIA-32 | BZFlag: file to column 80 and add a local var footer to help keep it consistent. |
| 14:34.35 | CIA-32 | BZFlag: 03brlcad * r17111 10/trunk/bzflag/NEWS: local var footer |
| 14:35.31 | CIA-32 | BZFlag: 03brlcad * r17112 10/trunk/bzflag/BUGS: utf-8 |
| 14:41.03 | *** join/#bzflag Upsette1 (n=Ups@i577B7335.versanet.de) |
| 14:45.41 | CIA-32 | BZFlag: 03brlcad * r17113 10/trunk/bzflag/NEWS: more detail about formatting in footer |
| 14:52.10 | catay | Flash: ok. I was not sure about it. |
| 14:52.13 | whodaman | ~brlcad++ |
| 14:53.06 | CIA-32 | FTGL: 03sammy * r1025 10/trunk/src/FTLayout/ (FTLayout.cpp FTLayoutImpl.h): |
| 14:53.06 | CIA-32 | FTGL: * Add a virtual destructor to FTLayoutImpl to make sure derived classes |
| 14:53.06 | CIA-32 | FTGL: have their destructors called. |
| 14:53.07 | CIA-32 | FTGL: * Make all FTLayoutImpl members protected. Only its derived classes and |
| 14:53.07 | CIA-32 | FTGL: FTLayout need to access them. |
| 14:53.44 | catay | Flash: i will commit it later today |
| 14:55.04 | *** join/#bzflag TimRiker (n=timr@70-7-116-48.area7.spcsdns.net) |
| 14:55.04 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:07.31 | *** join/#bzflag Upsetter (n=Ups@i59F7C98A.versanet.de) |
| 15:49.41 | *** join/#bzflag noyb (n=noyb@pool-71-119-173-104.lsanca.dsl-w.verizon.net) |
| 15:51.22 | *** join/#bzflag AAA_awright____ (n=AAA_awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 15:55.34 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 16:01.26 | *** join/#bzflag noyb_ (n=noyb@nat/sun/x-ad8fbb0f00c0e83d) |
| 16:12.21 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 16:13.22 | CIA-32 | BZFlag: 03catay * r17114 10/branches/v2_0branch/bzflag/src/bzfs/bzfs.cxx: |
| 16:13.22 | CIA-32 | BZFlag: Accepted patch 1954900 from Bullet Catcher |
| 16:13.22 | CIA-32 | BZFlag: * Add missing newlines to some log messages. |
| 16:13.22 | CIA-32 | BZFlag: * Corrected kick explanation on flag transfer |
| 16:40.36 | sam | brlcad: C#/.NET bindings for FTGL are starting to work |
| 16:40.46 | sam | here's our first C# program: http://zoy.org/~sam/ftgl-scrolltext.png |
| 16:44.37 | *** join/#bzflag Erroneous (n=dtremena@about/essy/CrazyCoder/DTRemenak) |
| 16:44.37 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 17:20.47 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-010-001.ewe-ip-backbone.de) |
| 17:21.29 | *** join/#bzflag TimRiker (n=timr@pdpc/supporter/bronze/TimRiker) |
| 17:21.29 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 17:28.34 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-010-001.ewe-ip-backbone.de) |
| 17:38.42 | *** join/#bzflag rtfm (n=rtfm@pdpc/supporter/active/blast007) |
| 17:38.42 | *** mode/#bzflag [+v rtfm] by ChanServ |
| 17:39.08 | *** join/#bzflag kirun (n=kirun@10.126.gr5.adsl.brightview.com) |
| 17:50.33 | Flash | Does anyone know if there is a reason why the bzfsAPI uses a different net handler management than bzfs.cxx? |
| 17:52.07 | Flash | or more importantly, is there any bad thing that would happen by combining them? |
| 17:52.29 | donny_baker | Flash: other than the world ending? ;) |
| 17:52.46 | Flash | which world? I already found "delete world" |
| 17:56.50 | Erroneous | Flash: the API has some specific requirements for what it can and can't do |
| 17:56.59 | Erroneous | for instance, you can't pass STL containers across the API |
| 17:57.22 | JeffM | flash, also the API is abstracted in case we change the backend |
| 17:57.29 | JeffM | what did you want to combine? |
| 17:57.38 | Erroneous | also, the API one should not change, even if we change the main implementation |
| 17:57.53 | Erroneous | but JeffM just said that :) |
| 17:58.02 | Erroneous | seems to type too slow |
| 17:58.06 | Flash | I see APISocketListener looks like it has lots in common with the connection management code in bzfs |
| 17:58.30 | JeffM | Flash, yes becase right now it's nearly a 1 to 1 maping |
| 17:58.31 | Flash | I was looking for the places where NetHandler are allocated and deleted and found those 2 places |
| 17:58.50 | *** join/#bzflag brad (n=brad@89.149.224.44) |
| 17:58.58 | JeffM | you can't send a net handler to a plugin |
| 17:59.00 | JeffM | that would be bad |
| 17:59.21 | Flash | <PROTECTED> |
| 17:59.50 | Flash | but that's not actually being sent to the plugin, is it? |
| 18:00.04 | JeffM | no that's calling the callbacks that may be installed |
| 18:00.06 | Flash | that's where the plugin ties into the game |
| 18:00.13 | JeffM | they should just get the connection ID |
| 18:00.35 | JeffM | the idea is the net handler is the conenction |
| 18:00.52 | JeffM | and there may be any number of things that accept that connection |
| 18:00.56 | JeffM | the game ( for players ) |
| 18:01.04 | JeffM | the API, for non client connections |
| 18:01.10 | JeffM | or something else later |
| 18:01.29 | JeffM | but the API dosn't have access to the net handler class |
| 18:01.32 | JeffM | not should it |
| 18:01.42 | JeffM | since it only needs a subset of methods in it |
| 18:01.59 | JeffM | bzfs manages them, but just gets the input/output from the API |
| 18:06.46 | JeffM | Flash, now if you wanted you could merge the API socket listener into the base net handler, but I don't think it buys anything |
| 18:07.01 | JeffM | and it kinda makes it harder to follow, it's nice to have the API stuff all in the API file |
| 18:07.40 | JeffM | cus basicly you'd just be giving the netHandler a generic callback system for those events. |
| 18:20.06 | CIA-32 | BZFlag: 03catay * r17115 10/trunk/bzflag/src/bzflag/ServerLink.cxx: |
| 18:20.06 | CIA-32 | BZFlag: Accepted patch 1948438 from Flash |
| 18:20.06 | CIA-32 | BZFlag: When the client quits (e.g., F12) the termination message may not be |
| 18:20.07 | CIA-32 | BZFlag: received by the server. This patch adds a flush() to the code that sends |
| 18:20.07 | CIA-32 | BZFlag: that message to make sure the message is sent before returning. |
| 18:25.06 | *** mode/#bzflag [+o blast007] by ChanServ |
| 18:25.41 | *** mode/#bzflag [+b *!*=4d00*@*] by blast007 |
| 18:25.48 | *** mode/#bzflag [-o blast007] by blast007 |
| 18:35.26 | *** join/#bzflag Suspect (n=Suspect@68-113-163-117.dhcp.plt.ny.charter.com) |
| 18:38.01 | *** join/#bzflag AAA_awright_____ (n=AAA_awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 18:44.09 | *** join/#bzflag bier (n=bier@p54A56F20.dip.t-dialin.net) |
| 18:47.22 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@unaffiliated/spazzymcgee) |
| 18:49.48 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 19:15.53 | *** join/#bzflag jftsan1 (n=jftsang@88-108-171-83.dynamic.dsl.as9105.com) |
| 19:17.42 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 19:26.49 | *** join/#bzflag bier (n=bier@p54A57165.dip.t-dialin.net) |
| 19:38.30 | *** part/#bzflag jftsan1 (n=jftsang@88-108-171-83.dynamic.dsl.as9105.com) |
| 19:59.58 | *** join/#bzflag hobbsc (n=hobbsc@ip70-178-55-100.ks.ks.cox.net) [NETSPLIT VICTIM] |
| 19:59.58 | *** join/#bzflag Flash (n=jwmelto@unaffiliated/flash) |
| 20:00.45 | *** join/#bzflag Constitution (n=const@unaffiliated/macsforme) |
| 20:09.06 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 20:13.14 | Flash | are plugins allowed to initiate network connections, or should they only be able to use the defined callbacks? |
| 20:13.22 | *** join/#bzflag Wyk3d (i=Wyk3d@82.78.166.254) |
| 20:15.00 | JeffM | Flash, at present only callbacks |
| 20:15.15 | JeffM | if they want to do there own networking they can do that inside in there own way |
| 20:15.31 | JeffM | normaly servers don't connet to anything so having bzfs connect out is "wierd" |
| 20:15.31 | Flash | so is the bz_NetworkSocketListener an aberration? |
| 20:15.48 | JeffM | ahh listening |
| 20:15.53 | JeffM | not connecting |
| 20:16.09 | Flash | ok, poorly worded question |
| 20:16.10 | JeffM | yes I intended to have an API for listening on a non standard port |
| 20:16.21 | JeffM | but it would use similar callbacks and classes |
| 20:16.30 | JeffM | but I'm not so sure about that now |
| 20:16.41 | JeffM | I'd probalby pull it untill there was a need |
| 20:16.49 | JeffM | there is no need for non game port listening |
| 20:17.10 | *** join/#bzflag jftsang (n=jftsang@88-108-171-83.dynamic.dsl.as9105.com) |
| 20:17.29 | JeffM | if we want to do listening on another port, we can add that into the plugin utils, cus it realy dosn't have ANYThing to do with bzfs at that point |
| 20:50.13 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 20:50.13 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 20:50.49 | *** join/#bzflag dude (n=dude@pool-96-237-183-28.bstnma.fios.verizon.net) |
| 20:54.54 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 21:18.10 | *** join/#bzflag AHA (n=aha@unaffiliated/aha) |
| 21:21.35 | *** join/#bzflag PrezKennedy (i=Matthew@74.86.45.130) |
| 21:26.12 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 21:42.27 | *** join/#bzflag TheReaper (n=4e22d450@bz.bzflag.bz) |
| 21:42.36 | blast007 | hello |
| 21:42.42 | TheReaper | hi |
| 21:47.18 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 21:50.58 | JeffM | does not fear TheReaper |
| 21:52.14 | me1 | Does he fear anything? |
| 21:55.11 | Winny | Rick Astley |
| 21:57.34 | blast007 | ~lart Winny |
| 21:57.34 | ibot | puts Winny into a headlock and administers a mighty noogie, rubbing half of Winny's hair of |
| 21:57.48 | Winny | Don't hate me because I like bad music. |
| 21:58.14 | Lukstr | Fake! You just like the idea of bad music |
| 22:13.52 | JeffM | so he's a bad music poser? |
| 22:14.12 | Lukstr | precisely. |
| 22:14.35 | Winny | nuh uh |
| 22:16.07 | JeffM | yep |
| 22:16.21 | JeffM | so say we all! |
| 22:17.26 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 22:29.34 | *** join/#bzflag L4m3r (n=l4m3r@about/essy/warning/L4m3r) |
| 22:29.34 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 22:51.17 | *** join/#bzflag Macrosoft (n=Macrosof@69.92.113.202) |
| 22:58.09 | Flash | JeffM: if it doesn't make sense for an API user (e.g., plugin) to listen on a socket, is there any need for the APISocketListener class? |
| 22:58.55 | JeffM | no, that's what I was saying, we should remove it |
| 22:59.36 | Flash | I started with removing the bz_NetworkSocketListener, and it cascaded to the APISocketListener |
| 23:00.02 | JeffM | indeed |
| 23:00.16 | JeffM | that was my start at generic socket listenging |
| 23:00.38 | JeffM | but if you pull that, make it' it's own patch |
| 23:00.49 | Flash | ok. I figured that |
| 23:01.40 | JeffM | cooleo |
| 23:03.05 | Flash | hmmm. it looks like pulling it will eliminate the illusion that NetListenerPacketBufferTicker did anything useful |
| 23:03.34 | Winny | I bet JeffM named that one |
| 23:03.48 | JeffM | anything that has to do with listening on non game ports can be yanked |
| 23:03.55 | JeffM | Winny, at least you know what it does ;) |
| 23:04.00 | Winny | this is true |
| 23:04.09 | JeffM | nn would have named it "i" |
| 23:04.38 | Winny | ntLstnrPcktBffrTckr would be my standard thing |
| 23:04.57 | Winny | vowels are for loosers |
| 23:05.00 | Think_Differentl | I'd name it pwnMyPackets |
| 23:05.18 | JeffM | have you read any of his code? |
| 23:05.24 | Think_Differentl | NN's? |
| 23:05.26 | Winny | nn? |
| 23:05.26 | JeffM | he dosn't do anything descriptive |
| 23:05.27 | JeffM | yeah |
| 23:05.31 | Think_Differentl | yeah |
| 23:05.39 | JeffM | all i, j, x1 |
| 23:05.44 | Winny | oh boy |
| 23:05.46 | Think_Differentl | console output is just as bad. |
| 23:05.49 | JeffM | g was a big one for him |
| 23:06.55 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-50.hsd1.tx.comcast.net) |
| 23:06.55 | *** mode/#bzflag [+v spldart] by ChanServ |
| 23:07.05 | Winny | I was reading someones code in programming class.. they used G, g, G_, g_, g- for the names of variables and functions that did completly different things |
| 23:07.37 | JeffM | icky |
| 23:07.53 | JeffM | my names may be long but none has complained about not knowing what they do :) |
| 23:08.47 | *** join/#bzflag donny_baker (n=joevano@about/essy/vvvvv/donnybaker) |
| 23:08.47 | *** mode/#bzflag [+v donny_baker] by ChanServ |
| 23:09.15 | Flash | has anyone used any of the API network stuff? |
| 23:09.24 | JeffM | the non client connection stuff yes |
| 23:09.35 | JeffM | not the generic socket stuff |
| 23:09.49 | JeffM | the non client connection calls are VERY important |
| 23:09.50 | Flash | bz_sendNetworkSocketData for example |
| 23:10.00 | JeffM | that's used by non client stuff |
| 23:10.02 | JeffM | so yeah |
| 23:10.08 | JeffM | IIRC |
| 23:10.13 | JeffM | HTTPD plugins use that |
| 23:10.17 | Flash | ok... the sweater just unravelled |
| 23:11.22 | JeffM | ? |
| 23:11.54 | Flash | bz_sendNetworkSocketData uses the APISocketListener class to manage the bound sockets |
| 23:12.13 | JeffM | does it only send to bound sockets? |
| 23:12.18 | JeffM | it's possible I may be wrong |
| 23:12.24 | JeffM | you should check what calls that |
| 23:12.48 | JeffM | does it send to net handlers too? or is that another API call? |
| 23:13.00 | JeffM | basicly look at the HTTP base class |
| 23:13.07 | JeffM | whatever that uses, is what we have to keep |
| 23:13.09 | Flash | the APISocketListener maintains its own set of NetHandlers |
| 23:13.25 | JeffM | but are those for non client connections? |
| 23:13.33 | Flash | correct |
| 23:13.37 | JeffM | then they have to stay |
| 23:13.42 | Flash | the client connections are entirely internal to bzfs |
| 23:13.43 | JeffM | or at least still work |
| 23:13.56 | JeffM | the guts don't mater so much as long as the API works |
| 23:14.39 | JeffM | what problem are you trying to fix? |
| 23:15.05 | Flash | at the moment, I'm just pulling on strings to see what happens |
| 23:15.23 | Flash | I started down this path chasing the server crash that catay (almost) fixed |
| 23:15.29 | JeffM | why not just follow the code in a debuger? |
| 23:15.56 | Flash | you have to know how to exercise it before you can follow it |
| 23:16.09 | Flash | especially where plugins and the API are concerned |
| 23:16.11 | JeffM | no..... |
| 23:16.21 | JeffM | you step thru the code as it runs, to understand it ;) |
| 23:16.32 | JeffM | debugers are your friend |
| 23:16.34 | JeffM | seriously |
| 23:16.35 | Flash | right, but if it doesn't go down a particular path.... |
| 23:16.49 | JeffM | then as you step you see WHY it didn't go down there |
| 23:16.52 | JeffM | it's not instant |
| 23:16.56 | JeffM | it's a process |
| 23:17.10 | JeffM | then you say "Oh what sets this so it'll go down there?" and do a search etc... |
| 23:21.38 | catay | Flash: there are a lot more issues when removePlayer is called I am afraid |
| 23:22.07 | catay | for example, when i a player gets banned, removePlayer gets called, it sends a superkill msg to the client |
| 23:22.12 | Flash | part of those issues are related to the management of NetHandlers, which is what I'm pulling on |
| 23:22.29 | catay | the client sends a msgExit back , but that never arrives back |
| 23:22.33 | JeffM | catay, you shuld probalby refrence count players and net handlers |
| 23:22.39 | JeffM | and then purge them when everyone is done |
| 23:22.40 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 23:23.09 | Flash | there is that window between connection and when a "player" exists |
| 23:23.43 | catay | i'm trying to get a view on the flow first :) |
| 23:23.45 | Flash | but if the server sends a superkill to the client, does it care about any response? |
| 23:24.37 | catay | well, when it's about a ban or a reject I would say not really |
| 23:25.10 | Flash | it also sends superkill if the idle time expires |
| 23:25.18 | Flash | and I suspect on other kick conditions |
| 23:26.17 | catay | everytime removePlayer gets called and when the notify flag is set iirc |
| 23:30.25 | catay | the nethandler still exists after a removePlayer is called , it's still in the netConnections list |
| 23:31.01 | catay | you might remove it in removePlayer , but thats probably ugly, and i have no idea what the effects are afterwards :) |
| 23:32.10 | Flash | you are right, there are other issues in removePlayer |
| 23:33.15 | catay | thas also why the SIGPIPE happens |
| 23:33.36 | catay | when a client sends a MsgExit , no SIGPIPE should happen, the connection should be closed in a good way |
| 23:33.51 | catay | i think |
| 23:34.08 | Flash | if the client sends to a closed socket, it will get an error |
| 23:34.24 | Flash | but the server shouldn't have to wait for the client to acknowledge a disconnect |
| 23:34.59 | Flash | perhaps, in response to a superkill message, the client should just do nothing |
| 23:35.36 | catay | yes, i was also thinking that |
| 23:36.45 | Flash | what I have seen is that in removePlayer, the player's NetHandler is marked for deletion, even though other players may be using it. |
| 23:36.52 | Flash | I think this is unique to robots, though |
| 23:37.15 | Flash | and a symptom of the fact that robots aren't forced to quit when the "real" user is |
| 23:38.43 | catay | didn't look into the bots problem |
| 23:38.56 | Flash | well, they are broken on trunk |
| 23:39.14 | catay | and they all use the same nethandler? |
| 23:39.21 | catay | the players nethandler? |
| 23:39.25 | Flash | on the server side, yes |
| 23:40.03 | JeffM | that alone may be reason enough to make them each use there own |
| 23:40.08 | Flash | probably because the server doesn't distinguish the source of UDP data (but I haven't looked) |
| 23:41.28 | Flash | ok, the sweater is still intact |
| 23:41.40 | Flash | no one was using the generic socket listening API |
| 23:41.50 | catay | what's 'sweater' ? |
| 23:42.04 | catay | or it's an expression ? |
| 23:42.12 | Flash | when you have a knitted sweater, if you pull a string, the whole thing can unravel |
| 23:42.21 | catay | aah ok :) |
| 23:42.49 | Flash | this string wasn't connected to anything, so I could pull it off |
| 23:42.52 | JeffM | the analogy dosn't come over very well to what you are doing |
| 23:43.12 | JeffM | since you shuld not be just pulling strings |
| 23:43.33 | JeffM | use your tools and follow them ;) |
| 23:46.55 | catay | maybe we should first focus on making sure the whole messaging between client <-> server is correct and consistent |
| 23:47.00 | catay | and then fix the bots |
| 23:48.54 | catay | it will probably easier to fix the bots when an individual client already behaves consisent |
| 23:49.20 | catay | if i'm talking nonsens, say so, i can handle it :) |
| 23:50.46 | *** join/#bzflag I_Died_Once (n=I_Died_O@unaffiliated/idiedonce/x-1828535) |
| 23:51.07 | I_Died_Once | question - what doews one have to do to enable the geno flag in bzfs ???????? |
| 23:51.22 | I_Died_Once | wzxuse me... in rabbit hunt |
| 23:51.34 | I_Died_Once | how do you get geno in rabbit hunt |
| 23:51.37 | Flash | oooooh.... fun (for the rabbit) |
| 23:51.47 | I_Died_Once | it used to work, i remember being rabbit and laying everyone to waste |
| 23:52.04 | I_Died_Once | with the regue geno plugin |
| 23:52.40 | JeffM | adding them with +f dosn't work? |
