| 00:00.50 | Lukstr | DTRemenak, Erroneous, or JeffM: Can someone verify I did my makefile.am's correctly? include, include/BZW, and tools/ and tools/worldTest :S I mostly copied by example. The build works but there may be some oddities in the files |
| 00:01.27 | JeffM | pffft, I can't even make them work half the time :) |
| 00:01.53 | Lukstr | oh yeah, why on earth did I include you |
| 00:01.55 | Lukstr | :P |
| 00:02.09 | Lukstr | I always forget about your windozeness |
| 00:03.17 | JeffM | don't forget plugins that load other plugins !;) |
| 00:11.13 | bryjen | only if you'll stop forgetting to use your parameters. |
| 00:11.23 | bryjen | them po po lonely parameters ;) |
| 00:11.27 | JeffM | I try to remember to comment them out |
| 00:11.30 | JeffM | what did I Miss? |
| 00:12.03 | bryjen | plugin_HTTPVDIR.h:50: warning: unused parameters 'vdir' 'resource' 'userID' 'requestID' |
| 00:12.32 | JeffM | yeah that one |
| 00:12.33 | JeffM | sorry |
| 00:12.54 | JeffM | any others? |
| 00:13.22 | bryjen | donno, it stops building there. i'll fix 'em up and see |
| 00:13.25 | JeffM | I had remember the one in httpTest.cpp just not the header, |
| 00:13.28 | JeffM | I'm commiting it now |
| 00:13.53 | CIA-35 | BZFlag: 03JeffM2501 * r17673 10/trunk/bzflag/plugins/plugin_utils/plugin_HTTPVDIR.h: remove unused params in the stubbed virtual functions |
| 00:14.24 | JeffM | usualy I just skipp the headers, but I forgot that I had stubs in that header |
| 00:14.45 | spldart | is doin test build in linux |
| 00:15.07 | bryjen | that's got it |
| 00:15.38 | JeffM | thanks |
| 00:15.50 | JeffM | I've been trying to remmber them :) |
| 00:25.30 | spldart | looks good |
| 00:32.26 | Thumper_ | bryjen: make -k |
| 00:33.29 | Thumper_ | votes we stop checking for unused parameters.... and just -Wno-unused-parameters as the default for debug builds - the code looks cleaner and it helps for stubbing things out |
| 00:36.53 | Erroneous | would be ok with that |
| 00:54.43 | *** join/#bzflag TD--Linux (n=wheeeeee@24-180-141-8.dhcp.roch.mn.charter.com) |
| 01:25.24 | *** join/#bzflag Electric1lf (n=dbharris@bas10-toronto63-1177603451.dsl.bell.ca) |
| 01:42.06 | *** join/#bzflag TD--Linux (n=wheeeeee@24-180-141-8.dhcp.roch.mn.charter.com) |
| 01:49.36 | JeffM | so blast007 you thought that having bzfs host HTTP was wierd, how about having BZFS host HTTP and support the PUT action, so that you can upload maps directly into the server? ;) |
| 01:49.55 | spldart | woah |
| 02:00.33 | CIA-35 | BZFlag: 03JeffM2501 * r17674 10/trunk/bzflag/plugins/HTTPServer/HTTPServer.cpp: |
| 02:00.33 | CIA-35 | BZFlag: parse and support all HTTP request types. |
| 02:00.33 | CIA-35 | BZFlag: send 100 responce code for POST and PUT |
| 02:00.58 | CIA-35 | BZFlag: 03JeffM2501 * r17675 10/trunk/bzflag/plugins/ (HTTPServer/HTTPServer.sln httpTest/httpTest.vcproj): build httpTest with HTTPServer for ease of testing. |
| 02:16.13 | brlcad | ~seen bugQ |
| 02:16.15 | ibot | bugq <n=bugQ@c-67-166-124-4.hsd1.ut.comcast.net> was last seen on IRC in channel #bzflag, 1d 2h 36m 42s ago, saying: 'I think that the client will associate the cookie with the port number by default, but not sure...'. |
| 02:19.23 | *** join/#bzflag KingofCamelot (n=davidsan@pb-fw.redshift.com) |
| 02:19.52 | *** join/#bzflag JeffM (n=JeffM@adsl-76-243-140-190.dsl.lsan03.sbcglobal.net) |
| 02:26.48 | JeffM | DTRemenak, you home yet? |
| 02:39.05 | temp_dist | has anyone thought about doing a translator right in the game chat - English->German etc |
| 02:39.41 | JeffM | yes it has been thought about |
| 02:39.59 | JeffM | our current translation system can't do it |
| 02:40.04 | JeffM | but other systems could |
| 02:40.10 | JeffM | they'd not be very accurate |
| 02:40.15 | JeffM | but they could try |
| 02:40.37 | JeffM | it'd eat up some client CPU |
| 02:40.41 | temp_dist | thx - again a question of resources I suppose |
| 02:40.52 | JeffM | well noone has done it |
| 02:40.54 | JeffM | that's all |
| 02:41.08 | temp_dist | eya |
| 02:41.09 | JeffM | the current translator only does static messages |
| 02:41.21 | JeffM | so in game messages |
| 02:41.35 | JeffM | chat requires a different translation system |
| 02:43.40 | JeffM | you are more then welcome to hook one up :) |
| 03:08.38 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 03:14.59 | *** join/#bzflag KingofCamelot (n=davidsan@pb-fw.redshift.com) |
| 03:36.58 | JeffM | tries to figure out how to parse HTTP headers using streams |
| 03:42.19 | *** join/#bzflag JeffMMain (n=Jeff@pool-71-109-217-145.lsanca.dsl-w.verizon.net) |
| 04:05.58 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 04:18.32 | JeffMMain | DTRemenak: you arround? |
| 04:40.30 | CIA-35 | BZFlag: 03JeffM2501 * r17676 10/trunk/bzflag/plugins/plugin_utils/ (plugin_utils.cpp plugin_utils.h): have tokenize take an optional offset so that it doesn't have to start at the beginning of the input string |
| 04:56.05 | JeffMMain | hmm what's better for a HTTP request code that isn't suported? 503 Service Unavailable or 501 Not Implemented |
| 04:56.28 | Lukstr | 410: Gone. |
| 04:56.41 | JeffMMain | no that's a client error |
| 04:56.48 | Lukstr | I know, but it's my favourite :P |
| 04:57.03 | temp_dist | 503 sounds like it's supposed to be there but isn't now |
| 04:57.04 | JeffMMain | heh |
| 04:57.20 | Lukstr | and 501 sounds like it will be eventually |
| 04:57.50 | JeffMMain | ahh 503 is due to load |
| 04:57.54 | JeffMMain | 501 it is |
| 05:46.09 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 05:46.09 | *** mode/#bzflag [+v tupone] by ChanServ |
| 06:12.11 | *** join/#bzflag KingofCamelot (n=davidsan@pb-fw.redshift.com) |
| 06:24.15 | *** join/#bzflag Saturos_iPod (n=root@i59F73479.versanet.de) |
| 06:36.37 | *** join/#bzflag codergeek42 (n=pgordon@fedora/codergeek42) |
| 06:48.54 | CIA-35 | BZFlag: 03JeffM2501 * r17677 10/trunk/bzflag/plugins/ (4 files in 3 dirs): |
| 06:48.54 | CIA-35 | BZFlag: convert the page generation and HTTP requests into a task system. |
| 06:48.54 | CIA-35 | BZFlag: handle HTTP GET, POST, PUT, OPTIONS, TRACE, and HEAD |
| 06:57.24 | *** join/#bzflag KingofCamelot (n=davidsan@pb-fw.redshift.com) |
| 07:11.42 | *** join/#bzflag LongDon (n=LongDon@host-091-097-031-208.ewe-ip-backbone.de) |
| 07:13.41 | *** part/#bzflag LongDon (n=LongDon@host-091-097-031-208.ewe-ip-backbone.de) |
| 08:30.19 | *** join/#bzflag zee217 (n=5c802f11@gateway/web/cgi-irc/zeebrothers.net/x-57e5e890cdae9701) |
| 08:38.17 | *** join/#bzflag noyb (n=noyb@nat/sun/x-efe982ef312d6ce7) |
| 08:47.44 | KingofCamelot | So who's awake? :) |
| 09:00.29 | CBG | Most Europeans... |
| 09:05.32 | KingofCamelot | Which doesn't seem like much in here :P |
| 09:05.59 | CBG | Nope. :P |
| 09:07.18 | L4m3r | I'm still up, but probably not for much longer |
| 10:01.43 | *** join/#bzflag ViciousM (n=max@cpe-024-211-248-161.nc.res.rr.com) |
| 10:02.22 | CIA-35 | FTGL: 03sammy * r1195 10/trunk/ (configure.ac docs/Makefile.am): |
| 10:02.22 | CIA-35 | FTGL: * Fix sf.net issue #1997905, thanks to Coleman Kane: |
| 10:02.22 | CIA-35 | FTGL: + Check for the sed tool. |
| 10:02.22 | CIA-35 | FTGL: + Do not use sed's -i flag: its behaviour across platforms is inconsistent. |
| 10:26.09 | Wyk3d | wtf .. fprintf(stderr, "x"); works fine in a single threaded build and crashes in a multithreaded build :S |
| 10:32.52 | CIA-35 | BZFlag: 03wyk3d * r17678 10/trunk/bzauthd/test/test.cpp: |
| 10:32.52 | CIA-35 | BZFlag: * Fixed all mem leaks except one which seems like a libgcrypt bug |
| 10:32.52 | CIA-35 | BZFlag: * Switched fprintf(stderr..) to printf because it seems to crash for no reason |
| 10:32.52 | CIA-35 | BZFlag: * Renamed some functions, added some comments |
| 10:54.07 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 11:09.12 | *** join/#bzflag Winny (n=KyleVE@unaffiliated/winny) |
| 11:13.41 | *** join/#bzflag LongDon (n=LongDon@host-091-097-031-208.ewe-ip-backbone.de) |
| 11:19.44 | CIA-35 | BZFlag: 03wyk3d * r17679 10/trunk/bzauthd/test/ (common.cpp common.h gcrypt.cpp ldap.cpp net.cpp test.cpp): |
| 11:19.44 | CIA-35 | BZFlag: * Split the test code for gcrypt, ldap and net into separate files |
| 11:19.44 | CIA-35 | BZFlag: * Added the precompiled header "common.h" |
| 11:19.45 | CIA-35 | BZFlag: * Added the standard bzflag header and footer to all files |
| 11:20.22 | CIA-35 | BZFlag: 03wyk3d * r17680 10/trunk/bzauthd/MSVC/VC7.1/test.vcproj: * Missed a file in the last commit |
| 11:27.54 | *** join/#bzflag zee114 (n=c319edba@gateway/web/cgi-irc/zeebrothers.net/x-b6e7ac706ffd3efe) |
| 11:58.37 | *** join/#bzflag ep (n=mdr@about/essy/guynextdoor/ep) |
| 12:03.52 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 12:10.16 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 12:10.16 | *** mode/#bzflag [+v tupone] by ChanServ |
| 12:15.54 | Wyk3d | http://bzflag.pastebin.com/m630236d4 .. any ideas ? |
| 12:15.56 | *** join/#bzflag ViciousM (n=max@cpe-024-211-248-161.nc.res.rr.com) |
| 12:16.28 | CBG | Well, if you an fix the errors, that'd definitely be a start! |
| 12:17.00 | Wyk3d | and the end too |
| 12:17.09 | CBG | Could be. |
| 12:32.00 | *** join/#bzflag QuantumBeep (i=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 12:46.39 | *** join/#bzflag Gabe_G23 (n=chatzill@cpe-069-134-026-246.nc.res.rr.com) |
| 13:06.18 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 13:13.06 | *** join/#bzflag CBG (n=CBG@cpc2-stme1-0-0-cust307.cdif.cable.ntl.com) |
| 13:39.38 | *** join/#bzflag Gabe_G23 (n=chatzill@cpe-069-134-026-246.nc.res.rr.com) |
| 13:54.07 | Wyk3d | in VC .. how do i make sure i'm linking dynamically with the CRT in each project ? |
| 13:56.25 | *** join/#bzflag spldart (n=short_ci@adsl-70-240-250-131.dsl.hstntx.swbell.net) |
| 13:56.25 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:03.51 | Wyk3d | woot .. problem solved :) |
| 14:10.17 | *** join/#bzflag F687s_ (n=noah@cpe-98-30-188-38.woh.res.rr.com) |
| 14:18.50 | brlcad | ~seen bugq |
| 14:18.52 | ibot | bugq <n=bugQ@c-67-166-124-4.hsd1.ut.comcast.net> was last seen on IRC in channel #bzflag, 1d 14h 39m 19s ago, saying: 'I think that the client will associate the cookie with the port number by default, but not sure...'. |
| 14:21.10 | Winny | brlcad: he fell down a well |
| 14:23.03 | *** join/#bzflag Warinthestar (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 14:26.43 | *** join/#bzflag F687s__ (n=noah@cpe-98-30-188-38.woh.res.rr.com) |
| 14:29.25 | brlcad | more like fell into a ditch, one he's digging |
| 14:29.54 | *** join/#bzflag F687s__ (n=noah@cpe-98-30-188-38.woh.res.rr.com) |
| 14:30.08 | *** part/#bzflag F687s__ (n=noah@cpe-98-30-188-38.woh.res.rr.com) |
| 14:31.48 | Winny | you don't sound very happy ;) |
| 15:11.57 | *** join/#bzflag Hannibal (n=47031448@gateway/web/cgi-irc/zeebrothers.net/x-57d7bfb8cfa1e919) |
| 15:12.05 | Hannibal | hello? |
| 15:12.20 | Hannibal | -_- |
| 15:12.55 | Gabe_G23 | Hi |
| 15:13.06 | Hannibal | i need help |
| 15:13.26 | Gabe_G23 | With what? |
| 15:13.37 | Gabe_G23 | If it's BzFlag related, I'm not the person to ask. :D |
| 15:13.41 | Gabe_G23 | But I can try |
| 15:14.07 | Hannibal | whenever i log into bzflag.com a page that says bz.bzflag.bz and a little devil at the bottom |
| 15:14.31 | brlcad | heh |
| 15:14.41 | Gabe_G23 | Just updates probably |
| 15:14.47 | Hannibal | and it says powered by freeBSD |
| 15:14.50 | Gabe_G23 | Nevermind |
| 15:14.54 | Gabe_G23 | Go to bzflag.org not .com |
| 15:15.05 | Hannibal | oh ;) |
| 15:15.16 | Gabe_G23 | Well, I guess BzFlag has their servers hosted on FreeBSD. :) Good choice. |
| 15:15.28 | brlcad | looks like tim didn't update the apache config for the .com domain |
| 15:15.30 | Hannibal | k problem solved |
| 15:15.33 | Hannibal | doh |
| 15:15.37 | Gabe_G23 | Lol |
| 15:15.39 | Hannibal | =P |
| 15:17.00 | Gabe_G23 | brlcad: Also, on bzflag.org if you click 'stats' it'll bring you to stats.bzflag.org, but it's just the main-page, the only way to navigate to the stats page (that I know of) is the Wiki for now. |
| 15:17.08 | Gabe_G23 | stats should redirect to my.bzflag.org I think |
| 15:17.30 | Thumper_ | brlcad: I'd like to stop checking for unused parameters on debug builds - this keep the code cleaner looking and makes stubbing things out easier - any object to me changing configure.ac for linux and adding -Wno-unused-parameter or debug builds? Not sure if you want to me to touch beos - I have no way to test that |
| 15:17.38 | Thumper_ | dtr was okay with that idea |
| 15:18.01 | Thumper_ | s/object/objection/ |
| 15:18.31 | Thumper_ | has to read before hitting return. duh. '-Wno-unused-parameter on* debug builds' |
| 15:18.55 | brlcad | Gabe_G23: riker changed all the domains yesterday, a fair bit is in flux -- mention it to him |
| 15:19.19 | Gabe_G23 | I'll try |
| 15:20.41 | brlcad | Thumper_: except those warnings sometimes make it rather blatently clear that there's some problem in the API |
| 15:21.10 | brlcad | someone refactors the guts to a function, implicitly changing what the API needed to be |
| 15:21.22 | Thumper_ | ok fair enough |
| 15:21.37 | brlcad | i wouldn't have heartbreak over it getting added, that's for sure |
| 15:21.45 | brlcad | but there is some (minor) benefit |
| 15:22.14 | Thumper_ | to check that kind of thign we could compile with that check enabled specifically - but that wouldn't be somethine we'd normally do I think |
| 15:22.34 | Thumper_ | but I can keep commenting out JeffM's unused parameters to get the linux build to work :) |
| 15:26.41 | CIA-35 | BZFlag: 03bthansen * r17681 10/trunk/bzflag/plugins/plugin_utils/plugin_HTTPVDIR.h: Unused parameters |
| 15:27.20 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 15:27.43 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 15:34.14 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 15:42.20 | *** join/#bzflag Think_Differentl (n=James@unaffiliated/thinkdifferentl/x-838543) |
| 15:47.11 | brlcad | Thumper_: or take away his vc build setting that turns off most warnings :) |
| 15:47.29 | Thumper_ | doesn't do VC build settings :) |
| 15:48.07 | Thumper_ | I could wing it and edit it by hand and if it breaks his project he'll have to fix it (after screaming at me) ;) |
| 15:48.56 | brlcad | that's what I usually do |
| 15:49.11 | brlcad | though the warning quells are actually in the code usually |
| 15:52.17 | CIA-35 | BZFlag: 03wyk3d * r17682 10/trunk/bzauthd/ (8 files in 4 dirs): |
| 15:52.17 | CIA-35 | BZFlag: * Missed a file in the last commit* Added some test code for the TCPConnection class that uses two threads for sending and receiving data |
| 15:52.17 | CIA-35 | BZFlag: * Modified TCPConnection to use a packet header consisting of an opcode and the data size instead of reading in chunks |
| 15:52.18 | CIA-35 | BZFlag: * Fixed the incorrect CRT setting in the test project that caused link errors |
| 15:52.20 | CIA-35 | BZFlag: * Other cleanups |
| 15:52.51 | Wyk3d | hmm how did "missed a file" get into the commit message :-/ |
| 15:53.14 | Wyk3d | oh well.. |
| 15:57.50 | *** join/#bzflag TimRiker (n=timr@70-1-117-50.area1.spcsdns.net) |
| 15:57.51 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 16:02.22 | brlcad | ques Gabe_G23 |
| 16:02.34 | Gabe_G23 | Lol |
| 16:03.13 | Gabe_G23 | TimRiker: At bzflag.org, there is a problem with the stats link on the left hand side. It links to stats.bzflag.org, but what comes up is the main-page, the only way to get to the real stats page is via the wiki, which leads you to my.bzflag.org |
| 16:04.41 | brlcad | (and bzflag.com doesn't seem to have the right configuration) |
| 16:06.38 | Gabe_G23 | Yep |
| 16:13.53 | *** join/#bzflag QuantumTim (n=tim@62-249-230-206.no-dns-yet.enta.net) |
| 16:36.41 | CIA-35 | BZFlag: 03wyk3d * r17683 10/trunk/bzauthd/test/tcp-net.cpp: |
| 16:36.41 | CIA-35 | BZFlag: * Added some more clients for testing |
| 16:36.41 | CIA-35 | BZFlag: * Fixed a buffer overrun |
| 16:39.36 | TimRiker | Gabe_G23: thx. I look at that. |
| 16:39.51 | Gabe_G23 | No problemo. |
| 16:41.11 | TimRiker | Gabe_G23: fixed. thanx. |
| 16:41.46 | Gabe_G23 | Cool, thank you also.b |
| 16:50.19 | *** join/#bzflag BenUrban (n=benurban@c-68-49-10-243.hsd1.md.comcast.net) |
| 16:54.56 | *** join/#bzflag Erroneous (n=dtremena@about/essy/CrazyCoder/DTRemenak) |
| 16:54.56 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 16:58.50 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:06.22 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 17:07.32 | *** join/#bzflag delusional_ (n=delusion@pool-71-253-20-249.pitbpa.east.verizon.net) |
| 17:28.18 | Winny | humm, I should empty my mailbox.. getting close to 4000 |
| 17:31.06 | *** join/#bzflag AAA_awright (n=AAA_awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 17:32.13 | whodaman- | ~Chestal++ |
| 17:35.26 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:42.14 | CIA-35 | BZFlag: 03wyk3d * r17684 10/trunk/bzauthd/ (tcp-net/src/TCPConnection.cpp test/tcp-net.cpp): |
| 17:42.14 | CIA-35 | BZFlag: * Added server replies to the clients' test packets. |
| 17:42.14 | CIA-35 | BZFlag: * Fixed a sendData bug. |
| 17:44.49 | *** join/#bzflag panoptical2 (n=Ned@adsl-144-242-240.aby.bellsouth.net) |
| 17:45.04 | *** part/#bzflag panoptical2 (n=Ned@adsl-144-242-240.aby.bellsouth.net) |
| 17:49.49 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 18:11.46 | *** join/#bzflag zee283 (n=53f119c5@gateway/web/cgi-irc/zeebrothers.net/x-5cce224abdb390cc) |
| 18:17.45 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 18:18.06 | Epyon | brlcad, ping |
| 18:18.14 | brlcad | Epyon: pong |
| 18:18.31 | Epyon | brlcad, I have a request for allowance of using namspaces :) |
| 18:19.27 | brlcad | we've been over this before, "why?" |
| 18:19.32 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@unaffiliated/spazzymcgee) |
| 18:19.40 | Epyon | After two days of research, I came up with the need to do a proper graph implementation. I'd like to use the names "Graph, Face, Edge, Node" but all those are very common, and conflict even with my own code. |
| 18:19.41 | brlcad | the one reason you gave turned out to actually be bad code from the sound of it |
| 18:20.12 | Epyon | I COULD name all the classes GraphEdge, GraphGraph, GraphFace, GraphNode, but that would look ugly imho |
| 18:20.22 | Lukstr | Graph::Edge |
| 18:20.23 | Lukstr | ;) |
| 18:20.30 | Epyon | So I'd like to keep them in a separate namespace. |
| 18:20.51 | Epyon | Lukstr, that'd make for a biiig Graph class :P |
| 18:20.59 | brlcad | actually, yeah, what Lukstr said .. wouldn't you have a Graph class that handles all those? |
| 18:21.04 | Epyon | But actually, that may not be as dumb as it sound. |
| 18:21.12 | Epyon | Edge needs to be a class too. |
| 18:21.33 | Epyon | But I don't know how to separate those classes into separate headers, |
| 18:21.42 | Epyon | Lukstr, any suggestions? |
| 18:21.54 | Epyon | Also there's the filenaming problem. |
| 18:22.37 | Wyk3d | I think you can just declare class X { class Y; }; and then do class X::Y {}; |
| 18:23.10 | JeffM | yep |
| 18:23.35 | JeffM | GameKeeper::Player:: anyone?! |
| 18:23.48 | Epyon | If I have a Graph class, can I then write in Edge.h "namespace Graph{ " ? |
| 18:24.00 | brlcad | since several of you are here listening, one thing I want to make sure is set up if not already for all the gsocers is a progress page -- if you don't have one already, something like using your wiki/User: page will work just fine |
| 18:24.15 | brlcad | if you do have one already set up, can you PM me the link |
| 18:24.16 | JeffM | heh, listening... yeah right ;) |
| 18:24.23 | Epyon | brlcad, I'll update the blog this weekend, is that enough? |
| 18:24.34 | brlcad | my weekend has already started :) |
| 18:24.42 | Epyon | And keep on updating it on a regular basis |
| 18:25.27 | Lukstr | hm? |
| 18:25.29 | Wyk3d | wouldn't the progress report be just a short form of the svn comments ? |
| 18:25.31 | Lukstr | sorry was making coffee |
| 18:25.37 | Epyon | I'm in a push right now, luckily nothing personal related (phd-related this time -- end of sememster, exams etc), but all is ok. |
| 18:25.51 | Lukstr | Epyon: yes, you can |
| 18:26.31 | Lukstr | re: namespace A{ class B; }; |
| 18:27.19 | brlcad | Wyk3d: highly paraphrased for a non-coder audience |
| 18:27.25 | brlcad | at a higher level |
| 18:27.48 | Wyk3d | i see .. |
| 18:28.00 | brlcad | just a sentance or two a week on what you did, what you're doing, and what the next step is |
| 18:28.13 | brlcad | can be more frequently (e.g. daily), but shouldn't be less |
| 18:30.33 | CIA-35 | BZFlag: 03chaos-dev * r17685 10/trunk/bzwgen/ (9 files in 3 dirs): Reorganization |
| 18:35.15 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 18:39.24 | CIA-35 | BZFlag: 03chaos-dev * r17686 10/trunk/bzwgen/inc/graph/ (Graph.h Node.h PlanarGraph.h): Reorgnization part two |
| 18:41.44 | Epyon | brlcad, btw, is my comment style ok now? (example MathUtils.h |
| 18:45.30 | brlcad | Epyon: your @name sections are going to get ganged up with the following block iirc |
| 18:45.46 | brlcad | looks like you're wanting groups |
| 18:45.48 | Epyon | I'll test that later |
| 18:45.56 | Epyon | yeah |
| 18:46.05 | brlcad | there's a grouping operator if that's really critical, otherwise just add the comment to the ones it applies to |
| 18:46.10 | Epyon | I used @name in another project and it worked. |
| 18:46.20 | Epyon | But i'll test it |
| 18:46.34 | brlcad | more troublesome that it's still in a math namespace with min/max funcs that don't belong there :P |
| 18:46.36 | Epyon | Today however is plan&code day, not maintenance day :) |
| 18:48.02 | brlcad | would like to see that plan documented somewhere before you get started on it |
| 18:49.36 | Epyon | I'm following my documented schedule |
| 18:49.59 | Epyon | However, I underestimated this weeks problems :/ |
| 18:50.17 | Epyon | I'll write my plans in more detail in the blog post tommorow |
| 18:50.37 | brlcad | well, then I have a question |
| 18:50.43 | Epyon | Go ahead |
| 18:50.45 | brlcad | what's the graph stuff actually for? |
| 18:50.58 | Epyon | To remove axis-alignment from the map |
| 18:51.23 | Epyon | And allow propoer non-quad based shapes as a bonus |
| 18:51.55 | brlcad | that didn't answer my question :) |
| 18:52.02 | Epyon | Another bonus will be proper and working MultiFaces (which don't work well) |
| 18:52.20 | brlcad | graphs have nothing to do with coordinates and allowed shapes |
| 18:52.44 | brlcad | what specific purpose does the graph serve other than it's the container you want to use? |
| 18:53.19 | Epyon | I told you, I don't want the map to be gridbased, because that looks a lot worse, then non-grid based |
| 18:53.24 | brlcad | you presumably already have some relational structure in place, if only via the grammer you defined for defining the worlds |
| 18:53.50 | brlcad | a graph doesn't magically make something not grid-based .. |
| 18:53.53 | Epyon | The grammar currently only builds buildings. |
| 18:54.13 | Epyon | The second part is the part that divides the world into the building lots |
| 18:54.41 | brlcad | the second part of what? |
| 18:54.49 | CIA-35 | BZFlag: 03wyk3d * r17687 10/trunk/bzauthd/ (6 files in 3 dirs): |
| 18:54.50 | CIA-35 | BZFlag: * Added the bzauthd project and solution |
| 18:54.50 | CIA-35 | BZFlag: * Other cleanups, comments etc |
| 18:54.52 | Epyon | And this is the part that I want to rewrite not to be axis-aligned. The fun part is that once I do that, there will be only a couple tweaks needed for the existing grammar to work on the new base. |
| 18:54.59 | Epyon | BZWGen |
| 18:55.26 | Epyon | BZWGen works in two steps -- 1) divide the world into lots 2) pass the lots to the grammar to build buildings |
| 18:55.35 | brlcad | "only builds buildings" .. isn't that kinda the point of the tool |
| 18:55.48 | brlcad | what else are you referring to? |
| 18:56.01 | Epyon | Yes, but having a only axis aligned base is limiting as hell. |
| 18:56.22 | Epyon | Refining step two will be done once step one is refined. |
| 18:56.51 | brlcad | ok, let me be clear .. I'm NOT arguing that axis aligned is good and that there aren't benefits to be had by making it not grid-based |
| 18:56.51 | Epyon | Also the current non-quad based grammar actions are a ugly hack |
| 18:57.00 | brlcad | i'm saying that has nothing to do with needing a graph structure |
| 18:57.10 | brlcad | what purpose does the graph itself serve? |
| 18:57.30 | Epyon | You're trying to say, that you don't need a graph to generate a non-axis-aligned world, right? |
| 18:57.47 | brlcad | if I was trying to say that, I would have said that |
| 18:57.56 | brlcad | i'm asking you why do you need a graph |
| 18:58.14 | Epyon | To make the world not axis aligned :/ |
| 18:58.23 | Epyon | I think we have a communication problem :( |
| 18:58.26 | brlcad | apparently |
| 18:58.36 | Epyon | I don't understand the question :( |
| 18:59.07 | Epyon | Ok, let's try it this way: |
| 18:59.14 | brlcad | okay, lets go down what you just suggested -- that you don't need a graph to generate a non-axis aligned world |
| 18:59.46 | Epyon | 1) Currently, as my accepted schedule says, I'm working on making the world not axis-aligned, right? |
| 18:59.57 | Epyon | Is that ok? |
| 18:59.58 | brlcad | I can pull up a text editor and make arbitrary map just fine, store those in a set or a linked list .. or a graph .. it's just an associative container |
| 19:00.27 | Epyon | Can you generate it randomly too? |
| 19:00.31 | brlcad | my point and question is why specifically is that sort of container needed versus something else |
| 19:00.51 | brlcad | or is it not needed and it's just the one you have in mind to use |
| 19:00.59 | Epyon | Because I need some Computational Geometry queries to do the random generation. |
| 19:01.06 | Epyon | 1) point location |
| 19:01.16 | Epyon | 2) nearest edge to given point |
| 19:01.24 | Epyon | 3) nearest point to given point |
| 19:02.18 | Epyon | I also can't start generating anything without the base "map". So it needs to be held in some container. |
| 19:02.36 | brlcad | technically you don't "need" that either, that's a want (a useful 'want' for the goal, but a want nonetheless) |
| 19:03.09 | Epyon | This container needs both to store edges (to generate roads from them) as well as vertices (to generate crossings) and faces (to generate lots) |
| 19:03.33 | brlcad | as you can still implement most computational geometry tasks with or without graphs |
| 19:05.17 | Epyon | http://en.wikipedia.org/wiki/Point_location |
| 19:05.36 | Epyon | Actually the biggest problem is the nearest edge |
| 19:06.04 | Epyon | I talked to a few people about that, and all refered me to bidirectional graphs. |
| 19:06.17 | Epyon | And that's also the response I got from Paul Mueller. |
| 19:07.32 | brlcad | ask a bunch of folks that work in computational geometry if you should use a graph or not, and they said you should .. imagine that :) |
| 19:07.45 | Epyon | I could try to come up with some other way, but it'd require a lot more thinking, and probably would be O(n^2) complexity |
| 19:08.05 | brlcad | i probably would have said the same thing, but my point is _for what purpose_ |
| 19:08.52 | Epyon | I still don't get the question. I have a problem. I use a known data structure to solve it. Isn't that a purpose? |
| 19:09.56 | brlcad | yes it is, I'm trying to evaluate that and until you explain the problem it's not clear whether that's a good development direction |
| 19:10.22 | brlcad | especially given you're wanting to break convention and introduce a fair level of complexity |
| 19:11.02 | brlcad | so, what's going into the graph -- the actual geometry in some topological form? |
| 19:11.12 | brlcad | or symbolic representations of some sort? |
| 19:13.05 | Epyon | Just the division of the world |
| 19:13.10 | Epyon | Into zones. |
| 19:13.40 | Epyon | Which won't neccessary be used to create buildings, the other generators will also need this |
| 19:15.00 | brlcad | dividing a world into zones.. that sounds more like a space partitioning problem |
| 19:15.23 | Epyon | To get something more like this : http://download.introversion.co.uk/mirror/introversion/blog/20071212/city1.jpg |
| 19:17.08 | Epyon | brlcad, yeah, I considered just throwing in all the points into a quadtree, and having a list of edges, but that would not allow me to do all the queries that I want |
| 19:17.29 | brlcad | what are your points in this case? |
| 19:17.33 | Epyon | Especialy retrieving a face to be passed to the building generator would be a big mess. |
| 19:18.01 | Epyon | face retrieval and checking which edge is the closest |
| 19:18.19 | brlcad | not what are they for |
| 19:18.23 | brlcad | what ARE they |
| 19:18.31 | brlcad | points on a face that represents some geometry? |
| 19:18.46 | Epyon | Um. |
| 19:19.00 | Epyon | Let me state it this way |
| 19:19.03 | brlcad | are they part of the geometry? |
| 19:19.06 | brlcad | simple question |
| 19:19.16 | Epyon | what is a planar division? |
| 19:19.21 | Epyon | A plane graph. |
| 19:19.46 | brlcad | are these points part of the geometry you're generating? |
| 19:19.58 | Epyon | So trying to do a planar division without a structure that holds a plane graph is somewhat.... wierd? |
| 19:20.06 | brlcad | i feel like i'm asking you if you like the color blue, and you tell me the weather |
| 19:20.52 | Epyon | points in this case are points that are the vertices of subdivision :/ |
| 19:21.08 | brlcad | so, the answer is NO |
| 19:21.17 | brlcad | jeez |
| 19:21.23 | Epyon | or in case of the city generator, they'd be the middle points of the road crossings |
| 19:22.24 | Epyon | I'm really feeling like an idiot now :/ |
| 19:23.42 | Epyon | Too bad there's no third party in this discussion to take anyones side and try to explain it to the other. |
| 19:23.43 | brlcad | just a major communication gap, missing terms |
| 19:24.30 | Lukstr | I'm trying to follow |
| 19:24.41 | Epyon | Lukstr, any comments? |
| 19:24.54 | Epyon | Lukstr, do you understand what brlcad wants from me? |
| 19:24.55 | brlcad | ignoring the third dimension, you're basically fracturing a plane into sections |
| 19:25.01 | brlcad | yes? |
| 19:25.03 | Epyon | Yes. |
| 19:25.19 | Lukstr | you're trying to figure out a new way to generate a city? :S |
| 19:25.21 | brlcad | now presently, you do this in a gridded fashion, yes? |
| 19:25.22 | Epyon | The sections also need to be arbitral polygons. |
| 19:25.35 | Epyon | Lukstr, I'm following an existing method. |
| 19:25.41 | Epyon | brlcad, yes. |
| 19:25.42 | Lukstr | oh? |
| 19:25.48 | Lukstr | so what problem are you solving |
| 19:26.31 | brlcad | so in your plan to make it non-gridded, your defining "cell" points by carving up the plane with line segments, yes? (remember 2d) |
| 19:26.43 | Epyon | Lukstr, I solved my problem, but brlcad dosn't like it :? |
| 19:26.54 | brlcad | I never said I didn't like it |
| 19:26.56 | Lukstr | figuring out a way to subdivide? |
| 19:27.02 | brlcad | I want you to be able to explain what you're doing |
| 19:27.15 | Epyon | brlcad, no, my new definition of cell is arbitrary polygons. |
| 19:27.37 | brlcad | yes, but you have to make a polygon and you're just starting with a plane |
| 19:28.03 | brlcad | polygon==cell that I was referring to |
| 19:28.09 | Epyon | brlcad, I need to subdivide a plane into polygons. |
| 19:28.21 | brlcad | yes, we're past that :) |
| 19:28.25 | Epyon | recursively even. |
| 19:28.28 | brlcad | to do that subdivision .. |
| 19:28.33 | brlcad | you're doing what? |
| 19:28.44 | brlcad | or intending to do what? |
| 19:29.07 | Epyon | Run a two-pass L-System ... |
| 19:29.16 | brlcad | no no, back up |
| 19:29.37 | Epyon | ok, another wat |
| 19:29.42 | Epyon | way* |
| 19:29.47 | brlcad | talking low level here, you have a plane, you need to slice that up into cells |
| 19:29.55 | Epyon | I'm going to recursively add edges to the graph |
| 19:30.20 | Epyon | which *not always* will divide it into two parts |
| 19:30.53 | brlcad | based on your slicing rules, sure |
| 19:31.16 | Epyon | no, that's the difference, there's no slicing here |
| 19:31.31 | brlcad | eh? |
| 19:31.39 | Epyon | It's rather growing a network of roads, that when possible connect to existing ones. |
| 19:32.30 | brlcad | okay, that's just another way of describing the same action in my view .. those roads are "slicing rules" that are carving up the planar space |
| 19:32.39 | Epyon | ok |
| 19:33.11 | brlcad | would you say you start with a road or a point? |
| 19:33.31 | Epyon | I start with a face actually |
| 19:33.40 | brlcad | a face is defined how? |
| 19:33.55 | brlcad | connected set of edges (defined as a connected set of points) |
| 19:33.56 | Epyon | One face, four nodes, and 4 edges -- the bzflag worldspace |
| 19:34.08 | Lukstr | Epyon: Why use an L-System? Don't you want constant resolution? |
| 19:34.11 | brlcad | nodes == the corners? |
| 19:34.15 | Epyon | yes |
| 19:34.22 | Epyon | Lukstr, resolution? |
| 19:34.32 | Lukstr | well an L-System is just a recursive fractal |
| 19:34.44 | brlcad | so topologically, at least at the beginning, your nodes are geometric points |
| 19:34.57 | Lukstr | it doesn't seem applicable to city generation |
| 19:35.01 | brlcad | then you add new nodes to subdivide? |
| 19:36.26 | brlcad | you mentioned growing, how are you growing from an encompassing quad like that? (topologically) |
| 19:36.44 | Epyon | Lukstr, http://www.vision.ee.ethz.ch/~pmueller/documents/procedural_modeling_of_cities__siggraph2001.pdf |
| 19:37.07 | Epyon | brlcad, actually, I think I'll start from the middle |
| 19:37.08 | brlcad | notes mueller has had some updates since then :) |
| 19:37.16 | Epyon | By adding a new point |
| 19:37.30 | Epyon | node* |
| 19:37.47 | brlcad | point sounds better :) |
| 19:37.58 | sam | hi there |
| 19:38.00 | brlcad | as that is geometrically what it is |
| 19:38.31 | Epyon | Well, I'm trying to adhere to the mathematical standard naming conventions here :? |
| 19:38.33 | brlcad | Epyon: so then you have a point, what's next step? |
| 19:38.56 | Epyon | add an edge |
| 19:38.57 | brlcad | Epyon: the great thing with standards is that there are so many to choose from? |
| 19:39.27 | brlcad | outside the math department and cg folks, everyone else would call it a point |
| 19:39.37 | sam | brlcad: do you know/remember how the SF.net SVN are configured for CIA notifications? they seem to have zero delay |
| 19:39.38 | brlcad | a point that can be represented as a node in a graph, but it's still a point |
| 19:40.00 | brlcad | sam: there's a post-commit hook registered through the website |
| 19:40.00 | Epyon | ok, ok, but that's not the point (lol!) now :P |
| 19:40.21 | sam | brlcad: do you know whether it uses e-mail or http/xmlrpc ? |
| 19:40.38 | sam | I tried the e-mail one for a project but it's terribly slow |
| 19:40.44 | brlcad | looks |
| 19:40.48 | Epyon | if you wouldn't call it "point" in this sentence "[21:17] <@brlcad> what are your points in this case?" I wouldn't get confused :P |
| 19:41.05 | Epyon | That's why "Node" is better, because it doesn't hold another meaning. |
| 19:41.39 | Epyon | When you asked "what's your point?" I was all the time thinking about "is it pointless" :P |
| 19:41.44 | Epyon | laughs. |
| 19:42.00 | brlcad | sam: it looks like it's xmlrpc |
| 19:42.09 | Epyon | I think you might agree now, that "Node" is a better word to use, at least in discussion :P |
| 19:42.16 | brlcad | sf e-mail stopped a couple hours ago today fwiw |
| 19:42.17 | sam | brlcad: nice, thanks |
| 19:42.39 | sam | I don't touch anything remotely related to sf except when forced to |
| 19:43.00 | brlcad | Epyon: well one is geometry, the other is just one way to represent that geometry |
| 19:43.03 | Lukstr | Epyon: I'm not sure how robust you're trying to make this, but the way I see it is fairly simple |
| 19:43.38 | Lukstr | let me type it up in a pastebin |
| 19:44.00 | Epyon | Lukstr, try |
| 19:44.08 | brlcad | i.e. it's a layer of indirection that just muddles the actual geometric problem being solved |
| 19:44.20 | Epyon | Lukstr, but remember that I need to generate geometry from that afterwards |
| 19:44.34 | Epyon | And the geometry must be mesh-wise perfect |
| 19:44.43 | brlcad | sam: using http://cia.vc/clients/svn/ciabot_svn.py |
| 19:45.06 | Epyon | I'm going to take a quick shower, be right back |
| 19:45.26 | brlcad | Epyon: to finish up for now... I'll just wait to see what you write up in your plan |
| 19:45.51 | brlcad | it's a little more clear what you're trying to solve now that we've gotten to the meat of it |
| 19:47.19 | Epyon | brlcad, let me just state this -- I tried as hard as I could to find a way to solve this without implementing a proper plane graph class, but none of it seemed to work :/ |
| 19:48.50 | Epyon | It's not the same situation as with the language implementation last year -- my argument is not that "this is the way it's done" but simply "I don't see any alternative after doing extensive research on the toopic" |
| 19:50.30 | brlcad | Epyon: the questioning wasn't to say don't do this or that there was a better way, I'm just wanting to understand what you're actually trying to do |
| 19:50.57 | brlcad | and your explanations were just inconsistent with my questions, which led us to even more questions.. |
| 19:54.57 | brlcad | Epyon: also, if you've not already come across it (and I can't imagine that you haven't), CGAL implements a fair bit related to this (althought the QPL portions are untouchable) |
| 19:55.25 | *** join/#bzflag KingofCamelot (n=davidsan@pb-fw.redshift.com) |
| 19:55.33 | brlcad | KingofCamelot! |
| 19:57.09 | brlcad | KingofCamelot: do you have a dev log online somewhere? |
| 20:03.01 | brlcad | Epyon: "a much more detailed timeline will be presented before May 26" .. did I miss that somewhere? |
| 20:08.53 | Epyon | The one before was a lot less detailed :P |
| 20:09.15 | Epyon | CGAL is overloated |
| 20:09.17 | brlcad | heh, "oh" |
| 20:09.21 | Epyon | overbloated* |
| 20:09.39 | Epyon | And wasn't it you who was telling about adding more dependencies? |
| 20:09.58 | Epyon | Not to mention that the CGAL graph implementation relies partially on boost::graph afaik :P |
| 20:10.13 | brlcad | they can always be added, it's just a matter of justifying the cost |
| 20:10.25 | brlcad | it's not like we don't have any dependencies |
| 20:10.59 | brlcad | the boost comments were a word of caution, not a don't go there sign |
| 20:11.46 | JeffM | Epyon, I've told you like THREE times to use boost in your project if you wanted to |
| 20:12.54 | Epyon | Anyway, need to go, we'll talk later |
| 20:12.58 | *** part/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 20:13.13 | brlcad | I'd probably prefer boost over implementing a bunch of graph code anyways, especially if that bit is in c++0x (I don't remember), and especially given you're trying to use that as an excuse for namespaces :) |
| 20:13.17 | brlcad | bleh |
| 20:13.53 | JeffM | he does love to waste the time |
| 20:14.33 | Lukstr | well, someone stop me if this sounds insane |
| 20:14.44 | JeffM | STOP |
| 20:14.47 | Lukstr | :( |
| 20:14.48 | JeffM | hammer time! |
| 20:14.54 | Lukstr | k |
| 20:14.54 | JeffM | do do do do! |
| 20:15.19 | JeffM | what is your insanity? |
| 20:15.31 | Lukstr | ~lart JeffM |
| 20:15.31 | ibot | beats JeffM over the head with a microkernel |
| 20:15.40 | JeffM | no thanks, I don't use macs |
| 20:15.48 | Lukstr | uh, well I was thinking of an easy way to generate cities |
| 20:15.52 | Lukstr | easy as in straightforward |
| 20:22.01 | JeffM | and? |
| 20:23.01 | Lukstr | well |
| 20:23.07 | Lukstr | if we were all in an office with a whiteboard |
| 20:23.11 | Lukstr | this could be easily explained |
| 20:23.18 | Lukstr | essentially you start with a road |
| 20:23.20 | JeffM | welcome to the internet ;) |
| 20:23.36 | Lukstr | each road is defined by a start and end point |
| 20:23.40 | Lukstr | so really you start with a point |
| 20:23.48 | Lukstr | pick a random spot (somewhere near the middle is good) |
| 20:24.57 | Lukstr | it's easier to do everything in polar coordinates |
| 20:25.07 | Lukstr | so you pick a direction and you start iterating |
| 20:25.23 | Lukstr | so each iteration each road grows, in both directions, one unit |
| 20:25.24 | JeffM | sounds like a good ruleset to try in bzwgen |
| 20:25.42 | Lukstr | I used to mess around with fractals and procedurally generated stuff in high school :P |
| 20:25.45 | Lukstr | I have a lot of books |
| 20:26.01 | Lukstr | http://www.complexification.net/gallery/machines/substrate/index.php |
| 20:26.03 | Lukstr | click Medium |
| 20:26.50 | JeffM | fun |
| 20:27.03 | JeffM | but yeah sounds just the kinda thing for an externl ruleset for bzwgen |
| 20:27.10 | Lukstr | what's Epyon working on |
| 20:27.14 | JeffM | that's what it's sposed to allow, people to try various generation algos |
| 20:27.15 | JeffM | yeah |
| 21:02.46 | *** join/#bzflag QuantumBeep (i=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 21:04.38 | *** join/#bzflag bier__ (n=bier@p54A54046.dip.t-dialin.net) |
| 21:18.16 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 21:26.19 | *** join/#bzflag Think_Differentl (n=James@unaffiliated/thinkdifferentl/x-838543) |
| 21:43.03 | *** join/#bzflag Gabe_G23 (n=chatzill@cpe-069-134-026-246.nc.res.rr.com) |
| 22:02.05 | *** join/#bzflag bier_ (n=bier@p54A576D2.dip.t-dialin.net) |
| 22:12.12 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 22:12.12 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 22:13.34 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-50.hsd1.tx.comcast.net) |
| 22:13.34 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:14.02 | CIA-35 | BZFlag: 03dtremenak * r17688 10/branches/gsoc_libbzw/MSVC/VC8/world.vcproj: fix paths |
| 22:14.22 | Erroneous | Lukstr: how are things going? |
| 22:14.33 | spldart | Grr... Boss decided in the middle of this business day that he want to redo are network to wireless.... So no net for me till i got home :( |
| 22:24.06 | *** join/#bzflag bier__ (n=bier@p54A54E27.dip.t-dialin.net) |
| 23:00.43 | CIA-35 | BZFlag: 03JeffM2501 * r17689 10/trunk/bzflag/plugins/ (4 files in 3 dirs): |
| 23:00.43 | CIA-35 | BZFlag: refactor callback systems to only have one content callback, and move the request and reply into modular classes |
| 23:00.43 | CIA-35 | BZFlag: support deferred replys. |
| 23:00.43 | CIA-35 | BZFlag: add initial support for session states and cookie parsing. |
| 23:00.43 | CIA-35 | BZFlag: finish off the basics of HTTP Hosting and have the HTTP test serve a basic page |
| 23:10.18 | CIA-35 | BZFlag: 03JeffM2501 * r17690 10/trunk/bzflag/plugins/HTTPServer/HTTPServer.cpp: support the HEAD HTTP command to just send the header not the body |
| 23:12.24 | CIA-35 | BZFlag: 03JeffM2501 * r17691 10/trunk/bzflag/plugins/plugin_utils/plugin_HTTPVDIR.h: remove auth flag from the VDIR base class. It will be moved to a utility base class later that can be optionally derived |
| 23:15.56 | JeffM | blast007, how do I do an upload field in a form? |
| 23:20.03 | brad | <input type="file" name="file" /> |
| 23:20.29 | JeffM | thanks |
| 23:20.39 | JeffM | if this works, it'll be wierd |
| 23:24.27 | JeffM | hmmm, browser sent it as a get, not a put |
| 23:24.45 | JeffM | http://pastebin.bzflag.bz/m4e877e39 |
| 23:26.33 | CIA-35 | BZFlag: 03JeffM2501 * r17692 10/trunk/bzflag/plugins/httpTest/httpTest.cpp: make the httpTest support PUT and just return the data back. |
| 23:28.58 | CIA-35 | BZFlag: 03JeffM2501 * r17693 10/trunk/bzflag/plugins/HTTPServer/HTTPServer.cpp: need to parse out the params from the URL from all methods except POST |
| 23:40.29 | *** join/#bzflag delusional (n=delusion@pool-141-158-98-225.pitt.east.verizon.net) |
| 23:46.00 | CIA-35 | BZFlag: 03JeffM2501 * r17694 10/trunk/bzflag/plugins/plugin_utils/ (plugin_HTTPVDIR.cpp plugin_HTTPVDIR.h): base class method for vdirs to get the base URL outside of a request ( fastmap needs it ) |
