| 00:13.08 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 00:13.09 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:14.48 | *** part/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 00:22.27 | CIA-76 | BZFlag: 03trepan * r20315 10/trunk/bzflag/ (32 files in 12 dirs): (log message trimmed) |
| 00:22.27 | CIA-76 | BZFlag: * bumped protocol and rev |
| 00:22.27 | CIA-76 | BZFlag: * added the "depthoffset <factor> <units>" parameter to materials, |
| 00:22.27 | CIA-76 | BZFlag: and removed the "polyoffset" parameter from the "text" object |
| 00:22.27 | CIA-76 | BZFlag: (this controls glPolygonOffset() for FILL, LINE, and POINT) |
| 00:22.30 | CIA-76 | BZFlag: * added the "vel" parameter to the bz_ShotFiredEventData_V1 class |
| 00:22.32 | CIA-76 | BZFlag: * removed the server-side shotPos calculation |
| 00:23.19 | CIA-76 | BZFlag: 03trepan * r20316 10/trunk/bzflag/src/bzflag/ (DisplayMenu.cxx Makefile.am): * oops, not yet |
| 00:34.48 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 00:41.54 | *** join/#bzflag mrapplecomputer1 (n=admin@c-69-180-173-220.hsd1.mn.comcast.net) |
| 01:06.00 | *** join/#bzflag rob1n (n=robin@cm61-10-139-91.hkcable.com.hk) |
| 01:07.50 | *** part/#bzflag mrapplecomputer1 (n=admin@c-69-180-173-220.hsd1.mn.comcast.net) |
| 01:19.27 | CIA-76 | BZFlag: 03trepan * r20317 10/trunk/bzflag/src/ (bzfs/bzfsClientMessages.cxx clientbase/LocalPlayer.cxx): |
| 01:19.27 | CIA-76 | BZFlag: * actually unpack the shot pos & vel data at the server |
| 01:19.27 | CIA-76 | BZFlag: (shots now appear on other clients) |
| 01:55.02 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 01:55.02 | *** mode/#bzflag [+v spldart] by ChanServ |
| 02:00.40 | *** join/#bzflag bier|tp (n=bier@p54A57FF1.dip.t-dialin.net) |
| 02:28.19 | CIA-76 | BZFlag: 03wyk3d * r20318 10/branches/gsoc_bzauthd/src/bzauthd/ (5 files): Added code to handle the registration http request. |
| 02:29.27 | CIA-76 | BZFlag: 03wyk3d * r20319 10/branches/gsoc_bzauthd_db/ (bzfls.php userstore.php): Send the registration request through http with the curl extension from bzfls. |
| 02:30.10 | blast007 | Wyk3d: cool :) |
| 02:30.39 | Wyk3d | seems to work too :) |
| 02:31.01 | Wyk3d | except i just realised i have to add the mail sending to the registration process as well |
| 02:31.43 | Wyk3d | is that necessary even when registering from the client though ? |
| 02:31.54 | blast007 | yeah |
| 02:32.17 | blast007 | I think the idea was that they could play a limited amount of times before having to confirm the email |
| 02:34.10 | Wyk3d | so whether or not it's been confirmed should be passed to the server at checktokens right ? |
| 02:34.29 | blast007 | probably |
| 02:34.46 | Wyk3d | or |
| 02:34.56 | blast007 | at least for 2.99.x/3.0.0 servers. Maybe send a "CONFIRMED" group back? |
| 02:35.00 | blast007 | or maybe* |
| 02:35.23 | Wyk3d | yeah but if you don't confirm for long enough |
| 02:35.28 | Wyk3d | your account should simply be deleted ? |
| 02:35.33 | blast007 | shrugs |
| 02:35.52 | Wyk3d | :) |
| 02:37.00 | Wyk3d | yeah probably better to just have the server kick the player if not confirmed |
| 02:37.09 | Wyk3d | for x amount of time |
| 02:47.51 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 02:47.51 | *** mode/#bzflag [+v spldart] by ChanServ |
| 03:00.57 | *** join/#bzflag Abominable (n=chatzill@97.104.162.86) |
| 03:31.42 | CIA-76 | BZFlag: 03trepan * r20320 10/trunk/bzflag/src/bzfs/lua/ (Obstacles.cxx Obstacles.h): |
| 03:31.42 | CIA-76 | BZFlag: * added explicit casting for uint32_t => double |
| 03:31.42 | CIA-76 | BZFlag: * added two spatial query call-outs |
| 03:41.56 | CIA-76 | BZFlag: 03trepan * r20321 10/trunk/bzflag/src/bzfs/ (4 files): * added some missing mesh finalizers |
| 03:44.47 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 04:08.10 | Bambino | ~bzflist |
| 04:39.42 | *** join/#bzflag QuantumT1m (n=tim@62.249.230.206) |
| 05:28.25 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 05:28.25 | *** join/#bzflag Will07c5 (n=William@c-67-173-127-196.hsd1.il.comcast.net) |
| 05:28.25 | *** join/#bzflag Bambino (n=Bambino_@S0106002191dd19a8.gv.shawcable.net) [NETSPLIT VICTIM] |
| 05:28.25 | *** join/#bzflag BulletCatcher (n=bc@bzflag/developer/BulletCatcher) [NETSPLIT VICTIM] |
| 05:28.25 | *** join/#bzflag matelich (n=tom@c-67-185-123-234.hsd1.wa.comcast.net) [NETSPLIT VICTIM] |
| 05:28.25 | *** join/#bzflag bigjust (n=bigjust@adsl-074-232-230-165.sip.asm.bellsouth.net) [NETSPLIT VICTIM] |
| 05:28.25 | *** join/#bzflag QuantumT1m (n=tim@62.249.230.206) [NETSPLIT VICTIM] |
| 05:28.25 | *** mode/#bzflag [+o ChanServ] by irc.freenode.net |
| 05:28.54 | *** join/#bzflag PrezKennedyII (i=Matthew@whitecalf.net) |
| 05:28.54 | *** join/#bzflag Thumper_ (n=Thumper@about/essy/coffeeAddict/Thumper) |
| 05:28.54 | *** join/#bzflag ts (n=ts@bzflag/developer/ts) |
| 05:28.54 | *** join/#bzflag ruskie (i=ruskie@sourcemage/mage/ruskie) |
| 05:28.54 | *** mode/#bzflag [+v Thumper_] by irc.freenode.net |
| 05:37.01 | *** join/#bzflag bigjust_ (n=bigjust@adsl-074-232-230-165.sip.asm.bellsouth.net) |
| 05:42.21 | *** join/#bzflag bigjust__ (n=bigjust@adsl-074-232-230-165.sip.asm.bellsouth.net) |
| 05:53.04 | *** join/#bzflag bigjust (n=bigjust@adsl-074-232-230-165.sip.asm.bellsouth.net) |
| 06:37.21 | *** join/#bzflag rob1n (n=robin@cm61-10-139-91.hkcable.com.hk) |
| 06:52.16 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 07:05.22 | *** join/#bzflag qqqqqqqqq (n=NOYOU@c-98-221-136-250.hsd1.nj.comcast.net) |
| 07:24.13 | *** join/#bzflag DTRemenak (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 07:24.13 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 08:05.24 | *** join/#bzflag qqqqqqqq (n=NOYOU@c-98-221-136-250.hsd1.nj.comcast.net) |
| 08:12.08 | *** join/#bzflag tupone (n=alfredo@gentoo/developer/tupone) |
| 08:12.08 | *** mode/#bzflag [+v tupone] by ChanServ |
| 08:14.07 | *** join/#bzflag dmtrius (n=dmitry_g@194.105.145.112) |
| 08:22.20 | *** part/#bzflag dmtrius (n=dmitry_g@194.105.145.112) |
| 08:56.32 | *** join/#bzflag rob1n (n=robin@cm61-10-139-91.hkcable.com.hk) |
| 10:18.57 | cygal | yey, replay works a *lot* better |
| 10:19.04 | cygal | ~trepan++ |
| 10:19.21 | cygal | ~JeffM++ |
| 10:25.42 | *** join/#bzflag QuantumT1m (n=tim@62.249.230.206) |
| 10:25.42 | *** join/#bzflag matelich (n=tom@c-67-185-123-234.hsd1.wa.comcast.net) [NETSPLIT VICTIM] |
| 10:25.42 | *** join/#bzflag BulletCatcher (n=bc@bzflag/developer/BulletCatcher) |
| 10:26.09 | *** join/#bzflag PrezKennedyII (i=Matthew@whitecalf.net) |
| 10:26.09 | *** join/#bzflag Thumper_ (n=Thumper@about/essy/coffeeAddict/Thumper) |
| 10:26.09 | *** join/#bzflag ts (n=ts@bzflag/developer/ts) |
| 10:26.09 | *** join/#bzflag ruskie (i=ruskie@sourcemage/mage/ruskie) [NETSPLIT VICTIM] |
| 10:26.09 | *** mode/#bzflag [+v Thumper_] by irc.freenode.net |
| 10:37.57 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 10:37.57 | *** mode/#bzflag [+o ChanServ] by irc.freenode.net |
| 10:38.26 | *** join/#bzflag emknox (n=marten@p5B235B8C.dip.t-dialin.net) |
| 10:52.14 | *** join/#bzflag Marzipan (n=marzi@84-119-52-222.dynamic.xdsl-line.inode.at) |
| 10:58.13 | *** join/#bzflag emknox_ (n=marten@p5B236BBE.dip.t-dialin.net) |
| 11:49.53 | *** join/#bzflag Wits (n=Wits@248.119.33.65.cfl.res.rr.com) |
| 12:00.00 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 12:00.00 | *** mode/#bzflag [+v spldart] by ChanServ |
| 12:11.44 | *** join/#bzflag rob1n (n=robin@cm61-10-139-91.hkcable.com.hk) |
| 12:14.33 | *** join/#bzflag tupone (n=alfredo@gentoo/developer/tupone) |
| 12:14.33 | *** mode/#bzflag [+v tupone] by ChanServ |
| 12:15.17 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 12:21.46 | *** join/#bzflag Swigg_ (n=Default@98.104.243.197) |
| 12:30.21 | *** join/#bzflag Default__ (n=Default@98.104.243.197) |
| 12:36.36 | *** join/#bzflag _anomaly_ (n=mike@h55.26.89.75.dynamic.ip.windstream.net) |
| 12:59.24 | *** join/#bzflag Winny (n=iWinny@bzflag/contributor/Winny) |
| 13:49.15 | *** join/#bzflag Wyk3d (n=Wyk3d@79.116.94.159) |
| 13:57.52 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 14:01.14 | *** join/#bzflag bryjen (n=bryjen@63.147.94.149) |
| 14:01.15 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 14:03.19 | *** join/#bzflag bier|tp (n=bier@pD9E2D474.dip.t-dialin.net) |
| 14:12.31 | *** join/#bzflag Atluxity (n=atluxity@wikipedia/Atluxity) |
| 14:15.00 | Atluxity | I got a problem with Bzflag in ubuntu 8.10 |
| 14:15.07 | Atluxity | it doesnt exit correctly |
| 14:15.26 | Atluxity | it gives me the X background, and a mouse |
| 14:15.49 | Atluxity | but nothing happend, no keyclicks responds, not even ctrl+alt+backspace |
| 14:15.54 | blast007 | what version of the client does 8.10 have? |
| 14:16.09 | Atluxity | the bzflag-client? |
| 14:16.28 | blast007 | sounds more like an issue with a driver or X though |
| 14:16.28 | Atluxity | atluxity@Atlux-lap:~$ bzflag -v |
| 14:16.29 | Atluxity | BZFlag client 2.0.10.20080527-MAINT-linux-gnu-SDL (protocol 0026) http://BZFlag.org/ |
| 14:16.29 | Atluxity | Copyright (c) 1993 - 2007 Tim Riker |
| 14:17.21 | Atluxity | I just exited nicely, then I did F4, that gave me X and I right-clicked on BZflag and choose quit |
| 14:17.28 | Atluxity | I mean close |
| 14:18.37 | blast007 | so is it only when you exit through the bzflag menu or the F12 key that it does that? |
| 14:18.47 | blast007 | "that" being screw stuff up ;) |
| 14:19.20 | Atluxity | I did'nt know about the F12 key before now |
| 14:19.31 | Atluxity | but when I do the menu, then it hangs |
| 14:19.38 | blast007 | hmm |
| 14:20.06 | blast007 | can't say I've had that happen. I'm running 9.04 though. |
| 14:20.23 | blast007 | are you running desktop effects (compiz) ? |
| 14:20.29 | blast007 | I've had random issues with that |
| 14:20.41 | Atluxity | compiz is running, but no grand effects |
| 14:21.00 | blast007 | might try turning it off completely |
| 14:21.11 | Atluxity | yeah... |
| 14:21.22 | Atluxity | I can try that |
| 14:21.38 | blast007 | if that fails, you could try building your own client from the v2_0branch SVN repo |
| 14:21.56 | Atluxity | yeah |
| 14:21.58 | blast007 | http://my.bzflag.org/w/SVN |
| 14:22.09 | Atluxity | thanks for the tip |
| 14:22.30 | Atluxity | btw, I heard about BZflag on the podcast FLOSS weekly |
| 14:22.32 | blast007 | Ubuntu 9.04 actually runs 2.0.13, which would be the stuff in SVN (not an official release) |
| 14:22.36 | cygal | how would that help? |
| 14:22.36 | blast007 | yup :) |
| 14:22.45 | Atluxity | been enjoying playing it, but I suck |
| 14:22.50 | Atluxity | even though its my third day |
| 14:22.50 | blast007 | cygal: might help if it's an issue with the build |
| 14:23.21 | cygal | but then you would not be able to play neither |
| 14:23.26 | blast007 | cygal: what? |
| 14:23.34 | blast007 | I said the v2_0branch |
| 14:23.38 | blast007 | so yes, he could play |
| 14:23.54 | cygal | no but you use the exact same build since you have 9.04 too, and it works |
| 14:24.15 | blast007 | ? |
| 14:24.21 | cygal | nevermind |
| 14:24.23 | blast007 | he has 8.10 |
| 14:24.37 | cygal | it's the same package |
| 14:24.48 | blast007 | no, he has 2.0.10, I have 2.0.13 |
| 14:25.26 | cygal | sorry. :) |
| 14:26.10 | blast007 | Atluxity: hehe, and that's another thing you could do: try upgrading to Ubuntu 9.04 ;) |
| 14:27.15 | blast007 | check your video driver too |
| 14:27.29 | cygal | check if you can play with other games |
| 14:28.05 | cygal | blast007 is right, upgrading to latest ubuntu would be easier than building the svn branch, if you don't know how to do that |
| 14:28.40 | Atluxity | last time I checked, some packages I wanted didnt work with 9.04, I'll check that later |
| 14:30.07 | blast007 | ah |
| 14:30.41 | blast007 | could also try renaming your config file to see if that's the problem. |
| 14:31.02 | blast007 | http://my.bzflag.org/w/Config_File |
| 14:33.04 | CIA-76 | BZFlag: 03wyk3d * r20322 10/branches/gsoc_bzauthd_db/ (bzfls.php serversettings.php.tmpl userstore.php): Send group intersect request through http. |
| 14:34.03 | CIA-76 | BZFlag: 03wyk3d * r20323 10/branches/gsoc_bzauthd/src/bzauthd/HttpHandler.cxx: Handle group intersect request. |
| 14:40.23 | Wyk3d | kicks CIA-76 |
| 14:40.23 | CIA-76 | ow |
| 14:41.28 | *** join/#bzflag Wyk3d (n=Wyk3d@79.116.94.159) |
| 14:43.08 | *** join/#bzflag Winny (n=iWinny@bzflag/contributor/Winny) |
| 14:43.08 | *** join/#bzflag tupone (n=alfredo@gentoo/developer/tupone) [NETSPLIT VICTIM] |
| 14:43.09 | *** join/#bzflag cygal (n=cygal@ks23738.kimsufi.com) [NETSPLIT VICTIM] |
| 14:43.09 | *** join/#bzflag Cobra_Slow (n=coprah@static.108.245.40.188.clients.your-server.de) [NETSPLIT VICTIM] |
| 14:43.09 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |
| 14:43.09 | *** mode/#bzflag [+v tupone] by irc.freenode.net |
| 14:43.34 | blast007 | netsplit ftl |
| 14:51.26 | *** join/#bzflag bier|tp_ (n=bier@pD9E2FB94.dip.t-dialin.net) |
| 14:56.17 | *** join/#bzflag Upsetter (n=ups@89.246.164.216) |
| 15:10.08 | Atluxity | Does the different colors have any special powers? |
| 15:10.24 | Atluxity | I see alot of players with the yellow color |
| 15:11.59 | rob1n | kicks CIA-76 |
| 15:11.59 | CIA-76 | ow |
| 15:12.22 | jorgenpt | hugs CIA-76 |
| 15:12.23 | CIA-76 | hugs jorgenpt |
| 15:12.26 | TD-Linux | yellow color? o.O |
| 15:13.14 | blast007 | the rogue team isn't really a team, so they can shoot anyone, including other rogues |
| 15:14.38 | Atluxity | ahhhh |
| 15:14.45 | Atluxity | that explains so much |
| 15:14.47 | Atluxity | :D |
| 15:14.52 | rob1n | heh your question makes sense now |
| 15:15.21 | Atluxity | so the genocide-flag wont kill all rouges, because they are "independent" |
| 15:15.37 | rob1n | yes |
| 15:16.00 | bryjen | there's a server add-on that makes that happen, but by default, no, geno doesn't work on rogues |
| 15:17.02 | Atluxity | I got to practice not to jump... I'm just bouncing all over the place... |
| 15:17.07 | bryjen | many folks play as rogue in free-for-all because they're not going to play as a team, and having teammates then becomes a liability |
| 15:17.25 | Atluxity | mhm |
| 15:17.32 | Atluxity | that makes sense |
| 15:20.00 | TD-Linux | play on modified pillbox for no-jumping practice :P |
| 15:20.46 | *** join/#bzflag joevano (n=joevano@bzflag/developer/JoeVano) |
| 15:20.46 | *** mode/#bzflag [+v joevano] by ChanServ |
| 15:58.02 | BulletCatcher | My motto about jumping is "jump first, die first." |
| 15:58.31 | BulletCatcher | Someone else probably said that before me. |
| 16:01.27 | _anomaly_ | BulletCatcher: probably the first person to jump said that |
| 16:16.35 | *** join/#bzflag TD--Linux (n=wheeeeee@96-42-95-185.dhcp.roch.mn.charter.com) |
| 16:18.11 | *** join/#bzflag Allejo (n=alllejo@adsl-69-234-127-158.dsl.irvnca.pacbell.net) |
| 16:21.19 | *** join/#bzflag TD---Linux (n=wheeeeee@96-42-95-185.dhcp.roch.mn.charter.com) |
| 16:22.54 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 16:22.54 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 16:27.45 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 16:27.45 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 16:29.42 | Marzipan | BulletCatcher: not always :P if you do it right, then the other one is dead first :) |
| 16:39.00 | cygal | JefferyM: Replay works far better thanks to your changes :) |
| 16:40.52 | JefferyM | that's because it's not using the server time |
| 16:40.53 | cygal | what is "obviously left" is: the "spawn effect" is at the center of the map, and there is no ricochet (but I don't know where I should be changing code for that to work yet) |
| 16:41.17 | JefferyM | there is an option to turn the server time on, and we should do that |
| 16:41.20 | JefferyM | so replay still needs to comp for the current server clock |
| 16:41.25 | cygal | ah k |
| 16:41.27 | JefferyM | or set the current server clock to the same as the replay |
| 16:41.44 | JefferyM | my changes need massive testing |
| 16:41.44 | cygal | sounds better |
| 16:41.49 | JefferyM | I only did minimal testing |
| 16:42.07 | JefferyM | I'd also like to test out using the server clock again |
| 16:42.14 | *** join/#bzflag Quol (n=ian@modemcable104.199-203-24.mc.videotron.ca) |
| 16:42.18 | JefferyM | since it's all using the same clock as the world |
| 16:42.18 | cygal | to see the diff? |
| 16:42.35 | JefferyM | to see if the DR problems of the past were because of the clock, or because of the DR code |
| 16:42.51 | cygal | DR still looks weird |
| 16:42.52 | JefferyM | since I didn't actualy change the DR code at all |
| 16:42.55 | JefferyM | see |
| 16:43.05 | JefferyM | then it's not the lag comp that is the problem |
| 16:43.13 | JefferyM | or its a bug in my changes |
| 16:43.42 | cygal | well, the tank moved like "two units forward", "one unit back" in one of my replays, I'd guess it means 'dr is wrong' |
| 16:43.48 | cygal | ah, and I wondered, when will we have an automatic test framework? "when someones sets it up", or "never"? |
| 16:43.53 | JefferyM | not nessisaraly |
| 16:44.08 | JefferyM | we have things when people write them |
| 16:44.16 | JefferyM | code does not magicaly appear ;) |
| 16:44.25 | cygal | I know, but it can be rejected too |
| 16:44.32 | cygal | I'll do that after gsoc |
| 16:44.47 | JefferyM | you can't really test DR inside of replay, because I don't get the feeling that you fully understand replay |
| 16:44.52 | JefferyM | test DR outside of replay |
| 16:44.55 | cygal | yup |
| 16:45.00 | JefferyM | then you can see where the issues are |
| 16:45.34 | cygal | I don't understand replay, I'd not say "at all", but it's not very far... I understand the global mechanism, but do not how we decide wich packets are sent to replay and why |
| 16:45.43 | cygal | s/how/know/ |
| 16:45.54 | JefferyM | it should just be a fixed list of packets |
| 16:45.57 | JefferyM | movement, shots, chat |
| 16:46.03 | JefferyM | anything that is sent to others |
| 16:46.17 | JefferyM | I can't actualy think of many packets we would NOT send |
| 16:47.33 | cygal | <PROTECTED> |
| 16:48.04 | cygal | and "game time updates" |
| 16:48.29 | JefferyM | because the game time messages are stamped into the update |
| 17:02.05 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 17:06.51 | *** join/#bzflag Will07c5 (n=William@c-67-173-127-196.hsd1.il.comcast.net) |
| 17:09.32 | *** join/#bzflag bigjust_ (n=bigjust@adsl-074-232-230-165.sip.asm.bellsouth.net) |
| 17:10.42 | *** join/#bzflag Think_Differentl (n=fatass@pool-96-231-94-86.washdc.east.verizon.net) |
| 17:29.09 | *** join/#bzflag me1 (n=ausom@bzflag/player/Me1) |
| 17:37.21 | Will07c5 | I'm just going to do bug fixing today, we can discuss where to proceed next when that is "done" |
| 17:42.09 | *** join/#bzflag Tupone (n=Tupone@gentoo/developer/tupone) |
| 17:42.09 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 17:43.07 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 17:48.45 | Atluxity | quiting from the menu makes X hang, pressing F12 does not.... at least not this time |
| 17:48.53 | CIA-76 | BZFlag: 03will07c5 * r20324 10/trunk/bzworkbench/src/ (3 files in 2 dirs): fixed issue with rotation not being saved to bzw |
| 17:53.20 | joevano | cygal: i based on your description "two forward, one back"... want to ask |
| 17:53.43 | joevano | have yeu seen a replay ona 2.0.x server? |
| 17:54.03 | cygal | yes - but I don't remember how movements are |
| 17:54.26 | joevano | not sure if it is a "new" phenomanon.. or maybe just more pronounced |
| 17:55.16 | joevano | it would kind of describe what you see when watching someone aim in a replay |
| 17:56.23 | joevano | but then i always watch replays remotely, so i dont know if that is the behaviour localy |
| 18:00.52 | JefferyM | has anyone actualy tried to play a 2 player game with the last set of shot/movement changes? |
| 18:01.03 | cygal | yes |
| 18:01.06 | cygal | it works good |
| 18:01.14 | cygal | reverting to before your changes right now to see the difference |
| 18:02.15 | JefferyM | better to just use the bzdb var to swap methods |
| 18:02.36 | cygal | hm |
| 18:02.47 | JefferyM | then it'll do the dt stuff |
| 18:02.54 | cygal | ah, if the result is the same, I'll do that the next time. |
| 18:03.18 | JefferyM | if you are testing in replay I would not bother |
| 18:03.26 | JefferyM | test in play then worry about replay later |
| 18:03.28 | JefferyM | replay can' |
| 18:03.37 | JefferyM | can't work untill we know the live game works |
| 18:03.49 | cygal | yeah, I'm not testing in replay - would be a bad idea |
| 18:04.14 | JefferyM | reverting the changes tests more then just the inital DR clock logic |
| 18:04.21 | JefferyM | since the clock changed as well |
| 18:05.39 | cygal | then how should I test this? |
| 18:06.02 | JefferyM | with the var to change methods |
| 18:06.41 | JefferyM | the key is to understand where the problem is coming from |
| 18:06.50 | JefferyM | not just randomly turn stuff on and off to see if it goes away |
| 18:07.02 | cygal | it's the only start point I have |
| 18:07.11 | cygal | this is how I found out about the clock |
| 18:07.17 | *** join/#bzflag Wyk3d (n=Wyk3d@79.116.94.159) |
| 18:07.22 | trepan | is tank DR still to be reverted / optionned ? |
| 18:07.23 | JefferyM | and you were wrong about the clock ;) |
| 18:07.44 | JefferyM | trepan, the current code defaults to doing the DR clock start the same way as 2.0.x |
| 18:07.48 | JefferyM | that was the major change for lag comp |
| 18:07.50 | cygal | I don't know if I was wrong or not, but by looking at the commits there were things to do :) |
| 18:08.04 | trepan | JefferyM: hm, still looked quite jerky when |
| 18:08.09 | JefferyM | yep |
| 18:08.15 | trepan | i looked at it (local client / server) |
| 18:08.25 | JefferyM | thats why I've always said that I didn't htink lag comp is the problem |
| 18:08.42 | trepan | something is amiss (w.r.t. 2.0.x's performance) |
| 18:08.58 | JefferyM | yes something is amiss, and I don't think it's lag comp |
| 18:09.20 | JefferyM | something else has been changed in DR, and it happened before the last set of changes before SOC |
| 18:09.45 | JefferyM | I honestly think the entire DR system needs to be reviewed |
| 18:09.53 | JefferyM | since we don't know what changed to "revert" |
| 18:11.27 | *** join/#bzflag TimRiker (n=timr@saygus.com) |
| 18:11.27 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 18:12.07 | JefferyM | the packets should be very similar in method to 2.0.x now |
| 18:12.14 | JefferyM | shots have a pos etc... |
| 18:12.31 | Tupone | I removed lag compensation on 2.0 last versions |
| 18:12.33 | JefferyM | the only addition is a timestamp that is set to gametime that can be optonly used for the start time |
| 18:12.44 | JefferyM | 2.0.x dosn't have lag comp |
| 18:13.30 | Tupone | it had but was removed .... visible problems with mouse enhanced player |
| 18:13.32 | cygal | the changes make the movements look actually better in a 2 players game |
| 18:13.44 | JefferyM | you mean before 2.0.0? |
| 18:14.12 | Tupone | I remember so |
| 18:14.14 | JefferyM | ok |
| 18:14.23 | JefferyM | well in 2.99, lag comp is off by default |
| 18:14.25 | cygal | before, when going forward then backward, there was a small "defect", I don't know how to describe that |
| 18:14.31 | JefferyM | so if we see DR issues, the are not related to lag comp |
| 18:14.39 | JefferyM | we need to find them and see what causes them. |
| 18:14.52 | JefferyM | there will always be jumps when a tank stops |
| 18:15.16 | JefferyM | the DR will have them move along the last path untill the packet with 0 speed gets to the client |
| 18:15.30 | JefferyM | then it'll look like you will "snap" back |
| 18:15.53 | cygal | what I can say is that r20324 is better r20309 wrt to DR (or displaying of the other thanks, I think that is DR) |
| 18:16.09 | JefferyM | I would like you to try it with lag comp |
| 18:16.16 | JefferyM | to see if its' any big difference |
| 18:16.19 | cygal | sure |
| 18:16.33 | JefferyM | if there is, then lag comp was buggy, if not, then it was just the synced clock that was buggy |
| 18:17.07 | JefferyM | what may be intersting is to log out the deta between the DR posiion, and the update position for debug testing |
| 18:17.16 | JefferyM | see how far they are off from each other |
| 18:17.19 | JefferyM | with and with out lag comp |
| 18:17.26 | trepan | s/_userServerDRClock/_useServerDRClock/ ? |
| 18:17.46 | JefferyM | yeah I can't spell :( |
| 18:17.52 | JefferyM | sorry |
| 18:18.02 | trepan | no prob; will you, or shall i ? |
| 18:18.09 | JefferyM | I'm at work, can you? |
| 18:18.24 | JefferyM | I would recomend only changing it when noone is moving |
| 18:18.28 | JefferyM | or noone is spawned |
| 18:18.30 | trepan | sure, < csar _userServerDRClock _useServerDRClock > and it's done |
| 18:18.49 | JefferyM | there is no protection, against having a wacky update in the middle of changing |
| 18:18.56 | *** join/#bzflag Wyk3d (n=Wyk3d@79.116.94.159) |
| 18:19.28 | JefferyM | optimaly it should store both start times, and then be able to switch between them, but I didn't go that far |
| 18:19.50 | CIA-76 | BZFlag: 03trepan * r20325 10/trunk/bzflag/src/ (clientbase/Player.cxx game/GameTime.cxx): * typo, s/_userServerDRClock/_useServerDRClock/ |
| 18:40.30 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 18:40.30 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 18:41.37 | *** join/#bzflag temp_work (n=temporal@bzflag/serverop/TemporalDistraction) |
| 18:43.43 | *** join/#bzflag camello (n=drogas@aa20060611363b8b1fd4.userreverse.dion.ne.jp) |
| 18:43.57 | camello | #supremos |
| 18:44.00 | camello | #supremos |
| 18:44.04 | camello | #supremos |
| 18:44.08 | *** kick/#bzflag [camello!n=JefferyM@bzflag/projectadmin/JeffM] by JefferyM (JefferyM) |
| 18:44.16 | *** join/#bzflag camello (n=drogas@aa20060611363b8b1fd4.userreverse.dion.ne.jp) |
| 18:47.46 | *** join/#bzflag Bambino (n=Bambino_@S0106002191dd19a8.gv.shawcable.net) |
| 19:02.29 | *** join/#bzflag mrapplecomputer1 (n=admin@c-69-180-173-220.hsd1.mn.comcast.net) |
| 19:15.43 | matelich | cygal, in case you were curious, you were right about why lasers are shorter - http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/game/global.cxx?view=diff&r1=12042&r2=12043 |
| 19:16.02 | matelich | its only been like that for 3 years 8 months. what a trunk newbie I am :) |
| 19:16.36 | JefferyM | yeah they were made shorter |
| 19:16.59 | matelich | a lot shorter, to reduce self-kills? |
| 19:17.07 | JefferyM | for many resons |
| 19:17.25 | blast007 | we started using cheaper laser to cut costs, so the range isn't as far |
| 19:17.30 | matelich | heh |
| 19:17.42 | JefferyM | yeah it's all diode based now |
| 19:17.56 | JefferyM | gas cylinders cost too much |
| 19:18.22 | matelich | just curious so I don't break the world by locally setting it back to 1000 |
| 19:18.30 | JefferyM | you can do that |
| 19:18.31 | *** join/#bzflag Marzipan (n=marzi@84-119-52-222.dynamic.xdsl-line.inode.at) |
| 19:18.36 | JefferyM | that's why it's a var |
| 19:18.49 | JefferyM | if it breaks something we should fix what gets broken |
| 19:27.10 | *** join/#bzflag Bambino_ (n=Bambino@unaffiliated/sniper15) |
| 19:27.24 | matelich | hmm, bzfs crashed on me. waah, I wanna play not wait for a debug build :) |
| 19:30.56 | *** join/#bzflag Wits_ (n=Wits@248.119.33.65.cfl.res.rr.com) |
| 19:31.01 | cygal | matelich: ah, thanks |
| 19:31.27 | cygal | concerning the crash, if you show how to reproduce, maybe someone will find out the problem for you :) |
| 19:34.02 | matelich | debugger is warning about Teleporter::getLinkMaterial - "Run-Time Check Failure #2 - Stack around the variable 'mat' was corrupted" |
| 19:35.16 | matelich | I'll try a diff't map |
| 19:38.32 | matelich | ~BzMaterial calling delete[] shaders; who has a value of 0x00000001 |
| 19:38.44 | JefferyM | valgrind it |
| 19:38.54 | matelich | on winders |
| 19:39.08 | JefferyM | boundschecker |
| 19:39.20 | JefferyM | or just step along in the debuger till you see it go bad |
| 19:39.29 | matelich | BC has never found a problem in a real world program for me :) |
| 19:39.38 | matelich | maybe my problems are too hard |
| 19:39.49 | JefferyM | then perhaps you havne't used it enough |
| 19:39.57 | JefferyM | it is not a trivial tool to use, but it is usefull |
| 19:40.08 | JefferyM | you can set a conditional breakpoint when the pointer changes. |
| 19:40.09 | matelich | ok, it might have found some things back in 98 |
| 19:40.23 | cygal | good night |
| 19:40.27 | JefferyM | see ya |
| 19:40.28 | matelich | I'll try another map, see if its generically broken. |
| 19:40.30 | matelich | bye |
| 19:40.40 | matelich | worked on saturday night |
| 19:40.58 | *** join/#bzflag mrapplecomputer1 (n=admin@c-69-180-173-220.hsd1.mn.comcast.net) |
| 19:40.58 | JefferyM | it's still a bug |
| 19:40.58 | JefferyM | even if it only happens in some maps |
| 19:41.19 | trepan | which map, and where/when is it crashing? |
| 19:41.38 | matelich | airport, exiting BzMaterialManager::addMaterial |
| 19:42.34 | matelich | >bzfs.exe!Teleporter::getTeleMaterial() Line 399 + 0xf bytesC++ |
| 19:42.35 | matelich | <PROTECTED> |
| 19:42.35 | matelich | <PROTECTED> |
| 19:42.35 | matelich | <PROTECTED> |
| 19:42.35 | matelich | <PROTECTED> |
| 19:42.39 | JefferyM | pastebin please |
| 19:42.43 | matelich | sorry |
| 19:43.58 | trepan | could you pastebin the map, or provide a link to it? |
| 19:44.11 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 19:44.28 | matelich | happening on two maps |
| 19:44.32 | trepan | either |
| 19:44.41 | mrapplecomputer1 | says hi to javawizzard! |
| 19:45.02 | matelich | map: http://pastebin.com/d6102bb80 |
| 19:45.05 | *** join/#bzflag Wits (n=Wits@248.119.33.65.cfl.res.rr.com) |
| 19:45.48 | matelich | conf: http://pastebin.com/d3d87ad49 |
| 19:46.23 | matelich | included sub-conf: http://pastebin.com/d78200897 |
| 19:46.59 | trepan | hm, no crash |
| 19:48.01 | matelich | just updated svn again. I'm running Vista / VS2008 SP1 |
| 19:48.28 | trepan | not that it should matter, but: Plugin:playHistoryTracker.dll found but does not contain bz_Load method ... |
| 19:48.56 | JefferyM | pfff, just delete that one, tis stupid |
| 19:49.24 | trepan | worked with playHistoryTracker.so ;) |
| 19:49.27 | trepan | my bad |
| 19:49.33 | JefferyM | hah |
| 19:49.50 | matelich | took out my -conf param, no help, as expected |
| 19:49.51 | JefferyM | not sure why people insist on putting the dll and so in the conifg |
| 19:50.03 | JefferyM | bz will add the correct extension for you |
| 19:50.17 | matelich | documentation is not verbose enough, I guess. |
| 19:50.28 | JefferyM | tho I'm not sure why we even maintain a windows bzfs |
| 19:50.51 | matelich | for people like me whose linux boxes are on deaths door? |
| 19:51.01 | JefferyM | meh |
| 19:51.02 | JefferyM | VM it |
| 19:51.08 | JefferyM | maybe for 3.2 |
| 19:51.11 | trepan | JefferyM: for windows mappers ? |
| 19:51.17 | JefferyM | double meh |
| 19:52.20 | trepan | matelich: i'll be back later; if you find anything, let the powers the be (Jeff) know ;) |
| 19:52.27 | matelich | aight |
| 19:52.39 | trepan | tbh, the BzMaterialManager needs to be rework anyways |
| 19:52.55 | trepan | it doesn't use the std::map<> that's defined, does linear searches (ew) |
| 19:58.28 | Bambino | So...I think this is spam http://my.bzflag.org/bb/viewtopic.php?f=8&t=14541 |
| 20:00.01 | *** join/#bzflag Wyk3d (n=Wyk3d@79.116.94.159) |
| 20:00.45 | joevano | Bambino: what post ;) |
| 20:00.47 | _anomaly_ | or russian |
| 20:00.56 | Bambino | :) |
| 20:01.08 | joevano | thanks |
| 20:01.27 | Bambino | *gasp* it's gone! |
| 20:02.39 | joevano | _anomaly_: technicaly the post was from Romania, but could have been Russian I guess |
| 20:04.37 | _anomaly_ | .ru is russia I believe |
| 20:06.00 | joevano | yeah, but that isn't where the post was from... spammers are like that ;) |
| 20:06.14 | _anomaly_ | I see |
| 20:06.42 | _anomaly_ | just advertising for a Russian game site |
| 20:06.56 | JefferyM | no, just spreading mallware |
| 20:07.39 | _anomaly_ | what else would a "Russian game site" do |
| 20:07.58 | JefferyM | give out porn |
| 20:08.11 | _anomaly_ | ah |
| 20:13.10 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 20:13.10 | *** mode/#bzflag [+o ChanServ] by irc.freenode.net |
| 20:18.46 | *** join/#bzflag Wits (n=Wits@248.119.33.65.cfl.res.rr.com) |
| 20:26.59 | matelich | silly me. forgot the "do a rebuild before publicly complaining about anything when using Visual Studio" rule of thumb. |
| 20:27.10 | matelich | well, after a bunch of hopping around from revision to revision, the problem is magically gone. sorry for the noise |
| 20:27.32 | JefferyM | probably an old lib, it happens |
| 20:30.22 | *** join/#bzflag Qew (n=qew@unaffiliated/qew) |
| 20:32.33 | *** join/#bzflag jcp1 (n=jw@unaffiliated/javawizard2539) |
| 20:52.46 | trepan | would like to add GPU info to join messages |
| 20:52.52 | trepan | anyone opposed ? |
| 20:54.44 | JefferyM | you mean to the version info? |
| 20:54.50 | JefferyM | or as it's own message? |
| 20:54.56 | JefferyM | I mean own variable |
| 20:55.23 | brlcad | seems more like clientquery data |
| 20:55.27 | JefferyM | yeah |
| 20:55.42 | JefferyM | it should go along with OS, version, etc.. |
| 20:56.18 | JefferyM | if you are tryng to use it for specific "I support XXXX feature" then just send those up as bits |
| 21:00.33 | trepan | no, not just features, more along the lines of glGetString(GL_RENDERER) |
| 21:00.51 | JefferyM | yeah you want it for information gathering right? |
| 21:00.57 | trepan | exactly |
| 21:01.09 | *** join/#bzflag MindstormsKid (n=msk@Wikipedia/MindstormsKid) |
| 21:01.11 | JefferyM | then it should be part of the existing info gathering stuff we have |
| 21:01.17 | JefferyM | OS and version, etc.. |
| 21:01.29 | JefferyM | just tack it onto that string |
| 21:02.06 | Atluxity | Are you guys doing the programming of BZflag? |
| 21:02.15 | *** join/#bzflag Gilly (n=btw@83.146.211.140) |
| 21:02.18 | JefferyM | thats the general idea :) |
| 21:02.46 | Atluxity | cool... I just started playing, listened to FLOSS weekly and got intrested.. I got a suggestion |
| 21:02.58 | trepan | JefferyM: add an extra string to ServerLink::sendEnter(), or make a separate query call? (i'd prefer the former) |
| 21:03.26 | JefferyM | trepan, we should treat it all the same, if you arn't going to split out the OS, I don't see why you would split out the GPU |
| 21:03.37 | JefferyM | Atluxity, and that is? |
| 21:03.42 | trepan | the former it is then ;) |
| 21:04.03 | JefferyM | the OS is merged in with the same string as Version right? |
| 21:04.13 | JefferyM | or are version and OS seperate? |
| 21:04.20 | Atluxity | I have learned that if you become "unresponsive" nobody sees you moving, but your client is moving around and trying to kill people, but nobody notices your shots. What I would want is better feedback to the player that "excuse me, but nobody can see you anymore" |
| 21:04.32 | trepan | oh, no, i'm just going to nboPackStdString(glGetString(GL_RENDERER)) at the end of the MsgEnter |
| 21:04.54 | JefferyM | trepan, where do we send the existing version? |
| 21:05.03 | trepan | ServerLink::sendEnter() |
| 21:05.08 | JefferyM | Atluxity, that's actualy not suposed to happen |
| 21:05.12 | trepan | the version string uses a fixed length buffer |
| 21:05.24 | JefferyM | so make it a variable lenght buffer |
| 21:05.30 | JefferyM | and make it all one string |
| 21:05.37 | JefferyM | then I don't have to change stats :) |
| 21:05.41 | trepan | na, i'd rather nboPackStdString(glGetString(GL_RENDERER)) be separate |
| 21:05.51 | JefferyM | then we should make the OS seperate too |
| 21:06.07 | JefferyM | I don't mind them seperate, I just want it consistent |
| 21:06.30 | trepan | the GPU doesn't related to the exec as much as the OS does |
| 21:06.44 | *** join/#bzflag qqqqqqqq (n=NOYOU@c-98-221-136-250.hsd1.nj.comcast.net) |
| 21:06.47 | JefferyM | yeah, I think I should make it query the actual OS, not just a build flag |
| 21:06.51 | trepan | 2.99.48.20090726-DEVEL-linux-gnu-SDL & GeForce 8800 GTS 512/PCI/SSE2 in my case |
| 21:06.54 | Atluxity | JefferyM, but yet it has.. I had a hard time understanding why my shot was'nt being registered... |
| 21:07.02 | JefferyM | split it like you want, and we'll see about pulling the OS out of the app versiopn |
| 21:07.19 | JefferyM | Atluxity, you probalby dropped UDP |
| 21:07.33 | JefferyM | our next version won't let you join if that happens and gives you a better message |
| 21:07.33 | brlcad | Atluxity: you not being able see all of them live and them not being able to see you are indistinguishable, they're the same thing |
| 21:07.36 | trepan | having the os in the app version hasn't been a problem so far |
| 21:07.54 | brlcad | Atluxity: eventually a timeout will kick in and you'll see everyone as NR (not responding) on the player list |
| 21:07.55 | CBG | Atluxity: that tends to happen when you or the server has connection issues. It's much the same as when you're browsing the web and suddenly one page is loading for a long time. Eventually, when it can't get a response from the server for a minute or two, it tells you that you need to fix your net. It's similar (I assume) where you go NR in bzflag, but the client doesn't tell you immediately. |
| 21:07.57 | JefferyM | trepan, dosn't tell us specfics ( like what version of windows ) |
| 21:07.57 | brlcad | and they'll see you as NR |
| 21:08.32 | JefferyM | I'd like to put the specific OS in there, uname for nix, etc.. |
| 21:08.33 | trepan | JefferyM: can the same exec run on different versions of windows? |
| 21:08.39 | JefferyM | yeah |
| 21:08.45 | JefferyM | thats why I want to split it |
| 21:08.51 | Atluxity | brlcad, how long is this timeout? |
| 21:08.52 | JefferyM | to know how many are on 9x, vs xp etc.. |
| 21:09.18 | JefferyM | bassicly replace the static build #def with a call to what is "uname" on windows |
| 21:09.38 | JefferyM | then we know not what it was built on, but what it's running on |
| 21:10.15 | brlcad | Atluxity: depends on your link to the server, but generally anywhere from a few seconds to a minute of unresponsiveness |
| 21:10.23 | Atluxity | ok |
| 21:10.33 | JefferyM | also depends on WHY your connecton has poofed |
| 21:10.38 | JefferyM | and how much of it has |
| 21:11.27 | JefferyM | tho an indicator with green yellow red based on ping packetloss would not be bad |
| 21:15.00 | CBG | Atluxity: I'd say it is the same in many online games... :) |
| 21:16.08 | Atluxity | CBG, yeah... I just wish for a way to get feedback about it, because it can be kind of frustrating to see the bullet go straight threw a guy for no apparent reason.. |
| 21:16.32 | CBG | What sort of feedback (if any) have you noticed in other games? |
| 21:18.19 | Atluxity | I havent played anything since CS source got out... but in CS I think you just got a message that you dropped... and everyone else could see your model hanging in the air in a certain way |
| 21:19.28 | CBG | In CS:S, you get a little red warning text in the upper right corner of the screen after a variably short while, but until then you continue to play (and fail). |
| 21:19.36 | CBG | Unsure about 1.6. |
| 21:26.11 | *** join/#bzflag bier|tp_ (n=bier@p54A57CF3.dip.t-dialin.net) |
| 21:27.42 | *** join/#bzflag randomparticle (n=xell@about/essy/snick/randomparticle) |
| 21:28.20 | *** part/#bzflag randomparticle (n=xell@about/essy/snick/randomparticle) |
| 21:33.12 | JefferyM | CBG, a lot of games have a "lag-o-meter" that gives you an indication of your connection status |
| 21:33.26 | JefferyM | we could do that by checking how many unresponded pings there are |
| 21:33.50 | JefferyM | bzflag wasn't realy meant for the internets, just lan play so it never had one |
| 21:34.08 | CBG | Oh sure, source games show you your ping, if that's what you mean. |
| 21:34.15 | JefferyM | yeah that's one way |
| 21:34.26 | CBG | I don't think it updates enough to be significantly more informative than the warning text though. |
| 21:34.41 | JefferyM | if I feel up to it I'll look into a green->yellow->red circle based on your pings/packetloss |
| 21:35.22 | JefferyM | probably factor in "time since last message" as well |
| 21:35.27 | JefferyM | then we could know NR pretty fast |
| 21:35.36 | JefferyM | eveyrone should send an update every 30 seconds |
| 21:35.40 | JefferyM | at the last |
| 21:36.39 | JefferyM | lagkick and lagwarn are now in BZDB too, we can use that to show how close you are to those |
| 21:38.03 | *** join/#bzflag ahs3- (n=ahs3@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 21:43.25 | CIA-76 | BZFlag: 03will07c5 * r20326 10/trunk/bzworkbench/ (17 files in 7 dirs): yay transforms now work properly, also changed meshbox and meshpyr to be aliases of box and pyramid for simplicity. |
| 21:45.21 | Will07c5 | it actually turned out that I was applying the transforms in the right order, there was just some subtle problem with generating the rotation matrix |
| 21:46.09 | JefferyM | good job |
| 21:47.26 | Will07c5 | thanks, well I think that is the last major known bug, although I'm willing to bet there are others |
| 21:47.34 | JefferyM | possibly |
| 21:47.53 | JefferyM | sounds like it's time to start making some maps and seeing what else could use some lovin |
| 21:49.12 | Will07c5 | oh there is plenty, the interface isn't very intuitive |
| 21:49.44 | Will07c5 | I think some parts could definitely use tool tips to clarify things |
| 21:54.32 | Atluxity | the control-panel on the console, how to i flip between the tabs? |
| 21:57.41 | brlcad | emphasis on the "known" part .. I'm sure could find some other major bugs if we poke at it just a lil |
| 21:57.58 | brlcad | still, nice work Will07c5 :) |
| 21:58.17 | JefferyM | yeah at least it's pokeable now |
| 22:01.16 | Atluxity | what does the F4 button do? |
| 22:06.34 | temp_work | minimizes the game to the dock or taskbar |
| 22:06.46 | Will07c5 | brlcad: thanks, yeah I have no doubt there are other major bugs |
| 22:14.48 | *** part/#bzflag bryjen (n=bryjen@63.147.94.149) |
| 22:45.41 | CIA-76 | BZFlag: 03wyk3d * r20327 10/branches/gsoc_bzauthd/ (5 files in 2 dirs): Added a GuardedSingleton to make the use of UserStorage thread safe. |
| 22:47.51 | brlcad | hm, I somehow have doubts that is truely thread safe |
| 22:48.17 | brlcad | my initial version of the Singleton class supported thread locking and different memory allocation schemes |
| 22:48.32 | brlcad | but that logic was ripped out to keep things simple |
| 22:48.32 | Wyk3d | it is not thread safe at creation |
| 22:48.36 | Wyk3d | but when it is used |
| 22:48.41 | Wyk3d | the individual function calls |
| 22:48.51 | Wyk3d | are locked before and unlocked after |
| 22:49.20 | Wyk3d | you cannot call any function of the class without going through the lock |
| 22:51.03 | Wyk3d | do you see other issues besides the obvious one if multiple threads call the first instance() at the same time .. or if multiple threads try to destroy it |
| 22:51.07 | Wyk3d | ? |
| 22:51.39 | Wyk3d | i don't have those problems because i only fork into multiple threads after i created the user storage |
| 22:52.19 | brlcad | more concerned that it seems like a rather inelegant solution |
| 22:52.47 | Wyk3d | i don't see how it could be more elegant |
| 22:52.54 | Wyk3d | maybe the implementation looks odd but |
| 22:53.01 | Wyk3d | it's use is very elegant |
| 22:53.08 | Wyk3d | drop in replacement for normal singleton |
| 22:53.13 | Wyk3d | .. if you use #defines |
| 22:53.44 | Wyk3d | you don't have to worry about putting guards in every single function of the class |
| 22:53.50 | Wyk3d | or at every call of the function |
| 22:54.02 | Wyk3d | there's no overhead when the class calls its own function |
| 22:56.10 | Wyk3d | i don't know of any other mechanism in C++ that can make sure that code is called before and after a function call |
| 22:57.22 | brlcad | notes INSTANTIATE_GUARDED_SINGLETON doesn't actually instantiate anything |
| 22:57.40 | Wyk3d | yeah could use a better name |
| 22:57.44 | brlcad | well like I said, originally, it had protection and allocation types |
| 22:57.51 | brlcad | template parameters |
| 22:58.05 | brlcad | works out pretty cleanly |
| 22:58.14 | brlcad | takes care of a lot of access guarantees |
| 22:58.36 | brlcad | plus it would work with the existing singleton interface as it's just a specialization |
| 22:58.59 | brlcad | so there's not two singleton codes to maintain |
| 22:59.02 | brlcad | has to run off for a bit |
| 23:00.53 | matelich | It looks pretty well locked down, assuming friendly users who won't cache the reference, or pass it to other functions. |
| 23:03.11 | Wyk3d | i suppose it would be possible to combine the two implementations and increase reuse with some more templates |
| 23:08.03 | JefferyM | so there is no ping or heartbeat to the server while you are playing? |
| 23:18.10 | *** join/#bzflag blast (i=4cc99596@gateway/web/freenode/x-935a0a6070a01df3) |
| 23:27.05 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 23:41.58 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 23:45.34 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |