| 00:26.25 | trepan | svn-commit.7.tmp -- time to give up? :) |
| 00:51.54 | blast007 | "SourceForge.net is receiving higher than usual traffic, and some services are slow as a result." slow? that's the best word they have to describe it? ;) |
| 00:52.23 | TD-Linux | why is sourceforge so terrible lately |
| 00:52.30 | TD-Linux | and by lately I mean the last 5 years |
| 00:53.12 | TD-Linux | fortunately at least their site looks consistent now |
| 01:18.59 | smoooth | So any news on a potential "ready" date for 2.4? |
| 01:19.14 | blast007 | no |
| 01:19.31 | blast007 | the 14th is the cutoff for features though, and then we start testing/reverting |
| 01:19.43 | smoooth | what's your swag guess blast? |
| 01:20.13 | blast007 | near the end of june ideally |
| 01:20.44 | smoooth | cool, junish-julyish.. excellent |
| 01:27.40 | delusional | when is the last time somebody donated to sourceforge? |
| 01:34.02 | smoooth | you already did if you bought $300 shares of VA Linux back in 99' ;) |
| 01:55.14 | trepan | lucky number svn-commit.10.tmp? (and yes, I know, I'm only making the problem worst :) |
| 01:56.11 | blast007 | hehe |
| 01:56.45 | trepan | at least it was a short one, died a minute into it |
| 01:57.43 | trepan | wonders how google code and bitbucket compare for reliability / speed |
| 02:42.19 | a_meteorite | github ftw |
| 02:44.36 | blast007 | a_meteorite: DVCS ftw in general. |
| 02:47.06 | a_meteorite | indeed |
| 02:48.13 | a_meteorite | bitbucket and gitorious interfaces annoy me though |
| 02:52.19 | blast007 | I don't mind bitbucket |
| 02:53.56 | *** join/#bzflag Gnurdux (~gnurdux@c-24-6-185-47.hsd1.ca.comcast.net) |
| 02:56.51 | a_meteorite | Woah now Gnurdux joins us. All these old players coming back. |
| 02:57.03 | Gnurdux | actually i've lurked in this channel forever |
| 02:57.09 | a_meteorite | oh :P |
| 02:57.13 | Gnurdux | lol |
| 02:57.44 | Gnurdux | i do wonder whether bzflag will ever get a nice successor |
| 02:58.00 | a_meteorite | You haven't heard about 2.4 coming up then? |
| 02:58.27 | Gnurdux | whoa, nope, i should look into that |
| 02:58.37 | Gnurdux | is that what was formerly known as bzflag 3.0, or is it less ambitious? |
| 02:58.40 | blast007 | http://my.bzflag.org/w/BZFlag_2.3 |
| 02:58.44 | a_meteorite | http://my.bzflag.org/w/BZFlag_2.3 |
| 02:58.52 | blast007 | less ambitious |
| 02:58.56 | blast007 | a_meteorite: I win. |
| 02:58.57 | blast007 | ;) |
| 02:58.57 | a_meteorite | Gnurdux: mostly 2.99 backports, less ambitious |
| 02:59.16 | a_meteorite | 3.0 was aimng too big |
| 02:59.42 | Gnurdux | meh, not in my opinion |
| 02:59.59 | Gnurdux | if the 3.0 goals can't happen bz is prolly dead |
| 03:00.10 | blast007 | Gnurdux: there was too much |
| 03:01.12 | blast007 | however, it's still being worked on slowly |
| 03:01.14 | Gnurdux | my guess is that really bzflag is a project whose time has come, and it might be best to let it die |
| 03:01.26 | blast007 | we'll see |
| 03:01.41 | a_meteorite | you'll have to take bzflag out of my cold dead hands! |
| 03:01.53 | Gnurdux | there are a lot of changes one could make that could be cool but would leave it no longer bzflag |
| 03:01.54 | blast007 | ~bzfrag a_meteorite |
| 03:01.54 | ibot | ACTION destroys a_meteorite with a guided missile |
| 03:01.57 | blast007 | there. |
| 03:02.06 | a_meteorite | aw man.. |
| 03:02.17 | Gnurdux | like making the tanks be able to not lie flat |
| 03:02.18 | a_meteorite | ~respawn |
| 03:02.18 | ibot | hmm... respawn is what happens when WoW decided you've killed enough of its mobs and thinks you should die. |
| 03:02.37 | blast007 | heh |
| 03:08.49 | *** join/#bzflag Swigg (~Default@50.42.48.95) |
| 03:08.49 | *** join/#bzflag Swigg (~Default@bzflag/player/Swigg) |
| 04:10.53 | JeffM | a_meteorite, 3.0 wasn't too big, the developers gave up |
| 04:11.23 | a_meteorite | had some showstopper bugs that no one could track down, even if they did give up |
| 04:11.54 | JeffM | if 3.0 had been planed and managed like 2.4 is it would have shiped 3 years ago |
| 04:12.03 | a_meteorite | yeah |
| 04:12.31 | JeffM | cus as the showstopers were put in they would have been fixed or removed |
| 04:46.30 | *** part/#bzflag smoooth (~smoooth@cpe-098-024-240-002.ec.res.rr.com) |
| 05:03.48 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 05:19.03 | kierra | " |
| 05:26.55 | *** join/#bzflag AAA_awright (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 06:05.02 | *** join/#bzflag Marzipan- (~Marzipan@p5B2261D4.dip.t-dialin.net) |
| 06:06.23 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 06:35.54 | *** join/#bzflag AAA_awright (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 07:02.03 | *** join/#bzflag Marzipan- (~Marzipan@p5B226531.dip.t-dialin.net) |
| 07:03.36 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:28.11 | *** join/#bzflag GransRemedy (~john@121-79-204-29.sta.inspire.net.nz) |
| 07:31.03 | *** join/#bzflag Upsetter (~er@i59F6A3B0.versanet.de) |
| 07:44.22 | *** join/#bzflag jcp|alive (~boydam@dhcp-198-244.housing.utah.edu) |
| 07:45.14 | CIA-103 | BZFlag: 03Grans Remedy 07http://my.bzflag.org * r7721 10/w/Group_management_system_functional_requirements: |
| 08:19.50 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:20.13 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:37.19 | CIA-103 | BZFlag: 03Grans Remedy 07http://my.bzflag.org * r0 10/w/Special:Log/upload: uploaded "[[Image:GMS Architecture.png]]": BZFlag Group Management System: Architecture |
| 09:37.44 | CIA-103 | BZFlag: 03Grans Remedy 07http://my.bzflag.org * r7723 10/w/GMS_Architecture: New page: {{DesignDocument}} A three-tier architecture was chosen to allow the interface to be changed independently of the application/business logic, and to allow the data storage technology to be... |
| 11:23.28 | *** join/#bzflag bleach (bleach@osama.destroyislam.org) |
| 11:35.35 | *** join/#bzflag sirquine (~quine@adsl-75-37-35-18.dsl.pltn13.sbcglobal.net) |
| 11:59.31 | *** join/#bzflag kierra (~jolie@ool-44c153c5.dyn.optonline.net) |
| 11:59.32 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 12:10.43 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 12:14.20 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 12:14.20 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 12:15.14 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 12:15.14 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 13:28.17 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 13:28.17 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 13:45.23 | *** join/#bzflag Swigg (~Default@bzflag/player/Swigg) |
| 13:48.42 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 14:19.40 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 14:32.33 | *** join/#bzflag bier|tp (~bier@p54A5A644.dip.t-dialin.net) |
| 14:34.02 | *** join/#bzflag bier (~bier@p54A5A644.dip.t-dialin.net) |
| 14:45.41 | *** join/#bzflag spldart (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 14:45.41 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 14:45.41 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:47.26 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 15:59.01 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 16:00.32 | *** join/#bzflag JeffM (~JeffM@69.36.85.130) |
| 16:00.32 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 16:00.32 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 16:57.37 | CIA-103 | BZFlag: 03bullet_catcher * r21888 10/trunk/bzflag/src/other/ares/ (121 files in 3 dirs): Upgrade to c-ares 1.7.4, preserving the minor change made in r21125. |
| 16:57.53 | BulletCatcher | https connections to SourceForge still occasionally hang, then fail. |
| 16:57.56 | BulletCatcher | It took several tries over the last 2 hours to get that commit in. |
| 16:59.11 | blast007 | yep |
| 16:59.20 | blast007 | perfect timing with their issues ;) |
| 16:59.39 | blast007 | I seem to recall this happening before around the time we wanted to release |
| 17:00.13 | BulletCatcher | It's always something. |
| 17:00.26 | blast007 | I mean, it took two tries for my one file change last night |
| 17:00.29 | BulletCatcher | CIA had its management change just as we started work on 2.3. |
| 17:00.53 | blast007 | hehe, yeah, that too |
| 17:01.15 | blast007 | there was barely any commits up to that point, and then when we start it goes away |
| 17:01.45 | blast007 | maybe...maybe it's a sign |
| 17:01.55 | BulletCatcher | I wonder how many tries it will take me to commit changes to 338 files for the cURL upgrade. |
| 17:02.32 | trepan | SF/SVN has to DIE! :) |
| 17:02.35 | blast007 | estimates 6 hours |
| 17:02.49 | ruskie | just switch to sf/git already |
| 17:02.54 | blast007 | ruskie: or hg |
| 17:03.04 | trepan | or not sf at all |
| 17:03.11 | blast007 | even better |
| 17:03.11 | ruskie | anything distributed |
| 17:03.26 | blast007 | github/bitbucket are better environments for DVCS |
| 17:03.44 | BulletCatcher | Let's get 2.4 out before making any repository changes. |
| 17:03.52 | blast007 | yeah, of course |
| 17:03.54 | trepan | BulletCatcher: been trying to get a 462 file commit in since yesterday afternoon, no joy |
| 17:04.20 | trepan | BulletCatcher: blast007 and I are playing with 'hg convert' to see how well the branches in history can be pulled in |
| 17:04.21 | blast007 | maybe SF is working on upgrading their Pentium II SVN server right now. |
| 17:04.28 | trepan | *and history |
| 17:04.57 | blast007 | when we move the branches into subdirectories, that made it more difficult to migrate |
| 17:05.00 | trepan | then we can pick something like bitbucket or google code to host |
| 17:05.11 | BulletCatcher | Wireless is one of your problems, isn't it trepan? Perhaps a temporary wired connection would be worth the effort. |
| 17:05.39 | blast007 | in SF's current state, it doesn't matter ;) |
| 17:05.41 | trepan | BulletCatcher: blast007 provided me with a 'svn sync' .tgz to play with, makes conversion testing much easier |
| 17:06.02 | trepan | *svnsync |
| 17:19.27 | JeffM | google svn works fine too |
| 17:20.27 | BulletCatcher | I have gotten a few code-500 errors from Google svn, but it wasn't as bad as SF is. |
| 17:21.03 | JeffM | I'm still not convinced that a DVCS is right for us |
| 17:21.14 | blast007 | we could also move the SVN repo to .bz |
| 17:21.16 | blast007 | ducks |
| 17:21.34 | JeffM | blast007, in anticipation of that I put a svn server on my machine |
| 17:21.39 | JeffM | so it's not a bad idea |
| 17:21.42 | blast007 | hehe |
| 17:21.48 | blast007 | I used to have one on mine too |
| 17:21.52 | JeffM | I've been using it for my stuff |
| 17:21.55 | blast007 | don't think I set that back up yet |
| 17:21.58 | JeffM | they are simple to setup |
| 17:22.02 | blast007 | and probably won't now that I moved to hg |
| 17:22.12 | blast007 | was yours through apache? |
| 17:22.13 | JeffM | wonder if it could be tied to weblogin :) |
| 17:22.25 | JeffM | yeah it's using HTTP |
| 17:22.34 | blast007 | mine was using HTTPS |
| 17:22.37 | JeffM | I"m even pondering getting a cert for it to do https |
| 17:22.39 | blast007 | so a bit more complicated |
| 17:22.47 | blast007 | (was just self-signed though) |
| 17:22.55 | JeffM | 13$ can get me a real cert |
| 17:22.58 | blast007 | yeah |
| 17:23.06 | blast007 | I have a few free ones laying around too |
| 17:23.15 | blast007 | got 'em with domain transfers |
| 17:23.19 | JeffM | fun |
| 17:23.39 | blast007 | didn't really matter for me at the time since it was just for me |
| 17:24.02 | blast007 | now I just use private repos on bitbucket |
| 17:24.32 | CIA-103 | BZFlag: 03bullet_catcher * r21889 10/trunk/bzflag/src/other/curl/ (338 files in 10 dirs): Upgrade to cURL 7.21.6, preserving several changes required due to the way it is bundled with BZFlag. |
| 17:24.36 | BulletCatcher | w00t! Success on the first attempt. |
| 17:25.09 | BulletCatcher | Maybe this is the designated hour for SF to work well. |
| 17:25.32 | blast007 | you probably just got lucky |
| 17:25.44 | BulletCatcher | Just like when I play BZFlag. |
| 17:25.45 | trepan | tries his luck |
| 17:25.55 | blast007 | well, I updated without it crapping out |
| 17:26.00 | blast007 | so maybe it's good now |
| 17:26.33 | JeffM | I did try to set up git on my server too |
| 17:26.48 | JeffM | was pretty easy up to the point where I wanted it to work remotely |
| 17:27.06 | JeffM | isn't happy with the assumption of a unix user per git user |
| 17:27.12 | BulletCatcher | The Windows build system probably needs to be tweaked for the new versions of ares and curl. |
| 17:27.29 | JeffM | fun |
| 17:27.42 | BulletCatcher | Your fun, not mine. ;-) |
| 17:27.42 | JeffM | did they add any files? |
| 17:27.57 | BulletCatcher | Yes. More so in curl than ares. |
| 17:28.34 | JeffM | what problem did this upgrade fix? |
| 17:28.50 | BulletCatcher | Both packages had security fixes. |
| 17:29.02 | BulletCatcher | I didn't investigate to see how/if it affected us. |
| 17:29.04 | JeffM | but no functional fixes for us |
| 17:29.10 | BulletCatcher | Nope. |
| 17:29.15 | BulletCatcher | A new feature or two. |
| 17:29.19 | JeffM | we probably could have left it for later then |
| 17:29.39 | trepan | ruskie: you use git on windows? |
| 17:30.26 | BulletCatcher | I can give you a list of the new files if you want. |
| 17:30.43 | JeffM | I have the list in my checkout log |
| 17:30.43 | blast007 | I don't think ruskie uses WIndows. ;) |
| 17:31.01 | JeffM | git can work on windows |
| 17:31.12 | JeffM | it's just less awesome then other systems |
| 17:31.27 | trepan | has no problems with git, but i'm told it's windows support isn't great |
| 17:31.32 | JeffM | it isn't |
| 17:31.36 | JeffM | but it would work enough |
| 17:31.43 | JeffM | my problems with it are not techincal |
| 17:31.51 | JeffM | but procedural |
| 17:32.29 | blast007 | I still need to figure out how to get git to read my SSH key on Windows.. |
| 17:32.39 | CIA-103 | BZFlag: 03trepan * r21890 10/branches/experimental/v2_99continuing/bzflag/ (462 files in 22 dirs): |
| 17:32.39 | CIA-103 | BZFlag: * reordered the #includes |
| 17:32.39 | CIA-103 | BZFlag: (excluding #include <...>, and only sorted in contiguous blocks) |
| 17:32.39 | CIA-103 | BZFlag: * added some missing #includes to clientbase/clientvars.h |
| 17:32.39 | CIA-103 | BZFlag: * changed the game/global.h references for the moved file |
| 17:32.49 | JeffM | what did you generate the key with? |
| 17:32.55 | blast007 | PuTTYgen |
| 17:33.00 | JeffM | I used puttygen with github and it's fine |
| 17:33.03 | blast007 | exported it to various formats though |
| 17:33.19 | blast007 | I probably wasn't putting it in the right spot |
| 17:33.21 | BulletCatcher | trepan: Now is the time buy lottery tickets. |
| 17:33.30 | trepan | :) |
| 17:34.02 | trepan | _is_ convinced the DVCS is the way to go |
| 17:34.10 | JeffM | I know you are |
| 17:34.16 | JeffM | cus it fits how you work |
| 17:34.29 | trepan | because it's more flexible |
| 17:34.30 | JeffM | and that's my problem with it, I"m not a huge fan of how you work ;) |
| 17:34.36 | JeffM | it can be yes |
| 17:34.52 | JeffM | I have fears about people going off and doing there own things |
| 17:34.57 | JeffM | then disapearing and we loose the code |
| 17:35.05 | blast007 | the problem is that they already do that |
| 17:35.06 | JeffM | cus they never pushed to a hosted branch |
| 17:35.16 | JeffM | yeah but at least we GET there code |
| 17:35.20 | trepan | so you lose it, so what? |
| 17:35.22 | JeffM | by making them commit to a branch |
| 17:35.25 | blast007 | JeffM: no, we dn't ;) |
| 17:35.28 | blast007 | don't* |
| 17:35.36 | JeffM | we do in some ways |
| 17:35.43 | blast007 | if someone doesn't have commit rights or they don't commit it, we don't have anything |
| 17:35.47 | trepan | if they hadn't finished it, then it's unlikely that someone else is going to pick it up to support it anyways |
| 17:35.59 | JeffM | possibly |
| 17:36.05 | JeffM | I just hate big code dumps |
| 17:36.15 | trepan | you'll probably get smaller ones |
| 17:36.19 | JeffM | I already fear that people won't like your 2.99 cus it's so different |
| 17:36.24 | trepan | or at least smaller changesets |
| 17:36.28 | JeffM | if we enforce it maybe |
| 17:36.30 | blast007 | a DVCS on a proper hosting platform is more likely to get people to fork and make changes publically |
| 17:36.45 | trepan | i could commit 30 times into a feature before testing it and pushing it |
| 17:36.55 | JeffM | I understand that |
| 17:37.04 | JeffM | I doubt my optionns on it are going to change it |
| 17:37.09 | JeffM | you all are set for it so it'll happen |
| 17:37.14 | JeffM | I'm just expressing my doubts |
| 17:37.32 | JeffM | and I agree SF blows |
| 17:38.05 | blast007 | eventually, I think we could just use SF as a download hosting site |
| 17:38.17 | blast007 | and an info blurb |
| 17:38.35 | JeffM | how much bandwith do we use for downloads a month? |
| 17:38.55 | blast007 | not sure |
| 17:39.06 | blast007 | I suppose after this release we might have a better idea |
| 17:39.21 | blast007 | when everyone has to upgrade :) |
| 17:39.23 | JeffM | BulletCatcher, did they break ares into 4 libs? |
| 17:40.33 | JeffM | or was there not a vc dir in the new repo you merged in? |
| 17:44.33 | trepan | <PROTECTED> |
| 17:44.53 | JeffM | yeah thanks for that |
| 17:44.58 | JeffM | just the code drop on you rown |
| 17:44.59 | JeffM | own |
| 17:45.04 | JeffM | I know I'm not perfect |
| 17:45.10 | JeffM | thanks for pointing that out |
| 17:45.16 | JeffM | I feel so much better now |
| 17:45.29 | JeffM | I didn't mean to say your metod wasn't valid |
| 17:45.40 | JeffM | I just have concerns |
| 17:45.43 | JeffM | but forget it |
| 17:46.23 | TD-Linux | github's forking feature is really nice... it actually wouldn't need a dvcs but it helps with the merging thing |
| 17:46.45 | JeffM | Github solves all problems |
| 17:46.49 | JeffM | I hope it can fix my marrage |
| 17:46.56 | trepan | JeffM: it's forgotten; you certainly are rockin' as the 2.4 manager, sh*t is happening :) |
| 17:47.08 | JeffM | too much is happening |
| 17:47.25 | JeffM | this curl thing may add more time to the release, it should have happend way easierly |
| 17:48.36 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
| 17:48.52 | blast007 | I'd be curious if any of the security fixes really apply to us |
| 17:49.01 | JeffM | I doubt they do |
| 17:49.06 | JeffM | our use is so limited |
| 17:49.21 | JeffM | we don't even realy "process" what we read from curl |
| 17:49.30 | JeffM | we look for specific things |
| 17:49.52 | JeffM | and most linux servers would have pulled it from an external package |
| 17:49.59 | JeffM | so really this if for I guess windows people |
| 17:50.10 | JeffM | who now have 51 files to add |
| 17:50.46 | blast007 | BulletCatcher: can we just do that for 2.4.2 instead? |
| 17:51.00 | TD-Linux | indeed when I build bzflag, configure selects none of the in-tree libraries |
| 17:51.11 | JeffM | and the lovely people at ares went and threw all the source files for all there tools into one dir so I can't just grab em all |
| 17:52.04 | JeffM | was this change even on the list? |
| 17:53.33 | blast007 | I'm just gonna see if I can revert them here |
| 17:53.39 | JeffM | k |
| 17:53.46 | JeffM | be a lot simpler |
| 17:53.51 | blast007 | doing it from linux though, so it's not all clicky |
| 17:54.03 | JeffM | whatever works |
| 17:54.26 | blast007 | this seem right to revert 21889 and 21888? svn merge -r 21889:21887 https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/ |
| 17:55.25 | JeffM | it does look like they have change proxy support |
| 17:58.38 | *** join/#bzflag TD-Linux (~thomas@68-115-86-128.dhcp.roch.mn.charter.com) |
| 17:58.39 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 18:00.09 | JeffM | I got it to build |
| 18:00.20 | JeffM | but I still kinda want to revet it |
| 18:00.27 | JeffM | otherwise we have to test the crap out of it |
| 18:00.35 | blast007 | yeah, I have it ready to revert |
| 18:00.39 | JeffM | k |
| 18:00.59 | JeffM | I'll make a patch with the changes and submit it so we have it when we do it later |
| 18:01.30 | blast007 | ok |
| 18:01.41 | JeffM | maybe for 2.4.2 I can make it so we don't use curl on windows :) |
| 18:01.49 | blast007 | heh |
| 18:02.07 | JeffM | I mean it's not like the OS can't do it for us ;) |
| 18:02.14 | BulletCatcher | I don't mind reverting ares and curl if it is going to impact the release too much. |
| 18:02.21 | blast007 | BulletCatcher: I'm doing it right now |
| 18:02.26 | JeffM | BulletCatcher, I'm just woried about testing |
| 18:02.26 | TD-Linux | do you only use the http part of curl? |
| 18:02.45 | blast007 | TD-Linux: we don't use HTTPS, if that's what you mean |
| 18:02.45 | JeffM | I guess we could also follow FTP links |
| 18:03.27 | CIA-103 | BZFlag: 03blast007 * r21891 10/trunk/bzflag/src/other/ (459 files in 13 dirs): Revert r21888 and r21889. We will update cURL/ares once 2.4.0 is released. |
| 18:04.51 | TD-Linux | I mean curl does a huge pile of protocols |
| 18:04.53 | JeffM | we wrap up curl anyway so we just wrap ares then I can implemen my own and we are good :) |
| 18:05.00 | JeffM | yeah we use it get URLS thats it |
| 18:05.13 | JeffM | images, maps, etc.. |
| 18:05.16 | JeffM | and do the list stuff |
| 18:05.46 | BulletCatcher | Mac OS X 10.4 (obsolete, I know...) needs ares because it doesn't have its own. |
| 18:05.54 | JeffM | hmmmm could make platform a DLL and make it mixed mode then I could just pic up the .net url classses :) |
| 18:06.06 | blast007 | heh |
| 18:06.19 | JeffM | then bz would respect system proxy server settings |
| 18:06.25 | JeffM | that'd a be a huge thing |
| 18:07.16 | blast007 | yay, then malware infected PCs can also intercept BZFlag passwords ;) |
| 18:07.25 | JeffM | heh |
| 18:07.34 | JeffM | well then we could do https too |
| 18:07.46 | blast007 | yeah |
| 18:07.53 | JeffM | I'm not against getting a cert for the list and using that if we can |
| 18:08.08 | JeffM | but I think we'd have to fix up our url loading system first |
| 18:08.13 | BulletCatcher | I presume malware will intercept before the data is encrypted. |
| 18:08.32 | JeffM | probably |
| 18:08.37 | blast007 | BulletCatcher: just talking about some of them that set up local proxies |
| 18:10.21 | JeffM | there are people who do have to use proxies for HTTP for valid reasons |
| 18:10.27 | JeffM | so we can't realy tell the diff |
| 18:11.11 | TD-Linux | curl doesn't use system wide proxy settings? |
| 18:11.30 | JeffM | it does it's own networking |
| 18:12.08 | JeffM | and it's rather linux centric so taking the time to go find the settings on a "dirty" windows machine is not worth it to them |
| 18:13.04 | JeffM | also our wraper around it isn't that great |
| 18:13.15 | JeffM | no controlls for global in/out bandwith capping |
| 18:13.31 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 18:13.34 | TD-Linux | yeah sounds like native is best |
| 18:13.45 | TD-Linux | WinINet is the C api |
| 18:14.04 | JeffM | I am aware of the windows APIs for getting web data ;) |
| 18:14.09 | JeffM | all 4 of tehm |
| 18:14.11 | JeffM | them |
| 18:14.30 | TD-Linux | I'm not, so I should stop talking :> |
| 18:14.41 | JeffM | System.Net.Web.HTTPClient is the best of them |
| 18:15.04 | JeffM | or maybe it's WebClient now |
| 18:15.08 | JeffM | cus it does more then HTTP |
| 18:15.42 | JeffM | I belive that would let the web sytem use IPV6 as well |
| 18:16.03 | JeffM | not sure if curl uses ares in that way |
| 18:17.35 | randomparticle | could we make the bz console a scripting environment? |
| 18:17.40 | JeffM | no |
| 18:18.22 | JeffM | tho I'll bet with client side lua you could probably find a way to get it hooked in |
| 18:18.34 | randomparticle | could always hack it in myself :) |
| 18:18.49 | JeffM | what % of players do you think would use that feature? |
| 18:18.49 | randomparticle | though, i'd settle for cut and paste |
| 18:19.01 | trepan | wasn't going to mention it, but /luauser doline ... provides limited bz console scripting |
| 18:19.14 | trepan | (even has word completion based on the script env.) |
| 18:19.15 | JeffM | I figured you had something like that in there |
| 18:19.45 | JeffM | since it'd just send the input to the lua engine |
| 18:21.13 | blast007 | randomparticle: iirc, 2.99.x does have paste |
| 18:21.15 | trepan | it does make writing little scriptlets (and doing small tests), considerably easier |
| 18:21.39 | TD-Linux | hmm... since you are dropping opengl 1.0 support, a lot of the effects could be converted to glDrawArrays now, right? |
| 18:21.53 | JeffM | lots of things can happen with graphics |
| 18:22.10 | trepan | glDrawArrays are already used, iirc |
| 18:22.13 | TD-Linux | I think it'd be neat to make bzflag opengl es 1.1 compatable |
| 18:22.14 | trepan | nothing new to see here |
| 18:22.16 | randomparticle | another thing i thought might be nice for a future version of bz is tank skinning |
| 18:22.28 | trepan | randomparticle: already possible in 3.0 |
| 18:22.40 | JeffM | yeah it's been on the list for a while |
| 18:22.52 | randomparticle | how do you avoid the naked-lady-on-tank problem? :--) |
| 18:23.04 | trepan | limited texture urls |
| 18:23.10 | JeffM | same as you do for maps |
| 18:23.12 | randomparticle | i was thinking in terms of procedural patterns |
| 18:23.15 | blast007 | same way we limit the naked-lady-on-box problem |
| 18:23.21 | randomparticle | hehe |
| 18:23.26 | trepan | randomparticle: you're pretty much hosed on that one :) |
| 18:23.44 | JeffM | 3.0 solves all of the non gameplay related problems :) |
| 18:23.47 | TD-Linux | well it's somewhat up to the server admin in that case |
| 18:23.57 | TD-Linux | and you now have keys to get on the server list |
| 18:24.02 | JeffM | TD-Linux, no the end user, for what URLs they allow to read |
| 18:24.36 | TD-Linux | JeffM, yes, but if a rogue server _really_ wanted to they could do it with geometry |
| 18:24.45 | TD-Linux | in which case you fixed that problem by being able to boot them off the server list |
| 18:24.49 | JeffM | possibly |
| 18:24.50 | trepan | might end up fixing some of the real gameplay issues just to fix the 3.0 gameplay bugs |
| 18:24.55 | JeffM | heh |
| 18:25.06 | JeffM | trepan, so you are going to redo networking to just send input? |
| 18:25.13 | trepan | might even be easier to go that way |
| 18:25.13 | TD-Linux | is there a list of 3.0 blockers anywhere? |
| 18:25.17 | JeffM | cus the real gameplay won't be fixed untill that's done |
| 18:25.40 | JeffM | TD-Linux, it has a buglist |
| 18:25.44 | trepan | JeffM: i'd already made a couple of commits in that direction a while back: svn log PlayerState.h (iirc) |
| 18:25.48 | blast007 | also need a -lowPing option that boots people if they go over 80ms |
| 18:25.50 | blast007 | ;) |
| 18:27.44 | TD-Linux | what do you mean by "just send input" by the way? |
| 18:27.52 | trepan | exactly what it sounds like |
| 18:28.05 | trepan | just mouse/kbd/joy from client->server |
| 18:28.10 | TD-Linux | the server tells the client where its own tank is going? |
| 18:28.14 | JeffM | yep |
| 18:28.20 | JeffM | then you can't cheat it |
| 18:28.26 | TD-Linux | visible input lag on the client :S |
| 18:28.31 | JeffM | oh no no |
| 18:28.31 | trepan | nope |
| 18:28.43 | JeffM | you have the client do the same thing it expects the server to do |
| 18:28.50 | JeffM | then when you arn't cheating it's all good |
| 18:28.58 | TD-Linux | ok, so there is lag compensation in there too? |
| 18:29.02 | trepan | and you use quantized simulations steps |
| 18:29.02 | JeffM | yeah |
| 18:29.09 | TD-Linux | so when the server gets an input, it knows that actually happened x milliseconds ago |
| 18:29.13 | JeffM | this is how most other games work |
| 18:29.23 | JeffM | yeah it ain't rocket surgery |
| 18:29.32 | JeffM | been happening for 15 years now |
| 18:29.35 | TD-Linux | because also if your packets don't get sent at the same framerate as the client, your server prediction is going to drift over time |
| 18:29.36 | JeffM | we just need to get with the times |
| 18:29.38 | blast007 | it's why most game servers need more than a few MB of RAM ;) |
| 18:29.51 | JeffM | TD-Linux, you timestamp them |
| 18:29.55 | TD-Linux | it's why minecraft's server needs a few GB of RAM |
| 18:30.03 | blast007 | TD-Linux: no, that's just java |
| 18:30.06 | JeffM | most quake systems are hosted on linux |
| 18:30.09 | JeffM | and they do this |
| 18:30.19 | JeffM | quake, CS, TF, TF2, etc... |
| 18:30.23 | JeffM | al the COD games |
| 18:30.42 | TD-Linux | I'm just worried about dropped packets |
| 18:30.56 | TD-Linux | a dropped packet means an accumulated error that won't go away |
| 18:30.57 | JeffM | there are ways to take care of it |
| 18:31.02 | TD-Linux | you should have the client send coordinates too |
| 18:31.06 | JeffM | again this is well docuemnted |
| 18:31.07 | trepan | it's not accumulated |
| 18:31.14 | TD-Linux | and allow a certain amount of error per time |
| 18:31.17 | JeffM | bzflags networking is horrible |
| 18:31.17 | trepan | you resync for incoming server packets |
| 18:31.24 | JeffM | go read up on the subject ;) |
| 18:31.41 | JeffM | yeah you update your state based on what the server says |
| 18:31.55 | TD-Linux | oh you just do the error correction the other way |
| 18:31.59 | JeffM | so if you lost a packet then you jump back, but your sim in the world is corect |
| 18:32.06 | trepan | you can also do a little state interpolation to smooth things out on the client |
| 18:32.07 | JeffM | yeah punish the laggy not the rest of the game ;) |
| 18:32.08 | TD-Linux | correct the client's estimate rather than the server's |
| 18:32.11 | trepan | but the server is god |
| 18:32.17 | trepan | and god shall be obeyed |
| 18:32.25 | JeffM | it is the only state that can be trusted |
| 18:32.38 | TD-Linux | I'm working on a similar project, but it's for a physical airplane |
| 18:32.41 | JeffM | there is a good paper by valve on it |
| 18:32.54 | TD-Linux | so unfortunately I can't correct the earth to what my gyroscopes read :/ |
| 18:33.10 | JeffM | then the plane is the server |
| 18:33.28 | TD-Linux | yeah I guess that works :) |
| 18:33.43 | JeffM | it just applies it's state data to the control surfaces |
| 18:34.37 | TD-Linux | well I was more talking discrepancies between my dead reckoned data and absolute data |
| 18:37.31 | TD-Linux | you could also do a low pass filter on the client side to make jitter less noticeable |
| 18:37.43 | trepan | you can also do a little state interpolation to smooth things out on the client <- |
| 18:38.13 | TD-Linux | I call it a low pass filter |
| 18:38.36 | trepan | that's nice :) |
| 18:38.55 | trepan | you also want to smooth out the clock deliver from the server |
| 18:38.56 | blast007 | I recall trying to play Fear Combat on a crappy computer with dialup. Couldn't get through a door - it kept snapping me back inside the room. Then someone came along and "helped" me get out with a large weapon. |
| 18:39.07 | trepan | *delivered |
| 18:39.33 | trepan | it sends it's exact time, the frame, and the frame offset |
| 18:40.30 | trepan | hm, s/it's/its/, silly mistake for a native engrish speaker |
| 18:43.30 | TD-Linux | frame offset? |
| 18:44.24 | trepan | time since the frame really started |
| 18:45.16 | TD-Linux | like how much time since inputs were sampled? |
| 18:45.58 | trepan | inputs aren't sampled by the server |
| 18:46.11 | TD-Linux | oh wait this is what the server sends? OK |
| 18:46.35 | TD-Linux | well the beginning of the frame the server samples the current state from the packets it has got |
| 18:46.50 | trepan | it depends on how you setup the server loop |
| 18:47.11 | trepan | providing a frame offset makes it more flexible, at little cost |
| 18:48.06 | TD-Linux | also you'd want to store a cache of previous simulation results |
| 18:48.09 | trepan | you could split out a thread to update time syncs, that is itself not synced to the server frame loop |
| 18:48.34 | trepan | TD-Linux: yup, read up on rollback mechanisms and the such |
| 18:48.51 | TD-Linux | because if you get a "bullet fired 100ms ago" you want to check for collsions with tanks 100ms ago and simulate forward to present time |
| 18:49.13 | TD-Linux | lucky for no tank to tank collision :P |
| 18:49.44 | trepan | tank vs. tank actual becomes easier, but users will notice some bump and grind effects :) |
| 18:50.49 | trepan | (it's easier because the server controls all the "real" tank states) |
| 18:52.58 | trepan | also note that the use of something like streflop might help improve client-side DR accuracy, it isn't required |
| 18:55.58 | trepan | woot, working bzflag hg repo with branches and all their histories (had to move all the branches back into the top-level branches/ dir for the conversion, but that's easy) |
| 18:59.39 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 18:59.41 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 19:01.00 | blast007 | trepan: neat |
| 19:01.30 | trepan | going to play with it to make sure all is well, but it looks ok so far |
| 19:02.10 | trepan | but it's a little confusing, 'hg log' runs so darned fast :) |
| 19:02.52 | blast007 | :) |
| 19:04.56 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 19:11.07 | *** part/#bzflag Upsetter (~er@i59F6A3B0.versanet.de) |
| 19:23.23 | Pimpinella | JeffM: have you flag events in? |
| 19:24.14 | Pimpinella | something with bz_FlagUpdateRecord, not sure what that is. |
| 19:24.20 | Pimpinella | do you need that? |
| 19:29.01 | blast007 | something like that could go in for 2.4.2, no? |
| 19:33.19 | Pimpinella | i leave it in and just comment it out for now |
| 19:33.22 | TD-Linux | I understand hg is cleaner than the huge hack that is git/ |
| 19:34.21 | blast007 | Pimpinella: or post it to the patch tracker? |
| 19:35.03 | Pimpinella | whats that? |
| 19:35.25 | blast007 | the place where we keep track of patches ;) |
| 19:35.53 | Pimpinella | figured, but how do i post something there? ;) |
| 19:36.14 | blast007 | http://sf.net/projects/bzflag tracker > patches, and post your patch (which you make via 'svn diff') |
| 19:36.56 | Pimpinella | ah, thats what you mean... |
| 19:37.30 | Pimpinella | no, it's just a code fragment that might be used later, maybe not |
| 19:37.40 | blast007 | exactly |
| 19:38.00 | Pimpinella | it's a code fragment that BREAKS stuff atm ;) |
| 19:38.30 | Pimpinella | no probably not |
| 19:38.33 | Pimpinella | ;) |
| 19:38.51 | JeffM | I did a bunch of events |
| 19:38.55 | JeffM | I don't recall what ones |
| 19:39.11 | JeffM | I did most of the ones that I Could given that the flags weren't updated as much |
| 19:40.06 | *** join/#bzflag noyb (~noyb@64.134.228.153) |
| 19:40.21 | Pimpinella | think i just leave it out for now |
| 19:42.36 | JeffM | what specific events are missing? |
| 19:44.27 | Pimpinella | nothing missing, i just backported some stuff from r12507 |
| 19:45.45 | blast007 | well what was in r12507 that you were backporting? ;) |
| 19:45.58 | Pimpinella | the refactorings |
| 19:46.11 | Pimpinella | not the api stuff |
| 19:46.32 | JeffM | was refactoring flags on the inital list? |
| 19:47.00 | Pimpinella | it's really tiny stuff ;) |
| 19:47.02 | JeffM | BulletCatcher, did you have one month of testing on your inital plan? |
| 19:47.09 | JeffM | was it on the list? ;) |
| 19:47.18 | Pimpinella | guess no |
| 19:47.25 | JeffM | if not add it to the list for 2.4.2 |
| 19:47.33 | Pimpinella | ok ;) |
| 19:47.55 | JeffM | optimaly I'd love to know what we want to be in 2.4.2 before we ship 2.4.0 |
| 19:48.01 | JeffM | then we can just chug away on it |
| 19:48.19 | JeffM | I'd like .2 to be releases about a month after .0 |
| 19:48.31 | JeffM | then 4 about 2-3 months after .2 |
| 19:48.44 | JeffM | or sooner |
| 19:50.10 | Pimpinella | shouldn't .2 be a bugfix release (in case we need that of course) in the first place? |
| 19:50.16 | JeffM | yes |
| 19:50.28 | JeffM | but if the bugs arn't too bad it can have some features |
| 19:50.48 | JeffM | it's possible that .2 will be a "oh crap" release and we'll push all the stuff on the list back by .2 |
| 19:51.05 | JeffM | but since we have the forth number now we don't have to do a .2 just for a package problem |
| 19:51.37 | JeffM | but I understand we will find some bugs, thats why .2 has a shorter time in my mind |
| 19:52.39 | JeffM | it'll probably take us up to like 2.4.0.3 or .4 to get the packages right anyway |
| 19:52.50 | JeffM | tho I really want to have a full set of packages for beta |
| 19:52.54 | JeffM | so we can test them too |
| 19:53.35 | JeffM | I would like to start beta on the 16th if we can |
| 19:53.51 | JeffM | then release the week of the 27th |
| 19:54.37 | JeffM | prep to move services on the long weekend if the 4th and then maybe move em on the weekend of the 9th |
| 19:54.50 | JeffM | tho that may be too soon if upgrades arn't happening fast |
| 19:55.14 | JeffM | but if we get over half the servers up to 2.4 by then I think it'll be ok |
| 19:55.33 | Pimpinella | will re have an RC? |
| 19:55.43 | JeffM | yes |
| 19:55.46 | JeffM | sometime before |
| 19:56.04 | JeffM | but I expect the testing to happen in the beta |
| 19:56.15 | JeffM | it will all side down if there are issues of course |
| 19:56.48 | JeffM | optimaly we'd have an RC on the 27th, then if it's good release by the 30th |
| 19:57.14 | JeffM | would really like to release in june |
| 20:01.28 | blast007 | yeah |
| 20:02.31 | Thumper_ | you scared Tim off with that comment |
| 20:02.48 | JeffM | what? actual management? :) |
| 20:12.14 | ruskie | hmm still have crappy link to viper :( |
| 20:12.47 | brad | sposed /win 47 |
| 20:12.52 | brad | fail |
| 20:31.30 | *** join/#bzflag ibot (~ibot@rikers.org) |
| 20:31.30 | *** topic/#bzflag is http://my.bzflag.org/w/BZFlag_2.3 || http://my.BZFlag.org || http://cia.vc/stats/project/BZFlag || http://my.BZFlag.org/w/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.0.16 is the current release, use it wisely |
| 20:31.30 | *** mode/#bzflag [+o ibot] by ChanServ |
| 20:37.53 | CIA-103 | BZFlag: 03pimpinella * r21893 10/trunk/bzflag/ (4 files in 3 dirs): backport MsgNearFlag, r13192 |
| 20:41.11 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 20:48.27 | RatOmeter | admins over at A*A trying to tighten up on the map bugs? |
| 20:48.48 | RatOmeter | A*A Bridge Crossing, that is |
| 20:49.01 | *** join/#bzflag JeffM (~JeffM@69.36.85.130) |
| 20:49.01 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 20:49.01 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 21:01.46 | temporalD | RatOmeter: I doubt it - why? |
| 21:05.11 | *** join/#bzflag randomparticle (~randompar@cpc3-wilm2-2-0-cust912.1-4.cable.virginmedia.com) |
| 21:05.11 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 22:01.56 | Pimpinella | hmm, that MsgNearFlag requires new protocol version and revision number, right? |
| 22:08.49 | JeffM | yes |
| 22:12.04 | *** join/#bzflag JeffM_ (~JeffM@69.36.85.130) |
| 22:17.11 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 22:32.40 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 22:48.54 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 22:57.53 | CIA-103 | BZFlag: 03pimpinella * r21894 10/trunk/bzflag/ (ChangeLog src/date/buildDate.cxx): bump protocol version and ChangeLog adds |
| 23:16.58 | *** join/#bzflag rathomas (~chatzilla@r74-195-237-138.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
| 23:17.47 | rathomas | any bztank.net admins around? |
| 23:18.17 | rathomas | or even asquare ;) |
| 23:35.49 | *** join/#bzflag KTL (~KTL@85.234.201.192) |
| 23:44.55 | JeffM_ | so is there anyting major we are missing for 2.4? |
| 23:45.12 | Thumper_ | unit tests ;) |
| 23:45.21 | JeffM_ | heh we'll never have those |
| 23:45.36 | JeffM_ | I mean for features |
| 23:45.43 | JeffM_ | all the flag ID stuff is done? |
| 23:45.57 | JeffM_ | and all the DNS caching is removed? |
| 23:46.41 | Thumper_ | I don't think I have anything major left - still reviewing bugfix commits but if we don't get anymore for 2.4 that will be fine I think |
| 23:46.57 | JeffM_ | I think we did good with our schedule |
| 23:48.23 | JeffM_ | ooo you beat DTRemenak in completed tasks :) |
| 23:48.38 | JeffM_ | and mdskpr_ really bucked up |
| 23:49.08 | JeffM_ | BulletCatcher, would you say your 2 items are done? |
| 23:49.31 | JeffM_ | and same for you Pimpinella ? |
| 23:50.28 | JeffM_ | and who wants to document the server "upgrade" procedure for owners? |
| 23:53.37 | Thumper_ | JeffM_: what's involved in documenting it? Create a site on the wiki and include details about -publickey (and generating keys) and what else? - how to upgrade 2.0.x plugins? |
| 23:53.57 | JeffM_ | I wrote an article for the plugins so that should jsut be referenced |
| 23:54.00 | JeffM_ | but yeah that's about it |
| 23:54.10 | JeffM_ | and any changes to command line options etc.. |
| 23:54.48 | Thumper_ | I can probably do that |
| 23:54.53 | Thumper_ | by when? |
| 23:55.07 | JeffM_ | it would be nice before beta |
| 23:55.14 | JeffM_ | but before release |
| 23:55.17 | Thumper_ | do we have a date for that? |
| 23:55.38 | JeffM_ | optimaly I'd like to be in beta on the 20th |
| 23:55.42 | JeffM_ | and released on the 30th |
| 23:55.52 | Thumper_ | ok |
| 23:56.56 | Thumper_ | I'll try to get that done by the 20th |
| 23:57.11 | Thumper_ | does that need to be a task in the 2.4 spreadsheet? |
| 23:57.25 | JeffM_ | no, I'm adding it to the wiki page |
| 23:58.14 | CIA-103 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7724 10/w/BZFlag_2.3: |
| 23:58.34 | JeffM_ | puts some dates on this sucker :) |