| 00:06.03 | racecar56 | hmm it seems like i'm not having any lag problems anymore |
| 00:06.36 | JefferyM | welcome to the internet |
| 00:50.09 | CIA-76 | BZFlag: 03t-s * r20399 10/trunk/bzflag/src/platform/BzfDisplay.cxx: Detect Mac OS X Version |
| 01:11.41 | *** join/#bzflag jorgenpt (n=jorgenpt@tjer.no) [NETSPLIT VICTIM] |
| 01:11.41 | *** join/#bzflag joevano (n=joevano@bzflag/developer/JoeVano) |
| 01:11.41 | *** mode/#bzflag [+v joevano] by irc.freenode.net |
| 01:12.06 | Gabe_G23 | wb joevano |
| 01:23.29 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 01:25.21 | CIA-76 | BZFlag: 03wyk3d * r20400 10/branches/gsoc_bzauthd/ (7 files in 2 dirs): |
| 01:25.21 | CIA-76 | BZFlag: Added a unified changeUserInfo function which changes can change both username,password and email at the same time and give the appropriate error. |
| 01:25.21 | CIA-76 | BZFlag: Other cleanups. |
| 01:25.50 | blast007 | Wyk3d1: yay :) |
| 01:26.40 | Wyk3d1 | and .. changing username,password,email works in phpbb and mediawiki too :) |
| 01:26.41 | CIA-76 | BZFlag: 03wyk3d * r20401 10/branches/gsoc_bzauthd_db/userstore.php: Added the changeUserInfo function. |
| 01:27.06 | Wyk3d1 | i.e you change any of those in phpbb and it updates in ldap and mediawiki |
| 01:27.57 | blast007 | cool |
| 01:28.28 | Wyk3d1 | though it's quite complicated so still needs more testing |
| 01:29.03 | Gabe_G23 | ooh |
| 01:35.11 | trepan | fwiw, getOSString() probably doesn't belong in BzfDisplay (a new file maybe?) |
| 01:36.16 | trepan | ex: SDL vs. X11 BzfDisplay subclasses; same OS, different strings? |
| 01:49.18 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 02:03.34 | *** part/#bzflag bryjen (n=bryjen@75.81.201.131) |
| 02:29.00 | *** join/#bzflag TimRiker (i=timr@t500.rikers.org) |
| 02:29.00 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 02:43.15 | racecar56 | i'll try out the new svn stuff :D |
| 02:43.39 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 03:07.54 | *** join/#bzflag racecar56 (n=racecar5@unaffiliated/racecar56) |
| 03:27.32 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 03:53.58 | *** join/#bzflag racecar56 (n=racecar5@unaffiliated/racecar56) |
| 03:54.06 | racecar56 | O_o crazy freenode |
| 04:06.54 | *** join/#bzflag Admirarch (n=Athelthr@mrush.mth.abdn.ac.uk) |
| 04:14.52 | *** join/#bzflag GvzEvxre (i=timr@bzflag/projectlead/TimRiker) |
| 04:14.52 | *** mode/#bzflag [+o GvzEvxre] by ChanServ |
| 04:19.01 | *** join/#bzflag Swigg_ (n=Default@97.95.231.32) |
| 04:54.51 | *** join/#bzflag Default__ (n=Default@97.95.231.32) |
| 05:32.37 | *** join/#bzflag Bambino (n=Bambino@unaffiliated/sniper15) |
| 05:39.43 | *** join/#bzflag Bambino_ (n=Bambino@unaffiliated/sniper15) |
| 06:17.02 | *** join/#bzflag Bambino_ (n=Bambino@unaffiliated/sniper15) |
| 06:17.36 | *** join/#bzflag Bambino (n=Bambino@unaffiliated/sniper15) |
| 06:30.39 | *** join/#bzflag rob1n_ (n=rob1n@unaffiliated/rob1n) |
| 07:20.59 | *** join/#bzflag rob1n (n=rob1n@unaffiliated/rob1n) |
| 07:48.40 | *** join/#bzflag Supertan1er (n=supertan@lt3.astro.Princeton.EDU) |
| 07:52.30 | a_meteorite | ~bz20svn |
| 07:52.31 | ibot | [bz20svn] http://my.bzflag.org/w/BZFlag_SVN and svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag |
| 08:05.03 | *** join/#bzflag TutTankAhmon (n=olivier@about/essy/MobileTarget/LePoulpe303) |
| 09:22.43 | *** join/#bzflag Swigg_ (n=Default@97.95.231.32) |
| 09:37.30 | *** join/#bzflag CBG` (n=CBG@about/essy/fan/CBG) |
| 09:41.46 | *** join/#bzflag bier|tp (n=bier@p54A562A3.dip.t-dialin.net) |
| 10:26.25 | *** join/#bzflag Upsetter (n=ups@89.246.178.120) |
| 10:30.18 | *** join/#bzflag Wyk3d (n=Wyk3d@cl-86-125-162-252.cablelink.mures.rdsnet.ro) |
| 10:44.48 | Wyk3d | blast007: so what should i do with the changes to phpbb / mediawiki ? put the full sources on svn, put just the .patch files on svn, or ? |
| 10:51.38 | Wyk3d | also, if i make changes to bzgrpmgr, should i branch it ? |
| 11:30.04 | *** join/#bzflag matelich (n=tom@c-67-185-123-234.hsd1.wa.comcast.net) |
| 11:33.35 | *** join/#bzflag _anomaly_ (n=mike@h43.26.89.75.dynamic.ip.windstream.net) |
| 12:02.50 | *** join/#bzflag racecar56 (n=racecar5@unaffiliated/racecar56) |
| 12:04.10 | *** join/#bzflag racecar56 (n=racecar5@unaffiliated/racecar56) |
| 12:08.45 | *** join/#bzflag Default__ (n=Default@97.95.231.32) |
| 12:38.22 | *** join/#bzflag Swigg_ (n=Default@97.95.231.32) |
| 13:38.22 | *** join/#bzflag bryjen (n=bryjen@63.147.94.149) |
| 13:38.22 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 14:12.20 | blast007 | Wyk3d: hmm, I'll have to think about that |
| 14:23.51 | Wyk3d | i can try to get the change to mediawiki's ldap extension added officially, it's a fairly minor change, almost like a bug fix really, it already supported everything we needed |
| 14:24.09 | Wyk3d | the change to phpbb is more extensive and custom |
| 14:24.18 | cygal | could it be integrated in they codebase? |
| 14:24.23 | Wyk3d | that's what i mean |
| 14:24.32 | Wyk3d | about the mediawiki part |
| 14:24.35 | cygal | yeah |
| 14:24.36 | Wyk3d | but not the phpbb part |
| 14:25.11 | cygal | their* |
| 14:25.41 | cygal | what you did to phpbb is add an ldap mod? |
| 14:25.58 | Wyk3d | no, it already had one |
| 14:26.17 | Wyk3d | but what i need is not so much ldap as talking to the daemon |
| 14:26.35 | Wyk3d | you cannot do the kind of complicated things i do with ldap in php |
| 14:26.45 | cygal | okay |
| 14:27.15 | Wyk3d | plus it's easier to maintain with the heavy stuff in one place |
| 14:27.53 | cygal | yeah if everything is in one place and not depending on the internals it would be easy to maintain |
| 14:28.57 | cygal | I don't know how phpbb mods work though |
| 14:30.22 | Wyk3d | some are simple like phpbb, just bind and if the user doesn't exist in phpbb yet, pull information like mail from the entry |
| 14:30.25 | *** join/#bzflag Sk3letr0n (i=IceChat7@adsl-67-122-137-158.dsl.pltn13.pacbell.net) |
| 14:30.35 | Sk3letr0n | hi someone registered my name and it kick me off server |
| 14:30.37 | Wyk3d | some have everything but the kitchen sink like mediawiki :) |
| 14:30.55 | Sk3letr0n | please delete this person |
| 14:31.03 | *** mode/#bzflag [+o blast007] by ChanServ |
| 14:31.12 | *** kick/#bzflag [Sk3letr0n!n=blast007@bzflag/developer/Blast] by blast007 (blast007) |
| 14:31.12 | *** mode/#bzflag [+b *!*=IceChat7@*.dsl.pltn13.pacbell.net] by blast007 |
| 14:31.19 | Wyk3d | it blew my mind how it was able to retrieve the user's uid from ldap when the username changed |
| 14:31.52 | Wyk3d | just needed a small fix to store the uid |
| 14:32.03 | Wyk3d | added a new table for it |
| 14:33.11 | cygal | would be great to integrate this in mediawiki |
| 14:33.30 | cygal | how do you want to keep the modifications you made to phpbb ? a simple .patch file would be a pain to maintain, no? |
| 14:34.09 | Wyk3d | i'm not sure .. there's some tight coupling with phpbb internals there |
| 14:35.06 | cygal | so someone would have to rework the patch at every update :/ |
| 14:35.44 | Wyk3d | you'd probably have to change little but yes |
| 14:35.44 | cygal | there is not anyway to *not* depend on the internals? don't they have an API you could modify to add things you need? |
| 14:35.51 | Wyk3d | nope |
| 14:36.00 | Wyk3d | well |
| 14:36.18 | cygal | I mean, try to put as less code as possible in their code |
| 14:36.20 | Wyk3d | i could just put everything related to changing user info / registering to another website |
| 14:36.42 | cygal | at least another file |
| 14:37.04 | Wyk3d | the bulk is in another file |
| 14:37.37 | Wyk3d | but if i want to use the phpbb code i need to insert some code in the middle of the ucp page |
| 14:38.00 | cygal | yeah |
| 14:38.12 | Wyk3d | that is how it's done atm |
| 14:38.37 | cygal | do you know about any other "easier-to-maintain" ways? |
| 14:38.55 | Wyk3d | again, besides making a new website, not really |
| 14:39.12 | cygal | hm |
| 14:39.14 | Wyk3d | phpbb's module system is not as flexible as mediawiki's |
| 14:39.42 | Wyk3d | and even there i'm not sure if it's fully doable |
| 14:40.31 | cygal | siggraph: where is your "expected line height" thing? if I want to enlarge the fonts in some menus, changing the bzdb vars is not the solutions? |
| 14:41.56 | cygal | Wyk3d: then what do you plan to do? |
| 14:42.14 | cygal | doing another website does not seem to be a good idea |
| 14:42.21 | Wyk3d | i don't know the current plan is to just carry on .. keep it as is |
| 14:42.35 | Wyk3d | maybe someone will find a better way or time to do a website later |
| 14:43.19 | cygal | can I see the .patch file? I'm curious |
| 14:45.24 | blast007 | the patch could always go on the patch tracker, I suppose. |
| 14:45.29 | *** mode/#bzflag [-o blast007] by blast007 |
| 14:45.48 | cygal | would not help much |
| 14:45.56 | blast007 | I mean for now |
| 14:46.19 | blast007 | eventually I'll probably throw phpBB3 into SVN so that it's easier to track the modifications we make to it |
| 14:47.39 | Wyk3d | i'm tracking it with git locally, if you want i can put it on something like github or whatever |
| 14:48.24 | cygal | blast007: there are other modifications of phpbb source code? |
| 14:48.31 | blast007 | cygal: sure |
| 14:48.36 | blast007 | like the quick reply mod |
| 14:48.44 | blast007 | and our customized template |
| 14:49.12 | blast007 | Wyk3d: put what in github? |
| 14:49.45 | Wyk3d | well the phpbb sources, it's just a git push command away .. :) |
| 14:50.18 | blast007 | wonders why we would want it in a git repo |
| 14:50.24 | Wyk3d | ok then nvm |
| 14:50.25 | Wyk3d | :) |
| 14:50.27 | blast007 | ;) |
| 14:52.04 | BulletCatcher | I see two reasonable choices. |
| 14:52.11 | BulletCatcher | 1. Put phpBB3 into SVN and modify it the same way we do with other 3rd party software under trun/src/other. |
| 14:52.17 | BulletCatcher | 2. Put just the patch file into SVN and update it as needed. |
| 14:52.18 | BulletCatcher | Maintennance of them is different, but roughly the same level of work. |
| 14:52.36 | Wyk3d | http://paste2.org/p/366515 |
| 14:52.59 | cygal | blast007: git would help if we could maintain the patch as a branch |
| 14:53.12 | cygal | then pick only the security updates |
| 14:53.47 | cygal | I don't know how SVN handles that |
| 14:53.52 | cygal | phpBB uses SVN too, btw |
| 14:54.05 | Wyk3d | (that's just change info atm, still needs some code for registration but that's easier, plus .. work in progess) |
| 14:55.12 | Wyk3d | the conditions there are copypasted from phpbb code so that would be the first thing to change at new phpbb version |
| 14:58.29 | Wyk3d | and the mediawiki changes are just http://paste2.org/p/366518 |
| 15:03.58 | BulletCatcher | If those last two pastes represent the complete set of changes at this time, then it is small enough that I would go with just putting .patch files into SVN. We can change to the other way later if needed. |
| 15:04.36 | Wyk3d | phpbb needs a bit more, also depends on whether you want to do things like banning from phpbb |
| 15:07.06 | BulletCatcher | Those two pastes show changes to 3 files. If the total number of changed files is less than about 10 then it should be easier for BZFlag as a group to manage just the .patch files in SVN. |
| 15:07.47 | Wyk3d | i think it'll stay less than 10 |
| 15:10.27 | BulletCatcher | Then I recommend putting .patch files into BZFlag SVN. If we decide we don't like it we can easily switch to the other method. |
| 15:10.57 | Wyk3d | k |
| 15:12.37 | Wyk3d | and about bzgrpmgr ? branch ? |
| 15:13.12 | BulletCatcher | I am not familiar with that. Where is the upstream? |
| 15:13.42 | Wyk3d | trunk/web/bzgrpmgr |
| 15:16.31 | BulletCatcher | Either copy the current bzgrpmgr into a deprecated branch (like the v2_0branch of BZFlag itself) and do your work on the trunk, or else branch a new version. I'll defer to blast007 on that choice. |
| 15:17.16 | blast007 | we don't even use that yet, so there might not even be a reason to branch it |
| 15:17.36 | BulletCatcher | That would be even easier. :-) |
| 15:18.08 | blast007 | suppose it would depend if we would switch to an external group manager before switching to LDAP, but it's probably safe just to push it into trunk |
| 15:18.10 | *** join/#bzflag bier|tp (n=bier@p54A550F0.dip.t-dialin.net) |
| 15:18.12 | *** join/#bzflag bier (n=bier@p54A550F0.dip.t-dialin.net) |
| 15:18.54 | BulletCatcher | If we can make a branch from a non-head revision, then just using trunk for now should be fine. |
| 15:21.43 | Wyk3d | ok |
| 15:24.31 | BulletCatcher | (And it looks like a branch can indeed be made from any historical revision.) |
| 15:28.03 | *** join/#bzflag Marzipan (n=marzi@84-119-63-99.dynamic.xdsl-line.inode.at) |
| 15:43.37 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 15:45.59 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 15:45.59 | *** mode/#bzflag [+v spldart] by ChanServ |
| 16:07.32 | *** join/#bzflag Allejo (n=alllejo@adsl-69-234-131-36.dsl.irvnca.pacbell.net) |
| 16:12.08 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 16:12.09 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 16:14.57 | ts | JefferyM: ping |
| 16:15.04 | JefferyM | ? |
| 16:15.22 | ts | Hi, I implemented that detection stuff but I didn't know where to put it |
| 16:15.34 | ts | so I put it in bzfdisplay.cxx |
| 16:15.46 | ts | but I think it doesn't belong there |
| 16:15.48 | JefferyM | it dosn't |
| 16:15.56 | JefferyM | it would go in the mac platform |
| 16:16.03 | JefferyM | and the SDL platform in a apple #def |
| 16:16.30 | ts | Is Mac platform actually used? |
| 16:16.47 | JefferyM | the most common build is SDL |
| 16:16.55 | JefferyM | but I belivce the mac code will build still |
| 16:16.59 | ts | I mean every build uses SDL on Mac OS X..and without SDL it fails since 2.0 |
| 16:17.02 | JefferyM | if it won't then we should pull it |
| 16:17.09 | JefferyM | if it stays then it should get that code |
| 16:17.17 | JefferyM | then we should remove that code |
| 16:17.28 | ts | So SDLDisplay and MacDisplay it should go in? |
| 16:17.41 | trepan | 22:35 <+trepan> fwiw, getOSString() probably doesn't belong in BzfDisplay (a new file maybe?) |
| 16:17.42 | JefferyM | or pull the mac platform |
| 16:17.44 | trepan | 22:36 <+trepan> ex: SDL vs. X11 BzfDisplay subclasses; same OS, different strings? |
| 16:17.53 | trepan | that stuff? |
| 16:17.58 | ts | trepan: oh, didn't saw that..I was sleeping at that time |
| 16:17.59 | JefferyM | yeah I agree that it should not be in display ether |
| 16:18.05 | JefferyM | we don't have an "app" |
| 16:18.09 | JefferyM | maybe we should put it with date |
| 16:18.12 | JefferyM | or something |
| 16:18.23 | ts | but date doesn |
| 16:18.23 | JefferyM | I would not cry if it was put in it's own thing |
| 16:18.26 | JefferyM | yeah |
| 16:18.31 | ts | 't call system specific stuff |
| 16:18.46 | JefferyM | timekeeper does |
| 16:19.31 | JefferyM | sugestions? a new platform file? a new file in common? |
| 16:19.39 | ts | timekeeper keeps time..date does keep date... |
| 16:19.54 | ts | dunno what to do |
| 16:19.59 | JefferyM | no, date also gives out the version number IIRC ;) |
| 16:20.56 | trepan | and protocol version, and app version (with BZ_BUILD_TYPE ;) |
| 16:21.07 | trepan | and BZ_BUILD_OS ... |
| 16:21.07 | ts | Uh yeah now that I look at it, I see |
| 16:21.11 | JefferyM | yeah little more then date |
| 16:21.21 | JefferyM | so host OS is not totaly out of place there |
| 16:21.40 | JefferyM | but I'm not saying that could be the only place |
| 16:21.49 | JefferyM | we just have to pick one, it's not that big of a deal |
| 16:22.15 | bryjen | the only date in date is build-date. it's really more about versions |
| 16:22.22 | JefferyM | yeah |
| 16:23.28 | ts | Well, then I'd think the getOSString stuff should be moved there there |
| 16:23.34 | ts | oops one there too much |
| 16:25.29 | ts | Do I have an okay or do you want to do the stuff? |
| 16:30.04 | JefferyM | put it in date, use #defs for windows and mac |
| 16:30.15 | JefferyM | make it a single function |
| 16:34.44 | JefferyM | can linux/unix just call uname? |
| 16:38.22 | cygal | yeah |
| 16:38.56 | cygal | http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html |
| 16:45.50 | ts | Is _Win32 correct for all Windows(R) versions? |
| 16:47.21 | BulletCatcher | We could use uname() on Mac OS, too. |
| 16:47.37 | ts | I don't think so |
| 16:47.58 | BulletCatcher | Yes, we could. We may or may not want to. |
| 16:48.08 | ts | It'll print the kernel version and not the Mac OS X version |
| 16:48.35 | ts | One would have to map in kernel version to the Mac OS X versions to find out what they use |
| 16:48.50 | ts | s/in/the/ |
| 16:49.45 | BulletCatcher | The problem with Linux systems is it is similarly non-trivial to get the name of the distro. |
| 16:49.54 | *** join/#bzflag MindstormsKid (n=msk@Wikipedia/MindstormsKid) |
| 16:50.15 | cygal | yeah but we don't need to know that |
| 16:50.33 | BulletCatcher | In general, what do we need/want to know? |
| 16:51.56 | ts | I think we'd rather want the Mac OS X version because with new major releases they add features and then we might know if we could use these features |
| 16:53.01 | BulletCatcher | Do we have non-hypothetical requirements to know things like OS version? |
| 16:53.30 | ts | If no one uses the old version its support could be dropped |
| 16:54.36 | cygal | MsgQueryGL and MsgQueryOS help us or will help us to know what to support |
| 16:56.13 | BulletCatcher | Generally, developers only support systems that they are able to test on. |
| 16:57.01 | cygal | sure, but if we know that everybody has OpenGL feature X, then we can make it mandatory |
| 16:57.06 | BulletCatcher | For example, although there are test cases for BeOS in configure.ac, we have no idea whether it really works. |
| 16:58.06 | cygal | this is another problem indeed |
| 16:58.17 | BulletCatcher | Are there non-hypothetical examples of "OpenGL feature X"? |
| 16:58.37 | JefferyM | ts, sure |
| 16:58.41 | cygal | I'd ask to trepan |
| 16:59.11 | cygal | BulletCatcher: but it can be simple things like texturing |
| 16:59.31 | JefferyM | BulletCatcher, the things I want to know like on mac, are the major version, and if its' PPC or Intel |
| 16:59.46 | blast007 | cygal: "support" for textures doesn't necessarily mean they work well ;) |
| 16:59.49 | JefferyM | on windows, if it's 32 or 64, and how much vista is out there. |
| 17:00.07 | JefferyM | as for GL the idea is to see how many people have what hardware |
| 17:00.14 | cygal | blast007: :p actually it does works well ingame |
| 17:00.25 | JefferyM | it's possible the server may also want to kick people if they don't have good fog, etc.. |
| 17:00.33 | JefferyM | tho that's probably a bad example |
| 17:00.33 | blast007 | cygal: I'm talking about if the video card/drivers can handle them |
| 17:00.40 | JefferyM | the GL stuff is mostly for info for now |
| 17:00.59 | cygal | blast007: what card/driver would not handle texturing? |
| 17:01.03 | JefferyM | the OS one is info I'm going to send to stats |
| 17:01.16 | blast007 | the S3 Savage IX, for instance. It could do textures, just not well |
| 17:01.18 | JefferyM | cygal, a number of them |
| 17:01.32 | blast007 | the textures would get swapped around |
| 17:01.41 | cygal | huh |
| 17:01.46 | JefferyM | rage3d cards have similar issues |
| 17:01.53 | blast007 | like I'd have the grass texture in one of the mountain spots, and I had a mountain flying overhead instead of clouds |
| 17:01.56 | blast007 | etc |
| 17:02.04 | blast007 | and the ground was white |
| 17:02.43 | blast007 | also it was slower in hardware acceleration than software acceleration :) |
| 17:03.06 | JefferyM | stupid hardware decellerators |
| 17:03.25 | blast007 | think I have the same or similar chipset in my quad PIII IBM server |
| 17:03.33 | cygal | then why make texturing mandatory? it just has a few bugs in menu, nothing important |
| 17:03.47 | blast007 | cygal: well, that S3 Savage IX is ancient |
| 17:03.52 | JefferyM | we arn't going to make it manditory right now |
| 17:03.54 | blast007 | it was in a PIII 700MHz laptop |
| 17:04.08 | JefferyM | the idea is to not support those old crappy cards at some point |
| 17:04.20 | JefferyM | bassicly say GF2 or better |
| 17:04.23 | cygal | BulletCatcher: and there a lot of GL extensions and things that got standardized in new versions, even if we won't be able to use that before a long long time :] |
| 17:04.27 | JefferyM | but that looks like it'll have to wait |
| 17:04.38 | BulletCatcher | My concern is that we seem to be building something that collects a variety of information about the client environment when we really require only a few specific details. If we go too far, it becomes spyware. |
| 17:04.51 | blast007 | we've already dropped the ability to play with software rendering on Windows |
| 17:04.56 | JefferyM | BulletCatcher, it won't get anything personal |
| 17:05.02 | JefferyM | we are not storing GL data |
| 17:05.03 | blast007 | or even with Vista's OpenGL-over-Direct3D stuff, iirc |
| 17:05.07 | JefferyM | only OS data |
| 17:05.21 | JefferyM | the GL message is not activly used, it's just there for now |
| 17:05.31 | JefferyM | it could be used when client scripting is back online |
| 17:05.35 | BulletCatcher | Some people may consider the details of their hardware to be personal. :-| |
| 17:05.52 | JefferyM | then hack out that message :) |
| 17:06.03 | blast007 | BulletCatcher: but those people probably think their IP address is to be kept secret ;) |
| 17:06.10 | BulletCatcher | :-) |
| 17:06.10 | JefferyM | your browser sends up some of your hardware info when you hit a web page, even if it's not used |
| 17:06.59 | BulletCatcher | Yes. The details in browser strings should be acceptable. |
| 17:07.15 | blast007 | man, building this BZFriends thing is a pain.. |
| 17:07.18 | JefferyM | if we start collecting GL info then we throw a message in the startup text that tells them we'll do that, and they can quit if they want |
| 17:07.30 | cygal | it's nothing personal, and only here for making the game better |
| 17:07.47 | JefferyM | the current system for GL data is not for data collection but for capability query |
| 17:07.53 | cygal | but seriously, who would want to hide their gl info? |
| 17:08.00 | bryjen | "If you're embarrassed by your creaky old hardware, select Quit now" |
| 17:08.02 | JefferyM | security freaks |
| 17:08.19 | JefferyM | there will always be some people that don't like some thing that we do |
| 17:08.31 | JefferyM | BulletCatcher is right, we do need to make sure we don't go too far |
| 17:08.48 | JefferyM | like I'd not grab free disk space, ram, or CPU serial number or anything |
| 17:08.56 | BulletCatcher | I am borderline "security freak" so I understand the concerns of the truly paranoid. |
| 17:09.12 | JefferyM | for the OS I just want the version and general CPU type |
| 17:09.19 | BulletCatcher | That should be fine. |
| 17:09.32 | ts | Heck, even I think OS version and GL info is fine |
| 17:09.45 | JefferyM | ts, it dosn't matter, we arn't storing GL |
| 17:09.58 | JefferyM | GL is currently only exposed to lua scripting IIRC |
| 17:10.04 | cygal | but we could in a near future |
| 17:10.12 | JefferyM | possibly |
| 17:10.13 | cygal | or not that near, but still |
| 17:10.32 | JefferyM | if we decide to grab GL data, we have to figure out what to query |
| 17:10.43 | JefferyM | because the system dosn't really let you get a full enumeration |
| 17:10.46 | ts | I'd think it's good to know the installed hardware/software of our users. We don't store personal information.. |
| 17:10.47 | JefferyM | you have to know what to ask for |
| 17:11.04 | JefferyM | ts, what are you talking about, we sure as hell do store personal info :) |
| 17:11.08 | JefferyM | we just don't give it out |
| 17:11.18 | JefferyM | if we didnt' store personal info we'd not have to do COPPA |
| 17:11.31 | ts | Hmm, not too personal... |
| 17:11.45 | JefferyM | by law what we store is considered personal |
| 17:12.00 | cygal | bzbb is something else |
| 17:12.43 | *** join/#bzflag Chestal (i=thilo@vmax.unix-ag.uni-siegen.de) |
| 17:12.43 | *** join/#bzflag Allejo (n=alllejo@adsl-69-234-131-36.dsl.irvnca.pacbell.net) |
| 17:12.43 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 17:12.43 | *** join/#bzflag Marzipan (n=marzi@84-119-63-99.dynamic.xdsl-line.inode.at) [NETSPLIT VICTIM] |
| 17:12.43 | *** join/#bzflag bryjen (n=bryjen@63.147.94.149) [NETSPLIT VICTIM] |
| 17:12.43 | *** join/#bzflag JonathanD (i=Jonathan@freenode/staff/jonathand) [NETSPLIT VICTIM] |
| 17:12.43 | *** join/#bzflag brad (n=brad@moooo.org) |
| 17:12.43 | *** join/#bzflag siggraph (n=sean@bz.bzflag.bz) |
| 17:12.44 | *** join/#bzflag cods (n=cods@rsbac/developer/cods) [NETSPLIT VICTIM] |
| 17:12.44 | *** mode/#bzflag [+ov Chestal bryjen] by irc.freenode.net |
| 17:12.57 | bryjen | wheeee |
| 17:13.55 | blast007 | :) |
| 17:14.30 | ts | make |
| 17:14.35 | ts | ooh wrong window |
| 17:14.47 | blast007 | Enter root password: |
| 17:14.49 | BulletCatcher | not war? |
| 17:15.07 | JefferyM | cygal, no it's not, it's all kept on the same system |
| 17:15.17 | JefferyM | we tie it all togeher with our "user management" |
| 17:15.24 | JefferyM | since we use bzdb for the game |
| 17:15.30 | JefferyM | bzbb I mean |
| 17:15.42 | cygal | OS version is tied to users? |
| 17:15.55 | JefferyM | it will be kept in the log in the stats system |
| 17:16.03 | JefferyM | since they will also give us the BZID |
| 17:16.09 | JefferyM | so we can tie them togeher |
| 17:16.13 | JefferyM | so yeah, |
| 17:16.17 | ts | JefferyM: What headers does Win32 version query need? |
| 17:16.19 | JefferyM | now I don't plan on keeping aggrigate states |
| 17:16.22 | JefferyM | windows.h |
| 17:16.41 | JefferyM | sorry I only plan on keeping aggrigate stats, not like a history of machines |
| 17:16.44 | JefferyM | per user |
| 17:16.49 | ts | I don't see where it is included.. |
| 17:16.51 | JefferyM | but the logs will have that data |
| 17:17.26 | JefferyM | ts, it's pulled in from the windows display |
| 17:17.42 | JefferyM | just paste the code into the #def section, I'll make it build |
| 17:17.57 | JefferyM | getting bzfs to use windows is "interesting" |
| 17:19.30 | BulletCatcher | As long as the hardware info is encoded into a variable length string, we can change what we send over the wire without breaking protocol. |
| 17:19.31 | BulletCatcher | So start with the minimum info that we have a clear interest in: OS, OS major version, hardware type. Add more later when we have specfic needs. |
| 17:21.03 | JefferyM | yeah that's why I did it as it's own message |
| 17:21.06 | JefferyM | it's just a string |
| 17:21.22 | JefferyM | nbo_packstdstr :) |
| 17:21.36 | cygal | if we stored those infos in another way, so we can't tie them to users, wouldn't it clear the concerns about privacy? |
| 17:21.54 | BulletCatcher | For example the "uname -smr" command on my box returns: "Linux 2.6.27.25-170.2.72.fc10.x86_64 x86_64", is that good enough? |
| 17:22.23 | BulletCatcher | On my MacBook with 10.4.11 it returns "Darwin 8.11.1 i386". |
| 17:23.06 | JefferyM | BulletCatcher, it would be nice to know what distro, debian, ubuntu, redhat etc.. to help with package managers |
| 17:23.14 | JefferyM | but that's the only other thing I'd like to know |
| 17:23.16 | ts | On my MP this will return Darwin 9.8.0 i386 |
| 17:23.18 | cygal | we can't know the distro easily |
| 17:23.18 | BulletCatcher | Distro name is harder to get. |
| 17:23.22 | JefferyM | ok |
| 17:23.30 | cygal | in Debian, it's in "/etc/debian_version" |
| 17:23.35 | BulletCatcher | The method varies by distro. |
| 17:23.39 | ts | The kernel versions differ |
| 17:23.40 | JefferyM | It'd just be nice to know how linux people get the game |
| 17:23.50 | JefferyM | so we can know what packages to put more effort into |
| 17:23.55 | cygal | well we have sf stats and package managers stats |
| 17:23.56 | ts | bleh reading and coding slows me down.. |
| 17:24.05 | JefferyM | cygal, but that's just downloads |
| 17:24.09 | JefferyM | this is actual RUNS |
| 17:24.17 | JefferyM | it's good to compare the 2 |
| 17:25.04 | cygal | but not that useful compared to difficulty to know that and privacy issues |
| 17:25.31 | JefferyM | some of the OS info is now sent up to the server EVERY time |
| 17:25.38 | JefferyM | since the OS is in the build string |
| 17:25.42 | JefferyM | at least the build OS |
| 17:25.50 | JefferyM | and noone has complained about that |
| 17:26.02 | JefferyM | we have logs that track that to specific people too |
| 17:26.14 | cygal | do people know that? |
| 17:26.14 | JefferyM | so I'm not sure why this seems new |
| 17:26.20 | JefferyM | client query man |
| 17:26.25 | JefferyM | been in the game since day one |
| 17:26.43 | cygal | a lot of things seem new when we start to discuss about it :) |
| 17:26.44 | JefferyM | as an admin in game you can get the client info from any player |
| 17:26.54 | JefferyM | most leauges do that |
| 17:26.57 | JefferyM | it's well known |
| 17:27.30 | JefferyM | now I do not plan on EVER releasing data or stats that would let anyone match this data to a player |
| 17:27.35 | JefferyM | as in fom what stats will collect |
| 17:27.49 | JefferyM | stats will just show names and scores, and last server played, etc.. |
| 17:27.58 | JefferyM | the OS stuff will be put into a usage report |
| 17:28.06 | JefferyM | and the logs are never publicly exposed |
| 17:28.44 | JefferyM | I mean if oyu look at the big IM providers, they keep data that ties a LOT of stuff to specific people, but never release it |
| 17:29.01 | JefferyM | does a web browser show your distro? |
| 17:29.33 | BulletCatcher | The current clientquery info is *very* limited. It has the kernel version for Darwin but not for Linux or Windows. |
| 17:29.56 | JefferyM | it has the kernel for what the system was built on, not running IRC |
| 17:30.12 | JefferyM | since the app version is a premade string at compile time |
| 17:30.21 | JefferyM | and most mac people don't build |
| 17:30.30 | JefferyM | or does it get a runtime thing? |
| 17:30.52 | JefferyM | with this message, we can probably pull some of the stuff out of the client query string |
| 17:30.57 | JefferyM | and out of the "version" |
| 17:31.06 | BulletCatcher | My Firefox on Fedora browser string looks like this: "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.12) Gecko/2009072110 Fedora/3.0.12-1.fc10 Firefox/3.0.12" |
| 17:31.16 | BulletCatcher | So yeah, that is quite a bit of info. |
| 17:31.26 | JefferyM | ok, then if distro is hard, I won't cry if we don't have it |
| 17:31.29 | JefferyM | it would just be nice |
| 17:31.58 | BulletCatcher | We can do it, but it will require separate special cases for most of them. |
| 17:32.02 | JefferyM | if we really need the distro for packages we could build the package version/system into the build string. |
| 17:32.06 | JefferyM | yeah it's ok then |
| 17:32.10 | ts | BulletCatcher: There is even more information from the browser in the http request string |
| 17:32.26 | BulletCatcher | ts: Yes, but that usually isn't logged. |
| 17:32.34 | ts | Anyone can |
| 17:33.01 | JefferyM | my bigest problem right now is that we don't get granularity on the major version of OSX and windows, and that info is very handy when building our binary versions |
| 17:33.08 | JefferyM | since those are the 2 major binary distros |
| 17:33.17 | JefferyM | the linux info is just a bonus |
| 17:33.32 | JefferyM | so if it's hard, leave it out |
| 17:33.43 | CIA-76 | BZFlag: 03t-s * r20402 10/trunk/bzflag/ (7 files in 4 dirs): Move getOSString() to buildDate.cxx |
| 17:33.49 | JefferyM | this thing should not make the build process anymore difficult |
| 17:34.21 | *** join/#bzflag Yassen (n=Yassen@c-24-16-60-208.hsd1.wa.comcast.net) |
| 17:36.33 | JefferyM | as for the GL stuff, the current implementation is mostly for getting GL support info so we can possibly change what data we send to the client and for the use of client side graphical scripting later |
| 17:37.01 | JefferyM | finding shader support, etc... |
| 17:37.24 | JefferyM | or sending a higher res map to better hardware |
| 17:38.52 | JefferyM | if someone wants to write up a blurb in the readme about what data we log in the stats system, and how we'll never give it out in a personal way, that'd be good too |
| 17:40.31 | JefferyM | if it becomes something that is a problem later we can aways make a "privacy" bzdb var that people can set, but since we arn't storing and sending anything more then a browser does now I don't think we have to worry about it. |
| 17:41.41 | BulletCatcher | Now that we have had this discussion, I am confident that we won't go too far with data collection. Thanks, everyone. |
| 17:42.02 | JefferyM | heh |
| 17:42.25 | JefferyM | yeah I just want to know how many people are still on PPC, or 10.3, or windows 2000, etc... |
| 17:42.49 | JefferyM | it's a lot simpler if we can just build the mac bin for 10.5, for instance |
| 17:43.34 | JefferyM | 3.0 isn't really going to support 2000 tho, so that'll be interesting |
| 17:44.15 | BulletCatcher | If we drop support for something that gets used, we'll hear about it on BZBB. I'm not too worried about that. :-) |
| 17:44.25 | JefferyM | yeah I know |
| 17:44.37 | JefferyM | but in the future it'll be nice to know BEFORE we drop it |
| 17:44.44 | ts | Could be many people use Windows® 2000..I know at least of one school still using it |
| 17:45.04 | JefferyM | ts, possibly. don't realy have an easy way to support them |
| 17:45.10 | JefferyM | MS desuported them |
| 17:45.13 | JefferyM | no more runtimes for them |
| 17:45.16 | BulletCatcher | "patches welcome" |
| 17:45.26 | JefferyM | they could probalby build themseves with VC 2005 |
| 17:45.38 | JefferyM | but our bin version wont |
| 17:45.56 | JefferyM | as for 9x, that's right out, we are now calling API calls that don't exist in those versions |
| 17:46.28 | ts | I know no one using 9x anymore |
| 17:46.30 | JefferyM | BZ also upgraded to directX 8, so that changes what is supported a bit too |
| 17:47.45 | blast007 | JefferyM: Windows 2000 supports the latest visual C++ runtimes |
| 17:47.56 | blast007 | it was the .net 3.5 framework that isn't supported |
| 17:48.01 | JefferyM | ahh |
| 17:48.05 | blast007 | 2.0 works though |
| 17:48.21 | JefferyM | I wonder how the last set of VC runtime updates work on 2k |
| 17:48.41 | JefferyM | we may have some suck coming down the pipe with regards to the VC9 runtimes |
| 17:48.50 | blast007 | which ones? I was using the Visual C++ 2008 SP1 redist |
| 17:48.51 | JefferyM | we may have to install 2 packages |
| 17:49.05 | JefferyM | no, the SP1 ATL update |
| 17:49.19 | JefferyM | it seems that there is an update for the build system and the runtimes |
| 17:49.26 | JefferyM | and if they missmatch stuff goes bad |
| 17:49.39 | JefferyM | it's affecting our work builds now |
| 17:49.59 | JefferyM | trying to see if the new runtime "patch" is a full set of runtimes, or an update to the old runtimes |
| 17:50.09 | JefferyM | if it's an update, we may have to do 2 runtime installs |
| 17:50.26 | blast007 | are you just referring to SP1? or is there a hotfix to that? |
| 17:50.33 | JefferyM | a hotfix to that |
| 17:50.45 | JefferyM | that was pushed to VC9 via MS update |
| 17:51.04 | JefferyM | it happened late last week |
| 17:51.23 | JefferyM | an "ATL security update" |
| 17:51.33 | JefferyM | all our dev systems got the update |
| 17:51.53 | JefferyM | now our bins won't run on systems that don't have VC |
| 17:52.10 | JefferyM | ok, looks like we can still just install one runtime, it just has to be the newer one |
| 17:52.22 | JefferyM | has been having a fun morning :) |
| 17:52.35 | blast007 | does that even apply to us? |
| 17:52.39 | JefferyM | yeah |
| 17:52.46 | blast007 | "The Active Template Library (ATL) is a set of template-based C++ classes that simplify the development of Component Object Model (COM) objects." |
| 17:52.58 | JefferyM | yeah, but it's built as part of the base runtimes |
| 17:53.01 | JefferyM | and they got updated |
| 17:53.05 | JefferyM | we don't even use ATL |
| 17:53.45 | blast007 | would it affect our binary then? |
| 17:53.59 | JefferyM | if the system that built the bin had the update |
| 17:54.24 | JefferyM | and since thats being pushed out it's highly likely that it'll happen |
| 17:55.00 | JefferyM | bassicly we just need to make sure we use this redist in our installer and we are good, http://www.microsoft.com/downloads/details.aspx?familyid=2051A0C1-C9B5-4B0A-A8F5-770A549FD78C&displaylang=en |
| 17:55.29 | blast007 | ok |
| 17:56.14 | JefferyM | it's kinda like SP1.1 :) |
| 17:59.40 | CIA-76 | BZFlag: 03blast007 * r20403 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: Point to the VC redist with the "ATL Security Update". |
| 18:01.28 | JefferyM | does the installer download the runtime from the intertubes? |
| 18:02.10 | blast007 | nope |
| 18:02.25 | blast007 | just a comment in the file of what to download for building the installer |
| 18:02.36 | JefferyM | ahh ok |
| 18:03.35 | JefferyM | bzflag needs V.A.T.S. |
| 18:04.07 | blast007 | Video-Assisted Thoracoscopic Surgery? ;) |
| 18:04.18 | JefferyM | Vault Assisted Targeting System |
| 18:04.30 | blast007 | that was my second guess |
| 18:04.45 | JefferyM | did ares update recently? |
| 18:06.20 | JefferyM | uggs at ts's #def style |
| 18:11.43 | BulletCatcher | There are newer upstream versions of both ares and curl. I can't see a compelling reason to upgrade what we have in svn, but I plan to do it anyway because it will make future upgrades (which may be urgent) easier. |
| 18:12.12 | JefferyM | it didn't change, our distributed build system just burped on it |
| 18:13.57 | CIA-76 | BZFlag: 03JeffM2501 * r20404 10/trunk/bzflag/src/date/buildDate.cxx: |
| 18:13.57 | CIA-76 | BZFlag: make #defs more inline with existing format |
| 18:13.57 | CIA-76 | BZFlag: add missing ; |
| 18:13.57 | CIA-76 | BZFlag: add required windows headers. |
| 18:17.20 | ts | JefferyM: I'm a Haskell coder ;) |
| 18:17.26 | JefferyM | so? |
| 18:17.45 | JefferyM | we are suposed to at least TRY to match the existing code |
| 18:17.51 | JefferyM | I mean that's what I get yelled at for all the time |
| 18:18.59 | ts | Well, I didn't thought there was some rule..so I put like I use to..but now I'll remember |
| 18:19.19 | JefferyM | there was on in the other format right above it ;) |
| 18:19.25 | JefferyM | it's all good now :) |
| 18:19.49 | ts | I guess I was too busy reading the chat |
| 18:20.27 | JefferyM | can someone throw the uname code in there for linux? |
| 18:22.34 | BulletCatcher | I'll do it later today unless someone else beats me to it. |
| 18:22.44 | JefferyM | thanks |
| 18:23.32 | BulletCatcher | If any aspiring developers are around, this is an easy change that will get your feet wet. |
| 18:26.46 | ts | JefferyM: The Mac stuff doesn't use TextUtils..maybe take that into the _WIN32 def? |
| 18:27.08 | JefferyM | it's not windows specific, I don't think it matters much |
| 18:27.14 | JefferyM | we kinda use it all over |
| 18:27.31 | ts | and maybe someone wants to "clean" my Mac part..not sure if people like the way I code |
| 18:29.22 | JefferyM | yay, only 885 more errors to go :) |
| 18:31.31 | ts | 885? |
| 18:31.37 | JefferyM | yep |
| 18:31.47 | JefferyM | nother glorious day in the corps ;) |
| 18:31.53 | ts | Where? BZFlag? |
| 18:31.58 | JefferyM | nope |
| 18:32.10 | JefferyM | post.lib and postIO.dll |
| 18:32.25 | JefferyM | that's what happens when you remove a key structure from the header file |
| 18:33.46 | JefferyM | it was a couple thousand eariler this week |
| 18:34.27 | ts | Eww I kind of know this |
| 18:35.46 | ts | Once in university we had to program a little tool but we tested with telnet and so we got a \n after each input but our task was to do it without \n..and so we had to change the entire code we wrote because different types |
| 18:36.02 | ts | It was such a pain |
| 18:37.14 | BulletCatcher | Many of the lessons learned at school are not explictly in the curriculum. |
| 18:37.30 | *** join/#bzflag TimRiker (i=timr@bzflag/projectlead/TimRiker) |
| 18:37.30 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 18:59.33 | *** join/#bzflag linus52 (n=jmc@starfury.cs.rit.edu) |
| 18:59.49 | linus52 | afternoon everyone. back again |
| 19:00.16 | linus52 | blast007 -- I have a little info from printf-style debugging. :-) |
| 19:02.25 | blast007 | ok |
| 19:03.15 | linus52 | I went into SDLMedia::doReadSound as you suggested, and put in something just to see if I was getting there. I wasn't, so I traced back.. |
| 19:03.49 | linus52 | and found in BzfMedia there is the readSound function |
| 19:03.52 | blast007 | was that after you ran ./configure again so that it was building with SDL support? |
| 19:04.04 | linus52 | yeah, I am building with SDL again |
| 19:04.06 | blast007 | k |
| 19:04.42 | linus52 | readSound tries to call doReadSound with different file extensions, and when it fails it gives the |
| 19:04.46 | linus52 | Unable to locate [phantom] audio file (media dir is set to /usr/local/versions/bzflag-2.0.12/share/bzflag) |
| 19:04.49 | linus52 | message, so |
| 19:05.12 | linus52 | I put a bunch of debug std::couts in there to see what's up. |
| 19:05.37 | linus52 | what seems to be happening is it's calling this function later in the file: |
| 19:05.48 | *** join/#bzflag Upsetter (n=ups@89.246.178.120) |
| 19:05.49 | linus52 | #ifdef HAVE_SDL |
| 19:05.49 | linus52 | float* BzfMedia::doReadSound(const std::string&, int&, int&) const |
| 19:05.49 | linus52 | { |
| 19:05.49 | linus52 | <PROTECTED> |
| 19:05.49 | linus52 | } |
| 19:05.50 | linus52 | #else |
| 19:06.26 | a_meteorite | pastebin |
| 19:06.40 | linus52 | and it's happily returning null every time it gets called, eventually bombing out at the bottom of readSound |
| 19:07.08 | blast007 | hmm |
| 19:07.58 | linus52 | so I am assuming HAVE_SDL means it really is happy with my version of SDL, but how do we get it to pull the doReadSound from SDLMedia instead of here? |
| 19:08.15 | linus52 | that's what I am trying to work out at this point. |
| 19:09.11 | Wyk3d | so, with the confirmation email sent from the client, the user should not be able to log in at the forum until he confirms right ? |
| 19:09.39 | Wyk3d | s/from the client/from the daemon when registration was done through the client |
| 19:18.19 | blast007 | linus52: for the latest 2.0.x code from SVN (v2_0branch is at 2.0.13) I'm hitting the doReadSound in the SDLMedia.cxx file, using Ubuntu linux |
| 19:19.32 | blast007 | Wyk3d: right, I think the idea was that they could play a bit (few times?) but that's it |
| 19:20.57 | blast007 | linus52: have you tried doing a clean build? |
| 19:22.10 | *** join/#bzflag ep (n=quassel@about/essy/guynextdoor/ep) |
| 19:23.28 | *** join/#bzflag racecar56 (n=racecar5@unaffiliated/racecar56) |
| 19:24.19 | racecar56 | i used the blender export plugin 2.0.4beta4 (i think) and exported my bzw file, and the teleporters don't work, using bzflag 2.99 svn |
| 19:24.59 | blast007 | pastebin the teleporter/link code |
| 19:25.05 | blast007 | ~bzpastebin |
| 19:25.05 | ibot | i guess bzpastebin is http://pastebin.bzflag.bz or a place to put large chunks of text so as not to flood a channel |
| 19:25.33 | racecar56 | can i just paste the whole thing? it isn't enormous |
| 19:25.39 | racecar56 | in pastebin of course |
| 19:25.42 | blast007 | sure |
| 19:25.45 | racecar56 | k |
| 19:27.16 | racecar56 | http://pastebin.bzflag.bz/m43fe9b02 |
| 19:28.19 | racecar56 | realizes that the from and to say *, but originally they said teleport1 to teleport2 |
| 19:28.27 | racecar56 | that's when it didn't work |
| 19:31.59 | blast007 | so what exactly "doesn't work" ? |
| 19:32.19 | racecar56 | the teleporters don't make me go anywhere |
| 19:32.24 | racecar56 | they don't do anything |
| 19:32.59 | blast007 | I teleported just now with the map provided, or should I be replacing the * with the teleporter names? |
| 19:33.33 | blast007 | hmm, wait, I was using 2.0.13 ;) |
| 19:33.51 | blast007 | but did it do anything with * in the link? |
| 19:33.56 | racecar56 | replace * with teleporter names |
| 19:34.03 | racecar56 | i can fix that in the pastebin if you want |
| 19:34.12 | blast007 | you do realize that you have to specify the side of the teleporter if you use the name, right? |
| 19:34.18 | racecar56 | ah |
| 19:34.21 | blast007 | and you have to have a link going each direction |
| 19:34.40 | blast007 | so to make two teleporters link to each other's side, you need 4 links |
| 19:34.44 | racecar56 | put 2 links, one going one way the other one going the other way? |
| 19:35.00 | racecar56 | oh |
| 19:35.29 | linus52 | blast007 ... each rebuild I do a make clean; make install |
| 19:36.15 | blast007 | racecar56: for example, you'd have to do links to: teleporter1:f to teleporter2:f, teleporter1:b to teleporter2:b, teleporter2:f to teleporter1:f, and teleporter2:b to teleporter1:b |
| 19:37.13 | blast007 | linus52: okay |
| 19:38.14 | blast007 | not sure why it's not calling the SDL version of that function then |
| 19:39.19 | racecar56 | blast007: now i have to jump into the teleporter for it to work O_o |
| 19:39.28 | racecar56 | blast007: driving into it dosen't work |
| 19:40.50 | racecar56 | blast007: never mind |
| 19:41.38 | racecar56 | blast007: never mind the never mind O_. i was right |
| 19:43.57 | blast007 | yeah, I was having that problem even on 2.0.x |
| 19:44.47 | blast007 | try making your positions and sizes a little more sane (less odd decimals or use whole numbers) |
| 19:44.52 | blast007 | might just be some floating point issue |
| 19:45.44 | linus52 | I feel better knowing I am not the only one scratching my head, :-) |
| 19:46.48 | blast007 | linus52: have you tried the SVN trunk code? (2.99.x) |
| 19:47.07 | linus52 | I did; although that blew up mid-compile over something else |
| 19:47.20 | linus52 | I didn't feel like getting deeper into it at the time |
| 19:47.34 | blast007 | hmm |
| 19:48.30 | *** join/#bzflag Upsetter1 (n=ups@89.246.161.64) |
| 19:49.04 | linus52 | it has beena *LOOOOOOOOONG* time since I did much coding -- would an explicit call to SDLMedia::doReadSound be possible? |
| 19:49.54 | blast007 | not sure |
| 19:50.01 | blast007 | it's suppose to do it automatically |
| 19:59.23 | *** join/#bzflag Erroneous (n=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 19:59.23 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 20:02.24 | racecar56 | blast007: :| it's still not working right |
| 20:02.43 | blast007 | linus52: ah, think I figured it out |
| 20:02.49 | blast007 | the solaris stuff isn't set up to use SDL |
| 20:03.36 | blast007 | if you look in src/platform/SolarisPlatformFactory.cxx, you don't see anything about SDL |
| 20:04.44 | blast007 | but if you look in at least the WinPlatformFactory, there is checks for if it's using SDL |
| 20:04.57 | JefferyM | IIRC there were issues with the solaris port of SDL at one point |
| 20:05.16 | blast007 | same with src/platform/MacOSX/MacPlatformFactory.cxx |
| 20:05.33 | blast007 | JefferyM: k |
| 20:05.51 | blast007 | linus52: so easiest is to just not build with SDL and get any deps that you need for that |
| 20:05.56 | JefferyM | isn't here a SDL platform factory? |
| 20:06.29 | blast007 | JefferyM: yes |
| 20:06.35 | blast007 | is it supposed to be using that? |
| 20:06.42 | JefferyM | cus IIRC SDL is treated as it's own "Platform" and dosn't need to use the other platforms |
| 20:06.44 | JefferyM | yeah |
| 20:06.56 | JefferyM | if you are doing SDL the only platform files you use are the SDL ones |
| 20:06.59 | JefferyM | none of the native stuff |
| 20:07.12 | racecar56 | blast007: now all it is is a thing i can drive through and it dosen't do anything even jumping dosen't seem to help |
| 20:07.14 | JefferyM | SDL platform hsa it's own #defs for the variuos differnces in the SDL plats |
| 20:07.17 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 20:08.18 | blast007 | JefferyM: he was hitting the BzfMedia::doReadSound function in src/platform/BzfMedia.cxx that just returns NULL right away |
| 20:08.20 | JefferyM | how's it going KingRobot ? |
| 20:08.26 | blast007 | within the #ifdef HAVE_SDL |
| 20:08.30 | racecar56 | blast007: want me to pastebin? |
| 20:08.35 | KingRobot | JefferyM: Just the one I wanted to see |
| 20:08.37 | JefferyM | blast007, that means that his platform didn't implement the virtual function |
| 20:08.39 | blast007 | racecar56: sure |
| 20:08.52 | KingRobot | JefferyM: Had a chance to look over my last commit? |
| 20:08.54 | JefferyM | what derived class does he have |
| 20:09.02 | JefferyM | KingRobot, you removing 2 files? |
| 20:09.08 | JefferyM | I didn't think it was enough to even look at |
| 20:09.15 | KingRobot | JefferyM: the last set of commits :) |
| 20:09.23 | racecar56 | blast007: http://pastebin.bzflag.bz/d4129b6 |
| 20:09.25 | JefferyM | no I have not |
| 20:09.29 | JefferyM | what did they do? |
| 20:10.35 | KingRobot | JefferyM: The more I got into improving the API, the more [unnecessarily] complex things became due to the frontend/backend/sockets design |
| 20:10.46 | JefferyM | ok |
| 20:11.13 | KingRobot | JefferyM: So after talking with jorgenpt and trepan, I've opted to remove all that |
| 20:11.15 | JefferyM | so you removed that entire system? |
| 20:11.23 | JefferyM | and jorg was ok with it? |
| 20:11.33 | KingRobot | I'm replacing it with a simple set of callbacks. |
| 20:11.38 | JefferyM | k |
| 20:11.45 | JefferyM | as long as he's fine with it |
| 20:11.48 | JefferyM | that's the big thing |
| 20:11.54 | JefferyM | does sound simpler |
| 20:12.07 | JefferyM | never understood why a bot would need to be a seperate app |
| 20:12.29 | KingRobot | The only difficult part now will be making sure the callbacks work properly with the multithreading |
| 20:12.49 | JefferyM | object locks are your friend :) |
| 20:13.04 | JefferyM | throw a BDL around your accessors and you are good |
| 20:13.12 | blast007 | racecar56: two of your links don't have any source or destination |
| 20:13.52 | racecar56 | blast007: haha i did something stupid xD lemme fix that (the pastebin thing) |
| 20:14.08 | blast007 | I copied the one at the end to test |
| 20:14.18 | KingRobot | JefferyM: BDL? I've used pthread_mutex and friends before, but am not familiar with that term |
| 20:14.21 | racecar56 | blast007: http://pastebin.bzflag.bz/d664b233a the actual thing |
| 20:14.26 | JefferyM | Big Damn Lock ;) |
| 20:14.36 | KingRobot | lol, ok |
| 20:14.50 | blast007 | racecar56: you still have two links with no "to" or "from" ;) |
| 20:15.38 | blast007 | kinda weird though |
| 20:15.44 | blast007 | it teleporters shots but not the tank |
| 20:16.11 | blast007 | ah, jumping through does work |
| 20:16.24 | blast007 | so your teleporter is probably too high and you're driving under it |
| 20:16.43 | blast007 | your box sizes are still wacky |
| 20:16.56 | blast007 | and positions |
| 20:17.40 | KingRobot | What about the event callbacks? The way the bot API is built, you have a main loop that is doing stuff in it's own thread, and then event methods that are called by the bzrobots thread (for example, when is killed) |
| 20:18.25 | JefferyM | you can lock during the event calls |
| 20:18.46 | JefferyM | or you can lock during the API calls that it may make back in the main thread |
| 20:19.07 | JefferyM | all you have to do is make sure that the main thread only has one bot thread calling stuff at a time |
| 20:19.54 | JefferyM | do the events just return data to the main thread? or do the bot threads call functions in the main thread to do stuff like changes states? |
| 20:20.16 | KingRobot | Depends on the bot; I was actually thinking of how to ensure the bot would be thread safe, but I guess that will be up to the bot designer. |
| 20:20.27 | JefferyM | you can make the API thread safe |
| 20:20.40 | JefferyM | then the bot can't realy do anything that will screw up the main thread |
| 20:20.51 | JefferyM | does the bot thread call API functions? |
| 20:21.02 | JefferyM | or just build up data that is sent back via event returns? |
| 20:21.46 | KingRobot | The bot thread will call all sorts of API functions |
| 20:21.55 | JefferyM | then the simplest thing to do is to do a single lock object for the API |
| 20:22.08 | JefferyM | and lock that for each API call |
| 20:22.13 | KingRobot | The events may or may not call API functions, depending on the designer, but they are not run by the bot thread. |
| 20:22.21 | JefferyM | and also make the main thread lock that before it edits anything the API can access. |
| 20:23.08 | JefferyM | what you mostly need to make sure is that when a bot calls an API function (Whenever) that noone else is using that data |
| 20:23.24 | JefferyM | since the bot thread can do that at any time, you have to lock up all access to that data in a lock |
| 20:23.41 | KingRobot | Yeah, that should be pretty easy. |
| 20:23.52 | JefferyM | depends on how many places you have to lock |
| 20:23.58 | KingRobot | How do the server-side bots to it? |
| 20:24.05 | JefferyM | they arn't threaded |
| 20:24.11 | *** join/#bzflag mrapplecomputer1 (n=cjbruess@c-69-180-173-220.hsd1.mn.comcast.net) |
| 20:24.18 | KingRobot | Oh, okay |
| 20:24.25 | JefferyM | bzfs is not thread safe |
| 20:24.46 | mrapplecomputer1 | hey ummm, all of you people in mofo.* groups, might wanna check out planet mofo. i think someone was screwing with /poll set. unless mofo now has yellow skies with rain......... |
| 20:24.55 | JefferyM | the API could be made threadsafe, but it'd be hard to make the rest of bzfs lock when needed. |
| 20:25.14 | JefferyM | mrapplecomputer1, they have there own channel, you should go there and tell them |
| 20:25.23 | mrapplecomputer1 | hmm where |
| 20:25.35 | JefferyM | ##planetmofo IIRC |
| 20:25.45 | mrapplecomputer1 | thanks |
| 20:25.45 | JefferyM | use your channel search |
| 20:27.12 | mrapplecomputer1 | ok thanks |
| 20:36.01 | linus52 | blast007 --- good news. this time I could compile --without-SDL |
| 20:36.11 | linus52 | I have sound now. :-) |
| 20:36.14 | blast007 | yay :) |
| 20:37.00 | linus52 | thank you for your help stepping through this |
| 20:38.19 | blast007 | no problem, glad it works now |
| 20:39.24 | linus52 | can a 2.0.10 client play on a 2.0.12 server? I may also have this installed in our iMac labs. :-) |
| 20:39.33 | blast007 | yup |
| 20:39.34 | JefferyM | yeah |
| 20:39.39 | linus52 | tres cool. |
| 20:39.40 | blast007 | 2.0.x is compatible |
| 20:39.42 | JefferyM | all the 2.0.x are compatabile |
| 20:39.48 | JefferyM | we break at major versions |
| 20:39.54 | JefferyM | so 3.x won't be compatable |
| 20:40.17 | linus52 | This is a load off my shoulders; I have to have some forms of gaming in the labs for Frosh Orientation, I said I would get bzflag running. Now I know it will work. |
| 20:40.18 | JefferyM | and 1.x wasn't comtable with 2.x |
| 20:42.32 | JefferyM | wonder how 3.0 builds on sgi and solaris |
| 20:44.35 | KingRobot | JefferyM: Why would I have had to add ObstacleMgr.cxx to bzrobots to get it to link properly, when I was already linking to libObstacle with it, and an nm of that library grepped for the symbols that gcc complained were missing? |
| 20:44.48 | JefferyM | dunno |
| 20:44.57 | KingRobot | Strangest thing ever... |
| 20:46.07 | *** part/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 20:46.09 | *** part/#bzflag linus52 (n=jmc@starfury.cs.rit.edu) |
| 20:48.44 | *** join/#bzflag jh` (i=jh@212-149-242-219.bb.dnainternet.fi) |
| 21:01.04 | *** join/#bzflag beanpole (n=Evan@ip68-96-131-240.om.om.cox.net) |
| 21:25.46 | *** part/#bzflag mrapplecomputer1 (n=cjbruess@c-69-180-173-220.hsd1.mn.comcast.net) |
| 21:28.18 | *** join/#bzflag randomparticle (n=Xell@about/essy/snick/randomparticle) |
| 21:31.02 | randomparticle | i'm getting this odd slowdown. e.g., 24fps but cpu usage is almost zero. frame limiter set to 40fps |
| 21:31.30 | *** join/#bzflag matelich (n=tom@c-67-185-123-234.hsd1.wa.comcast.net) |
| 21:31.33 | randomparticle | http://www.pixentral.com/show.php?picture=1hnZ4wCAN4NuMrvp99u6jHbDbh4AxZ1 |
| 21:32.42 | randomparticle | i've tried setting core affinity |
| 21:32.47 | Manu | randomparticle: yes the fps thing is not perfect ;) |
| 21:33.06 | randomparticle | it's not usually out by that much though :) |
| 21:33.15 | randomparticle | this is still 2.0.x, btw |
| 21:33.28 | Manu | yes |
| 21:33.39 | randomparticle | Windows 7 RTM. Under RC the problem wasn't there. |
| 21:33.42 | x_ares_x | gah |
| 21:33.43 | x_ares_x | crap |
| 21:34.02 | Manu | I have set it to 50 fps and goes down when there are a lot of objects close |
| 21:34.04 | x_ares_x | er, wrong window |
| 21:34.40 | Manu | randomparticle: for example in Viper it goes down when the tank is in the center of the map |
| 21:34.46 | JefferyM | probalby just driver timing |
| 21:34.55 | JefferyM | but yeah the fps limiter dosn't always "get it right" |
| 21:35.05 | Manu | JefferyM: IIRC brlcad implemented it and wasn't perfect at all :) |
| 21:35.05 | JefferyM | I think some changes were made for trunk, but I'm not sure |
| 21:35.13 | JefferyM | nothing is perfect |
| 21:35.14 | randomparticle | in that psast it's varied by a frame or two here and there |
| 21:35.15 | JefferyM | it can't be |
| 21:35.27 | Manu | JefferyM: we are ;) |
| 21:35.30 | JefferyM | it may just be "missing" the frame time most of the time |
| 21:35.31 | randomparticle | but this is altogether different |
| 21:35.35 | JefferyM | Manu, like hell ;) |
| 21:35.54 | randomparticle | oh, like a resonant frequency type effect? |
| 21:36.00 | JefferyM | yeah kinda |
| 21:36.06 | JefferyM | like a "worst case" wait state |
| 21:36.18 | JefferyM | you have the same drives? and is vsync on or off? |
| 21:36.37 | randomparticle | i did try with vsync off, but didn't seem to affect it |
| 21:36.51 | JefferyM | you have the drivers that came with 7 or the ones from the card's mfg? |
| 21:36.55 | randomparticle | not sure if i have the same driver as when i had the RC on |
| 21:36.58 | randomparticle | nvidia's |
| 21:37.08 | JefferyM | that'd be where I would think the problem is |
| 21:37.13 | randomparticle | but it's confusing. there are so many of them :) |
| 21:37.22 | JefferyM | what card is it? |
| 21:37.26 | randomparticle | 8800GT |
| 21:37.52 | randomparticle | i've tried a few diff drivers but it still doing it |
| 21:38.10 | randomparticle | it's similar to that audio problem i had a while back |
| 21:38.12 | JefferyM | I only see one driver for 64 bit windows 7 |
| 21:38.18 | JefferyM | 190.38 |
| 21:38.25 | randomparticle | that's the latest |
| 21:38.34 | randomparticle | but there are some earlier ones, and vista drivers can be used too |
| 21:38.52 | JefferyM | I woudl think vista drivers would cause more issues then not |
| 21:38.58 | JefferyM | and the ones from MS are way old |
| 21:39.18 | JefferyM | tho I think I'm using beta drivers at home on my nvidia 7 system |
| 21:39.33 | jh` | hi jeff! |
| 21:39.39 | JefferyM | hello jh` |
| 21:40.19 | randomparticle | these are ones i have in the list: |
| 21:40.20 | randomparticle | http://www.pixentral.com/show.php?picture=10pKqqbdIphxWpgXvHgloLXmkVY5R |
| 21:40.33 | JefferyM | wow, you use that? |
| 21:40.37 | randomparticle | i didn't install 190.38 because some people are saying it inverts the fan speeds |
| 21:40.46 | JefferyM | I just manualy install the ones I want |
| 21:41.10 | randomparticle | is just an easy way to get the list of the ones on my system |
| 21:41.37 | JefferyM | well it's probably going to be related to the driver somehow |
| 21:41.47 | randomparticle | people were saying 190.38 causes cards to overheat because the fan runs slowest when the card is hottest |
| 21:41.51 | randomparticle | that put me off somewhat :) |
| 21:42.09 | randomparticle | yeah, must be a driver issue |
| 21:42.21 | JefferyM | the frame limiter dosn't have that tight of a timing algo, it can be off by over a frame time, and if it keeps doing that then it could get out of step and end up being like 1/2 the limit |
| 21:42.35 | JefferyM | you could just increase the limit till you got what you wanted |
| 21:42.45 | randomparticle | i can see that could happen |
| 21:42.58 | randomparticle | it's just, it wasn't happening before on win7 RC or on server 2008 |
| 21:43.10 | JefferyM | it was intended to lower power useage, not provide a super accurate timing system for frames |
| 21:43.24 | JefferyM | well you changed drivers when you changed OSs |
| 21:43.29 | randomparticle | yeah |
| 21:43.53 | randomparticle | what's a good way of cleaning out all the graphics driver stuff and starting again? |
| 21:44.07 | JefferyM | dunno |
| 21:44.15 | blast007 | format c:\ |
| 21:44.16 | JefferyM | the drives show up in the programs controll pannel? |
| 21:44.18 | randomparticle | just worried there may be some bit of something lurking around |
| 21:44.26 | JefferyM | there always is ;) |
| 21:53.42 | randomparticle | the taskbar icon glow thing is quite clever in windows 7 |
| 21:54.10 | randomparticle | if you hover the pointer over an icon it seems to glow with the predominant colour of the icon |
| 21:54.30 | randomparticle | e.g., orange for firefox |
| 21:57.40 | racecar56 | :P i'm still having teleporter trouble :P |
| 22:00.50 | *** part/#bzflag bryjen (n=bryjen@63.147.94.149) |
| 22:00.59 | racecar56 | does anyone know about the teleporter crazyness? |
| 22:01.15 | randomparticle | what is the craziness? :) |
| 22:01.29 | racecar56 | i seem to go right through the teleporters instead of being teleported |
| 22:01.51 | blast007 | what happens if you jump through? |
| 22:01.59 | racecar56 | same |
| 22:02.11 | blast007 | does it work on 2.0.x? |
| 22:02.15 | racecar56 | lemme try |
| 22:03.26 | racecar56 | no |
| 22:03.56 | racecar56 | if i knew how to host a game i could host one and you could see what problem im having |
| 22:05.41 | blast007 | pastebin it again |
| 22:06.42 | racecar56 | http://pastebin.bzflag.bz/d23647d4a |
| 22:07.55 | blast007 | broken link src: Tele_1:b |
| 22:07.55 | blast007 | broken link dst: Tele_1:f |
| 22:08.04 | blast007 | (you get that if you run bzfs with -dddd) |
| 22:08.28 | blast007 | you named it Tele1, not Tele_1 |
| 22:09.25 | racecar56 | ah thanks |
| 22:11.48 | racecar56 | they still dont work |
| 22:12.23 | racecar56 | blast007: that seemed to make no difference O_o |
| 22:18.11 | racecar56 | http://pastebin.bzflag.bz/d65d37076 |
| 22:31.18 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 22:31.18 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:40.16 | *** join/#bzflag bryjen (n=bryjen@75.81.201.131) |
| 22:40.16 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 22:47.30 | *** part/#bzflag randomparticle (n=Xell@about/essy/snick/randomparticle) |
| 22:48.25 | *** join/#bzflag JefferyM (n=JefferyM@bzflag/projectadmin/JeffM) |
| 22:48.25 | *** mode/#bzflag [+o JefferyM] by ChanServ |
| 22:53.51 | *** join/#bzflag Swigg_ (n=Default@97.95.231.32) |
| 22:56.13 | Winny | the scarecrow was the one without a brain, right? |
| 23:02.00 | spldart | yeah... |
| 23:02.12 | spldart | Did i miss something? |
| 23:02.52 | Winny | Nope |
| 23:03.02 | Winny | just needed to make sure |
| 23:03.47 | spldart | @ lion = missing courage, tin man = missing heart |
| 23:22.05 | Wyk3d | blast007: is it an acceptable bug that until the user is activated, phpbb will display invalid username/password error instead of an inactive user error ? |
| 23:22.49 | *** join/#bzflag plasma_kaz (n=Evan@ip68-96-131-240.om.om.cox.net) |
| 23:24.51 | Wyk3d | if the user was registered via the client then both phpbb and mediawiki and everything else's ldap code would need to be changed to read an additional value whether the user is registered but not active |
| 23:25.29 | JefferyM | that's probably ok |
| 23:25.43 | JefferyM | if it becomes a problem we can clean it up later |
| 23:27.31 | Wyk3d | and by "that" you mean the bug ? |
| 23:27.48 | JefferyM | can't even really call it a "bug" |
| 23:27.53 | JefferyM | it's just a different error message |
| 23:28.14 | JefferyM | the end result is still the same, they can't login untill they activate |
| 23:28.24 | JefferyM | so the message isn't as pretty or as exact as it could be :) |
| 23:29.08 | Wyk3d | k |
| 23:32.09 | *** join/#bzflag Evan__ (n=Evan@ip68-96-131-240.om.om.cox.net) |
| 23:40.09 | *** join/#bzflag bryjen (n=bryjen@75.81.201.131) |
| 23:40.09 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 23:50.07 | *** join/#bzflag KTL (n=KTL@213.219.151.155.adsl.dyn.edpnet.net) |