00:01.18 | JeffM_ | blast007, is there anyway we could modify the list server on the old machine and make it return an malformed result that will crash copies of 2.0.x after we move to the new machine? |
00:07.48 | blast007 | lol |
00:08.11 | *** join/#bzflag Gnurdux (~gnurdux@c-24-6-185-47.hsd1.ca.comcast.net) |
00:20.29 | KTL | just put "please upgrade!" in front of every returned description? |
00:25.34 | trepan | return a server list crafted with fake servers ordered with Please | upgrade | to | 2.4 | now | (go to bzflag.org) --tweak the player counts to order them |
00:25.50 | blast007 | trepan: the problem is more with the servers |
00:25.59 | blast007 | clients doesn't have an issue with it |
00:26.18 | trepan | the servers that will no longer be listed if they are running 2.0.x ? |
00:26.38 | Erroneous | when the clients upgrade, the servers will follow. it's not like we need 200 servers on day one... |
00:26.38 | blast007 | 2.0.x servers cache the list server IP indefinately |
00:26.56 | Thumper_ | blast007: just shut it off :) |
00:26.58 | blast007 | Erroneous: we're talking about the list migration |
00:27.04 | Erroneous | still |
00:27.10 | Erroneous | we don't need 200 servers on day one ;) |
00:27.22 | blast007 | the list migration is giong to wait until 2.4 is released on somewhat popular anyway |
00:27.25 | trepan | <PROTECTED> |
00:27.35 | Erroneous | restart a few, then let whoever cares migrate the others |
00:27.48 | Erroneous | might be good for the game if a bunch don't restart, who knows |
00:27.54 | blast007 | hehe |
00:27.56 | trepan | :) |
00:28.12 | Thumper_ | let me know if I should shut mine off :) |
00:28.22 | trepan | -publickey might be enough to knock off 10 or 20 of them |
00:28.23 | *** part/#bzflag kierra (~jolie@unaffiliated/kierra) |
00:29.28 | Erroneous | Thumper_: naw, the ones we need to lose are the ones that have operators who don't care ;) |
00:29.47 | blast007 | and any that are running on Windows. |
00:29.51 | Thumper_ | heh |
00:30.08 | blast007 | though Erroneous already covered that |
00:30.10 | blast007 | ;) |
00:30.19 | Erroneous | yeah, that's a wee bit redundant ;) |
00:31.07 | blast007 | there's probably at least one person running a Windows server on their laptop over wifi at least part of the time. |
00:31.14 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
00:31.15 | *** mode/#bzflag [+v spldart] by ChanServ |
01:44.31 | *** join/#bzflag JeffM (~Jeff@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
01:44.32 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
01:44.32 | *** mode/#bzflag [+v JeffM] by ChanServ |
02:03.19 | *** join/#bzflag rathomas (~chatzilla@r74-195-237-138.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
03:03.05 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
03:23.11 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
04:20.52 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
04:20.52 | *** mode/#bzflag [+o TimRiker] by ChanServ |
04:39.22 | CIA-103 | BZFlag: 03bullet_catcher * r21895 10/trunk/bzflag/configure.ac: Increment the package version number to match BZ_REV in buildDate.cxx. |
04:42.00 | CIA-103 | BZFlag: 03trepan * r21896 10/branches/experimental/v2_99continuing/bzflag/MSVC/build/ (24 files): |
04:42.00 | CIA-103 | BZFlag: * added: |
04:42.01 | CIA-103 | BZFlag: ../../src |
04:42.01 | CIA-103 | BZFlag: to the .vcproj AdditionalIncludeDirectories fields that already had: |
04:42.02 | CIA-103 | BZFlag: ../../src/include |
04:42.53 | trepan | unfortunatly, I appended, so they don't quite match the premake build |
04:43.01 | trepan | but hopefully that won't matter shortly |
04:43.53 | delusional | manpages come up blank http://my.bzflag.org/bzfman.cgi? |
04:44.34 | allejo | same here |
04:46.17 | trepan | try: http://my.bzflag.org/bzfman3.cgi?bzw.5.in :) |
04:47.45 | trepan | i'll take a shot at fixing the trunk one |
04:49.04 | allejo | trepan: bzfman3.cgi works |
04:49.10 | trepan | i know |
04:49.19 | trepan | 3.0 is not trunk |
04:49.59 | allejo | not the current topic of discussion, but is there an API for 2.4 plugins? |
04:50.02 | trepan | hm, the other one isn't either, it's v2_0branch from the looks of it |
04:50.15 | trepan | bzfsAPI.h |
04:51.00 | trepan | hm, actually, bzfman3.cgi is trunk, not 3.0 :) |
04:51.17 | allejo | thanks trepan for the api info |
04:51.44 | trepan | what did you expect? |
04:52.01 | delusional | http://my.bzflag.org/w/BZFS_API_2.4_Upgrade |
04:52.22 | delusional | ah, thanks trepan |
04:52.47 | trepan | is fixing bzfman3.cgi, it will point to the 2.99 man pages |
04:53.54 | trepan | http://my.bzflag.org/bzfman3.cgi?bzw.5.in now points to branches/experimental/v2_99continuing |
05:12.40 | trepan | http://my.bzflag.org/bzfman2.0.cgi?bzw.5.in (actually, v2_0_10 tag, later tags semmed to be messed up) |
05:12.49 | trepan | (and I can't edit bzfman.cgi) |
05:13.08 | trepan | *seem to be ... |
05:23.10 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
07:00.13 | *** join/#bzflag Marzipan- (~Marzipan@p5B22369C.dip.t-dialin.net) |
07:01.24 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
07:31.46 | CIA-103 | BZFlag: 03bullet_catcher * r21897 10/trunk/bzflag/src/bzfs/Permissions.cxx: Rename two variables from "info" to "accessInfo" to avoid conflict with the "info" enum value defined in the PlayerAccessInfo class. |
07:35.08 | CIA-103 | BZFlag: 03bullet_catcher * r21898 10/trunk/bzflag/src/platform/XDisplay.cxx: Rename variable from "modeIndex" to "_modeIndex" to avoid conflict with the BzfDisplay::modeIndex class element. |
07:40.36 | CIA-103 | BZFlag: 03bullet_catcher * r21899 10/trunk/bzflag/src/bzflag/Makefile.am: Use $CONF_CPPFLAGS so the embedded curl .h files can be found. |
07:50.09 | CIA-103 | BZFlag: 03bullet_catcher * r21900 10/trunk/bzflag/ (4 files in 3 dirs): |
07:50.09 | CIA-103 | BZFlag: Accept, with modification, numbers 1, 4, and 5 of 5 in SourceForge patch 3152896 from dmichelsen (Dagobert Michelsen): |
07:50.09 | CIA-103 | BZFlag: Make the first parameter of VotingBooth::vote() const to match its declaration. |
07:50.09 | CIA-103 | BZFlag: Cast integer logf() argument to float to avoid ambiguity. |
07:50.09 | CIA-103 | BZFlag: Declare HUDuiList::createSlider() parameter as const to match its implementation. |
08:05.00 | CIA-103 | BZFlag: 03bullet_catcher * r21901 10/trunk/bzflag/AUTHORS: BZFlag participated in Google Summer of Code in 2009, too. |
08:09.56 | *** join/#bzflag Djpenguin (~David@c-98-207-67-102.hsd1.ca.comcast.net) |
08:19.06 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
08:19.24 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
09:26.21 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
09:26.21 | *** mode/#bzflag [+v L4m3r] by ChanServ |
09:27.16 | *** join/#bzflag Constitution (~const@bzflag/developer/Constitution) |
12:05.26 | *** join/#bzflag heartnet (~heartnet@p4082-ipbf306fukuhanazo.fukushima.ocn.ne.jp) |
12:09.06 | *** part/#bzflag heartnet (~heartnet@p4082-ipbf306fukuhanazo.fukushima.ocn.ne.jp) |
12:23.23 | *** join/#bzflag heartnet (~heartnet@p4082-ipbf306fukuhanazo.fukushima.ocn.ne.jp) |
12:58.44 | CIA-103 | BZFlag: 03trepan * r21902 10/branches/experimental/v2_99continuing/bzflag/ (3 files in 3 dirs): * moved a header |
13:05.42 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
13:05.43 | *** mode/#bzflag [+o TimRiker] by ChanServ |
13:17.46 | Pimpinella | anyone, is it ok in c++ if i don't catch a return value? |
13:18.49 | Pimpinella | bool somefunction() |
13:18.55 | Pimpinella | to be called like : |
13:19.00 | Pimpinella | somefunction() |
13:19.02 | Pimpinella | ; |
13:19.10 | Pimpinella | instead of: |
13:19.34 | Pimpinella | bool dontCare = somefunction(); |
13:20.31 | Pimpinella | gcc doesn't sem to care, i on't know about other compilers though |
13:20.40 | trepan | yup, it's ok |
13:21.08 | trepan | you can do (void)somefunction(); if you we to be pedantic |
13:21.29 | Pimpinella | great, ty |
13:21.58 | Pimpinella | that way i cat the return value to void? |
13:22.03 | Pimpinella | cast |
13:22.30 | cygal | it tells the compiler "ignore the value, really" |
13:22.37 | trepan | it's sometimes useful if a function has been tagged with the "warn_unused_result" attribute |
13:23.47 | trepan | (that's gcc, not sure what other compilers use) |
13:24.15 | Pimpinella | ok |
13:25.31 | trepan | http://stackoverflow.com/questions/4226308/msvc-equivalent-of-attribute-warn-unused-result |
13:26.39 | trepan | and for extra points: http://stackoverflow.com/questions/3614691/casting-to-void-doesnt-remove-warn-unused-result-error |
13:28.35 | cygal | so it would be either (void) or (void*) depending if the function returns a pointer or not. |
13:32.25 | trepan | cygal: (void) works just as well as (void*), i think ;) |
13:32.47 | trepan | but they are right that neither make gc happy |
13:32.50 | trepan | *gcc |
13:33.14 | trepan | (tested with g++-4.6.1) |
13:35.19 | cygal | ph I thought (void *)freopen("/dev/null", "w", stderr); |
13:35.23 | cygal | oh* |
13:35.33 | cygal | (I thought this line worked) |
13:37.14 | trepan | nope, didn't work for me -- although, up until i tested, i would have thought it sufficient :) |
13:58.58 | *** join/#bzflag RatOmeter (~chatzilla@r74-195-237-138.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
14:17.31 | *** join/#bzflag spldart (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
14:17.31 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
14:17.31 | *** mode/#bzflag [+v spldart] by ChanServ |
14:34.25 | *** join/#bzflag bier (~bier@p54A5BA88.dip.t-dialin.net) |
14:35.09 | *** join/#bzflag bier|tp (~bier@p54A5BA88.dip.t-dialin.net) |
14:49.18 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
15:26.02 | Pimpinella | blast007: still time for a final commit? |
15:26.29 | Thumper_ | I think today is the last day for commits except for bugfixes of existing stuff |
15:26.49 | BulletCatcher | It is never too late to fix bugs. |
15:27.05 | Pimpinella | not a bug, it's a feature ;) |
15:27.12 | BulletCatcher | :-) |
15:27.19 | Thumper_ | Pimpinella: so I think the answer is YES |
15:27.29 | Thumper_ | and tomorrow it will be NO |
15:27.35 | Pimpinella | lets go then :) |
15:28.01 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
15:28.01 | BulletCatcher | Go ahead and do it. |
15:28.03 | BulletCatcher | We'll revert if it causes too big a problem. |
15:30.05 | CIA-103 | BZFlag: 03pimpinella * r21903 10/trunk/bzflag/src/bzfs/ (Permissions.cxx Permissions.h): groups can be referenced in groupdb now before they were defined. Order doesn't matter at all now. |
15:31.25 | Pimpinella | everything else can wait |
15:32.55 | Pimpinella | BulletCatcher: you make the server migration guide, right? |
15:33.13 | Thumper_ | I think that's me |
15:33.20 | Pimpinella | ah, ok :) |
15:33.42 | Thumper_ | Jeff put it on the wiki for the 2.3/2.4 page but I haven't looked at it yet |
15:34.01 | Thumper_ | The plan is to have that done by the 20th |
15:34.05 | Thumper_ | in time for the first beta |
15:34.24 | Pimpinella | that last commit doesn't change anything for previously correct groupdb files at all |
15:34.56 | Pimpinella | however if they were wrong before the behavior might change now |
15:35.40 | Thumper_ | ok - I'll attempt to document that and you can review it when it's ready |
15:35.46 | Pimpinella | lty |
15:37.11 | CIA-103 | BZFlag: 03trepan * r21904 10/branches/experimental/v2_99continuing/bzflag/src/include/BaseResources.h: * removed an unused header |
15:37.13 | BulletCatcher | If the server migration guide is a wiki page, then anyone can start it at any time, and everyone can contribute. |
15:37.50 | Thumper_ | the plan is for it to be a wiki page - but it hasn't been created yet |
15:37.52 | Pimpinella | yep |
15:38.01 | Thumper_ | feel free to start it :) |
16:00.48 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
16:08.35 | CIA-103 | BZFlag: 03bullet_catcher * r21905 10/trunk/bzflag/plugins/timedctf/timedctf.cpp: Rename variable "GS" to "_GS", as "GS" is a macro defined in /usr/include/sys/regset.h on Solaris x86. |
16:36.15 | CIA-103 | BZFlag: 03bullet_catcher * r21906 10/trunk/bzflag/ (data/shot_tail.png tools/TextTool-W32/res/Toolbar.bmp): Set the Subversion svn:mime-type property to image/bmp and image/png for .bmp and .png files, respectively. |
16:39.03 | CIA-103 | BZFlag: 03Thumper 07http://my.bzflag.org * r7725 10/w/BZFlag_2.3: Own the server side handicap backport |
16:41.15 | *** join/#bzflag JeffM (~JeffM@69.36.85.130) |
16:41.15 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
16:41.15 | *** mode/#bzflag [+v JeffM] by ChanServ |
16:52.33 | JeffM | so is anything left? |
16:55.43 | *** join/#bzflag RatOmeter (~chatzilla@r74-195-237-138.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
16:58.17 | BulletCatcher | I need to adjust some of the *nix build system to install less stuff, but that doesn't have to block a beta release. |
16:58.41 | CIA-103 | BZFlag: 03JeffM2501 * r21907 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: add a shortcut to the config dir. |
16:58.48 | JeffM | actualy it does, I want a set of packages for beta |
16:58.53 | JeffM | so that we test the install too |
16:59.13 | BulletCatcher | We don't want to install plugin .a files, nor things like cURL .h files. |
16:59.15 | JeffM | or do you mean less stuff for people to isntall |
16:59.20 | JeffM | to build |
16:59.34 | JeffM | probably not |
16:59.39 | JeffM | that's just a make install right? |
16:59.43 | JeffM | not a debian package |
17:00.09 | JeffM | somone needs to update the debian package to include plugins too |
17:00.09 | BulletCatcher | Correct. I want to have "make install" install fewer files. |
17:00.20 | JeffM | it would be nice if that was done by beta |
17:00.30 | JeffM | so people could test the final method |
17:00.33 | *** join/#bzflag Upsetter (~er@i59F6AD37.versanet.de) |
17:00.46 | BulletCatcher | I'm not going to get it done today or even tomorrow. |
17:01.17 | Thumper_ | the first beta is planned for the 20th IIRC |
17:04.14 | BulletCatcher | I expect to have time to do the config stuff this Friday or Saturday, which will be in time for the beta planned on the 20th. |
17:04.37 | randomparticle | i seem to recall this is responsible for shots going through blocks (unintended maths precision error): |
17:04.39 | randomparticle | define ZERO_TOLERANCE 1.0e-06f |
17:04.43 | randomparticle | from common.h |
17:04.52 | randomparticle | might be worth checking what it is in 2.99 |
17:04.54 | JeffM | BulletCatcher, sounds fine |
17:05.14 | JeffM | randomparticle, honstly we will forget that comment by the time we get to that codebase |
17:05.19 | trepan | randomparticle: #define ZERO_TOLERANCE 0.00005f |
17:05.55 | JeffM | the soonest that I could possibly see full development moving to 2.99 would be 4-5 months from now. |
17:06.09 | randomparticle | i think the change is safe |
17:06.11 | JeffM | given our speed |
17:06.17 | Thumper_ | JeffM: I think he's referring to backporting a fix for 2.3 |
17:06.17 | trepan | could have some seriously useful stuff done by then :) |
17:06.24 | JeffM | ahh |
17:06.25 | randomparticle | Thumper_: yeah |
17:06.44 | Thumper_ | randomparticle: I'll put it on my list |
17:06.49 | randomparticle | thanks |
17:06.52 | JeffM | those values looks very similar |
17:07.17 | JeffM | ahh no, one less 0 |
17:07.22 | randomparticle | yeah. not too dissimilar. what happens atm is the code thinks the shot is on the other side of a block surface (precision error) |
17:07.28 | JeffM | Thumper_, how much more do you have to do? |
17:07.40 | randomparticle | and thus shots end up going through walls rather than being bounced back |
17:10.21 | BulletCatcher | During a recent test we saw a [nr] player who did not drop his flag. That needs further investigation and hopefully a fix. |
17:10.51 | CIA-103 | BZFlag: 03JeffM2501 * r21908 10/trunk/bzflag/include/common.h: we have zero tolerance for bad tolerances. |
17:11.11 | JeffM | BulletCatcher, you want to keep the bugs we find/fix in beta in the bugs file or on SF? |
17:12.21 | BulletCatcher | The BUGS file is fine. |
17:12.38 | BulletCatcher | Want me to add my note about flags? |
17:12.58 | JeffM | yes |
17:13.14 | JeffM | put it in a "critial for 2.4" section or something |
17:15.00 | BulletCatcher | Right now most of the BUGS file is from 2.99. |
17:15.10 | *** join/#bzflag Thumper_ (~Thumper@about/essy/coffeeAddict/Thumper) |
17:15.10 | *** mode/#bzflag [+v Thumper_] by ChanServ |
17:16.35 | JeffM | not sure that's a good thing |
17:16.59 | *** mode/#bzflag [+o JeffM] by ChanServ |
17:17.02 | BulletCatcher | Yeah. It should be pruned to show only problems with the current trunk. |
17:17.19 | JeffM | I'd revert it back to the 2.0.x one and add to it |
17:18.00 | BulletCatcher | I'll do that now. |
17:18.41 | *** topic/#bzflag by JeffM -> http://my.BZFlag.org || http://cia.vc/stats/project/BZFlag || http://my.BZFlag.org/w/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || Code Freeze for 2.4 is today 6/14/11 finish your stuff || 2.4 beta on 6/20/11 |
17:18.53 | JeffM | thanks |
17:19.29 | BulletCatcher | I'll revert the TODO file to the 2.0 one, too. |
17:19.32 | JeffM | GvzEvxre, what are the odds of you checking out the debian buid system for turnk? |
17:19.37 | JeffM | BulletCatcher, good call |
17:20.08 | JeffM | does the ubuntu package have any mods we don't have in trunk? |
17:21.04 | JeffM | and does anyone know who maintains that? |
17:22.58 | trepan | http://packages.debian.org/squeeze/bzflag-server , Tim? |
17:23.07 | JeffM | tim does debian |
17:23.21 | JeffM | but at one point there was somoeone on the ubuntu side that was doing a bit more |
17:23.29 | JeffM | cus tim wasn't updating the debian packages |
17:23.35 | trepan | ah, thought they'd just source it raw |
17:24.17 | JeffM | I belive they do that for a lot of stuff, but in the case where the package maintainer on debian dosn't care anymore I think they can have someone step in and make new ones just for them |
17:24.52 | trepan | http://packages.ubuntu.com/oneiric/bzflag -- "Ubuntu MOTU Developers", with Tim as the original maintainer |
17:26.38 | JeffM | I guess I can get the source, and diff it with our 2.0.16 tarbal |
17:26.57 | JeffM | I think we fixed up eveything they used to mod but I just want to be sure |
17:30.50 | JeffM | is makefile.in generated? or do we geneate that? |
17:31.12 | trepan | yup, it is generated |
17:31.21 | JeffM | same for "configure" ? |
17:31.41 | trepan | yup |
17:31.50 | JeffM | k, those are the only files that are different |
17:34.44 | CIA-103 | BZFlag: 03bullet_catcher * r21909 10/trunk/bzflag/ (BUGS TODO): |
17:34.44 | CIA-103 | BZFlag: Revert BUGS and TODO to the 2.0.17 version in r21397 so we can move forward. |
17:34.44 | CIA-103 | BZFlag: Preserve the deletion of the spin inversion BUGS item done in r21842. |
17:39.06 | BulletCatcher | Did we deliberately change 2.3 so slash commands sent to the server are not echoed in the client's chat window? If not, it is a bug. |
17:39.14 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
17:40.16 | CIA-103 | BZFlag: 03bullet_catcher * r21910 10/trunk/bzflag/BUGS: Add a couple of new flag grab/drop bugs. |
17:42.51 | Thumper_ | JeffM: There are lots of commits I haven't looked at for possible backport bugfixes but I don't think there is anything critical left on my list (for code) |
17:43.02 | Thumper_ | I also have the server migration documentation to do for the 20th |
17:43.55 | Thumper_ | for BUGS and TODO I tried to merge the 3.0 and 2.0.x stuff (missed part of the conversation before the reverts) |
17:46.15 | CIA-103 | BZFlag: 03Pimpinella 07http://my.bzflag.org * r7726 10/w/BZFlag_2.3: |
17:49.32 | JeffM | Thumper_, today is the last day for backports |
17:49.39 | JeffM | so will you finish any today? |
17:50.22 | Thumper_ | I don't have anything currently outstanding so I'm probably already finished - the only thing I'm looking for now is actual bug fixes in the 2.99 branch |
17:50.38 | Thumper_ | if it fixes something we have currently broken in 2.3 then I'll consider applying it otherwise I leave it |
17:50.47 | JeffM | still will you have time to do any of them today? |
17:50.47 | Thumper_ | I'm not backporting any new functionality |
17:51.05 | JeffM | I don't even want bacported bug fixes after today |
17:51.15 | JeffM | unless we find a problem in testing |
17:51.37 | Thumper_ | probably won't get much more done today on this |
17:51.41 | JeffM | ok |
17:51.54 | JeffM | then don't worry about going thru 2.99 commits |
17:51.59 | Thumper_ | ok |
17:52.00 | JeffM | we'll find the others in testing |
17:59.34 | CIA-103 | BZFlag: 03trepan * r21911 10/trunk/bzflag/ChangeLog: * credit where credit is due |
18:04.32 | CIA-103 | BZFlag: 03bthansen * r21912 10/trunk/bzflag/ChangeLog: More credits |
18:10.32 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
18:10.47 | *** part/#bzflag Upsetter (~er@i59F6AD37.versanet.de) |
18:18.31 | randomparticle | diff has an exclude pattern option |
18:18.41 | randomparticle | but i want to exclude everything except *.cxx files |
18:18.55 | randomparticle | what would be a good way to do that? |
18:19.35 | randomparticle | seems to me like it could do with having an include pattern option |
18:19.54 | randomparticle | maybe it accepts extended regexps |
18:21.39 | JeffM | works in winmerge :) |
18:21.55 | randomparticle | yeah |
18:22.02 | randomparticle | maybe i need a better diffing tool |
18:22.15 | JeffM | winmerge is awesome |
18:22.19 | trepan | svn diff, or local diffs? |
18:22.32 | randomparticle | i've been using local |
18:22.37 | randomparticle | could svn do it for me? |
18:23.18 | trepan | yes |
18:23.36 | trepan | it's one of the most basic VCS tools |
18:23.37 | randomparticle | ok, i'm just going to type in what i guess might work. hope i don't destroy the world ;--) |
18:24.16 | randomparticle | well, that was rather easy |
18:24.18 | randomparticle | thanks |
18:26.40 | randomparticle | this is my patch to solve the apple clock problem: http://dl.dropbox.com/u/22994649/machtime.diff |
18:27.22 | randomparticle | the problem is this: gettimeofday uses the system clock, which may be adjusted by ntpd during gameplay, causing glitching |
18:28.07 | randomparticle | my patch uses instead mach_absolute_time, which counts the number of cpu ticks since system bootup and doesn't suffer from the abovementioned problem |
18:28.35 | randomparticle | there's a link to the apple technical documentation in the patch |
18:32.09 | trepan | POSIX timers might be another approach |
18:32.47 | trepan | sorry, POSIX clocks, of the monotonic variety |
18:33.52 | randomparticle | i've just removed a printf debugging statement from the patch |
18:34.41 | JeffM | yeah I'm glad windows uses the QPF for that |
18:36.29 | randomparticle | i'm not sure if POSIX clocks are available on darwin |
18:36.43 | randomparticle | i seem to recall some discussion about them being missing before |
18:37.01 | JeffM | I thought it was UNIX certified, dosn't it have to have all the posix stuff for that? |
18:37.14 | JeffM | food |
18:37.15 | randomparticle | not necessarily all |
18:37.26 | randomparticle | i think a subset is optional |
18:39.45 | trepan | Feature Test Macro Requirements for glibc: _POSIX_C_SOURCE >= 199309L |
18:42.32 | randomparticle | $ grep TIMER /usr/include/unistd.h |
18:42.32 | randomparticle | #define_POSIX_TIMERS(-1)/* [TMR] */ |
18:43.31 | trepan | guess that's out for MacOSX then, might be something to look into for linux later |
18:43.42 | randomparticle | cut and paste hasn't worked there. there's a gap before the opening parenth |
19:09.14 | *** join/#bzflag tupone (~tupone@gentoo/developer/tupone) |
19:09.15 | *** mode/#bzflag [+v tupone] by ChanServ |
19:13.11 | tupone | wonders when bzls will support ipv6 |
19:35.14 | blast007 | JeffM: what packages are we going to build for the beta? I've attempted to do debian packages before, but they never seem to work for me. ;) |
19:38.22 | trepan | tupone: when you add it? :) |
19:39.01 | JeffM | blast007, I would like to have as many as we can have |
19:39.21 | blast007 | I think there was some "magic" way to do it |
19:39.36 | blast007 | like, maybe you had to have a specific OpenGL package installed |
19:39.43 | JeffM | if there is we need to beat the info out of tim |
19:40.03 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
19:40.03 | *** mode/#bzflag [+o TimRiker] by ChanServ |
19:40.05 | JeffM | optimaly I would like as many package systems documened as possible |
19:40.10 | JeffM | speak of the devil! |
19:40.30 | JeffM | TimRiker, is there any magic to making debian packages that work? |
19:41.23 | tupone | trepan, Actually I even don't know where the bzls reside :) |
19:41.25 | blast007 | tupone: when server hosts start giving a crap about Ipv6? :) |
19:45.07 | *** join/#bzflag JeffM_ (~JeffM@69.36.85.130) |
19:45.23 | blast007 | it'd be trivial to add IPv6 support to the list server, but it's of no use if we don't have an IPv6 accessible host |
19:45.34 | blast007 | not to mention that BZFlag doesn't support IPv6 either |
19:45.40 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
19:45.40 | *** join/#bzflag Erroneous (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
19:45.40 | *** mode/#bzflag [+v Erroneous] by ChanServ |
19:45.46 | blast007 | and that's a much larger task than updating the list to support it |
19:47.51 | tupone | blast007, yes I know, but it is a start |
19:48.14 | tupone | has an IPV6 host (not tunneled) |
19:48.54 | trepan | tupone: i'd be willing to help setup 2.99.x for IPv6 |
19:50.02 | tupone | 1st step is to decide the changes in the protocols |
19:52.45 | randomparticle | whatever server i try to connect to, it says "error connecting to server" |
19:52.58 | blast007 | randomparticle: what version and what OS? |
19:53.10 | randomparticle | mac os 2.0.13 i think |
19:53.18 | randomparticle | was working about 15 mins ago |
19:53.29 | blast007 | 2.0.13 you think? please check for sure. |
19:53.42 | randomparticle | yes it is |
19:53.59 | blast007 | okay. Go get the latest version then. That's not even a release version. |
19:54.10 | randomparticle | ok i will do |
19:54.19 | randomparticle | but i'm not sure why it would stop working on all servers just now |
19:54.22 | blast007 | 2.0.16 is the latest/last 2.0.x |
19:54.47 | blast007 | not sure, but not worth troubleshooting an ancient development version of the game either :) |
19:55.07 | randomparticle | well, it's worked without any problem for nearly 2 years :) |
19:55.49 | blast007 | shrugs |
19:55.54 | blast007 | then it's not a problem with the game ;) |
19:55.56 | blast007 | fix your os ;) |
19:57.10 | randomparticle | is working again now |
19:57.24 | randomparticle | i blame global :--P |
20:00.20 | blast007 | or your DNS was furbar |
20:00.26 | blast007 | fubar* |
20:01.03 | blast007 | global being doesn't would cause that |
20:01.20 | blast007 | then again, DNS down would probably yeild a "server not found" error |
20:01.23 | randomparticle | probably was some unfathomable net issue |
20:01.26 | blast007 | so it's probably our ISP taking a nap |
20:01.29 | blast007 | your* |
20:02.12 | randomparticle | sigh. how do you keep the motivation levels up? |
20:02.28 | randomparticle | i'm in that frame of mind that, whenever i look at a line of code, i start to feel a bit sleepy |
20:02.45 | blast007 | what's why I code in my sleep |
20:02.50 | randomparticle | hehe |
20:02.58 | JeffM_ | look at some other code |
20:03.02 | JeffM_ | then come back to it |
20:03.05 | randomparticle | yeah |
20:03.08 | JeffM_ | also take on smaller tasks |
20:03.25 | blast007 | like writing microsoft excel in turbopascal |
20:03.27 | JeffM_ | then it's simpler to see where you are in the task |
20:03.33 | randomparticle | i think it's best to get started in the morning |
20:03.49 | JeffM_ | or making a C# minecraft world |
20:04.05 | blast007 | I still need to finish updating the bzfquery.php file... got caught up with a problem with it not liking OpenFFA servers |
20:04.18 | blast007 | think I'm assuming something that isn't the case for OFFA |
20:04.28 | JeffM_ | did we get IsKillable fixed up to workwith openFFA? |
20:04.42 | blast007 | not sure what that is |
20:04.59 | blast007 | oooh, where it didn't say you TKed someone? |
20:05.04 | JeffM_ | it's the function that is used to know if someone you shot or aim at is killable |
20:05.16 | blast007 | I don't know if that was fixed or not |
20:05.21 | JeffM_ | yeah cus TK is optional now |
20:05.34 | JeffM_ | and in openFFA everyone is killable and not a friend |
20:05.41 | blast007 | :) |
20:05.49 | JeffM_ | probalby should make a "IsFriendly" function that's used by the IFF |
20:05.51 | blast007 | not even the companion cube is your friend there |
20:05.59 | mdskpr_ | mcspider posted a patch for that fix |
20:06.02 | blast007 | but that's probably becaused you murdered it |
20:06.11 | JeffM_ | mdskpr_, did you apply it? |
20:06.18 | mdskpr_ | not yet |
20:06.22 | JeffM_ | k |
20:06.30 | mdskpr_ | i was gonna ask if someone else had started, but i guess not |
20:06.37 | JeffM_ | go for it |
20:10.03 | blast007 | are we putting all the necessary names for credit on the changelog? like, if we accept a patch, should it have the name of who applied it and who wrote it? |
20:11.28 | JeffM_ | yes |
20:11.36 | JeffM_ | under code contributors |
20:11.45 | JeffM_ | I've been doing that for the patches I've applied |
20:12.09 | blast007 | I mean, here, I guess it shows the name in the description too "* Accepted patch from McSpider, removed client option to turn off fog - David Anderson" |
20:12.43 | JeffM_ | oh changelog |
20:12.49 | JeffM_ | sorry I read authors |
20:13.02 | JeffM_ | yeah I don't think we care if it was a patch in the changelog |
20:13.14 | JeffM_ | just state the feature and the w2 people who did it |
20:13.16 | blast007 | we should probably limit it to 80 chars as per devinfo too ;) |
20:13.18 | JeffM_ | patch author and applyer |
20:13.25 | JeffM_ | just like a backport |
20:13.31 | JeffM_ | origonal author and backporter |
20:14.18 | blast007 | is the above example fine though since it has "accepted from from PatchAuthorHere" ? |
20:14.31 | Pimpinella | anyone remembers where too old packets are discarded? |
20:15.45 | blast007 | Pimpinella: playing.cxx inside handlePlayerMessage? |
20:15.49 | blast007 | it checks the packet order there |
20:15.58 | blast007 | for MsgPlayerUpdate/MsgPlayerUpdateSmall |
20:16.41 | blast007 | JeffM_: oh, and for after 2.4.x, does it make sense that shots should be sent TCP instead of UDP? |
20:17.27 | blast007 | currently MsgShotBegin/MsgShotEnd are UDP |
20:18.15 | JeffM_ | really? |
20:18.20 | blast007 | yeah |
20:18.25 | JeffM_ | that sux |
20:18.36 | JeffM_ | does any code have to change other then the send? |
20:18.44 | blast007 | probably the receive |
20:18.50 | blast007 | I'm not sure though |
20:18.51 | JeffM_ | I don't think so |
20:19.00 | JeffM_ | they all go into a common switch after TCP and UDP |
20:19.05 | JeffM_ | I say move it now |
20:19.10 | JeffM_ | and we test it over the week |
20:19.13 | JeffM_ | and revert if needed |
20:19.23 | Chestal | IMHO they must be UDP |
20:19.44 | JeffM_ | why? |
20:19.44 | Chestal | delayed shots are no use at all |
20:19.44 | blast007 | yes they are |
20:19.46 | JeffM_ | lost shots are usless too |
20:19.49 | blast007 | that's like saying that delayed flag grabs are not useful |
20:19.56 | JeffM_ | they can stay UDP if the server sends back a TCP shot confitm |
20:19.59 | JeffM_ | confirm |
20:20.00 | blast007 | if a shot is supposed to be there, it should be there |
20:20.00 | Chestal | if you make shots TCP you can as well make the position updated TCP, too |
20:20.12 | blast007 | Chestal: no. |
20:20.13 | JeffM_ | no, positons get resent again |
20:20.14 | JeffM_ | shots don't |
20:20.18 | brad | ~bz20svn |
20:20.18 | ibot | it has been said that bz20svn is http://my.bzflag.org/w/BZFlag_SVN and svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag |
20:20.27 | blast007 | brad: that's outdated |
20:20.33 | JeffM_ | I understand your concern about delay |
20:20.36 | Chestal | what good is a shot that is sent 1 or 2 seconds later? |
20:20.43 | brad | thought so, getting errors svn up'ing :p |
20:20.45 | Chestal | it does more harm than good IMHO |
20:20.54 | JeffM_ | but we need something to remove dropped shots |
20:21.00 | *** join/#bzflag RatOmeter (~chatzilla@r74-195-237-138.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
20:21.11 | blast007 | Chestal: the fact that the player shooting sees a bullet. that's what's wrong. ;) |
20:21.15 | JeffM_ | perhaps TCP is not the answer but what we do now is not great |
20:21.21 | JeffM_ | blast007, it'll be in the wrong place |
20:21.24 | blast007 | if their bullet didn't get through, the local client shouldn't think there is |
20:21.26 | JeffM_ | we won't interpolate it |
20:21.35 | JeffM_ | at least now the droped shot won't kill anyone |
20:21.46 | JeffM_ | so I understand his point |
20:21.49 | JeffM_ | ponders |
20:21.56 | blast007 | the reason I'm bringing this up is because it's likely why there is false EndShot credit kicks |
20:22.11 | JeffM_ | probablyh |
20:22.18 | blast007 | if someone is shooting a GM and their begin's are getting dropped, but their ends are getting send - KICK |
20:22.21 | blast007 | sent* |
20:22.38 | JeffM_ | a solution that would work for both sets would be for the server to send back a TCP "shot confirmed" message |
20:22.54 | JeffM_ | then if the client dosn't get that in some time or before another one to drop the shot from it's local display |
20:23.11 | JeffM_ | and the delay in the confirmation message dosn't matter |
20:23.11 | blast007 | that might be more confusing for the player shooting |
20:23.27 | Pimpinella | really, any delay is unacceptabe as far as it concerns shots |
20:23.29 | JeffM_ | it's no more confusing then it is now for when there shot goes thru someone and dosn't kill them |
20:23.39 | blast007 | cuz currently shots disappearing shortly after firing == someone else on the map cheating |
20:23.50 | JeffM_ | so does shots not killing someone ;) |
20:23.59 | Chestal | the upcoming release doesn't include major changes to lag / server side state handling, or does it? |
20:23.59 | trepan | JeffM_: which all the cheats about, they're probably used to it ;) |
20:24.08 | JeffM_ | and lag too |
20:24.13 | JeffM_ | Chestal, no |
20:24.43 | blast007 | I just think that a bullet being there or not is important information that shouldn't get lost |
20:24.55 | JeffM_ | you are correct |
20:24.56 | blast007 | considering we aren't a game where you're firing 30 rounds a second |
20:25.19 | JeffM_ | we'd need to make sure that the client was able to handle the delay in remote shots |
20:25.23 | Chestal | it might be nice to have the server detect a lost shot and keep track of it in lagstats or some place |
20:25.23 | JeffM_ | so yeah push it to 2.6 |
20:25.34 | JeffM_ | it needs more thought |
20:25.41 | JeffM_ | but is a valid concern |
20:26.25 | Chestal | actually, an even more important stat might be lost incoming shots for a player |
20:26.34 | CIA-103 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7727 10/w/Development_RoadMap: /* 2.6 (Next Breaking Release) */ dropped shots |
20:26.36 | Chestal | because I suspect that some UDPpackets get lost server -> player |
20:26.43 | JeffM_ | yeah |
20:27.01 | JeffM_ | that could be done with UDP confirm codes too |
20:27.09 | Chestal | which would explain some non-deaths |
20:27.16 | blast007 | the ones that are causing the endshot kicks are lost from player -> server |
20:27.16 | JeffM_ | tho that's the same as TCP retansmits |
20:27.26 | JeffM_ | oh there are so many reasons for non-deaths :) |
20:27.27 | Chestal | of course, you can't really draw any conclusons from it because when he's cheating he can just fake the stats :-) |
20:27.29 | blast007 | (or at least, that's my hunch as to the source of the problem) |
20:27.57 | JeffM_ | I'd be interesting to test if our own UDP confirm messages are generaly faster or slower then TCP |
20:28.30 | mdskpr_ | JeffM: simple bug fixes do not go into the changelog? |
20:28.38 | JeffM_ | depends |
20:28.44 | JeffM_ | but some of them won't |
20:28.54 | blast007 | at some point should we be looking into a lib like enet? http://enet.bespin.org/ |
20:29.04 | JeffM_ | blast007, we could |
20:29.04 | blast007 | wonder if that would mix with our HTTP stuff |
20:29.06 | JeffM_ | or raknet |
20:29.13 | JeffM_ | that's the problem with them |
20:29.24 | JeffM_ | but at that point maybe we do HTTP on it's own port |
20:29.27 | blast007 | enet is UDP only, and offers the confirmations |
20:29.33 | JeffM_ | yeah |
20:29.36 | blast007 | so we could do UDP for the game stuff, and TCP for the HTTP |
20:29.37 | JeffM_ | raknet can do the same |
20:29.50 | JeffM_ | I have used both |
20:30.04 | JeffM_ | I liked raknet's API better |
20:30.15 | JeffM_ | more C++y |
20:30.43 | JeffM_ | I belive it had classes that made it easy to keep copies of objects synced on both sides of a net connection |
20:30.45 | JeffM_ | and has channels |
20:30.59 | blast007 | raknet's license isn't "open" though? |
20:31.25 | JeffM_ | it isn't? |
20:31.33 | blast007 | http://www.jenkinssoftware.com/pricing.html |
20:32.04 | JeffM_ | huh I never paid for it |
20:32.07 | JeffM_ | guess it changes |
20:32.09 | JeffM_ | changed |
20:32.13 | JeffM_ | yep enet it is then :) |
20:32.22 | JeffM_ | that sucks it was really cool |
20:32.23 | blast007 | their hobbyist is "free", but seemingly only free as in beer |
20:33.08 | JeffM_ | yeah but I didn't have to fill out a form when I was using it |
20:33.11 | JeffM_ | oh well |
20:35.09 | blast007 | probably easier to integrate enet as it doesn't do as much - it's just a network lib, not a lobby/update/etc system |
20:35.40 | JeffM_ | go managed and use lidgren |
20:36.00 | blast007 | :) |
20:38.31 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
20:43.04 | JeffM_ | allejo, Thumper_ or myself are available to help you with upgrade questions if needed. |
20:43.45 | TD-Linux | I don't see any good reason to just do TCP for that if there is already a TCP connection |
20:43.55 | allejo | JeffM_: very much appreciated :) |
20:43.58 | TD-Linux | ... well I guess TCP also guarantees in-order which isn't necessary |
20:45.30 | JeffM_ | TD-Linux, it can also make a big delay |
20:45.41 | JeffM_ | if it has to do retransmits |
20:45.57 | TD-Linux | yeah because of the in-order ness |
20:46.00 | JeffM_ | so the position won't be right for the time that the client gets it |
20:46.04 | JeffM_ | or packetloss |
20:46.15 | JeffM_ | it will try to send that sucker for a while :) |
20:46.28 | TD-Linux | well for the shots you want an ack and retransmit anyway you were saying |
20:46.28 | JeffM_ | yeah but only once |
20:46.32 | JeffM_ | not a retransmit |
20:46.38 | JeffM_ | not for to server |
20:46.51 | JeffM_ | if no ack from server drop it |
20:46.54 | TD-Linux | oh, so the bullet just dissapears if no ack |
20:46.57 | JeffM_ | yeah |
20:47.00 | JeffM_ | faster |
20:47.12 | trepan | another common tactic is to double up on the control messages, or even send them 3 times |
20:47.12 | TD-Linux | actually the server will always be telling the client the state of its own bullets |
20:47.22 | JeffM_ | it only makes one person's sim less accurate |
20:47.33 | JeffM_ | trepan, yeah I could see that |
20:47.37 | TD-Linux | so it's not even an ack because you should be getting a stream of them, just like you do player positions from the server |
20:47.59 | JeffM_ | TD-Linux, except the server dosn't do much shot tracking now |
20:47.59 | TD-Linux | which will fix the player's bullet positions in the case of a physics mismatch |
20:48.04 | JeffM_ | shotbranch did the ack thing |
20:48.17 | JeffM_ | TD-Linux, thats only after we have full server side sim |
20:48.23 | JeffM_ | this could be implemented before |
20:48.28 | TD-Linux | oh OK I see |
20:49.02 | TD-Linux | what extent of server side sim is implemented in 2.99? or is that just lag compensation? |
20:49.05 | JeffM_ | in shot branch shots you fired were given temporary IDs untill you got back a "real" ID from the server |
20:49.13 | JeffM_ | lag comp isn't even in 2.99 |
20:49.14 | trepan | TD-Linux: basically, nothing |
20:49.29 | trepan | if i'm going to do it, i'm going to do it right |
20:49.39 | JeffM_ | go read the "common miconceptions about v3" |
20:50.15 | trepan | and right means rippin', lotza rippin' |
20:50.45 | *** join/#bzflag noyb (~noyb@64.134.228.153) |
20:54.13 | CIA-103 | BZFlag: 03mudskipper * r21913 10/trunk/bzflag/src/bzflag/ (World.h playing.cxx): Accepted Patch #3315330 from McSpider, fixing oFFA same color lockon with GM--it no longer shows an invalid marker |
20:54.13 | JeffM_ | hopefuly we'll survive it :) |
20:56.21 | trepan | thing of it like Steve Austin :) |
20:56.35 | JeffM_ | harder faster better stronger |
20:56.57 | JeffM_ | but sadly he could not go back to the people in his former life, to them he was dead ;) |
21:09.10 | trepan | fwiw, i'll note that when sending control input from clients to the server, the UDP header size is likely a significant portion of the packet |
21:09.33 | trepan | so tacking in a few redundant frames of older info is low cost |
21:25.10 | TD-Linux | is there a reason locking on to a teammate with GM is even allowed? |
21:30.41 | allejo | so the tk ratio is still in use? o.O |
21:33.06 | JeffM_ | TD-Linux, it's a disavantage of the shot |
21:33.37 | allejo | can you still shoot teammates in 2.3? |
21:33.45 | allejo | just with regular shots? |
21:37.11 | *** join/#bzflag KTL (~KTL@85.234.201.192) |
21:47.07 | blast007 | allejo: 2.3/2.4 has an option to disable shots from killing teammates |
21:47.23 | blast007 | and it also has an Open FFA mode (which is where color doesn't matter - you can shoot anyone) |
21:47.49 | blast007 | but those two exceptions aside, TKs work the same as in 2.0.x |
21:47.58 | allejo | ah alright |
21:50.18 | *** join/#bzflag Kutakizukari (~Kutakizuk@74.5.221.235) |
21:52.15 | *** join/#bzflag Gilly (~btw@83.146.211.140) |
21:52.16 | *** join/#bzflag Gilly (~btw@about/essy/ilkimys/gilly) |
21:56.13 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
22:18.06 | allejo | on here, http://my.bzflag.org/w/BZFS_API_2.4_Upgrade, are " bz_bz_APIFloatList" and "bz_bz_APIStringList" typos? |
22:18.58 | JeffM_ | what does the header say? |
22:22.05 | allejo | i'm sorry, what header? |
22:22.47 | JeffM_ | the api header |
22:22.51 | JeffM_ | bzfapi.h |
22:23.51 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
22:23.51 | *** mode/#bzflag [+v bryjen] by ChanServ |
22:25.29 | allejo | header says "bz_APIStringList" and "bz_APIFloatList" |
22:26.22 | *** join/#bzflag kierra1 (~jolie@ool-44c153c5.dyn.optonline.net) |
22:28.31 | *** join/#bzflag BlasterWisconsin (~blasterwi@CPE-72-131-125-36.wi.res.rr.com) |
22:28.31 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
22:28.49 | CIA-103 | BZFlag: 0376.95.144.121 07http://my.bzflag.org * r7728 10/w/BZFS_API_2.4_Upgrade: /* Upgrade */ |
22:29.10 | JeffM_ | the header is king |
22:29.27 | JeffM_ | there was a lot of copy and paste when I wrote that :) |
22:33.57 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
22:34.32 | KTL | http://my.bzflag.org/bb/download/file.php?id=13810 <- this was on the forum, looks nice |
22:35.23 | allejo | copy paste rules but it's too easy to make errors :P |
22:37.24 | allejo | btw, should i have added the change i made? i forgot about that |
22:39.03 | JeffM_ | delusional, a few months ago was totaly different code. |
22:39.18 | delusional | so get the new SDL? |
22:39.29 | JeffM_ | what worked for 2.0.x? |
22:39.33 | delusional | try it, then revert when it doesnt work? |
22:40.13 | JeffM_ | the build system for 2.4 is based on the one from 3.0 |
22:40.27 | JeffM_ | and yes I belive we upgraded that to 1.3 for sdl |
22:40.34 | JeffM_ | 2.0.x uses 1.2 |
22:40.49 | KTL | http://my.bzflag.org/bb/viewtopic.php?f=43&t=16818&p=153094 <- these look good, seem to look better compared to some from the game, license seems to be ok ... |
22:40.50 | delusional | 95 percent of the compile problems I've ever had have been SDL related.... after this compile finishes, I'll upgrade SDL and see what heppens. |
22:41.31 | JeffM_ | you can't have both SDLs? |
22:41.49 | delusional | i know |
22:41.57 | JeffM_ | that was a question |
22:42.00 | JeffM_ | I can have both on windows |
22:42.11 | JeffM_ | and point each build to the right one |
22:42.51 | delusional | missing is missing. from configure... |
22:42.52 | delusional | configure: WARNING: `missing' script is too old or missing |
22:43.14 | JeffM_ | other people don't seem to have an issue building |
22:43.18 | delusional | <PROTECTED> |
22:43.21 | JeffM_ | I know BulletCatcher and blast have been doing it |
22:43.29 | JeffM_ | did you run autogen and all that? |
22:43.33 | delusional | yep |
22:43.50 | JeffM_ | probably want to pastebin the output and get with BulletCatcher on it then |
22:44.00 | JeffM_ | these are the things I wanted tested :) |
22:44.19 | KTL | compiles for me, without fresh autogen |
22:44.38 | JeffM_ | what version of SDL do you have KTL ? |
22:44.40 | blast007 | delusional: latest code? |
22:45.10 | KTL | libsdl1.2-dev 1.2.14-6.4 |
22:45.18 | KTL | 1.2 |
22:45.19 | blast007 | delusional: hmm, and yeah, I don't have that file either |
22:45.24 | JeffM_ | oh do we care about supporting PPC this release? |
22:45.34 | JeffM_ | or anything older then 10.4? |
22:45.34 | blast007 | though I have a locally installed libcurl dev package, so I'm not building the curl in our tree |
22:46.01 | allejo | i don't have that file in the source either |
22:47.25 | allejo | JeffM_: are you talking about mac os 10.4? |
22:48.13 | blast007 | yes |
22:48.40 | allejo | mac os 10.7 is being released in july. i think most people would drop 10.4 support by now |
22:49.08 | blast007 | all the mac people I know (granted, not too many) aren't going to get 10.7 |
22:49.23 | delusional | unless they have a laptop |
22:52.27 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
22:54.07 | JeffM_ | 10.4 was the first with universal support IIRC |
22:57.31 | JeffM_ | the other question is who is going to build the .app package |
22:57.36 | JeffM_ | I hope Constitution can do it |
22:57.42 | JeffM_ | he did a good job on the last one |
22:58.38 | JeffM_ | also.. no debug build this time |
23:08.18 | blast007 | wonder if we need to tweak any build scripts or the xcode project so that it strips the binaries for mac |
23:08.35 | JeffM_ | probably |
23:09.19 | PlasticTank | Has anyone tried on xcode 4? |
23:10.00 | allejo | i really dislike xcode 4 so i haven't tried |
23:10.16 | blast007 | it probably doesn't really matter which version, much |
23:10.41 | JeffM_ | it would be nice if the .app was part of make install |
23:10.42 | blast007 | we don't really use xcode for much of the process - we just have it call the shell scripts (configure and make, and maybe autogen to start off) |
23:10.46 | JeffM_ | instead of the xcode |
23:10.57 | JeffM_ | then just have xcode call that |
23:11.14 | JeffM_ | remove some of brlcad's mysic sorcery |
23:11.19 | JeffM_ | mystic even |
23:11.51 | blast007 | well, or something like debian's build (we have a 'make debian-release' |
23:11.52 | blast007 | ) |
23:11.57 | JeffM_ | yeah |
23:12.02 | JeffM_ | something like that |
23:12.07 | JeffM_ | or even a seperate script that is called |
23:12.15 | JeffM_ | but something somewhere we can actualy see and edit |
23:12.21 | JeffM_ | and call from the command line |
23:12.51 | JeffM_ | techincaly I can build the full windows bins AND installers from the commandline using msbuild :) |
23:13.16 | JeffM_ | or just hit F7 |
23:13.55 | blast007 | I think OSX has a command line thing too for xcode |
23:14.56 | blast007 | and really, I don't think we need the fancy DMG with the background image |
23:15.04 | blast007 | we could just zip the .app |
23:15.21 | JeffM_ | probably |
23:15.28 | JeffM_ | can OSX unzip by default? |
23:15.44 | *** part/#bzflag kierra (~jolie@unaffiliated/kierra) |
23:15.47 | allejo | blast007: xcodebuild -project BZFlag.xcodeproj -alltargets |
23:16.15 | allejo | blast007: that would be the command line for xcode |
23:21.47 | allejo | JeffM_: i'm not entirely sure but i was looking through my macports list of installed packages and i don't see zip or unzip, so i'm assuming it's already installed by default |
23:21.56 | CIA-103 | BZFlag: 03Thumper 07http://my.bzflag.org * r7729 10/w/BZFS_2.4_Upgrade: New page: Stub for BZFS 2.0.x to 2.4 server upgrade path == TODO == * document -publickey and how to generate them * document changes in command line options * reference plugin upgrade for 2.0.x t... |
23:22.14 | JeffM_ | how does someone unzip from the finder? |
23:22.26 | McSpider | double click it |
23:23.00 | JeffM_ | that works on a default clean install? |
23:23.09 | allejo | yes |
23:23.09 | McSpider | yep |
23:23.12 | JeffM_ | if so then zip is fine |
23:23.15 | PlasticTank | archiver does it right? |
23:23.21 | allejo | PlasticTank: yes |
23:23.33 | JeffM_ | works all the way back to 10.4? |
23:23.42 | blast007 | JeffM_: yeah |
23:23.48 | JeffM_ | then yeah zip is fine |
23:24.10 | blast007 | easier to automate :) |
23:24.13 | JeffM_ | yeah |
23:24.17 | JeffM_ | does it work in IE3? |
23:24.18 | JeffM_ | ;) |
23:24.30 | blast007 | only if you reboot between steps |
23:24.51 | allejo | blast007: awww no fancy dmg? mac users like those :P |
23:25.01 | blast007 | allejo: they should get a PC then ;) |
23:25.07 | blast007 | our fancy installer on Windows is a double click to make |
23:25.15 | McSpider | I like zips better, thank you :P |
23:25.16 | CIA-103 | BZFlag: 03Thumper 07http://my.bzflag.org * r7730 10/w/BZFS_2.4_Upgrade: Fix the link |
23:25.29 | JeffM_ | not even a double click anymore blast007 |
23:25.32 | JeffM_ | it's part of the build |
23:25.33 | JeffM_ | ;) |
23:25.57 | allejo | McSpider: but dmgs look fancy |
23:26.05 | JeffM_ | whopty do |
23:26.12 | McSpider | so what, zips open faster. |
23:26.32 | PlasticTank | I was gonna say dmgs are spiffy :D |
23:26.46 | JeffM_ | you can make your own dmg if you want |
23:28.31 | allejo | McSpider: i think it depends on what is being distributed. if the dmg has an .pkg then it comes in handy. one less thing to delete. if it's an .app then it comes about to be the same. |
23:28.59 | McSpider | yep |
23:29.19 | JeffM_ | prefers the minecraft method of distrobution |
23:29.29 | JeffM_ | ship one thing and have it patch itself up to the current version |
23:29.59 | bryjen | JeffM_ / KTL : i noticed when 2.99 started complaining it wanted SDL 1.3, but it never failed to build or caused problems for me with 1.2 |
23:30.11 | JeffM_ | hmmm |
23:30.15 | Pimpinella | i could reproduce the "bzfs sometimes gets into a mode where CTF team flags spawn at random places, |
23:30.15 | Pimpinella | <PROTECTED> |
23:30.16 | JeffM_ | that sounds like build system bug then |
23:30.22 | JeffM_ | it ether requires it or it dosn't |
23:30.23 | Pimpinella | bug |
23:30.46 | Pimpinella | happens when i leave the server while holging my teamflag |
23:30.58 | JeffM_ | find a fix fo rit? |
23:31.09 | Pimpinella | not tonight |
23:31.12 | Pimpinella | beddine ;) |
23:31.17 | Pimpinella | bedtime |
23:31.20 | JeffM_ | sometime in the next week? |
23:31.27 | Pimpinella | already typing crap all the time ;) |
23:31.30 | Pimpinella | i hope so |
23:31.33 | JeffM_ | good enough |
23:55.49 | JeffM_ | delusional, 2.4.2 will not have horizontal teleporters |
23:56.00 | JeffM_ | the soonest that can go in is 2.6 |
23:57.45 | KTL | *mental breakdown for delusional* |
23:58.09 | JeffM_ | it would be a proto breaking change |
23:58.18 | JeffM_ | and that means the next breaking release |
23:58.21 | JeffM_ | not the next release |