irclog2html for #bzflag on 20050104

00:00.19JeffM2501damn p4 2.4's are STILL over 120$
00:00.28JeffM2501you can get a 3000+ for that
00:00.28DTRemenakheh
00:00.33DTRemenakyup
00:01.24JeffM2501well the XP 64 4000 is still like 300$ less then the "extreme" p4
00:01.53DTRemenakyeah.  they're both too expensive :)
00:02.13JeffM2501looks like the best bang/buck 64 is the 3400 at about $200
00:02.46JeffM2501I'd like to have PCIe as well
00:02.50JeffM2501tho that means new card
00:03.08*** join/#bzflag blast007 (~blast007@dialup-4.159.80.132.Dial1.Chicago1.Level3.net)
00:03.48g0th1k_n00dl3WHASSAAAAAAAAAP!!!
00:04.05purple_cowJeffM2501: well, neither CPU can come close to the cost of a good ia64 chip ;)
00:04.23JeffM2501what is an ia64?
00:04.27purple_cowitanium
00:04.30JeffM2501ahh
00:04.48JeffM2501wasn't that intels atempt at 64ness?
00:04.56g0th1k_n00dl3yup
00:05.06JeffM25011200$ damn...
00:05.15JeffM2501why did it flop and not the AMD?
00:05.22purple_cowit didn't flop
00:05.24*** part/#bzflag darrend (~darren@43-015.adsl.zetnet.co.uk)
00:05.26purple_cowthe markets are different
00:05.41JeffM2501more of the minicomputer market then?
00:05.43TimRikeria64 systems are selling fairly well. just not in the desktop market.
00:05.46JeffM2501instead of consumer
00:05.46purple_cowia64 are aimed at supercomputers, opteron are aimed at servers
00:05.49JeffM2501ahh
00:06.01JeffM2501and the XP64's?
00:06.07purple_cowend-users :)
00:06.10DTRemenakpurple_cow, intels original intent did include a broader market
00:06.10JeffM2501and what's a FX64?
00:06.14JeffM2501how does that differ?
00:06.21DTRemenakbut nobody bought ia64 workstations...
00:07.04DTRemenakFX64 is for people with too much money and a need for gaming speed
00:07.06purple_cowuhhuh. imagine that, a hardware vendor forgetting that purchasing decisions are made based on software...
00:07.17DTRemenakheh :)
00:07.39JeffM2501now operrons don't run 32 bit code do they?
00:07.47DTRemenakyeah
00:07.48JeffM2501unlike the XP64s that run both
00:07.49JeffM2501ok
00:07.50purple_cowthough i think intel is still on track for a price-point merge between xeon and itanium in 5 years or so
00:07.56DTRemenaker, thought you said do
00:07.58purple_cowwhich will be a very cool day
00:08.10DTRemenakall amd64s run 32-bit code if you want them to
00:08.21JeffM2501ahh
00:08.26JeffM2501and the intel?
00:08.37JeffM2501can that run "normal" stuff too?
00:08.42DTRemenakemulates it
00:08.44purple_cowia64 has an emulation mode, but it's pretty slow
00:08.48DTRemenaknot very fast
00:08.53purple_cowtheir new em64t stuff is basically just x86_64
00:09.15JeffM2501so the AMDs seem beter targeted at those who would be upgrading
00:10.06JeffM2501I'm at a XP2800 now
00:10.12JeffM2501so 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.38trepanc3po: looks like map processing time still counts as part of the initial lag
00:20.38trepanor at least it did yesterday... just re-tested, doesn't now ?
00:20.40TuponeI thought I did it
00:21.07trepanthink DTRemenak or learner might be able to confirm yesterday's observation
00:21.21TuponeDon't remember exactly what I did to remove :/
00:21.27trepan:)
00:21.49*** join/#bzflag noob_dont (~janko@dke90.neoplus.adsl.tpnet.pl)
00:22.11Tuponeyour server I suppose
00:22.28trepanyup, 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.22trepanTupone: weird, i must have been dreaming...
00:24.39Tuponeyeah
00:25.01TuponeHope a good dream, not a nightmare
00:25.08ducttapeHey, 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.15trepanhope it doesn't recur, whatever it was
00:26.46TravisBarkerok, how do we make the bot join my server?
00:27.49TravisBarker~bzfquery thetabase.net:5154
00:30.15trepanTupone: 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.56Tuponewhat can I do?
00:33.03trepandunno, would have to reproduce it first
00:35.06trepanTupone: looks like lagInfo.reset() is called in GameKeeper, from its signingOn method
00:36.00Tuponeyeah, it is called after map processing
00:36.14trepanthe signingOn method is in bzfs.cxx addPlayer, which follows from a MsgEnter
00:36.28Tuponelemme re-see
00:36.33trepani thought that we we're going to reset it after the first MsgAlive
00:36.45trepans/'//
00:36.59TuponeMsgEnter was sent after World processing, no?
00:37.14trepandunno, haven't checked client-side yet
00:38.08Tuponeplaying.cxx:4231
00:38.10trepanMsgEnter is sent from ServerLink::sendEnter
00:38.24TimRikerTravisBarker: ibot just connects, get's the player list, and disconnects. similar to what the public list server tries.
00:39.10trepanya, after the collision on scene processing
00:39.50trepans/on/and
00:39.55Tuponeso it should be ok, unless your server did an overwork
00:40.09trepanmaybe he switched zbuffer modes or something
00:40.23trepanor the collision grid got rebuilt from some strange reason
00:41.07Tuponecould be alsa that your server did something like file system check :)
00:42.32TuponeI got this warning message : Player c3po [0] (Blue Team) tried to capture Red Team flag without reaching its own base.
00:42.55TuponeProbably we should update position before capturing
00:43.17trepanwe should probably have better checks
00:43.24*** join/#bzflag TravisBarker (~travis@h237n2fls32o897.telia.com)
00:43.26TuponeI was not cheating :/
00:43.52TravisBarkercheater
00:43.53TravisBarker:)
00:44.43trepani warned about that particular problem to whomever it was that threw that code in
00:45.02trepanfirst off, playerupdates are udp
00:45.45trepansecondly (now looking at the code), there is no tolerance whatsoever
00:46.35Tuponeif we send a player update before capturing, we could, in future check the speed for speed cheating
00:46.37TravisBarkerive 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.49trepanthirdly: 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.02trepanline 2811
00:47.21Tupone:/ I know that ... I didn't like that check too
00:47.34Tuponeand I removed some
00:47.50trepancare to take out the rest? just leave it as a DEBUG1 only, or fix it?
00:47.54TravisBarkerso you guys are the bzflag developers?
00:48.04TravisBarkerwhats it written in?
00:48.14purple_cownope, they're fairies
00:48.15trepanthe whoseBase() isn't really written with tolerancing in mind
00:48.16purple_cowevery one of them!
00:48.33*** join/#bzflag TravisBa1ker (~travis@h237n2fls32o897.telia.com)
00:48.36Tuponewell, I wanna this release out, so I postpone if is just a DEBUG1
00:48.40TravisBarkerwhat?
00:48.41trepan~lart purple_cow
00:48.45TravisBarkerthat is ME
00:48.52TravisBarkerhow did i just join AGAIN?
00:48.56trepankinda gradiose for a simple bot
00:50.49trepanTupone: at least the MsgTeleport's are TCP, so if we did do some checking, that should be safe
00:50.49TravisBa1keryou better be worried
00:51.26TravisBarker:|
00:51.43trepansetup 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.02trepaneither that, or disable it
00:53.20TravisBarkerasking again: what is bzflag written in?
00:53.24trepanC++
00:54.05trepanTupone: guess who's code?   ;)
00:54.16TravisBarkersomething i should probably get around to learning one day
00:54.33Tuponelan56?
00:54.50trepanbingo
00:54.58Tupone:) I remember that
00:56.36TuponeWell. My solution will be sending a capture msg with a position ;)
00:57.02TuponeThen we have to check if position is compatible with speed
00:57.18Tuponeand that is the bounding box you said
00:58.06trepanusing a single packet for the new position makes it very easy to cheat against
00:58.31Tuponewhy, we have to incorporate Manu patch for speed checking
00:58.37Tuponeand fix approriately
00:58.56trepanare there any holes in his patch that might cause false convictions ?
00:59.36TuponeI don't have that. There was but I have fixed the client to send a corect time
01:00.00Tuponethere were :)
01:00.15trepanso no possibility of false convictions now?  (looking for a commitment here  :)
01:00.32Tuponetrepan: I have not seen the code !
01:00.59trepanah, certainly wouldn't expect a commitment then   =)
01:01.10TuponeI just talk him
01:06.08CIA-2BZFlag: 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.10trepan007, license to fill  (...screens with join/part messages  ;)
01:11.19scanline:)
01:11.27scanlinesmall screen ;)
01:12.35trepan105x43; so i exaggerated a little
01:12.47amathishah
01:38.00TravisBarker105x43? are you talking to us from a cheap cell phone?
01:38.17TravisBarkercheep(sp?)
01:38.20*** join/#bzflag MeBigFatGuy (dave@balt-209-150-116-22.dynamic-dial.qis.net)