| 00:04.20 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 00:07.48 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 00:16.03 | *** part/#bzflag keenerd (~kyle@67-23-13-172.static.slicehost.net) |
| 00:21.45 | CIA-5 | BZFlag: 0376.92.85.169 07http://wiki.bzflag.org * r7840 10/Releases: add last two releases |
| 00:31.45 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 00:31.45 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:40.58 | *** join/#bzflag Constitution (~const@bzflag/developer/Constitution) |
| 00:41.38 | *** join/#bzflag bier|tp (~bier@p54A5B5AF.dip.t-dialin.net) |
| 00:41.43 | *** join/#bzflag bier (~bier@p54A5B5AF.dip.t-dialin.net) |
| 02:16.40 | *** join/#bzflag KTL (~KTL@213.219.154.82.adsl.dyn.edpnet.net) |
| 02:28.01 | *** join/#bzflag swigg (~swigg@bzflag/player/Swigg) |
| 03:14.39 | *** part/#bzflag djlawler (~dlawler@static-173-59-115-18.phlapa.fios.verizon.net) |
| 03:29.08 | delusional | <PROTECTED> |
| 03:29.36 | delusional | somebody knows if per=face rico works. |
| 03:29.49 | *** join/#bzflag swigg (~swigg@71-85-132-27.dhcp.spbg.sc.charter.com) |
| 03:38.26 | ahs3- | delusional, yes works great |
| 03:39.01 | delusional | good news, all i need now is time to map |
| 03:39.07 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 03:39.07 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 03:39.56 | delusional | any specifics? or does it work exactly like i'd expect. |
| 03:41.24 | *** join/#bzflag swigg (~swigg@71-85-132-27.dhcp.spbg.sc.charter.com) |
| 03:45.24 | delusional | hmmm, rico, shootthrough, shots_die.... rico, shootthrough, shots_die.... rico, shootthrough, shots_die.... |
| 04:28.39 | *** join/#bzflag Constitution (~const@bzflag/developer/Constitution) |
| 05:04.24 | *** join/#bzflag Guest001 (ca59b013@gateway/web/freenode/ip.202.89.176.19) |
| 05:23.51 | *** join/#bzflag short_circuit (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 05:23.54 | *** join/#bzflag Djpenguin (~David@c-98-207-67-102.hsd1.ca.comcast.net) |
| 06:00.33 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 06:08.03 | *** join/#bzflag Marzipan- (~Marzipan@p5B222A6A.dip.t-dialin.net) |
| 06:08.48 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:24.52 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:33.49 | *** join/#bzflag AAA_awright (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 08:45.27 | *** part/#bzflag bryjen (~bryjen@76.92.85.169) |
| 09:37.01 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 11:28.50 | *** join/#bzflag nielsle_ (~nielsle@4135136-cl69.boa.fiberby.dk) |
| 11:36.15 | *** join/#bzflag nielsle (~nielsle@4135136-cl69.boa.fiberby.dk) |
| 11:42.50 | *** join/#bzflag nielsle (~nielsle@4135136-cl69.boa.fiberby.dk) |
| 11:46.55 | *** join/#bzflag nielsle (~nielsle@4135136-cl69.boa.fiberby.dk) |
| 11:49.36 | *** join/#bzflag nielsle (~nielsle@4135136-cl69.boa.fiberby.dk) |
| 11:50.18 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 13:10.33 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 13:24.10 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 13:41.34 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 13:41.34 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 13:42.10 | *** join/#bzflag spldart (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 13:42.10 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 13:42.10 | *** mode/#bzflag [+v spldart] by ChanServ |
| 13:55.41 | *** join/#bzflag meeba (~lamer@71.196.238.53) |
| 14:38.15 | *** join/#bzflag Upsetter (~er@i59F6C76F.versanet.de) |
| 15:05.17 | CIA-5 | BZFlag: 03bullet_catcher * r22070 10/trunk/bzflag/README.Linux: |
| 15:05.17 | CIA-5 | BZFlag: Remove info about 2.99 bzrobots. |
| 15:05.17 | CIA-5 | BZFlag: Update list of Fedora packages. |
| 15:05.17 | CIA-5 | BZFlag: Add "make distclean" recommendation. |
| 15:05.17 | CIA-5 | BZFlag: Fix grammar. |
| 15:07.07 | CIA-5 | BZFlag: 03bullet_catcher * r22071 10/trunk/bzflag/src/date/buildDate.cxx: Add bzls.lua to the list of files to be modified when BZ_PROTO_VERSION changes. |
| 15:09.00 | CIA-5 | BZFlag: 03bullet_catcher * r22072 10/trunk/bzflag/ChangeLog: Add entries for solo bot changes and thiefControl plugin. |
| 15:24.04 | *** join/#bzflag quantumdot (~jmlopez@bzflag/player/QuantumDot) |
| 15:33.29 | blast007 | note that I'll be putting in a better thiefControl plugin |
| 15:33.53 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 15:33.53 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 15:33.56 | blast007 | the one from trunk was better, and I had backported that to 2.0.x for my servers, and now I ported the 2.0.x one to 2.4 |
| 15:34.05 | blast007 | just need to test it |
| 15:34.31 | BulletCatcher | Just remember to update the ChangeLog when you commit it. :-) |
| 15:34.44 | blast007 | ;) |
| 16:00.47 | JeffM | so do we want another list of individual items with people for 2.4.2? cus we seem to be slacking on the development |
| 16:01.24 | joevano | sure... seems to work |
| 16:01.45 | JeffM | it does, but that means that we are moving to more of an assignment based development |
| 16:01.49 | JeffM | I don't mind it |
| 16:01.58 | JeffM | I just want to know if that is where we are going |
| 16:02.10 | JeffM | very different from what we did in the past |
| 16:02.34 | JeffM | and if it's going to be long term like that, is the wiki the best place to do that? |
| 16:03.02 | JeffM | or should we be using a bug tracker |
| 16:04.53 | JeffM | and that leads into the version controll question |
| 16:05.26 | JeffM | I would have less concern with using GIT if we are using a more managed devlopment approach, cus then there is someone to bug people for pushes |
| 16:08.08 | blast007 | seems like it would be complicated to migrate our project to a DVCS without losing some/lots of history |
| 16:08.19 | JeffM | yes that would suck |
| 16:08.30 | JeffM | does that mean we are stuck on SF forever? |
| 16:08.51 | blast007 | just means it's time to start from scratch! ;) |
| 16:09.13 | JeffM | could we move to google svn and keep history? |
| 16:09.13 | blast007 | yeah |
| 16:09.13 | blast007 | but then what does that gain us? |
| 16:09.13 | BulletCatcher | I think that means we haven't yet found a compelling reason to change. |
| 16:09.13 | JeffM | we all seem to have noting good to say about SF |
| 16:09.22 | JeffM | sf speed, sf downtime, etc.. |
| 16:09.39 | blast007 | I don't really like google code though :) |
| 16:09.39 | JeffM | or are we ok wiht it? |
| 16:09.44 | BulletCatcher | Google doesn't seem to be very fast, either. |
| 16:09.49 | JeffM | I can use the SF bug tools, they are meh but they work |
| 16:09.53 | JeffM | ok |
| 16:10.05 | blast007 | I tried both for my own project |
| 16:10.09 | blast007 | preferred SF |
| 16:10.14 | JeffM | ok |
| 16:10.17 | JeffM | I prefer google :) |
| 16:10.20 | JeffM | it's simpler |
| 16:10.22 | blast007 | though I use bitbucket for my source now |
| 16:10.24 | JeffM | but I can deal with both |
| 16:10.27 | JeffM | they do svn? |
| 16:10.31 | blast007 | mercurial |
| 16:10.45 | JeffM | well you said we can't move to that with out loss of history or lots of complications |
| 16:10.56 | blast007 | yeah, just saying what I'm doing for my own ;) |
| 16:11.06 | blast007 | using SF + that |
| 16:11.16 | blast007 | instead of google code + that (or google code alone) |
| 16:11.27 | JeffM | I'm just asking if the wiki/google doc thing was ok last time, or would doing it in SF bugs be better? |
| 16:11.33 | JeffM | or do we run our own bug tracking site? |
| 16:11.48 | blast007 | SF even has some other hosted apps we could run |
| 16:11.50 | JeffM | I was not totaly happy with the google doc |
| 16:12.00 | JeffM | what do they have? |
| 16:12.51 | JeffM | mostly I want a way to have a group of bugs/tasks in a group and sort them by developer |
| 16:13.02 | JeffM | so that I can build up a list for each release |
| 16:13.10 | JeffM | and see what is claimed |
| 16:13.15 | blast007 | in the past, SF had a timeline feature |
| 16:13.39 | blast007 | which we had populated a bit for our various release targets.. but never really stuck to ;) |
| 16:14.03 | blast007 | timeline or milestone |
| 16:14.21 | blast007 | they probably ditched that in favor of some 3rd party hosted apps |
| 16:14.38 | JeffM | I don't see anything like that on the bug tracker |
| 16:14.58 | JeffM | I can redo our groups and categories to make them be "function" and "release" and make it work |
| 16:15.23 | JeffM | but the bug list tracker is very flatfile |
| 16:16.21 | JeffM | ahh looks like we could turn on Trac |
| 16:16.26 | JeffM | under available features |
| 16:16.45 | JeffM | also something called "dotProject" |
| 16:17.21 | JeffM | I can look into those |
| 16:19.50 | BulletCatcher | I like our Development_RoadMap wiki page as the place for assignments. |
| 16:19.51 | BulletCatcher | It is easy to see the highlevel view of what is (or will be) going on, and the outline format allows addition of details as needed. |
| 16:20.14 | JeffM | yes, I want to keep the wiki page for roadmap |
| 16:20.27 | JeffM | I am talking about the 2.3 specific wiki and the google doc that went with it |
| 16:21.40 | JeffM | if we are going to make a more detailed thing for the current release we are working on ( 2.4.2 now) was that google doc/ wiki good enough? and if so how do we integrate bug reports from SF/forums into it? |
| 16:23.24 | JeffM | whoof... dotProject is way more then we need |
| 16:25.29 | JeffM | hmmm can't delete groups for bugs that have them... |
| 16:26.42 | blast007 | should it be a new tracker, not the bugs one? |
| 16:27.16 | JeffM | yeah that's what I'm thinking |
| 16:27.40 | JeffM | taking a quick look at trac |
| 16:29.07 | JeffM | proably better to have the place where the players submit bugs be different then the task list, then a real person can make the choice to have a developer evaluate them |
| 16:29.40 | blast007 | hmm. http://zero-install.sourceforge.net/ |
| 16:35.45 | JeffM | they talk about linux binary compatability being a key, sounds like it's more like "run linux apps on every system" not "run native apps with easy install" |
| 16:41.11 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 17:48.03 | joevano | nope just mercurial... but we do use most of the Atlassian software here at work and like it |
| 17:48.33 | joevano | darn scroll buffer |
| 17:52.28 | JeffM | blast007, it looks like Trac has the milestones and stuff |
| 17:54.36 | joevano | Atlassian does give away their software to open-source software projects, JIRA is pretty sweet |
| 17:54.55 | joevano | this is free for open-source communities : http://www.atlassian.com/hosted/studio/ |
| 17:55.29 | joevano | (and non-profits) which is why I like it ;-) |
| 17:58.13 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 17:58.13 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 18:46.46 | *** join/#bzflag DarkCalff (DC@173.231.40.98) |
| 18:54.29 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 18:54.40 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 19:35.02 | *** join/#bzflag ts (~ts@BZ.BZFLAG.BZ) |
| 20:41.33 | joevano | JeffM: you're my hero |
| 20:41.40 | JeffM | ? |
| 20:41.57 | joevano | Google+ invite worked ;-) |
| 20:42.01 | JeffM | nobody had sent you an invite yet? |
| 20:42.16 | joevano | oh sure... but they haven't worked |
| 20:42.34 | JeffM | all I did was drag you into a circle |
| 20:42.54 | JeffM | then click the big blue button that said "do you want to invite the people you added that arn't in google+?" |
| 20:57.23 | *** join/#bzflag swigg (~swigg@71-85-132-27.dhcp.spbg.sc.charter.com) |
| 21:22.51 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 21:26.09 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 21:26.09 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 21:31.32 | JeffM | so I never really saw a consensus on if we wanted to do the same kind of management that we did on 2.4 for the other releases |
| 21:31.42 | JeffM | are we all just "meh" about it all? |
| 21:32.14 | JeffM | Was development actualy reinvigorated or just shoved a little further down the road against its will? |
| 21:34.54 | Pimpinella | 2.4 was really pushed. let everyone a little time to regenerate, then make a plan like for 2.4 and a deadline |
| 21:37.48 | Pimpinella | or probably have a deadline until detailed release goals have to be made, then have a deadline to implement it |
| 21:39.30 | JeffM | oh I know, that's why I waited a few weeks just to ask what we want to do |
| 21:39.47 | JeffM | I think we'll need less hard dealines then 2.4 had |
| 21:39.59 | JeffM | but do we even want to do the "list of tasks" |
| 21:41.15 | BulletCatcher | The task list is useful to keep us focused, and also gives us a way to say "not yet" for some ideas. |
| 21:41.26 | JeffM | yes I think it helped a lot |
| 21:42.28 | JeffM | it was also nice to have the list for when new people came in and we could just ask them if they wanted an item off the list |
| 21:42.47 | JeffM | rather then "well look at this big list of bugs in 4 different places and see if you want to do anything" |
| 21:43.17 | BulletCatcher | Yup. A lot of the 2.4.0 items were backports that required relatively little new work. |
| 21:43.27 | BulletCatcher | I think we are past that, now. |
| 21:43.33 | JeffM | yes |
| 21:43.59 | JeffM | do do we want to go back to how it was and let development happen with whatever people want, maybe with a roadmap? |
| 21:44.26 | JeffM | or build up a list for the next release, let people claim them, then be able to judge the release on how that list is doing at various times. |
| 21:45.52 | BulletCatcher | I think it would be worthwhile to get all new ideas onto the roadmap to help ensure that dependencies will be properly met. |
| 21:46.10 | JeffM | sure |
| 21:46.20 | BulletCatcher | When someone starts working on an item they will "claim" it to avoid duplication of effort. |
| 21:46.31 | BulletCatcher | But we may need to set time limits. |
| 21:46.37 | JeffM | we may |
| 21:46.48 | JeffM | so sounds like you'd like some tracking of release progress |
| 21:46.55 | JeffM | is the wiki good enough for this? |
| 21:47.02 | BulletCatcher | I think it is. |
| 21:47.16 | JeffM | how about bug reports from users? put that in the wiki too? |
| 21:47.37 | JeffM | with links to SF/forum posts? |
| 21:48.30 | BulletCatcher | We could try that and see how well it works. My crystal ball is cloudy on which way it will go. |
| 21:49.08 | BulletCatcher | The advantage is there would be a single public place (the wiki) to find the current status and plans. |
| 21:49.13 | JeffM | ok, then I'll recomend a wiki page for the release we are working on that the roadmap links to, so the roadmap can be high level, and the detail page have more specifics. |
| 21:49.18 | JeffM | yes |
| 21:49.36 | BulletCatcher | A page per release sounds good. |
| 21:49.45 | JeffM | I'd also recomend taking all the bugs out of the bugs file in the source and put them in SF and link to them on the wiki |
| 21:51.08 | JeffM | can the wiki have an alias to something like Current_Dev_Bugs that always points to the page for the current release we are developing? |
| 21:51.33 | BulletCatcher | I feel like old entries in both SF and the BUGS both get ignored pretty well. |
| 21:51.41 | JeffM | they do |
| 21:51.52 | JeffM | I'm willing to go thru them all |
| 21:52.00 | JeffM | and weed out the ones that arn't valid anymore |
| 21:52.19 | BulletCatcher | That would help a lot. |
| 21:52.35 | JeffM | I've done it before, I can do it again :) |
| 21:53.01 | BulletCatcher | :-) |
| 21:53.02 | BulletCatcher | You are probably the best qualified to do that kind of triage. |
| 21:53.16 | JeffM | I don't know about that |
| 21:53.24 | JeffM | but probably the only one willing |
| 21:55.16 | BulletCatcher | You understand the codebase better than almost anyone. |
| 21:55.17 | BulletCatcher | If I were to do it there would be a bunch of bugs that would take me hours of research just to fully understand. |
| 21:56.51 | JeffM | do we want SF bug reports to show in CIA or in IRC in some way? |
| 21:56.57 | JeffM | like wiki edits do? |
| 21:57.23 | BulletCatcher | That would be great, if it isn't too much effort. |
| 21:57.40 | cygal_ | there's a LOT of bugs left, and triaging is often hard - if you are willing to playtest them all |
| 21:57.46 | JeffM | oh I have no idea if it is possible or not :) |
| 21:58.02 | JeffM | cygal_, initaly I want to just categorize them |
| 21:58.32 | JeffM | and if they are in code we know is broken and want to replace, etc.. |
| 21:58.46 | JeffM | we have lived with most of them for this long, they can't be that bad :) |
| 21:59.08 | CIA-5 | BZFlag: 03JeffM2501 07http://wiki.bzflag.org * r7841 10/DevelpmentPlans/2.4.2: Created page with "==Overview== 2.4.2 will be the first maintenance release of the 2.4.x compatibility line. Its primary function is to fix bugs found in the 2.4.0 release and to include non breaki..." |
| 21:59.28 | CIA-5 | BZFlag: 03JeffM2501 07http://wiki.bzflag.org * r0 10/DevelpmentPlans/2.4.2: |
| 21:59.47 | CIA-5 | BZFlag: 03JeffM2501 07http://wiki.bzflag.org * r7843 10/Development_RoadMap: add link to planing page for 2.4.2 |
| 22:00.24 | *** join/#bzflag Erroneous (~DTRemenak@75.16.90.217) |
| 22:00.24 | *** join/#bzflag Erroneous (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 22:00.24 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 22:01.16 | JeffM | did we decide if the ST bracket autopilot thing was really a bug or not? |
| 22:03.18 | BulletCatcher | I think you said it is a bug deep in game state, revealed by the brackets. |
| 22:03.51 | BulletCatcher | In other words, it may not be easy to fix. |
| 22:04.02 | JeffM | me? |
| 22:04.08 | JeffM | I have no idea what it is |
| 22:04.31 | JeffM | is it similar to the lockon thingy? |
| 22:04.36 | JeffM | cus I "fixed" that ;) |
| 22:04.40 | BulletCatcher | That's what I was thinking of. |
| 22:04.47 | BulletCatcher | You mean the autopilot thing in BUGS. |
| 22:04.50 | JeffM | I don't think that has anything to do with uatopilot |
| 22:04.52 | JeffM | yeah |
| 22:05.27 | BulletCatcher | I don't know whether anyone has reproduced it since 2.4.0 was released. |
| 22:05.56 | JeffM | then I'm tempted to remove it untill it's reported again |
| 22:06.09 | BulletCatcher | For now, I was thinking that we should keep it as an unconfirmed bug. |
| 22:09.39 | CIA-5 | BZFlag: 03JeffM2501 07http://wiki.bzflag.org * r7844 10/DevelopmentPlans/2.4.2: |
| 22:14.09 | swigg | As far as bugs go: What about the bullets ricocheting by themselves in thin air? |
| 22:14.42 | JeffM | was that ever reported anywhere? |
| 22:14.58 | swigg | No; I just recently noticed it |
| 22:15.09 | JeffM | then can you please report it on sourceforge? |
| 22:15.16 | JeffM | so it can be evaluated and tracked |
| 22:15.37 | swigg | It may have been linked to modded clients |
| 22:15.51 | swigg | I'll go report it; I have no idea as to how |
| 22:15.55 | JeffM | a moded client can't make your client do a rico |
| 22:16.01 | swigg | my thought too |
| 22:16.04 | JeffM | your client computes the path for any nonGM thought |
| 22:16.09 | JeffM | shot |
| 22:16.15 | swigg | but that was where I saw it; when someone was cheating |
| 22:16.38 | JeffM | it's possible they created a shot that looked like a rico, that is possible |
| 22:16.41 | swigg | the bullets rico in a tight area and then drift off while rich=ocheting |
| 22:16.44 | JeffM | and techincaly not a "bug" |
| 22:17.09 | JeffM | it's and undesired consiquence of the networking design |
| 22:17.42 | swigg | as many cheaters as I have caught, I've never seen this until the new version; It was in fact how I fingered the person |
| 22:18.09 | swigg | I'll get someone more qualified to detail it; Benfish has the actual server logs |
| 22:18.42 | swigg | Maybe he can pastebin it to whoever needs to see it? |
| 22:19.23 | swigg | oh, and sorry for the typo; I have a dell and a lenovo with different keyboard arrangements |
| 22:19.35 | JeffM | nothing in the log would help show anything |
| 22:19.38 | swigg | and I can't type on either very well |
| 22:19.54 | JeffM | we don't log network packets or simulation state |
| 22:20.05 | swigg | Ben said something about the shot definitions was different from anything he has seen before |
| 22:20.22 | JeffM | then he was probably creating shots |
| 22:20.26 | JeffM | it happens |
| 22:21.16 | JeffM | that's not something that can be fixed like a normal bug |
| 22:21.42 | swigg | It might have value for endshot credits |
| 22:22.58 | JeffM | that requires the entire simulation system to be rewriten |
| 22:23.16 | JeffM | enshot credits is a weak way of detecting the issue |
| 22:23.19 | JeffM | not a solution |
| 22:23.41 | swigg | Well, I don't see how thier client should influence how my client would interret and display shot behavior |
| 22:23.49 | swigg | *interpret |
| 22:24.01 | swigg | It's just a curiosity |
| 22:24.16 | JeffM | easy, they send an endshot, shot dies, they make a new one on the rico vector |
| 22:24.29 | JeffM | your client dosn't check when other people get hit |
| 22:24.35 | JeffM | so it accepts enshots |
| 22:25.05 | JeffM | as far as your client is concerned it did what it was told |
| 22:25.49 | swigg | Humor me for a sec: Why would this only be prevelant now and not in previous versions? |
| 22:25.58 | JeffM | it wasn't |
| 22:26.11 | JeffM | they are not linked |
| 22:26.26 | JeffM | ether you didn't see this trick before, or the cheater just decided to do it now that we had a new version |
| 22:26.43 | JeffM | we didn't change the shots at ALL in 2.4, they are bassicly the same as 2.0.x |
| 22:26.49 | JeffM | from a networking/simulation standpoint |
| 22:26.55 | swigg | other admins have seen this as well; Never before. I realize this is subjective analyis... |
| 22:27.15 | JeffM | yeah the release probalby got a cheater off his butt so he could cheat against new people ;) |
| 22:27.32 | JeffM | was probalby bored before this with the old release |
| 22:28.39 | JeffM | it is possible that it's a bug with the per face rico thing, but then it woudl have had to happen near some geometry and would happen for anyone. |
| 22:28.48 | swigg | Time will tell. This may be one of those things you need to see for youself; I'm probably not explaining it very well |
| 22:29.13 | JeffM | there are lots of things cheaters can do that look like bugs |
| 22:29.22 | JeffM | they bassicly have full controll of the gamestate |
| 22:29.30 | JeffM | they can spawn shots inside you |
| 22:29.37 | JeffM | boom.. you asplode |
| 22:29.46 | swigg | Oh sure; I do get that. It's just that it seems new but I digress. |
| 22:30.16 | JeffM | making the shot look like a rico may get them by a casual visual check for a bit |
| 22:30.20 | KTL | hehe new development effort -> new cheating effort :D |
| 22:30.28 | JeffM | they always go together |
| 22:30.41 | swigg | nYeah, it's thinking outside the box |
| 22:30.57 | JeffM | most of them are probalby laughing saying we are stupid for not fixing any of the things they exploit |
| 22:31.16 | swigg | heck, it might just make ideas for new flags or features |
| 22:34.29 | *** join/#bzflag BlasterWisconsin (~blasterwi@CPE-72-131-65-159.wi.res.rr.com) |
| 22:34.40 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
| 22:35.52 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 22:37.51 | blast007 | re: using the wiki to post bugs - I don't think that's really well suited to that task |
| 22:38.14 | JeffM | no it's not, I just want to reference existing bugs on the wiki, not use the wiki for reporting |
| 22:38.30 | blast007 | unless you just mean linking to the SF bug tracker items |
| 22:38.36 | JeffM | yes that's what I mean |
| 22:38.44 | JeffM | a URL link to a real bug |
| 22:39.12 | blast007 | k |
| 22:41.16 | blast007 | JeffM: and if ibot can monitor an RSS feed, we can get bug reports easily posted here |
| 22:41.26 | blast007 | or we could run another but, like a supybot |
| 22:41.29 | blast007 | bot* |
| 22:43.58 | JeffM | we can have SF send an email for every new bug |
| 22:44.28 | *** join/#bzflag spldart (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 22:44.28 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 22:44.28 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:44.52 | JeffM | ugg, SF dosn't let me group bugs by planed release |
| 22:44.57 | JeffM | wants a new tracker per |
| 22:44.59 | JeffM | oh well |
| 22:45.42 | blast007 | there's better options if we want :) |
| 22:45.48 | JeffM | yeah |
| 22:45.53 | JeffM | trac can probably do it |
| 22:45.54 | blast007 | a decent bug tracker should have a 'milestone' dropdown |
| 22:46.06 | JeffM | but I"ll just use the wiki for grouping |
| 22:46.09 | JeffM | for now |
| 22:46.11 | blast007 | k |
| 22:46.18 | JeffM | and we can look at better stuff later if this works |
| 22:47.25 | CIA-5 | BZFlag: 03JeffM2501 07http://wiki.bzflag.org * r0 10/BZFlag_2.3: |
| 22:51.20 | CIA-5 | BZFlag: 03bullet_catcher * r22073 10/trunk/bzflag/src/bzflag/playing.cxx: Establish network connections for solo bots only after it is known that the server will accept them. |
| 22:51.39 | BulletCatcher | That does remain compatible with 2.4.0, by the way. |
| 22:51.52 | JeffM | sure |
| 22:53.23 | BulletCatcher | Except for possible newly introduced bugs, that should complete the solo bot joining changes from blast007 and me. |
| 22:53.28 | BulletCatcher | It is much cleaner now. |
| 22:55.06 | BulletCatcher | A 2.4.1 client will not try to create bots when the server has -disableBots. |
| 22:55.30 | BulletCatcher | A 2.4.1 server will individually reject bots rather than kick the live player. |
| 23:01.44 | BulletCatcher | gcc won't let me overload these two methods: |
| 23:01.48 | BulletCatcher | std::string get() |
| 23:01.53 | BulletCatcher | std::vector<FlagType*> get() |
| 23:01.56 | BulletCatcher | Is that because overloaded methods must be distinguished by their parameters and not just their return values? |
| 23:02.02 | JeffM | yes |
| 23:02.17 | JeffM | C++ has an ambiguity in that case |
| 23:02.32 | JeffM | since you can call a function with a return value and not use |
| 23:02.38 | JeffM | then it won't know what one to call |
| 23:03.09 | BulletCatcher | Okay, so I'll just give them different names. |
| 23:10.27 | CIA-5 | BZFlag: 03bullet_catcher * r22074 10/trunk/bzflag/src/bzfs/ (FlagHistory.cxx FlagHistory.h bzfsAPI.cxx commands.cxx): |
| 23:10.27 | CIA-5 | BZFlag: Rename the two FlagHistory::get() methods to getStr() and getVec() to disambiguate their new usage. |
| 23:10.27 | CIA-5 | BZFlag: Have getStr() return std::string to avoid complicated and error-prone manipulation of char[] arrays. |
| 23:10.27 | CIA-5 | BZFlag: This fixes truncation of the flag history output lines. |
| 23:49.53 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |