| 00:00.22 | randomparticle | i suppose you could have a glowing hit zone around the tank. you could call it an energy field or something |
| 00:00.40 | A-Delusion | random particles? |
| 00:00.49 | randomparticle | that'll do |
| 00:01.42 | A-Delusion | hmmm.. never thought to test top and bottom.. |
| 00:01.42 | randomparticle | it would kind of make sense if you thought of it as a defense shield |
| 00:02.37 | PuMpErNiCkLe | Vulnerability shield? O.o |
| 00:02.53 | randomparticle | or that |
| 00:04.30 | randomparticle | it could be quite nice looking. a shell hits the shield, the shield glows even more, changes color, then the tank wobbles a bit and explodes showering cake over the onlookers |
| 00:04.58 | randomparticle | doesn't have to be cake, but cakes are nice :) |
| 00:05.41 | Theme97 | FROGS! |
| 00:05.49 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 00:05.49 | randomparticle | yeah! |
| 00:06.02 | randomparticle | do they go splat when they hit you? |
| 00:06.47 | Theme97 | Hmm... |
| 00:06.50 | Theme97 | Naw, froggies are cool. |
| 00:07.11 | randomparticle | i might code up this force field thing and see how it might look |
| 00:07.15 | randomparticle | time permitting, that is |
| 00:07.58 | Theme97 | or could just be metal. |
| 00:08.08 | randomparticle | you need to see the tank too, though |
| 00:08.57 | randomparticle | it's quite hard to see through most metal :) |
| 00:09.09 | Theme97 | But it already exploded. |
| 00:09.13 | Theme97 | How can you see it? |
| 00:09.20 | randomparticle | oh, after the explosion. ok |
| 00:10.20 | randomparticle | i like the shower of frogs idea, i must say |
| 00:11.20 | randomparticle | hmm.. are there any opengl wizards here? |
| 00:13.02 | *** part/#bzflag randomparticle (n=randompa@about/essy/snick/randomparticle) |
| 00:15.18 | spldart | transparent aluminium!!! |
| 00:21.56 | CIA-3 | BZFlag: 03bthansen 07v2_0branch * 10bzflag/plugins/newplug.sh: Rename the missing file in .deps too |
| 00:29.59 | *** join/#bzflag CBG (n=CBG@cpc4-stme1-0-0-cust103.cdif.cable.ntl.com) |
| 00:34.28 | Flash | I have a protocol question (probably irrelavant) |
| 00:34.43 | blast007 | k |
| 00:34.48 | Flash | MsgShotBegin uses and unsigned short for the shot id |
| 00:34.57 | Flash | MsgShotEnd uses a short for the shot id |
| 00:35.04 | blast007 | heh |
| 00:35.22 | Flash | I'm just in playing.cxx right now, so I'm not sure what the server is sending |
| 00:40.25 | DTRemenak | same number of bits |
| 00:40.58 | Flash | right, as I said, probably irrelevant |
| 00:44.20 | Flash | what is the difference between a local player (BaseLocalPlayer) and a remote player (RemotePlayer) ?? |
| 00:44.33 | Flash | (telling me to read the code is OK :-) |
| 00:45.20 | Flash | and also a Player |
| 00:47.08 | Gnurdux | Flash: you need to understand a bit of OOP, Player is the superclass of local and remote players, from the names i would guess a BaseLocalPlayer is a player attached to THAT client, and a remote one is another player on the server |
| 00:48.09 | Flash | ShotBegin references a RemotePlayer; ShotEnd references a BaseLocalPlayer |
| 00:48.20 | Flash | seems like they should both describe the same entity |
| 00:48.38 | Flash | of course, I could totally not understand the relationship between ShotBegin and ShotEnd |
| 00:49.39 | Gnurdux | Flash, what are you trying to implement |
| 00:49.49 | blast007 | ShotBegin is sent the by player that fired, and ShotEnd is sent by the player that got hit |
| 00:49.54 | Flash | nothing yet; I'm trying to document the protocol |
| 00:50.07 | Flash | so I have to figure out all the messages that are sent/received |
| 00:53.38 | Tupone | Flash: are you documenting the current (2.0.x) or the future (2.1.x)? |
| 00:53.43 | Flash | 2.1 |
| 00:53.44 | *** join/#bzflag bz19 (n=4238e4bb@bz.bzflag.bz) |
| 00:54.07 | Flash | I figured 2.0 was too close to being obsolete ;-) |
| 00:54.22 | Tupone | shotbegin and shotend are both generated from server, based on messages from the client |
| 00:54.46 | Tupone | there is no more shotend from client |
| 00:55.21 | Flash | ok; right now I'm gettting what I can from playing.cxx, where the various messages are handled |
| 00:55.33 | Flash | I'll get to where the server generates them in a bit ;-) |
| 00:56.13 | Tupone | well, just pointing that hat the client send is not what he receive |
| 00:56.20 | Tupone | s/hat/what/ |
| 00:57.21 | Flash | ok; the only thing I've seen the client send (so far) are world requests and GM strategy updates |
| 00:57.35 | blast007 | ah, 2.1 |
| 00:59.21 | Tupone | did that change to remove that hackish end-of-shot check |
| 00:59.33 | Tupone | the anti cheat one |
| 01:02.54 | blast007 | cool |
| 01:03.54 | Tupone | well, not cool, just due :/ |
| 01:15.21 | *** join/#bzflag bryjen (n=bryjen@2002:4cb1:b973:0:0:0:0:1) |
| 01:15.21 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 01:26.16 | Flash | bleah |
| 01:26.36 | Flash | MsgAdminInfo has two different syntaxes, depending on how many IPs are sent? |
| 01:28.32 | blast007 | heh |
| 01:28.51 | Flash | well, at least the structure is consistent (wasn't sure at first) |
| 01:30.08 | Flash | there's a comment in the case where only 1 IP is sent that "replacement for the normal MsgAddPlayer message" ... seems unpleasant |
| 01:30.24 | *** join/#bzflag [NP]Tangent (n=hyperdev@71-212-209-112.hlrn.qwest.net) |
| 01:44.14 | *** join/#bzflag TD-Linux (n=TD-Linux@24-159-197-22.dhcp.roch.mn.charter.com) |
| 02:05.31 | *** join/#bzflag AAA_awright (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 02:13.40 | *** join/#bzflag BenUrban (n=benurban@unaffiliated/benurban) |
| 03:10.23 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 03:35.42 | AAA_awright | ~ibot |
| 03:35.50 | ibot | ibot is, like, a blootbot written in perl run by TimRiker on his server. logs on http://ibot.rikers.org/<chan>/ , ibot, jbot, apt are all the same process. It uses sqlite, but mysql or other SQL storage is also supported. |
| 03:35.50 | AAA_awright | ~bzflag |
| 03:35.52 | ibot | i heard bzflag is a 3D internet multiplayer multiplatform (win32, linux, mac, etc) opensource opengl Battlezone capture the flag game of the same name that you must try at http://BZFlag.org/ or a continual development project with periodic gaming interuptions. See also TimRiker |
| 04:13.05 | [NP]Tangent | ~timriker |
| 04:13.08 | ibot | from memory, timriker is my owner http://rikers.org/ mailto:Tim@Rikers.org mailto:TimR@Debian.org maintainer of BZFlag, member of a ton of open source projects http://www.advogato.com/person/timriker/ http://sourceforge.net/users/timriker/ the guy who GPL'd SCO's ABI files, giving every Linux user the right to use them ;-), or a very cool guy. |
| 04:14.47 | Flash | would it be reasonable (or useful) to have a tank report its size |
| 04:14.55 | Flash | or is that just too easy to cheat |
| 04:16.14 | a_meteorite | ...someone could easily change what they report |
| 04:16.33 | a_meteorite | ~seen JeffM2501 |
| 04:16.52 | ibot | jeffm2501 <n=jeffm@pdpc/supporter/sustaining/JeffM2501> was last seen on IRC in channel ##essy, 3d 10h 6s ago, saying: 'but vegas and San Diego with Dana will be quite nice'. |
| 04:17.31 | Flash | or should (does in 2.1) the server compute collisions? |
| 04:17.38 | a_meteorite | Dana? isn't that SportChick? |
| 04:17.48 | a_meteorite | Flash: no idea |
| 04:18.23 | Flash | SportChick is Donna |
| 04:18.28 | a_meteorite | ahh |
| 04:18.35 | a_meteorite | similar names :) |
| 04:37.15 | spldart | bzzt |
| 05:10.48 | *** join/#bzflag maxwells (n=4129f7d3@bz.bzflag.bz) |
| 05:11.08 | maxwells | oh huh, i didn't know people actually used this |
| 05:21.43 | *** join/#bzflag zee286 (i=3e4de48a@gateway/web/cgi-irc/zeebrothers.net/x-ad1631783f3ea3e6) |
| 05:48.33 | *** join/#bzflag ep (n=mdr@about/essy/guynextdoor/ep) |
| 05:49.48 | *** join/#bzflag kyelewis` (n=kyelewis@ppp194-186.static.internode.on.net) |
| 07:01.27 | *** join/#bzflag Theme97 (n=Theme97@about/essy/phpwriter/Theme97) |
| 07:08.54 | *** join/#bzflag Pommes (n=Pommes@about/essy/frenchy/Pommes) |
| 07:11.49 | *** join/#bzflag twitch_ (n=gort242z@cpe-75-82-228-143.socal.res.rr.com) |
| 07:29.18 | *** part/#bzflag twitch_ (n=gort242z@cpe-75-82-228-143.socal.res.rr.com) |
| 08:24.46 | *** join/#bzflag kyelewis` (n=kyelewis@ppp194-186.static.internode.on.net) |
| 10:06.57 | *** join/#bzflag Birdie (n=Birdie__@d54C12302.access.telenet.be) |
| 10:32.27 | *** join/#bzflag |zongo| (n=zongo@int-34-54.mobile.unibas.ch) |
| 10:33.26 | *** join/#bzflag bz67 (n=3ee2fd9b@bz.bzflag.bz) |
| 10:49.06 | *** join/#bzflag mwr25 (i=mwr25@pip.srcf.societies.cam.ac.uk) |
| 10:51.52 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 10:51.52 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 11:19.11 | *** join/#bzflag ts (n=ts@p54B03F32.dip0.t-ipconnect.de) |
| 11:36.37 | *** join/#bzflag Teppic (n=Teppic@cpc2-cbly2-0-0-cust985.glfd.cable.ntl.com) |
| 12:04.15 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@fordend.demon.co.uk) |
| 12:30.24 | *** join/#bzflag Toast (n=4464e0b9@bz.bzflag.bz) |
| 12:30.36 | Toast | hick |
| 12:30.37 | Toast | fdedd |
| 12:30.53 | Toast | Anyone here? |
| 12:33.26 | CBG | Nope. |
| 13:19.09 | Teppic | No 2 |
| 13:27.37 | short_circuit | heh |
| 13:35.54 | *** join/#bzflag bz61 (n=54a36bd6@bz.bzflag.bz) |
| 13:36.20 | *** part/#bzflag bz61 (n=54a36bd6@bz.bzflag.bz) |
| 13:47.43 | Teppic | indeed |
| 14:13.33 | *** join/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 14:14.52 | *** join/#bzflag BWD (n=bdotson@pdpc/supporter/student/bdotson) |
| 14:16.43 | *** join/#bzflag A-Delusion (n=A-Delusi@pool-151-201-122-253.pitt.east.verizon.net) |
| 14:41.23 | *** part/#bzflag A-Delusion (n=A-Delusi@pool-151-201-122-253.pitt.east.verizon.net) |
| 14:49.06 | *** join/#bzflag annieP (n=181d3f90@bz.bzflag.bz) |
| 14:49.50 | annieP | hey..i'm new to this..hope this is an alright place to ask a general question about website updating? |
| 14:50.24 | annieP | anyone know where I can start if I want to learn this process? |
| 14:52.12 | annieP | ok maybe not |
| 14:53.50 | *** join/#bzflag tannerld (n=tanner@adsl-068-209-251-067.sip.asm.bellsouth.net) |
| 15:22.26 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 15:22.26 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 16:24.07 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 16:27.20 | *** join/#bzflag cods_ (n=cods@tuxee.net) |
| 16:48.10 | *** join/#bzflag ||Wolverine|| (n=The_Pred@d81-211-177-188.cust.tele2.it) |
| 18:08.32 | *** join/#bzflag bz81 (n=18fa7ca2@bz.bzflag.bz) |
| 18:33.52 | *** join/#bzflag Guu` (n=supybot@bz.bzflag.bz) |
| 18:38.41 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 18:40.13 | *** join/#bzflag AAA_awright (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 18:42.13 | *** join/#bzflag Linuxx0r (n=ich@pD9E34D18.dip.t-dialin.net) |
| 19:10.55 | Gnurdux | is there any "road map" for bzflag at all? |
| 19:11.37 | brlcad | not really |
| 19:12.00 | *** join/#bzflag BWD (n=bdotson@pdpc/supporter/student/bdotson) |
| 19:12.20 | CBG | rofl, Gnurdux |
| 19:12.43 | brlcad | one was started on a couple years ago, but it was quickly diverged from |
| 19:13.44 | Gnurdux | is development stagnating, or not> |
| 19:16.46 | gsnedders | it's really rather hard to have a road map for any open source software |
| 19:16.55 | gsnedders | people will code what they want. |
| 19:17.44 | brlcad | Gnurdux: ebb and flows constantly -- never really ever stagnates but it does ebb and flow |
| 19:18.02 | Gnurdux | ok |
| 19:18.55 | brlcad | either way, you really shouldn't "expect" anything, especially if you're not a contributor but even if you were you can only expect what is already provided |
| 19:21.11 | *** join/#bzflag ||Wolverine|| (n=The_Pred@d81-211-177-218.cust.tele2.it) |
| 19:21.52 | Gnurdux | right, im just curious |
| 19:23.39 | brlcad | the closest thing to a road map would be the task tracker on the project site |
| 19:24.09 | brlcad | hasn't been actively updated in a while, but it has several desirable items listed |
| 19:30.32 | [NP]Tangent | ~bzfquery nullbzflag.gotdns.com:5154 |
| 19:31.40 | *** join/#bzflag wegstar (i=wegstar@166.15.185.213.dk-hvi.res.dyn.perspektivbredband.net) |
| 19:32.23 | *** join/#bzflag ts (n=ts@p54B03F32.dip0.t-ipconnect.de) |
| 19:35.48 | [NP]Tangent | welp |
| 19:35.54 | [NP]Tangent | it appears that whole server is down |
| 19:35.56 | [NP]Tangent | not just bzflag |
| 19:36.18 | *** join/#bzflag donny_baker (n=donny_ba@mse1.bowencenter.org) |
| 19:42.57 | brlcad | nifty, http://links-clan.net/download/image/Bzflag%20server%20Liste.PNG |
| 19:43.52 | donny_baker | yes... requires .NET framework |
| 19:43.59 | brlcad | ahh |
| 19:44.05 | brlcad | shame |
| 19:44.15 | donny_baker | it was released on the forums about 6 months ago |
| 19:44.20 | brlcad | would make a nice "bz" startup interface that we talked about a while back |
| 19:44.42 | donny_baker | yes, I have used it from time to time to find servers |
| 19:44.42 | brlcad | yeah, I vaguely recall it being released, but didn't look into any details |
| 19:45.00 | brlcad | the turret mod caught my curiosity too |
| 19:45.15 | brlcad | who's the dev? |
| 19:45.18 | donny_baker | didn't see that one |
| 19:45.32 | donny_baker | links2000 if i remember correctly |
| 19:45.50 | donny_baker | one sec and ill check for sure |
| 19:47.47 | donny_baker | 'Links 2004' is the developer http://my.bzflag.org/bb/viewtopic.php?t=8790 |
| 19:49.04 | ts | ~bzflist |
| 19:49.26 | ts | ~bzfquery brad.bz:1337 |
| 19:49.39 | ts | Umm, something is broken |
| 19:49.57 | ts | There's only 1 obs there |
| 19:51.39 | brlcad | does it report 8 in the client too? |
| 19:51.50 | brlcad | could just be an ibot issue |
| 19:51.58 | brlcad | or from the list directly |
| 19:52.04 | *** join/#bzflag Bluer (n=user@about/essy/terimahkSC/Bluer) |
| 19:52.51 | ts | brlcad: No, only 1 obs |
| 19:53.15 | blast007 | the hex part of the list probably changed for 2.1 |
| 19:53.32 | *** join/#bzflag Flash_away (n=jwmelto@c-24-9-8-185.hsd1.co.comcast.net) |
| 19:54.04 | brlcad | yeah, then just ibot fuzz |
| 19:54.55 | ts | spldart has another server but there are no players listed in ibot.. |
| 19:56.07 | ts | Hmm, no players there |
| 19:59.06 | *** join/#bzflag yummy (n=chatzill@tou77-1-87-88-83-138.dsl.club-internet.fr) |
| 19:59.35 | Flash | any feel for how expensive new/delete are in terms of game play? |
| 20:00.05 | brlcad | Flash: in what context? |
| 20:01.27 | Flash | what if each message from the server resulted in a new/delete of the message object? |
| 20:01.27 | brlcad | the only place they'd have a massive impact would be in the scene graph or somewhere graphics-related .. but in the gameplay logic itself, it's rarely an issue |
| 20:01.27 | brlcad | ahh |
| 20:01.27 | brlcad | that wouldn't be too much |
| 20:01.28 | Flash | I'd like to create a class for each server message, to improve encapsulation |
| 20:01.28 | Flash | and facilitate self-documentation |
| 20:01.28 | brlcad | server processes messages on the order of a few dozen per second per player |
| 20:02.00 | brlcad | as an upper bound .. often much less, rarely more |
| 20:02.18 | Flash | so not an appreciable performance impact to brute-force it then |
| 20:02.25 | brlcad | nope |
| 20:02.28 | brlcad | sounds like a good idea |
| 20:02.29 | Flash | (non-heap optimizations are possible) |
| 20:02.50 | brlcad | yeah, tons of optimizations possible, but I doubt it'll be even a blip on a profile |
| 20:03.36 | brlcad | server spends considerably more time checking bounds, placing players, filtering text, updating game play, etc |
| 20:03.48 | brlcad | and that's only getting more intensive as more client logic is moved server-side |
| 20:08.44 | Gnurdux | honestly, for game-speed stuff its mostly limited by the server, for "smoothness" by the graphics |
| 20:28.11 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 20:28.11 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 20:30.24 | CIA-3 | BZFlag: 03brlcad * 10bzflag/ (4 files in 4 dirs): apply patch from Links 2004 that bumps the button support up to 32 (from 16). |
| 20:33.31 | AAA_awright | ~bzfquery viper2.pimpi.org:5158 |
| 20:35.39 | *** join/#bzflag Birdie (n=Birdie__@d54C12302.access.telenet.be) |
| 21:04.12 | ts | brlcad: Do you know why the setvars are not documented in the bzfs man page? |
| 21:04.59 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@fordend.demon.co.uk) |
| 21:36.57 | *** join/#bzflag Blue_Eyes (n=Blue@host86-137-dynamic.60-82-r.retail.telecomitalia.it) |
| 21:56.09 | *** join/#bzflag master_tux (n=will@pool-71-99-7-205.tampfl.dsl-w.verizon.net) |
| 21:56.19 | master_tux | Hi everyone |
| 21:58.51 | brlcad | ts: because someone forgot to edit the man page? |
| 22:01.15 | ts | It's a bit much to simply "forget" that |
| 22:01.48 | brlcad | nah |
| 22:01.56 | brlcad | people forget to update the docs all the time |
| 22:02.09 | brlcad | quite frequently |
| 22:02.17 | brlcad | especially when adding new commands, flags, options |
| 22:02.29 | ts | I guess I'll add some new section to the man page then |
| 22:03.01 | ts | yeah, I forgot some stuff in the wiki, too :/ |
| 22:12.54 | brlcad | i never update the wiki docs myself |
| 22:13.15 | brlcad | there's plenty of others that can deal with that, it's more than enough just to get the stuff in cvs updated correctly |
| 22:13.31 | Tupone | wiki should die, and a new wiki should live |
| 22:13.40 | brlcad | :) |
| 22:13.44 | brlcad | media? |
| 22:13.48 | Tupone | yep |
| 22:14.05 | brlcad | media in drupal |
| 22:14.35 | brlcad | custom drupal auth module |
| 22:14.50 | brlcad | auth module talks to new list/auth server |
| 22:17.12 | brlcad | need a good name for the new list/auth server, something not bzfls :) |
| 22:17.30 | blast007 | brlcad: "OpenLDAP"? ;) |
| 22:17.33 | brlcad | mebbie bzauthd |
| 22:17.40 | brlcad | heh, blast007, maybe |
| 22:18.03 | blast007 | there's stuff to get phpBB, Drupal, and MediaWiki to all use an LDAP server |
| 22:18.04 | brlcad | i have been considering it, but it'd be a little fugly |
| 22:18.23 | brlcad | blast007: hmm.. good point |
| 22:18.26 | blast007 | media wiki was as simple as an extra file, and editing a config file |
| 22:19.20 | brlcad | i mean actually organizing all of the data into an ldap hierarchy that would preferably be managed by ldap |
| 22:19.47 | brlcad | user accounts, user profiles, server accounts, server profiles |
| 22:19.51 | blast007 | it would make a distributed list easier too |
| 22:19.56 | blast007 | it could do all the syncing for us |
| 22:20.00 | brlcad | somewhat |
| 22:20.41 | blast007 | still would need a layer between the client/server and the LDAP stuff |
| 22:20.46 | brlcad | about just as easy to write a simple lightweight syncing protocol, but I quite agree that the potential benefits probably outweigh |
| 22:20.48 | Tupone | and no more writing in the database temporary key. Just forget that way. Too crazy for a db |
| 22:21.22 | blast007 | brlcad: I suppose |
| 22:21.31 | brlcad | i wasn't even considering the auth keys yet |
| 22:21.42 | brlcad | that could perhaps be the layer then.. bzauthd of sorts |
| 22:21.57 | brlcad | it would/could talk to the ldap server(s) |
| 22:22.37 | Tupone | yeah, just a server, and if the server die, only loose some pending authentication on the way |
| 22:22.38 | brlcad | and would serve as the gate keeper for authentication keys |
| 22:22.39 | Manu | wow bzflag 2.0.8 for Slackware I guess they were using my build script |
| 22:23.01 | blast007 | yay for slackware |
| 22:23.10 | brlcad | Manu: yeah, I meant to mention that I uploaded that earlier |
| 22:23.32 | Manu | brlcad: I know. SF notified it me |
| 22:23.33 | brlcad | it's been sitting in the anonymous ftp incoming dir for quite a while.. forget who provided it |
| 22:23.59 | brlcad | Manu: ah, you're one of the 3 or so subscribers :) |
| 22:24.11 | Manu | hehe |
| 22:27.17 | brlcad | hm, i think i like bzauthd |
| 22:28.06 | Manu | brlcad: heh I added to monitoring slackware packages4 years ago :/ then I forgot it |
| 22:28.13 | a_meteorite | ~seen JeffM2501 |
| 22:28.36 | ibot | jeffm2501 <n=jeffm@pdpc/supporter/sustaining/JeffM2501> was last seen on IRC in channel ##essy, 4d 4h 11m 50s ago, saying: 'but vegas and San Diego with Dana will be quite nice'. |
| 22:28.45 | a_meteorite | Hmmm, still on vacation. :) |
| 22:29.44 | brlcad | having the clients talk to it would actually make it a little easier to add in-game registration too |
| 22:30.52 | *** join/#bzflag AAA_awright (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 22:32.16 | brlcad | blast007: do you know how you set up the mapping of ldap entities to those applications? |
| 22:33.10 | brlcad | i mean, it might be straightforward for the default entities, full name, user name, password style data, but groups could be problematic I'd think |
| 22:33.15 | blast007 | I haven't really looked into it too much |
| 22:33.36 | blast007 | I was using a Windows Server 2003 AD machine for the testing of MediaWiki |
| 22:33.49 | brlcad | and how to tie names together |
| 22:34.02 | blast007 | groups would be easy |
| 22:35.11 | brlcad | i mean if media expects groups to simply be the default "department" entity and drupal expects it to be some naming nomenclature, they'd be unrelated (which isn't necessarily a bad thing, but something to look at) |
| 22:36.05 | brlcad | i also want the auth mechanism to support registration and identification of servers too |
| 22:36.26 | brlcad | and how those servers will get recorded and distinguished from players might get interesting |
| 22:36.42 | brlcad | probably a simple department or other grouping hack will work |
| 22:37.51 | brlcad | but I could see adding a drupal module down the road, for example, that would let a server op log in using their "server account" and see a special page of server usage statistics |
| 22:38.53 | blast007 | for the mediawiki one: "Syncronization of LDAP groups to MediaWiki security groups (LDAP->MediaWiki only)" |
| 22:39.22 | brlcad | where/how all this gets logged is also an interesting question (open to ideas) .. it'd be nice to get mysql out of the picture, but if it were only used for logging, that might work well |
| 22:40.25 | brlcad | blast007: what is that quote? |
| 22:40.41 | blast007 | it's from http://meta.wikimedia.org/wiki/LDAP_Authentication |
| 22:40.50 | *** join/#bzflag spldart (n=troublem@cpe-24-28-107-184.houston.res.rr.com) |
| 22:41.16 | blast007 | drupal: http://drupal.org/project/ldap_integration |
| 22:43.23 | brlcad | so sounds like you can make groups (e.g. in drupal) and mediawiki will pull them from ldap, but you couldn't make them in mediawiki and use them in drupal |
| 22:43.23 | brlcad | which is good/fine actually, don't care about that direction |
| 22:43.57 | brlcad | actually don't care about being able to create groups on either since a custom drupal module could be written for group management and/or one in the client directly |
| 22:44.02 | blast007 | and if we had to, we could make a custom module for drupal to handle that |
| 22:44.03 | brlcad | or something command-line simple |
| 22:44.12 | brlcad | yep ;) |
| 22:44.14 | blast007 | :) |
| 22:44.45 | brlcad | jeez, almost sounds like a plan |
| 22:45.12 | blast007 | heh |
| 22:45.44 | brlcad | that is incredible.. mediawiki has made three quarters of a million dollars in the past two weeks |
| 22:45.53 | blast007 | nice |
| 22:46.10 | brlcad | rather, the wikimedia foundation |
| 22:46.51 | Tupone | brlcad: why you want to have mysql out? it could be the ldap backend. you prefer other backend? |
| 22:48.24 | brlcad | Tupone: perhaps only biased by the load put on the current mysql db for the list server requests .. |
| 22:49.14 | Tupone | but there will be no more such a thing |
| 22:49.17 | brlcad | that's probably just because we have it doing tons of inserts and selects simultaneously |
| 22:49.28 | brlcad | tons of selects might be fine |
| 22:50.01 | brlcad | i don't mean for the ldap backend, mysql could be used or whatever for all I care.. i mean for logging |
| 22:50.01 | Tupone | not a lot of select, unless openldap does it, which I don't think |
| 22:50.24 | Tupone | ahh, no, no mysql then |
| 22:50.33 | Tupone | no database at all |
| 22:51.14 | brlcad | there are two needs -- 1) looking up user auth information (groups, password authentication), which would come from ldap, occasional select involved if mysql is the backend and an insert when new accounts are made, etc |
| 22:51.43 | Tupone | for login, direct access to memory, inside the bzauthd |
| 22:52.59 | brlcad | 2) logging all actions, requests, authentications, etc so complete arbitrary statistics can be extracted like how frequently a player joins a given server in the summertime, etc |
| 22:53.10 | brlcad | oop, poof go tupone |
| 22:53.14 | blast007 | hehe |
| 22:53.18 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 22:53.18 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 22:53.19 | *** join/#bzflag Tupone_ (n=Tupone@pdpc/supporter/active/Tupone) |
| 22:53.19 | *** mode/#bzflag [+v Tupone_] by ChanServ |
| 22:53.27 | brlcad | heh |
| 22:53.35 | brlcad | tupone: 2) logging all actions, requests, authentications, etc so complete arbitrary statistics can be extracted like how frequently a player joins a given server in the summertime, etc :) |
| 22:53.43 | Tupone | lost my mouse :/ had to restart x |
| 22:54.27 | Tupone | eek :| |
| 22:54.28 | brlcad | i agree.. for login, that would be bzauthd's job frankly .. fast access to auth data |
| 22:55.08 | brlcad | it could just be shoved to a text file and data-mined as needed.. but that means a lot of custom on-demand parsing |
| 22:55.09 | Tupone | logging should be done at bzfs and probably batched |
| 22:56.05 | Tupone | or at bzauthd |
| 22:56.08 | brlcad | logging could also be done at bzfs, but server ops can't really be trusted either :) |
| 22:56.13 | brlcad | right, I"m thinking at bzauthd |
| 22:56.17 | brlcad | but to where :) |
| 22:56.19 | Manu | heh |
| 22:56.34 | brlcad | to mysql or to text file, or something nasty in ldap even ;) |
| 22:56.53 | blast007 | or sqlite |
| 22:57.07 | blast007 | embed it into bzauthd |
| 22:57.19 | Tupone | I'd prefer to a text-file |
| 22:57.25 | brlcad | that's what I was saying about "maybe not to mysql" though it does sort of make sense and might be efficient enough with the other auth "select" queries now gone |
| 22:57.57 | *** join/#bzflag triclops (n=triclops@203-206-240-117.dyn.iinet.net.au) |
| 22:58.02 | Tupone | remember we want also to do a switch from a bzauthd to another |
| 22:58.11 | Tupone | in case of failure |
| 22:58.16 | brlcad | Tupone: the only problem with that is that the text file is going to get *massive* really fast and data-mining is going to get more and more expensive |
| 22:58.45 | Tupone | during the night switch, you can do that |
| 22:58.52 | brlcad | e.g. we have a text log for bzfls web interface now -- I can pull up how many times you've played in the past three months with a little perl scripting or some creative grep/awking |
| 22:58.56 | blast007 | datestamps |
| 22:58.56 | Tupone | like when analyzing the apache log |
| 22:59.35 | blast007 | a database is still gonna be easier for that |
| 22:59.46 | blast007 | and typically faster |
| 22:59.48 | brlcad | you generally don't make interactive queries of an apache log, they are generally "reports" and you're done |
| 23:00.35 | brlcad | especially if there's a web interface tied to this, so a user can pull up when c3po last played, for example |
| 23:00.48 | brlcad | and it has to parse a 1GB text file |
| 23:01.25 | Tupone | I mean you write to a text file, after 24 hours you switch text file, and write to db , if you want. |
| 23:01.35 | brlcad | instead of a select lastLoginDate from tblLogin where callsign="c3po"; etc |
| 23:01.44 | brlcad | Tupone: ah, hmm |
| 23:02.16 | brlcad | by the way, blast007 .. |
| 23:02.34 | brlcad | there's something that's been going on in the new phpbb that crashes apache |
| 23:02.42 | blast007 | joy :/ |
| 23:03.10 | Tupone | bzauthd could be unreachable, database could be unreachable, you should have simple log that could be batched when all is on |
| 23:03.17 | brlcad | probably an apache bug, since it is crashing afterall, but if someone figures out what causes it .. it could be DoS prone |
| 23:03.23 | brlcad | Dec 28 18:01:58 bz kernel: pid 31394 (httpd), uid 80: exited on signal 4 |
| 23:03.40 | brlcad | get lots of those in a row for about a minute, then they go away |
| 23:03.47 | brlcad | couple times a day |
| 23:04.04 | blast007 | probably someone posting with too many smilies |
| 23:04.12 | blast007 | ;) |
| 23:04.19 | brlcad | heh |
| 23:04.24 | blast007 | any idea what is going on at the time it crashes? |
| 23:04.42 | blast007 | correlating page requests would be useful |
| 23:05.27 | brlcad | Tupone: i like the idea, though it could limit the system .. couldn't tell me that you just played on bzgirl's server 5 minutes ago, or all the servers that you've played on today |
| 23:05.39 | brlcad | at least without parsing both the DB and the log or something |
| 23:05.53 | brlcad | blast007: I haven't correlated yet |
| 23:05.56 | blast007 | k |
| 23:06.03 | brlcad | haven't "caught it in the act" |
| 23:06.11 | blast007 | :) |
| 23:06.28 | brlcad | and the requests fly by about a dozen a second, so it's hard to just watch |
| 23:07.01 | brlcad | see if I can pull up the one that just happened though with the stamp.. |
| 23:12.48 | Flash | can you grab a core file? |
| 23:16.24 | brlcad | oh shoot |
| 23:16.31 | brlcad | i think I know what's causing it |
| 23:16.36 | brlcad | never mind blast007 :) |
| 23:18.48 | brlcad | Flash: not easily, would have to reconfig some things to get them to dump core |
| 23:19.19 | brlcad | but not needed, I just found the correlation to the logs |
| 23:19.45 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@fordend.demon.co.uk) |
| 23:20.21 | blast007 | brlcad: k |
| 23:33.51 | *** join/#bzflag randomparticle (n=randompa@about/essy/snick/randomparticle) |
| 23:34.42 | CIA-3 | BZFlag: 03brlcad * 10bzflag/ (AUTHORS NEWS): attribute 'Markus' aka Links 2004 on the increased joystick button support (from 16 to 32 buttons) |
| 23:38.38 | Flash | is there widespread understanding/appreciation of "the rule of 3" among the devs? |
| 23:39.51 | randomparticle | you refer to a roman triumvirate? :) |
| 23:40.04 | Flash | nope... |
| 23:41.11 | randomparticle | am i right in thinking C structs can't be used as return values? |
| 23:41.44 | *** join/#bzflag QuantumTim (i=tpg25@pip.srcf.societies.cam.ac.uk) |
| 23:41.58 | Flash | why not? |
| 23:42.13 | randomparticle | i think that's how it used to be. not sure if it still (or ever did) holds true now |
| 23:42.46 | brlcad | it's never been the case |
| 23:42.54 | Flash | C++ has always allowed it (as long as a copy-ctor either exists or can be generated) |
| 23:43.21 | randomparticle | never which way, brlcad? |
| 23:43.42 | brlcad | you can return a struct as a value |
| 23:43.47 | randomparticle | oh good |
| 23:43.57 | brlcad | not something you "should" do in most situations, but doable |
| 23:44.08 | Flash | very small structs ;-) |
| 23:44.20 | brlcad | yeah very small |
| 23:44.28 | randomparticle | what's the problem with bigger ones? |
| 23:44.45 | brlcad | better to just return a pointer to the struct, or reference if you're c++ing |
| 23:45.15 | randomparticle | i wanted to avoid the ugly &argument thing |
| 23:45.21 | Flash | references need to pay attention to scope... |
| 23:45.42 | Flash | randomparticle: bigger structures incur the expense of making a copy on the return |
| 23:45.47 | randomparticle | and the pointer approach may not work because the original may cease to exist |
| 23:46.10 | randomparticle | ok, but if i have to copy the values in the function anyway, does it make any difference? |
| 23:46.14 | Flash | what do you need to return? |
| 23:47.06 | randomparticle | it's just a coordinate triple: struct { double x, double y, double z} blah; |
| 23:47.25 | Flash | that's trivial; go ahead and return it |
| 23:48.02 | Flash | brlcad: care to weigh in on my "rule of 3" question? |
| 23:48.15 | randomparticle | thanks |
| 23:48.58 | brlcad | Flash: sure .. which rule of 3 |
| 23:49.08 | brlcad | consensus or return |
| 23:49.16 | brlcad | or something else |
| 23:49.21 | Flash | if any of copy-ctor, operator=, or dtor are required, then all are required |
| 23:49.30 | Flash | Scott Meyers, Exceptional C++ |
| 23:49.44 | Flash | (at least, I think it's attributed to Meyers) |
| 23:49.45 | brlcad | heh |
| 23:49.54 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-233-242.hsd1.md.comcast.net) |
| 23:50.18 | Flash | conversely, don't define ctors/dtor that the compiler can generate for you |
| 23:50.19 | brlcad | i'm not sure I'd call that a "rule of three", but yes I'm familiar with that and I'm sure you'll find plenty of examples in bz that don't conform |
| 23:51.43 | brlcad | more prevalent that I know if is "rule of three" is the consensus theory that no group larger than three can form a complete consensus on a given decision |
| 23:51.48 | Flash | http://cpp.codenewbie.com/articles/cpp/1504/The_Rule_Of_Three-Page_1.html |
| 23:51.54 | Flash | (not the best reference) |
| 23:52.36 | brlcad | or the wissa concept that you get back three-fold what you give .. so if you're talking about bad code, implies that one should take the time to do it right .. sort of a correlation to the golden rule |
| 23:52.42 | brlcad | s/wissa/wicca/ |
| 23:52.48 | Flash | (a better reference) http://everything2.com/index.pl?node_id=502226 |
| 23:53.50 | brlcad | heh, and absent from http://en.wikipedia.org/wiki/Rule_of_three |
| 23:54.17 | brlcad | anyways, what's your point? :) |
| 23:59.41 | Flash | (Marshall Cline coined the phrase) |
| 23:59.46 | randomparticle | suppose you have a objc instance describing a geometric entity. you want to query it to get a list of vertices to render. what is the cleanest way of getting those vertices back? i could pass in a pointer and have the instance malloc some memory, but then the caller must remember to free it later |
