| 01:38:33 | captain_proton | hi vogon_jeltz |
| 01:39:24 | vogon_jeltz | hi |
| 01:41:16 | vogon_jeltz | reads up on the ATI Radeon series |
| 02:22:58 | vogon_jeltz | captain_proton: how much did your GeForce3 cost? |
| 03:46:01 | iLLf8d | seems the format squashes it so I made adjustments so it displays correctly |
| 03:55:27 | iLLf8d | yeah |
| 03:55:31 | iLLf8d | how goes it |
| 03:56:24 | iLLf8d | got most of the pics from desktop girls heh |
| 03:56:30 | iLLf8d | actually all of them |
| 03:56:43 | iLLf8d | I sent it to captain too so you may have it twice now |
| 03:59:48 | iLLf8d | I also changed my building colors and rooftop |
| 03:59:54 | iLLf8d | n looks cooler now |
| 04:34:32 | iLL_Flag | oh I've been having one of the worst bzflaging days ever |
| 04:34:35 | iLL_Flag | ah well |
| 04:38:22 | iLL_Flag | I notice when it gets into the teens player wise I get my ass kicked |
| 05:08:54 | iLL_Flag | i'll probably make a nekid one next =P /me sitll carying on |
| 07:54:04 | captain_proton | vogon_jeltz: $350 probably |
| 07:54:12 | vogon_jeltz | eww |
| 07:54:56 | captain_proton | heh |
| 07:55:00 | captain_proton | worth it though |
| 07:55:06 | vogon_jeltz | is getting a Radeon 7200 for $91 |
| 07:55:34 | captain_proton | would like to remind vogon_jeltz that he has no AGP port |
| 07:55:54 | vogon_jeltz | would like to remind captain_proton that he is getting a new mainboard, too |
| 07:56:18 | captain_proton | god...i think i drank 3 cokes tonight |
| 07:56:24 | vogon_jeltz | heh |
| 07:56:30 | vogon_jeltz | I've had the equivalent of 4 |
| 07:56:40 | captain_proton | one of my friends had 7 + 2 red bulls + 1 coffee |
| 07:57:01 | vogon_jeltz | I once had 3 liters of Coke in one day |
| 07:58:08 | captain_proton | our 'super lintendo' reciever box looks like it came out of a bad scifi movie |
| 07:58:23 | vogon_jeltz | hah |
| 07:58:44 | captain_proton | then again, so does the whole idea :) |
| 07:58:48 | vogon_jeltz | I actually priced the box in the topic :) |
| 07:58:55 | vogon_jeltz | that'd be a l33t-ass box |
| 07:59:15 | captain_proton | 5500??? thats it? |
| 07:59:17 | vogon_jeltz | it's serious "strap yourself in and feel the $" |
| 07:59:24 | vogon_jeltz | yep |
| 07:59:32 | captain_proton | starts thinking |
| 07:59:34 | vogon_jeltz | what can I say? components go for cheap |
| 07:59:52 | vogon_jeltz | the case and PSU might come in at another $500... |
| 08:00:10 | vogon_jeltz | it's an "Extended ATX" mobo |
| 08:00:29 | vogon_jeltz | I can give you URLs for all the part information pages, if you want |
| 08:01:00 | captain_proton | is going to have to dremel 2 more cord holes - we decided to make it possible to use the first 2 controllers to interface with a regular SNES as well as the parallel port |
| 08:01:02 | vogon_jeltz | but, man, that mofo would be a loud computer |
| 08:01:10 | captain_proton | you have no idea |
| 08:01:17 | vogon_jeltz | 18 hard drives :) |
| 08:01:24 | captain_proton | i have a friend who bought a computer - it came with no cooling |
| 08:01:29 | vogon_jeltz | bahahahaha |
| 08:01:35 | captain_proton | athlon too :P |
| 08:01:49 | captain_proton | it would reset when he tried to play CS (vc overheat) |
| 08:02:07 | captain_proton | so he bought 2 HUGE fans at the local surplus electronics store |
| 08:02:11 | vogon_jeltz | that computer specs in at 18 HDs, 2 main CPU fans, and a video CPU fan |
| 08:02:19 | captain_proton | and wired them at 2x the voltage they're rated |
| 08:02:25 | vogon_jeltz | hahahah |
| 08:02:28 | captain_proton | with a big-ass switch on the front |
| 08:02:41 | captain_proton | he turns it on for 2 seconds every 1/2 hour |
| 08:02:45 | vogon_jeltz | "Overdrive" |
| 08:02:50 | captain_proton | and it moves all the air through in just a fraction of a second |
| 08:03:23 | captain_proton | its insane |
| 08:03:56 | vogon_jeltz | http://www.microx-press.com/templates/micro/product.asp?sid=9F02C2B0C12C4589AF9953376CAF8C1&prodid=MBRTY201 |
| 08:03:59 | captain_proton | well i have a class in just under 6 hours - time for sleep... |
| 08:04:10 | captain_proton | goodnight |
| 08:04:14 | vogon_jeltz | heh |
| 08:04:29 | vogon_jeltz | nn |
| 08:04:54 | vogon_jeltz | http://www.microx-press.com/templates/micro/product.asp?sid=9F02C2B0C12C4589AF9953376CAF8C1&prodid=B2E7DCB95BC1444A98CFE8EBDC4485F0 |
| 08:06:11 | vogon_jeltz | http://www.microx-press.com/templates/micro/product.asp?sid=9F02C2B0C12C4589AF9953376CAF8C1&prodid=C8D9B12703484710A7290C61E342C6D0 |
| 08:07:25 | vogon_jeltz | http://www.microx-press.com/templates/micro/product.asp?sid=9F02C2B0C12C4589AF9953376CAF8C1&prodid=6AFE95F00E2E492E875203D782420C0A |
| 08:08:26 | vogon_jeltz | http://www.microx-press.com/templates/micro/product.asp?sid=9F02C2B0C12C4589AF9953376CAF8C1&prodid=HDDMA120C |
| 08:09:22 | vogon_jeltz | http://www.microx-press.com/templates/micro/product.asp?sid=9F02C2B0C12C4589AF9953376CAF8C1&prodid=CDRYA250C |
| 08:18:27 | vogon_jeltz | is away: afk |
| 09:14:08 | vogon_jeltz | is back (gone 00:55:41) |
| 09:32:13 | Chestal | re |
| 13:27:55 | vogon_jeltz | is away: sleep |
| 15:55:58 | captain_proton | returns |
| 16:00:51 | captain_proton | argh where is my buddy...i need mathematica |
| 16:16:34 | captain_proton | goes off to the lab to work |
| 19:33:19 | |ks| | hey tim, I found *a* solution to the ghost flags in the CVS version, but I don't know that it's the best... I added a test to the rendering code that prevents rendering of the flag if it's on the player's tank... it works as long as there are no mirrors, anyway =) |
| 19:33:33 | |ks| | should I submit a patch? |
| 19:34:03 | |ks| | I assume the better fix is to find out why the flag's location isn't being changed on the local tank, which I haven't been able to track down |
| 19:39:11 | Chestal | hi ks |
| 19:39:12 | Chestal | yes, I realyl feel that we shoudl find the cause of the bug |
| 19:39:35 | Chestal | sadly, I don't remember the old ghost flag bug, I think it also had visual / radar flag inconsitencies |
| 19:39:45 | Chestal | I hacked a bot, btw. |
| 19:40:00 | Chestal | took my old robot code and enhanced it with new shot evading code. He's nasty |
| 19:41:03 | Chestal | if I rememebr correctly, the cleint has a flags and a flagscenenode array |
| 19:41:20 | Chestal | the first contaitn logical info about flags, the other is rsponsible for flags in 3D view |
| 19:41:26 | Chestal | I wonder how these can get out of sync |
| 19:41:35 | Chestal | and what Tim's new network code has to do with it |
| 19:42:36 | Chestal | I didn't grab the current CVS code yet |
| 19:43:51 | |ks| | I've gone through the history of various files... haven't seen any changes that seem even remotely related to flag handling (aside from one that I ruled out) |
| 19:44:29 | |ks| | I can't help but think that it's part of the "butt ugly hack", which does some sort of mangling of packets to support old clients |
| 19:45:36 | Chestal | the old ghost flag bug was server related, too |
| 19:45:55 | Chestal | some error with NoFlag and -1 |
| 19:46:06 | Chestal | I'm checkign the client logic on rsponse to MsgGrabFlag |
| 19:46:16 | Chestal | flag.unpack() should do it |
| 19:46:26 | |ks| | hmmm... the problem only occurs on new server/client... not old server/new client... not sure about new server/old client |
| 19:47:07 | Chestal | bug is most probabvly in grabFlag() in bzfs.cxx |
| 19:47:13 | Chestal | but I do not have the new code here |
| 19:49:01 | |ks| | ok, process of elimination... back out to older versions of bzfs and find the patch that broke it... |
| 19:50:17 | Chestal | I will still try to udnerstand the client side mechanism when a flag is picked up |
| 19:50:22 | Chestal | somewhere the flagscenenode must be updated |
| 19:50:46 | Chestal | ah, there is World::updateFlag(), probagbly called regularly |
| 19:51:18 | Chestal | does the bug only occur when I pick up a flag? or when another player does it, too? |
| 19:53:12 | |ks| | I believe it's only your own flag... |
| 19:53:30 | |ks| | pick up a flag, you still see it out the window until you drop it somewhere else (which brings it back in sync) |
| 19:53:46 | |ks| | I don't believe it affects others, but don't have enough evidence to be sure |
| 19:54:07 | Chestal | somehting with the id |
| 19:54:21 | Chestal | flag.owner and ownid don;t match or something |
| 19:54:59 | Chestal | is Tim's server up? |
| 19:55:56 | |ks| | dunno |
| 19:56:40 | Chestal | do you know how the id handlign has changed? |
| 19:56:45 | |ks| | my patch checks flags[i].id == LocalPlayer::getMyTank()->getFlag(), so that at least is in sync |
| 19:57:05 | |ks| | not specifically... I haven't spent much time in the guts, so I'm still figuring out a lot of things =) |
| 19:57:21 | Chestal | do you have a CVS server running? |
| 19:57:30 | |ks| | it may just be player ids... there's a table mapping old ids to new ids, and a method that does the conversion |
| 19:57:34 | |ks| | no, just a client |
| 19:57:52 | Chestal | hmm, so we can't test it now, no server running CVS code |
| 19:58:02 | |ks| | i've backed out two versions of bzfs, and the bug disappears |
| 19:58:28 | |ks| | oh, sorry, thought you meant "CVS server" not "current bzflags server from cvs" =) |
| 19:58:36 | |ks| | I'm running a local copy, but it's not public... |
| 19:59:06 | Chestal | ah |
| 19:59:09 | Chestal | can I connect to it? |
| 20:00:00 | |ks| | ok, so the problem occurs between 1.52 and 1.53 |
| 20:00:19 | |ks| | nope, I'm behind a NAT firewall.... |
| 20:01:05 | |ks| | with a little work, I could set up a server on my firewall, but I've never had much luck getting a bz server running on that machine... probably could do it now that I know more about bz networking, though |
| 20:01:17 | Chestal | does it play the flag pickup sound? |
| 20:01:47 | |ks| | yep, that's the "butt ugly hack to allow changing playerid but keep working with old clients" update |
| 20:02:12 | |ks| | everything works except you see a ghost flag out the window |
| 20:03:07 | Chestal | in palyer.cxx updateflags() is responsible to move flags on tanks |
| 20:03:12 | Chestal | which it obviously doesn't |
| 20:03:32 | Chestal | so, either status!=FlagOnTank or flag.owner is wrong |
| 20:03:56 | |ks| | I suspect the latter... |
| 20:04:59 | Chestal | I'll check out the CVS code on sourceforge |
| 20:05:25 | |ks| | yep, FlagOnTank is correct... my workaround is in an if block that tests that condition |
| 20:05:28 | Chestal | I have some experience debuggign bzflag :-) |
| 20:06:32 | |ks| | I'm gonna take a closer look at the changes to bzfs... |
| 20:09:38 | Chestal | maybe patchMessage for MsgGrab should contain another patchPlayerId call? |
| 20:10:09 | Chestal | MsgGrab contains two player ids, one for the grabber and one as part of the flag structure |
| 20:10:17 | Chestal | I guess the latter also has to be patched before sending |
| 20:12:15 | Chestal | patchPlayerId(fromId, toId, msg, 20); I guess |
| 20:13:37 | Chestal | similar MsgDropFlag |
| 20:13:45 | Chestal | I'm quite sure this is the problem |
| 20:16:55 | Chestal | wah,bzfs crashes. We should fix this annoying SEGV bug |
| 20:17:20 | Chestal | ks: are you there? would be great if you could try what I propose |
| 20:18:09 | |ks| | i'm working on it... |
| 20:18:28 | |ks| | why does drop flag have two ids? shouldn't it just have the id of the player dropping it? |
| 20:18:49 | |ks| | and/or the id of the flag? |
| 20:19:23 | Chestal | well, the scheme both for msggrabflag and msgdropflag is simple |
| 20:19:37 | Chestal | the message begins with the plateyid of the player grabbing/dropping |
| 20:19:54 | Chestal | then the whole flag information is sent via flag.pack() |
| 20:20:04 | Chestal | anf data geneated by flag.pack() contains id of owner of flag |
| 20:20:15 | |ks| | i c... |
| 20:20:25 | Chestal | which should be == grabber id for grabflag and 0 or somethign for dropflag |
| 20:20:34 | Chestal | so for dropfalg the patch isnt necessary I guess |
| 20:20:41 | |ks| | so Flag.pack() defines the message structure? |
| 20:21:09 | Chestal | yes |
| 20:21:19 | Chestal | it's similar to the PVM way |
| 20:22:46 | Chestal | hmm, I still wonder whether Tim's patches work in all cases |
| 20:23:27 | Chestal | in fact I wonder if it works at all, looks broken to me |
| 20:24:05 | Chestal | or maybe I don't understand it |
| 20:24:57 | |ks| | hmmm... looks like sendFlagUpdate just sends the flag info... don't see it adding a player id 'cept through Flag.pack |
| 20:25:22 | BZFlag | is back, didn't read all the logs yet... |
| 20:25:26 | BZFlag | there is no new client yet. |
| 20:25:39 | BZFlag | just new server. so all clients are "old" ;-) |
| 20:26:26 | |ks| | oh, i c... directMessage adds it |
| 20:26:34 | Chestal | bzflag: I am tryng to understand your id patches |
| 20:26:39 | BZFlag | need to find where the GL and HUD get updated from. WHatever the GL uses is broken and should probably just get killed and use the HUD info (well get updated in the same code that updates the HUD) |
| 20:26:42 | |ks| | well, there's the CVS client, which is newer than the released version |
| 20:26:56 | BZFlag | the "butt ugly" ones? ;-) |
| 20:27:26 | BZFlag | ok, here's the deal: |
| 20:27:37 | |ks| | bz: there's a trivial patch to World::addFlags, which just skips the flag on the local tank... but that's kind of ugly, and if anyone ever adds mirrors... =) |
| 20:27:58 | BZFlag | a client connects and tells the server it's id which is just the server IP + server port + a 1 byte id. |
| 20:28:23 | BZFlag | if the server is only listening on one port then all clients will tell the server they have the same id. |
| 20:28:30 | BZFlag | whoops, that won't work will it? |
| 20:28:34 | BZFlag | so... |
| 20:28:45 | Chestal | ok, I understood that part and it's a good change |
| 20:29:19 | Chestal | with the new server and the old clients, the client will always work with the odl style player ids? |
| 20:29:30 | BZFlag | The server let's the client believe it it that old id, but builds a new playerid |
| 20:30:09 | BZFlag | that is based on what the server sees the client address/port as + the one byte of _actual_ id. |
| 20:30:37 | Chestal | it's two bytes I guess? |
| 20:30:46 | BZFlag | so, to answer Chestal, ... |
| 20:30:53 | Chestal | well, imagine MsgScore |
| 20:30:55 | Chestal | eh |
| 20:30:56 | Chestal | MskKilled |
| 20:31:00 | BZFlag | oh, yes. your are correct. 2 bytes of id. |
| 20:31:09 | Chestal | MsgKilled contains a victim and a kiler id |
| 20:31:38 | BZFlag | so the current (old) clients see the correct id for everyone but themselves. |
| 20:31:49 | Chestal | ah, hmm |
| 20:32:02 | Chestal | hmm, hmm |
| 20:32:06 | BZFlag | new clients (when I get to that) will see the correct id for everyone. |
| 20:32:10 | Chestal | that's confusing |
| 20:32:26 | BZFlag | yes. but the only way to get old clients working on one tcp port |
| 20:32:41 | Chestal | so the server woudl have to patch every playerid A that is in a mesage which is sent to A? |
| 20:32:58 | BZFlag | and received from A. exactly. |
| 20:33:07 | Chestal | ok |
| 20:33:20 | Chestal | then thre are just some cases missing in patchMessage() |
| 20:33:29 | BZFlag | likely, yess. |
| 20:33:30 | Chestal | for example in MsgGrabMessage which cuases the ghost flag bug |
| 20:33:34 | Chestal | at offset 20 |
| 20:33:40 | Chestal | flag.owner |
| 20:34:14 | Chestal | in theroy, same for msgdrop, but after dropping owner is set to 0 anyway I guess |
| 20:34:44 | BZFlag | hmmm... did I do 20? |
| 20:35:08 | Chestal | you only patch offset 4 for msggrabflag |
| 20:35:21 | BZFlag | that's probably the bug right there! |
| 20:35:30 | Chestal | yep |
| 20:35:34 | |ks| | ches: yep, 20 bytes in does it |
| 20:35:35 | BZFlag | changes cvs... |
| 20:35:55 | |ks| | just tested it, want a patch? |
| 20:36:35 | Chestal | so the new server will have to know whether a client is using new or old style ids? so it can know if it has to patch ids or not? |
| 20:37:54 | BZFlag | case MsgGrabFlag: |
| 20:37:54 | BZFlag | if (len > 28) |
| 20:37:54 | BZFlag | patchPlayerId(fromId, toId, msg, 4); |
| 20:37:54 | BZFlag | patchPlayerId(fromId, toId, msg, 20); |
| 20:37:55 | BZFlag | break; |
| 20:37:55 | BZFlag | ;; |
| 20:38:03 | BZFlag | look right? |
| 20:38:17 | |ks| | I didn't test len, but otherwise yes |
| 20:38:31 | BZFlag | Chestal: yes, it will have to know. if the client does a reconnect, it will assume old style. |
| 20:38:34 | |ks| | I also did it for MsgDropFlag, though that seems to work ok... |
| 20:39:07 | BZFlag | good point. doing DropFlag as well... |
| 20:39:32 | Chestal | well, in for msgdropflag flag.owner will be 0 anyway :-) |
| 20:39:47 | Chestal | by definition noone owns a dropped flag |
| 20:39:50 | |ks| | heh... true... =) |
| 20:40:12 | Chestal | but it's probably good style anyway |
| 20:40:19 | BZFlag | ah, true. but the offset 4 should not happen for an incoming packet. |
| 20:41:04 | Chestal | hmm? why not? |
| 20:42:00 | BZFlag | cause the player version of the message does not contain an id. |
| 20:43:46 | Chestal | oh |
| 20:44:10 | BZFlag | that fixed it, thanx! commited to CVS. |
| 20:44:30 | BZFlag | please review other packet types to see if I missed anything ;-) |
| 20:48:01 | |ks| | btw, didn't you kill off the pastel colors? they look washed out, and I'm not sure if it's my display or not... |
| 20:48:04 | Chestal | shouldn;t msg length be checked for the groups of msgs which are patched at offset 4 also? |
| 20:48:44 | Chestal | some of these have client->server versions, that do not contain a playerid at this offset |
| 21:13:31 | BZFlag | I'm still waiting for someone to send me radar colors they like. |
| 21:13:49 | BZFlag | Chestal: probably. |
| 21:33:27 | Chestal | I liek the radar colours I have (have disabled coloured shots in radar though) |
| 21:33:40 | Chestal | but it depends on your gfx settings |
| 21:33:57 | Chestal | colour of shots in 3D view depend on radar colurs also, right? |
| 21:34:08 | Chestal | I still havebn't found good colours for the shots |
| 21:34:28 | Chestal | they're hard to see sometimes for me, it's much better at home where I can play with textures on |
| 21:34:50 | Chestal | hehe, my bot is in the lead on ducati |
| 21:35:04 | Chestal | BZFlag: I hacked a special bot client |
| 21:35:30 | Chestal | BZFlag: I took my old aiming code I did early this year and put it into localplayer |
| 21:35:46 | Chestal | bzflag: so my bot technically isn't a bot, it's a patched client |
| 21:36:27 | Chestal | bzflag: and I added some code to evade shots. Except for evasive maneuvers it doesn't move though and it's quite dumb |
| 21:36:43 | Chestal | bzflag: and my bot client still has all the menus / gfx etc. |
| 21:45:58 | |ks| | which is your bot? |
| 21:46:21 | |ks| | gonna have to take it on from my real client =) |
| 21:48:34 | BZFlag | Chestal: cool. feel free to post patches in SF so others can play. |
| 21:48:44 | BZFlag | I really need to rip out the bot guts.... =( |
| 21:49:02 | Chestal | yes |
| 21:49:19 | Chestal | my bot is just hacked in |
| 21:49:29 | Chestal | thst's definitely not the way to go, but I wanted to tryit |
| 21:50:03 | Chestal | ks: well, it's not difficult to guess who's the bot :-) |
| 21:51:22 | |ks| | I've got a couple guesses... |
| 21:51:46 | Chestal | it's the one who doesn't move |
| 21:54:06 | Chestal | now that I have created a simple bot, several issues about bots 'cheating' came to my mind |
| 21:54:26 | Chestal | if we want to do a bot's API we'll have to decide which information is given to the bots |
| 21:54:43 | Chestal | there are some nifty details |
| 21:55:47 | Chestal | btw: finalyl bzflag is working at home (win98) for me |
| 21:55:55 | Chestal | installed the newest Matrox drivers |
| 21:56:11 | Chestal | I still get some strange artifacts, but at least it's working now |
| 21:58:49 | BZFlag | nice. client and server on same machine? |
| 21:59:49 | Chestal | ehm, what are you talkign about? my bot or my home machine? I don't get it :-) |
| 21:59:56 | BZFlag | the network needs a rewrite. Simple cheats should be detected, like if you don't have a laser flag, you can't claim to fire a laser, etc. |
| 22:00:22 | Chestal | ok, we ccan detect a wide range of cheats automatically, but not everything |
| 22:00:27 | Chestal | so I wonder whether it's worth the effort |
| 22:00:41 | BZFlag | the server should tell the client where all the flags are, but not _what_ they are except for team flags. |
| 22:00:59 | Chestal | I am using a client-side patch to detect too high tank or shot speed, because that is a cheat which is hard to detect manually |
| 22:01:16 | BZFlag | if we are going to remove the cheat potential from the bot, it needs to be done there. |
| 22:01:37 | BZFlag | doing cheat prevention in a client side piece of code, just does not make sense. |
| 22:01:38 | Chestal | I was thinking of other things when I was taling about cheating bots |
| 22:02:09 | Chestal | thigns liek: shoudkl the bot have exact inforatmion on other tanks' position, speed and angular speed? |
| 22:02:13 | BZFlag | the programmer that want's to "cheat" on bot code, will just bypass the cheat prevention code. |
| 22:02:38 | Chestal | we can create a robot API that prevents bots from being able to cheat |
| 22:02:52 | Chestal | question is: what kidn of inforamtion shoudl be available to robot programmers |
| 22:03:02 | BZFlag | what's to prevent a bot that looks like a player? it would have complete info. |
| 22:03:11 | Chestal | ok, that's possible of course |
| 22:03:24 | Chestal | I just thought about the bot API which might come someday |
| 22:03:45 | Chestal | it's not quite clear what info to give to the bot |
| 22:03:52 | BZFlag | and since it's open source, a bot-player would be almost as easy as writing to the "bot api" if there was one. |
| 22:04:10 | Chestal | it's not that easy currently |
| 22:04:29 | Chestal | a clean API would make it much easier IMHO |
| 22:04:33 | BZFlag | ah, but it's easier than writing to the bot api which does not exist yet. ;-) |
| 22:04:35 | Chestal | (and prevent cheating if you use that API) |
| 22:04:58 | BZFlag | I'm much more interested in protocol changes that prevent cheats from players and bots alike. |
| 22:04:58 | Chestal | for example, consider controls |
| 22:05:15 | BZFlag | we don't (yet) have an issue with invincible bots. |
| 22:05:21 | Chestal | a bot can fire a shot, set speed bewtween -0.5 and 1.0 and set ang velocity between -1.0 and 1.0 |
| 22:05:46 | Chestal | my bot would be better if it woudl mvoe forward when attackign, thus speedings up its shots |
| 22:05:47 | BZFlag | true, same goes for a cheating player. |
| 22:06:06 | Chestal | it woudl be possible for my bot to set it's speed to 1.0, wait one frame / time step, then shoot and stop moving |
| 22:06:27 | Chestal | that's not exactly cheating, but I stil wonder if it's fair |
| 22:07:09 | Chestal | its jsut that a bot can do such things as drive at full speed for 1/100s |
| 22:07:25 | Chestal | ands then stop immediately. A player coudl theoretically do that also, but it woudl be most difficult :-) |
| 22:08:09 | BZFlag | ah, but the server could put acceleration checks in and stop both the bot and the cheats. |
| 22:08:32 | Chestal | with basic settings there's no inertia, so no limits to acceleration |
| 22:08:44 | Chestal | I guess noone ever played with inertia enabled |
| 22:08:54 | Chestal | maybe I shoudl activie it on ducati :-) |
| 22:09:09 | Chestal | y bot is using the same calls as a normal player for controlling the tank |
| 22:09:22 | Chestal | so, technically it can't cheat this way |
| 22:09:43 | BZFlag | hmm... yes inertia should probably be on my default at some low value. |
| 22:09:52 | Chestal | of course the input it uses is totalyl different from that a player gets |
| 22:10:24 | Chestal | basically my bot uses 100% accurate radar |
| 22:12:08 | BZFlag | I've been thinking about what happens at the net layer for bad flags... some should probably cause less info to be sent over. |
| 22:12:12 | Chestal | heh, |ks| is outperforming my bot |
| 22:12:29 | BZFlag | heh |
| 22:12:39 | BZFlag | time to build a better bot then. ;-) |
| 22:12:50 | BZFlag | does you bot get flags? |
| 22:12:56 | BZFlag | s/you/your/ |
| 22:13:01 | Chestal | only by accident |
| 22:13:12 | BZFlag | go get the laser then use the same algorithm. ;-) |
| 22:13:19 | Chestal | as it doesn't normally move, I ave never seen it pick up a flag |
| 22:13:33 | Chestal | I guess it would be really powerful with laser |
| 22:13:34 | BZFlag | go get it and drop it over the bot. |
| 22:14:15 | Chestal | the bot has several weaknesses which can be exploited |
| 22:14:27 | Chestal | first, it's rather predictable and it doesnt know about ricohet |
| 22:14:52 | Chestal | it doesn't know about buildings, too (at least not when moving) |
| 22:15:16 | BZFlag | hates ricohet server switch. |
| 22:15:28 | Chestal | when it evades shots, it only looks at the one shot which would hit it first |
| 22:15:35 | Chestal | always plays with rico enabled |
| 22:15:39 | Chestal | rico rocks :-) |
| 22:15:52 | BZFlag | it kills laser |
| 22:16:10 | BZFlag | just try HiX with rico on. |
| 22:16:15 | Chestal | well, laser with rico is both more powerfull and less useful |
| 22:16:29 | Chestal | I am playign without flags most of the time lately |
| 22:16:33 | Chestal | and rico really adds to the game |
| 22:16:41 | BZFlag | I suppose it would not bee so bad if laser stopped when it hit someone. |
| 22:17:27 | Chestal | I haven't quite understood how laser works |
| 22:17:30 | BZFlag | I'd suggest no rico, no jumping, and a small set of known flags. 1 rico, 1 jump, etc. |
| 22:17:48 | Chestal | migh tbe an interesting setting |
| 22:18:01 | Chestal | but I prefer rico, no jump, 2 shots, that's perfect for me |
| 22:18:20 | Chestal | soemtimes I play with flags, sometimed without |
| 22:18:36 | Chestal | I hacked a /flags command into my server experimentally |
| 22:18:37 | BZFlag | try no rico but rico flags. ;-) |
| 22:18:48 | BZFlag | what does /flags do? |
| 22:18:52 | Chestal | so I can switch flags on and off during runtime |
| 22:19:03 | Chestal | yet another hack :-) |
| 22:19:10 | BZFlag | what does it do? |
| 22:19:30 | BZFlag | you set the number of flags? or just turn them all on and off? |
| 22:19:46 | Chestal | I start the server with flags activated |
| 22:20:18 | BZFlag | do they all rise and go away? |
| 22:20:21 | Chestal | when I do /flags <password> off an internal flag (sic!) is set, all flags are removed and no new ones are spawned |
| 22:20:54 | Chestal | after /flags <password> on the flag is just reset, so after soem time the flags will be back |
| 22:21:09 | Chestal | it's funny how tanks lose their flags when I do flags off :-) |
| 22:21:16 | BZFlag | what happens? |
| 22:21:40 | Chestal | well,m the flags are just gone, but it takes the players by surprise |
| 22:22:00 | Chestal | I use the swtich very rarely and only when the playrs that are on agree to change the mode |
| 22:22:03 | BZFlag | do the tanks get notified? or do they still believe they have one? |
| 22:22:10 | Chestal | they get notified |
| 22:22:23 | Chestal | it was easy to do, I am just using the normal removeflag() fucntion or whatever it it |
| 22:22:24 | BZFlag | so they see a normal drop message? |
| 22:23:18 | BZFlag | imho the admin should be able to change a lot of things on the fly. |
| 22:23:23 | Chestal | yep, I call zapFlag() which sends MsgDropFlag to the tanks |
| 22:23:39 | BZFlag | some will require a server "restart" for the clients to handle it. |
| 22:23:44 | Chestal | in addition I still have the observer mode in my server |
| 22:23:44 | BZFlag | nice. |
| 22:23:51 | Chestal | but these things have to be redone in a clean way |
| 22:24:47 | Chestal | btw: my server crashed today |
| 22:24:59 | Chestal | these crashes are less frequent than they used to be |
| 22:25:02 | BZFlag | mine does fairly often. |
| 22:25:03 | Chestal | crashes aobu tonce a week now |
| 22:25:26 | BZFlag | I'm looking at adding playerid checks and discards. |
| 22:25:27 | Chestal | it's about the last bug that is remaining |
| 22:25:45 | Chestal | difficult to track, though |
| 22:26:00 | BZFlag | I have a script that just spawns in a while sleep 3 loop. |
| 22:26:25 | BZFlag | much better since the port reuse flag is set now. ;-) |
| 22:27:17 | BZFlag | in the old days, server crashes would hold the port locked for a long time... |
| 22:27:36 | Chestal | sadly, I had one occurence of a lost message lately :-( I sent a message via 'n' and it didn;t echo |
| 22:27:59 | |ks| | damn, that bot's a pain => |
| 22:28:00 | Chestal | it;s quite strange cause I was quite sure I eliminated this error (see my two network bug reports) |
| 22:28:09 | Chestal | ks: well, at least you're better than he is :-) |
| 22:28:27 | Chestal | bzflag: yes, I remember the port being blocked, that was annoying |
| 22:28:39 | |ks| | well, until I grabbed stealth, it had survived more duels with me than I had =) |
| 22:29:06 | Chestal | ks: yes, it ignores stealthed tanks completely |
| 22:29:23 | Chestal | ks: I thought this fair, you could say the bot is playing by radar only, it also ignores invisible bullets |
| 22:29:41 | Chestal | ks: I woudl have to check if a tank is visible within it's field of view |
| 22:30:07 | Chestal | ks: Paul is very hard to hit when you're not either very close or are using rico |
| 22:30:22 | |ks| | an idea: the bot checks radar or visible, but not both at once (like a real person, that must focus attention on one or the other) |
| 22:30:35 | |ks| | maybe switches focus back and forth periodicially |
| 22:30:56 | |ks| | yes, he is, and his shots are extremely accurate... |
| 22:30:58 | Chestal | ks: well, it;s not exactly using radar, it's just using the internal position, velocity and angular velocity data from each player |
| 22:31:05 | |ks| | should build in some margin of error |
| 22:31:06 | Chestal | ks: so it's data is very accurate |
| 22:31:45 | |ks| | exactly, but you could switch between which data it uses (radar-visible or in field of vision) |
| 22:31:52 | Chestal | ks: I guess you're lucky when you're lagged, cause it doesnt take that into consideration |
| 22:32:11 | |ks| | heh |
| 22:32:21 | |ks| | anyway, need to actually be productive... afk... |
| 22:32:26 | Chestal | ks: cu |
| 22:32:36 | Chestal | I have to go home, it's late again |