| 00:09.20 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 00:11.27 | moiree | Where shall I send the patch? |
| 00:11.45 | JeffM | source forge please |
| 00:11.58 | moiree | k |
| 00:13.42 | trepan | DTRemenak: have you tried the typeof.h with boost for MSVC? (with tmp_test_foreach.cpp) |
| 00:14.57 | trepan | my current diff is up to 150K, waiting on that functionality :) |
| 00:15.27 | trepan | is trying to avoid the boom-shakalaka commits, seems to make others nervous |
| 00:15.30 | JeffM | he's not at his desk, he's on the otherside of the cube wall from me |
| 00:15.40 | trepan | heh, small world |
| 00:16.28 | trepan | one of these days, i'll stick windows in a VM and things will be easier |
| 00:17.46 | allejo | what os are you on trepan? |
| 00:18.07 | trepan | amd64/debian |
| 00:19.14 | allejo | ah. linux ftw. what do you need windows for? |
| 00:19.25 | trepan | testing code on MSVC |
| 00:19.33 | JeffM | creating a build system that works on it ;) |
| 00:19.45 | trepan | yup, that too |
| 00:19.48 | JeffM | and code |
| 00:20.21 | trepan | btw, with the 'foreign' crap that i've added to premake, it shouldn't be too hard with setup properly for MSVC |
| 00:20.39 | *** join/#bzflag tannerld (~tanner@lawn-128-61-125-55.lawn.gatech.edu) |
| 00:20.50 | trepan | (makes it so that you can use .sln files in premake projects) |
| 00:21.27 | trepan | (and autotools projects) |
| 00:27.11 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 00:27.13 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:33.53 | trepan | converted walls to mesh faces; now it's all meshes, all the time (well, WorldText as well, but I could just as easily slap text onto a face, using the first 3 vertices do define the plane) |
| 00:50.04 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 00:50.06 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 01:09.33 | TD-Linux | so, is 2.2 out yet? |
| 01:10.21 | TD-Linux | ... oh wow it's been a long time |
| 01:18.52 | BulletCatcher | 2.2 is long abandoned, but there is a fair chance that 2.4 will be released by the end of the month. |
| 01:25.21 | TD-Linux | why did you restart from 2.0? |
| 01:25.28 | TD-Linux | I don't remember that many bugs in 2.99 |
| 01:26.01 | mdskpr_ | http://my.bzflag.org/w/BZFlag_2.3 <----that should tell the story |
| 01:26.23 | TD-Linux | I read that and no it doesn't |
| 01:26.29 | TD-Linux | it looks like a big list of backports? |
| 01:26.51 | BulletCatcher | There were some critical bugs, particularly in the dead-reconing and font systems, that we just couldn't fix. |
| 01:30.37 | BulletCatcher | By setting a limited scope for 2.4 we have gotten developers interested in developing again, and so far it looks like we will actually be able to deliver a successful release. |
| 01:32.15 | TD-Linux | sounds like a good idea, mainly the release cycle thing |
| 01:33.31 | BulletCatcher | Yeah. Without any kind of plan we were never really motivated to stop doing new stuff and do the polishing necessary to do a release. |
| 01:33.45 | BulletCatcher | I think we have now learned our lesson about that. |
| 01:35.23 | TD-Linux | a lot of other projects are moving to timed release cycles I noticed |
| 01:35.29 | TD-Linux | rather than feature based |
| 01:37.36 | BulletCatcher | We set a fixed working period for 2.4 development just to encourage discipline. |
| 01:37.38 | BulletCatcher | Our plans beyond that are deliberately not fixed at this time. |
| 01:38.52 | BulletCatcher | http://my.bzflag.org/w/Development_RoadMap shows what we are thinking about, though. |
| 01:40.07 | TD-Linux | I'm actually tempted to look at the code a bit... I know a lot more C++ than in 2005-2006 when I was active |
| 01:41.16 | BulletCatcher | I encourage you to do so. |
| 01:41.18 | BulletCatcher | We are currently in no danger of having too many active developers. |
| 01:43.04 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 01:43.04 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 01:44.46 | TD-Linux | does the code still use immediate opengl? |
| 01:44.56 | TD-Linux | or have we progressed to vbo's yet? |
| 01:47.55 | BulletCatcher | I am not really familiar with those techinical terms, but 2.4 will use OpenGL in virtually the same way as in 2.0.x. |
| 01:48.26 | TD-Linux | oh hey the forums aren't green |
| 01:49.06 | BulletCatcher | Man, that changed a couple of *years* ago, I think. :-) |
| 01:49.43 | TD-Linux | my login still works yay |
| 01:51.03 | TD-Linux | my sister made a bzflag map a while ago, I made moving water waves using a drawInfo block |
| 01:51.16 | TD-Linux | IIRC that was basically a drawlist |
| 01:52.16 | TD-Linux | I'm not entirely sure why that was separate from mesh actually |
| 01:52.27 | TD-Linux | I better be careful, I might look at the code :> |
| 01:53.34 | a_meteorite | omg... TD-Linux? |
| 01:54.48 | TD-Linux | OMG a_meteorite !!! |
| 01:55.12 | TD-Linux | let's go play on boxywar |
| 01:55.16 | TD-Linux | right now |
| 01:55.40 | a_meteorite | sure, it should be up. search for boxy. one sec. |
| 01:55.47 | TD-Linux | hold on |
| 01:55.52 | TD-Linux | I need to install bzflag :> |
| 01:55.58 | a_meteorite | :o |
| 01:56.11 | TD-Linux | I switched from kubuntu to fedora about a year ago |
| 01:56.35 | TD-Linux | my home directory survived but I don't feel like recompiling |
| 01:56.38 | BulletCatcher | "yum install bzflag" is all you need to do. |
| 01:56.59 | TD-Linux | and it's what I'm doing :) |
| 01:57.04 | BulletCatcher | yay |
| 01:57.11 | TD-Linux | I first learned about bzflag by finding it my default install of fedora core 3 |
| 01:57.58 | TD-Linux | I'm now on fedora 14... |
| 01:58.10 | TD-Linux | should upgrade to 15 |
| 01:58.25 | Mr430 | what version was BZ? |
| 01:58.42 | TD-Linux | 1.10 IIRC |
| 01:59.16 | TD-Linux | I remember upgrading to 2.0.2 after that, so I think it was out of date |
| 01:59.34 | JeffM | TD-Linux: it's identitcal |
| 02:00.05 | BulletCatcher | Fedora 15 seems to be more troublesome for a lot of people than other recent versions. |
| 02:00.06 | BulletCatcher | I suggest waiting for f16 unless you have a specific reason to go to 15. |
| 02:00.29 | JeffM | 2.0.0 is over 6 years old |
| 02:00.31 | TD-Linux | yay I see my name in the boxywar texture downloads, a_meteorite join :) |
| 02:02.01 | a_meteorite | Getting AAA to join |
| 02:10.54 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 03:26.12 | blast007 | hiya TD-Linux |
| 03:37.16 | TD-Linux | hi blast007 |
| 03:48.22 | PlasticTank | I was playing with an bot and it was shooting normal bullets at me while holding TH |
| 04:18.19 | *** join/#bzflag Legoguy (~Legoguy@S0106001ee54ac005.ed.shawcable.net) |
| 04:28.30 | CIA-103 | BZFlag: 03dtremenak * r21860 10/branches/experimental/v2_99continuing/bzflag/src/include/tmp_test_foreach.cpp: string iterators must originate from the same object; instantiate first. |
| 04:28.37 | DTRemenak | trepan: works fine with that change |
| 04:32.11 | trepan | thanks |
| 04:33.07 | CIA-103 | BZFlag: 03trepan * r21861 10/branches/experimental/v2_99continuing/bzflag/src/include/tmp_test_foreach.cpp: * foreach() works with gcc & msvc, remove the test file |
| 04:34.09 | trepan | "string iterators must originate from the same object" -- odd error message, it didn't like the temporary var? |
| 04:38.05 | DTRemenak | it didn't like multiple temporary vars |
| 04:38.56 | DTRemenak | since it's a macro, it's instantiated more than once |
| 04:39.04 | DTRemenak | not sure why gcc didn't mind |
| 04:39.17 | DTRemenak | some optimization maybe |
| 04:43.58 | trepan | ya, good point - (CON).BEGIN() & (CON).END() |
| 04:44.29 | trepan | but it worked fine for gcc, guess it has a looser interpretation |
| 04:46.08 | DTRemenak | I'm guessing it figured out they were constant, and just initialized one |
| 04:53.42 | trepan | think i can hack something to avoid that problem |
| 04:56.45 | *** join/#bzflag Legoguy (~Legoguy@S0106001ee54ac005.ed.shawcable.net) |
| 05:58.40 | *** join/#bzflag Anxuiz (~Anxuiz@c-67-171-11-99.hsd1.wa.comcast.net) |
| 05:58.41 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 06:04.14 | *** join/#bzflag sirquine (~quine@adsl-75-37-33-191.dsl.pltn13.sbcglobal.net) |
| 06:07.47 | *** join/#bzflag Marzipan- (~Marzipan@p5B227CDF.dip.t-dialin.net) |
| 06:07.50 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 06:54.16 | *** join/#bzflag Legoguy (~Legoguy@S0106001ee54ac005.ed.shawcable.net) |
| 07:12.16 | *** join/#bzflag short_circuit (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 08:18.14 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:19.13 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:43.33 | *** join/#bzflag Upsetter (~er@i59F6D4A.versanet.de) |
| 09:27.38 | *** join/#bzflag delusional (~delusiona@unaffiliated/delusional) |
| 09:51.34 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 11:38.39 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 11:41.48 | *** join/#bzflag ahs3- (~ahs3@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 12:29.11 | *** join/#bzflag Zac_ (ca59b013@gateway/web/freenode/ip.202.89.176.19) |
| 14:32.40 | *** join/#bzflag bier|tp (~bier@p57A679DC.dip.t-dialin.net) |
| 14:32.46 | *** join/#bzflag bier (~bier@p57A679DC.dip.t-dialin.net) |
| 14:40.57 | moiree | ATM enhanced markers are not shown when the target has ST or CL and one has not SE. |
| 14:41.59 | moiree | I think when the target has MQ and one has not SE the marker should show ones team color instead of the real one. |
| 14:44.32 | moiree | Are there more funny combinations to think of? |
| 14:46.22 | moiree | OTOH are these markers really useful or more decorative? |
| 14:49.46 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 14:49.46 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 15:03.55 | CIA-103 | BZFlag: 03Optic Delusion 07http://my.bzflag.org * r7718 10/w/2.3_NewEffects: /* Genocide */ |
| 15:06.07 | CIA-103 | BZFlag: 03Optic Delusion 07http://my.bzflag.org * r7719 10/w/2.3_NewEffects: /* Genocide */ remove previous edit. |
| 15:09.24 | *** join/#bzflag jh` (~jh_@212-149-234-105.bb.dnainternet.fi) |
| 16:02.20 | BulletCatcher | moiree: I agree that MQ without SE should result in one's own color in the enhanced marker. |
| 16:07.39 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 16:07.40 | *** mode/#bzflag [+v spldart] by ChanServ |
| 16:24.18 | TD-Linux | I kind of really hate the MQ flag |
| 16:25.13 | TD-Linux | how are light effects done in non-bzflag games? like light cast from bullets? |
| 16:25.21 | TD-Linux | bzflag seems to subdivide the floor and use vertex lighting |
| 16:26.31 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 16:26.32 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 16:27.44 | trepan | TD-Linux: ground lights are a special case, look for 'GroundReceivers' in BackgroundRenderer.cpp |
| 16:28.47 | trepan | how do other games do it? deferred rendering with shaders, multipass with shaders (for higher light counts, with a spatial manager) |
| 16:29.31 | trepan | ray casting, soon? :) |
| 16:34.56 | *** join/#bzflag Anxuiz (~Anxuiz@c-67-171-11-99.hsd1.wa.comcast.net) |
| 16:34.57 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 16:38.35 | trepan | TD-Linux: http://trepan.bzflag.bz/bzrelief.jpg -- simple single-pass relief shader lighting using a server-sourced LuaWorld script |
| 16:39.40 | KTL | bumpmap please stay |
| 16:40.42 | trepan | ? |
| 16:40.56 | delusional | it was never here |
| 16:41.33 | KTL | those stones on the ground, arent those bumpmapped? trepans code that never got into the main code |
| 16:42.08 | trepan | that image is from 2.99, it's in SVN |
| 16:42.23 | trepan | http://trepan.bzflag.bz/bzdistort.jpg -- notice how there's a bit of distortion around the shots :) |
| 16:42.34 | TD-Linux | trepan: I remember seeing a screenshot like that a long time ago |
| 16:42.54 | KTL | idem, but now the shots are the idea of the picture |
| 16:43.02 | trepan | KTL: http://trepan.bzflag.bz/noshow/relief.jpg -- that one? |
| 16:43.09 | TD-Linux | trepan, what's LuaWorld? runs on the client? |
| 16:43.11 | trepan | that was raw coded shaders, not lua |
| 16:43.14 | TD-Linux | also what are the shaders written in? |
| 16:43.16 | KTL | older even |
| 16:43.25 | trepan | TD-Linux: ya, sourced by the server, run on the client |
| 16:43.40 | TD-Linux | what is the role of the lua script in the first image? |
| 16:43.58 | trepan | it renders all the world obstacles |
| 16:44.13 | trepan | (faster than the bz rendering, if done without shaders) |
| 16:44.13 | TD-Linux | oh, so no map file |
| 16:44.31 | trepan | no, it uses the world information from the map file |
| 16:44.34 | TD-Linux | did it use VBO's and modern OpenGL stuff? |
| 16:44.39 | trepan | it works with any world |
| 16:44.54 | trepan | TD-Linux: for that one, I used lists, iirc |
| 16:45.01 | trepan | it could also use VBOs |
| 16:45.02 | TD-Linux | just wondering what made it faster |
| 16:45.43 | TD-Linux | also ground effects is a great hack :) |
| 16:45.51 | KTL | those i wanted everywhere |
| 16:47.19 | trepan | TD-Linux: thanks (well the improved version is my work :) |
| 16:50.05 | *** join/#bzflag JeffM (~JeffM@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
| 16:50.06 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 16:50.06 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 16:50.25 | TD-Linux | why do you force black fog when drawing them? |
| 16:50.36 | TD-Linux | oh are you using a different blend mode? |
| 16:52.25 | trepan | they're rendered after the opaque obstacles, |
| 16:53.34 | TD-Linux | does the ground not render onto the z buffer? |
| 16:53.47 | trepan | nope |
| 16:55.00 | TD-Linux | still don't get the black fog color, wouldn't that make them black spots in the distance if you have, say, gray fog? |
| 16:55.22 | trepan | disable it, and see what happens with fog enabled |
| 17:01.50 | CIA-103 | BZFlag: 03JeffM2501 * r21862 10/trunk/bzflag/src/bzflag/effectsRenderer.cxx: go back to rings death when fancy effects are on for all deaths, we'll do per type deaths in a point release. |
| 17:02.18 | TD-Linux | I see the recievers are fogged wrong... but why are they fogged differently from the rest of the geometry? |
| 17:03.13 | trepan | rendering order |
| 17:03.37 | TD-Linux | oh.. because the geometry behind them is fogged |
| 17:03.39 | TD-Linux | and they are transparent |
| 17:03.41 | TD-Linux | you get 2x fog |
| 17:04.50 | TD-Linux | also for some reason the mountains aren't fogged when there is one active, I probably broke something |
| 17:04.56 | trepan | it's most because the use additive blending to fake lighting |
| 17:05.08 | TD-Linux | oh, they _do_ use addtive mode? |
| 17:05.45 | trepan | of course they do :) src_alpha blending doesn't really work for fake lights |
| 17:07.23 | TD-Linux | ok makes sense why it is black then, disregard me |
| 17:07.48 | TD-Linux | I thought it was pure alpha action |
| 17:13.24 | TD-Linux | I'm also curious, why did you make the special drawInfo block for display lists? Why not just add on to the mesh block? |
| 17:14.01 | trepan | it's was hacked in with a protocol change |
| 17:14.06 | trepan | *without |
| 17:28.08 | TD-Linux | so MeshSceneNode is the "drawInfo" view-only mesh |
| 17:43.19 | CIA-103 | BZFlag: 03JeffM2501 * r21863 10/trunk/bzflag/plugins/ (2 files in 2 dirs): fix up to build 64 bit |
| 17:57.46 | *** join/#bzflag meeba (~lamer@c-24-8-181-169.hsd1.co.comcast.net) |
| 17:58.13 | CIA-103 | BZFlag: 03JeffM2501 * r21864 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: take the command line parameter /DBUILD_64 to trigger the 64 bit installer |
| 17:58.50 | CIA-103 | BZFlag: 03JeffM2501 * r21865 10/trunk/bzflag/MSVC/build/ (fullbuild.sln installer.vcproj): trigger the installers for release targets ( assumes nsis is installed on the same drive as VC9). |
| 18:17.41 | BulletCatcher | Pimpinella: I agree that the end shot detection we have in the server mostly produces false positives. |
| 18:17.45 | BulletCatcher | Any objection (by anyone) to disabling it by default? |
| 18:17.49 | BulletCatcher | Or maybe we should just make it log and not kick. |
| 18:19.44 | JeffM | make it log |
| 18:21.26 | JeffM | I have some installers for people to test, http://www.awesomelaser.com/test/bzflag-2.3.0.20110515_32Bit.exe and http://www.awesomelaser.com/test/bzflag-2.3.0.20110515_64Bit.exe |
| 18:22.10 | blast007 | BulletCatcher: in what instances does it cause false positives? I was thinking it was mainly when there was network issues. |
| 18:23.44 | BulletCatcher | When I first started running my server, I saw some players get EndShot kicked who I was sure were not cheating. |
| 18:23.47 | BulletCatcher | They tended to be laggy, but not always. |
| 18:23.55 | BulletCatcher | So I turned it off. |
| 18:24.03 | BulletCatcher | No regrets. |
| 18:34.16 | BulletCatcher | Do you use it on bzexcess, blast007? |
| 18:34.18 | BulletCatcher | If so, how many of the EndShot kickees do you think were actually cheating? |
| 18:41.10 | CIA-103 | BZFlag: 03JeffM2501 * r21866 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: put the date in the installer dialog so we can easily tell what we are installing. |
| 18:44.11 | blast007 | well, probably very few - however, I'd also venture to bet that if we default the check to off that the cheaters would start abusing that |
| 18:44.31 | blast007 | in the last 10 months, I've had 72 EndShot credit kicks |
| 18:44.57 | blast007 | that's out of around 376248 joins |
| 18:46.13 | blast007 | and just glancing through the list of those who got kicked, I see at least one that I am well aware that has network issues (packet loss specifically, iirc) |
| 18:46.54 | BulletCatcher | Packet loss can definitely lead to endshot trouble. |
| 18:47.27 | blast007 | also betting if I checked on the individuals that had the endshot kick that I would find some network related kicks for most of them |
| 18:48.03 | blast007 | in what situations does the endshot kick normally happen to unfortunate people? is it when their client still thinks they have a GM flag? |
| 18:49.19 | BulletCatcher | The logs I have from when it was enabled, in late 2007, were on a map without GM. |
| 18:49.46 | blast007 | then it seems strange that it happened |
| 18:50.00 | BulletCatcher | Yes. That's why I disabled it. :-) |
| 18:50.01 | blast007 | the end shot message is only supposed to occur when you get hit, or when you are shooting GMs |
| 18:50.35 | blast007 | not sure how it works for shield, but I know when you fire a GM, you get a "credit" that can be used to end the shot when it finishes |
| 18:50.52 | BulletCatcher | Ah. My map uses shield flags. |
| 18:51.08 | blast007 | still, seems strange |
| 18:51.26 | blast007 | the messages should be TCP, so they should get there at SOME point, right? |
| 18:52.22 | blast007 | I imagine you get an end shot credit when you get hit whild holding a shield flag, and when you report that you got shot and died |
| 18:53.10 | blast007 | so someone would have had to end 5 shots without the server getting the message that they fired a GM, died, or lost their shield flag due to being hit |
| 18:53.39 | BulletCatcher | MsgShotEnd goes via UDP. |
| 18:53.49 | blast007 | ewww, why? |
| 18:55.02 | BulletCatcher | Same as MsgShotBegin, MsgGMUpdate, etc. |
| 18:55.30 | blast007 | GM update I can see being UDP (since there would be another update coming soon, right?), but why shot begin/end? |
| 18:56.17 | blast007 | seems like that could be the reason for the incorrect endshot kicks |
| 18:56.32 | BulletCatcher | Could very well be. |
| 18:57.04 | BulletCatcher | MsgShotBegin via UDP isn't really a problem. If your gun misfires you'll just click again. |
| 18:57.33 | blast007 | the local client would think their shot started though |
| 18:57.44 | blast007 | it doesn't get the message from the server that it fired |
| 18:57.57 | blast007 | it assumes it did and does it without any network interaction |
| 18:58.01 | BulletCatcher | k |
| 18:58.20 | blast007 | so it would also assume that, in the case of a GM, that it needs to send the MsgShotEnd |
| 18:58.30 | BulletCatcher | But you don't want shots to begin late due to possible TCP delays. |
| 18:58.32 | blast007 | even if the server never got the begin |
| 18:58.45 | blast007 | is it better for them to be late than to never come at all? |
| 18:58.52 | blast007 | it's not like a player movement update |
| 18:58.57 | blast007 | if it's missed, it will never come |
| 18:59.12 | blast007 | it's just like flag updates |
| 18:59.24 | Pimpinella | anyone for a quick test on hix ? |
| 18:59.34 | blast007 | we send though via TCP because they HAVE to get there or else someone might not know that someone has a flag |
| 18:59.52 | blast007 | I think that a bullet being fired or not is important enough that it should be TCP |
| 19:00.06 | blast007 | this is also probably why some GMs never end, since the end message can get lost |
| 19:00.15 | BulletCatcher | I think it is too late to consider changing MsgShotBegin to TCP for 2.3, but we should keep it in mind for later. |
| 19:00.19 | blast007 | yeah |
| 19:00.59 | BulletCatcher | It sounds like end shot detection hasn't been a big problem either way. |
| 19:01.04 | BulletCatcher | I'll simply change bzfs to log endshot incidents even when _endShotDetection is zero. |
| 19:01.06 | BulletCatcher | That will give us more data for future evaluation. |
| 19:01.25 | blast007 | what will it log if it's zero? |
| 19:01.47 | blast007 | the end shot credit amount *will* change as a player plays |
| 19:02.01 | Pimpinella | anyone? will only take 20 seconds |
| 19:02.14 | blast007 | Pimpinella: with a 2.3 client? |
| 19:02.16 | BulletCatcher | What server, Pimpinella? |
| 19:02.18 | Pimpinella | yep |
| 19:02.22 | Pimpinella | hix |
| 19:02.37 | blast007 | let me see if my client is updated enough |
| 19:02.37 | BulletCatcher | goes to connect |
| 19:04.02 | Pimpinella | ty |
| 19:06.14 | CIA-103 | BZFlag: 03pimpinella * r21867 10/trunk/bzflag/src/bzflag/playing.cxx: drop lock when dropping GM or the previously locked player will still have crosshairs (thats the right term?) |
| 19:11.41 | Pimpinella | BulletCatcher: i have end shot detection enabled, but threshold is set high, not sure, 10 probably |
| 19:12.10 | Pimpinella | a cheater will get kicked soon anyway |
| 19:12.47 | Pimpinella | but it clearly produces false positives |
| 19:12.58 | Pimpinella | not only with GM |
| 19:17.40 | Pimpinella | PlasticTank: fixed GM, thank you for hint |
| 19:18.02 | PlasticTank | Np |
| 19:31.42 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 19:33.32 | *** join/#bzflag jh`` (~jh_@212-149-234-105.bb.dnainternet.fi) |
| 19:43.26 | *** join/#bzflag zomane (~zarine@zumane.pppoe.fiber-lan.eu) |
| 20:13.56 | TD-Linux | why have the arrow things above tank? |
| 20:14.00 | TD-Linux | I think player names are enough |
| 20:14.09 | TD-Linux | they look too similar to flag indicators |
| 20:14.53 | PlasticTank | aren't these the same as tank labels? |
| 20:18.38 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 20:18.39 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 20:22.23 | *** join/#bzflag Upsetter (~er@88.130.189.135) |
| 20:27.00 | TD-Linux | yes? |
| 20:27.15 | TD-Linux | in BoltSceneNode, why is there both color and teamColor? |
| 20:27.21 | TD-Linux | teamColor is used for GM rendering only |
| 20:29.50 | JeffM | Constitution, the shadows are so cheezy it's embarasing :) |
| 21:24.20 | TD-Linux | what base color are blue bolts? 0, 0, 1? |
| 21:26.52 | JeffM | what code base are you talking about and what render quality? |
| 21:30.56 | TD-Linux | hmm experimental quality, what code path is that? |
| 21:31.15 | TD-Linux | the problem is a red flare behind the bolt |
| 21:31.16 | JeffM | in trunk? or 2.99? |
| 21:31.20 | TD-Linux | makes it look purple, in trunk |
| 21:31.56 | TD-Linux | shotLength is 4 |
| 21:32.07 | TD-Linux | so it doesn't call renderGeoGMBolt(); |
| 21:32.43 | JeffM | ahh so it's the normal spiked flair |
| 21:32.48 | JeffM | theose are always orange on GMs |
| 21:33.24 | JeffM | I belive it was suposed to be the "fire" from the missile |
| 21:33.37 | TD-Linux | but it's on all bullets |
| 21:33.44 | TD-Linux | and it applies on High quality as well |
| 21:33.51 | JeffM | trunk or 2.99? |
| 21:33.54 | TD-Linux | trunki |
| 21:34.29 | JeffM | lets see, maybe I screwed it up |
| 21:34.45 | TD-Linux | I'm a bit confused about the logic on line 581 of BoltSceneNode.cxx |
| 21:35.25 | JeffM | for GM it draws both the 3d missle AND the flare |
| 21:36.28 | JeffM | it should not be getting into the flare section |
| 21:36.45 | JeffM | is sceneNode->drawFlares true? |
| 21:37.37 | TD-Linux | I'm only concerned about normal bolts here |
| 21:37.42 | JeffM | I know |
| 21:38.01 | JeffM | but it sounds like it's using flare color when it should not |
| 21:38.10 | TD-Linux | well flare color is set to shot color |
| 21:38.30 | JeffM | <PROTECTED> |
| 21:38.33 | JeffM | no.. no it is not |
| 21:38.38 | TD-Linux | I assume the "flare" is the tail ? |
| 21:38.58 | TD-Linux | what about line 293 |
| 21:39.01 | JeffM | no |
| 21:39.08 | JeffM | the flare is the GM spike thing |
| 21:39.18 | TD-Linux | oh... this is a red "tail" |
| 21:39.22 | TD-Linux | looks like flames |
| 21:39.22 | JeffM | YES |
| 21:39.24 | JeffM | yes |
| 21:39.27 | JeffM | for a missle ;) |
| 21:39.32 | JeffM | fawooooossshhhh |
| 21:39.49 | JeffM | thats why it's only suposed to be used for GM |
| 21:39.49 | TD-Linux | what is that called in the code? |
| 21:40.14 | JeffM | a flare |
| 21:40.33 | moiree | I probably updated a patch for enhanced HUD markers: <https://sourceforge.net/tracker/?func=detail&aid=3314933&group_id=3248&atid=303248> |
| 21:40.41 | JeffM | the tail is in the part where it draws the core and corona |
| 21:41.31 | JeffM | it should be using maincolor and outercolor |
| 21:41.51 | moiree | And I do think that a new client should not be released with the enhanced HUD markers in their current state as they might be too enhanced. |
| 21:42.49 | JeffM | ahh I see the shot tail uses the "missle" texture |
| 21:43.00 | JeffM | moiree, why? |
| 21:44.11 | moiree | JeffM: Because they give too much information, the player should not have: Like f.e. the TeamColor when holding CB. |
| 21:44.28 | JeffM | well that's a bug we should fix |
| 21:44.40 | JeffM | I thought that's what you did fix |
| 21:45.07 | JeffM | TD-Linux, the color comes from the texture |
| 21:45.16 | moiree | Yes, I think so. Probaly someone else want to confirm that it does fix it. |
| 21:45.28 | JeffM | then what is the problem once that is fixed? |
| 21:45.37 | JeffM | 2.3 hasn't been released yet |
| 21:45.44 | JeffM | and won't be untill that gets applied |
| 21:45.49 | JeffM | this isn't going in 2.0.x |
| 21:46.19 | moiree | Godd. |
| 21:46.29 | moiree | Good even. |
| 21:46.38 | JeffM | you do understand we never release odd versions right? |
| 21:46.47 | JeffM | 2.3 will never be an official release |
| 21:46.50 | JeffM | it will be 2.4 |
| 21:46.55 | JeffM | and this is development time |
| 21:47.14 | moiree | But it's only 3 days, IIRC? |
| 21:47.23 | JeffM | no no no |
| 21:47.30 | JeffM | we arn't going ot just build and say it's done |
| 21:47.34 | JeffM | we start TESTING in 3 days |
| 21:47.42 | moiree | Phew. okay then. |
| 21:47.48 | JeffM | this deadline is the new feature cutoff |
| 21:47.50 | JeffM | that's it |
| 21:47.58 | JeffM | there hasn't even been a beta |
| 21:49.35 | JeffM | heck the doc even has a one month testing period, that's too long |
| 21:49.45 | TD-Linux | JeffM: how about changing shot tail texture to the same bolt texture? |
| 21:49.59 | JeffM | show me screenshots of how bad it looks |
| 21:50.03 | TD-Linux | ok |
| 21:50.43 | CIA-103 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7720 10/w/BZFlag_2.3: /* Schedule */ clarify and update |
| 21:50.55 | TD-Linux | did the screenshot button change? |
| 21:51.06 | JeffM | dunno |
| 21:51.17 | JeffM | the screenshot code changes for sure |
| 21:51.27 | JeffM | always uses printscreen and paste into PS |
| 21:55.39 | TD-Linux | bzflag seems to capture all keys, can't print screen |
| 21:55.52 | JeffM | works for me |
| 21:56.01 | TD-Linux | you're on a better OS |
| 21:56.10 | JeffM | just needs moiree's info for the autors file |
| 21:56.16 | JeffM | damn skippy I am :) |
| 21:56.18 | TD-Linux | also the screenshot feature seems broken |
| 21:57.00 | JeffM | dosn't suprise me |
| 21:57.04 | JeffM | it was made multithreaded |
| 21:58.13 | TD-Linux | is there a way to let bzflag let go of mouse? |
| 21:58.29 | JeffM | yeah config option to not have it clamp the mouse to the window |
| 21:58.40 | TD-Linux | got it |
| 22:01.12 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 22:01.41 | *** join/#bzflag jh` (~jh_@212-149-234-105.bb.dnainternet.fi) |
| 22:02.42 | TD-Linux | http://i.imgur.com/8z0oy.jpg |
| 22:02.53 | TD-Linux | http://i.imgur.com/5F4SM.jpg |
| 22:03.28 | JeffM | I kninda like it |
| 22:04.33 | TD-Linux | side view is OK |
| 22:04.41 | TD-Linux | but still looks very purple esp. in motion |
| 22:05.19 | JeffM | the problem is the code assumes multiple frames |
| 22:05.29 | JeffM | swaping it to the bolt would not work |
| 22:05.54 | TD-Linux | maybe less intense would help |
| 22:06.02 | JeffM | that means a new image |
| 22:06.14 | JeffM | since the image is shared with lower quality GM |
| 22:06.14 | TD-Linux | no I mean less alpha |
| 22:06.27 | JeffM | ponders |
| 22:06.49 | TD-Linux | the code *could* be changed too |
| 22:07.01 | JeffM | yeah but having the variation is pretty cool |
| 22:07.09 | JeffM | going to a single frame is repetitive |
| 22:07.09 | TD-Linux | yeah I like how it flickers |
| 22:07.18 | JeffM | I don't mind making a new image just for the tail |
| 22:07.48 | JeffM | most of the defintion in the image is in it's hue so desaturating it looses a lot |
| 22:08.50 | TD-Linux | it could me a more "lightning" like sequence |
| 22:09.08 | TD-Linux | put in detail with edges |
| 22:11.57 | JeffM | give that a whirl |
| 22:12.01 | CIA-103 | BZFlag: 03JeffM2501 * r21868 10/trunk/bzflag/ (3 files in 2 dirs): use a different image for the shot tail so it's orange doesn't blend into the shot. |
| 22:14.00 | TD-Linux | also I discovered just making it smaller so it fits into the white center of the shot helps a LOT, but then you don't see the animation when it's going toward you or away from you |
| 22:14.26 | KTL | a bit white-ish |
| 22:14.43 | JeffM | yeah too whiteish |
| 22:17.58 | CIA-103 | BZFlag: 03JeffM2501 * r21869 10/trunk/bzflag/ (data/shot_tail.png src/geometry/BoltSceneNode.cxx): get some team color in there and make the tail not so bright |
| 22:18.11 | JeffM | give that a whirl |
| 22:22.46 | *** join/#bzflag Anxuiz (~Anxuiz@c-67-171-11-99.hsd1.wa.comcast.net) |
| 22:22.47 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 22:23.38 | KTL | maybe hsv colorspace might help here, just intuition |
| 22:23.40 | TD-Linux | that's fine... maybe not as cool as the flame |
| 22:24.00 | TD-Linux | I dunno how much we care about clarity of the bullet color |
| 22:25.24 | TD-Linux | if you use r21867 and set startSize to 0.3f it works nicely too |
| 22:26.34 | CIA-103 | BZFlag: 03JeffM2501 * r21870 10/trunk/bzflag/ (AUTHORS src/bzflag/playing.cxx): fix hud markers with flags that affect vision from patch 3314933 (thanks moiree) |
| 22:27.18 | JeffM | I kinda like having a seperate image for it |
| 22:27.28 | JeffM | then we can tweak it as needed |
| 22:27.54 | KTL | are those triangles above teamflags those hud markers? |
| 22:28.07 | JeffM | thats one kind of hud marker, yes |
| 22:28.30 | JeffM | there are lockon and iff markers too |
| 22:28.44 | JeffM | the teamflag one is just an extension of the one on the compas |
| 22:28.51 | JeffM | not really new info |
| 22:29.04 | TD-Linux | the lock on marker is great |
| 22:30.10 | JeffM | what's a hud with out a lockon target :) |
| 22:30.35 | JeffM | tho our hud isn't really that much of a heads up display as a "look down at this radar and play the game" display |
| 22:40.40 | KTL | mmm segfault of the client when the server restarted |
| 22:41.27 | KTL | i compiled with enable-profiling and enable-debug, any traces left that can help? |
| 22:43.19 | blast007 | linux? |
| 22:43.38 | blast007 | if so, what does 'ulimit -c' say? |
| 22:43.56 | KTL | it says |
| 22:43.57 | KTL | 0 |
| 22:44.02 | blast007 | then no |
| 22:44.32 | blast007 | do a 'ulimit -c unlimited' on the shell you're running the client/server from, or run them within gdb from the start |
| 22:44.47 | blast007 | ulimit -c controls the maximum core dump size |
| 22:45.45 | KTL | ah |
| 22:52.58 | KTL | i suppose it is a consequence of the networking changes that tanks often seem to still exist after their explosion? |
| 22:53.11 | KTL | that the client waits for server confirmation that the opponent has been killed? |
| 22:53.32 | JeffM | nothing for networking like that changed |
| 22:53.37 | JeffM | the death explosion code did |
| 22:53.41 | JeffM | how old is your build? |
| 22:53.49 | KTL | last of the last |
| 22:53.56 | *** part/#bzflag Upsetter (~er@88.130.189.135) |
| 22:54.01 | JeffM | do you have facny deaths enabled? |
| 22:54.24 | KTL | yes |
| 22:54.33 | JeffM | turn em off and see if it still happens |
| 23:07.24 | KTL | ah next crash :) |
| 23:07.51 | JeffM | were the graphic deaths causing the pause? |
| 23:08.59 | KTL | the visual tank might be gone in time, the radar one ... i often had the impression it disappeared quite late |
| 23:09.19 | JeffM | that wasn't changed at all |
| 23:09.31 | KTL | http://pastebin.com/rsVuTyTT <- backtrace crash when server was restarted |
| 23:11.44 | JeffM | and you tured death effects off? |
| 23:12.40 | KTL | the segfault was at a moment i had it on, but dont worry about it because first i need to see it 100 times more to be sure |
| 23:12.56 | JeffM | they are what is crashing |
| 23:12.59 | JeffM | I'll have to pull em |
| 23:15.46 | KTL | i had a situation a few minutes ago where my bullets were extremely slow, the bots wouldnt shoot anymore, reload time also extremely slow, but my opponent "all" had normal bullets |
| 23:16.36 | CIA-103 | BZFlag: 03JeffM2501 * r21871 10/trunk/bzflag/src/bzflag/ (effectsRenderer.h playing.cxx): remove death effects that change the explosion, we'll do those in 2.4.4 |
| 23:17.20 | KTL | drastic... |
| 23:17.26 | JeffM | not really |
| 23:17.28 | JeffM | I had planed on it |
| 23:17.35 | JeffM | I don't have time to add more |
| 23:17.44 | JeffM | and rings didn't change the explosion |
| 23:17.57 | JeffM | all I did was have it not add it to the player |
| 23:18.22 | JeffM | we've got a good list of effects to do for 2.4.4 so we can do it proper :) |
| 23:20.23 | delusional | sobs sadly |
| 23:20.37 | KTL | lol |
| 23:20.43 | JeffM | we'll get there |
| 23:20.49 | JeffM | the mechanism is still in place |
| 23:23.39 | CIA-103 | BZFlag: 03blast007 * r21872 10/trunk/bzflag/src/bzfs/CmdLineOptions.cxx: Output the game options value properly |
| 23:28.31 | McSpider | btw, in openFFA the teammate lock warning indicator shoudn't be shown. |
| 23:29.03 | JeffM | true |
| 23:29.18 | JeffM | that should be calling the "isKillable" function that takes that into account |
| 23:58.00 | TD-Linux | is openFFA FFA but ignoring colors? |
