| 00:09.45 | *** join/#bzflag Scrumpy_ (~Scrumpy@smurfnet.xs4all.nl) |
| 00:10.10 | *** join/#bzflag BlasterWisconsin (~blasterwi@CPE-72-131-65-159.wi.res.rr.com) |
| 00:10.10 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
| 00:29.55 | *** join/#bzflag JeffM (~JeffM@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
| 00:29.55 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 00:29.55 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 00:48.31 | JeffM | so we ready for a beta? |
| 01:07.02 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 01:15.27 | delusional | Is beta ready for us? |
| 01:15.39 | trepan | nope, just in europe |
| 01:21.41 | allejo | are people using it yet? |
| 01:23.12 | trepan | it hasn't been tagged/released |
| 01:24.30 | allejo | is the svn still tagged as 2.3.13? |
| 01:26.07 | BulletCatcher | I have had about 20 different players connect to my 2.3.x server over the last month. |
| 01:26.43 | allejo | BulletCatcher: i meant using it to actually play, not just explore and test stuff |
| 01:26.44 | blast007 | points allejo to https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/src/date/buildDate.cxx |
| 01:27.02 | blast007 | depends on your definition of "play" |
| 01:27.31 | allejo | darn it. still 2.3.13 D: |
| 01:27.31 | BulletCatcher | We had a multiplayer test session a week or two ago. |
| 01:27.38 | BulletCatcher | It lasted about 20 minutes. |
| 01:27.41 | blast007 | multiple people have been on the same 2.3 server, if that's "playing" |
| 01:28.00 | KTL | and bots, 30 bots at once, thing worked fine |
| 01:28.01 | blast007 | allejo: and why does it matter if it's still 2.3.13? |
| 01:28.53 | allejo | blast007: i was just curious, wondering if the svn was 2.4 officially |
| 01:29.10 | BulletCatcher | On Friday I failed to reproduce the reported flag grab bugs, so at this point I don't know of any regressions. |
| 01:30.36 | BulletCatcher | Anyone else up for "test" session right now? We just need to pick a map. |
| 01:30.50 | delusional | I'll go |
| 01:30.52 | KTL | has a fresh compiled client |
| 01:31.56 | BulletCatcher | How about Fox Burrow? rabbit chase is good free-for-all |
| 01:32.18 | blast007 | let me build a release client quick so I can play on this system |
| 01:32.30 | delusional | i need a few seconds too |
| 01:32.41 | delusional | my sdl needs to bdowngraded |
| 01:33.00 | BulletCatcher | Come and get me. |
| 01:34.01 | delusional | the bug was in CTF, right? |
| 01:34.18 | BulletCatcher | One of them was. |
| 01:34.35 | blast007 | what was the bug? |
| 01:35.08 | delusional | jump to capture a flag... your flag is on your base... you capture your flag |
| 01:35.30 | blast007 | wonder if that's induced by high lag |
| 01:37.21 | BulletCatcher | I was on my local network when I tested, so I can't rule that out. |
| 01:38.28 | delusional | who reported it? |
| 01:38.54 | *** join/#bzflag bier_ (~bier@p54A5AD1E.dip.t-dialin.net) |
| 01:39.23 | BulletCatcher | moiree reported it |
| 01:47.11 | delusional | looks like that bug is there |
| 01:47.15 | BulletCatcher | Yup. |
| 01:48.03 | blast007 | however, I do seem to recall that it exists in 2.0.x as well, so I don't think it's a regression |
| 01:48.17 | delusional | I'm getting "cannot load texture shot_tail" on every bullet |
| 01:48.42 | blast007 | delusional: are you running from a .app you made? |
| 01:48.51 | delusional | I am |
| 01:49.13 | delusional | there is no other mac version available |
| 01:49.30 | blast007 | you can run from the source tree, I mean ;) |
| 01:50.01 | delusional | I'm too fat. |
| 01:50.01 | TD-Linux | BulletCatcher: I'm in |
| 01:52.40 | blast007 | delusional: I'm betting if you check inside the .app that the shot_tail.png file is not there |
| 01:54.17 | delusional | Was not following what you said.... i need to "make install" to have an app. I did not do that. So i'm running from inside the source tree |
| 01:55.37 | delusional | shot_tail.png is in my data folder |
| 01:58.09 | moiree | delusional: You need to start it from the trunk directory like: src/bzflag/bzflag |
| 01:58.22 | delusional | thats what I'm doing |
| 01:58.27 | moiree | um |
| 02:00.44 | moiree | Then perhaps start it with the -dir option? |
| 02:01.17 | JeffM | oh I don't expect us to have builds untill tomorow night my time |
| 02:01.23 | JeffM | I just got back from idaho |
| 02:02.48 | allejo | you western time jeff? |
| 02:03.31 | JeffM | ja |
| 02:06.13 | JeffM | if we need an extra day or so that's fine |
| 02:06.30 | JeffM | I just didn't see much in the logs over the weekend and I wonder where we are |
| 02:06.43 | JeffM | I'm sure there will be packaging problems with all the builds |
| 02:06.55 | JeffM | we'll be constantly updating them with fixes I hop |
| 02:06.56 | JeffM | hope |
| 02:08.09 | delusional | hmm.. that worked... I thought if I needed -directory, i would not have ANY textures |
| 02:08.20 | delusional | instead of only a single texture missing |
| 02:08.43 | JeffM | when I added the new texture I just added it to the makefile |
| 02:08.57 | JeffM | that won't affect the creation of the .app unless it does all things in the data dir |
| 02:28.02 | blast007 | JeffM: well, I built release on my system and it is running fine on another system via the installer |
| 02:28.10 | blast007 | so at least the important OS works fine ;) |
| 02:28.21 | blast007 | runs from all the mac and *nix users |
| 02:28.32 | JeffM | oh yeah the windows installer is fine it does data/* |
| 02:30.51 | JeffM | and what all 4 of them? that can't be that hard |
| 02:31.40 | TD-Linux | so where do screenshots go on linux? |
| 02:31.47 | blast007 | hmm, should the misc/ directory be within data/ or in the root of the install path? |
| 02:31.56 | blast007 | TD-Linux: probably ~/.bzf/screenshots/ |
| 02:31.57 | JeffM | dev/null |
| 02:32.04 | JeffM | root not data |
| 02:32.12 | blast007 | k |
| 02:32.28 | TD-Linux | also does 2.3 print a message when you take a screenshot? |
| 02:33.45 | delusional | it may also be worth testing /saveworld and /saveworld -o |
| 02:34.18 | JeffM | or removing them :) |
| 02:34.29 | allejo | TD-Linux: on Mac it does, so i'm assuming it should on linux |
| 02:34.41 | TD-Linux | yeah I get nothing |
| 02:34.43 | TD-Linux | what source file is that? |
| 02:35.04 | JeffM | TD-Linux, your key bindings right? |
| 02:35.11 | TD-Linux | quite possibly not |
| 02:36.03 | JeffM | new config dir so you don't get your old one |
| 02:36.12 | blast007 | there's been some wackyness with the key bindings not getting set up right |
| 02:36.15 | JeffM | and I doubt anyone changed the migration code like I asked |
| 02:36.23 | TD-Linux | there is no screenshot key binding in bzflag menu |
| 02:36.43 | JeffM | well that fixes F5 problems then |
| 02:37.05 | TD-Linux | F5 is not bound to anything |
| 02:37.13 | TD-Linux | I thought F5 was threaded now anyway? |
| 02:37.21 | JeffM | just the compression on the command |
| 02:37.36 | JeffM | sounds like the binding and command got broken in that change |
| 02:37.54 | JeffM | who backported that? |
| 02:38.05 | TD-Linux | ok yup 2.4 has no f5 keybinding |
| 02:38.18 | TD-Linux | I copied the line "bind f5 screenshot" from my 2.0 config file and it works now |
| 02:38.23 | JeffM | but can you set it in the UI? |
| 02:38.25 | TD-Linux | nope |
| 02:38.40 | JeffM | you want to fix it? |
| 02:38.53 | TD-Linux | I can |
| 02:39.03 | JeffM | make it so |
| 02:39.05 | CIA-5 | BZFlag: 03blast007 * r21946 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: For the server shortcuts (and the server config thingy), set the working directory to the installation root instead of the data directory. |
| 02:39.48 | allejo | "server config thingy"? o.O |
| 02:40.30 | JeffM | we want to remove the in game server menu and replace it with an external tool |
| 02:40.47 | JeffM | there is a java config makeer and a 2 different C# apps that can do it |
| 02:41.19 | blast007 | allejo: the bzfs_config.html thingy |
| 02:41.26 | allejo | ohhhhh |
| 02:41.26 | blast007 | javascript, not java ;) |
| 02:41.32 | JeffM | whatevs |
| 02:42.20 | delusional | no apparent problems in saveworld.... there is still no "info" block, i guess |
| 02:42.33 | delusional | "info object" |
| 02:42.33 | blast007 | nope |
| 02:42.42 | blast007 | only BZW change is the ricochet thing |
| 02:43.00 | *** join/#bzflag Ebert (~EbErT@99-98-153-115.lightspeed.tukrga.sbcglobal.net) |
| 02:43.52 | Ebert | any quol admins on here? if on appears, direct him/her to quol 5158 |
| 02:50.35 | JeffM | do we have to support finding the config from more then one old version ago? |
| 02:52.03 | Ebert | nvm, the issue has been settled |
| 02:52.51 | blast007 | JeffM: nah |
| 02:54.05 | trepan | delusional: material \n name info \n addshader copyright__(c)_2010-2011_delusional \n addshader license__i_don't_care \n end |
| 02:54.49 | delusional | never underestimate my ability to not care. |
| 02:55.30 | KTL | :D |
| 02:55.34 | TD-Linux | JeffM: http://paste2.org/p/1479185 |
| 02:55.52 | JeffM | submit it to sf |
| 02:55.55 | JeffM | please |
| 02:55.59 | JeffM | we need a record of it |
| 02:56.27 | JeffM | why is it in a #def? |
| 02:56.57 | TD-Linux | I removed the def |
| 02:57.02 | JeffM | k |
| 02:57.22 | TD-Linux | the def was only partially implemented anyway, that's the only instance of SNAPPING in the code |
| 02:57.59 | JeffM | who added that? |
| 02:59.21 | trepan | SNAPPING been around for quite some time |
| 02:59.37 | JeffM | never seen it as a build option |
| 02:59.42 | JeffM | oh well |
| 02:59.59 | trepan | see r21440 (DTR) |
| 03:00.29 | JeffM | seems like a silly thing to have as an option now |
| 03:01.59 | CIA-5 | BZFlag: 03JeffM2501 * r21947 10/trunk/bzflag/src/game/DirectoryNames.cxx: no more "my" crap |
| 03:03.39 | TD-Linux | https://sourceforge.net/tracker/?func=detail&aid=3322754&group_id=3248&atid=303248 |
| 03:06.16 | CIA-5 | BZFlag: 03JeffM2501 * r21948 10/trunk/bzflag/src/bzflag/clientConfig.cxx: have windows pull the config from the old docs dir if it can find it before it tries to "upgrade" it |
| 03:07.23 | JeffM | you already in the authors file TD-Linux ? |
| 03:10.07 | TD-Linux | not for bzflag |
| 03:11.44 | CIA-5 | BZFlag: 03JeffM2501 * r21949 10/trunk/bzflag/ (3 files in 2 dirs): add patch 3322754 to add screenshots back to the keybindings. Thanks TD-Linux |
| 03:11.52 | JeffM | you are now |
| 03:13.55 | TD-Linux | ok |
| 03:14.19 | BulletCatcher | Here's a fun bug PlasticTank just discovered. |
| 03:14.21 | BulletCatcher | If you are touching a wall, you can fire lasers through the wall at a 45 degree angle. |
| 03:14.32 | BulletCatcher | Easy to reproduce on the flagbuffet map. |
| 03:14.39 | BulletCatcher | Even the outside wall. |
| 03:14.43 | JeffM | does it happen in 2.0? |
| 03:15.02 | BulletCatcher | Probably not, but I'll test. |
| 03:15.09 | PlasticTank | It's greater then 45 degrees |
| 03:15.10 | JeffM | actualy I bet it does |
| 03:15.19 | JeffM | cus that code hasn't changed IIRC |
| 03:15.47 | trepan | ZERO_TOLERANCE? |
| 03:16.04 | JeffM | ahh possibly |
| 03:17.20 | JeffM | if it's not a regression then the caring level should go down a lot |
| 03:22.08 | blast007 | I've done stuff like that for a long time |
| 03:23.18 | JeffM | if it's not new then it falls into the "yes we know sim sucks" boat |
| 03:23.46 | blast007 | works on teleporters too (if you aim just right, you can shoot between the border and the event horizon and kill tanks behind a tele) |
| 03:23.59 | blast007 | yeah, we've had that issue forver |
| 03:24.14 | blast007 | I remember it being worse in 1.7 when the laser was even longer and there was less compex map objects |
| 03:25.06 | JeffM | we'll see what BulletCatcher says he seems to have the duplication down |
| 03:25.34 | JeffM | if it was changed for the worse by the tolerance then we revert and fix sim later |
| 03:33.21 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 03:33.21 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 03:36.59 | BulletCatcher | I cannot reproduce laser through walls in 2.0.16. |
| 03:37.44 | PlasticTank | Same here |
| 03:38.19 | delusional | it should be on the same map |
| 03:38.25 | BulletCatcher | I'll revert ZERO_TOLERANCE and test again. |
| 03:38.26 | BulletCatcher | It will take me awhile to recompile. |
| 03:39.25 | JeffM | k |
| 03:39.39 | JeffM | we can delay the schedule a few days if needed |
| 03:39.46 | JeffM | we are still doing good |
| 03:40.09 | BulletCatcher | Would we have to make any other changes to compensate for reverting ZERO_TOLERANCE? |
| 03:40.20 | JeffM | nope |
| 03:40.35 | JeffM | and thats what I fear may be the problem, it may have gone along with other changes to SIM |
| 03:41.19 | trepan | there were definitely related changes in 2.99 |
| 03:41.41 | JeffM | then revert away :) |
| 03:44.49 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 03:44.49 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 03:45.06 | JeffM | do we want to build a set of "alpha" packages just to get more testing? |
| 03:45.24 | JeffM | tho we are "feature complete" so we can call it beta |
| 03:49.23 | BulletCatcher | Windows and Mac OS X can easily have multiple versions of BZFlag installed at the same time, but Linux packaging doesn't have that convenience. |
| 03:49.28 | BulletCatcher | I could build a Fedora RPM that would install in a non-standard location. |
| 03:49.29 | BulletCatcher | If someone else could do Debian/Ubuntu then we ought to have most players covered. |
| 03:51.15 | BulletCatcher | Reverting ZERO_TOLERANCE fixes the laser-through-walls problem for me. |
| 03:53.37 | BulletCatcher | The old working value is 1/50 of the new one that doesn't work, so we have to be less tolerant of errors. |
| 03:53.46 | blast007 | BulletCatcher: could this be helpful? http://sourceforge.net/projects/suparun/ someone had done that for 2.0.8 |
| 03:54.35 | BulletCatcher | Huh. |
| 03:55.35 | blast007 | haven't tried it myself though - not sure it it would take over as the main one if you run 'bzflag' in a terminal |
| 03:56.29 | BulletCatcher | My idea was to have our beta executable named "bzflag24b" or similar. |
| 03:56.44 | BulletCatcher | To prevent any confusion. |
| 03:57.05 | blast007 | k |
| 03:58.05 | JeffM | then go ahead and revert it |
| 03:58.11 | BulletCatcher | Will do. |
| 03:58.15 | JeffM | and bump the proto and rev so everyone has the same value |
| 03:58.24 | BulletCatcher | Good call. |
| 03:58.40 | trepan | bzflag24b1; hope for the best, plan for the worst |
| 03:59.00 | BulletCatcher | :-) |
| 04:06.26 | CIA-5 | BZFlag: 03bullet_catcher * r21950 10/trunk/bzflag/ (4 files in 4 dirs): |
| 04:06.27 | CIA-5 | BZFlag: Revert the change to ZERO_TOLERANCE from r21908, as it lets lasers go through walls. |
| 04:06.27 | CIA-5 | BZFlag: Bump the protocol to encourage acceptance of this fix. |
| 04:08.59 | BulletCatcher | We still have to fix the flag grabbing bug(s). |
| 04:09.42 | BulletCatcher | Having at least 80 ms of lag helps manifest the problem. |
| 04:12.14 | JeffM | do we know what the fix is? |
| 04:13.02 | BulletCatcher | I suspect that the protocol back-and-forth messages need to be adjusted. |
| 04:13.05 | BulletCatcher | I am looking now. |
| 04:13.32 | BulletCatcher | In other words, "no". |
| 04:13.55 | JeffM | sounds like you have a hunch thop |
| 04:14.00 | JeffM | that's better then nothin |
| 04:14.29 | BulletCatcher | Yeah. I'd rather not revert the flag grabbing changes we have made. |
| 04:15.01 | JeffM | indeed |
| 04:19.38 | blast007 | BulletCatcher: is it a regression or just an old bug from 2.0.x (or earlier) ? |
| 04:20.27 | BulletCatcher | I haven't tested specifically, but I feel like the jump-on-flag CTF bug must be new or else we would have heard about it long ago. |
| 04:21.47 | JeffM | and.... pain meds just kicked in.... |
| 04:21.49 | delusional | I put together a map to test per-object ricochet.... didn't notice any bugs |
| 04:22.32 | BulletCatcher | The per-object rico seems to work okay in game, but I'm not so sure about saved maps. |
| 04:22.46 | delusional | hmm |
| 04:23.34 | delusional | i kinda wish it was the other way around... the keyword should be noRicochet |
| 04:23.58 | BulletCatcher | Actually, I think we should have both. |
| 04:24.29 | delusional | yessir |
| 04:24.37 | JeffM | yeah with one you wiull be wrong 1/2 time |
| 04:25.18 | BulletCatcher | "ricochet" would be be used without +r, and "noricochet" would be used with it. |
| 04:26.10 | JeffM | yeah we can figure out the sense |
| 04:26.39 | JeffM | like how the elveator at work has 2 buttons and only needs 1 cus we only have 2 floors. We just need a button that says "the other one" |
| 04:27.24 | JeffM | just make it "toglerico" |
| 04:27.42 | BulletCatcher | That's just the meds talking. :-) |
| 04:28.15 | JeffM | [.possibly |
| 04:28.25 | JeffM | but it is a togle |
| 04:28.30 | delusional | hmm.. actually, my map isnt as good as i thought it was. |
| 04:29.11 | JeffM | driving 2000 miles in a weekend is murder on my shoulder |
| 04:29.38 | blast007 | BulletCatcher: just tried to duplicate the self-cap issue on 2.0.x and couldn't, but with the same map on 2.3.x it happened |
| 04:29.47 | delusional | truck drivers all complain of shoulder pain |
| 04:30.08 | BulletCatcher | Thanks, blast007. That confirms my suspicion. |
| 04:30.28 | blast007 | this is also pre-r21950 if that matters |
| 04:31.14 | BulletCatcher | Hmm. The tolerance setting *could* affect the grabbing. |
| 04:31.28 | blast007 | updating to latest and will try again |
| 04:31.37 | BulletCatcher | Need to test r21950 before I spend more time on the protocol. |
| 04:32.09 | blast007 | oo, interesting - crashed bzflag when exiting it after I killed the server while the client was minimized |
| 04:32.19 | blast007 | I'll have to try that with a debug build |
| 04:32.32 | BulletCatcher | I don't have enough lag to my own server to demonstrate the capture bug. |
| 04:32.34 | blast007 | for now I'll test the flag grab thingy though |
| 04:40.02 | BulletCatcher | Do we currently have any object properties whose effect can be reversed by a bzfs option? |
| 04:40.03 | BulletCatcher | If not, then we probably don't want togglerico to be the first. |
| 04:42.41 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 04:46.02 | trepan | tbh, all those booleans bzw settings should probably take optional true/false values |
| 04:46.36 | trepan | that'd work nicely for "sub-classing" in general, whether it be via grouping of mesh/meshface |
| 04:46.50 | trepan | s/of/or/ |
| 04:48.07 | BulletCatcher | That would be a good one for the future releases wiki page. |
| 04:49.39 | delusional | right now, if you want to make one object not-ricochet, and all others ricochet.... you have to turn rico off, and add ricochet to all other objects. |
| 04:49.52 | BulletCatcher | Yup. |
| 04:50.07 | trepan | which isn't actually all that difficult |
| 04:50.27 | delusional | if you have a script |
| 04:50.34 | trepan | grouping |
| 04:50.44 | delusional | ahh |
| 04:50.45 | trepan | you can do it in 4 lines |
| 04:52.41 | trepan | BulletCatcher: that's something else you could add to the wiki page, materials that combined visual and simulation properties :) |
| 04:53.27 | BulletCatcher | Like rubber coated objects? |
| 04:53.53 | trepan | green translucent ricochet drivethrough walls |
| 04:53.57 | BulletCatcher | Each rico would lose speed. |
| 04:54.29 | trepan | then again, the .bzw format should probably just die |
| 04:54.53 | BulletCatcher | Perhaps, but I propose that we first replace it with something else. :-) |
| 04:55.17 | trepan | well look at that, I've got code that'll do just that :) |
| 04:55.36 | delusional | uh-oh |
| 04:56.00 | trepan | (even if it only runs server-side for now, until I whip streflop into shape) |
| 04:57.09 | trepan | delusional: http://trepan.bzflag.bz/noshow/bzworld.lua -- also have a parser written in lua that'll handle the bzw format |
| 04:58.07 | TD-Linux | imagines trepan opening his cloak to reveal a series of 5.25" floppies |
| 04:58.43 | trepan | upgraded, USB sticks |
| 04:59.20 | blast007 | "flash" drives |
| 04:59.29 | delusional | heheh |
| 04:59.42 | BulletCatcher | ~hide blast007 |
| 04:59.42 | ibot | ACTION gets a huge black sheet and covers blast007 with it so that nobody can see what blast007 is doing! |
| 04:59.46 | delusional | calls the cops |
| 05:00.06 | blast007 | ~bzfrag BulletCatcher |
| 05:00.06 | ibot | ACTION fries BulletCatcher with a laser |
| 05:07.16 | CIA-5 | BZFlag: 03blast007 * r21951 10/trunk/bzflag/src/bzfs/commands.cxx: No need to loop through the players if we can only display ourself. |
| 05:08.52 | delusional | trepan... glitter 2.5? ..... lua sure has brevity. |
| 05:09.21 | trepan | it's a "specialbox", of course it glitters |
| 05:09.34 | delusional | if you say so. |
| 05:09.55 | trepan | exactly |
| 05:10.02 | TD-Linux | only in the sun |
| 05:10.02 | bryjen | as long as it's not a lockbox |
| 05:11.15 | *** join/#bzflag Foo_man_choo (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 05:11.42 | trepan | one big advantage to a scripted world is that you can setup parametric objects |
| 05:13.07 | *** join/#bzflag kierra1 (~jolie@c-98-230-46-23.hsd1.fl.comcast.net) |
| 05:14.16 | TD-Linux | btw, blender 2.5 now has user properties on everything |
| 05:14.23 | BulletCatcher | Well, 2.3.14 does not fix the CTF bug. |
| 05:14.31 | BulletCatcher | Time to enable protocol logging. |
| 05:14.56 | TD-Linux | so it could make a nice map editor that supports all the special features in a straightforward way |
| 05:15.07 | TD-Linux | what would be the preferred way to integrate this into lua? |
| 05:15.21 | TD-Linux | generate lua script? or have lua script parse another kind of file? |
| 05:16.21 | blast007 | BulletCatcher: the flag cap oddness happens even after the latest code (and I definately can't repo it in 2.0.16) |
| 05:17.00 | BulletCatcher | We agree on the results (see my note from 2 minutes ago). |
| 05:17.28 | trepan | blender2.5 still have that nasty 21 character name limit? |
| 05:17.59 | blast007 | BulletCatcher: ah, yeah :) hehe |
| 05:22.21 | blast007 | BulletCatcher: around line 3623 in src/bzflag/playing.cxx is where bzflag tells the server it capped a flag |
| 05:22.54 | blast007 | I'm building a debug version of bzflag again and will test assuming I don't fall asleep in the meantime ;) |
| 05:25.07 | BulletCatcher | I'm still trying to find the protocol debug code in 2.3. Maybe it is only in 2.99. |
| 05:36.08 | TD-Linux | trepan, on objects? don't think so |
| 05:37.47 | TD-Linux | nvm it still does |
| 05:50.12 | BulletCatcher | Sigh. |
| 05:50.13 | BulletCatcher | Although the packet decoding I want is in src/game/MsgStrings.cxx, I can't find anything in the 2.3 network handling code that uses it. |
| 05:51.28 | BulletCatcher | In 2.99 it is controled by the debugNetMesg BZDB variable. |
| 06:19.39 | *** join/#bzflag pfa89 (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 06:23.22 | pfa89 | was bzrobots ever complete, and what is its current state? |
| 06:36.43 | CIA-5 | BZFlag: 0376.126.100.208 07http://my.bzflag.org * r7763 10/w/Category:Tactics: |
| 06:39.39 | blast007 | pfa89: there is one in 2.99.x, but it's not compatible with 2.0.x or 2.3.x/2.4.x |
| 06:39.50 | blast007 | not sure if it's "complete" |
| 06:40.28 | blast007 | pfa89: what is your intention? there's several types of bots in bzflag, and they all have somewhat different uses |
| 06:42.20 | pfa89 | interested in own AI bot |
| 06:43.00 | pfa89 | if you shoot at teleporter with phantom zone it comes right back at you |
| 06:52.03 | *** join/#bzflag Marzipan- (~Marzipan@p5B221E04.dip.t-dialin.net) |
| 06:53.24 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:00.04 | *** join/#bzflag pfa89_ (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 07:29.13 | BulletCatcher | When the buggy flag capture occurs, the client repeatedly sends MsgCaptureFlag (probably every frame) until it receives MsgFlagUpdate from the server. |
| 07:32.21 | BulletCatcher | After the server sends MsgFlagUpdate, it sends MsgGrabFlag for the flag on the base, then presumably processes at least one outstanding MsgCaptureFlag and confusedly scores it as a self-capture. |
| 07:32.51 | *** join/#bzflag pfa89 (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 08:04.31 | CIA-5 | BZFlag: 03bullet_catcher * r21952 10/trunk/bzflag/src/bzfs/ (FlagInfo.cxx FlagInfo.h bzfs.cxx bzfsAPI.cxx): Change FlagInfo::teamIndex() to return type TeamColor instead of int. |
| 08:13.19 | CIA-5 | BZFlag: 03bullet_catcher * r21953 10/trunk/bzflag/src/bzfs/bzfs.cxx: |
| 08:13.19 | CIA-5 | BZFlag: Log when player captures a flag they aren't carrying. |
| 08:13.19 | CIA-5 | BZFlag: Remove casts to TeamColor that are redundant after revision 21952. |
| 08:15.24 | CIA-5 | BZFlag: 03bullet_catcher * r21954 10/trunk/bzflag/src/game/MsgStrings.cxx: Add minimal support for MsgGameSettings, MsgNearFlag, MsgWantSettings, MsgLagPing, MsgPingCodeReply, and MsgPingCodeRequest. |
| 08:19.36 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:19.44 | BulletCatcher | I think r21953 hints at the solution to the flag capture bug, but testing it requires client and server at least 80 ms apart, and a server operator who will check the logs for the "claimed to capture" message. |
| 08:20.10 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 09:54.39 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 09:55.49 | Pimpinella | BulletCatcher: there is some cheat detection code in captureFlag(...) that should log "Player $PLAYER might have sent MsgCaptureFlag for taking their own flag" if it's the way you suggest |
| 09:56.27 | Pimpinella | a return for tat case is commented out |
| 11:05.42 | *** join/#bzflag moiree_ (~moiree@dslb-084-059-137-140.pools.arcor-ip.net) |
| 11:08.53 | Constitution | so beta today? |
| 11:09.53 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 11:11.56 | ruskie | gah some routing is seriously busted somewhere... no matter what ISP I try here all connections to viper2 go through .nl :( |
| 11:12.51 | ruskie | hmm or not... will have to try this sometime |
| 11:15.39 | Constitution | nice work on the roadmap by jeff |
| 11:15.42 | Constitution | ~jeffm2501++ |
| 11:44.17 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 11:44.17 | *** mode/#bzflag [+v spldart] by ChanServ |
| 13:17.17 | blast007 | BulletCatcher: if MsgCaptureFlag, we should only need to send it once, right? |
| 14:15.40 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 14:19.27 | BulletCatcher | Yes, it might be enough for the client to explicitly drop the flag immediately after capture. |
| 14:19.28 | BulletCatcher | Flag updates already go via TCP so we don't need to worry about loss. |
| 14:20.37 | BulletCatcher | The server would still need to protect itself from naughty clients sending multiple MsgCaptureFlag. |
| 14:21.10 | blast007 | but that protection could be added later since it's server-side |
| 14:21.30 | blast007 | we just need to determine which side (client or server) had the regression |
| 14:21.48 | blast007 | in my test the client was trying to capture the flag for the other team three times |
| 14:22.28 | blast007 | but somehow ended up capture it's own |
| 14:22.32 | blast007 | capturing* |
| 14:23.53 | blast007 | I started with breakpoints, but that didn't work cuz it locked the client and then it didn't capture my own flag |
| 14:24.09 | blast007 | so I just had it dumping some output when it actually tried to cap a flag |
| 14:24.22 | *** join/#bzflag short_circuit (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 14:24.43 | blast007 | there's only one spot where we send MsgFlagCapture |
| 14:25.12 | BulletCatcher | Yup. A sendDropFlag() immediately after should help. |
| 14:27.24 | blast007 | I'd still be curious as to why it's happening |
| 14:27.44 | BulletCatcher | The server is definitely borked. |
| 14:28.19 | blast007 | did we change how captures worked? |
| 14:29.26 | BulletCatcher | I think we only intentionally changed flag grab/drop handling. |
| 14:30.02 | *** join/#bzflag JeffM (~JeffM@69.36.85.130) |
| 14:30.02 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 14:30.02 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 14:39.01 | *** join/#bzflag bier (~bier@p54A59C10.dip.t-dialin.net) |
| 14:40.15 | *** join/#bzflag bier_ (~bier@p54A59C10.dip.t-dialin.net) |
| 14:42.32 | blast007 | BulletCatcher: r21838 'Backport of tupones server side flag grab and flag ID stuff.' |
| 14:42.47 | blast007 | be interesting to see how caps work before and after that |
| 14:42.59 | mdskpr_ | blast007: i tested that |
| 14:43.08 | mdskpr_ | before the revision it worked |
| 14:43.12 | mdskpr_ | and after it worked |
| 14:43.16 | blast007 | ok |
| 14:43.46 | blast007 | mdskpr_: and you were able to duplicate the issue with the latest revision in the same environment? |
| 14:43.55 | BulletCatcher | I think there were a couple of flag related commits after r21838. |
| 14:44.05 | mdskpr_ | yes |
| 14:44.59 | blast007 | maybe I'll hop through revisions in a bit and see if I can track down when this regression occured |
| 14:47.11 | BulletCatcher | I expect multiple MsgCaptureFlag when the client is laggy even when the base has no team flag on it. |
| 14:51.07 | CIA-5 | BZFlag: 03bullet_catcher * r21955 10/trunk/bzflag/src/ (bzflag/ServerLink.cxx game/NetHandler.cxx): |
| 14:51.07 | CIA-5 | BZFlag: Add commented-out rudimentary network protocol debugging. |
| 14:51.07 | CIA-5 | BZFlag: Search for "MsgStrings" to find the pieces to uncomment. |
| 15:03.22 | *** join/#bzflag QuantumWork (~QuaWo@d3-4-1-0.r00.dllstx04.us.ce.gin.ntt.net) |
| 15:07.00 | mdskpr_ | blast007: r21928 could have effected flag capture |
| 15:12.39 | mdskpr_ | blast007: it worked fine on r21927 |
| 15:13.15 | BulletCatcher | Sending MsgDropFlag immediately after MsgCaptureFlag seems to stop the self-capture, but also prevents picking up the flag on base. |
| 15:13.55 | BulletCatcher | I think we'll have to change the server to eradicate this bug. |
| 15:32.12 | *** join/#bzflag Upsetter (~er@i59F6BEA6.versanet.de) |
| 15:34.05 | CIA-5 | BZFlag: 03bullet_catcher * r21956 10/trunk/bzflag/src/bzflag/playing.cxx: Immediately forget about possession of the flag a player just captured to prevent sending subsequent MsgCaptureFlag messages. |
| 15:34.35 | BulletCatcher | That fixes the client for me. |
| 15:35.08 | BulletCatcher | If others can confirm then I think we are ready to release the beta. |
| 15:36.25 | BulletCatcher | We just need to fix the server too before the final release. |
| 15:37.47 | mdskpr_ | it was fixed after 21955 |
| 15:39.11 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:39.11 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:53.46 | TD-Linux | whoa gnome 3 is really nice |
| 16:23.28 | BulletCatcher | What I have learned from the "claimed to capture" message added in r21953 is that the server does not reliably keep track of which flag is carried by each player. |
| 16:24.34 | JeffM | see how limited we are in what we can do with out a good server state :) |
| 16:24.49 | BulletCatcher | Yeah. |
| 16:24.50 | BulletCatcher | I think doing that will be the key to better behavior in the face of multiple MsgCaptureFlag messages. |
| 16:25.19 | JeffM | that's the key do doing better at lots of things |
| 16:27.37 | BulletCatcher | The server seems to maintain flag carrying state somewhat, now. |
| 16:27.39 | BulletCatcher | We just need to make it obsessive about it. |
| 16:28.29 | JeffM | yep no point in a halfassed state |
| 16:37.52 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:43.14 | JeffM | did TimRiker ever respond about debian packages? |
| 16:44.34 | Thumper_ | not that I know of |
| 16:46.37 | JeffM | le sigh |
| 16:54.41 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 16:54.41 | *** mode/#bzflag [+v trepan] by ChanServ |
| 16:54.47 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 17:02.38 | BulletCatcher | I am +1 on releasing the beta today, but I am leaving for work soon and won't be around to help. |
| 17:02.56 | JeffM | I won't be able to build a bin till tonight |
| 17:03.10 | JeffM | but sure lets go for it |
| 17:03.29 | JeffM | someone want to build a source package and see if they can build from it afterwards? |
| 17:03.48 | JeffM | just to make sure we ain't missin nothin |
| 17:04.01 | BulletCatcher | Done that. I found no problems. |
| 17:04.16 | JeffM | k |
| 17:04.32 | JeffM | k, where do we want to keep the betas? |
| 17:04.39 | JeffM | we can use my machine if we want |
| 17:05.31 | BulletCatcher | I can't think of a reason not to use SF. |
| 17:05.36 | JeffM | oh I can |
| 17:05.42 | JeffM | cus you can NEVER delete them |
| 17:05.49 | JeffM | and we want to update them like crazy |
| 17:05.57 | JeffM | we have never posted betas to SF |
| 17:06.29 | BulletCatcher | k |
| 17:06.32 | JeffM | We just ned a webdir somewhere to link to |
| 17:06.44 | JeffM | also dosn't clutter up the release system in SF with versions |
| 17:07.03 | JeffM | if we posted a newer verison to SF now it would try to push it out to new players cus it'd be"newer" |
| 17:07.06 | BulletCatcher | I didn't realize we couldn't delete files from SF. |
| 17:07.23 | JeffM | you can hide them but stuff stays in history forever |
| 17:07.32 | JeffM | they don't want to "Loose" anything |
| 17:07.45 | JeffM | the release system is more then just a folder with stuff in it |
| 17:08.04 | JeffM | they do browers OS detection and try to give users the package they think is right on a "download" button |
| 17:08.51 | BulletCatcher | I don't have a problem with the beta(s) being preserved forever, but we don't want to have them automatically selected for downloads. |
| 17:09.04 | DTRemenak | that's easy to avoid, just by using a different package name |
| 17:09.25 | JeffM | what do we get by using SF? |
| 17:09.41 | JeffM | slower downloads? :) |
| 17:09.51 | DTRemenak | essentially nothing |
| 17:09.55 | JeffM | yeah |
| 17:09.57 | BulletCatcher | Familiarity. |
| 17:10.08 | JeffM | you can't upload to a folder? |
| 17:10.14 | JeffM | it's just going to be a link in the forums |
| 17:10.22 | JeffM | we are not promoting the beta anywhere else |
| 17:10.24 | DTRemenak | betas don't need really wide distribution anyway |
| 17:10.38 | JeffM | people may think it's just a buggy release |
| 17:11.04 | JeffM | we used to just use a folder on .bz |
| 17:11.37 | JeffM | but it kinda sucks now |
| 17:15.13 | *** join/#bzflag Guest240 (530f27ea@gateway/web/freenode/ip.83.15.39.234) |
| 17:23.45 | JeffM | TimRiker, can you point beta.bzflag.org to opencombat.net ( sent you an email too) |
| 17:46.12 | joevano | JeffM: you in Idaho? |
| 17:47.29 | JeffM | not anymore |
| 17:47.30 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
| 17:47.44 | JeffM | drove there friday drove back last night |
| 17:48.00 | JeffM | anyone want a job in sunny california? |
| 17:48.42 | joevano | only if it is in the San Diego area and it involves sitting on the beach |
| 17:48.49 | JeffM | sadly no |
| 17:49.14 | JeffM | writing things that output text files and tweaking windows DLLs |
| 17:50.26 | JeffM | so far the last empoliee we got from this channel has worked out ;) |
| 17:53.58 | Pimpinella | blast007, BulletCatcher: i didn't read the whole backlog, but i'm not sure letting the client drop the flag would be a good idea |
| 17:54.27 | blast007 | why? |
| 17:54.44 | Pimpinella | 1. the server tries to zap it. That might provoke other problems |
| 17:56.16 | Pimpinella | 2. does that fix the problem that the server gives the client it's own teamflag, so we're probably still not safe |
| 17:56.39 | Pimpinella | does that fix,,, meant as a question |
| 17:56.45 | Pimpinella | forgit ? |
| 17:56.49 | Pimpinella | forgot |
| 17:57.52 | Pimpinella | blast007: does the team that's flag should be captured die too? |
| 17:59.10 | blast007 | Pimpinella: on 2.0.x, if you have a team flag and jump on your base (and land on your own team flag) it captures the opposing team's flag, and grabs your own |
| 17:59.20 | blast007 | 2.3.x does the same, but it also captures your own flag on your own base |
| 17:59.40 | Pimpinella | but the "right" team dies too? |
| 17:59.49 | blast007 | afaik |
| 18:00.13 | Pimpinella | then just make a sanity check server side |
| 18:00.48 | Pimpinella | it's already there, everything needed is probably uncommentig a return |
| 18:01.09 | Pimpinella | in captureFlag(..) |
| 18:02.59 | Pimpinella | line 3213 bzfs.cxx |
| 18:04.27 | blast007 | the server doesn't have enough state, afaik |
| 18:04.50 | blast007 | the capture message just says which team is being captured against, not which base |
| 18:05.21 | Pimpinella | but you can check if the player is on his own base |
| 18:05.44 | blast007 | sorta |
| 18:05.57 | blast007 | we can't accurately check that because the server-side state is not accurate |
| 18:06.13 | blast007 | that's why it's only a debug message right now |
| 18:07.38 | Pimpinella | another way, just make sure that the client will send only one MsgCaptureFlag within, lets say, 1 second |
| 18:10.40 | blast007 | or if we want to tweak the MsgFlagCapture message, add the base ID to the message |
| 18:11.00 | blast007 | then it could just be a "I took X's flag on base Y" message |
| 18:14.03 | Pimpinella | sure, if we can still break protocol, that'd be the "clean" slution |
| 18:15.23 | Pimpinella | but still, there should be just a single MsgCaptureFlag via TCP |
| 18:15.40 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 18:15.40 | *** mode/#bzflag [+v trepan] by ChanServ |
| 18:18.24 | Pimpinella | alternativly fire out a player update right before MsgCaptureFlag to ensure we have an accurate state. |
| 18:18.59 | Pimpinella | of course the player update could still arrive after the capture |
| 18:19.21 | Pimpinella | hmm |
| 18:19.25 | blast007 | and the player update could never arrive at all, since it's UDP |
| 18:19.36 | Pimpinella | true |
| 18:19.37 | blast007 | so that only does so much |
| 18:20.00 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 18:23.44 | Pimpinella | one more: just don't allow a player to capture more than one flag within $SECONDS seconds |
| 18:23.46 | *** join/#bzflag Calzaath (b8091530@gateway/web/freenode/ip.184.9.21.48) |
| 18:24.35 | Calzaath | can anyone put up a link on how to make a texture move? |
| 18:25.10 | trepan | wiki / textureMatrix |
| 18:28.51 | Pimpinella | but if the flag is just dropped after a capture the flag drop might arrive before the capture and that WILL cause other problems |
| 18:31.07 | *** join/#bzflag tupone (~tupone@host185-218-dynamic.43-79-r.retail.telecomitalia.it) |
| 18:31.07 | *** join/#bzflag tupone (~tupone@gentoo/developer/tupone) |
| 18:31.07 | *** mode/#bzflag [+v tupone] by ChanServ |
| 18:32.20 | blast007 | both of those messages are TCP though - so the order should always be correct |
| 18:32.51 | trepan | you could pump out a TCP MsgPlayerUpdate[Small] |
| 18:33.11 | blast007 | true |
| 18:33.54 | Calzaath | thanks |
| 18:46.53 | blast007 | I'm gonna see if I can determine when this regression started |
| 19:07.05 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 19:07.05 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 19:26.21 | *** part/#bzflag Upsetter (~er@i59F6BEA6.versanet.de) |
| 19:30.26 | TimRiker | ~nslookup beta.bzflag.org |
| 19:41.33 | JeffM | thank you TimRiker :) |
| 20:09.05 | JeffM | blast007, what do you think about making a sub forum under the bugs forum for reporting beta bugs? |
| 20:09.12 | JeffM | well for players to report bugs? |
| 20:09.23 | blast007 | I think that'd be overkill |
| 20:09.27 | JeffM | k |
| 20:09.36 | blast007 | not like the regular one gets used that much |
| 20:09.37 | JeffM | where do we want them to report them |
| 20:09.40 | JeffM | yeah |
| 20:09.44 | JeffM | just in that forum? |
| 20:09.45 | blast007 | they could just report them there |
| 20:18.11 | KTL | http://images.planet-mofo.com/donf/ranking.xhtml <- modified the visualization a bit, to spread out the players a bit more, pushing them a bit away from the median. |
| 20:23.35 | blast007 | BulletCatcher: well, I've not been able to duplicate the flag cap issue in r21750 |
| 20:23.41 | *** part/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 20:23.43 | blast007 | gonna keep jumping to newer revisions |
| 20:53.07 | blast007 | happens at 21850 though. Player blast2 [1] might have sent MsgCaptureFlag for taking their own flag onto their own base |
| 21:24.15 | blast007 | okay, it likely is r21838 that caused the flag cap issue |
| 21:24.44 | blast007 | at 21835 it works and at 21840 I get the self-cap |
| 21:40.35 | mdskpr_ | blast007: why is playing.cxx:3642 calling serverLink's sendplayerupdate, shouldn't it be calling bzfs's sendplayerupdate? |
| 21:41.33 | *** join/#bzflag JeffM_ (~JeffM@69.36.85.130) |
| 21:41.36 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 21:41.36 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 21:41.40 | *** join/#bzflag QWork (~QuaWo@d3-4-1-0.r00.dllstx04.us.ce.gin.ntt.net) |
| 21:41.48 | blast007 | mdskpr_: that is client code, so why would it be calling a bzfs function? |
| 21:43.48 | *** join/#bzflag Quolz (~Quol@69.90.0.146) |
| 21:45.21 | mdskpr_ | blast007: oops, right |
| 21:46.02 | blast007 | ;) |
| 21:49.03 | *** join/#bzflag deluional_ (~delusiona@pool-98-111-215-149.pitbpa.fios.verizon.net) |
| 21:49.04 | *** join/#bzflag deluional_ (~delusiona@unaffiliated/delusional) |
| 21:56.48 | *** join/#bzflag KTL (~KTL@85.234.201.192) |
| 21:57.02 | *** join/#bzflag bier (~bier@p54A59C10.dip.t-dialin.net) |
| 21:57.29 | *** join/#bzflag dcat (~dcat@c-98-249-63-154.hsd1.va.comcast.net) |
| 21:57.46 | *** join/#bzflag short_circuit (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 22:03.18 | *** join/#bzflag Anxuiz (~Anxuiz@c-76-22-102-23.hsd1.wa.comcast.net) |
| 22:03.18 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 22:07.37 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 22:07.37 | *** join/#bzflag Cobra_Fast (~coprah@2a01:4f8:7d:200:0:4e2f:b550:1) |
| 22:07.37 | *** join/#bzflag Nitroxis (~nitroxis@2a01:4f8:7d:200:0:4e2f:b550:3) |
| 22:07.40 | blast007 | anyone against me reverting the server-side flag grab? (gonna do a bit of tweaking to get rid of that but keep the server-side ID, if that's acceptable) |
| 22:08.28 | JeffM_ | thems the rules |
| 22:08.37 | JeffM_ | 2.99 had the same problem? |
| 22:08.42 | blast007 | it could have |
| 22:08.46 | JeffM_ | k' |
| 22:08.55 | JeffM_ | I think we'll find a lot of that as we go thru the code |
| 22:09.03 | JeffM_ | stuff in 2.99 dosn't always do what we thought it did |
| 22:09.10 | blast007 | I seemed to have recalled that issue from somewhere - so it might have been from much earlier versions of 2.99.x or even 2.1.x, and not 2.0.x like I had thought |
| 22:09.31 | blast007 | I might have lost track in the 5+ years ;) |
| 22:09.55 | JeffM_ | ya think :) |
| 22:10.39 | JeffM_ | this is kinda why I like the backport method we are doing now, we are getting much better testing of each feature as we move it back |
| 22:11.09 | blast007 | just imagine if we had a plan before ;) |
| 22:11.50 | blast007 | 2.99.x would have just been 2.1 and been released |
| 22:12.08 | JeffM_ | indeed |
| 22:12.13 | JeffM_ | we would have had smaller goals |
| 22:18.25 | Pimpi | blast007, why do you want to revert serverside flag grep? |
| 22:18.44 | blast007 | because it is causing the self-cap bug |
| 22:19.05 | JeffM_ | heh flag grep, when you have too many flags |
| 22:19.17 | blast007 | hehe |
| 22:19.55 | Pimpi | blast007, sos did you try to fix the bug? |
| 22:20.04 | Pimpi | s/sos/so/ |
| 22:20.08 | blast007 | nope |
| 22:20.08 | JeffM_ | they have been at it all day\ |
| 22:20.21 | blast007 | I mean, we tried to work around it by doing other stuff |
| 22:20.28 | JeffM_ | if pimi can fix it in a day or so we can give him that time |
| 22:20.31 | blast007 | k |
| 22:20.36 | JeffM_ | I'd like to keep it if we can |
| 22:20.46 | JeffM_ | I mean we should try to fix em, but if we can't then we pull em |
| 22:20.47 | blast007 | I'll go ahead and get the change ready and tested to ensure it works without that |
| 22:20.51 | JeffM_ | ok |
| 22:21.09 | JeffM_ | we just don't want to stall the release because of a problem |
| 22:21.22 | blast007 | yeah, and it's a bit late in the process at this point |
| 22:21.22 | JeffM_ | but if someone is willing to poke at it for a bit then that's a good thing |
| 22:21.32 | JeffM_ | well there will be bugs |
| 22:21.35 | blast007 | yeah |
| 22:21.37 | JeffM_ | beta dosn't mean bug free |
| 22:21.40 | JeffM_ | just feature complete |
| 22:21.42 | JeffM_ | this is a bug |
| 22:21.53 | JeffM_ | we will be fixing bugs over the next week or so |
| 22:22.16 | blast007 | but if a new feature is causing a regression at this point, it either gets fixed very quicky, or pulled |
| 22:22.17 | JeffM_ | so a few days to ether fix or undestand why we have to revert is fine |
| 22:22.23 | JeffM_ | yes |
| 22:22.29 | JeffM_ | but quickly is days not hours :) |
| 22:22.33 | JeffM_ | we just need to watch it |
| 22:22.48 | JeffM_ | if we have no new info on like wednesday then we look into pulling it |
| 22:23.05 | Pimpi | well, it's a nice feature. BulletCatcher and blast worked it out and based on that i suggested a bunch of possible fixes |
| 22:23.07 | blast007 | I think that's the biggest (only?) issue we noticed thus far, but we'll see once more people are banging on it |
| 22:23.14 | JeffM_ | yeah |
| 22:23.20 | blast007 | Pimpi: you suggested some additional workarounds |
| 22:23.21 | blast007 | not fixes |
| 22:23.22 | JeffM_ | we'll still post some bins tonight and note up known issues |
| 22:23.50 | JeffM_ | and it sounds like some people are willing to look at the issue so we'll give em a chance |
| 22:24.01 | Pimpi | i don't think hey were all just workarounds |
| 22:24.12 | JeffM_ | the revert is pretty easy so we can do that for a beta update |
| 22:24.25 | blast007 | well, sorta easy |
| 22:24.31 | blast007 | it's mixed with the server-side flag ID |
| 22:24.48 | JeffM_ | pimpi can you work with blast and see what you can figure out by wednesday? |
| 22:24.50 | blast007 | though it's not a huge amount of changes, so it shouldn't be too bad |
| 22:25.24 | JeffM_ | not nessisarly a fix by wednesday just info on what is busted, why, and if there is a fix |
| 22:25.34 | JeffM_ | then we can make an informed choice |
| 22:25.43 | blast007 | I'll be gone by wednesday afternoon |
| 22:25.47 | JeffM_ | ok |
| 22:26.02 | blast007 | won't be back until saturday or sunday |
| 22:26.20 | JeffM_ | submit your patch for rollack of just the cap stuff and we can have it on hand |
| 22:26.24 | blast007 | yeah |
| 22:26.32 | JeffM_ | and don't drive to idaho |
| 22:27.09 | Pimpi | yep, i can provide that until wednesday |
| 22:27.22 | JeffM_ | until or by? :) |
| 22:27.33 | blast007 | if I drive to idaho, I've gone way too far and the wrong direction ;) |
| 22:27.41 | JeffM_ | exactly |
| 22:27.54 | JeffM_ | utah was wierd |
| 22:27.55 | Pimpi | hmm, by meand on wednesday? |
| 22:28.00 | Pimpi | means |
| 22:28.12 | JeffM_ | somewhere around wed |
| 22:28.17 | Pimpi | yep |
| 22:28.18 | JeffM_ | if it was even thu morning i'd be fine |
| 22:28.26 | JeffM_ | just so we have some kind of timeline |
| 22:28.27 | JeffM_ | cool |
| 22:28.55 | JeffM_ | if we don't make the first I won't cry, as long as we have clear goals and know what is happening |
| 22:29.08 | JeffM_ | if we pull too much stuff then the release is silly |
| 22:29.36 | blast007 | this feature seems rather minor though if we have to pull it |
| 22:29.43 | JeffM_ | origonaly we had 1 month for bug fixing, I lowerd it to 2 weeks |
| 22:29.45 | JeffM_ | true |
| 22:29.50 | JeffM_ | but it would be nice to have for a lot cheats |
| 22:29.56 | JeffM_ | so it's worth a couple days of eval |
| 22:29.58 | Pimpi | it's clearly a step in the right direction |
| 22:30.01 | JeffM_ | yeah |
| 22:30.23 | JeffM_ | just so long as we don't forget that we will pull it if it stays this way |
| 22:30.31 | Pimpi | sure |
| 22:30.47 | JeffM_ | horay for planing |
| 22:30.54 | JeffM_ | planing is cool |
| 22:30.56 | blast007 | Pimpi: the client has a lastGrabSent timer - so maybe that just needs to be duplicated to the server |
| 22:31.02 | JeffM_ | like bow ties and fezs |
| 22:32.10 | bryjen | don't you love it when a plan comes together? |
| 22:32.28 | blast007 | think the client (before your change) only tried to grab a flag 0.2 seconds after the last grab (or drop?) |
| 22:32.30 | Pimpi | blast007, or we use that timer to prevent the client to send additional grab messenges |
| 22:32.45 | blast007 | that's the point though, the issue is NOT with the client |
| 22:32.47 | JeffM_ | bryjen, it hasn't come together yet, but it's really close |
| 22:32.47 | blast007 | the server is at fault now |
| 22:33.13 | blast007 | because the server handles grabbing flags based on the player's position updates, it is grabbing too fast |
| 22:33.32 | blast007 | so it's probably screwing up the (limited) state we have in bzfs |
| 22:34.15 | Pimpi | may i break protocol? |
| 22:34.29 | blast007 | what change do you have in mind? |
| 22:34.30 | JeffM_ | sure |
| 22:34.43 | JeffM_ | it's not set in stone untill 2.4.0 |
| 22:34.56 | Pimpi | on of what i described earlier, not sure which yet |
| 22:35.20 | JeffM_ | in fact it's kinda good to break proto in beta just to get people to get newer beta versions |
| 22:35.58 | Pimpi | however sending MsgPlayerUpdateSmall via TCP just before MsgCaptureFlag might be the best idea |
| 22:36.25 | Pimpi | or adding more information to MsgCaptureFlag |
| 22:36.28 | JeffM_ | you can pack a player update in the capture message if you want as well |
| 22:36.31 | JeffM_ | that'd be better |
| 22:36.38 | JeffM_ | just pack it in |
| 22:36.46 | blast007 | that's not the problem |
| 22:37.04 | blast007 | the server knows where the tank is |
| 22:37.10 | blast007 | it's just grabbing the flag too fast |
| 22:37.22 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 22:38.31 | Erroneous | what does "too fast" mean? |
| 22:38.42 | blast007 | as in, immediately |
| 22:38.47 | Erroneous | why is that too fast? |
| 22:38.56 | Erroneous | if you are at that location, that seems like a good time to grab it |
| 22:38.58 | blast007 | it's faster than it used to be |
| 22:39.01 | Erroneous | so? |
| 22:39.57 | blast007 | Erroneous: if you can find out why you can capture a purple flag on a purple base by landing on the purple flag while holding another team's flag, feel free to fix it ;) |
| 22:40.24 | Erroneous | yeah: identify the problem first. the real problem. not the symptom. THEN try to fix it. |
| 22:40.25 | Pimpi | i know why that can happen |
| 22:40.26 | blast007 | s/purple/your own/ |
| 22:40.32 | bryjen | does the cap message not say which flag you capped? ie, the server decides you've picked up your flag before it gets the cap message for the other flag and so... |
| 22:40.38 | blast007 | it does not say |
| 22:40.40 | Pimpi | no |
| 22:40.42 | blast007 | it just passes a team color |
| 22:40.59 | Pimpi | it says which player captured |
| 22:41.14 | Pimpi | the server takesthe flag the player holds. |
| 22:41.25 | Erroneous | cap is server side, right? |
| 22:41.31 | blast007 | no |
| 22:41.37 | Erroneous | then that needs to be fixed |
| 22:41.43 | Pimpi | now the client sends more than just one MsgCaptureFlag |
| 22:41.55 | blast007 | I think it's far too late to do server-side caps for 2.4 |
| 22:42.47 | Pimpi | the server processes the first, takes the flag from the player and (thats new) gives a new flag to the player |
| 22:43.20 | Pimpi | now more MsgCaptureFlags come in since the client didn't know it really capped |
| 22:43.48 | Erroneous | when it processes the first capture, it should send notice of that to the client immediately |
| 22:43.56 | Pimpi | and now that message is processed, but the player has his own teamflag now |
| 22:44.08 | blast007 | the client only says that it has captured "the flag" on which team's base. so the only thing sent is the team of the base the player is on. |
| 22:44.09 | Erroneous | client should see capture before grab |
| 22:44.14 | blast007 | so that's likely the issue |
| 22:44.24 | Erroneous | and not send another capture |
| 22:45.01 | blast007 | Erroneous: the client repeatedly sends the flag grab (at least, before the latest revision - that now sets the local flag to Flags::NullFlag) |
| 22:45.11 | *** part/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 22:45.17 | Pimpi | Erroneous, IMHO the client just shouldn't send more than just one MsgCaptureFlag |
| 22:45.19 | Erroneous | blast007: client should not be doing flag grabs |
| 22:45.22 | Pimpi | but it does |
| 22:45.23 | blast007 | so basically the client says "I capped!" "I capped!" "I capped!" |
| 22:45.36 | bryjen | that's what i was getting at, the client shouldn't say "I think I captured *A* flag", it should say "I think I captured flag #X" |
| 22:45.47 | blast007 | and the server, in the mean time, gets the first one, gives them another flag, then gets the next "I capped!" and caps their own flag |
| 22:45.53 | Erroneous | bryjen: the client shouldn't say that at all :) but that's beside the point |
| 22:46.01 | bryjen | Erroneous: :P |
| 22:47.01 | bryjen | foods |
| 22:47.06 | blast007 | so at this point, one possible fix would be to send the flag ID (or flag team) along with the MsgCaptureFlag to the server (as bryjen mentioned) |
| 22:47.25 | Pimpi | yep |
| 22:48.08 | blast007 | and there should probably be some boolean flag we set when we have sent the capture that gets cleared when we drop flags |
| 22:48.35 | blast007 | then we'd only send one capture message (and is a bit cleaner than just setting the local flag to noflag) |
| 22:51.32 | Pimpi | so thats the way to go. make the client send only one capture message (that should fix the bug alone) and change MsgCaptureFlag to what it should be to make things generally more consistent |
| 22:52.24 | Pimpi | unless it's comething completely different ;) |
| 22:53.03 | blast007 | also, sendGrabFlag in ServerLink can probably go bye bye, since we don't use that :) |
| 22:55.10 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 22:56.59 | blast007 | is there a way to access the ID number of a flag? |
| 22:57.54 | Pimpi | <PROTECTED> |
| 22:58.54 | blast007 | the flag type is, not a numerical index |
| 22:59.24 | blast007 | so I guess type is the best we'll get (which should be fine) |
| 22:59.25 | Pimpi | hmm, server side there is |
| 23:00.07 | blast007 | you sure? |
| 23:00.07 | Pimpi | need to go to upstairs |
| 23:00.11 | Pimpi | yep |
| 23:00.17 | Pimpi | bb in a minute |
| 23:00.32 | JeffM_ | the answers are always upstairs |
| 23:06.16 | Pimpinella | hmm, yes |
| 23:06.34 | Pimpinella | LocalPlayer doesn't have flag ID |
| 23:07.00 | Pimpinella | Gamekeeper::Player has |
| 23:11.19 | blast007 | hmm, it's probably better (for now) to just make sure it only sends one capture message.. |
| 23:11.50 | blast007 | the server-side state could make sending the flag type in the capture message problematic, since we still check what flag the player is holding |
| 23:15.21 | Pimpinella | I'd only use that for a sanity check, anyway. If the flag type from the message doesn't match what the server believes the player should be holding, skip |
| 23:16.14 | JeffM_ | the player is always lying |
| 23:16.25 | Pimpinella | we'll can never really be sure about the state as lnone as it's not fully conreolled server side |
| 23:16.37 | Pimpinella | long |
| 23:16.42 | Pimpinella | nargh |
| 23:16.53 | Pimpinella | it's too late, gtg to bed |
| 23:16.59 | JeffM_ | worst chat key choice EVER :) |
| 23:20.01 | *** join/#bzflag KTL (~KTL@213.219.155.152.adsl.dyn.edpnet.net) |
| 23:20.15 | Pimpinella | TODO: let the player know about flag id not just type |
| 23:20.22 | Pimpinella | after release |
| 23:21.05 | JeffM_ | won't that break proto? |
| 23:21.30 | Pimpinella | not 100% sure, but i think we send the id |
| 23:21.36 | JeffM_ | ahh ok |
| 23:22.12 | JeffM_ | yeah the ID should be the primary reference to the flag object since it is unique |
| 23:28.05 | Pimpinella | yep, id is sent |
| 23:29.05 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 23:29.15 | Pimpinella | g'nite |
| 23:32.06 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 23:34.32 | randomparticle | for removing an item from an array, and closing the gap, should i consider memcpy'ing the upper portion down? |
| 23:34.59 | randomparticle | seems to me it might be a little faster than the naive approach |
| 23:36.04 | KTL | the way teams are chosen when a player logs in |
| 23:36.13 | KTL | is there any logic in that? |
| 23:36.20 | KTL | has it been modified in 2.4? |
| 23:36.56 | KTL | because i was thinking, for the servers i run, i could try to equal the balance between teams by using the data from the ranking |
| 23:43.44 | blast007 | what good will letting the player know the ID do, though? |
| 23:48.17 | JeffM_ | randomparticle, use a list |
| 23:48.21 | JeffM_ | if you do it a lot |
| 23:54.04 | JeffM_ | in place mem copy will possibly loose memory |
| 23:54.16 | JeffM_ | or just use a vector and let it pool it |
| 23:58.10 | blast007 | KTL: the -autoTeam option on bzfs forces players into certains teams when the join (the logic in bzfs just balances the numbers of players on each team, but you could modify it) |
| 23:58.19 | blast007 | I think even plugins can affect that |
| 23:58.30 | JeffM_ | yep |
| 23:58.36 | JeffM_ | GetTeamEvent |
| 23:59.09 | bryjen | the client should know not to say "I capped flag X" if X is its team flag on its own base, and/or the server can ignore such messages |
| 23:59.58 | blast007 | bz_eGetAutoTeamEvent |