| 00:11.13 | CIA-11 | BZFlag: 03blast007 * r19496 10/trunk/bzflag/MSVC/build/clientLua.vcproj: Fix the include path for cURL for release builds. |
| 00:16.00 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 00:20.46 | *** join/#bzflag mhilmi (n=mhilmi@70.82.77.138) |
| 00:30.39 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 00:38.36 | CIA-11 | BZFlag: 03trepan * r19497 10/trunk/bzflag/src/common/ParseColor.cxx: |
| 00:38.36 | CIA-11 | BZFlag: * implemented the hexadecimal color specification format |
| 00:38.36 | CIA-11 | BZFlag: (#rgb, #rgba, #rrggbb, #rrggbbaa) |
| 00:38.36 | CIA-11 | BZFlag: * improved named color parsing times by using a map<> |
| 00:41.14 | *** join/#bzflag pacman87 (n=timothy@pool-173-57-39-82.dllstx.fios.verizon.net) |
| 00:42.31 | *** part/#bzflag pacman87 (n=timothy@pool-173-57-39-82.dllstx.fios.verizon.net) |
| 00:42.34 | *** join/#bzflag pacman87 (n=timothy@pool-173-57-39-82.dllstx.fios.verizon.net) |
| 00:47.21 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 00:47.21 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:49.11 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |
| 00:50.50 | CIA-11 | BZFlag: 03trepan * r19498 10/trunk/bzflag/src/common/ParseColor.cxx: |
| 00:50.50 | CIA-11 | BZFlag: * added the (0xRGB, 0xRGBA, 0xRRGGBB 0xRRGGBBAA) hexadecimal notation |
| 00:50.50 | CIA-11 | BZFlag: (for bzw files, to avoid the '#' comment character) |
| 00:57.56 | *** join/#bzflag whodaman (n=whodaman@bzflag/player/Dexter) |
| 01:11.38 | *** join/#bzflag res2k3 (n=res@erft-4d07d10d.pool.mediaWays.net) |
| 01:17.34 | *** part/#bzflag pacman87 (n=timothy@pool-173-57-39-82.dllstx.fios.verizon.net) |
| 01:17.41 | *** join/#bzflag pacman87 (n=timothy@pool-173-57-39-82.dllstx.fios.verizon.net) |
| 01:26.32 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 01:27.26 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 01:43.37 | *** join/#bzflag MacBook (n=whodaman@bzflag/player/Dexter) |
| 02:02.36 | *** join/#bzflag rolando (n=rolando@236.166.54.77.rev.vodafone.pt) |
| 02:02.59 | blast007 | crash in bzfs: http://pastebin.bzflag.bz/d4b4e881b (that's when I tried to join a second client with torBlock, serverControl, fastmap, and webstats loaded) |
| 02:06.49 | JeffM | that's in the data loger |
| 02:19.44 | *** join/#bzflag PositiveG (n=sniper15@S0106002191dd19a8.gv.shawcable.net) |
| 02:28.11 | *** join/#bzflag jcp1 (n=jw@unaffiliated/javawizard2539) |
| 02:33.18 | *** join/#bzflag FastLizard4 (i=FastLiza@wikipedia/FastLizard4) |
| 02:39.51 | delusional | It looked like xcode had completely frozen up when it tried to compile ParseColor.cxx. but it turned out fine. |
| 03:09.01 | *** join/#bzflag rolando_ (n=rolando@164.25.103.87.rev.vodafone.pt) |
| 03:10.10 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 03:24.39 | CIA-11 | BZFlag: 03trepan * r19499 10/trunk/bzflag/src/common/ParseColor.cxx: * faster compilation? (replaced the macro expansions with static data + looping) |
| 03:24.42 | trepan | delusional: see if that helps :) |
| 03:27.13 | CIA-11 | BZFlag: 03trepan * r19500 10/trunk/bzflag/src/common/ParseColor.cxx: * added the missing [ #include "common.h" ] |
| 03:30.32 | delusional | only a couple seconds, this time. |
| 03:31.36 | delusional | at least five minutes... earlier |
| 03:33.01 | trepan | i've seen that before when there are a lot of macro expansions |
| 03:34.45 | CIA-11 | BZFlag: 03blast007 * r19501 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: |
| 03:34.45 | CIA-11 | BZFlag: Include the data/sounds/ directory. |
| 03:34.45 | CIA-11 | BZFlag: Use more specific matches for what files are included. |
| 03:45.14 | dexter- | ~bzflist |
| 03:46.40 | dexter- | awn |
| 04:05.29 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 04:09.05 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 04:11.16 | *** join/#bzflag L4m3r (n=L4m3r@bzflag/developer/L4m3r) |
| 04:11.16 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 04:31.50 | *** join/#bzflag rolando (n=rolando@9.168.54.77.rev.vodafone.pt) |
| 05:32.25 | nightstrike_ | <PROTECTED> |
| 05:33.20 | nightstrike_ | is refactoring and modularizing redundant code, say in, src/bzflag, src/bzrobots and src/bzfs a sufficiently long list? |
| 05:46.37 | *** join/#bzflag short_circuit (n=james@c-98-197-19-35.hsd1.tx.comcast.net) |
| 05:48.12 | *** join/#bzflag nsquare (n=chatzill@c-71-56-70-78.hsd1.ga.comcast.net) |
| 05:52.20 | nsquare | hello |
| 05:52.32 | PositiveG | Hi |
| 05:52.53 | nsquare | hi positiveg |
| 05:54.26 | nsquare | any bzflag developers available? |
| 05:55.01 | blast007 | nsquare: yeah |
| 05:55.17 | blast007 | nightstrike_: hmm, I'm not entirely sure |
| 05:55.31 | nsquare | oh ok |
| 05:55.38 | blast007 | nsquare: what's up? |
| 05:56.03 | nsquare | nothing much :D .. was interested in one of the project ideas |
| 05:56.08 | blast007 | cool |
| 05:56.09 | blast007 | which one? |
| 05:56.29 | nsquare | the one with global authentication |
| 05:56.40 | nsquare | are you also student? |
| 05:57.05 | blast007 | developer |
| 05:57.19 | nsquare | cool :) |
| 05:57.36 | blast007 | do you have any specific questions about the global auth daemon idea? |
| 05:57.36 | nightstrike_ | blast007: I should ask brlcad? |
| 05:57.42 | blast007 | nightstrike_: probably |
| 05:58.06 | nsquare | the webpage says it'll be continuation of last year's project |
| 05:58.18 | nightstrike_ | blast007: I've already found a lot of redundant code, and by comparing the current stable release with the SVN checkout, I'm figuring out how to go about my work |
| 05:58.45 | nightstrike_ | as in, how they've gone about adding things to libgame |
| 05:59.23 | blast007 | nsquare: yeah, current code: http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzauthd/ (similar URL if you want to do a checkout. Just replace http with https and viewvc with svnroot) |
| 05:59.45 | blast007 | nightstrike_: okay |
| 06:01.02 | nsquare | blast: thanks. so i guess i'll need to modify or extend this module, right? |
| 06:01.40 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |
| 06:02.11 | blast007 | nsquare: yup |
| 06:02.38 | blast007 | I'm honestly not sure how far the current code is. haven't looked at in in a while |
| 06:03.06 | blast007 | the general idea is to tie it into OpenLDAP so that we can do a distributed authentication system |
| 06:04.12 | blast007 | end goal is to have our web apps then use that OpenLDAP for authentication (mediawiki, phpbb3), but that probably goes beyond the scope of the GSoC project |
| 06:04.29 | blast007 | those two web services already have some support for LDAP authentication |
| 06:04.42 | nsquare | hmm .. ok |
| 06:05.00 | nsquare | I have one year of experience in this area |
| 06:05.05 | *** join/#bzflag basix (n=DJ@unaffiliated/basix) |
| 06:05.16 | nsquare | so i guess i should be able to do something useful :) |
| 06:05.22 | blast007 | :) |
| 06:06.21 | nsquare | i think the current version of this module is not in deployment, right? |
| 06:06.46 | blast007 | right, haven't been touched in a while |
| 06:06.59 | blast007 | at least for any serious development |
| 06:08.50 | nsquare | i see that this module was started in gsoc 2008. any idea how can i contact Mr. David Wollner or Istvan Szakats? |
| 06:10.12 | blast007 | Wyk3d was the one that started it in 2008 |
| 06:10.21 | blast007 | he was on IRC here earlier today |
| 06:10.25 | blast007 | ~seen Wyk3d |
| 06:10.27 | ibot | wyk3d <n=middle@c7.campus.utcluj.ro> was last seen on IRC in channel #bzflag, 8h 57m 16s ago, saying: 'sorry ;)'. |
| 06:10.56 | nsquare | oh ok |
| 06:11.02 | nightstrike_ | blast007: can you tell me how I can contact brlcad? His email ID or something? |
| 06:11.51 | blast007 | nightstrike_: brlcad hanges out on here, though seems to be away atm |
| 06:12.31 | nightstrike_ | Ok, I seem to miss him by a whisker most of the time |
| 06:12.33 | blast007 | you could try sending an email to his SF email address if you keep missing him here |
| 06:12.47 | nightstrike_ | which is? |
| 06:13.14 | blast007 | http://sourceforge.net/users/brlcad/ <-- info there |
| 06:13.19 | nsquare | blast: so is wyk3d going to continue this project? |
| 06:13.40 | nsquare | assuming that syk3d is student :D :D |
| 06:13.49 | trepan | blast007: heh, started on phaseII of the lua junk, could be interesting :) |
| 06:13.50 | blast007 | nsquare: that's a possibility |
| 06:14.03 | blast007 | trepan: oooh :) |
| 06:14.42 | blast007 | hopefully an nVidia Go 7600GT will be enough to test it, since that's what I'm stuck with at the moment |
| 06:15.08 | CIA-11 | BZFlag: 03Sumit 07http://my.bzflag.org * r5589 10/w/User:Sumit: New page: Hi, I am a student of USIT (University School of Information Technology, Delhi, India), doing my engineering in Information Technology. My fields of interest are : # Game Development # ... |
| 06:15.31 | trepan | blast007: phaseII wasn't a gfx thing |
| 06:15.35 | blast007 | ah |
| 06:15.36 | trepan | s/wasn't/isn't/ |
| 06:16.09 | nsquare | blast: how can I contact the mentor of that project? Mr. Wollner? |
| 06:17.01 | nsquare | . |
| 06:17.02 | blast007 | http://sourceforge.net/users/wyk3d/ |
| 06:17.22 | blast007 | or idle on IRC and check for them to return tomorrow ;) |
| 06:18.02 | nsquare | cool. thanks :) |
| 06:18.07 | trepan | blast007: using the MsgLuaData[Fast] packet types to do the sim entirely in lua |
| 06:18.20 | blast007 | trepan: heh |
| 06:18.52 | trepan | server and client... |
| 06:19.33 | trepan | if nothing else, it might be a decent reference should one of the gsoc'ers want to take a whack at the same for c++ |
| 06:24.27 | *** join/#bzflag Wyk3d (n=middle@c7.campus.utcluj.ro) |
| 06:25.17 | blast007 | nsquare: ping ;) |
| 06:25.59 | nsquare | blast :) .. was just looking at some code :) |
| 06:26.15 | nsquare | i am pretty much interested in taking up this authentication module |
| 06:26.37 | blast007 | Wyk3d: hello |
| 06:27.09 | nsquare | oh hi wyk3d :) |
| 06:27.21 | blast007 | hehe, thus my ping |
| 06:28.28 | nsquare | :P |
| 06:34.18 | Wyk3d | blast007: hi |
| 06:36.44 | Wyk3d | did you try to do that crash ? |
| 06:37.32 | nsquare | hi wyk3d |
| 06:38.08 | blast007 | Wyk3d: yeah, but I got a different one this time |
| 06:38.42 | blast007 | http://pastebin.bzflag.bz/d4b4e881b |
| 06:41.02 | Wyk3d | btw if you do make backtraces you might as well use bt full for more info |
| 06:41.43 | nsquare | wyk3d: i am interested in taking up global authentication module for gsoc |
| 06:41.55 | Wyk3d | nsquare: me too ;) |
| 06:42.08 | nsquare | blast told me that you started it last summer :) |
| 06:42.22 | Wyk3d | yep |
| 06:42.39 | blast007 | Wyk3d: ah, didn't know about that |
| 06:43.49 | nsquare | wyk3d: do you have any specific project scope in mind or i need to come with with one in project proposal? |
| 06:44.20 | nsquare | as in, some work has been already done and i guess i need to go through that before deciding the scope |
| 06:44.52 | blast007 | Wyk3d: http://pastebin.bzflag.bz/d3f7c3e9d |
| 06:46.18 | Wyk3d | well the scope is .. getting it fully operational to deploying it |
| 06:46.24 | Wyk3d | *deploy |
| 06:46.59 | nsquare | ok |
| 06:47.03 | trepan | blast007: disp GameKeeper::Player::getPlayerByIndex(1) ? |
| 06:47.46 | blast007 | will that work from a core file? or do I need to run bzfs within gdb and crash it again? |
| 06:48.12 | blast007 | didn't output anything when I ran it |
| 06:48.27 | trepan | heh, tbh, never tried that using a core |
| 06:48.43 | blast007 | k |
| 06:48.48 | Wyk3d | i can only assume it should work but don't know really |
| 06:53.21 | *** join/#bzflag sumit (n=Administ@59.94.97.109) |
| 06:54.23 | nsquare | wyk3d: i'll go through the some parts of bzauthd code to have a clear idea of whats it doing and i'll get back to you if i have any doubts regarding the project proposal |
| 06:56.23 | blast007 | (gdb) disp GameKeeper::Player::getPlayerByIndex(1) |
| 06:56.23 | blast007 | 1: GameKeeper::Player::getPlayerByIndex (1) = (GameKeeper::Player *) 0x0 |
| 06:56.34 | blast007 | trepan: ^ |
| 06:56.47 | blast007 | (and apparently it doesn't work from a core file) |
| 06:56.54 | trepan | i guess we all figured that that would be the case (NULL) |
| 07:00.17 | *** join/#bzflag Supertanker (n=Arek@unaffiliated/supertanker) |
| 07:00.28 | trepan | blast007: you gonna commit the fix? |
| 07:01.04 | Supertanker | Huh. So this is the place I terrorized the first day ever on IRC. |
| 07:01.11 | Supertanker | Where's JeffM? |
| 07:02.53 | blast007 | trepan: is the fix just doing a null check in bzfs.cxx before trying to use netHandler? |
| 07:03.12 | trepan | that's what i've got coded ;-) |
| 07:03.50 | trepan | (there may be other problems, but it's a safe bet to add the check regardless) |
| 07:08.12 | trepan | i = curMaxPlayers + 1; // odd way to do a break :) |
| 07:08.43 | Supertanker | ""Emma just dont worry hes gone now we are safe but you must forget what you saw today since when you awoke at 7:00 AM to right now said a mother shaking and crying in fear"" |
| 07:08.52 | Supertanker | I think this person should be approved right now. |
| 07:08.55 | Supertanker | ... |
| 07:08.58 | Supertanker | This is the wrong channel. |
| 07:09.05 | Supertanker | ...this is the wrong computer, too. |
| 07:09.58 | CIA-11 | BZFlag: 03blast007 * r19502 10/trunk/bzflag/src/bzfs/bzfs.cxx: Sanity check against a null return value. |
| 07:10.19 | blast007 | trepan: does that fix seem right? |
| 07:10.27 | blast007 | I tested it and it didn't crash |
| 07:10.38 | trepan | ya, basically the same |
| 07:10.42 | blast007 | k |
| 07:11.07 | trepan | i ended up tweaking too much formatting in the surrounding code, probably better that you committed ;-) |
| 07:11.21 | blast007 | heh |
| 07:35.08 | Will07c5 | since we are supposed to submit a patch as part of the application process, are there any suggestions for a bug to fix or a small feature to implement? |
| 07:53.02 | blast007 | Will07c5: we have a BUGS file as well as a bugs tracker on SF.net |
| 07:53.11 | blast007 | see if you can reproduce and fix one of those |
| 07:53.45 | *** join/#bzflag sniper15_ (n=sniper15@S0106000d88e222e1.gv.shawcable.net) |
| 07:54.15 | Will07c5 | yeah I looked at that, I just wasn't sure which to choose |
| 07:54.39 | blast007 | if you know anything about Dead Reckoning, that's a bit buggy in trunk (specificaly in the Z direction, but maybe more than just that) |
| 07:54.54 | Will07c5 | I know what it is |
| 07:55.21 | Will07c5 | I'm a bit tired so I'll probably take a look at it tomorrow morning |
| 07:55.31 | blast007 | ok |
| 07:55.46 | blast007 | you'll notice it if you watch another player land from a jump |
| 07:55.59 | Will07c5 | ok thanks |
| 07:56.07 | blast007 | so either run two clients, or have someone else hop on a server ;) |
| 07:56.36 | Will07c5 | yeah I looked at the server list and there was nobody on :P |
| 07:57.34 | Will07c5 | can you run two clients on the same computer? |
| 07:58.01 | blast007 | yeah, though that would be tricky to make one jump and watch from the other |
| 07:58.18 | Will07c5 | I'll probably just set up another computer then |
| 07:58.51 | Will07c5 | thanks for the help :) |
| 07:59.08 | Will07c5 | time for me to sleep |
| 07:59.11 | Will07c5 | good night |
| 07:59.30 | trepan | blast007: that's not hard ... join one as an observer, and track the other |
| 08:00.05 | trepan | (windowed, both) |
| 08:00.07 | blast007 | right, but you'd have to make the other one jump, and then switch to the other client |
| 08:00.21 | blast007 | hmm |
| 08:00.31 | trepan | i make the real tank's window small |
| 08:00.33 | blast007 | suppose the Win32NoMin variable could be turned on |
| 08:01.09 | blast007 | assuming it's windows, at least |
| 08:01.24 | blast007 | linux doesn't automatically minimze the client when it loses focus? |
| 08:02.08 | trepan | nope, don't know what crazy minimiziness you speak of :) |
| 08:02.32 | blast007 | k :) |
| 08:19.18 | *** join/#bzflag sumit (n=Administ@59.94.97.109) |
| 08:20.30 | Constitution | blast007: or you could http://www.apple.com/getamac |
| 09:17.10 | nightstrike_ | is it compulsory to submit a patch as part of the application process? I didn't see it mentioned for BZFlag on the organisation profile? |
| 09:17.45 | Wyk3d | http://my.bzflag.org/w/Google_Summer_of_Code_Acceptance |
| 09:24.20 | nightstrike_ | how did i miss that??? :| |
| 09:24.21 | nightstrike_ | thanks! |
| 09:40.42 | *** join/#bzflag sumit1 (n=Administ@59.94.97.109) |
| 09:49.47 | nightstrike_ | as far as submitting a patch as per the application process, I'll be taking a step ahead with libgame and add some redundant code in src/bzflag and src/bzrobots to src/game. Is that ok? Because I don't think that's listed in the bug tracker |
| 09:50.55 | *** join/#bzflag QuantumT1m (n=tim@62.249.230.206) |
| 10:03.45 | *** join/#bzflag sumit (n=Administ@59.96.162.100) |
| 10:14.56 | *** join/#bzflag Upsetter (n=Ups@i577B6BEF.versanet.de) |
| 11:34.18 | *** join/#bzflag MPS_ (n=mathias@p57B241FA.dip0.t-ipconnect.de) |
| 11:38.11 | *** join/#bzflag sumit1 (n=Administ@59.96.162.100) |
| 11:39.10 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-001-091.ewe-ip-backbone.de) |
| 11:39.18 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-001-091.ewe-ip-backbone.de) |
| 11:43.03 | *** join/#bzflag Epyon (n=Epyon@static-78-8-146-214.ssp.dialog.net.pl) |
| 12:03.37 | *** join/#bzflag nightstrike_ (n=nightstr@210.212.97.141) |
| 12:17.46 | *** join/#bzflag leeguy92 (n=lee@host86-168-47-9.range86-168.btcentralplus.com) |
| 12:34.57 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 12:37.07 | *** join/#bzflag bwd (n=me@pdpc/supporter/student/bdotson) |
| 12:49.58 | *** join/#bzflag sumit (n=Administ@59.96.161.64) |
| 12:57.05 | *** join/#bzflag nightstrike__ (n=nightstr@210.212.97.141) |
| 12:58.08 | delusional | last night i was wondering why clearing the cache, both serverlist and download, did not work under version 2.99..... this morning I start up 2.0.x, and all the caches are cleared. |
| 13:40.26 | *** join/#bzflag nightstrike_ (n=nightstr@210.212.97.141) |
| 14:11.02 | *** join/#bzflag bz71 (n=bc172f97@bz.bzflag.bz) |
| 14:12.14 | *** join/#bzflag qwequ777 (n=stefan@188-23-47-151.adsl.highway.telekom.at) |
| 14:33.54 | *** join/#bzflag nightstrike_ (n=nightstr@210.212.97.141) |
| 14:58.50 | *** join/#bzflag TD-Linux (n=wheeeeee@96-42-68-26.dhcp.roch.mn.charter.com) |
| 15:01.13 | *** join/#bzflag sumit (n=Administ@59.94.96.109) |
| 15:02.01 | *** join/#bzflag donny (n=joevano@bzflag/developer/JoeVano) |
| 15:02.01 | *** mode/#bzflag [+v donny] by ChanServ |
| 15:07.43 | *** part/#bzflag sumit (n=Administ@59.94.96.109) |
| 15:09.35 | *** join/#bzflag Will07c5_ (n=William@c-67-173-127-196.hsd1.il.comcast.net) |
| 15:10.00 | *** part/#bzflag qwequ777 (n=stefan@188-23-47-151.adsl.highway.telekom.at) |
| 15:14.55 | *** join/#bzflag sumit (n=root@59.96.160.126) |
| 15:15.03 | *** part/#bzflag sumit (n=root@59.96.160.126) |
| 15:15.05 | *** join/#bzflag sumit (n=root@59.96.160.126) |
| 15:16.39 | CIA-11 | BZFlag: 03Optic Delusion 07http://my.bzflag.org * r5590 10/w/Talk:Map_Info%28object%29: Has not the "map info object" been implemented by trepan? Perhaps this page should be moved out of design proposals. |
| 15:26.02 | CIA-11 | BZFlag: 03*Boinkage*! 07http://my.bzflag.org * r5591 10/w/Flag_ideas: /* List of flag ideas to process to new fomrat: */ |
| 15:38.07 | *** join/#bzflag sumit (n=root@59.94.101.216) |
| 15:41.16 | sumit | is /trunk/bzflag/src/makefile.am the file which we need to make to run bzflag on a single machine |
| 15:44.12 | sumit | i am working on fedora 8 |
| 15:59.00 | blast007 | sumit: what do you mean? |
| 15:59.12 | blast007 | that's just a file that is part of the build system |
| 15:59.23 | *** join/#bzflag a_temp_dist (n=temp_dis@bzflag/serverop/TemporalDistraction) |
| 15:59.38 | sumit | well i want to compile the code, actually i wanted to test the bzrobots module |
| 16:00.15 | blast007 | read the README file :) |
| 16:00.38 | blast007 | "Compiling and Installation" |
| 16:01.24 | sumit | cool, got it... |
| 16:01.42 | jorgenpt | :-) |
| 16:03.53 | sumit | blast007: one more thing, i have some plans for the bzrobots project for gsoc, what is the way you guys prefer to read such a proposal, i am making a page on bzflag wiki regarding the same, i hope thats fine with the devs.. |
| 16:06.15 | blast007 | yeah, throw some info into your user page for that |
| 16:06.49 | jorgenpt | sumit: \o/ |
| 16:07.03 | blast007 | wiki user page* |
| 16:07.04 | sumit | sure, i would be adding personal info on my user page, as that would serve the purpose in a better way i suppose |
| 16:07.05 | jorgenpt | sumit: Feel free to post the link to the details in here. I'd love to hear about it. |
| 16:08.16 | sumit | jorgenpt: i am still in the middle of adding content to that page, actually i generally compile documentation stuff offline and then put them online, i would add stuff soon and get back to you with the link |
| 16:08.48 | sumit | i am using the username sumit on wiki |
| 16:10.06 | blast007 | k |
| 17:06.56 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 17:06.57 | *** mode/#bzflag [+v spldart] by ChanServ |
| 17:08.26 | *** join/#bzflag Tupone (n=Tupone@gentoo/developer/tupone) |
| 17:08.26 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 17:25.42 | CIA-11 | BZFlag: 03trepan * r19503 10/trunk/bzflag/ (13 files in 9 dirs): |
| 17:25.42 | CIA-11 | BZFlag: * changed some 'typedef struct {...} Tag;' to 'struct Tag {...};' |
| 17:25.42 | CIA-11 | BZFlag: * renamed the s64 types to i64 (in keeping with printf, scanf, etc...) |
| 17:25.42 | CIA-11 | BZFlag: * hid lua's bz.GetLight() from scripts without fullRead (reveals shot information) |
| 17:49.44 | *** join/#bzflag Carnage00 (n=carnage@dyn216-8-144-236.ADSL.mnsi.net) |
| 18:00.27 | CIA-11 | BZFlag: 03Sumit 07http://my.bzflag.org * r0 10/w/Special:Log/upload: uploaded "[[Image:UseCaseScenario-CodeModularization.png]]": This file is just for reference purposes for application for a proposal GSoc 09. |
| 18:00.51 | *** join/#bzflag BlasterWisconsin (n=blasterw@CPE-72-131-125-36.wi.res.rr.com) |
| 18:02.10 | *** join/#bzflag JeffM (n=Jeff@bzflag/projectadmin/JeffM) |
| 18:02.11 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 18:05.32 | Winny | so you guys got any good april fools stuff planned? |
| 18:06.11 | *** join/#bzflag Upsetter (n=Ups@i59F7C440.versanet.de) |
| 18:09.04 | JeffM | yeah we'll release |
| 18:11.26 | *** join/#bzflag me1 (n=ausom@bzflag/player/Me1) |
| 18:21.22 | CIA-11 | BZFlag: 03Sumit 07http://my.bzflag.org * r5593 10/w/Google_Summer_of_Code/2009/ideas/sumit: New page: == GSoc '09 Ideas == Hi, I am Sumit. I have ideas to work on BZ Robots project and the Code Modularization project. I am posting my ideas regarding both of them, it would be great to hear... |
| 18:24.37 | JeffM | wtf? |
| 18:29.47 | delusional | maybe he should keep that on a :User page? |
| 18:29.58 | JeffM | probably |
| 18:32.06 | blast007 | which is what I had suggested... |
| 18:32.10 | blast007 | 11:06:14 <+blast007> yeah, throw some info into your user page for that |
| 18:32.27 | blast007 | probably wasn't specific enough |
| 18:32.32 | CIA-11 | BZFlag: 03Sumit 07http://my.bzflag.org * r5594 10/w/Google_Summer_of_Code/2009/ideas/sumit: |
| 18:33.46 | blast007 | and of course he signed off IRC now.. |
| 18:34.48 | JeffM | really that stuff should go into his application |
| 18:35.08 | blast007 | k, wasn't sure |
| 18:35.16 | blast007 | thought we had them put it on the wiki first last year |
| 18:36.34 | JeffM | IIRC wasn't it after they were accepted and we wanted them to flesh out there plans that it was wiki |
| 18:36.42 | blast007 | maybr |
| 18:36.43 | JeffM | may be misremembering |
| 18:36.45 | blast007 | maybe* |
| 18:37.10 | blast007 | nah, I'm probably wrong |
| 18:37.20 | JeffM | I should show you the WONDERFULL PM I got to day |
| 18:38.02 | JeffM | http://pastebin.bzflag.bz/m65003916 |
| 18:38.08 | JeffM | you know, just a simple question :) |
| 18:40.39 | CIA-11 | BZFlag: 03Sumit 07http://my.bzflag.org * r5595 10/w/User_talk:Sumit: New page: == GSoc '09 Ideas == Hi, I am Sumit. I have ideas to work on the Code Modularization project and the BZ Robots project. I am posting my ideas regarding both of them, it would be great to ... |
| 18:40.48 | CIA-11 | BZFlag: 03Sumit 07http://my.bzflag.org * r5596 10/w/Google_Summer_of_Code/2009/ideas/sumit: Removing all content from page |
| 18:41.30 | delusional | looks like he didnt like it either. |
| 18:41.49 | *** join/#bzflag sumit (n=root@59.94.106.241) |
| 18:42.06 | JeffM | that stuff should go in your application sumit |
| 18:42.14 | JeffM | or your user page, not a page in the wiki proper |
| 18:42.18 | blast007 | hi sumit, I was wrong about doing it on the wiki |
| 18:43.00 | sumit | JeffM : I have added the contents on my user page |
| 18:43.05 | JeffM | k |
| 18:43.15 | sumit | and have removed that info from that page |
| 18:43.21 | JeffM | but really that's stuff for your app, not realy a colaborative thing yet |
| 18:43.34 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@bzflag/contributor/SpazzyMcGee) |
| 18:43.37 | JeffM | we use the wiki after you are chosen to flesh out your deisgn with the rest of the developers |
| 18:43.48 | sumit | okay |
| 18:44.31 | JeffM | the application part has to come from just you :) |
| 18:44.49 | sumit | well i discussed about doing so here, and i got a green flag, so i went ahead with it, if you want i can host that stuff somewhere else even, or say send a mail to the conccerned mentors regarding the same |
| 18:44.58 | JeffM | and just so you know, our intent for that idea, was not to redesign the internals of bzflag |
| 18:45.04 | JeffM | but simply to move the code around |
| 18:45.17 | JeffM | a 'doc' in an online network game dosn't really make much sense |
| 18:45.45 | JeffM | we do our design discussions here mostly |
| 18:45.48 | nightstrike_ | may I know who'll be the potential mentor for the libgame project? There's a lot I'd like to discuss! |
| 18:45.51 | JeffM | people arn't going to "just look at the wiki" |
| 18:45.59 | JeffM | nightstrike_: all of us |
| 18:46.02 | JeffM | we mentor as a team |
| 18:46.26 | sumit | okay.. |
| 18:46.32 | JeffM | and you all should note, that libgame is going to be one of the popular ones, so it's best if you submit more then one idea |
| 18:46.40 | JeffM | it's also one of the harder ones |
| 18:47.47 | nightstrike_ | ok, first of all, I'd like to know what exactly the developers have in mind when it comes to the libgame project. I've been going through the source since the last couple of days, and I've found several instances of code that has been duplicated. Does the project involve merely moving all this code into libGame, or is there something else also at hand? |
| 18:47.51 | JeffM | for a code reorg proejct, personaly I feel the seperation of the graphics code is easier, since its' easy to tell what is graphics code, and not as easy to tell what is "game code" |
| 18:48.03 | nightstrike_ | exactly! |
| 18:48.08 | JeffM | nightstrike_: that could be part of it |
| 18:48.22 | JeffM | the final goal would be to have a lib that can represent an entire gamestate |
| 18:48.41 | JeffM | basicly somethign that can know where every player is, what the score is, how everyone is suposed to move, etc.. |
| 18:48.53 | JeffM | then we can use that lib in both the server and the client to represent the game state |
| 18:48.56 | nightstrike_ | so we move code revolving around game scores, number of players etc to libGame as well |
| 18:49.01 | nightstrike_ | ok, yes |
| 18:49.06 | JeffM | that lib should not be dependent on any drawing or netowrking code |
| 18:49.23 | JeffM | personaly I'd like to see lib game broken into 2 parts |
| 18:49.24 | nightstrike_ | so in a way, this would help the cheat prevention folks as well? |
| 18:49.34 | JeffM | libGameState, and libGameLogic |
| 18:49.42 | nightstrike_ | hmmm... |
| 18:49.45 | JeffM | nightstrike_: it would be part of the start for some cheats |
| 18:49.46 | JeffM | yes |
| 18:49.53 | JeffM | since we'd have more info on the server |
| 18:49.57 | nightstrike_ | exactly |
| 18:50.15 | JeffM | but it, in itself is not any sort of complete cheat solution |
| 18:50.31 | nightstrike_ | yes, but it certainly would help |
| 18:50.31 | JeffM | LibGameState should be able to track where everyone and everything is |
| 18:50.44 | JeffM | the gameLogic should have the responses to events |
| 18:50.55 | JeffM | how shots move, what flags do, etc.. |
| 18:51.08 | nightstrike_ | so things like players online, scores go into GameState and stuff like Shots, Tanks and game physics in general go to GameLogic? |
| 18:51.09 | JeffM | then it could be very easy to replace the game logic for different game modes etc.. |
| 18:51.50 | nightstrike_ | nice... |
| 18:52.32 | JeffM | if the game logic seperate, and the graphic stuff is done, then all that's left in the application is a very lightweight shell that gets input/networking and does some basic OS stuff. |
| 18:52.44 | JeffM | our final goal is to make the client as stupid as possible |
| 18:52.58 | nightstrike_ | ok, I understand |
| 18:53.30 | delusional | the deadline is april 3, you have time to put an application together. http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline |
| 18:53.49 | JeffM | I highly recomend multiple apps from students |
| 18:54.08 | JeffM | we had some dupes last year who only turned in one app, so we had to turn away some good people |
| 18:54.36 | JeffM | anyone who is looking to do the game logic project should also apply for the graphic code clean up one as well |
| 18:54.41 | JeffM | since they are so very simial |
| 18:54.44 | *** join/#bzflag elad01 (n=they@void-59.cs.huji.ac.il) |
| 18:54.55 | sumit | JeffM : Regarding the reorganization thing, I don't plan to change the basic architecture of the game, or say a recode, we would just have to organize the things in such a way that they don't mingle with each others work, it would be basically a shifting of code and linking everything |
| 18:55.21 | JeffM | sumit: then that would not be a model view controller system ;) |
| 18:55.41 | nightstrike_ | so what would be a reasonable list of deliverables for this project? 1) Splitting libGame into libGameLogic and libGameState and, 2) Refactoring redundant code in the 3 clients and adding them to LibGame___... be fine? |
| 18:55.54 | sumit | well, whats your perspective about the project |
| 18:56.04 | JeffM | sumit: I just said it all ;) |
| 18:56.34 | JeffM | nightstrike_: I doubht you'd get to all of those, but yes that would sound like a decent deliveralble |
| 18:57.04 | nightstrike_ | great! |
| 18:57.08 | JeffM | if at the end of SOC we have a lib that only the main client uses, that'd be fine by me. as hooking it up to the other clients would be a simple task |
| 18:57.23 | JeffM | we've had some problems with projects having too many goals |
| 18:57.24 | nightstrike_ | which is src/bzflag right? |
| 18:57.41 | JeffM | so don't worry about finishign early and not having anything to do, we'll put you to work ;) |
| 18:57.47 | JeffM | most of the code is in that dir yes |
| 18:58.00 | JeffM | tho a lot of that is shared by bzadmin and bzrobots |
| 18:58.03 | nightstrike_ | one more thing, although I've seen several instances myself, may I know how bad the extent of redundant code is right now? That'll help me decide on the deliverables :) |
| 18:58.04 | JeffM | in a very crappy way |
| 18:58.24 | JeffM | we don't really know |
| 18:58.39 | nightstrike_ | hehe, so hence the project :) |
| 18:58.41 | JeffM | bzrobots and bzadmin actualy pull in a number of files from bzflag |
| 18:58.49 | JeffM | but they also duplicate some code as well |
| 18:59.13 | nightstrike_ | some functions are literally copy pasted btwn bzflag and bzrobots :| |
| 18:59.20 | JeffM | generaly they duped the code when it was eaiser then fixing bzflag's code to be less dependent on drawing and stuff |
| 18:59.22 | JeffM | yeah |
| 18:59.45 | JeffM | usualy when the client code had stuff in the same file that didn't exist in the bzadmin or robots codebases |
| 19:00.00 | *** join/#bzflag MPS_ (n=mathias@p3EE0C171.dip.t-dialin.net) |
| 19:00.06 | nightstrike_ | ok |
| 19:00.07 | JeffM | the server generaly has it's own set of logic classes for things because it initaly didn't do much |
| 19:00.22 | JeffM | so it has some duplicated functionality, but writen in a different, and sometimes better way |
| 19:00.30 | nightstrike_ | but now the idea is to strengthen it right? |
| 19:00.31 | JeffM | since it dosn't have to deal with local players |
| 19:00.50 | JeffM | the idea is to have something that dosn't depend on WHERE it is, so that everyone can use it |
| 19:01.01 | nightstrike_ | okies |
| 19:01.02 | JeffM | and like bzadmin would not use the game logic lib |
| 19:01.04 | JeffM | cus it has no logic |
| 19:01.07 | nightstrike_ | yep |
| 19:01.14 | brlcad | blast007: not a bad idea, just wasn't a user page :) |
| 19:01.17 | JeffM | bzrobots would use game state and game logic but not application and dispaly |
| 19:01.24 | JeffM | the main client woudl use all of them, etc... |
| 19:01.28 | nightstrike_ | bzflag would use em all |
| 19:01.29 | nightstrike_ | yes... |
| 19:01.54 | JeffM | server would use a logic class with lots of hooks for API events, etc.. |
| 19:01.55 | nightstrike_ | I'm currently charting out my application now, when I'm done, may I mail it to you for a review? |
| 19:02.28 | JeffM | I'd just submit it, you can edit your application after you submit |
| 19:02.34 | JeffM | and all mentors can comment on it |
| 19:02.40 | nightstrike_ | ok, thanks |
| 19:02.45 | JeffM | applications are VERY much iterative projects |
| 19:02.55 | JeffM | we do dislike last min. applications |
| 19:03.32 | nightstrike_ | ok, I've read about a lot of gsoc students experiences on how they've got their apps reviewed several times before the final submission |
| 19:03.42 | nightstrike_ | and may I have some info on the n/w testing and simulation environment project? |
| 19:03.43 | JeffM | yeah we do that a lot |
| 19:03.50 | JeffM | but we do it inside the scope of the application |
| 19:03.59 | JeffM | some projects just want a "perfect app" at the end |
| 19:04.11 | JeffM | but that's cus they have like 150 students and 25 mentors |
| 19:04.16 | JeffM | we are a LOT smaller |
| 19:04.18 | nightstrike_ | gasps |
| 19:04.24 | JeffM | we expet to have 2 students |
| 19:04.45 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 19:05.24 | nightstrike_ | but the idea of contributing to a game sounds great! I'll be giving it everything I got... |
| 19:05.29 | JeffM | and the big thing for us is comunication |
| 19:05.38 | JeffM | because we expect your project to be done interactivly |
| 19:05.45 | JeffM | not you go off, do it, and give us a code dump |
| 19:05.55 | nightstrike_ | yes, I understand |
| 19:06.10 | Will07c5 | hey, if we should submit multiple applications I might also be interested in improving the world editor |
| 19:06.26 | Will07c5 | so what is the current status of the world editor? |
| 19:06.31 | JeffM | you should fully expect that other developers will be changing the codebase (your code included) during the project |
| 19:06.41 | nightstrike_ | yes |
| 19:06.43 | JeffM | Will07c5: it compiles on some OSs ;) |
| 19:07.05 | nightstrike_ | and what about the network testing aand simulation environment project? |
| 19:07.05 | Will07c5 | what does 'some' include? :P |
| 19:07.10 | JeffM | but it has the basic framwork, file readers, most of the ojbects are supported, and a REALLY crapy UI |
| 19:07.26 | JeffM | nightstrike_: some way to simulate lag/packetloss and report on postions and stuff |
| 19:07.27 | Winny | speaking of world editor, has anyone seen jude- recently? |
| 19:07.30 | JeffM | IMHO not that important |
| 19:07.42 | nightstrike_ | wow! that sounds real interesting |
| 19:08.07 | nightstrike_ | oh, but it's listed as high priority :| |
| 19:08.18 | JeffM | Will07c5: what I'd like to see for that is the rest of the objects suported, the OSG sceenegraph optimised somewhat, and a good UI made |
| 19:08.26 | JeffM | the UI being the most important |
| 19:08.39 | JeffM | nightstrike_: it was by the developer that wrote the wiki page :) |
| 19:08.50 | JeffM | personaly I feel the world editor is a high priority |
| 19:09.03 | Will07c5 | JeffM: so what ui library would I be using, qt, gtk, wxwidgets, etc? |
| 19:09.12 | JeffM | it uses FLTK right now |
| 19:09.21 | JeffM | and that works |
| 19:09.33 | Will07c5 | googles it |
| 19:09.45 | JeffM | you could stick with that, or change, but you'd have to be able to explain why the change, and what the benifits of the new would be etc.. |
| 19:09.55 | JeffM | I'm not against changing, it just adds some more work |
| 19:10.15 | JeffM | FLTK ain't that great, but it's pretty simple and it generaly builds on all the OSs we care about |
| 19:10.17 | Will07c5 | ok I'd have to take a closer look before knowing if changing would be a good idea or not |
| 19:10.23 | JeffM | yeah |
| 19:10.41 | JeffM | so basicly the app framework IS there, and it does do something |
| 19:10.43 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 19:10.43 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 19:10.53 | nightstrike_ | quite a lot of cheats listed in the 'known cheats' section :| |
| 19:11.02 | blast007 | nightstrike_: and that's just a small list |
| 19:11.16 | Will07c5 | I'd probably want to get some feedback from the community on what they want in a UI |
| 19:11.24 | nightstrike_ | it's categorized as high priority as well |
| 19:11.38 | JeffM | nightstrike_: you can pretty much do anything you want, most of the logic is done on the client |
| 19:11.45 | JeffM | hence why libGame is somewhat important |
| 19:11.56 | nightstrike_ | hmmm... |
| 19:12.00 | JeffM | I don't belive the "game cheat" project can even start untill we have a good server state |
| 19:12.06 | nightstrike_ | yes |
| 19:12.12 | nightstrike_ | i was about to ask that |
| 19:12.38 | JeffM | in our trunk code, the server is trying to track more stuff, but again it's a duplicate of similar logic in the client |
| 19:12.45 | JeffM | but it's nowhere complete |
| 19:12.50 | JeffM | like the server dosn't even know where shots are |
| 19:13.17 | JeffM | there was some work done last year on making the shot interface be it's own code that could be used on the client and server |
| 19:13.27 | JeffM | that code would be very useufll in the libGame project |
| 19:13.37 | JeffM | since shot paths are a large part of the game |
| 19:13.52 | nightstrike_ | yeah, I saw some code relating to that |
| 19:14.10 | JeffM | there are techincaly 2 branches that do that |
| 19:14.13 | JeffM | the one from SOC last year |
| 19:14.16 | JeffM | and my own |
| 19:14.23 | JeffM | mine is all jacked up tho :) |
| 19:14.25 | nightstrike_ | :) |
| 19:14.25 | JeffM | I went too far |
| 19:15.02 | nightstrike_ | so the network testing one aint that important eh? :( |
| 19:15.03 | JeffM | the final goal of lib game will have to get where my branch tried to go, but it'll have to do it in baby steps |
| 19:15.10 | JeffM | depends who you talk to |
| 19:15.19 | JeffM | if we had it, it would help with some problems we have |
| 19:15.40 | JeffM | but when compared to other things, my opinion is that it's not that important |
| 19:15.45 | nightstrike_ | yeah |
| 19:15.54 | JeffM | it too would be easier after the game lib was busted up |
| 19:16.07 | JeffM | cus then you could use libState to be a tool for where people are, etc.. |
| 19:16.17 | nightstrike_ | the bug fixes and both the modularization projects will help you in getting out a good version 3.0 I guess |
| 19:16.25 | JeffM | yes |
| 19:16.32 | nightstrike_ | hence, the priority |
| 19:16.35 | JeffM | the world editor will help the most number of people |
| 19:16.43 | JeffM | even players of the current version |
| 19:17.53 | elad01 | hi all! |
| 19:17.53 | nightstrike_ | the GUI design in question would be similiar to the way you've designed the menus in the game? |
| 19:18.14 | JeffM | oh god no |
| 19:18.17 | nightstrike_ | or are we talking about something like gtk? |
| 19:18.27 | JeffM | are you talking about the editor? |
| 19:18.30 | nightstrike_ | yeah |
| 19:18.31 | JeffM | or somethign else? |
| 19:18.38 | JeffM | oh yeah, it should be a REAL application |
| 19:18.49 | nightstrike_ | the editor... (forgive the silly question) |
| 19:18.50 | JeffM | our game menus are horrible |
| 19:19.01 | JeffM | and would suck for antyhing other then "pick this thing from a list" |
| 19:19.09 | brlcad | nightstrike_: the networking testing isn't as immediately important -- but if someone had a solid idea and plan for it, it's still something we could immediately use for testing and even code restructuring work |
| 19:19.22 | JeffM | part of that project would be coming up with a good UI pardigm for editing objects |
| 19:19.37 | JeffM | like having 3d widgets that you could grab on objects to move/scale them |
| 19:19.47 | JeffM | and interface dialogs to set properties, etc.. |
| 19:20.00 | JeffM | basicly it's making the interface to something like a 3d modeler |
| 19:20.00 | elad01 | I need to write a review about your opensource project for my university, can someone sum up the main features in the project? |
| 19:20.01 | brlcad | since moving a lot of code out of the server and client into libgame has a lot of potential to get jacked up in network state, being able to test and inspect the network and harness it becomes useful |
| 19:20.14 | JeffM | elad01: you shoot people and they blow up |
| 19:20.24 | brlcad | elad01: which university? |
| 19:20.29 | elad01 | huji |
| 19:20.41 | elad01 | http://www.huji.ac.il |
| 19:20.43 | nightstrike_ | perhaps I'll work on the network testing thing if I don't get selected... |
| 19:21.04 | nightstrike_ | JeffM: nice one! |
| 19:21.06 | JeffM | elad01: have you played the game? |
| 19:21.23 | brlcad | elad01: have you played the game before -- best to just play on a variety of servers, you'll get the idea pretty quickly |
| 19:21.48 | JeffM | well I should clarify, you shoot people and they may or may not blow up ;) |
| 19:21.51 | elad01 | JeffM: no, I had no time for it yet. and I can't install it here... |
| 19:22.08 | JeffM | then your review will be very dificult |
| 19:22.25 | JeffM | one should use the thing they are going to review, anything else is just writing down lies |
| 19:22.55 | elad01 | JeffM: I need to review the development project, not the game |
| 19:23.04 | JeffM | ahh |
| 19:23.20 | JeffM | what should be interesting :) |
| 19:24.14 | JeffM | what kind of "features" are you looking for then? |
| 19:24.34 | *** join/#bzflag sumit (n=root@59.94.97.121) |
| 19:26.12 | elad01 | JeffM: what features the project is made of, like, (I guess): 3d graphic libs using openGL, game UI, game server, low-level os based code, translations to many languages |
| 19:26.47 | JeffM | they don't want you to research that yourself? |
| 19:26.54 | JeffM | we use open GL |
| 19:27.00 | JeffM | we have a number of translations |
| 19:27.00 | brlcad | check out the source code |
| 19:27.10 | JeffM | I'm not sure what you are looking for about the rest |
| 19:29.37 | elad01 | JeffM: lets say you write in your CV about this project and the things in it, so you will get a good developer job. what will you write about the features in it? |
| 19:30.31 | JeffM | I'd only put my involvement in it |
| 19:30.47 | JeffM | and what I did on it |
| 19:31.00 | JeffM | I think you need to be asking more specific questions |
| 19:31.19 | JeffM | if your intenet is to interview the developers of the project about the project |
| 19:31.33 | brlcad | and having a more specific goal/focus |
| 19:31.39 | JeffM | indeed |
| 19:32.06 | JeffM | it's like you are asking "What are the features of this cake", but you've never seen a cake |
| 19:32.07 | JeffM | ;) |
| 19:32.27 | JeffM | and the baker just says "it's a cake, and it's umm... round" |
| 19:33.15 | JeffM | when what I think you want to know is more about how he made the cake, then the 'features' of the cake ;) |
| 19:35.06 | JeffM | for a starter, I think you should read the project history on the wiki |
| 19:35.13 | JeffM | that would give you a good idea of where the project game from |
| 19:35.23 | JeffM | and may help you make some better questions |
| 19:39.41 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 19:44.59 | sumit | hey, what does the Face object doing in the code |
| 19:45.27 | *** join/#bzflag bier (n=bier@p54A55BC6.dip.t-dialin.net) |
| 19:45.46 | JeffM | represents the face of a mesh |
| 19:45.51 | sumit | it has referrences in /bzflag/src/obstacle/meshFace.cxx |
| 19:45.57 | JeffM | yeah |
| 19:46.10 | JeffM | think of it as one triangle in a mesh |
| 19:46.14 | sumit | what do you mean by the "face of a mesh" |
| 19:46.21 | JeffM | think of a cube |
| 19:46.25 | sumit | ok |
| 19:46.25 | JeffM | one "side" of the cube is a face |
| 19:46.37 | sumit | ah, okay... |
| 19:46.43 | JeffM | a mesh is made up of a collection of faces |
| 19:46.48 | sumit | now what does the cube represents here |
| 19:47.00 | JeffM | an object in the world |
| 19:47.09 | sumit | oh, got it... |
| 19:47.29 | JeffM | that's going to be one of the harder things for the game/drawing split |
| 19:47.34 | sumit | u mean to say that every 3d object is in the world is a mesh |
| 19:47.40 | JeffM | getting obstacles to be handled independetly of there drawing |
| 19:47.46 | JeffM | no |
| 19:47.46 | sumit | and it is defined by faces |
| 19:47.49 | JeffM | we have some other primtives |
| 19:47.53 | JeffM | mesh is just one type of object |
| 19:48.00 | sumit | okay... |
| 19:48.03 | JeffM | we have boxes, pyramids, etc.. |
| 19:48.18 | JeffM | the mesh is just the final "catchall" object as you can define any object as a mesh |
| 19:48.22 | JeffM | any shape I mean |
| 19:49.39 | sumit | okay, so u want to say that suppose, the 3d object of a tank can be represented by a mesh, which constitutes of certain faces, but a bomb can be represented by an object of a sphere |
| 19:49.51 | JeffM | no tanks are not world objects |
| 19:49.59 | sumit | okay.. |
| 19:49.59 | JeffM | world objects are just static things in the world |
| 19:50.01 | JeffM | buildings, etc.. |
| 19:50.08 | sumit | okay... |
| 19:50.16 | JeffM | tanks and shots are special things that move in the world |
| 19:50.28 | JeffM | they are not part of the static scenegraph |
| 19:50.36 | JeffM | but added every frame when they move |
| 19:50.43 | sumit | something, like sprites in pygame |
| 19:50.46 | JeffM | the drawing for the tank is hardcoded in the geometry project |
| 19:50.49 | JeffM | yeah kinda |
| 19:50.52 | sumit | okay |
| 19:51.03 | JeffM | for collisions the tanke uses a modified cylinder |
| 19:51.08 | JeffM | ish |
| 19:52.00 | JeffM | tho I did write the avatar manager, so I guess I did start spliting out tank drawing ;) |
| 19:52.14 | JeffM | that should make that part simpler |
| 19:52.22 | delusional | ... i ws gonna say. |
| 19:52.31 | JeffM | well I disabled all that |
| 19:52.34 | JeffM | but the code is still there |
| 19:52.47 | JeffM | it just uses the hardcode geometry by default |
| 19:53.01 | sumit | avatar manager, does it enables a player to define his own tank |
| 19:53.10 | JeffM | brlcad: do you now if there is a C# interface or implementation to FTGL? |
| 19:53.12 | sumit | in terms of dimension or looks |
| 19:53.23 | JeffM | sumit: that was the eventual goal |
| 19:53.33 | sumit | okay... |
| 19:53.36 | JeffM | allowing tanks to be defined as external models, and giving people options |
| 19:54.55 | sumit | and which module defines/computes the dimensions of the cylinder for collision detection (i suppose, it would be using some approximations) |
| 19:55.17 | JeffM | obstacle does most of that |
| 19:55.28 | JeffM | tho tank/shot collisions are done elsewhere IIRC |
| 19:55.37 | sumit | as defining perfect collision detection is generally neither feasable nor recommended |
| 19:55.55 | sumit | IIRC ? |
| 19:55.57 | JeffM | IIRC LocalPlayer has the tank collision stuff |
| 19:56.03 | JeffM | If I Recall Correctly |
| 19:56.04 | sumit | okay... |
| 19:56.09 | sumit | lemme check.. |
| 20:03.39 | brlcad | jjeyes, http://trac.geekisp.com/bleep/wiki/FTGLSharp |
| 20:03.49 | brlcad | er, JeffM yes |
| 20:04.57 | JeffM | saw that, needs a moded ftgl tho |
| 20:05.01 | JeffM | ponders |
| 20:07.32 | sumit | JeffM : It might be very idiotic question but what part of the code is on the client side and what part of it is on the server side |
| 20:07.54 | sumit | i think things like collision detection etc should be on the server side |
| 20:08.13 | brlcad | sumit: src/bzflag is client and src/bzfs is server |
| 20:08.17 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 20:08.27 | brlcad | logic-wise, though, much is shared or sharable |
| 20:08.41 | sumit | okay... |
| 20:09.12 | sumit | well it seems that most of the logical part of it is on the client side.... |
| 20:09.42 | brlcad | presently, almost all of the logic is on the client |
| 20:09.48 | sumit | or maybe i need to check out the server side code properly :) |
| 20:09.51 | sumit | okay.... |
| 20:10.15 | brlcad | that's part of the project and work needed is to abstract out the "game" aspect that is mostly in the client right now |
| 20:10.29 | brlcad | that the part that needs to get moved into libgame |
| 20:10.39 | sumit | okay... |
| 20:11.05 | brlcad | I'm gathering that "okay..." really means "I don't know what the hell you just said, but .. okay..." |
| 20:11.56 | sumit | well that makes sense, having multiple clients doing computation isnt good, rather than making only the server side doing the computations, would lead to efficiency |
| 20:12.06 | sumit | brlcad: its not like that |
| 20:12.30 | sumit | its just that, i will take some time to learn about the code architecture |
| 20:12.35 | brlcad | the idea isn't just to get the server to do the computations -- it's to abstract the logic from the networking and graphics |
| 20:12.38 | sumit | or bzflag |
| 20:12.47 | sumit | okay... |
| 20:12.59 | brlcad | there again with the "okay..." :) |
| 20:13.11 | sumit | ah!! |
| 20:13.14 | brlcad | properly abstracted, it should be easier to maintain a game state in the server if needed |
| 20:13.21 | brlcad | (and it is needed) |
| 20:14.55 | sumit | well, its like, i came up with an idea of organizing the code structure in a form of an mvc model, which was dumped to a certain extent as it would require a lot of recode, although i too am not in the favor of a strict mvc model, as that is generally not possible |
| 20:15.18 | sumit | but trust me thats where the two projects of modularization lead to.. |
| 20:15.39 | sumit | abstracting graphics and game logic, would mean that only to a certain extent |
| 20:15.55 | brlcad | even in mvc terms, the brunt of the work is separating out the v |
| 20:16.07 | sumit | okay... |
| 20:16.20 | brlcad | okay... |
| 20:16.25 | brlcad | that's a bad habit |
| 20:16.40 | sumit | ah!! i will try and remove that |
| 20:17.56 | sumit | well but dont you think that it would make sense if we could transfer a major chunk of view and model to the server side and make client as view with a minimal controller |
| 20:18.09 | sumit | and a network interface module |
| 20:18.50 | sumit | although i would have to study about the feasability of such a thing with the current code base |
| 20:19.20 | Will07c5 | ok I'm having trouble getting bzworkbench to compile, I get message "Error 190fatal error C1083: Cannot open source file: '..\..\osrc\bjects\weapon.cpp': No such file or directoryc1xx" which seems simple enough, but the compiler refers to a file "c1xx" as the culprit but this file doesn't seem to exist! |
| 20:19.34 | Pimpi | the idea if libgame is to have the stuff wherever we need it, no? wether client or server, it's available. |
| 20:19.43 | brlcad | I wouldn't be so focused on slapping mvc labels onto the restructure design as there are various components in play, hierarchy of interfaces all with potential mvc aspects |
| 20:21.35 | Pimpi | Carnage00: ping |
| 20:21.40 | brlcad | sumit: more immediate to what we need is simply getting the logic we have that construes a game into libgame, separated from all networking and graphics code .. regardless of whether it's presently in the client, other clients, or the server |
| 20:23.02 | brlcad | so there are plenty of useful projects that can break up that work -- working on cleanly/fully separating the networking, or the graphics, or the game aspects themselves |
| 20:23.26 | brlcad | the networking is mostly separated now (but not entirely) |
| 20:23.32 | brlcad | the graphics is really easy to identify and separate |
| 20:23.38 | sumit | okay, so you mean that game logic is related to things like, position of tanks, bombs,scores of players, computations regarding collision detection etc and you want to abstract it into libgame module |
| 20:23.46 | brlcad | yes |
| 20:24.13 | *** join/#bzflag Think_Differentl (n=fatass@bzflag/player/ThinkDifferent) |
| 20:24.27 | brlcad | everything I might need to "simulate a game of bzflag" |
| 20:24.56 | sumit | okay, say a type of non graphics version |
| 20:25.04 | sumit | a terminal version |
| 20:25.21 | sumit | actually i have worked on something like that earlier |
| 20:26.02 | sumit | it might be of some interest to you : http://code.google.com/p/ai-challenge/ |
| 20:26.05 | brlcad | yeah, you could trivially make a terminal version if it was done like that |
| 20:26.18 | brlcad | or a stand-alone bzflag client, or server-side game state, etc |
| 20:26.46 | sumit | ah!! now i cant write okay |
| 20:27.10 | sumit | as it has been black listed :) |
| 20:27.44 | Will07c5 | nevermind my question I think I just figured out what is wrong |
| 20:30.16 | Will07c5 | there was a typo in the vcproj file in case anyone was wondering |
| 20:30.28 | JeffM | Will07c5: what project? |
| 20:30.36 | JeffM | and what code branh? |
| 20:30.45 | Will07c5 | BZWorkbench.vcproj |
| 20:30.53 | Will07c5 | and trunk I think |
| 20:30.55 | JeffM | ahh, that does not suprise me :) |
| 20:31.04 | JeffM | it was initaly done on linux |
| 20:31.14 | JeffM | and I didn't keep the windows stuff up to date |
| 20:31.34 | Will07c5 | yeah usually I use linux |
| 20:31.55 | Will07c5 | but my laptop has windows and I couldn't take my desktop home for spring break |
| 20:32.03 | JeffM | ponders just porting ftgl texture font to pure C# |
| 20:32.31 | sumit | brlcad : well if we see it in some way, isnt it someway related, if we separate the game logic from the code base into libgame, wouldn't the graphics portion be separated automatically |
| 20:32.48 | JeffM | sumit: no there is more then just game and graphics |
| 20:33.00 | JeffM | there is networking, and input, and the OS specific stuff |
| 20:33.12 | sumit | right... |
| 20:33.22 | sumit | but that stuff is almost seperated only |
| 20:33.24 | JeffM | there is LESS left, that is for sure |
| 20:33.30 | JeffM | not totaly |
| 20:33.37 | JeffM | platform stuff is still mixed in a lot of places |
| 20:33.41 | JeffM | as is input |
| 20:33.51 | JeffM | but some of it has been started that's for sure |
| 20:33.53 | brlcad | sumit: yeah, they're *very* intertwined projects |
| 20:33.59 | brlcad | it's more how you approach the separation |
| 20:34.08 | brlcad | that's why working on separating the logic is a nice contained piece of it |
| 20:34.13 | brlcad | er, graphics logic |
| 20:34.39 | brlcad | makes separating the game logic a lot more obvious, whereas attacking the game logic by itself is a lot more intertwined |
| 20:34.42 | JeffM | graphics will be easier to seperate, cus it's simpler to tell if the code in question DRAWS |
| 20:34.56 | sumit | right... |
| 20:35.47 | sumit | but it would be cumbersome to classify the code as game logic or not, as after seperating them one would have to check if it could be related to where it is to be used |
| 20:36.17 | JeffM | that would be one of the more dificult parts of the proejct, sure |
| 20:36.28 | brlcad | it's generally not to hard to identify, it's just harder to decouple |
| 20:36.30 | JeffM | it means you have to understand what the code does before you split it ;) |
| 20:36.39 | sumit | right... |
| 20:36.44 | brlcad | sumit: heh, so have done from "okay..." to "right..."? :) |
| 20:37.07 | JeffM | there may also be different ways to implement the code that would allow better decoupling |
| 20:37.13 | brlcad | s/done/gone/ |
| 20:37.17 | sumit | one would be required to understand that what all stuff(variables) that code requires and how much of it can be made globally available |
| 20:37.44 | brlcad | yes, and that can get messily intertwined |
| 20:38.11 | sumit | brlcad : it seems you are against usage of "single word" lines |
| 20:38.33 | sumit | well, it is generally tricky to do such a thing |
| 20:53.41 | *** part/#bzflag sumit (n=root@59.94.97.121) |
| 20:53.45 | *** join/#bzflag sumit (n=root@59.94.97.121) |
| 20:55.07 | *** join/#bzflag Wyk3d (n=middle@c7.campus.utcluj.ro) |
| 20:55.07 | brlcad | sumit: not so much single word lines as statements that are repetitive and really convey nothing useful |
| 20:55.44 | brlcad | it's not at all tricky unless you've picked up the habit of vocalizing and typing what that internalization |
| 20:56.01 | brlcad | s/what// |
| 20:56.27 | sumit | well i mentioned the tricky thing about abstracting the game logic |
| 20:56.31 | brlcad | it's like the folks that type "wait" all the time |
| 20:56.33 | brlcad | wait |
| 20:56.37 | brlcad | what do you mean? |
| 20:56.44 | brlcad | do they really expect everyone to wait? |
| 20:56.58 | JeffM | of course |
| 20:57.02 | brlcad | hehe |
| 20:57.07 | JeffM | cus isn't the world just there for them? |
| 20:57.32 | sumit | well, i just mean that "it is generally tricky" was meant for abstracting the game logic and not to stop using "okay" and "right" |
| 20:58.16 | brlcad | :) yes that part can be tricky |
| 20:58.32 | JeffM | remember, you only have a 50/50 chance of getting your point across in text, it's scientificly proven ;)\ |
| 20:58.41 | sumit | brlcad : Well i would consider not using such words as it would also save some precious bytes to be travelling over my broadband cable,lol |
| 20:59.07 | JeffM | of you are concerned about saving letters.... this is not the place for you ;) |
| 20:59.22 | JeffM | we ask that everyone do what they can to comunicate as clearly as possible |
| 20:59.31 | sumit | JeffM : I am concerbned about not wasting them, theres a difference |
| 20:59.39 | JeffM | to help that 50/50 chance be better |
| 20:59.40 | trepan | every time a byte is lost to the internet, an angel dies |
| 20:59.54 | JeffM | sumit: you have N of them, who cares |
| 21:00.09 | brlcad | it's more about scalable etiquette .. if we were all doing that, it would be so very unproductive |
| 21:00.15 | JeffM | using them to enhance the clarity of your comunication is TOTALY not a waste |
| 21:00.24 | CIA-11 | BZFlag: 03Optic Delusion 07http://my.bzflag.org * r5597 10/w/BZW_Exporter_for_Wings3D: Maajor Update |
| 21:00.27 | brlcad | aside from just being repetitive and annoying after a while (because there is no value) :) |
| 21:00.28 | JeffM | think of it as linquistic checksums |
| 21:01.11 | trepan | and you can save the occasional byte be removing leters, as does Jeff (comunication/totaly ;-) |
| 21:01.24 | JeffM | well tha's just cus I can't spell ;) |
| 21:01.35 | brlcad | you do it in person because probably learned it as a way to convey that you are listening -- just doesn't translate well to a forum |
| 21:01.54 | JeffM | there is a difference between spelling wrong and typing crap like "sry", and "w/e" |
| 21:02.05 | sumit | exactly that is the case, i am so very used to it |
| 21:02.21 | sumit | well i wrote that for brlcad |
| 21:03.11 | sumit | its like in my college we have a sort of a formal senior junior relationship, so you can consider it as a consequence of that |
| 21:03.20 | brlcad | sumit: fair enough, just don't type everything you think :) |
| 21:03.36 | JeffM | thinks he'll put sox on |
| 21:03.47 | trepan | listening to tunes? |
| 21:03.50 | brlcad | red sox ? :) |
| 21:04.01 | JeffM | whitesox |
| 21:04.07 | JeffM | tis windy here ;) |
| 21:05.28 | sumit | well guys i will take a leave, it was nice interacting with you |
| 21:05.34 | JeffM | have fun |
| 21:05.39 | sumit | :) |
| 21:05.45 | *** part/#bzflag sumit (n=root@59.94.97.121) |
| 21:09.40 | blast007 | threw up an updated Windows installer for the latest trunk code: http://beta.bzflag.bz/builds/2.99.x/bzflag-2.99.19.20090322.exe |
| 21:10.03 | blast007 | this one actually has the sound files, which might have been the only reason I wasn't getting sound on my Vista machine ;) |
| 21:10.12 | trepan | what's svn rev? |
| 21:10.18 | trepan | *which |
| 21:10.21 | blast007 | checks |
| 21:10.47 | blast007 | 19503 |
| 21:10.54 | trepan | thanks |
| 21:14.12 | trepan | would be nice to automate an svn rev insertion using svnversion, or $Id$, or <insert better method here> |
| 21:15.23 | nightstrike_ | hey guys, I'll be submitting an application tomorrow. Kindly review it :) |
| 21:15.35 | nightstrike_ | almost done preparing it |
| 21:18.05 | Will07c5 | I just got bzworkbench to compile and seeing the gui my first impression is to scrap the gui and start over |
| 21:18.44 | JeffM | yeah |
| 21:18.51 | JeffM | it's not very good |
| 21:19.00 | JeffM | but that dosn't mean you need to scrap the toolkit |
| 21:19.08 | Will07c5 | yeah |
| 21:19.09 | JeffM | as the gui is just what the first developer threw together |
| 21:19.23 | JeffM | it was basicly the minimum he needed to test the backend |
| 21:20.09 | Will07c5 | understandable, although I'm wondering if there is anyway to make fltk look better on windows since it is very ugly |
| 21:20.21 | JeffM | as long as it's useable that's fine |
| 21:20.29 | JeffM | I added code to have it use a native windows file open and save box |
| 21:20.32 | JeffM | the rest is fine |
| 21:21.07 | Will07c5 | yeah that's true |
| 21:21.18 | JeffM | making it pretty is simpler, later ;) |
| 21:21.45 | *** join/#bzflag jcp1 (n=jw@unaffiliated/javawizard2539) |
| 21:22.00 | Will07c5 | I think I'll look at other game editors and see what they do right |
| 21:22.18 | Will07c5 | that could help give some ideas for how to improve the gui |
| 21:22.45 | *** join/#bzflag nsquare (n=chatzill@c-71-56-70-78.hsd1.ga.comcast.net) |
| 21:25.24 | Will07c5 | also on the opengl modularization topic I was just thinking would it be best to have an interface for the graphics code so that it would be possible to implement different backends for rendering graphics? |
| 21:25.38 | JeffM | that is the final goal |
| 21:25.55 | JeffM | the first part is getting it all in one place, so we can see what kind of interface we'll need |
| 21:26.13 | *** join/#bzflag Wyk3d (n=middle@c7.campus.utcluj.ro) |
| 21:26.24 | JeffM | a basic API will emerge as the code is seperate that is for sure |
| 21:26.30 | Will07c5 | I was just thinking how is that much different from getting it all in one place? |
| 21:26.49 | JeffM | getting it in one place is part of making an API for it |
| 21:26.59 | JeffM | cus you have to know what you are going to make an API for ;) |
| 21:27.30 | JeffM | but yes I expect as part of the proeject there to efectivly be an inteface that is the calls from the ouside code into the graphics section |
| 21:27.39 | JeffM | then that interface be refactored to a cleaner API |
| 21:27.53 | JeffM | but I'd do it in 2 steps, to make sure you don't break stuff just by moving it. |
| 21:27.59 | Will07c5 | ok that helps clear things up a lot |
| 21:32.54 | Wyk3d | JeffM: I can only reproduce that WorldEventManager crash as a shutdown crash. There is no handling for signals so when you 'x' the window i think it immediately halts the main thread which means there's nothing to call bz_Unload but the global variables are destructed in reverse order. Plugins like torBlock and serverControl have global eventHandler which are ofcourse unloaded before the WorldEventManager cause the crash. I found this by storing the num |
| 21:33.16 | Wyk3d | hides |
| 21:33.28 | JeffM | that is a very long sentace |
| 21:33.47 | JeffM | have you updatd sources recently? |
| 21:34.12 | JeffM | cus it should now remove all event handlers on destory |
| 21:34.30 | blast007 | fastmap is broken too I think |
| 21:34.37 | JeffM | so if unload isn't called, it should be fine |
| 21:34.48 | JeffM | if unload is called, th destructor remove just won't find anyone |
| 21:34.58 | Wyk3d | hmm no, i didn't update to that yet |
| 21:35.06 | JeffM | blast007: possibly |
| 21:35.16 | JeffM | Wyk3d: we went and removed all that autodelete crap |
| 21:35.37 | Wyk3d | good |
| 21:35.38 | JeffM | and there is now a single "remove all handlers that use this pointer" thing |
| 21:47.16 | trepan | can a plugin dynlib be loaded more than once? (wondering about static bz_EventHandler's) |
| 21:47.54 | JeffM | it's not prevented, but they'd each have there own instance, and there own static pointers |
| 21:48.03 | JeffM | they'd be seperate as far as everything was concerned |
| 21:48.29 | JeffM | we'd call load lib twice basicly, and that'd reinstance the lib |
| 21:49.00 | JeffM | at least that's how DLLs worked, if .so's did it differently I'd be very supprised |
| 21:49.03 | trepan | dlopen(): If the same library is loaded again with dlopen(), the same file handle is returned |
| 21:49.37 | JeffM | that sucks |
| 21:50.04 | JeffM | how does it work if 2 apps oppen the same lib at the same time? |
| 21:50.16 | JeffM | does it get the same static between them? |
| 21:51.36 | trepan | dunno, gotta gedda pizza |
| 22:17.56 | *** join/#bzflag CBG (n=CBG@cpc2-newe2-0-0-cust921.cdif.cable.ntl.com) |
| 22:27.43 | spldart | mmmMMMmmmm pizza |
| 22:29.49 | *** join/#bzflag forrestv (n=forrestv@unaffiliated/forrestv) |
| 22:31.49 | a_meteorite | cuts a slice of spldart's pizza |
| 22:31.59 | a_meteorite | you forgot the anchovies! :P |
| 22:32.09 | spldart | Help yourself and :-p |
| 22:32.34 | spldart | runs eldest daughter to Hot Topic for birthday spendings :) |
| 22:32.56 | a_meteorite | heh |
| 22:33.01 | a_meteorite | how old? |
| 22:33.18 | spldart | 17 |
| 22:33.38 | a_meteorite | I feel so old at 18 |
| 22:33.56 | spldart | Wait till 40 comes and goes |
| 22:34.04 | a_meteorite | heh |
| 22:34.18 | a_meteorite | time flies faster than I'd like |
| 22:44.45 | delusional | MAKE IT STOP! |
| 22:45.27 | a_meteorite | the great thing about that is if time stopped in its tracks we'd be oblivious. |
| 22:49.37 | trepan | JeffM: looks like static vars are shared across multiple dlopen()'s to the same dynlib from an executable instance |
| 22:53.18 | JeffM | then i'd not use static classes for event handlers ;) |
| 22:53.37 | JeffM | or make sure you remove them all on the uload |
| 22:54.14 | trepan | at least instead of crashing, your tweak will just make duplicates useless after the first unloads |
| 22:54.58 | trepan | (work have to check the code, but that's what it sounds like at least :) |
| 23:01.17 | JeffM | true |
| 23:01.48 | JeffM | really shold have done it where the pluing just registered a class instance |
| 23:01.54 | JeffM | then all this could be avoided |
| 23:11.09 | *** join/#bzflag tj13820 (n=unknown@unaffiliated/tj13820) |
| 23:14.02 | *** join/#bzflag TimRiker (n=timr@rikers.org) |
| 23:15.47 | *** join/#bzflag mindnull (n=mindnull@71-90-96-211.dhcp.aldl.mi.charter.com) |
| 23:16.46 | *** join/#bzflag Wyk3d (n=middle@c7.campus.utcluj.ro) |
| 23:34.25 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |
| 23:41.24 | *** join/#bzflag FastLizard4 (i=FastLiza@wikipedia/FastLizard4) |
| 23:48.59 | JeffM | ditches axiom |
| 23:51.19 | trepan | c# ogre ... why ditched? |
| 23:51.44 | JeffM | too much of a pita to get running on linux |
| 23:51.54 | JeffM | even by there own admission |
| 23:52.05 | JeffM | it's cool code and all, but just not "there" yet |
| 23:53.16 | JeffM | it's a little overkill for my simple test too |
| 23:54.45 | trepan | apparently there's an Irrlicht.NET CrossPlatform project |
| 23:55.19 | JeffM | if my test ideas work out I can always look into other engines, this is just more of a "what can C# do?" thing |
| 23:56.25 | JeffM | openTK seems more like what I need |
| 23:57.06 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |