00:00.19 | JeffM2501 | damn p4 2.4's are STILL over 120$ |
00:00.28 | JeffM2501 | you can get a 3000+ for that |
00:00.28 | DTRemenak | heh |
00:00.33 | DTRemenak | yup |
00:01.24 | JeffM2501 | well the XP 64 4000 is still like 300$ less then the "extreme" p4 |
00:01.53 | DTRemenak | yeah. they're both too expensive :) |
00:02.13 | JeffM2501 | looks like the best bang/buck 64 is the 3400 at about $200 |
00:02.46 | JeffM2501 | I'd like to have PCIe as well |
00:02.50 | JeffM2501 | tho that means new card |
00:03.08 | *** join/#bzflag blast007 (~blast007@dialup-4.159.80.132.Dial1.Chicago1.Level3.net) |
00:03.48 | g0th1k_n00dl3 | WHASSAAAAAAAAAP!!! |
00:04.05 | purple_cow | JeffM2501: well, neither CPU can come close to the cost of a good ia64 chip ;) |
00:04.23 | JeffM2501 | what is an ia64? |
00:04.27 | purple_cow | itanium |
00:04.30 | JeffM2501 | ahh |
00:04.48 | JeffM2501 | wasn't that intels atempt at 64ness? |
00:04.56 | g0th1k_n00dl3 | yup |
00:05.06 | JeffM2501 | 1200$ damn... |
00:05.15 | JeffM2501 | why did it flop and not the AMD? |
00:05.22 | purple_cow | it didn't flop |
00:05.24 | *** part/#bzflag darrend (~darren@43-015.adsl.zetnet.co.uk) |
00:05.26 | purple_cow | the markets are different |
00:05.41 | JeffM2501 | more of the minicomputer market then? |
00:05.43 | TimRiker | ia64 systems are selling fairly well. just not in the desktop market. |
00:05.46 | JeffM2501 | instead of consumer |
00:05.46 | purple_cow | ia64 are aimed at supercomputers, opteron are aimed at servers |
00:05.49 | JeffM2501 | ahh |
00:06.01 | JeffM2501 | and the XP64's? |
00:06.07 | purple_cow | end-users :) |
00:06.10 | DTRemenak | purple_cow, intels original intent did include a broader market |
00:06.10 | JeffM2501 | and what's a FX64? |
00:06.14 | JeffM2501 | how does that differ? |
00:06.21 | DTRemenak | but nobody bought ia64 workstations... |
00:07.04 | DTRemenak | FX64 is for people with too much money and a need for gaming speed |
00:07.06 | purple_cow | uhhuh. imagine that, a hardware vendor forgetting that purchasing decisions are made based on software... |
00:07.17 | DTRemenak | heh :) |
00:07.39 | JeffM2501 | now operrons don't run 32 bit code do they? |
00:07.47 | DTRemenak | yeah |
00:07.48 | JeffM2501 | unlike the XP64s that run both |
00:07.49 | JeffM2501 | ok |
00:07.50 | purple_cow | though i think intel is still on track for a price-point merge between xeon and itanium in 5 years or so |
00:07.56 | DTRemenak | er, thought you said do |
00:07.58 | purple_cow | which will be a very cool day |
00:08.10 | DTRemenak | all amd64s run 32-bit code if you want them to |
00:08.21 | JeffM2501 | ahh |
00:08.26 | JeffM2501 | and the intel? |
00:08.37 | JeffM2501 | can that run "normal" stuff too? |
00:08.42 | DTRemenak | emulates it |
00:08.44 | purple_cow | ia64 has an emulation mode, but it's pretty slow |
00:08.48 | DTRemenak | not very fast |
00:08.53 | purple_cow | their new em64t stuff is basically just x86_64 |
00:09.15 | JeffM2501 | so the AMDs seem beter targeted at those who would be upgrading |
00:10.06 | JeffM2501 | I'm at a XP2800 now |
00:10.12 | JeffM2501 | so it's time to upgrade |
00:12.51 | *** join/#bzflag tankgina (~gigi@105-48.240.81.adsl.skynet.be) |
00:13.19 | *** join/#bzflag JeffM2501 (~JeffM@Patlabor221.active.supporter.pdpc) |
00:19.38 | trepan | c3po: looks like map processing time still counts as part of the initial lag |
00:20.38 | trepan | or at least it did yesterday... just re-tested, doesn't now ? |
00:20.40 | Tupone | I thought I did it |
00:21.07 | trepan | think DTRemenak or learner might be able to confirm yesterday's observation |
00:21.21 | Tupone | Don't remember exactly what I did to remove :/ |
00:21.27 | trepan | :) |
00:21.49 | *** join/#bzflag noob_dont (~janko@dke90.neoplus.adsl.tpnet.pl) |
00:22.11 | Tupone | your server I suppose |
00:22.28 | trepan | yup, i think it was the rocks server (about 5 secs processing for me) |
00:24.02 | *** join/#bzflag ducttape (~45012a16@webchat.bzflag.bz) |
00:24.22 | trepan | Tupone: weird, i must have been dreaming... |
00:24.39 | Tupone | yeah |
00:25.01 | Tupone | Hope a good dream, not a nightmare |
00:25.08 | ducttape | Hey, need some feedback trying to start a bz server on windows, but i keep getting an error back, no host data found for 11004. Can anyone tell me what this means? |
00:25.15 | trepan | hope it doesn't recur, whatever it was |
00:26.46 | TravisBarker | ok, how do we make the bot join my server? |
00:27.49 | TravisBarker | ~bzfquery thetabase.net:5154 |
00:30.15 | trepan | Tupone: hehe, rrlog tool to the rescue; it was dtr and i on the rocks server, he started off with 6323 ms lag, which is strikingly close to my processing time |
00:31.56 | Tupone | what can I do? |
00:33.03 | trepan | dunno, would have to reproduce it first |
00:35.06 | trepan | Tupone: looks like lagInfo.reset() is called in GameKeeper, from its signingOn method |
00:36.00 | Tupone | yeah, it is called after map processing |
00:36.14 | trepan | the signingOn method is in bzfs.cxx addPlayer, which follows from a MsgEnter |
00:36.28 | Tupone | lemme re-see |
00:36.33 | trepan | i thought that we we're going to reset it after the first MsgAlive |
00:36.45 | trepan | s/'// |
00:36.59 | Tupone | MsgEnter was sent after World processing, no? |
00:37.14 | trepan | dunno, haven't checked client-side yet |
00:38.08 | Tupone | playing.cxx:4231 |
00:38.10 | trepan | MsgEnter is sent from ServerLink::sendEnter |
00:38.24 | TimRiker | TravisBarker: ibot just connects, get's the player list, and disconnects. similar to what the public list server tries. |
00:39.10 | trepan | ya, after the collision on scene processing |
00:39.50 | trepan | s/on/and |
00:39.55 | Tupone | so it should be ok, unless your server did an overwork |
00:40.09 | trepan | maybe he switched zbuffer modes or something |
00:40.23 | trepan | or the collision grid got rebuilt from some strange reason |
00:41.07 | Tupone | could be alsa that your server did something like file system check :) |
00:42.32 | Tupone | I got this warning message : Player c3po [0] (Blue Team) tried to capture Red Team flag without reaching its own base. |
00:42.55 | Tupone | Probably we should update position before capturing |
00:43.17 | trepan | we should probably have better checks |
00:43.24 | *** join/#bzflag TravisBarker (~travis@h237n2fls32o897.telia.com) |
00:43.26 | Tupone | I was not cheating :/ |
00:43.52 | TravisBarker | cheater |
00:43.53 | TravisBarker | :) |
00:44.43 | trepan | i warned about that particular problem to whomever it was that threw that code in |
00:45.02 | trepan | first off, playerupdates are udp |
00:45.45 | trepan | secondly (now looking at the code), there is no tolerance whatsoever |
00:46.35 | Tupone | if we send a player update before capturing, we could, in future check the speed for speed cheating |
00:46.37 | TravisBarker | ive been kicked for "moving too fast" before, and it was apparently only due to good ping time because i was *not* cheating at the time |
00:46.49 | trepan | thirdly: you may note that removePlayer is commented out at bzfs.cxx/2774, that was the only way that i was going to not revert the change |
00:47.02 | trepan | line 2811 |
00:47.21 | Tupone | :/ I know that ... I didn't like that check too |
00:47.34 | Tupone | and I removed some |
00:47.50 | trepan | care to take out the rest? just leave it as a DEBUG1 only, or fix it? |
00:47.54 | TravisBarker | so you guys are the bzflag developers? |
00:48.04 | TravisBarker | whats it written in? |
00:48.14 | purple_cow | nope, they're fairies |
00:48.15 | trepan | the whoseBase() isn't really written with tolerancing in mind |
00:48.16 | purple_cow | every one of them! |
00:48.33 | *** join/#bzflag TravisBa1ker (~travis@h237n2fls32o897.telia.com) |
00:48.36 | Tupone | well, I wanna this release out, so I postpone if is just a DEBUG1 |
00:48.40 | TravisBarker | what? |
00:48.41 | trepan | ~lart purple_cow |
00:48.45 | TravisBarker | that is ME |
00:48.52 | TravisBarker | how did i just join AGAIN? |
00:48.56 | trepan | kinda gradiose for a simple bot |
00:50.49 | trepan | Tupone: at least the MsgTeleport's are TCP, so if we did do some checking, that should be safe |
00:50.49 | TravisBa1ker | you better be worried |
00:51.26 | TravisBarker | :| |
00:51.43 | trepan | setup a bounding box based on last pos/vel + maximum velocities, get a list from CollisionManager, and see if any of the obstacles are a base of the right color |
00:52.02 | trepan | either that, or disable it |
00:53.20 | TravisBarker | asking again: what is bzflag written in? |
00:53.24 | trepan | C++ |
00:54.05 | trepan | Tupone: guess who's code? ;) |
00:54.16 | TravisBarker | something i should probably get around to learning one day |
00:54.33 | Tupone | lan56? |
00:54.50 | trepan | bingo |
00:54.58 | Tupone | :) I remember that |
00:56.36 | Tupone | Well. My solution will be sending a capture msg with a position ;) |
00:57.02 | Tupone | Then we have to check if position is compatible with speed |
00:57.18 | Tupone | and that is the bounding box you said |
00:58.06 | trepan | using a single packet for the new position makes it very easy to cheat against |
00:58.31 | Tupone | why, we have to incorporate Manu patch for speed checking |
00:58.37 | Tupone | and fix approriately |
00:58.56 | trepan | are there any holes in his patch that might cause false convictions ? |
00:59.36 | Tupone | I don't have that. There was but I have fixed the client to send a corect time |
01:00.00 | Tupone | there were :) |
01:00.15 | trepan | so no possibility of false convictions now? (looking for a commitment here :) |
01:00.32 | Tupone | trepan: I have not seen the code ! |
01:00.59 | trepan | ah, certainly wouldn't expect a commitment then =) |
01:01.10 | Tupone | I just talk him |
01:06.08 | CIA-2 | BZFlag: 03trepan * 10bzflag/src/bzfs/bzfs.cxx: flag/base checking is broken, just give warnings |
01:06.29 | *** join/#bzflag blast007_ (~blast007@dialup-4.159.183.210.Dial1.Chicago1.Level3.net) |
01:08.23 | *** join/#bzflag blast007_away (~blast@dialup-4.159.183.210.Dial1.Chicago1.Level3.net) |
01:09.10 | trepan | 007, license to fill (...screens with join/part messages ;) |
01:11.19 | scanline | :) |
01:11.27 | scanline | small screen ;) |
01:12.35 | trepan | 105x43; so i exaggerated a little |
01:12.47 | amathis | hah |
01:38.00 | TravisBarker | 105x43? are you talking to us from a cheap cell phone? |
01:38.17 | TravisBarker | cheep(sp?) |
01:38.20 | *** join/#bzflag MeBigFatGuy (dave@balt-209-150-116-22.dynamic-dial.qis.net) |