From 007 at freemail.at Sun Dec 2 13:08:04 2001 From: 007 at freemail.at (Kurt Siegl) Date: Wed Jan 12 00:50:35 2005 Subject: Virus Alert: Was Re: Re: [Netrek Clients] problems installing cow3 In-Reply-To: <0GNQ00AHSCCDTH@mxout2.netvision.net.il> References: <0GNQ00AHSCCDTH@mxout2.netvision.net.il> Message-ID: <200112021901.UAA20764@mx0.atnet.at> On Sunday 02 December 2001 19:50, Hayt wrote: > > Oh looks like this damm new virus with iframe attachments. It activates even in the preview window in an windows environment :-( Please be careful, when finding such a mail. Kurt -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@freemail.at Tel (ISDN): *(7225)7017 URL: http://members.aon.at/presents/siegl/kurt/ From nobelpassaglia at grupoip.com Tue Dec 4 08:41:30 2001 From: nobelpassaglia at grupoip.com (Nobel Clemar Passaglia) Date: Wed Jan 12 00:50:35 2005 Subject: [Netrek Clients] =?Windows-1252?Q?Fw:_Agradecer=E9_su_respuesta?= Message-ID: <006101c17cd1$fbda95a0$0100007f@nobel> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11496 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011204/6f350b10/attachment.jpe From rutabega20 at hotmail.com Sun Dec 9 02:58:57 2001 From: rutabega20 at hotmail.com (Gerard Lim) Date: Wed Jan 12 00:50:35 2005 Subject: [Netrek Clients] problems :( Message-ID: Hi Kurt, There's some minor problems with the win32 version 3pl3 of cow from the web site cow.netrek.org. The font name included with it is ntrk6x10.fon but it should be renamed to netrek.fon. The filename is hardcoded as netrek.fon in gnu_win32.c, so it's not loading the font included with it. Result is windows are misaligned, and text is "variable" width instead of fixed (very horrid looking). Also some other issues: portSwap isn't documented in netrekrc.example, so it won't work when you're behind a NAT. I think this should be there, and set to 'on' as default.... Lots of people are behind NATs these days... Do you think it would be a better idea just to rename netrekrc.example in the win32 distribution to just netrekrc? One less worry for newbies, IMO. One more thing :( pointer disappears when you're not in the tactical or galactic window, but reappears when you move back into the tactical or galactic. Don't know the cause of this yet. Gerard _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From rutabega20 at hotmail.com Sun Dec 9 03:10:02 2001 From: rutabega20 at hotmail.com (Gerard Lim) Date: Wed Jan 12 00:50:35 2005 Subject: [Netrek Clients] re: problems :( Message-ID: Hi Kurt, Sorry, I just noticed that even by renaming the fonts, while improving the window alignment and text issues vastly, it is still not a solution, as it cuts off the playerlist significantly as well as the message boxes (can only see 3/4 the playerlist as version 2.02). Gerard _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From elnacional at elnacional.net Sat Dec 8 20:48:22 2001 From: elnacional at elnacional.net (EL NACIONAL) Date: Wed Jan 12 00:50:35 2005 Subject: [Netrek Clients] sacarme inmediatamente Message-ID: <000001c180bb$23b3a520$d71620c8@nobel> DESUSCRIBANME INMEDIATAMEN Y RETIREN MI NOMBRE Y/O DIRECCION WEB Y DE E-MAIL. ACCIONARE JUDICIALMETE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011208/5a4de3e7/attachment.htm From nobelpassaglia at elnacional.net Sun Dec 9 09:46:37 2001 From: nobelpassaglia at elnacional.net (Nobel Clemar Passaglia) Date: Wed Jan 12 00:50:35 2005 Subject: [Netrek Clients] SACARME Message-ID: <000001c180c8$b71e10e0$441620c8@nobel> DEMANDO A USTEDES QUITARME DEL BUSCADOR YAHOO Y TODO MEDIO PUBLICO EN RED U OTROS, ASI COMO DE SU LISTA DE MAILING, PARA LO QUE NO HAN SIDO AUTORIZADOS, CON PERJUICIO DE PROMOVERLES ACCION PENAL POR LAS VIAS JURIDICAS PERTINENTES DOY A USTEDES EL PLAZO DE 24 HORAS PARA HACER EFECTIVA MI DEMANDA NOBEL CLEMAR PASSAGLIA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011209/a681da2e/attachment.html From ssheldon at sodablue.org Sun Dec 9 13:17:53 2001 From: ssheldon at sodablue.org (Steve Sheldon) Date: Wed Jan 12 00:50:36 2005 Subject: [Netrek Clients] SACARME In-Reply-To: <000001c180c8$b71e10e0$441620c8@nobel> Message-ID: <002a01c180e6$33e6c640$8400000a@inside.sodablue.com> Roughly translates to: I DEMAND you to TAKE OFF OF THE SEARCHING YAHOO AND ALL MEANS I PUBLISH IN NET OR OTHER, AS WELL AS OF THEIR LIST DE MAILING, FOR WHAT you/they have not BEEN AUTHORIZED, WITH DAMAGE OF PROMOTING THEM PENAL ACTION FOR THE PERTINENT JURIDICAL ROADS I GIVE you THE TERM OF 24 HOURS to MAKE EFFECTIVE MY DEMAND ------ I think this idiota is demanding he be unsubscribed from the mailing list since he just realized that it has nothing to do with the sale of Vanilla beans or Ted Turner merchandise. -----Original Message----- From: vanilla-clients-admin@us.netrek.org [mailto:vanilla-clients-admin@us.netrek.org] On Behalf Of Nobel Clemar Passaglia Sent: Sunday, December 09, 2001 9:47 AM To: vanilla-clients@us.netrek.org Subject: [Netrek Clients] SACARME DEMANDO A USTEDES QUITARME DEL BUSCADOR YAHOO Y TODO MEDIO PUBLICO EN RED U OTROS, ASI COMO DE SU LISTA DE MAILING, PARA LO QUE NO HAN SIDO AUTORIZADOS, CON PERJUICIO DE PROMOVERLES ACCION PENAL POR LAS VIAS JURIDICAS PERTINENTES DOY A USTEDES EL PLAZO DE 24 HORAS PARA HACER EFECTIVA MI DEMANDA NOBEL CLEMAR PASSAGLIA From vanilla-devel at us.netrek.org Thu Dec 6 15:47:55 2001 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:51:36 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200112062147.fB6Llti30622@swashbuckler.real-time.com> Date: Thursday December 6, 2001 @ 15:47 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv30619 Modified Files: PROJECTS Log Message: **************************************** Index: Vanilla/PROJECTS diff -u Vanilla/PROJECTS:1.90 Vanilla/PROJECTS:1.91 --- Vanilla/PROJECTS:1.90 Mon Oct 29 15:43:06 2001 +++ Vanilla/PROJECTS Thu Dec 6 15:47:55 2001 @@ -1,5 +1,5 @@ -$Id: PROJECTS,v 1.90 2001/10/29 21:43:06 cameron Exp $ +$Id: PROJECTS,v 1.91 2001/12/06 21:47:55 cameron Exp $ List of things to do in the future @@ -128,6 +128,9 @@ obs<->player switching and non-contiguous INL slot PROJECT entries. First crack at it assigned to Carlos V. + - cloaked position randomisation, do it once per turn rather than + once per client per turn, in order to ensure that any cooperating + robots do not get a tactical advantage. INL robot issues following testing with Tom Holub From vanilla-devel at us.netrek.org Thu Dec 6 21:58:57 2001 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:51:36 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200112070358.fB73wvW30747@swashbuckler.real-time.com> Date: Thursday December 6, 2001 @ 21:58 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv30744 Modified Files: ChangeLog Log Message: minor fixes to handlers **************************************** Index: Vanilla/ChangeLog diff -u Vanilla/ChangeLog:1.126 Vanilla/ChangeLog:1.127 --- Vanilla/ChangeLog:1.126 Wed Oct 10 02:36:52 2001 +++ Vanilla/ChangeLog Thu Dec 6 21:58:57 2001 @@ -1,3 +1,13 @@ +Fri Dec 7 14:55:21 2001 James Cameron + + * ntserv/socket.c: fix spacing to be consistent, added NULL + handler for when FEATURE_PACKET not defined. + +Sun Nov 11 23:00:00 2001 Darryl Palmer Jr + + * ntserv/socket.c: when PING is not defined, all handlers will be + off by one. + Wed Oct 10 17:29:13 2001 James Cameron * xsg/redraw.c: added '#include ' to fix compilation @@ -1317,4 +1327,4 @@ update_sys_defaults in updateMessages to a more appropriate location - updateClient in socket.c. - $Id: ChangeLog,v 1.126 2001/10/10 07:36:52 cameron Exp $ + $Id: ChangeLog,v 1.127 2001/12/07 03:58:57 cameron Exp $ From vanilla-devel at us.netrek.org Thu Dec 6 21:58:57 2001 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:51:36 2005 Subject: [Vanilla Devel] CVS update: Vanilla/ntserv Message-ID: <200112070358.fB73wvZ30752@swashbuckler.real-time.com> Date: Thursday December 6, 2001 @ 21:58 Author: cameron Update of /home/netrek/cvsroot/Vanilla/ntserv In directory swashbuckler.real-time.com:/var/tmp/cvs-serv30744/ntserv Modified Files: socket.c Log Message: minor fixes to handlers **************************************** Index: Vanilla/ntserv/socket.c diff -u Vanilla/ntserv/socket.c:1.31 Vanilla/ntserv/socket.c:1.32 --- Vanilla/ntserv/socket.c:1.31 Wed Oct 10 02:36:52 2001 +++ Vanilla/ntserv/socket.c Thu Dec 6 21:58:57 2001 @@ -1,4 +1,4 @@ -/* $Id: socket.c,v 1.31 2001/10/10 07:36:52 cameron Exp $ +/* $Id: socket.c,v 1.32 2001/12/07 03:58:57 cameron Exp $ */ /* @@ -142,7 +142,7 @@ }; struct packet_handler handlers[] = { - { 0, NULL}, /* record 0 */ + { 0, NULL }, /* record 0 */ { sizeof(struct mesg_cpacket), handleMessageReq }, /* CP_MESSAGE */ { sizeof(struct speed_cpacket), handleSpeedReq }, /* CP_SPEED */ { sizeof(struct dir_cpacket), handleDirReq }, /* CP_DIRECTION */ @@ -182,38 +182,42 @@ #ifdef RSA { sizeof(struct rsa_key_cpacket), handleRSAKey }, /* CP_RSA_KEY */ #else - { 0, NULL}, /* 37 */ + { 0, NULL }, /* 37 */ #endif - { 0, NULL}, /* 38 */ - { 0, NULL}, /* 39 */ - { 0, NULL}, /* 40 */ - { 0, NULL}, /* 41 */ + { 0, NULL }, /* 38 */ + { 0, NULL }, /* 39 */ + { 0, NULL }, /* 40 */ + { 0, NULL }, /* 41 */ #ifdef PING { sizeof(struct ping_cpacket), handlePingResponse }, /* CP_PING_RESPONSE*/ +#else + { 0, NULL }, /* 42 */ #endif { sizeof(struct shortreq_cpacket), handleShortReq }, /* CP_S_REQ */ { sizeof(struct threshold_cpacket), handleThresh }, /* CP_S_THRS */ { -1, handleSMessageReq}, /* CP_S_MESSAGE */ - {0, NULL}, /* 46 */ - {0, NULL}, /* 47 */ - {0, NULL}, /* 48 */ - {0, NULL}, /* 49 */ + { 0, NULL }, /* 46 */ + { 0, NULL }, /* 47 */ + { 0, NULL }, /* 48 */ + { 0, NULL }, /* 49 */ #if defined(BASEPRACTICE) || defined(NEWBIESERVER) - {sizeof(struct oggv_cpacket), handleOggV}, /* CP_OGGV */ + { sizeof(struct oggv_cpacket), handleOggV }, /* CP_OGGV */ #else - {0, NULL}, /* 50 */ + { 0, NULL }, /* 50 */ #endif - {0, NULL}, /* 51 */ - {0, NULL}, /* 52 */ - {0, NULL}, /* 53 */ - {0, NULL}, /* 54 */ - {0, NULL}, /* 55 */ - {0, NULL}, /* 56 */ - {0, NULL}, /* 57 */ - {0, NULL}, /* 58 */ - {0, NULL}, /* 59 */ + { 0, NULL }, /* 51 */ + { 0, NULL }, /* 52 */ + { 0, NULL }, /* 53 */ + { 0, NULL }, /* 54 */ + { 0, NULL }, /* 55 */ + { 0, NULL }, /* 56 */ + { 0, NULL }, /* 57 */ + { 0, NULL }, /* 58 */ + { 0, NULL }, /* 59 */ #ifdef FEATURE_PACKETS - {sizeof(struct feature_cpacket), handleFeature }, /* CP_FEATURE */ + { sizeof(struct feature_cpacket), handleFeature }, /* CP_FEATURE */ +#else + { 0, NULL }, /* 60 */ #endif }; From vanilla-devel at us.netrek.org Fri Dec 7 00:05:06 2001 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:51:36 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200112070605.fB7656g30854@swashbuckler.real-time.com> Date: Friday December 7, 2001 @ 0:05 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv30851 Modified Files: PROJECTS Log Message: withdrawal **************************************** Index: Vanilla/PROJECTS diff -u Vanilla/PROJECTS:1.91 Vanilla/PROJECTS:1.92 --- Vanilla/PROJECTS:1.91 Thu Dec 6 15:47:55 2001 +++ Vanilla/PROJECTS Fri Dec 7 00:05:06 2001 @@ -1,5 +1,5 @@ -$Id: PROJECTS,v 1.91 2001/12/06 21:47:55 cameron Exp $ +$Id: PROJECTS,v 1.92 2001/12/07 06:05:06 cameron Exp $ List of things to do in the future @@ -127,10 +127,6 @@ Cleaning up the observer code is a prerequisite for obs<->player switching and non-contiguous INL slot PROJECT entries. First crack at it assigned to Carlos V. - - - cloaked position randomisation, do it once per turn rather than - once per client per turn, in order to ensure that any cooperating - robots do not get a tactical advantage. INL robot issues following testing with Tom Holub From quozl at us.netrek.org Sat Dec 1 22:40:42 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:42 2005 Subject: [Vanilla List] Rom obs prevented logins during Kli/Ori game Message-ID: <20011202154042.B32243@us.netrek.org> Reported on continuum then, two Romulan observer slots seemingly the cause of team selection window showing 6 vs 2, but new players could not log in, and yet t-mode was still present. Any ideas? I can't see how things can get so confused in the server. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From hawks at night-hawks.com Sun Dec 2 16:35:44 2001 From: hawks at night-hawks.com (hawks) Date: Wed Jan 12 00:52:42 2005 Subject: [Vanilla List] new BRM-Hadley 2.4 client port Message-ID: I have successfully compiled the BRMH-2.4 client source under MacOSX running with XDarwin. What do I need to do to get the client blessed? Alan Palmer hawks@night-hawks.com From doosh at inl.org Mon Dec 3 15:24:37 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:42 2005 Subject: CVS? (Re: [Vanilla List] any growth on this?) In-Reply-To: <200111270925.AA7930020@sodablue.org>; from ssheldon@sodablue.org on Tue, Nov 27, 2001 at 09:25:56AM -0700 References: <200111270925.AA7930020@sodablue.org> Message-ID: <20011203132437.A80850@inl.org> On Tue, Nov 27, 2001 at 09:25:56AM -0700, Steve Sheldon wrote: > > I don't think Sourceforge is going away yet. There is some concern as VA Linux(or VA Research or VA Software or whatever they are calling themselves these days) is flushing money down toilets faster than they can find it. VA Linux has $100 million in the bank; they lost $8 million last quarter. There's not much danger there. -Tom From ssheldon at sodablue.org Tue Dec 4 13:28:05 2001 From: ssheldon at sodablue.org (Steve Sheldon) Date: Wed Jan 12 00:52:42 2005 Subject: [Vanilla List] any growth on this? Message-ID: <200112041228.AA153616554@sodablue.org> From: Kurt Siegl <007@freemail.at> > >So lets agree on the syntax of this defaults file for a common base and grep >all information for that out of the code. Additional special comments within >the code to support it should not be a problem at all. Years ago I swear we started to do something like this with COW-lite. Maybe Jeff Nelson was initiating it. Can't remember the details now. But anyway. I was thinking of embedding XML tags into the comments to better describe these defaults. Sort of like the way Javadocs or C# works with it's self-documenting code. From michaelwyatt at PunkAss.com Tue Dec 4 14:23:54 2001 From: michaelwyatt at PunkAss.com (Michael Wyatt) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] any growth on this? References: Message-ID: <001901c17d01$9991c0f0$0200a8c0@mike2k> I think that I've got the setup program fixed. It seems that when the Inno Setup program compresses the pixmaps it corrupts them. I copied the pixmaps in their original tgz file format with the setup program, and then included a uncompression program to unzip them on the target end. I think I've got almost all of the bugs worked out and I'm ready to upload it to a location for testing. ftp.netrek.org ? Are there any other clients that could use this 'seamless' installation? As for Linux, I found a few setup programs on www.downloads.com but none seem to work. (Rust and Noodle) RPM is the only was to go in doing this. I know that Red Hat & Mandrake support RPMs, but do the other main distributors support them? Rust is an GUI RPM creator, but I had no luck compiling. The Noodle installer is a PERL program that looks promising, but I can get the files in the correct format for the program. >Very nice. I think you have all that is needed for an rc editor >right there. Any point in contineuing with writing another? :) Do want me to continue developing in this area? From quozl at us.netrek.org Tue Dec 4 15:48:30 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] any growth on this? In-Reply-To: <001901c17d01$9991c0f0$0200a8c0@mike2k>; from michaelwyatt@punkass.com on Tue, Dec 04, 2001 at 02:23:54PM -0600 References: <001901c17d01$9991c0f0$0200a8c0@mike2k> Message-ID: <20011205084830.V32243@us.netrek.org> G'day Michael, That's excellent news. Yes, ftp.netrek.org's incoming directory is the place to put it. Stick it there then tell the mailing list, and someone will take the file and put it where it belongs. Kurt, I would hope. Then we can try testing it. I can trot down to the outback internet cafe down the road and try installing it. Could you also describe the process you used to make the package, and upload this into the COW CVS as a file? (Or mail it to one of us so that we can upload it). For your package to last over time, even after you have gone, we need to be able to point people to how to rebuild it for a new version. We would of course try contacting you first. Efficiency is getting the right man for the job. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Tue Dec 4 23:42:13 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <200105072357.f47NvMK15890@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Mon, May 07, 2001 at 07:57:22PM -0400 References: <20010507161024.F21375@us.netrek.org> <200105072357.f47NvMK15890@denali.ccs.neu.edu> Message-ID: <20011205164213.B32243@us.netrek.org> Jeff wrote back in May something that summarises well what I am aiming for here ... I commend it to the new members of the list ... On Mon, May 07, 2001 at 07:57:22PM -0400, Jeffrey Nowakowski wrote: > The really important project is to get netrek as a single download > that includes a spiffy client with a tutorial. The download should > include the server so the user can play without connecting to the > network. It should run under 95/98/NT. It should include an option > for a small sized map that lets a small group of office workers play > and have fun. Task list and progress: - single download spiffy client, happening, beta done, - test spiffy client on 95, 98, and NT, yet to start, - tutorial, yet to start, - server in download, needs porting work, no fork() to dup() fd's, - server with small map, yet to start, low priority. Let's just do it. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From Darryl_Palmer_Jr at acm.org Wed Dec 5 08:00:04 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205164213.B32243@us.netrek.org> Message-ID: I remember that was one goal of my porting the server code to work on NT. My goals have slightly increased and I wanted to also make it possible for people to write their own robots, and maybe steal some of the thunder from robo-soccer. I have switched to rewriting the server in Java. It still remains to be seen if the server can realistically handle 16+ clients, but the code currently isn't really that optimized and it will have to wait until January or so when I can test it. Here is a list of some discussion that I had with Sheldon: -----Original Message----- From: Darryl Palmer Jr [mailto:Darryl_Palmer_Jr@acm.org] Sent: Sunday, December 02, 2001 12:12 PM To: Steve Sheldon Subject: RE: [Vanilla List] Server questions Where it is right now is not that far. It is able to accept the incoming connections (I've tested it up to two cliens). It is able to send a hard coded Message of the Day, plus emulate a queue. It is able to send the first update messages to get the player to the login screen, but it currently doesn't support that. The way that I was looking at for versions is below: Version Release Feature 0.4 12/01 No queue support. No player database support. No UDP support. No short packet support. No feature support. (ALL features disabled) Players are able to login as guest. Players are able to select teams. Add support for custom Motd. Limited functionality, players are just able to fly around galaxy and send messages. 0.7 12/01 Add Weapon support. Add docking support. Add feature support. Add support for custom Features file. Add support for misc. commands such as refitting and repairing. Add queue support. Add database support. This function should appear as a fully functional Bronco server without voting support. 0.9 1/02 Add support for UDP. Add support for short packets. Add support for Ghostbusted clients. Add RSA support. 1.0 1/02 Add support for other server types. INL/Hockey/Practice/Newbie 2.0 ??? Add support for user designed robots. Add support for scenario training. -----Original Message----- From: Darryl Palmer [mailto:Darryl_Palmer_Jr@acm.org] Sent: Thursday, September 27, 2001 2:01 AM To: Steve Sheldon Subject: RE: [Vanilla List] Server questions I was going to take up doing the NT port again, but then I stopped myself. Orgininally the windows port of netrek was to increase the number of people running a server. Ideally one could also bundle the client with the server so that individuals could practice in a nice "friendly" environment with the buddies or just with automated robots. Well, then I was thinking about what if it was in Java instead. Yeah java is slow, java is inefficient but what exactly is the target audience for the users. It doesn't matter that the server may require more resources than an optimized server, such as the current Vanilla server or a Windows port, because the user will be using this server intermittently not to setup a permanent game server for the metaserver. For the same reason the user will probably not care that much for the increased resources that the "client" portion also requires. Now the question is what is the gain? Well we can support more people using the software than just Windows users. We can also do something a little bit cooler. What if we had the capability of not only including bots in the server but also allow people to write their own bots? Writing a netrek bot, whether it is a single player or is an entire team, must be more fun than that robosoccer stuff. And if it is easy enough we might even be able to have a Robotic Netrek League of some sort. So if the idea now is for people to write their own robots, which language should it be in? And which technology supports dynamically loading classes/objects while having strict security and restrictions on this classes. It came down to either Corba, COM(+), or Java. Java is the outright winner because most newbie programmers will be able to write a Java program versus the other two. I was trying to figure out what should a valid program look like. And I was thinking it should have a format similar to how JUnit functions. Something like: class myAI extends AIRobot { void setupRules() { AIRules rules = new AIRules(); rules.addRule(new PlanetTake("takeUndefendedPlanet")); rules.addRule(new PlanetTake("cloakedPlanetTake")); rules.addRule(new runnerScummer("buttTorpLikeHell")); rules.addRule(new runnerScummer("runLikeCrazy")); rules.addRule(new runnerScummer("patrolCore")); rules.run(); } class runnerScummer extends AIRule { void buttTorpLikeHell() { Ship nearestEnemy = findNearestEnemy(); if( distance(nearestEnemy) < 5000) { Direction shipBearing = bearing(nearestEnemy); // Rotate bearing 180 degress so we run away from the ship. Direction newShipDirection = rotateDirection(shipBearing, 180); setDesiredDirection(newShipDirection); setDesiredSpeed(getMaxShipSpeed()); if(fuel() > 5000) { fireTorpedo(shipBearing); } } } } } The rules should probably be selected accourding to some ruleSelector that decides which rule should be followed according to either random probababily or mixed also with some weighted evaluator. Hmm, does this sound intersted or just rants from a crazy person. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of James Cameron Sent: Tuesday, December 04, 2001 11:42 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures Jeff wrote back in May something that summarises well what I am aiming for here ... I commend it to the new members of the list ... On Mon, May 07, 2001 at 07:57:22PM -0400, Jeffrey Nowakowski wrote: > The really important project is to get netrek as a single download > that includes a spiffy client with a tutorial. The download should > include the server so the user can play without connecting to the > network. It should run under 95/98/NT. It should include an option > for a small sized map that lets a small group of office workers play > and have fun. Task list and progress: - single download spiffy client, happening, beta done, - test spiffy client on 95, 98, and NT, yet to start, - tutorial, yet to start, - server in download, needs porting work, no fork() to dup() fd's, - server with small map, yet to start, low priority. Let's just do it. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/f462953f/smime.bin From karthik at karthik.com Wed Dec 5 09:44:46 2001 From: karthik at karthik.com (Karthik Arumugham) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: I'm sure a lot of people will disagree with me on this, but I still don't see the point of a Windows server port. We have a shortage of players now, not a shortage of servers. Suddenly having dozens of poorly connected Windows servers show up on the metaservers won't help things any... Of course, it's great that you want to do something to help the Netrek community. It beats having nobody working on any Netrek-related code at all. On Wed, 5 Dec 2001, Darryl Palmer Jr wrote: > I remember that was one goal of my porting the server code to work on NT. > My goals have slightly increased and I wanted to also make it possible for > people to write their own robots, and maybe steal some of the thunder from > robo-soccer. I have switched to rewriting the server in Java. It still > remains to be seen if the server can realistically handle 16+ clients, but > the code currently isn't really that optimized and it will have to wait > until January or so when I can test it. > > Here is a list of some discussion that I had with Sheldon: > > -----Original Message----- > From: Darryl Palmer Jr [mailto:Darryl_Palmer_Jr@acm.org] > Sent: Sunday, December 02, 2001 12:12 PM > To: Steve Sheldon > Subject: RE: [Vanilla List] Server questions > > > Where it is right now is not that far. It is able to accept the incoming > connections (I've tested it up to two cliens). It is able to send a hard > coded Message of the Day, plus emulate a queue. It is able to send the > first update messages to get the player to the login screen, but it > currently doesn't support that. The way that I was looking at for > versions is below: > > Version Release Feature > 0.4 12/01 No queue support. > No player database support. > No UDP support. > No short packet support. > No feature support. (ALL features disabled) > Players are able to login as guest. > Players are able to select teams. > Add support for custom Motd. > Limited functionality, players are just able to fly around > galaxy and send messages. > > 0.7 12/01 Add Weapon support. > Add docking support. > Add feature support. > Add support for custom Features file. > Add support for misc. commands such as refitting and repairing. > Add queue support. > Add database support. > This function should appear as a fully functional Bronco server > without voting support. > > 0.9 1/02 Add support for UDP. > Add support for short packets. > Add support for Ghostbusted clients. > Add RSA support. > > 1.0 1/02 Add support for other server types. INL/Hockey/Practice/Newbie > > 2.0 ??? Add support for user designed robots. > Add support for scenario training. > > -----Original Message----- > From: Darryl Palmer [mailto:Darryl_Palmer_Jr@acm.org] > Sent: Thursday, September 27, 2001 2:01 AM > To: Steve Sheldon > Subject: RE: [Vanilla List] Server questions > > > I was going to take up doing the NT port again, but then I stopped myself. > Orgininally the windows port of netrek was to increase the number of > people running a server. Ideally one could also bundle the client with > the server so that individuals could practice in a nice "friendly" > environment with the buddies or just with automated robots. > > Well, then I was thinking about what if it was in Java instead. Yeah java > is slow, java is inefficient but what exactly is the target audience for > the users. It doesn't matter that the server may require more resources > than an optimized server, such as the current Vanilla server or a Windows > port, because the user will be using this server intermittently not to > setup a permanent game server for the metaserver. For the same reason the > user will probably not care that much for the increased resources that the > "client" portion also requires. Now the question is what is the gain? > Well we can support more people using the software than just Windows > users. We can also do something a little bit cooler. What if we had the > capability of not only including bots in the server but also allow people > to write their own bots? Writing a netrek bot, whether it is a single > player or is an entire team, must be more fun than that robosoccer stuff. > And if it is easy enough we might even be able to have a Robotic Netrek > League of some sort. So if the idea now is for people to write their own > robots, which language should it be in? And which technology supports > dynamically loading classes/objects while having strict security and > restrictions on this classes. It came down to either Corba, COM(+), or > Java. Java is the outright winner because most newbie programmers will be > able to write a Java program versus the other two. > > I was trying to figure out what should a valid program look like. And I > was thinking it should have a format similar to how JUnit functions. > Something like: > > class myAI extends AIRobot > { > > void setupRules() > { > AIRules rules = new AIRules(); > > rules.addRule(new PlanetTake("takeUndefendedPlanet")); > rules.addRule(new PlanetTake("cloakedPlanetTake")); > > rules.addRule(new runnerScummer("buttTorpLikeHell")); > rules.addRule(new runnerScummer("runLikeCrazy")); > rules.addRule(new runnerScummer("patrolCore")); > > rules.run(); > } > > > class runnerScummer extends AIRule > { > void buttTorpLikeHell() > { > Ship nearestEnemy = findNearestEnemy(); > > if( distance(nearestEnemy) < 5000) > { > Direction shipBearing = bearing(nearestEnemy); > > // Rotate bearing 180 degress so we run away from the ship. > Direction newShipDirection = rotateDirection(shipBearing, 180); > > setDesiredDirection(newShipDirection); > > setDesiredSpeed(getMaxShipSpeed()); > > if(fuel() > 5000) > { > fireTorpedo(shipBearing); > } > } > > } > } > } > > The rules should probably be selected accourding to some ruleSelector that > decides which rule should be followed according to either random > probababily or mixed also with some weighted evaluator. > > > Hmm, does this sound intersted or just rants from a crazy person. > > > Darryl > > -----Original Message----- > From: vanilla-list-admin@us.netrek.org > [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of James Cameron > Sent: Tuesday, December 04, 2001 11:42 PM > To: vanilla-list@us.netrek.org > Subject: Re: [Vanilla List] Growing Netrek - Measures > > > Jeff wrote back in May something that summarises well what I am aiming > for here ... I commend it to the new members of the list ... > > On Mon, May 07, 2001 at 07:57:22PM -0400, Jeffrey Nowakowski wrote: > > The really important project is to get netrek as a single download > > that includes a spiffy client with a tutorial. The download should > > include the server so the user can play without connecting to the > > network. It should run under 95/98/NT. It should include an option > > for a small sized map that lets a small group of office workers play > > and have fun. > > Task list and progress: > > - single download spiffy client, happening, beta done, > - test spiffy client on 95, 98, and NT, yet to start, > - tutorial, yet to start, > - server in download, needs porting work, no fork() to dup() fd's, > - server with small map, yet to start, low priority. > > Let's just do it. ;-) > > -- > James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From doosh at inl.org Wed Dec 5 11:09:51 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from karthik@karthik.com on Wed, Dec 05, 2001 at 10:44:46AM -0500 References:

Message-ID: <20011205090951.A37505@inl.org> On Wed, Dec 05, 2001 at 10:44:46AM -0500, Karthik Arumugham wrote: > I'm sure a lot of people will disagree with me on this, but I still don't > see the point of a Windows server port. We need a stand-alone server with robots that winweenies can learn on. -Tom From Darryl_Palmer_Jr at acm.org Wed Dec 5 13:07:07 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: That is the reason why I stopped the Windows port. The key feature that is necessary is that people can play in a more "friendly" environment by running their own personal servers and invite their buddies on. It would be nice if the server also had the capability of having training "scenarios" where a player can practice taking planets or dogfighting, or ogging, not just a base practice server. Which in itself is not that useful because it requires most people to attain a descent rank even before they can base on a public server. I am thinking that people can use this server and see what netrek is about even before EVER logging onto a public server. The second issue was one of getting more weenies to write robots for netrek and maybe have robo-netrek as an alternative for engineer's week activities here in the US instead of robo-soccer. Personally I hate Netrek and the INL, maybe because I was a member of the team that gave Jitesh's team the fastest geno time on record. My plan is to create an all robot team that can kick those INL weenies. This is just one step in my overall plan. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Karthik Arumugham Sent: Wednesday, December 05, 2001 9:45 AM To: vanilla-list@us.netrek.org Subject: RE: [Vanilla List] Growing Netrek - Measures I'm sure a lot of people will disagree with me on this, but I still don't see the point of a Windows server port. We have a shortage of players now, not a shortage of servers. Suddenly having dozens of poorly connected Windows servers show up on the metaservers won't help things any... Of course, it's great that you want to do something to help the Netrek community. It beats having nobody working on any Netrek-related code at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/ceba1f83/smime.bin From karthik at karthik.com Wed Dec 5 13:53:35 2001 From: karthik at karthik.com (Karthik Arumugham) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: On Wed, 5 Dec 2001, Darryl Palmer Jr wrote: > Personally I hate Netrek and the INL, maybe because I was a member of the > team that gave Jitesh's team the fastest geno time on record. My plan is > to create an all robot team that can kick those INL weenies. This is just > one step in my overall plan. A bot that can out-dogfight humans most of the time? Possible. A bot that can out-clue a human and actually win the game? Doubtful. From ahn at vec.wfubmc.edu Wed Dec 5 14:24:26 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from karthik@karthik.com on Wed, Dec 05, 2001 at 10:44:46AM -0500 References:

Message-ID: <20011205152426.A169415@cecum.vec.wfubmc.edu> On Wed, Dec 05, 2001 at 10:44:46AM -0500, Karthik Arumugham wrote: > I'm sure a lot of people will disagree with me on this, but I still don't > see the point of a Windows server port. We have a shortage of players now, > not a shortage of servers. Suddenly having dozens of poorly connected > Windows servers show up on the metaservers won't help things any... I agree, mostly. I think better time is spent improving the client. The idea of a stand-alone server that runs on the client machine is nice, but we can get most of any benefits from that setup by having a real, dedicated newbie server with training bots. While I commend Darryl and others for trying to do a complete Java rewrite, I think that those "reimplementations" will have little to no benefit in improving the netrek player base. Regardless of the technical differences between Java and C/C++, any Java port will require substantial man-hours of implementation and testing without the help of most of our existing developer base that, I would guess, will continue to work on Vanilla, COW and other software. I really wish we could try to consolidate our development efforts. We merged the INL server functionality into Vanilla, so the server dev is pretty well organized. But there are simply too many clients with people forking off in different directions. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From zu22 at andrew.cmu.edu Wed Dec 5 14:30:34 2001 From: zu22 at andrew.cmu.edu (Zachary Uram) Date: Wed Jan 12 00:52:43 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: I have now created a Source Forge account. My login is "zinpgh" With all the discussion in past weeks I have lost site of what I should be doing to help out. Can you tell me exactly what I can do? I know how to login to Vanilla through anonymous CVS but have never logged in for COW. In Linux I usually play with BRMH client. And in Windoze I play with Netrek 1999/2000 client. Zach zu22@andrew.cmu.edu "Blessed are those who have not seen and yet have faith." - John 20:29 From zu22 at andrew.cmu.edu Wed Dec 5 14:41:43 2001 From: zu22 at andrew.cmu.edu (Zachary Uram) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: How do I add myself as a member? I see no option on the SF page that allow sme to join this project: http://sourceforge.net/projects/netrek/ Zach zu22@andrew.cmu.edu "Blessed are those who have not seen and yet have faith." - John 20:29 From jeffno at ccs.neu.edu Wed Dec 5 15:42:04 2001 From: jeffno at ccs.neu.edu (Jeffrey Nowakowski) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205152426.A169415@cecum.vec.wfubmc.edu> from "Dave Ahn" at Dec 05, 2001 03:24:26 PM Message-ID: <20011205214205.438A3172CF@denali.ccs.neu.edu> Dave Ahn wrote: > > I agree, mostly. I think better time is spent improving the client. The > idea of a stand-alone server that runs on the client machine is nice, but > we can get most of any benefits from that setup by having a real, dedicated > newbie server with training bots. While I commend Darryl and others for > trying to do a complete Java rewrite, I think that those "reimplementations" > will have little to no benefit in improving the netrek player base. I disagree. There are too many people with bad connections out there. You don't want the user's first experience to be a bad one due to a flakey connection. It's much better to have a local tutorial server that is rock solid. Any commercially successful game has a localized version. > Regardless of the technical differences between Java and C/C++, any Java > port will require substantial man-hours of implementation and testing > without the help of most of our existing developer base that, I would guess, > will continue to work on Vanilla, COW and other software. Going to Java is debatable. On the one hand the C code is well established, but it is also a mess. C is also harder to maintain. I'm willing to bet there are more converted C++ programmers on this list than you think. > I really wish we could try to consolidate our development efforts. We merged > the INL server functionality into Vanilla, so the server dev is pretty well > organized. But there are simply too many clients with people forking off in > different directions. I've been saying this for years. It's unlikely to happen unless somebody with enough sway can get everybody to agree on a clear vision. -Jeff From mark at mark.mielke.cc Wed Dec 5 17:18:51 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from karthik@karthik.com on Wed, Dec 05, 2001 at 02:53:35PM -0500 References:

Message-ID: <20011205181851.A11036@mark.mielke.cc> On Wed, Dec 05, 2001 at 02:53:35PM -0500, Karthik Arumugham wrote: > On Wed, 5 Dec 2001, Darryl Palmer Jr wrote: > > Personally I hate Netrek and the INL, maybe because I was a member of the > > team that gave Jitesh's team the fastest geno time on record. My plan is > > to create an all robot team that can kick those INL weenies. This is just > > one step in my overall plan. > A bot that can out-dogfight humans most of the time? Possible. A bot that > can out-clue a human and actually win the game? Doubtful. Why not? :-) *Especially* since, at least theoretically, the bots could work as a single unit with relatively instant response times. Legs and arms of the same body that destroys the opposition. As the stupidest example, 'clued' humans will attempt to phaser the cloaker to obtain their exact co-ordinates, most especially during LPS. How much fuel is wasted with 2 or 3 'clued' humans all trying to make their best guess, all possibly missing? If the bots were in communication with each other, one bot could be assigned the area covered by the radius of the enemy ship at all possibly points along its phaser line, with a preference offered for the ship with the most powerful phaser, at the least range, at the most probable location that we suspect the cloaker is at. (Interpolate his co-ordinates given the approximatings offered by the server every few updates) This would also apply to base oggs. Usually, locating the ogger is half the battle. Why waste half your fuel on 6 incoming cloakers, just trying to find them, when a co-ordinated game of search and destroy would be so much more practical? Also, the computer doesn't blink when its eyelids get a little dry. No more "we got 6 of the oggers, but the 7th got through." Once found, the first one to see him could notify the others, possibly before the others finish receiving their next update. Other possibilities include "I'm going to plasma him, press him away from you and phaser him, and torp him so that we can distract him. The *instant* he phasers you, I'll launch the plasma." One sorta strange slip-up I've seen in the code when I last examined things, is that "detOwn" could be performed on a torp-by-torp basis. The GUI does not give you this level of control. Any torps that are guaranteed to not hit the ogger, should be detted immediately, so that we can lengthen our current salvo during the next daemon update. Co-ordinated planet takes? The bots could communicate their cloaked location to each other, which is more information than the enemy has. "I'm at x,y current heading 270" or "I'm orbitting planet z, current heading 270", potentially including "turning towards 165". This way, the other bots could det only if the torps would actually hit their partner bot. Also, the dets could be organized, such that if two bots were guarding at that instant, they could alternate, taking turns doing the detting. Reactions among several entities, co-ordinated to within a 1/10 of a second of each other? Not being able to take on an INL team? hmm.... Just some examples of how *theoretically* a bot team could be significantly better than a human team. Certain other aids are usually not as useful to clued players (such as having the clients remember the resources that the planet had before the other team stole it back, or having it estimate an army count based on how many armies we suspect were beamed up / down, and how many times, and at what rate, we suspect it popped at. Usually at least one player on a clued team is able to remember this, and a recently taken planet that isn't orbitted very soon after is pretty rare. But then again... if you know what resources it has, and you can predict (with some degree of accuracy) the number of armies it has on it... why waste time sending a scout, when you could be taking another planet, or ogging the other with all the kills instead? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From ssheldon at sodablue.org Wed Dec 5 17:25:56 2001 From: ssheldon at sodablue.org (Steve Sheldon) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures Message-ID: <200112051625.AA52494560@sodablue.org> From: jeffno@ccs.neu.edu (Jeffrey Nowakowski) >Dave Ahn wrote: >> Regardless of the technical differences between Java and C/C++, any Java >> port will require substantial man-hours of implementation and testing >> without the help of most of our existing developer base that, I would guess, >> will continue to work on Vanilla, COW and other software. > >Going to Java is debatable. On the one hand the C code is well >established, but it is also a mess. C is also harder to maintain. >I'm willing to bet there are more converted C++ programmers on this >list than you think. Is the future of development in procedural C calling arcane libraries with an arcane architecture, using arcane graphics? Is that what people are working on today in their jobs? Is that what people are learning in the schools? I don't think so. So it boils down to what do you want to work on. For me, I'm interested in experimenting with software that will help teach me new concepts I can utilize elsewhere. I had this discussion with Jim Ivey a few months ago over beer at a local pub. Now the two of us were talking about utilizing the .NET framework to build a new and improved Netrek. We sort of roughly outlined the types of things you could do today because of the availability of the new technologies. Better integrated into web sites, easier to extend clients and servers, so forth. The same is also true of Java or any other newer dev environment. Why? Well because it's cool. That's why! What more reason is there? Yeah, it's a lot of work, and I haven't convinced myself that it would be worthwhile. But I think it would be fun. There is also a realization that in order to be somewhat successful it would have to interoperate with the established systems. That's not impossible, simply a question of maintaining compatibility at the network layer. >> I really wish we could try to consolidate our development efforts. We merged >> the INL server functionality into Vanilla, so the server dev is pretty well >> organized. But there are simply too many clients with people forking off in >> different directions. > >I've been saying this for years. It's unlikely to happen unless >somebody with enough sway can get everybody to agree on a clear >vision. One of the advantages of changing directions like this is the invigoration and life it would bring. If you are on the bleeding edge of technology, what interest might that drive? And yes I know, it's been tried before. But like I said, maintaining compatibility is key. The Java client written by Temple is still in use by a few people, even though it was never 100% finished. I'm more of a complainer than a leader, but when I mentioned this months ago on r.g.n. I did receive some emails expressing interest. I suspect it would probably get some new blood as well, I have mentioned it to friends at work as well. Some of them have played Netrek in the past, others have never seen the game but expressed interest anyway. Well those are my thoughts, and I'm sure they don't help anyone because what I talk of doesn't fit into anybody elses grand scheme on this list.(Because I'm one of the few who doesn't have an anti-MS bias) So that just further forks things. Ohwell, I've got to finish my GIAC certification practical right now, but come January I'm going to think about this a lot more. I'll shut up now. From Darryl_Palmer_Jr at acm.org Wed Dec 5 18:23:10 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205152426.A169415@cecum.vec.wfubmc.edu> Message-ID: If the goal is to increase the netrek player base, then isn't this a "marketing" issue? From the Netrek Frequently Offered Clever Suggestion list it appears that any recommendation outstide of the inner "clue" circle is immediately shot down. So if there are no major features or enhancements that are even needed for netrek then why even bother rewriting the code? I am not looking forward to actively participating to cause another genre of kids to skip classes, to get CTS (Carpel Tunnel Syndrome), or to be exposed to the vulgarity of some of the players out there on the public servers. The fact that the code base still contains "doosh," and that someone uses it as their email address, and has been maintained in the code base for years sickens me. The only hit on the word "doosh" you will get in my code is in the readme saying that I didn't put it in. I am more focused on using Netrek for educational and research purposes, then just using it as a game. The idea of an entirely autonomous team, or one that is semi-autonomous with an observer "captain," that can defeat an entirely human team is intriguing. Making training scenarios for players are nice, because they can be used to train the bots also. At some point my code will dramatically shift from the current code base to support pluggable bots along with the increased security and performance monitoring that is needed for them. As long as we are moving in the same direction, I don't have a problem. If you want a mini-server for clients to be able to run, fine, I am doing that. If you want to have scenarios to teach newbies how to take planets and ogg starbases, fine, I will do that to. Don't want to use my code, don't want to run my server? I am not staying up late worrying about it. I am not trying to flame anyone or trash netrek entirely, although I do so hate the game, but I am merely explaining what my goals and reasons for doing a rewrite are. Darryl -----Original Message----- I agree, mostly. I think better time is spent improving the client. The idea of a stand-alone server that runs on the client machine is nice, but we can get most of any benefits from that setup by having a real, dedicated newbie server with training bots. While I commend Darryl and others for trying to do a complete Java rewrite, I think that those "reimplementations" will have little to no benefit in improving the netrek player base. Regardless of the technical differences between Java and C/C++, any Java port will require substantial man-hours of implementation and testing without the help of most of our existing developer base that, I would guess, will continue to work on Vanilla, COW and other software. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/f69dae75/smime.bin From Darryl_Palmer_Jr at acm.org Wed Dec 5 18:23:20 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: It would be neat to give it a shot. I could just wait until Jitesh and his team all develop arthritis and can't use mice anymore, then a simple bot could beat them. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Karthik Arumugham Sent: Wednesday, December 05, 2001 1:54 PM To: vanilla-list@us.netrek.org Subject: RE: [Vanilla List] Growing Netrek - Measures On Wed, 5 Dec 2001, Darryl Palmer Jr wrote: > Personally I hate Netrek and the INL, maybe because I was a member of the > team that gave Jitesh's team the fastest geno time on record. My plan is > to create an all robot team that can kick those INL weenies. This is just > one step in my overall plan. A bot that can out-dogfight humans most of the time? Possible. A bot that can out-clue a human and actually win the game? Doubtful. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/8e8dfd27/smime.bin From quozl at us.netrek.org Wed Dec 5 18:18:10 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Wed, Dec 05, 2001 at 08:00:04AM -0600 References: <20011205164213.B32243@us.netrek.org> Message-ID: <20011206111810.D32243@us.netrek.org> On Wed, Dec 05, 2001 at 08:00:04AM -0600, Darryl Palmer Jr wrote: > I remember that was one goal of my porting the server code to work on NT. > My goals have slightly increased and I wanted to also make it possible for > people to write their own robots, and maybe steal some of the thunder from > robo-soccer. I have switched to rewriting the server in Java. It still > remains to be seen if the server can realistically handle 16+ clients, but > the code currently isn't really that optimized and it will have to wait > until January or so when I can test it. Why Java? We have it in C now. The server code has nothing in it that should not execute fine as C compiled under Cygwin, in order to simulate the Netrek universe. The only issue left is to merge the code into a monolithic process rather than split processes. For that we need some heavy C clue and a bit of time. This would be for the Cygwin port only, not for UNIX. The advantage of split processes is considerable. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From ahn at vec.wfubmc.edu Wed Dec 5 18:37:21 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205214205.438A3172CF@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Wed, Dec 05, 2001 at 04:42:04PM -0500 References: <20011205152426.A169415@cecum.vec.wfubmc.edu> <20011205214205.438A3172CF@denali.ccs.neu.edu> Message-ID: <20011205193721.A169084@cecum.vec.wfubmc.edu> On Wed, Dec 05, 2001 at 04:42:04PM -0500, Jeffrey Nowakowski wrote: > > I disagree. There are too many people with bad connections out there. Broadband is here. While a lot of people do have bad connections (including modem-only), I think that most people who try out netrek for the first time will either already be computer-savvy or be at least network game-savvy. If their connections are really that bad, then training them for a couple of hours on their local servers won't go very far in retaining them when they get rewled repeatedly the first time they login to a real server. > You don't want the user's first experience to be a bad one due to a > flakey connection. It's much better to have a local tutorial server > that is rock solid. Any commercially successful game has a localized > version. I don't discount the value of a localized server. I've supported that idea for years. But, I simply don't think that a superb server is going to help the newbie understand how to change the keymap, if they even survive the first 10 minutes of trying to download, install and run the client. > Going to Java is debatable. On the one hand the C code is well > established, but it is also a mess. C is also harder to maintain. > I'm willing to bet there are more converted C++ programmers on this > list than you think. It's not as bad as it used to be. There may be some Java programmers on this list, but I don't see any of the current active developers embracing it. The only possible switch I see is to C++ since it is a superset of C and the transition can be done incrementally, and even that is a fair bit of work. > > I really wish we could try to consolidate our development efforts. > > I've been saying this for years. It's unlikely to happen unless > somebody with enough sway can get everybody to agree on a clear > vision. The biggest problem is time. Nobody with sufficient knowledge of netrek client software seems to have the time to dedicate to this. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From doosh at inl.org Wed Dec 5 19:21:59 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Wed, Dec 05, 2001 at 06:23:10PM -0600 References: <20011205152426.A169415@cecum.vec.wfubmc.edu> Message-ID: <20011205172159.A29044@inl.org> On Wed, Dec 05, 2001 at 06:23:10PM -0600, Darryl Palmer Jr wrote: > servers. The fact that the code base still contains "doosh," and that > someone uses it as their email address, and has been maintained in the > code base for years sickens me. The only hit on the word "doosh" you will > get in my code is in the readme saying that I didn't put it in. Uh, what is wrong with the word "doosh"? -Tom From mark at mark.mielke.cc Wed Dec 5 19:23:54 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206111810.D32243@us.netrek.org>; from quozl@us.netrek.org on Thu, Dec 06, 2001 at 11:18:10AM +1100 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> Message-ID: <20011205202354.B13350@mark.mielke.cc> On Thu, Dec 06, 2001 at 11:18:10AM +1100, James Cameron wrote: > On Wed, Dec 05, 2001 at 08:00:04AM -0600, Darryl Palmer Jr wrote: > > I remember that was one goal of my porting the server code to work on NT. > > My goals have slightly increased and I wanted to also make it possible for > > people to write their own robots, and maybe steal some of the thunder from > > robo-soccer. I have switched to rewriting the server in Java. It still > > remains to be seen if the server can realistically handle 16+ clients, but > > the code currently isn't really that optimized and it will have to wait > > until January or so when I can test it. > Why Java? We have it in C now. The server code has nothing in it that > should not execute fine as C compiled under Cygwin, in order to simulate > the Netrek universe. The only issue left is to merge the code into a > monolithic process rather than split processes. For that we need some > heavy C clue and a bit of time. > This would be for the Cygwin port only, not for UNIX. The advantage of > split processes is considerable. Considering that much of the code currently references shared memory, I wonder if it would be simpler to use threads instead of processes for ntserv, daemonII, robotII, etc.? It doesn't really have to be that monolithic. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From doosh at inl.org Wed Dec 5 19:46:28 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205193721.A169084@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Wed, Dec 05, 2001 at 07:37:21PM -0500 References: <20011205152426.A169415@cecum.vec.wfubmc.edu> <20011205214205.438A3172CF@denali.ccs.neu.edu> <20011205193721.A169084@cecum.vec.wfubmc.edu> Message-ID: <20011205174628.A30492@inl.org> On Wed, Dec 05, 2001 at 07:37:21PM -0500, Dave Ahn wrote: > On Wed, Dec 05, 2001 at 04:42:04PM -0500, Jeffrey Nowakowski wrote: > > > > I disagree. There are too many people with bad connections out there. > > Broadband is here. While a lot of people do have bad connections (including > modem-only), I think that most people who try out netrek for the first > time will either already be computer-savvy or be at least network game-savvy. > If their connections are really that bad, then training them for a couple of > hours on their local servers won't go very far in retaining them when they > get rewled repeatedly the first time they login to a real server. As a game player, I am much more likely to futz around with a game where I don't have to worry about other people at first. Playing against other people when you don't have any idea what's going on is intimidating. -Tom From doosh at inl.org Wed Dec 5 18:55:04 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205181851.A11036@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 06:18:51PM -0500 References:

<20011205181851.A11036@mark.mielke.cc> Message-ID: <20011205165504.A27009@inl.org> On Wed, Dec 05, 2001 at 06:18:51PM -0500, Mark Mielke wrote: > > As the stupidest example, 'clued' humans will attempt to phaser the > cloaker to obtain their exact co-ordinates, most especially during > LPS. How much fuel is wasted with 2 or 3 'clued' humans all trying to > make their best guess, all possibly missing? If the bots were in > communication with each other, one bot could be assigned the area > covered by the radius of the enemy ship at all possibly points along > its phaser line, with a preference offered for the ship with the most > powerful phaser, at the least range, at the most probable location > that we suspect the cloaker is at. (Interpolate his co-ordinates given > the approximatings offered by the server every few updates) This shows a lack of understanding of netrek dynamics. First of all, phaserlocking isn't that hard, and humans do it better than computers, because humans do fuzzy things better than computers. If you feed a computer bad data (as the netrek server does with cloakers), it will take an enormous amount of programming effort to make it perform as well as a human would. But that's not even the interesting point. The interesting point is that tactical perfection is only a small help in winning netrek games, and another thing computers are bad at is dynamic strategizing, which is the most important thing in winning netrek games. > This would > also apply to base oggs. Usually, locating the ogger is half the > battle. Why waste half your fuel on 6 incoming cloakers, just trying > to find them, when a co-ordinated game of search and destroy would be > so much more practical? Also, the computer doesn't blink when its > eyelids get a little dry. No more "we got 6 of the oggers, but the 7th > got through." Robot bases are very hard to kill, but they're pretty easy to neutralize. > Other possibilities include "I'm going to plasma him, press him away > from you and phaser him, and torp him so that we can distract him. The > *instant* he phasers you, I'll launch the plasma." Getting robots to do this level of communication is well beyond the point of diminishing returns. Maybe you get one extra plasma hit over the course of an entire game. > Just some examples of how *theoretically* a bot team could be > significantly better than a human team. Your examples are all in tactical situations. A tactically perfect bot, using the best netrek robot strategy code ever written, would get its butt kicked by any reasonable human team. Although that's partly because the people writing netrek robots tend to spend a lot of time on stupid shit like trying to improve dogfighting and phaserlocking and not enough time on interesting and difficult problems, like whether to refuel in place, try to mutual and get a fresh ship, go to a planet to refuel, or go back to core to pick armies. (To give one small example of the kind of decisions robots are extremely bad at). -Tom From ahn at vec.wfubmc.edu Wed Dec 5 18:56:20 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:44 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205181851.A11036@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 06:18:51PM -0500 References:

<20011205181851.A11036@mark.mielke.cc> Message-ID: <20011205195619.C169084@cecum.vec.wfubmc.edu> On Wed, Dec 05, 2001 at 06:18:51PM -0500, Mark Mielke wrote: > > Just some examples of how *theoretically* a bot team could be > significantly better than a human team. You can easily build bots that fire phasers and torps more efficiently and more accurately than all players that have and will ever play this game. It's harder to get a robot to adapt to dynamic strategy. If today's top AI computer scientists and strategists came together to build the ultimate netrek robot team that runs on ASCI White, then it's probably likely that it would repeatedly beat the best human team we can form (netrek's strategy space is actually quite small). Otherwise, I'll put my money on the human team any day of the week. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From xyzzy at speakeasy.org Wed Dec 5 18:59:33 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205181851.A11036@mark.mielke.cc> Message-ID: On Wed, 5 Dec 2001, Mark Mielke wrote: > > A bot that can out-dogfight humans most of the time? Possible. A bot that > > can out-clue a human and actually win the game? Doubtful. > > Why not? :-) > > Just some examples of how *theoretically* a bot team could be > significantly better than a human team. Certain other aids are usually That's it, it's just theoretical. In practice, any algorithm that you program will have a flaws and weaknesses. Humans will find these and exploit them, and your bots will lose. From ahn at vec.wfubmc.edu Wed Dec 5 19:37:27 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <200112051625.AA52494560@sodablue.org>; from ssheldon@sodablue.org on Wed, Dec 05, 2001 at 04:25:56PM -0700 References: <200112051625.AA52494560@sodablue.org> Message-ID: <20011205203727.D169084@cecum.vec.wfubmc.edu> On Wed, Dec 05, 2001 at 04:25:56PM -0700, Steve Sheldon wrote: > > Well those are my thoughts, and I'm sure they don't help anyone because > what I talk of doesn't fit into anybody elses grand scheme on this list. > (Because I'm one of the few who doesn't have an anti-MS bias) So that > just further forks things. I don't know about others, but I've been developing on WIN32 for the past year, and I have to say that my anti-MS bias has gotten worse. The problem is that MS's developer tools are simply unreliable, and their support for "standards" is always tainted with incompatibilities. Even when you build specifically using the WIN32 platform and MS provided SDK's, whenever you try to push the limits of the software, things fail unpredictably. It's no wonder that Windows applications (not just MS's) have been so prone to failure. It's clear that MS's stuff is improving in quality. The .NET strategy, albeit stolen completely from Java, certainly helps the different MS development platforms to work together and makes it easier to webify applications. This is a very big thing for desktop apps and a good move by MS. The question now is adoption rate. It's at a snail's pace and will stay that way for a while. Writing a new .NET netrek client would certainly be straightforward. Netrek is not a complex piece of software. But the biggest improvement anyone can make to the client is its usability and user interface. .NET doesn't give you anything truly useful there. > I'll shut up now. Please keep me posted on how things go. I'll be glad to provide services and space on netrek.org if you need them. While I feel that MS does not provide superior technology, they do provide dominant technology. Gotta target the bigger audience... -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From ahn at vec.wfubmc.edu Wed Dec 5 19:56:44 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Wed, Dec 05, 2001 at 06:23:10PM -0600 References: <20011205152426.A169415@cecum.vec.wfubmc.edu> Message-ID: <20011205205644.E169084@cecum.vec.wfubmc.edu> On Wed, Dec 05, 2001 at 06:23:10PM -0600, Darryl Palmer Jr wrote: > > As long as we are moving in the same direction, I don't have a problem. > If you want a mini-server for clients to be able to run, fine, I am doing > that. If you want to have scenarios to teach newbies how to take planets > and ogg starbases, fine, I will do that to. Don't want to use my code, > don't want to run my server? I am not staying up late worrying about it. This is precisely why netrek hasn't changed in years. New people come in wanting to contribute to the project but simply insist on writing everything from scratch in their own way for their own purpose. We seem to have lost any sense of collaboration. It would be great to have a client-side server that can train newbies and do all the things you want to explore. Maybe you will succeed, and your server will be superb. Good luck. And don't forget to upload stuff to ftp.netrek.org where your work can be archived. > I am not trying to flame anyone or trash netrek entirely, although I do so > hate the game, but I am merely explaining what my goals and reasons for > doing a rewrite are. I apologize for trying to leverage your efforts for the bigger community. Building/rebuilding on top of existing software would be better for us but is obviously not very appealing to you, particularly in light of how much you hate netrek. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From Darryl_Palmer_Jr at acm.org Wed Dec 5 20:07:30 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206111810.D32243@us.netrek.org> Message-ID: Trust me, Java sux. The benefit of writing in Java was to be able to support, download, and execute bots that other people write. Java allows you to run other code under different security from the main process, so you can limit people from accessing methods that you don't want them to. The other point was that more new programmers are probably learning Java more than C or C++, and it would be easier to support Java written bots with a Java based client. It is true that one could write a JNI interface for the bots to work with the C code but that is a path I didn't want to go down. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of James Cameron Sent: Wednesday, December 05, 2001 6:18 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures On Wed, Dec 05, 2001 at 08:00:04AM -0600, Darryl Palmer Jr wrote: > I remember that was one goal of my porting the server code to work on NT. > My goals have slightly increased and I wanted to also make it possible for > people to write their own robots, and maybe steal some of the thunder from > robo-soccer. I have switched to rewriting the server in Java. It still > remains to be seen if the server can realistically handle 16+ clients, but > the code currently isn't really that optimized and it will have to wait > until January or so when I can test it. Why Java? We have it in C now. The server code has nothing in it that should not execute fine as C compiled under Cygwin, in order to simulate the Netrek universe. The only issue left is to merge the code into a monolithic process rather than split processes. For that we need some heavy C clue and a bit of time. This would be for the Cygwin port only, not for UNIX. The advantage of split processes is considerable. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/358bf54a/smime.bin From ahn at vec.wfubmc.edu Wed Dec 5 20:14:00 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205202354.B13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 08:23:54PM -0500 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> Message-ID: <20011205211400.A168347@cecum.vec.wfubmc.edu> On Wed, Dec 05, 2001 at 08:23:54PM -0500, Mark Mielke wrote: > > Considering that much of the code currently references shared memory, > I wonder if it would be simpler to use threads instead of processes > for ntserv, daemonII, robotII, etc.? Yes. Switching to a thread model would also make a native WIN32 port of the server quite easy. A couple of hours of work. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From Darryl_Palmer_Jr at acm.org Wed Dec 5 20:21:44 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205172159.A29044@inl.org> Message-ID: Nothing is wrong with the word "doosh." But given that there are now pre-adults that play this game, and it could be mis-associated with human sexuality, or even abortion. I don't want to see little advid 6th to 9th Netrek players, saying "doosh" in their schools or at home. Adults could loose focus on the teamwork and hand-eye coordination that a game let Netrek teaches, and just see that Netrek teaches their children this word. I guess if it was off by default it wouldn't not be a problem. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Tom Holub Sent: Wednesday, December 05, 2001 7:22 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures On Wed, Dec 05, 2001 at 06:23:10PM -0600, Darryl Palmer Jr wrote: > servers. The fact that the code base still contains "doosh," and that > someone uses it as their email address, and has been maintained in the > code base for years sickens me. The only hit on the word "doosh" you will > get in my code is in the readme saying that I didn't put it in. Uh, what is wrong with the word "doosh"? -Tom _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/ffa4663c/smime.bin From Darryl_Palmer_Jr at acm.org Wed Dec 5 20:33:22 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205174628.A30492@inl.org> Message-ID: If someone is new to Netrek, how do they learn to play? Well if there friend didn't get them hooked, they have to go and find various FAQs and Newbie/Twink guides then go online and play. If on continuum you see someone in core playing around, cloaking and de-cloaking, tractoring and repulsing other players, and otherwise being an all-around core twink, what do we do. Someone sends him a message that he is a "twink." He might not even know what a twink is, but he might feel that he was insulted. Which of course he shouldn't because he IS a twink. In single-player mode, a player can see what netrek is about. He can try out the different commands and decide if he wants to investigate it more. If he does, he can try out some of the scenarios. How do you ogg? How do you sync on a base? Even the simple question of how do you take a planet could be answered before he logs in, I don't mean any strategies about taking a planet but more of the sequence of getting a kill, orbitting a friendly planet, loading armies, orbitting a non-friendly planet, and dropping armies. Oops did you have your war settings right? That's right twink, you got to know how to use that also. Now that you know the mechanisms of that, let's see you take a planet with an escort that is being defended. No twink, don't just go for the planet, there is no rush. Or let's see you escort a robot taking the planet, det twink, det. There are so many simple scenarios that could be done to help those twinks out there. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Tom Holub Sent: Wednesday, December 05, 2001 7:46 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures On Wed, Dec 05, 2001 at 07:37:21PM -0500, Dave Ahn wrote: > On Wed, Dec 05, 2001 at 04:42:04PM -0500, Jeffrey Nowakowski wrote: > > > > I disagree. There are too many people with bad connections out there. > > Broadband is here. While a lot of people do have bad connections (including > modem-only), I think that most people who try out netrek for the first > time will either already be computer-savvy or be at least network game-savvy. > If their connections are really that bad, then training them for a couple of > hours on their local servers won't go very far in retaining them when they > get rewled repeatedly the first time they login to a real server. As a game player, I am much more likely to futz around with a game where I don't have to worry about other people at first. Playing against other people when you don't have any idea what's going on is intimidating. -Tom _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/a0db1696/smime.bin From mark at mark.mielke.cc Wed Dec 5 20:30:43 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205165504.A27009@inl.org>; from doosh@inl.org on Wed, Dec 05, 2001 at 04:55:04PM -0800 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> Message-ID: <20011205213043.C13350@mark.mielke.cc> On Wed, Dec 05, 2001 at 04:55:04PM -0800, Tom Holub wrote: > On Wed, Dec 05, 2001 at 06:18:51PM -0500, Mark Mielke wrote: > > As the stupidest example, 'clued' humans will attempt to phaser the > > cloaker to obtain their exact co-ordinates, most especially during > > LPS. How much fuel is wasted with 2 or 3 'clued' humans all trying to > > make their best guess, all possibly missing? If the bots were in > > communication with each other, one bot could be assigned the area > > covered by the radius of the enemy ship at all possibly points along > > its phaser line, with a preference offered for the ship with the most > > powerful phaser, at the least range, at the most probable location > > that we suspect the cloaker is at. (Interpolate his co-ordinates given > > the approximatings offered by the server every few updates) > This shows a lack of understanding of netrek dynamics. First of all, > phaserlocking isn't that hard, and humans do it better than computers, > because humans do fuzzy things better than computers. If you feed a > computer bad data (as the netrek server does with cloakers), it will > take an enormous amount of programming effort to make it perform as > well as a human would. Not to be rude, but... well, duh... :-) Of course math and experience needs to be coded in. :-) This doesn't prove that a human is better. It just means that you can't think of the top of *your* head how you could make it be better. If you thought for a while, you would come up with things... > But that's not even the interesting point. The interesting point is > that tactical perfection is only a small help in winning netrek games, > and another thing computers are bad at is dynamic strategizing, which > is the most important thing in winning netrek games. You assume that Netrek is a complicated game like Life. It isn't, regardless as to how esteemed the 'clued' would like to feel. It is certainly an art, but believe it or not, it is possible to make a computer beat the best chess player in the world. It just takes a lot of investment into strategy and other such things up front. > > Other possibilities include "I'm going to plasma him, press him away > > from you and phaser him, and torp him so that we can distract him. The > > *instant* he phasers you, I'll launch the plasma." > Getting robots to do this level of communication is well beyond the > point of diminishing returns. Maybe you get one extra plasma hit over > the course of an entire game. This is one of among 1000 things I would complete my attempt with. > > Just some examples of how *theoretically* a bot team could be > > significantly better than a human team. > Your examples are all in tactical situations. A tactically perfect > bot, using the best netrek robot strategy code ever written, would get > its butt kicked by any reasonable human team. Although that's partly > because the people writing netrek robots tend to spend a lot of time > on stupid shit like trying to improve dogfighting and phaserlocking > and not enough time on interesting and difficult problems, like > whether to refuel in place, try to mutual and get a fresh ship, go to > a planet to refuel, or go back to core to pick armies. (To give one > small example of the kind of decisions robots are extremely bad at). This sounds like a dare. If I had some more spare time I'd ask you to put money on it. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Wed Dec 5 20:36:43 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from xyzzy@speakeasy.org on Wed, Dec 05, 2001 at 04:59:33PM -0800 References: <20011205181851.A11036@mark.mielke.cc> Message-ID: <20011205213643.D13350@mark.mielke.cc> On Wed, Dec 05, 2001 at 04:59:33PM -0800, Trent Piepho wrote: > On Wed, 5 Dec 2001, Mark Mielke wrote: > > > A bot that can out-dogfight humans most of the time? Possible. A bot that > > > can out-clue a human and actually win the game? Doubtful. > > Why not? :-) > > Just some examples of how *theoretically* a bot team could be > > significantly better than a human team. Certain other aids are usually > That's it, it's just theoretical. In practice, any algorithm that you > program will have a flaws and weaknesses. Humans will find these and exploit > them, and your bots will lose. So... some of us are believers, and some are non-believers. I don't personally have the time to do the whole thing myself... but... do some other believers want to put in some time with me to show these un-believers what years of coding in the practical realm can do to a few geeks with happy trigger fingers, and a lot of pride? :-) The flaws are not so easy to exploit, if the problem domain becomes sufficiently complex that the human mind is not able to discern any patterns that are guaranteed to exist. After all... what are human strategies, except for minor modifications of existing experience? The human mind is certainly wonderful. God is great, and all that. The human mind is *not* necessarily the best at everything. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From Darryl_Palmer_Jr at acm.org Wed Dec 5 20:44:36 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:45 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205205644.E169084@cecum.vec.wfubmc.edu> Message-ID: That statement is part sarcasm. Just for the record, I hate Netrek because I am not good it. Yes I still play Netrek sometimes, maybe 30 minutes or an hour a week, no where near what I put into it back in college. Instead of me trying to play it and become good at it, I am trying to do something new and different that could increase my skill set and make me more money in the future. Also I wanted to do something more educational to pull people who could code into the Netrek community. The idea is that newbies who start writing bots for Netrek would first need to learn what it is about, and maybe after writing a few bots they would want to get involved at a higher level. I am willing to help out with the core netrek code, but I don't have access to UNIX/Linux right now and probably won't have my old Linux box up and running again until next month or so. I guess one of the biggest things that could be done with netrek is probably to make some design documents for it. Has this ever been brought up? Darryl -----Original Message----- I apologize for trying to leverage your efforts for the bigger community. Building/rebuilding on top of existing software would be better for us but is obviously not very appealing to you, particularly in light of how much you hate netrek. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/9c6571aa/smime.bin From mark at mark.mielke.cc Wed Dec 5 20:49:53 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205172159.A29044@inl.org>; from doosh@inl.org on Wed, Dec 05, 2001 at 05:21:59PM -0800 References: <20011205152426.A169415@cecum.vec.wfubmc.edu> <20011205172159.A29044@inl.org> Message-ID: <20011205214953.E13350@mark.mielke.cc> On Wed, Dec 05, 2001 at 05:21:59PM -0800, Tom Holub wrote: > On Wed, Dec 05, 2001 at 06:23:10PM -0600, Darryl Palmer Jr wrote: > > servers. The fact that the code base still contains "doosh," and that > > someone uses it as their email address, and has been maintained in the > > code base for years sickens me. The only hit on the word "doosh" you will > > get in my code is in the readme saying that I didn't put it in. > Uh, what is wrong with the word "doosh"? Rumours that it isn't actually a geek in University who made audible sounds that were spelled out every time he took out an enemy with kills... :-) mark (who makes sounds when playing games sometimes as well... when I say geek, I sort of include myself in those ranks...) -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From quozl at us.netrek.org Wed Dec 5 20:50:20 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205202354.B13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 08:23:54PM -0500 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> Message-ID: <20011206135020.I32243@us.netrek.org> On Wed, Dec 05, 2001 at 08:23:54PM -0500, Mark Mielke wrote: > Considering that much of the code currently references shared memory, > I wonder if it would be simpler to use threads instead of processes > for ntserv, daemonII, robotII, etc.? I favour an event driven model; I've tried threading and it opens up a can of worms. At least select() works on Microsoft Windows. My point is that the code is already there, it just needs tweaking to make it function within a single process. As Dave says, it's time we need. Or more people. Given two people, one with C skills, one with Java skills, at equivalent experience levels, I'm sure the one with C skills would get the job done in a fraction of the time, because the code already works. However, it isn't as important as the spiffy client. My time I shall allocate to that first. Is it uploaded anywhere yet? -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Wed Dec 5 21:04:06 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from zu22@andrew.cmu.edu on Wed, Dec 05, 2001 at 03:30:34PM -0500 References:

Message-ID: <20011206140406.J32243@us.netrek.org> On Wed, Dec 05, 2001 at 03:30:34PM -0500, Zachary Uram wrote: > I have now created a Source Forge account. > My login is "zinpgh" Added. > With all the discussion in past weeks I have lost site of what I > should be doing to help out. Can you tell me exactly what I can > do? Well, as I said, my priorities are spiffy download client, (which some of us are working on by taking COW and encapsulating it within Inno Setup, along with others working out a Win32 GTK+ GUI for player preferences) then the porting of the server to Cygwin. Zach, I think you need to figure out exactly what you can do based on your skill set. This time I don't think I can realistically set tasks, because things are happening too quick for that. See if you can figure out what needs doing that you know you can do, and Just Do It. I *think* as a group we are agreed that the priority is the client. > I know how to login to Vanilla through anonymous CVS but have > never logged in for COW. Set up your CVS client, then follow the instructions to check out the COW source tree as a developer. http://sourceforge.net/cvs/?group_id=968 The module name is 'client' and the directory is 'cow'. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From Darryl_Palmer_Jr at acm.org Wed Dec 5 21:37:54 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205211400.A168347@cecum.vec.wfubmc.edu> Message-ID: I worked on the WIN32 server port two years ago. The version that I think you still can get from the FTP site has most of the functionality of the then current server. It even support the INL bot for INL games. The only thing that wasn't so nice is that it had to use the full path for the different programs and I think the database had to be changed. If anyone wanted to take some time to look at it, they could easily create a wrapper for the global memory and for some of the socket selects and signals that aren't implemented in Windows. The problem I had working on it was getting the source to the bots for the base practice server, but that has since been made available. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Dave Ahn Sent: Wednesday, December 05, 2001 8:14 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures On Wed, Dec 05, 2001 at 08:23:54PM -0500, Mark Mielke wrote: > > Considering that much of the code currently references shared memory, > I wonder if it would be simpler to use threads instead of processes > for ntserv, daemonII, robotII, etc.? Yes. Switching to a thread model would also make a native WIN32 port of the server quite easy. A couple of hours of work. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/d55417b9/smime.bin From quozl at us.netrek.org Wed Dec 5 21:37:46 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Wed, Dec 05, 2001 at 08:44:36PM -0600 References: <20011205205644.E169084@cecum.vec.wfubmc.edu> Message-ID: <20011206143746.K32243@us.netrek.org> On Wed, Dec 05, 2001 at 08:44:36PM -0600, Darryl Palmer Jr wrote: > I am willing to help out with the core netrek code, but I don't have > access to UNIX/Linux right now and probably won't have my old Linux box up > and running again until next month or so. Don't wait. Download and install Cygwin. Gives you a remarkably complete UNIX environment on your Microsoft Windows system. Lots of very handy utilities, even some with a GUI. Once you have downloaded and installed Cygwin, check out the COW client, and you should be able to immediately build it. In theory. Most of the Netrek server can also be built. Just some small fragments that are terribly critical don't actually work. > I guess one of the biggest things that could be done with netrek is > probably to make some design documents for it. Has this ever been > brought up? Yes. You're welcome to do this; document the protocol or the design. But you will have to be the one to make sure the documents track reality. The code is sufficient for most of us, and maintaining two separate instances of documentation for a protocol is costly. On the other hand since changes to the protocol are unlikely at this stage, the investment could be rewarded. To contribute, gain access to CVS, upload your design documents there. Format that I prefer is HTML. Or DocBook SGML. Tools are on Cygwin to handle that, I think. Not sure. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From mark at mark.mielke.cc Wed Dec 5 22:22:53 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205165504.A27009@inl.org>; from doosh@inl.org on Wed, Dec 05, 2001 at 04:55:04PM -0800 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> Message-ID: <20011205232253.G13350@mark.mielke.cc> On Wed, Dec 05, 2001 at 04:55:04PM -0800, Tom Holub wrote: > This shows a lack of understanding of netrek dynamics. First of all, > phaserlocking isn't that hard, and humans do it better than computers, > because humans do fuzzy things better than computers. If you feed a > computer bad data (as the netrek server does with cloakers), it will > take an enormous amount of programming effort to make it perform as > well as a human would. Just to show you that I'm not pulling shit out of my ass. Consider the 'bad data' sent to the client: #ifdef AS_CLOAK if (pl->p_ship.s_type == ASSAULT) { cpl->x=htonl(pl->p_x+(random() % 3000)-1500); cpl->y=htonl(pl->p_y+(random() % 3000)-1500); } else #endif { cpl->x=htonl(pl->p_x+(random() % 2000)-1000); cpl->y=htonl(pl->p_y+(random() % 2000)-1000); } Forget the AS_CLOAK thing for a second. The position is reported as being up to 1000 units off on both the X and Y axis. The speed is reported as 15 (or something else that is effectively useless). The direction is left to be whatever it was before (i.e. no-op updates). Pretty 'inaccurate', eh? Now, picture three clients all on the same screen. All three clients are robots that talk to each other using some other mechanism than smessage(). If three clients are each getting a sensor reading of 'up to 1000 units off on both the X and Y axis, but not more than that', they can average these co-ordinates together to get a significantly more accurate reading. How accurate? Well, the worst possibly situation is that they are all off by exactly sqrt(100000 + 100000), or around 1414.2 units. What is the chance of this happening? Well, about 1 in 10**18. What is the *probable* accuracy? This depends greatly on the random number generator being used by ntserv, and how well distributed the numbers are. The latest code released from this list defines ZAPPLAYERDIST to be 390. Consider only one axis for a second, as the result of this probability would only need to be squared to determine the probability in two dimensions. How many sets of 3 numbers are possible, given an integer space of -1000...999? The answer is, of course, 2000**3, or 8 x 10**9. How many sets of 3 numbers, in the integer space of -1000...999 add up to a sum between -390 and 390? I'm feeling a little lazy, so: (Yes, I divided the units by 10 to make it execute faster...) $ perl -e 'for $a (-100 .. 99) { for $b (-100 .. 99) { for $c (-100 .. 99) { $z = $a + $b + $c; $z = -$z if $z < 0; $i++ if $z < 39; } } } print "i = $i\n"; ' i = 2271808 Because it was divided by 10 three times, we need to multiply it by 10 three times to come close: 2 x 10**9 (I even rounded down) 2 x 10**9 --------- = 1/4 8 x 10**9 On two axis', this is 1/16. Normally, on two axis', there is only 1/25. In summary of the above, with the normal 'inaccurate' information, there is a 1 in 25 (4.00%) chance that a cloaked ship will be revealed by a phaser beam directed at the location actually sent by the server from any direction, at the very longest range that the ship can fire a phaser at. If three clients are receiving information, this can be increased in our favour to 1 in 16 (6.25%). This may not seem like much, but if you look carefully, this is a 56% increase in accuracy under extreme conditions. The 'extreme conditions' are, if we are exactly one phaser length away from his actual position (in any direction), the percentage represents the chance that we will be able to reveal him by only averaging the co-ordinates that are available to us, and firing at that point. At exactly one phaser length, the damage will be 0. (This is assuming that we do not possess knowledge that he is exactly one phaser length away... such knowledge would greatly increase our odds... :-) ) Under more realistic situations, he will often not be exactly one phaser length away. He may be more, or he may be less. How to narrow it down? Well, if you have one set of co-ordinates, the greatest probability to hit him on the first shot is achieved if we can be certain that he is not on our 'other side'. As the server will report him +/-1000 units, the server must report him as at least 2000-390-390 units away in order for us to maintain the greatest odds of hitting him. (He is then at least -389..1220 units from us, all within the range of our phaser) If three clients receive three different sets of co-ordinates, we can reduce the 2000-390-390 units for the closest reported set of co-ordinates by the difference between the furthest reported set of co-ordinates. I.e. if one client reports him at a distance of 1000, while another clients reports him at 1500, we can deduce that the closest he could possibly be is 500 units, and the furthest he could be is 2000 units. Not coincidentally, the greater the range of co-ordinates sent to us by the server, the more accurate our readings are. As an extreme example, if one client is told that he is within 1000 units of a point, and another client is told that he is within 3000 units of a point, we can be 100% certain that he is exactly 2000 units from the point. For my numbers, I am assuming an even distribution, and not taking these additional numbers into account. K... I'm getting tired, so I'm going to stop here. Suffice it to say that quite a bit of information can be transferred to offer a fairly large 'edge' in many situations. Exploitable patterns or not, the computer has a decisive advantage in terms of reflex, calculation, and organization. If it is programmed correctly, I see no reason why it shouldn't be able to beat the best INL team at least some of the time. I'm not saying it wouldn't take a lot of work. I'm saying that I can inject my experience, and the experience of other players into it, add a few lightning reflexes, split second team work organization that is able to abruptly adjust such that the entire robot team changes to a new tactic at the exact same instant if necessary, collective information processing that approximates what some might consider 'cheating', etc. If we actually did this, I don't think it would be too much blasphemy to label the team 'The Borg'. One mind and all that. It would be really cool to use custom graphics that were a little cold and calculating for the COW client to offer an atmosphere of omnipotence. "Resistance is futile. Prepare to be assimilated into the collective." Tom: Do you see the potential, even if you don't believe it would ever amount to anything in your life time? And even if exploits were found, watching the game and then make mild adjustments, or re-writing sections of code to eliminate the exploit can be a very effective method of "AI" evolution. If situations exist with several variables, the robot teams could be set against each other with different settings, and the top 50 performing settings could be randomly chosen, or switched between during actual combat with human players. They could be weighted according to success against different teams as a method of emulating 'learning'. If the team begins to lose, it would choose one of the other 50 pre-canned settings. It might be desirable to weight the settings such that the robot team might be able to judge one settings as perhaps offering a greater chance of success against another setting upon observation of the strategies used by the other team. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From ssheldon at sodablue.org Wed Dec 5 22:27:14 2001 From: ssheldon at sodablue.org (Steve Sheldon) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: <00a501c17e0e$486783f0$8400000a@inside.sodablue.com> > [mailto:vanilla-list-admin@us.netrek.org] On Behalf Of Darryl > Palmer Jr > > Nothing is wrong with the word "doosh." But given that there > are now pre-adults that play this game, and it could be > mis-associated with human sexuality, or even abortion. I > don't want to see little advid 6th to 9th Netrek players, > saying "doosh" in their schools or at home. Adults could > loose focus on the teamwork and hand-eye coordination that a > game let Netrek teaches, and just see that Netrek teaches > their children this word. I guess if it was off by default it > wouldn't not be a problem. If we're worried about children... I'd be more concerned with "Where's my fucking escort!?" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3228 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011205/eb6d0bfa/smime.bin From mark at mark.mielke.cc Wed Dec 5 22:38:38 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206135020.I32243@us.netrek.org>; from quozl@us.netrek.org on Thu, Dec 06, 2001 at 01:50:20PM +1100 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> Message-ID: <20011205233838.H13350@mark.mielke.cc> On Thu, Dec 06, 2001 at 01:50:20PM +1100, James Cameron wrote: > On Wed, Dec 05, 2001 at 08:23:54PM -0500, Mark Mielke wrote: > > Considering that much of the code currently references shared memory, > > I wonder if it would be simpler to use threads instead of processes > > for ntserv, daemonII, robotII, etc.? > I favour an event driven model; I've tried threading and it opens up a > can of worms. At least select() works on Microsoft Windows. select() is only implemented for sockets. Microsoft usually uses the WaitForObject() model with such silly limits as "you can only wait for 64 objects at once." This is not too mention that an event driven system is a system that switches in user space. This complicates the code significantly, and ensures that operations cannot happen asynchronously. As an example, with the current process model, 16 ntserv processes can be actively waiting for I/O while the daemon process is executing code. With an event driven system, daemon updates would need to be scheduled, and when the daemon was performing an update, I/O could become blocked. Clients would freeze, and it would all be downhill from there as the server tried to 'catch up' every time by building a huge select() mask, only to throw it away as soon as it realizes: "Hey, 8 people have data for me." For more real-time systems such as Netrek, there is almost always data to be read. Why bother switching yourself, when you can let the system do it for you? Threading is very neat and tidy. As I'm sure you are aware, Netrek already deals with shared memory, which is not really that different from the way threads function. The details you would need to fiddle with for threads, is that you would want to avoid using signals to wake up your threads. Instead, using a conditional, or a wait. > My point is that the code is already there, it just needs tweaking to > make it function within a single process. As Dave says, it's time we > need. Or more people. Given two people, one with C skills, one with > Java skills, at equivalent experience levels, I'm sure the one with C > skills would get the job done in a fraction of the time, because the > code already works. I suspect it would take less time to make the server threaded, than it would take to make it event driven. My loyalty to Netrek has to do with the fact that I learned C from Netrek when I was only around 10 years old. I had read about C, and played with it for a few years before that, but you need a goal to strive towards before you actually learn to program. I had such fun writing my first borg back in those days. I think I spent an entire summer attempting to perfect it. I realized that its primary weakness was organization. It is no use if four robots all decide to bomb and take the same planet. I learned calculus and trigonometry in grade 9 for the sole reason of improving my borg. I wanted better ways to calculate intercept courses. The standard robot is notably stupid when it comes to sending torpedoes at somebody orbitting a planet. Around that time, I started my first job, and time begin to disappear quite rapidly. I still owe Netrek something for everything I learned from it. Is it really 12 years later? :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Wed Dec 5 22:42:09 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Wed, Dec 05, 2001 at 08:07:30PM -0600 References: <20011206111810.D32243@us.netrek.org> Message-ID: <20011205234209.I13350@mark.mielke.cc> On Wed, Dec 05, 2001 at 08:07:30PM -0600, Darryl Palmer Jr wrote: > Trust me, Java sux. The benefit of writing in Java was to be able to > support, download, and execute bots that other people write. Java allows > you to run other code under different security from the main process, so > you can limit people from accessing methods that you don't want them to. > The other point was that more new programmers are probably learning Java > more than C or C++, and it would be easier to support Java written bots > with a Java based client. It is true that one could write a JNI interface > for the bots to work with the C code but that is a path I didn't want to > go down. I dunno... I like Java. It fixes quite a few of the goof-ups made in C++. I just wouldn't trust it for any sort of real time system, such as Netrek. Although... now that gcc can compile java... I may be forced to re-analyze my position... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From karthik at karthik.com Wed Dec 5 23:41:09 2001 From: karthik at karthik.com (Karthik Arumugham) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205232253.G13350@mark.mielke.cc> Message-ID: I'm not sure what plocking cloakers has to do with actual clue. That intangible "clue" is what is hard to code. Coding bots to take planets as well as humans do, making team plays to accomplish their goals, and so on would be quite difficult in my opinion. Not to mention, the difficulty of figuring out exactly what the other team is up to. Winning the game takes a whole lot more than creating a bunch of robots that may be tactically superior to the other team. I think Netrek is a much more complex game than many people realize (especially those who haven't played higher level clue games). Someone compared it to computers playing chess in a previous post. While I don't know much about chess past the basic rules, it's basically a very simple game with a small, fixed number of variables (with a very, very large number of permutations of these variables of course, which is what makes it a complex and interesting game). Netrek has far, far more variables at work in determining exactly what's going on, and exactly what course of action to take. On Wed, 5 Dec 2001, Mark Mielke wrote: > On Wed, Dec 05, 2001 at 04:55:04PM -0800, Tom Holub wrote: > > This shows a lack of understanding of netrek dynamics. First of all, > > phaserlocking isn't that hard, and humans do it better than computers, > > because humans do fuzzy things better than computers. If you feed a > > computer bad data (as the netrek server does with cloakers), it will > > take an enormous amount of programming effort to make it perform as > > well as a human would. > > Just to show you that I'm not pulling shit out of my ass. > > Consider the 'bad data' sent to the client: > > #ifdef AS_CLOAK > if (pl->p_ship.s_type == ASSAULT) { > cpl->x=htonl(pl->p_x+(random() % 3000)-1500); > cpl->y=htonl(pl->p_y+(random() % 3000)-1500); > } else > #endif > { > cpl->x=htonl(pl->p_x+(random() % 2000)-1000); > cpl->y=htonl(pl->p_y+(random() % 2000)-1000); > } > > Forget the AS_CLOAK thing for a second. The position is reported as > being up to 1000 units off on both the X and Y axis. The speed is > reported as 15 (or something else that is effectively useless). The > direction is left to be whatever it was before (i.e. no-op updates). > > Pretty 'inaccurate', eh? > > Now, picture three clients all on the same screen. All three clients > are robots that talk to each other using some other mechanism than > smessage(). If three clients are each getting a sensor reading of 'up > to 1000 units off on both the X and Y axis, but not more than that', > they can average these co-ordinates together to get a significantly > more accurate reading. How accurate? Well, the worst possibly > situation is that they are all off by exactly sqrt(100000 + 100000), > or around 1414.2 units. What is the chance of this happening? Well, > about 1 in 10**18. > > What is the *probable* accuracy? This depends greatly on the random > number generator being used by ntserv, and how well distributed the > numbers are. > > The latest code released from this list defines ZAPPLAYERDIST to be > 390. Consider only one axis for a second, as the result of this > probability would only need to be squared to determine the probability > in two dimensions. > > How many sets of 3 numbers are possible, given an integer space of > -1000...999? The answer is, of course, 2000**3, or 8 x 10**9. > > How many sets of 3 numbers, in the integer space of -1000...999 add up > to a sum between -390 and 390? I'm feeling a little lazy, so: > > (Yes, I divided the units by 10 to make it execute faster...) > $ perl -e 'for $a (-100 .. 99) { > for $b (-100 .. 99) { > for $c (-100 .. 99) { > $z = $a + $b + $c; > $z = -$z if $z < 0; > $i++ if $z < 39; > } > } > } > print "i = $i\n"; > ' > i = 2271808 > > Because it was divided by 10 three times, we need to multiply it by 10 three > times to come close: 2 x 10**9 (I even rounded down) > > 2 x 10**9 > --------- = 1/4 > 8 x 10**9 > > On two axis', this is 1/16. Normally, on two axis', there is only 1/25. > > In summary of the above, with the normal 'inaccurate' information, > there is a 1 in 25 (4.00%) chance that a cloaked ship will be revealed > by a phaser beam directed at the location actually sent by the server > from any direction, at the very longest range that the ship can fire a > phaser at. If three clients are receiving information, this can be > increased in our favour to 1 in 16 (6.25%). This may not seem like > much, but if you look carefully, this is a 56% increase in accuracy > under extreme conditions. > > The 'extreme conditions' are, if we are exactly one phaser length away > from his actual position (in any direction), the percentage represents > the chance that we will be able to reveal him by only averaging the > co-ordinates that are available to us, and firing at that point. At > exactly one phaser length, the damage will be 0. (This is assuming > that we do not possess knowledge that he is exactly one phaser length > away... such knowledge would greatly increase our odds... :-) ) > > Under more realistic situations, he will often not be exactly one phaser > length away. He may be more, or he may be less. > > How to narrow it down? Well, if you have one set of co-ordinates, the > greatest probability to hit him on the first shot is achieved if we > can be certain that he is not on our 'other side'. As the server will > report him +/-1000 units, the server must report him as at least > 2000-390-390 units away in order for us to maintain the greatest odds > of hitting him. (He is then at least -389..1220 units from us, all > within the range of our phaser) > > If three clients receive three different sets of co-ordinates, we can > reduce the 2000-390-390 units for the closest reported set of > co-ordinates by the difference between the furthest reported set of > co-ordinates. I.e. if one client reports him at a distance of 1000, > while another clients reports him at 1500, we can deduce that the > closest he could possibly be is 500 units, and the furthest he could > be is 2000 units. > > Not coincidentally, the greater the range of co-ordinates sent to us > by the server, the more accurate our readings are. As an extreme > example, if one client is told that he is within 1000 units of a > point, and another client is told that he is within 3000 units of a > point, we can be 100% certain that he is exactly 2000 units from the > point. For my numbers, I am assuming an even distribution, and not > taking these additional numbers into account. > > K... I'm getting tired, so I'm going to stop here. Suffice it to say > that quite a bit of information can be transferred to offer a fairly > large 'edge' in many situations. Exploitable patterns or not, the > computer has a decisive advantage in terms of reflex, calculation, and > organization. If it is programmed correctly, I see no reason why it > shouldn't be able to beat the best INL team at least some of the time. > > I'm not saying it wouldn't take a lot of work. I'm saying that I can > inject my experience, and the experience of other players into it, add > a few lightning reflexes, split second team work organization that is > able to abruptly adjust such that the entire robot team changes to a > new tactic at the exact same instant if necessary, collective > information processing that approximates what some might consider > 'cheating', etc. > > If we actually did this, I don't think it would be too much blasphemy > to label the team 'The Borg'. One mind and all that. It would be > really cool to use custom graphics that were a little cold and > calculating for the COW client to offer an atmosphere of > omnipotence. "Resistance is futile. Prepare to be assimilated into the > collective." > > Tom: Do you see the potential, even if you don't believe it would ever > amount to anything in your life time? And even if exploits were found, > watching the game and then make mild adjustments, or re-writing > sections of code to eliminate the exploit can be a very effective > method of "AI" evolution. If situations exist with several variables, > the robot teams could be set against each other with different > settings, and the top 50 performing settings could be randomly chosen, > or switched between during actual combat with human players. They > could be weighted according to success against different teams as a > method of emulating 'learning'. If the team begins to lose, it would > choose one of the other 50 pre-canned settings. It might be desirable > to weight the settings such that the robot team might be able to judge > one settings as perhaps offering a greater chance of success against > another setting upon observation of the strategies used by the other > team. > > mark > > -- > mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ > . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder > |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | > | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada > > One ring to rule them all, one ring to find them, one ring to bring them all > and in the darkness bind them... > > http://mark.mielke.cc/ > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From doosh at inl.org Thu Dec 6 01:29:03 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:46 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Wed, Dec 05, 2001 at 08:21:44PM -0600 References: <20011205172159.A29044@inl.org> Message-ID: <20011205232903.A48954@inl.org> On Wed, Dec 05, 2001 at 08:21:44PM -0600, Darryl Palmer Jr wrote: > Nothing is wrong with the word "doosh." But given that there are now > pre-adults that play this game, and it could be mis-associated with human > sexuality, or even abortion. I don't want to see little advid 6th to 9th > Netrek players, saying "doosh" in their schools or at home. That's absurd. The fact that it's a homonym for a female hygeine product has nothing to do with the meaning of the word, and for that matter nothing to do with sex. They can hear "douche" on a commercial during Ally McBeal. -Tom From doosh at inl.org Thu Dec 6 01:33:25 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205213043.C13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 09:30:43PM -0500 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205213043.C13350@mark.mielke.cc> Message-ID: <20011205233325.B48954@inl.org> On Wed, Dec 05, 2001 at 09:30:43PM -0500, Mark Mielke wrote: > > But that's not even the interesting point. The interesting point is > > that tactical perfection is only a small help in winning netrek games, > > and another thing computers are bad at is dynamic strategizing, which > > is the most important thing in winning netrek games. > > You assume that Netrek is a complicated game like Life. It isn't, > regardless as to how esteemed the 'clued' would like to feel. It is > certainly an art, but believe it or not, it is possible to make a > computer beat the best chess player in the world. It just takes a > lot of investment into strategy and other such things up front. Netrek is a lot more like go than chess, and go-playing programs suck. Chess-playing computers don't have great strategy, they just brute-force look ahead far enough that the strategy doesn't matter. I remember the deep blue team noting that if you replace deep blue's position evaluator with a random number generator, it still plays pretty good chess. You can't do that kind of forward analysis with netrek. > > > Other possibilities include "I'm going to plasma him, press him away > > > from you and phaser him, and torp him so that we can distract him. The > > > *instant* he phasers you, I'll launch the plasma." > > Getting robots to do this level of communication is well beyond the > > point of diminishing returns. Maybe you get one extra plasma hit over > > the course of an entire game. > > This is one of among 1000 things I would complete my attempt with. You're going to spend probably hundreds of hours of coding time to get one more plasma hit, while the base is in the WRONG POSITION because the computer doesn't know how to play netrek. It's simply the wrong thing to focus on, but perhaps the only thing you're capable of. > > Your examples are all in tactical situations. A tactically perfect > > bot, using the best netrek robot strategy code ever written, would get > > its butt kicked by any reasonable human team. Although that's partly > > because the people writing netrek robots tend to spend a lot of time > > on stupid shit like trying to improve dogfighting and phaserlocking > > and not enough time on interesting and difficult problems, like > > whether to refuel in place, try to mutual and get a fresh ship, go to > > a planet to refuel, or go back to core to pick armies. (To give one > > small example of the kind of decisions robots are extremely bad at). > > This sounds like a dare. If I had some more spare time I'd ask you to > put money on it. There have been several netrek robots done already--we have a pretty good idea of their flaws, and those don't have anything to do with how often their plasmas hit. -Tom From doosh at inl.org Thu Dec 6 01:34:35 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205213643.D13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 09:36:43PM -0500 References: <20011205181851.A11036@mark.mielke.cc> <20011205213643.D13350@mark.mielke.cc> Message-ID: <20011205233435.C48954@inl.org> On Wed, Dec 05, 2001 at 09:36:43PM -0500, Mark Mielke wrote: > On Wed, Dec 05, 2001 at 04:59:33PM -0800, Trent Piepho wrote: > > On Wed, 5 Dec 2001, Mark Mielke wrote: > > > > A bot that can out-dogfight humans most of the time? Possible. A bot that > > > > can out-clue a human and actually win the game? Doubtful. > > > Why not? :-) > > > Just some examples of how *theoretically* a bot team could be > > > significantly better than a human team. Certain other aids are usually > > That's it, it's just theoretical. In practice, any algorithm that you > > program will have a flaws and weaknesses. Humans will find these and exploit > > them, and your bots will lose. > > So... some of us are believers, and some are non-believers. Some of us have seen at least three different actual netrek-playing robots in games against humans. -Tom From doosh at inl.org Thu Dec 6 01:41:05 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205232253.G13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 11:22:53PM -0500 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> Message-ID: <20011205234105.E48954@inl.org> On Wed, Dec 05, 2001 at 11:22:53PM -0500, Mark Mielke wrote: > > Tom: Do you see the potential, even if you don't believe it would ever > amount to anything in your life time? I see that you have absolutely no clue what you're talking about. If you increase robot phaserlocking to be 100% accurate, ROBOTS WILL STILL SUCK AT NETREK. You're talking about the wrong problem. -Tom From Darryl_Palmer_Jr at acm.org Thu Dec 6 07:20:53 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: It depends on how you see it. Deep Blue is nothing more than a Knowledge-Based expert system. Netrek is more compicated and the game-space for Netrek is much more than chess. I am thinking that the easiest way to do it would to be able to assign "roles" to various bots. These "roles" would alter their behavior. If a bot had enough kills and the central AI, or human caption, told it to take a planet. It would switch roles to planet-taker and cause nearby bots to switch roles to escort if necessary. The different "roles" could be individually programmed or better yet, they could be evolved using something like Genetic Programming. The purpose of robot soccer is also to evolve an AI team. The difference with Netrek is that it is closer to real life. You have to control space, coordinate attacks on the enemy, assault planets, and force the enemy back. This is much closer to a military campaign then soccer is. If you look at Huber's and Hadley's paper, some of their research was sponsored by the NSF and DARPA. Who knows maybe someone could use the research for a master's topic for AI. Chess is slightly different then Netrek. In chess you can loose space, you can even loose pieces, but if you can attack and defeat one peace you win. It is not the same in Netrek, if you loose most of your planets then you go and take your enemy's homeworld, you just wasted armies. Now if you focus on first gaining and maintaining control of space then taking planets behind the front, you don't have to worry about the planettaker switching modes between attack/defending/ogg-avoidance/planettake, but maybe even this won't be a problem. If the bots were better at fighting, playing a more ship-to-ship type defense would probably work. As long as the sides are even in a conflict the bots would win out let's say 60% of the time. To win the game, is different from saying that you have to geno the team. If the strategy works to just be 1 or 2 planets ahead for most of the game, that is enough. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Karthik Arumugham Sent: Wednesday, December 05, 2001 11:41 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures I'm not sure what plocking cloakers has to do with actual clue. That intangible "clue" is what is hard to code. Coding bots to take planets as well as humans do, making team plays to accomplish their goals, and so on would be quite difficult in my opinion. Not to mention, the difficulty of figuring out exactly what the other team is up to. Winning the game takes a whole lot more than creating a bunch of robots that may be tactically superior to the other team. I think Netrek is a much more complex game than many people realize (especially those who haven't played higher level clue games). Someone compared it to computers playing chess in a previous post. While I don't know much about chess past the basic rules, it's basically a very simple game with a small, fixed number of variables (with a very, very large number of permutations of these variables of course, which is what makes it a complex and interesting game). Netrek has far, far more variables at work in determining exactly what's going on, and exactly what course of action to take. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011206/edfe3320/smime.bin From jeffno at ccs.neu.edu Thu Dec 6 08:02:04 2001 From: jeffno at ccs.neu.edu (Jeffrey Nowakowski) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205193721.A169084@cecum.vec.wfubmc.edu> from "Dave Ahn" at Dec 05, 2001 07:37:21 PM Message-ID: <20011206140204.911F7172B4@denali.ccs.neu.edu> Dave Ahn wrote: > > Broadband is here. 2000: 9% of online households subscribe to broadband 2006: 41% http://cyberatlas.internet.com/markets/broadband/article/0,,10099_905351,00.html I have no idea how accurate these numbers are, but they're the first ones I found when I went looking. > While a lot of people do have bad connections (including > modem-only), I think that most people who try out netrek for the first > time will either already be computer-savvy or be at least network game-savvy. I'm not sure how this relates to the discussion at hand. > If their connections are really that bad, then training them for a couple of > hours on their local servers won't go very far in retaining them when they > get rewled repeatedly the first time they login to a real server. But it will give them a chance to get hooked. When I was stuck on a dial-up modem, I had a hard time finding a service that would stay connected for hours at a time. Trying to learn a new game and dealing with crap like that just sucks. Once a newbie has learned the game locally, finding an online game that they can play for an hour on won't be so bad. Also, it'll be easier to write a tutorial on the local client with a local server than on a remote server. Remember how newbie.psychosis.net was turned into a tutorial server? I appreciated Karthik's efforts, but I doubt it was very helpful to newbies. > I don't discount the value of a localized server. You just did in your previous message. > I've supported that idea > for years. But, I simply don't think that a superb server is going to > help the newbie understand how to change the keymap, if they even survive > the first 10 minutes of trying to download, install and run the client. The whole point of this effort is to make the download, install, and running the client stupid-simple. Changing your keymap should not be difficult. Having a local tutorial server will get newbies up and running right away. -Jeff From zu22 at andrew.cmu.edu Thu Dec 6 10:31:39 2001 From: zu22 at andrew.cmu.edu (Zachary Uram) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <200112051625.AA52494560@sodablue.org> Message-ID: Isn't .NET a proprietary MS-only platform? If we are going to build a new netrek lets do so using open source/standard components. Zach zu22@andrew.cmu.edu "Blessed are those who have not seen and yet have faith." - John 20:29 From mark at mark.mielke.cc Thu Dec 6 11:10:10 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Netrek as an art. In-Reply-To: <20011205234105.E48954@inl.org>; from doosh@inl.org on Wed, Dec 05, 2001 at 11:41:05PM -0800 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> <20011205234105.E48954@inl.org> Message-ID: <20011206130731.E16413@mark.mielke.cc> On Wed, Dec 05, 2001 at 11:41:05PM -0800, Tom Holub wrote: > On Wed, Dec 05, 2001 at 11:22:53PM -0500, Mark Mielke wrote: > > Tom: Do you see the potential, even if you don't believe it would ever > > amount to anything in your life time? > I see that you have absolutely no clue what you're talking about. If you > increase robot phaserlocking to be 100% accurate, ROBOTS WILL STILL SUCK AT > NETREK. You're talking about the wrong problem. I think in my zeal, I forgot to present my argument. I presented a case, without listing the primary benefit. The primary benefit being... that cloaking is not an effective technique against robots that can see right through your cloak. The successful robot team would have to greatly diminish any gains you would receive from certain tactics, or cause them to be ineffective. By eliminating tactics that can be effectively used against the robots, the problem space becomes reduced as a result. You are telling me that I am approaching things from the wrong angle. I ask you... when was the last time you wrote a bot that could successfully win against most, if not all INL teams? How would you know which angle was the wrong one? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Thu Dec 6 11:29:04 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Netrek? Open source? Encouragement? In-Reply-To: <20011205233435.C48954@inl.org>; from doosh@inl.org on Wed, Dec 05, 2001 at 11:34:35PM -0800 References: <20011205181851.A11036@mark.mielke.cc> <20011205213643.D13350@mark.mielke.cc> <20011205233435.C48954@inl.org> Message-ID: <20011206122904.B16413@mark.mielke.cc> On Wed, Dec 05, 2001 at 11:34:35PM -0800, Tom Holub wrote: > On Wed, Dec 05, 2001 at 09:36:43PM -0500, Mark Mielke wrote: > > So... some of us are believers, and some are non-believers. > Some of us have seen at least three different actual netrek-playing robots > in games against humans. Which means absolutely nothing. One could declare that because the Wright brothers could only have a plane travel across a field a few times, that jets or space craft are an impossibility, so they might as well have given up. Not to associate it with the wonderful ability of being able to fly, which was a gigantic step forward for humanity, and far removed from a mere game such as Netrek, but rather, it is the concept regarding the ability for mankind to thwart the creative abilities of minority groups in an effort to maintain their illusion of reality and stability. What other purpose does it serve? Are you hurt by me spending time doing something that you don't expect I would succeed at? I should hope not. One of the most impressive gains of almost all open source movements is the injection of *new* talent, and *new* ideas. Linus Torvalds wrote a Unix kernel. It worked, but it wasn't really that good. Since then, it has incorporated rather extensive improvements, drivers, and quite a bit else that were likely beyond the ability of Linus Torvalds, perhaps in skill, and definately in terms of time. Development should be encouraged, not discouraged. What do you lose, if the effort is a success? You expect it to fail, you say? One of the other truths about open source, is that only the fanatically ignorant pursue open source for the sake of open source. Open source is not a gospel that grants the wielder a pass into Heaven. People who develop for open source usually do it for one of three primary reasons: 1) Fame, 2) Self improvement, 3) Thrill. While a few of the TODO items will definately be tackled, most people will tend to put their most open source efforts into fields that they believe will increase their fame, increase their self, or because they enjoy doing it. I enjoy the prospects of creating a set of units that will not only co-operate, but act as one, under the premise that I believe it could function sufficiently better than a human team of many, under a very strict, although complicated set of rules, to win most of the time. This is my premise. Your only arguments against are "it's never been done", "human players are more dynamic", and other such statements that actually mean nothing. In an infinite problem space, I suspect humans would definately have a clear advantage of any computer existing at this point in time. Fortunately for me, the Netrek problem space is *not* infinite. Perhaps I won't have the time to make it beat the best INL team. I suspect I could make it beat you. Why? Because if you were truly creative, you would not trample all over anybody else who attempted to be creative, or suggest that a bot could never match the skills of the wonderfully 'clued'. This seems religious in nature. I wonder what would happen if the best INL team *was* beaten by a set of bots? Would the loss in pride by sufficient to cause them to give up Netrek? Or would their ambition cause them to improve to a point where they could beat the bot? I would expect them to pursue the second, assuming they truly appreciated the art of Netrek. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Thu Dec 6 11:32:45 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206140204.911F7172B4@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Thu, Dec 06, 2001 at 09:02:04AM -0500 References: <20011205193721.A169084@cecum.vec.wfubmc.edu> <20011206140204.911F7172B4@denali.ccs.neu.edu> Message-ID: <20011206123245.C16413@mark.mielke.cc> On Thu, Dec 06, 2001 at 09:02:04AM -0500, Jeffrey Nowakowski wrote: > Dave Ahn wrote: > > Broadband is here. > 2000: 9% of online households subscribe to broadband > 2006: 41% One thing you will likely find, is that the type of people who would enjoy a game such as Netrek, are likely the type of people that have put in a fair amount of effort to obtain high speed access of some sort to either their home or work. The only exception here is remote areas of residence, or cities that are not considered to be large enough to fund high speed infrastructure building efforts. People who don't have computers by now, for example, would likely not really care for Netrek. The real world is much more interesting to them. :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From xyzzy at speakeasy.org Thu Dec 6 13:07:48 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206130731.E16413@mark.mielke.cc> Message-ID: On Thu, 6 Dec 2001, Mark Mielke wrote: > You are telling me that I am approaching things from the wrong angle. I > ask you... when was the last time you wrote a bot that could successfully > win against most, if not all INL teams? When was the last time you did it? Freebot was the product of someone's doctoral dissertation, and a team of freebots isn't that hard to beat. I think you'll find, like everyone else who has tried, that writing a good bot for netrek is hard, and making a bot team that can be humans is next to impossible. From ahn at vec.wfubmc.edu Thu Dec 6 13:39:26 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206140204.911F7172B4@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Thu, Dec 06, 2001 at 09:02:04AM -0500 References: <20011205193721.A169084@cecum.vec.wfubmc.edu> <20011206140204.911F7172B4@denali.ccs.neu.edu> Message-ID: <20011206143926.A170270@cecum.vec.wfubmc.edu> On Thu, Dec 06, 2001 at 09:02:04AM -0500, Jeffrey Nowakowski wrote: > Dave Ahn wrote: > > > > Broadband is here. > > 2000: 9% of online households subscribe to broadband > 2006: 41% In terms of sheer numbers, that's 5+ million households as of January 2001 with expectations that it will exceed 7.5M by January 2002. This doesn't include the large number of college students and other people who have high speed access through school or work. > > While a lot of people do have bad connections (including > > modem-only), I think that most people who try out netrek for the first > > time will either already be computer-savvy or be at least network game-savvy. > > I'm not sure how this relates to the discussion at hand. Because netrek's target audience isn't the typical household with children under 12. I can't find the link now, but I recall seeing statistics that a signifant number of households with broadband access play networked games. People who are familiar with broadband and networked games will be more understanding of the concept of lag. So, listing "bad connections" as a reason for having a local client is not very relevant, IMO. > > If their connections are really that bad, then training them for a couple of > > hours on their local servers won't go very far in retaining them when they > > get rewled repeatedly the first time they login to a real server. > > But it will give them a chance to get hooked. When I was stuck on a > dial-up modem, I had a hard time finding a service that would stay > connected for hours at a time. Trying to learn a new game and dealing > with crap like that just sucks. Once a newbie has learned the game > locally, finding an online game that they can play for an hour on > won't be so bad. While it may help the newbie learn the basic commands, I don't think it will get them hooked. Netrek is addictive because you play against people. > Also, it'll be easier to write a tutorial on the local client with a > local server than on a remote server. Remember how > newbie.psychosis.net was turned into a tutorial server? I appreciated > Karthik's efforts, but I doubt it was very helpful to newbies. It wasn't a tutorial server, at least not what I am talking about. > > I don't discount the value of a localized server. > > You just did in your previous message. Yes, in the context of the time and effort spent in writing a localized Java server. If someone is going to spend 50 hours coding, I'd rather see a better, friendlier client than a localized server. If not, I'd rather see the same functionality built on top of existing server rather than rewritten from the ground up on a different platform. If not, then whatever. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From ahn at vec.wfubmc.edu Thu Dec 6 13:45:34 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Netrek? Open source? Encouragement? In-Reply-To: <20011206122904.B16413@mark.mielke.cc>; from mark@mark.mielke.cc on Thu, Dec 06, 2001 at 12:29:04PM -0500 References: <20011205181851.A11036@mark.mielke.cc> <20011205213643.D13350@mark.mielke.cc> <20011205233435.C48954@inl.org> <20011206122904.B16413@mark.mielke.cc> Message-ID: <20011206144534.B170270@cecum.vec.wfubmc.edu> On Thu, Dec 06, 2001 at 12:29:04PM -0500, Mark Mielke wrote: > > This seems religious in nature. I wonder what would happen if the > best INL team *was* beaten by a set of bots? Would the loss in > pride by sufficient to cause them to give up Netrek? Or would their > ambition cause them to improve to a point where they could beat > the bot? I would suggest that you simply write your bots. A good place to start is Hadley's code and paper. See www.netrek.org/developer.html and the link at the top. (If you're not an ACM member, email me and I can send you the paper.) I can guarantee that if you were successful in writing AI heuristics to get a team of robots to win consistently against even an average league team, it would be worthy of publication in ACM or IEEE transactions. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From doosh at inl.org Thu Dec 6 14:08:28 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:47 2005 Subject: [Vanilla List] Netrek as an art. In-Reply-To: <20011206121010.A16413@mark.mielke.cc>; from mark@mark.mielke.cc on Thu, Dec 06, 2001 at 12:10:10PM -0500 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> <20011205234105.E48954@inl.org> <20011206130731.E16413@mark.mielke.cc> Message-ID: <20011206122343.B88643@inl.org> On Thu, Dec 06, 2001 at 01:07:31PM -0500, Mark Mielke wrote: > > The primary benefit being... that cloaking is not an effective technique > against robots that can see right through your cloak. Cloaking is not an effective technique against good players, either. > You are telling me that I am approaching things from the wrong angle. I > ask you... when was the last time you wrote a bot that could successfully > win against most, if not all INL teams? > > How would you know which angle was the wrong one? Scott Drellishak, an early server administrator and author of a netrek-playing bot, once hacked his server to report heuristics on things such as % of phaser hits, % of torps dodged, ability to do things on both sides of the ship, etc. His idea was to attempt to detect robots and borgs based on their tactical characteristics. He found that top players were indistinguishable from borgs and bots. Scott's robot's dodging was probably optimal. Optimal phasering is easy. Optimal torping is fuzzier, but not that important anyway. And his robot sucked at playing netrek. Every ehnancement you've talked about is to tactical stuff which top players, and existing robots, ALREADY DO ALMOST OPTIMALLY. It is extremely unlikely that any amount of tactical work will create a robot which could beat sfd's in a dogfight more than 55% of the time. Perfect tactical play is a SOLVED PROBLEM in netrek, so you can spend the rest of your life working on perfecting tactical play and not get anywhere. If you don't believe me, fine, go waste your time, what do I care? The interesting question is, when you've just won a dogfight at the front, have one kill, 1000 fuel and 20% damage, do you go back to core to pick, go to a front-line fuel planet to refuel, refuel in place, or try to mutual with an enemy, what is the proper thing to do? There is no one answer, and it is EXTREMEMLY DIFFICULT to codify a reasonable decision; there are too many variables. It's not impossible, but if this isn't the part of the problem you're working on, you will not get anywhere with a netrek robot. The game of netrek is about making this kind of multivariate decision CONSTANTLY. -Tom From quozl at us.netrek.org Thu Dec 6 16:27:18 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205233838.H13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 11:38:38PM -0500 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> <20011205233838.H13350@mark.mielke.cc> Message-ID: <20011207092718.M32243@us.netrek.org> On Wed, Dec 05, 2001 at 11:38:38PM -0500, Mark Mielke wrote: > select() is only implemented for sockets. Wrong. I'm using Cygwin. Anyway, it's not relevant, since it is only sockets that the server uses. File I/O can be ignored, in my opinion. > This is not too mention that an event driven system is a system that > switches in user space. What? The switch has to be done somewhere. It is much better if it is under the direct control of the programmer. More efficient. O/S level context switches are by comparison much less efficient, as they unnecessarily save registers. > This complicates the code significantly, and ensures that operations > cannot happen asynchronously. I disagree. Even with threads, on a single CPU, only one thing is happening at once. The Netrek server can support 20 players on a 486, at 100MHz, so it doesn't need a dual processor. > As an example, with the current process model, 16 ntserv processes > can be actively waiting for I/O while the daemon process is executing > code. A wait is not active. If I/O completes, the processes become schedulable, joining the run queue, and while the operating system is entitled to interrupt the daemon in order to process the I/O, most O/S's do not. The daemon will relinquish the processor soon. Now while my experience with operating system design and performance optimisation techniques is limited to OpenVMS and Linux, I would venture to say that the Win32 environment can't be terribly bad at this. > With an event driven system, daemon updates would need to be scheduled, > and when the daemon was performing an update, I/O could become blocked. I'm afraid you don't know what you are talking about. The daemon does the update in less than a tenth of a second. We don't need to process the I/O from the clients during that time, since the results would likely be buffered by the ntserv for inclusion into the next update. The data can wait. > Clients would freeze, and it would all be downhill from there > as the server tried to 'catch up' every time by building a huge > select() mask, 64 bits is not an expensive select mask to build. We're talking machines at least as fast as a 486/100 here. > only to throw it away as soon as it realizes: "Hey, 8 > people have data for me." For more real-time systems such as Netrek, > there is almost always data to be read. Why bother switching yourself, > when you can let the system do it for you? Because system switching costs more CPU cycles. I can guarantee that. Netrek may look real-time, but by comparison to other real-time systems, Netrek is very simple and slow. Only ten updates per second for 20 clients? Big deal. > Threading is very neat and tidy. As I'm sure you are aware, Netrek > already deals with shared memory, which is not really that different > from the way threads function. The details you would need to fiddle > with for threads, is that you would want to avoid using signals to > wake up your threads. Instead, using a conditional, or a wait. Yes, I know how to thread it, but having been there and done both threading and event driven models over my (ahem) 20 years professional programming career, I'm certain that an event driven model would be - easier to maintain, - just as effective, - cheaper to build, - simpler to debug, (lack of concurrency and race issues) - more efficient than a threaded model. Please, could you spare the time to read the presentation by John Ousterhout, entitled "Why Threads Are A Bad Idea (for most purposes)", which can be found at http://www.softpanorama.org/People/Ousterhout/Threads/ It is only 15 slides. I've just reviewed it again and concluded: - Netrek does not need true CPU concurrency. - Netrek does not need to restrict the developer base by choosing a difficult technology. We need to do the reverse. - Netrek is not a place in which we should demonstrate our coding prowess for an examiner. We're not a training ground. > I suspect it would take less time to make the server threaded, than it > would take to make it event driven. You start on the threading, I'll start on the event driven model. Show us the code. Who will judge between us? I'm worried that you're only discussing this in order to get me to act. It's a conspiracy. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Thu Dec 6 15:48:50 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011205232253.G13350@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 05, 2001 at 11:22:53PM -0500 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> Message-ID: <20011207084850.L32243@us.netrek.org> Mark's analysis shows that the randomised position generated by the server for each cloaked player should be generated once per turn rather than once per client per turn. Added to PROJECTS. Low priority. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From brian at thePaulsens.com Thu Dec 6 14:42:21 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures References: Message-ID: <006901c17e96$81bc9ae0$0200a8c0@lehman.com> Ok. I have to step in here... I wrote Freebot and I pretty aware of what it can and can't do. First, it was not part of a doctoral dissertation. It was a product of a bunch of free time that I had on my hands. The code was greatly geared towards being the ultimate dogfighter and I began adding some code to have it try to do things like take planets. As such, I'm willing to bet that there isn't a person around who can out dogfight the thing. And I'm willing to bet that there are few INL teams that couldn't beat a team of Freebots. Could it geno a team of Freebots? I don't know. As far as I know, the only time that anybody has played against a team of Freebots was very early in the coding of the thing. At that time, it had numerous dogfighting bugs which made it a bit easier to kill. The way I see it, any bot should easily beat any human in a dogfight. Given this, the strategy of a bot team may be greatly different than that of a human team. Also, a first goal of a bot team may be to win the front line and the agris and then just maintain that. I wouldn't worry at all about trying to knock a team past the core planets. When I get a chance, I'll release the bot code that I have as public source and we can build on top of that. Brian ----- Original Message ----- From: "Trent Piepho" To: Sent: Thursday, December 06, 2001 2:07 PM Subject: Re: [Vanilla List] Growing Netrek - Measures > On Thu, 6 Dec 2001, Mark Mielke wrote: > > You are telling me that I am approaching things from the wrong angle. I > > ask you... when was the last time you wrote a bot that could successfully > > win against most, if not all INL teams? > > When was the last time you did it? > > Freebot was the product of someone's doctoral dissertation, and a team of > freebots isn't that hard to beat. I think you'll find, like everyone else who > has tried, that writing a good bot for netrek is hard, and making a bot team > that can be humans is next to impossible. > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From brian at thePaulsens.com Thu Dec 6 14:42:37 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures References: Message-ID: <007e01c17e96$9d124920$0200a8c0@lehman.com> Ok. I have to step in here... I wrote Freebot and I pretty aware of what it can and can't do. First, it was not part of a doctoral dissertation. It was a product of a bunch of free time that I had on my hands. The code was greatly geared towards being the ultimate dogfighter and I began adding some code to have it try to do things like take planets. As such, I'm willing to bet that there isn't a person around who can out dogfight the thing. And I'm willing to bet that there are few INL teams that couldn't beat a team of Freebots. Could it geno a team of Freebots? I don't know. As far as I know, the only time that anybody has played against a team of Freebots was very early in the coding of the thing. At that time, it had numerous dogfighting bugs which made it a bit easier to kill. The way I see it, any bot should easily beat any human in a dogfight. Given this, the strategy of a bot team may be greatly different than that of a human team. Also, a first goal of a bot team may be to win the front line and the agris and then just maintain that. I wouldn't worry at all about trying to knock a team past the core planets. When I get a chance, I'll release the bot code that I have as public source and we can build on top of that. Brian ----- Original Message ----- From: "Trent Piepho" To: Sent: Thursday, December 06, 2001 2:07 PM Subject: Re: [Vanilla List] Growing Netrek - Measures > On Thu, 6 Dec 2001, Mark Mielke wrote: > > You are telling me that I am approaching things from the wrong angle. I > > ask you... when was the last time you wrote a bot that could successfully > > win against most, if not all INL teams? > > When was the last time you did it? > > Freebot was the product of someone's doctoral dissertation, and a team of > freebots isn't that hard to beat. I think you'll find, like everyone else who > has tried, that writing a good bot for netrek is hard, and making a bot team > that can be humans is next to impossible. > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From brian at thePaulsens.com Thu Dec 6 14:46:54 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures References: Message-ID: <009f01c17e97$2d93b1a0$0200a8c0@lehman.com> Ok. I have to step in here... I wrote Freebot and I pretty aware of what it can and can't do. First, it was not part of a doctoral dissertation. It was a product of a bunch of free time that I had on my hands. The code was greatly geared towards being the ultimate dogfighter and I began adding some code to have it try to do things like take planets. As such, I'm willing to bet that there isn't a person around who can out dogfight the thing. And I'm willing to bet that there are few INL teams that couldn't beat a team of Freebots. Could it geno a team of Freebots? I don't know. As far as I know, the only time that anybody has played against a team of Freebots was very early in the coding of the thing. At that time, it had numerous dogfighting bugs which made it a bit easier to kill. The way I see it, any bot should easily beat any human in a dogfight. Given this, the strategy of a bot team may be greatly different than that of a human team. Also, a first goal of a bot team may be to win the front line and the agris and then just maintain that. I wouldn't worry at all about trying to knock a team past the core planets. When I get a chance, I'll release the bot code that I have as public source and we can build on top of that. Brian ----- Original Message ----- From: "Trent Piepho" To: Sent: Thursday, December 06, 2001 2:07 PM Subject: Re: [Vanilla List] Growing Netrek - Measures > On Thu, 6 Dec 2001, Mark Mielke wrote: > > You are telling me that I am approaching things from the wrong angle. I > > ask you... when was the last time you wrote a bot that could successfully > > win against most, if not all INL teams? > > When was the last time you did it? > > Freebot was the product of someone's doctoral dissertation, and a team of > freebots isn't that hard to beat. I think you'll find, like everyone else who > has tried, that writing a good bot for netrek is hard, and making a bot team > that can be humans is next to impossible. > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From doosh at inl.org Thu Dec 6 17:37:35 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207092718.M32243@us.netrek.org>; from quozl@us.netrek.org on Fri, Dec 07, 2001 at 09:27:18AM +1100 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> <20011205233838.H13350@mark.mielke.cc> <20011207092718.M32243@us.netrek.org> Message-ID: <20011206153735.A2558@inl.org> On Fri, Dec 07, 2001 at 09:27:18AM +1100, James Cameron wrote: > > Please, could you spare the time to read the presentation by John > Ousterhout Go Bears! -Tom From Darryl_Palmer_Jr at acm.org Thu Dec 6 17:49:49 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207092718.M32243@us.netrek.org> Message-ID: It seems that there are more posts in 2 days for this list then there was last month. I want to put the bots and other crap aside for a moment and discuss the topic of Scenarios. What would be the idea scenarios/tutorials that we should have in order to train a newbie? Has anyone given this an idea before or have something in place for training INL or WNL team member newbies? I think Tom discussed this topic before, last year or so, and had scenarios like protecting a planet in a CA that was at 1 from a cloaked scout and such. Darryl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011206/966a13ec/smime.bin From Darryl_Palmer_Jr at acm.org Thu Dec 6 17:54:33 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: Message-ID: I think it was Brian Paulsen that wrote Freebot. Maybe some of the old timers remember. As far as I remember the code was not in the public domain, and he just let some individuals use it for testing or logging or something like that. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Trent Piepho Sent: Thursday, December 06, 2001 1:08 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] Growing Netrek - Measures On Thu, 6 Dec 2001, Mark Mielke wrote: > You are telling me that I am approaching things from the wrong angle. I > ask you... when was the last time you wrote a bot that could successfully > win against most, if not all INL teams? When was the last time you did it? Freebot was the product of someone's doctoral dissertation, and a team of freebots isn't that hard to beat. I think you'll find, like everyone else who has tried, that writing a good bot for netrek is hard, and making a bot team that can be humans is next to impossible. _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011206/25866589/smime.bin From ahn at vec.wfubmc.edu Thu Dec 6 18:11:35 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207092718.M32243@us.netrek.org>; from quozl@us.netrek.org on Fri, Dec 07, 2001 at 09:27:18AM +1100 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> <20011205233838.H13350@mark.mielke.cc> <20011207092718.M32243@us.netrek.org> Message-ID: <20011206191134.A171049@cecum.vec.wfubmc.edu> On Fri, Dec 07, 2001 at 09:27:18AM +1100, James Cameron wrote: > Yes, I know how to thread it, but having been there and done both > threading and event driven models over my (ahem) 20 years professional > programming career, I'm certain that an event driven model would be "Sonny, back when I was a young man..." > - Netrek does not need to restrict the developer base by choosing a > difficult technology. We need to do the reverse. > http://www.softpanorama.org/People/Ousterhout/Threads/ http://www.softpanorama.org/People/Ousterhout/Threads/sld005.htm That's pretty funny. Wizard? Who calls programmers wizards these days? I feel like I should grow a long(er) beard, put on a robe and wave my large cane like an old geezer. Wait a minute, I'm already a crusty old ... > You start on the threading, I'll start on the event driven model. > Show us the code. Who will judge between us? There is no real conceptual difference between using processes + signals + shm and threads + condition variables, both of which can be used to simulate an event driven model under MP/MT. I think the main reason to stay with processes is because it gives us isolation. ntserv still has bugs, and it's a good thing that a segfault doesn't crash daemonII and other ntserv's. Threads will hurt us there. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From doosh at inl.org Thu Dec 6 19:31:21 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:48 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207084850.L32243@us.netrek.org>; from quozl@us.netrek.org on Fri, Dec 07, 2001 at 08:48:50AM +1100 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> <20011205234105.E48954@inl.org> <20011206121010.A16413@mark.mielke.cc> <20011206120828.A88643@inl.org> Message-ID: <20011207002806.A18897@mark.mielke.cc> On Thu, Dec 06, 2001 at 12:08:28PM -0800, Tom Holub wrote: > On Thu, Dec 06, 2001 at 12:10:10PM -0500, Mark Mielke wrote: > > Don't assume that because others have failed, or that because you suspect > > you would fail, that it is not possible. > I suspect YOU will fail. If the problem interested me, I'm sure I could > do a better job than you, but I think it's an extremely difficult problem. What do you jump on anything that doesn't fit in your park? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Thu Dec 6 23:37:41 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from xyzzy@speakeasy.org on Thu, Dec 06, 2001 at 11:07:48AM -0800 References: <20011206130731.E16413@mark.mielke.cc> Message-ID: <20011207003741.B18897@mark.mielke.cc> On Thu, Dec 06, 2001 at 11:07:48AM -0800, Trent Piepho wrote: > On Thu, 6 Dec 2001, Mark Mielke wrote: > > You are telling me that I am approaching things from the wrong angle. I > > ask you... when was the last time you wrote a bot that could successfully > > win against most, if not all INL teams? > When was the last time you did it? There is always room for a first time if ones tries. There is never room for a first time, if one doesn't bother to try. If all research and theories were based entirely on existing research and implementations, progress would be impossible. There are only so many ways you can fiddle equations around, until you realize you need to invent a new type of math. > Freebot was the product of someone's doctoral dissertation, and a > team of freebots isn't that hard to beat. I think you'll find, like > everyone else who has tried, that writing a good bot for netrek is > hard, and making a bot team that can be humans is next to > impossible. Perhaps. However, I note the difference between your pessimism, and Tom's outright disrespect. :-) I thank you for this respect. I will attempt to put it to good use. There is certainly no harm in trying. If a few people here wish to put in some time, I still have quite a few ideas. Worst possible case -- there are quite a few things to learn from the attempt. Any and all participants, including myself, will have grown in the attempt. For those that find the idea intriguing, it is even potentially possible that the attempt could be enjoyed. Or, we could put our tails between our legs and crawl away from the obviously omnipotent Tom. :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Thu Dec 6 23:40:23 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <006901c17e96$81bc9ae0$0200a8c0@lehman.com>; from brian@thePaulsens.com on Thu, Dec 06, 2001 at 03:42:21PM -0500 References: <006901c17e96$81bc9ae0$0200a8c0@lehman.com> Message-ID: <20011207004023.C18897@mark.mielke.cc> Personally, I would appreciate reading through it. If you had any more time, I would welcome you to be part of an effort to build a 'bot that could at least provide fair competition (50%/50% chance of winning) to the best INL teams that still exist. If you have no time, or have since become bored with the idea, that's ok as well. mark On Thu, Dec 06, 2001 at 03:42:21PM -0500, Brian Paulsen wrote: > Ok. I have to step in here... > > I wrote Freebot and I pretty aware of what it can and can't do. > > First, it was not part of a doctoral dissertation. It was a product of a > bunch of free time that I had on my hands. The code was greatly geared > towards being the ultimate dogfighter and I began adding some code to have > it try to do things like take planets. > > As such, I'm willing to bet that there isn't a person around who can out > dogfight the thing. And I'm willing to bet that there are few INL teams > that couldn't beat a team of Freebots. Could it geno a team of Freebots? I > don't know. > > As far as I know, the only time that anybody has played against a team of > Freebots was very early in the coding of the thing. At that time, it had > numerous dogfighting bugs which made it a bit easier to kill. > > The way I see it, any bot should easily beat any human in a dogfight. Given > this, the strategy of a bot team may be greatly different than that of a > human team. Also, a first goal of a bot team may be to win the front line > and the agris and then just maintain that. I wouldn't worry at all about > trying to knock a team past the core planets. > > When I get a chance, I'll release the bot code that I have as public source > and we can build on top of that. > > Brian > > ----- Original Message ----- > From: "Trent Piepho" > To: > Sent: Thursday, December 06, 2001 2:07 PM > Subject: Re: [Vanilla List] Growing Netrek - Measures > > > > On Thu, 6 Dec 2001, Mark Mielke wrote: > > > You are telling me that I am approaching things from the wrong angle. I > > > ask you... when was the last time you wrote a bot that could > successfully > > > win against most, if not all INL teams? > > > > When was the last time you did it? > > > > Freebot was the product of someone's doctoral dissertation, and a team of > > freebots isn't that hard to beat. I think you'll find, like everyone else > who > > has tried, that writing a good bot for netrek is hard, and making a bot > team > > that can be humans is next to impossible. > > > > _______________________________________________ > > vanilla-list mailing list > > vanilla-list@us.netrek.org > > https://mailman.real-time.com/mailman/listinfo/vanilla-list > > > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Thu Dec 6 23:44:20 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206122343.B88643@inl.org>; from doosh@inl.org on Thu, Dec 06, 2001 at 12:23:43PM -0800 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> <20011205234105.E48954@inl.org> <20011206130731.E16413@mark.mielke.cc> <20011206122343.B88643@inl.org> Message-ID: <20011207004420.D18897@mark.mielke.cc> On Thu, Dec 06, 2001 at 12:23:43PM -0800, Tom Holub wrote: > Every ehnancement you've talked about is to tactical stuff which top > players, and existing robots, ALREADY DO ALMOST OPTIMALLY. It is > extremely unlikely that any amount of tactical work will create a > robot which could beat sfd's in a dogfight more than 55% of the time. > Perfect tactical play is a SOLVED PROBLEM in netrek, so you can spend > the rest of your life working on perfecting tactical play and not get > anywhere. If you don't believe me, fine, go waste your time, what do > I care? First off... you assume that existing robots are the best. For anybody who has lived on this planet for any length of time, one of the first lessons to be learned is that one is almost guaranteed to find 'better' in any category. Secondly, you make my point exactly. Why do you care what I 'waste' my time on? Seriously. Why is this such a hot issue with you? Will it bust your balls to see a group of people attempt to make the best 'bot ever seen? Why not be encouraging, or at least withhold a little bit of your rage? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Thu Dec 6 23:46:18 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207084850.L32243@us.netrek.org>; from quozl@us.netrek.org on Fri, Dec 07, 2001 at 08:48:50AM +1100 References:

<20011205181851.A11036@mark.mielke.cc> <20011205165504.A27009@inl.org> <20011205232253.G13350@mark.mielke.cc> <20011207084850.L32243@us.netrek.org> Message-ID: <20011207004618.E18897@mark.mielke.cc> On Fri, Dec 07, 2001 at 08:48:50AM +1100, James Cameron wrote: > Mark's analysis shows that the randomised position generated by the > server for each cloaked player should be generated once per turn rather > than once per client per turn. > > Added to PROJECTS. Low priority. :-) There are half a dozen others that I might neglect to mention, at least until we have a team of bots that can beat Tom... I can't let you take away all my fun. Staring at Netrek server code for hours on end 10 years ago should provide me at least a little bit of advantage... :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From quozl at us.netrek.org Fri Dec 7 00:05:06 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011206191850.A16402@inl.org>; from doosh@inl.org on Thu, Dec 06, 2001 at 07:18:50PM -0800 References: <20011206173121.A9564@inl.org> <20011206191850.A16402@inl.org> Message-ID: <20011207170506.S32243@us.netrek.org> On Thu, Dec 06, 2001 at 07:18:50PM -0800, Tom Holub wrote: > What I'm saying is that I think it could have an effect on human players. > If there are two base defenders and a base trying to phaserlock cloakers, > they are going to react differently if they're all getting the same > incorrect position, compared to if they're all getting different incorrect > positions. Yeah, okay, I agree. I withdraw it. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From mark at mark.mielke.cc Fri Dec 7 00:04:13 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Netrek? Open source? Encouragement? In-Reply-To: <20011206144534.B170270@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Thu, Dec 06, 2001 at 02:45:34PM -0500 References: <20011205181851.A11036@mark.mielke.cc> <20011205213643.D13350@mark.mielke.cc> <20011205233435.C48954@inl.org> <20011206122904.B16413@mark.mielke.cc> <20011206144534.B170270@cecum.vec.wfubmc.edu> Message-ID: <20011207010413.F18897@mark.mielke.cc> On Thu, Dec 06, 2001 at 02:45:34PM -0500, Dave Ahn wrote: > On Thu, Dec 06, 2001 at 12:29:04PM -0500, Mark Mielke wrote: > > This seems religious in nature. I wonder what would happen if the > > best INL team *was* beaten by a set of bots? Would the loss in > > pride by sufficient to cause them to give up Netrek? Or would their > > ambition cause them to improve to a point where they could beat > > the bot? > I would suggest that you simply write your bots. A good place to start > is Hadley's code and paper. See www.netrek.org/developer.html and the > link at the top. (If you're not an ACM member, email me and I can send > you the paper.) I can guarantee that if you were successful in writing > AI heuristics to get a team of robots to win consistently against even > an average league team, it would be worthy of publication in ACM or IEEE > transactions. I've wrote a bot about 10 years ago. Nobody on the Internet has seen it, as I only used it on the internal Nortel Networks (used to be BNR) Netrek servers. This was before the day of RSA in Netrek, back when it was ridiculously easy to reverse engineer the reserved.c code even on a stripped binary. I was almost found at when it phasered a few too many plasmas at ass-range, before the plasma left the docking bay of the other ship. The first time, the guy considered it luck. The third time, he complained. My message to ALL, "but only blessed clients are allowed on this server, are you just pissed that I'm better than you" only bought me a few weeks of borg-playing time... :-) My bot was hard at first, but after studying it for several weeks, and actually playing it, I realized that the problem wasn't with the basic strategies. The problem was direction. Independent decisions are often redundant, severely limiting the abilities of a bot "team". My next attempt will not be along the lines of a traditional bot. All of these have failed, because they are based on enhancing the existing client here and there. A true bot is not the same as a fully automated borg ship. "Auto-pilot" can only bring things so far. No, my next attempt will have a single process (although not necessarily single-threaded) act as all 8 clients. Any inputs from the server will be kept distinct only for the purpose of maintaining accuracy regarding the source of the pieces of information. For the most part, *all* actions will be co-ordinated from a single process. This single process would co-ordinate which ships should go where, which ships torps where, etc. Each ship will be an arm or leg to the master mind bot. Instead of having 8 borgs on auto-pilot all trying to guess what they should do, we have a single monster bot with 8 appendages, who assimilates all information available to it, and decides what to do based on this input. This has incredible potential even for dog-fights. Why have two ships torping an incoming ship independently, when the two ships could alternate torpedoes creating an impenetrable wall of torpedoes, while minimizing fuel consumption? I wonder how easy it would be for an INL team to take planets, if they can't manage to get a single kill? I have a vision. Unfortunately, I have a restricted time budget. Fortunately, I believe that many other interested parties exist who are all adequately skilled, and easily motivated by sheer intrigue... This is what I love about open source. It isn't about software being free and available. It is about talent sharing, where everybody can learn from everybody else. The applications are just a side benefit. I don't mind paying for good software. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Fri Dec 7 00:27:00 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207092718.M32243@us.netrek.org>; from quozl@us.netrek.org on Fri, Dec 07, 2001 at 09:27:18AM +1100 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> <20011205233838.H13350@mark.mielke.cc> <20011207092718.M32243@us.netrek.org> Message-ID: <20011207012700.G18897@mark.mielke.cc> On Fri, Dec 07, 2001 at 09:27:18AM +1100, James Cameron wrote: > On Wed, Dec 05, 2001 at 11:38:38PM -0500, Mark Mielke wrote: > > select() is only implemented for sockets. > Wrong. I'm using Cygwin. Anyway, it's not relevant, since it is only > sockets that the server uses. File I/O can be ignored, in my opinion. Worse, select() is emulated in CYGWIN. It will be your true bottle neck. Then again, I suppose what other purpose do some P4 1.6Ghz machines have other than spending 90% of their CPU emulating UNIX with CYGWIN to run a Netrek server... :-) > > This is not too mention that an event driven system is a system that > > switches in user space. > What? The switch has to be done somewhere. It is much better if it > is under the direct control of the programmer. More efficient. O/S > level context switches are by comparison much less efficient, as they > unnecessarily save registers. Often this is true. The reason why it is true is that most people are not familiar with programming in a threaded environment, and often end up serializing critical sections that should not be as large as they are. In terms of potential, a threaded program has significant gains over a process switched program. What are these gains? 5 processes can be performing rights at the same time, while the 6th is performing calculations. In a multi-CPU machine, a 7th or 8th process can also be performing calculations. Some systems support asynchronous I/O. I have not seen asynchronous I/O be used by any major (UNIX) products in existence. With select(), one can only perform a single read()/write() at a time, and CPU operations such as daemon updates need to be scheduled between these system calls. Sure, larger system buffers can improve performance, but for a real time system with a large amount of data being actively transferred back and forth between 16 or more clients... performance will suffer significantly. > > This complicates the code significantly, and ensures that operations > > cannot happen asynchronously. > I disagree. Even with threads, on a single CPU, only one thing is > happening at once. The Netrek server can support 20 players on a 486, > at 100MHz, so it doesn't need a dual processor. This is not actually true. 16 ntserv processes can be performing write() operations while the daemon is updating, or the robot is determining its next move. Move to a single threaded single process event driven model, and this is no longer true. > > As an example, with the current process model, 16 ntserv processes > > can be actively waiting for I/O while the daemon process is executing > > code. > A wait is not active. If I/O completes, the processes become schedulable, > joining the run queue, and while the operating system is entitled to > interrupt the daemon in order to process the I/O, most O/S's do not. > The daemon will relinquish the processor soon. A wait *can* be active. Consider read()/write(). Waiting for a write() to complete doesn't mean that nothing is happening. In an event driven model, waiting for select() *is* waiting. > Now while my experience with operating system design and performance > optimisation techniques is limited to OpenVMS and Linux, I would venture > to say that the Win32 environment can't be terribly bad at this. In some ways the win32 environment is significantly better, in others it is quite worse. In any case, CYGWIN is an emulation layer, and you can therefore expect worse performance. > > With an event driven system, daemon updates would need to be scheduled, > > and when the daemon was performing an update, I/O could become blocked. > I'm afraid you don't know what you are talking about. The daemon does the > update in less than a tenth of a second. We don't need to process the I/O > from the clients during that time, since the results would likely be > buffered by the ntserv for inclusion into the next update. The data can > wait. I don't mean blocked as in a write() blocking. I mean blocked, as in no data can be transferred between any of the clients and the server. For "less than a tenth of a second", "10 times a second", the server will be unable to exchange data. Just think about it for a bit. > > only to throw it away as soon as it realizes: "Hey, 8 > > people have data for me." For more real-time systems such as Netrek, > > there is almost always data to be read. Why bother switching yourself, > > when you can let the system do it for you? > Because system switching costs more CPU cycles. I can guarantee that. > Netrek may look real-time, but by comparison to other real-time systems, > Netrek is very simple and slow. Only ten updates per second for 20 > clients? Big deal. 1) The system is currently written to access shared memory. This is practically already a threaded model. An event driven model, by comparison, is far different. 2) Computers these days have Gbytes of hard drive, and Ghz of timer ticks. Therefore, let's make Netscape 50 Mbytes big in memory just to display a simple HTML page. Throw in XEmacs, and Microsoft Office. After all, we can always tell our customer to buy a bigger machine... This line of thinking has a critical point that shouldn't be passed. > > Threading is very neat and tidy. As I'm sure you are aware, Netrek > > already deals with shared memory, which is not really that different > > from the way threads function. The details you would need to fiddle > > with for threads, is that you would want to avoid using signals to > > wake up your threads. Instead, using a conditional, or a wait. > Yes, I know how to thread it, but having been there and done both > threading and event driven models over my (ahem) 20 years professional > programming career, I'm certain that an event driven model would be > - easier to maintain, > - just as effective, > - cheaper to build, > - simpler to debug, (lack of concurrency and race issues) > - more efficient than a threaded model. I don't know why it would be easier to maintain, when Netrek already uses shared memory. As for 'just as effective', this remains to be seen. Cheaper to build? Why would changing the model be cheaper to build? More efficient? Only if the threaded model was not done properly. Simpler to debug? Yes. > - Netrek does not need to restrict the developer base by choosing a > difficult technology. We need to do the reverse. Most people should have pthreads by now. > - Netrek is not a place in which we should demonstrate our coding > prowess for an examiner. We're not a training ground. So leave it as is than. Just as many people misunderstand event loops as misunderstand threading. > > I suspect it would take less time to make the server threaded, than it > > would take to make it event driven. > You start on the threading, I'll start on the event driven model. > Show us the code. Who will judge between us? Hmmm... :-) > I'm worried that you're only discussing this in order to get me to act. > It's a conspiracy. ;-) It's entirely possible... Tell you what... I'm leaving for Australia for my Christmas vacation. At least some of those days (Dec. 19th -> Jan 4th) I'll probably be pretty bored. You do your event driven model, and I'll do the thread model. We'll see which patch is smaller... :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From damouth at san.rr.com Fri Dec 7 00:51:36 2001 From: damouth at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Bots and bot teams References: <20011206173121.A9564@inl.org> <20011206191850.A16402@inl.org> Message-ID: <006d01c17eeb$9d5cbf00$3b824b42@san.rr.com> From: "Tom Holub" > On Thu, Dec 06, 2001 at 06:29:24PM -0800, Trent Piepho wrote: > > I think what he saying is that each client should receive the same random > > position, so that multiple clients can't communicate and derive more > > information. It really would have no effect on human players with non-borg > > clients. > > What I'm saying is that I think it could have an effect on human players. > If there are two base defenders and a base trying to phaserlock cloakers, > they are going to react differently if they're all getting the same > incorrect position, compared to if they're all getting different incorrect > positions. I agree with Tom and I think the randomization code should be left the way it is. I do this "averaging" in my head based on where I see my teammates aiming. It's a cool little thing about the game, IMO. If I ever write my bot team, my goal will be to make them as intelligent as possible, not to take advantage of the computer's faster reacion time or instant communications with other bots. If I were using Freebot, and if it is as good at fighting as is claimed here (i.e. if it's noticably better than me), I might even tone it down. Incidentally, last weekend I had dinner with old friends Marc Huber and Mike van Lent (we were Ph.D. candidates together at the Michigan AI lab; they actually completed their degrees). Mike is considering writing a book on AI and computer games, and Marc and I were trying to get him to include a chapter on netrek. As far as I know, Marc's bot team is the only one that was an integral part of a doctoral dissertation in AI, and his focus was limited to "plan recognition" (his bots tried to infer what other players were doing by observing their behavior). So he never spent much time trying to optimize his team to play its best against real teams. The problem is more difficult than you probably think, but it's certainly a worthwhile endeavor :) I would really like to have a go at it, but I'm afraid of starting something I won't be able to follow through on. Perhaps if it were a competition... say, Freebot gets released for everyone to use, and we have a robot team ladder system, or even just periodic contests. We could put together a basic downloadable Freebot team, make it available, and people could have fun tweaking or developing from there. Dan Damouth From mark at mark.mielke.cc Fri Dec 7 00:53:28 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Scenarios In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Thu, Dec 06, 2001 at 05:49:49PM -0600 References: <20011207092718.M32243@us.netrek.org> Message-ID: <20011207015328.H18897@mark.mielke.cc> On Thu, Dec 06, 2001 at 05:49:49PM -0600, Darryl Palmer Jr wrote: > It seems that there are more posts in 2 days for this list then there was > last month. I want to put the bots and other crap aside for a moment and > discuss the topic of Scenarios. > What would be the idea scenarios/tutorials that we should have in order to > train a newbie? Has anyone given this an idea before or have something in > place for training INL or WNL team member newbies? > I think Tom discussed this topic before, last year or so, and had > scenarios like protecting a planet in a CA that was at 1 from a cloaked > scout and such. As I recall, there existing a few training documents that described what words meant, and basic strategies. Other games would often detail these strategies in the client, and set up a scenario. For example: Start the player as a FED CA near Earth. If desirable, hide the other three empires from the galaxy map to reduce confusion. Display: "In this training session you will learn from the following topics: 1) Basic movement. 2) Basic combat. 3) Information gathering. 4) Resource utilization. 5) Empire expansion. 6) Ship classes. ... [OK] " Display: "Basic movement ============== You will notice that your ship is not currently moving. The Netrek universe does not contain momentum or gravity. To start moving, you must specify a speed that you wish your ship to attempt to reach. The speed is represented as a unit of warp. To move at "warp 5", push "5" on your keyboard. -- Push '5' on your keyboard -- " Wait for '5' to be pushed. Display: "Your ship will take time to get to warp 5. Different ship classes will take a different amount of time to accelerate. Now that you are at warp 5, ... " Ok... anyways... you get the idea... somewhere in there it should describe how to adjust direction, and show the user how it is harder to turn at higher speeds. Perhaps it could teach about the tractor beam and the pressor beam by placing an enemy within range. It could teach about locking by having the player lock on a planet and travel to it. Once aborting the planet, it could tell the player to lock on to a hostile planet with around 12 armies on it, and have the player bomb it to less than 4. The player could be told that in order to take a planet with armies <4, the player needs to beam up armies. To beam up armies, the player needs a kill. Offer a dummy ship to kill to grant a kill, teach them about torpedoes, phaser, etc. After having enough dummy ships killed, the player can beam up armies, be told to lock on to the enemy planet, bomb it again, and beam down. After taking the planet, it could send in another player at the edge of the tactical shooting torpedoes. It could tell the player to use the cloak to hide their position and flee. The dummy player would stop torping the instant the player cloaked. Later lessons could include effective use of the plasma, pilotting a starbase, guarding a planet, detecting a cloaker, ogging an enemy, etc. Technique would be emphasized, more than reflexes. This is, after all, perhaps the first time they have ever seen Netrek before. (i.e. the robots would not be horribly hard... make them miss a few shots, and have fewer hit points) The final conclusion could throw a whole bunch of the techniques together with very few 'pause' messages. Upon completion, they could have their name registered in some Netrek academy registry available online or something. Think this would be useful? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From quozl at us.netrek.org Fri Dec 7 01:24:33 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:49 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207012700.G18897@mark.mielke.cc>; from mark@mark.mielke.cc on Fri, Dec 07, 2001 at 01:27:00AM -0500 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> <20011205233838.H13350@mark.mielke.cc> <20011207092718.M32243@us.netrek.org> <20011207012700.G18897@mark.mielke.cc> Message-ID: <20011207182433.T32243@us.netrek.org> On Fri, Dec 07, 2001 at 01:27:00AM -0500, Mark Mielke wrote: > This is not actually true. 16 ntserv processes can be performing > write() operations while the daemon is updating, or the robot is > determining its next move. Move to a single threaded single process > event driven model, and this is no longer true. A write() is cheap. It just passes data down to the TCP/IP stack. We'd never write() if it would block, the socket would be set to non-blocking mode. So I don't agree with the performance penalty. > A wait *can* be active. Consider read()/write(). Waiting for a write() to > complete doesn't mean that nothing is happening. In an event driven model, > waiting for select() *is* waiting. No, I think we're talking cross-purposes here. In an event driven model, the select() is where the waiting for the write() to complete is happening. If anything else happens then we stop waiting immediately. > In some ways the win32 environment is significantly better, in others it > is quite worse. In any case, CYGWIN is an emulation layer, and you can > therefore expect worse performance. I can believe that! > I don't mean blocked as in a write() blocking. I mean blocked, as in > no data can be transferred between any of the clients and the > server. For "less than a tenth of a second", "10 times a second", the > server will be unable to exchange data. Just think about it for a bit. I did. It didn't worry me at all. It never worried Netrek players before. > 1) The system is currently written to access shared memory. This is > practically already a threaded model. An event driven model, by > comparison, is far different. That, I admit, is the best reason for threading. Dave pointed that out to me on IRC. However his mail to the list makes a much more important point out of stability by separation of process spaces. > > - Netrek does not need to restrict the developer base by choosing a > > difficult technology. We need to do the reverse. > > Most people should have pthreads by now. Yes, they have it. They don't code in it though. I'm thinking of people wanting to help out. I don't want a large clue barrier. > Tell you what... I'm leaving for Australia for my Christmas > vacation. At least some of those days (Dec. 19th -> Jan 4th) I'll > probably be pretty bored. You do your event driven model, and I'll do > the thread model. We'll see which patch is smaller... :-) Why not drop in? I'm in Australia. We could go down to the pub and draw diagrams on the wall. ;-) I'm six hours drive from Sydney, in what the Sydney people would call the outback. Other interesting things in this area include an emu farm, a national park, a historic hamlet, and a few professional telescope installations. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From mindmeld at bunkerhill.dyndns.org Fri Dec 7 03:49:52 2001 From: mindmeld at bunkerhill.dyndns.org (Gerard Lim) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] any growth on this? Message-ID: <20011207044952.B26527@bunkerhill.dyndns.org> I'm attaching a table that summarises a few things about most of the options we are likely to encounter (there are lots of them, most of which I do not know the purpose of). As you said, the conditional nature of some options does not let us know all of them, so it probably isn't a complete list. Two important options that were missed: metaserver (oops, didnt do -m) and useRSA (cos I don't have it). I think it would probably make it easier for us to declare and define all the client options (as variables) in one place: defaults.[ch] or data.[ch]? I think most of the int and boolean defaults are in data.[ch] already. Although I think getdefault and it's ilk would have to be modified to work with this, one way is to modify it's behaviour to almost never return NULL but to lookup in some sort of list whether that option it is being asked to look up is known to it, and to return that instead. No functional difference, and I predict nothing will break but it is something of an improvement to have all the options consolidated in one place. It would even be possible to dump a netrekrc based on what's in those header files. Theoretically, it should also be easier for us to write the config program. However, there are many options still not easily found, other than by searching through the code (if it's there at all), or in the stock netrekrc distributed with the client. There's a perl script that prints the table, and some modifications to the client to track calls to getdefault and its variants (not commited to the repository). gerard N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * G arrowCursorDef NULL * * * I autoquit 60 quittime 60 * G b1keymap NULL * G b2keymap NULL * G b3keymap NULL * * B backgroundPix 1 1 * * I baseLocalPort 0 baseLocalPort 0 * * G bigfont NULL * G boldfont NULL * * G buttonmap NULL G buttonmap-as NULL G buttonmap-att NULL G buttonmap-bb NULL G buttonmap-ca NULL G buttonmap-dd NULL G buttonmap-default NULL G buttonmap-ga NULL G buttonmap-sb NULL G buttonmap-sc NULL * * B censorMessages 0 censorMessages 0 * * G ckeymap NULL * G ckeymap-as NULL G ckeymap-att NULL * G ckeymap-bb NULL * G ckeymap-ca NULL * G ckeymap-dd NULL G ckeymap-default NULL G ckeymap-ga NULL * G ckeymap-sb NULL * G ckeymap-sc NULL * G cloakChars NULL * * B cloakPix 1 1 * G color.black NULL N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * G color.cyan NULL * G color.Fed NULL * G color.green NULL * G color.Ind NULL * G color.Kli NULL * G color.light grey NULL * G color.Ori NULL * G color.red NULL * G color.Rom NULL * G color.white NULL * G color.yellow NULL * * B colorgalactic 1 1 * * B continuetractor 1 continuetractor 1 * * * B continuousMouse 0 motion_mouse 0 * * * B DefLite 0 DefLite 0 * G documentation NULL G DocWin.geometry NULL G DocWin.parent NULL * * I enemyPhasers 1 enemyPhasers 1 * * B explosionPix 1 1 * * * B extraAlertBorder 1 extraBorder 1 G FED.geometry NULL B FED.mapped 0 G FED.parent NULL * * B fedPix 1 1 * G font NULL * * * B forcemono 0 forceMono * G help.geometry NULL B help.mapped 0 * G help.parent NULL * * B highlightFriendlyPhasers 0 highlightFriendlyPhasers 0 * * * B ignoreCaps 1 ignoreCaps 1 * * * B ignoreSignals 0 ignore_signals 0 N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * * B indPix 1 1 G info.geometry NULL B info.mapped 0 G info.parent NULL * G infoCursorDef NULL * G italicfont NULL * * * I keepInfo 15 keepInfo 15 * * * B keeppeace 0 keeppeace 0 * * G keymap NULL G keymap-as NULL G keymap-att NULL G keymap-bb NULL G keymap-ca NULL G keymap-dd NULL G keymap-default NULL G keymap-ga NULL G keymap-sb NULL G keymap-sc NULL G KLI.geometry NULL B KLI.mapped 0 G KLI.parent NULL * * B kliPix 1 1 G lagMeter.geometry NULL B lagMeter.mapped 0 G lagMeter.parent NULL G local.geometry NULL B local.mapped 0 G local.parent NULL * G localCursorDef NULL * * G logfile NULL * * * B logging 0 logmess 0 * G macroKey NULL G macrow.geometry NULL N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- G macrow.parent NULL G map.geometry NULL B map.mapped 0 G map.parent NULL * G mapCursorDef NULL * * B mapPix 1 1 * G message.geometry NULL * * * B message.mapped 1 1 * G message.parent NULL * * I messageHoldThresh 0 messHoldThresh 0 * * I messageHUD 0 messageHUD 0 G MetaServer List.geometry NULL B MetaServer List.mapped 0 G MetaServer List.parent NULL * * I motionThresh 16 user_motion_thresh 16 * * B mouseAsShift 0 mouse_as_shift 0 * * G name NULL * G netrek.geometry NULL G netrek.parent NULL G netrek_icon.geometry NULL G netrek_icon.parent NULL G netstat.geometry NULL B netstat.mapped 0 G netstat.parent NULL * * I netstatfreq 5 netstatfreq 5 * * * B netstats 0 netstat 0 G network.geometry NULL B network.mapped 0 G network.parent NULL * * * I newDashboard 0 newDashboard 0 * * * B newDistress 0 UseNewDistress 0 * * B newPlist 0 FALSE G option.geometry NULL N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- B option.mapped 0 G option.parent NULL G ORI.geometry NULL B ORI.mapped 0 G ORI.parent NULL * * B oriPix 1 1 * * B ownerhalo 0 0 * * * B partitionPlist 0 partitionPlist * G password NULL * * I PhaserMsg 2 showPhaser 2 * * I phaserShrink 0 phaserShrink 0 * * B PhaserStats 0 phaserShowStats 0 * * B phaserWindow 0 phaserWindow 0 G pingStats.geometry NULL B pingStats.mapped 0 G pingStats.parent NULL * * I pixFlags 4096 pixFlags 0 * * G pixmapDir NULL * G planet.geometry NULL B planet.mapped 0 * G planet.parent NULL * * I planetCycleTime 10 beep_lite_cycle_time_planet 10 * G player.geometry NULL * B player.mapped 1 * G player.parent NULL * * I playerCycleTime 10 beep_lite_cycle_time_player 10 * * G playerlist NULL * I playerListStyle -1 * * * I port 2592 DEFAULT_PORT I port.localhost -1 * * B portSwap 0 portSwap 0 * G quit.geometry NULL B quit.mapped 0 N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * G quit.parent NULL G rank.geometry NULL B rank.mapped 0 G rank.parent NULL G rcfile-as NULL G rcfile-att NULL G rcfile-bb NULL G rcfile-ca NULL G rcfile-dd NULL G rcfile-default NULL G rcfile-ga NULL G rcfile-sb NULL G rcfile-sc NULL * * I redrawDelay 0 redrawDelay 0 * * B rejectMacro 0 rejectMacro 0 * * B reportKills 1 reportKills 1 * G review.geometry NULL * B review.mapped 1 * G review.parent NULL * G review_all.geometry NULL * B review_all.mapped 0 * G review_all.parent NULL * G review_kill.geometry NULL * B review_kill.mapped 0 * G review_kill.parent NULL G review_phaser.geometry NULL B review_phaser.mapped 0 G review_phaser.parent NULL * G review_team.geometry NULL * B review_team.mapped 0 * G review_team.parent NULL * G review_your.geometry NULL * B review_your.mapped 0 N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * G review_your.parent NULL G ROM.geometry NULL B ROM.mapped 0 G ROM.parent NULL * * B romPix 1 1 * * * B ROMVLVS 0 ROMVLVS 0 G scanner.geometry NULL B scanner.mapped 0 G scanner.parent NULL * * B ScrollBar 1 scrollbar * * I ScrollBarWidth 5 scroll_thumb_width * * I ScrollSaveLines 100 scroll_lines G server.localhost NULL * * B shellTools 1 shelltools 1 * * * B shiftedMouse 0 extended_mouse 0 * * B shipPix 1 1 * * * I showgalactic 2 showgalactic 2 * * * B showIND 0 showIND 0 * * * I showlocal 2 showlocal 2 * * * I showLock 3 showLock 3 * * * B showMotd 1 1 * * B showplanetnames 1 1 * * * B showPlanetOwner 0 showPlanetOwner 0 * * B showstars 1 1 * * * B showstats 0 showStats 0 * * * B showTractorPressor 1 showTractorPressor 1 * * B shrinkPhaserOnMiss 0 shrinkPhaserOnMiss 0 * * * B sortMyTeamFirst 0 sortMyTeamFirst * * * B sortPlayers 0 sortPlayers * * * B sound 0 sound_init 0 G sound.geometry NULL G sound.parent NULL * G stats.geometry NULL N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * G stats.parent NULL * G textCursorDef NULL * * I theirPhaserShrink 0 theirPhaserShrink 0 G tools.geometry NULL G tools.parent NULL * * * B tryShort 1 tryShort 1 * * * B tryUdp 1 tryUdp 1 G tstat.geometry NULL B tstat.mapped 0 G tstat.parent NULL * G tts_color NULL * * G tts_font NULL * * I tts_max_len 40 tts_max_len 40 * * I tts_pos 234 tts_pos TWINSIDE / 2 - 16 * * I tts_time 25 tts_time 25 G UDP.geometry NULL B UDP.mapped 0 G UDP.parent NULL * * * I udpClientReceive 1 udpClientRecv 1 * * * I udpClientSend 1 udpClientSend 1 * * * I udpDebug 0 udpDebug 0 * * * B udpSequenceCheck 1 udpSequenceChk 1 * * I updatespersec 5 updatespeed 5 * * * B UseLite 0 UseLite 0 * * * B useTNGBitmaps 0 use_tng_fed_bitmaps 0 * * * B varyShields 1 VShieldBitmaps 1 * G war.geometry NULL B war.mapped 0 G war.parent NULL * G warn.geometry NULL * B warn.mapped 0 * G warn.parent NULL * * * B warnHull 0 vary_hull 0 N: Appears in the stock netrekrc distributed with the client G: Appears in egrep 'intDefault|booleanDefault|getdefault' D: Variable default is defined in data.c T: I = int, B = boolean, G = string -------------------------------------------------------------------------------------------------------------------------------------------- | N | G | D | T | Key | Value (preferred for bool or int) | Variable | data.c variable value -------------------------------------------------------------------------------------------------------------------------------------------- * * * B warnShields 0 warnShields 0 * * B weaponPix 1 1 G xtrekrc_help.geometry NULL G xtrekrc_help.parent NULL G xtrekrcWin.geometry NULL G xtrekrcWin.parent NULL Options in netrekrc.example not caught by calls to getdefault: server useRSA server.bronco port.bronco useRSA.bronco.ece.cmu.edu server.hockey port.hockey server.picklet server.picklet-home port.picklet-home server.picklet-away port.picklet-away metaCache metaserver continuetractors babes WMXYHintMode sounddir wwwlink WaitMotd.mapped netrek.mapped reportkills udp.geometry udp.mapped fed.parent fed.geometry rom.parent rom.geometry kli.parent kli.geometry ori.parent ori.geometry dist.^A.pop dist.bomb dist.^B.save_planet dist.space_control dist.^C.pickup dist.^D.bombing dist.^E.escorting dist.^F.ogging mac.^G.%u mac.^H.%u dist.^I.ogg dist.^J.help dist.^K.taking dist.^L.carrying macro.b.T macro.s.T macro.g.T mac.F.T mac.f mac.C.A mac.C.A mac.C.A mac.D.A mac.D.A mac.D.A mac.D.A mac.D.A mac.7.A mac.7.A mac.7.A mac.7.A mac.R.A mac.e.T mac.d.T mac.a.T mac.C.%i mac.N.%i mac.S.%i mac.T.%i mac.W.%t mac.I.%u mac.O.%u key.C key.B.0 mac.A.C singleMacro mac.^p mac.^h mac.^l.! lite.pickup lite.base_ogg lite.taking lite.help msg.kill msg.planet msg.bomb msg.destroy msg.take msg.ghostbust >From: James Cameron >Reply-To: vanilla-list@us.netrek.org >To: vanilla-list@us.netrek.org >Subject: Re: [Vanilla List] any growth on this? >Date: Tue, 27 Nov 2001 23:24:04 +1100 > >Yes, that's right. This should change. Suggest how to change it? > >Idea: special compilation mode for COW that causes getdefault() and the >datatype variants to track what is given to them to fetch. Use the >compiled result to generate a list of parameter names and types that are >placed in a header that is used by defaults.c. Change getdefault() to >issue a warning when a new parameter is seen that is not in the list. > >Audit the code periodically using regular expression searching to >verify that all the defaults are known. > >Since the client is in maintenance mode, and no new major features are >being written, the cost of keeping the known parameters in the list >should be low. > >My quick guess at the size of the task: >1) files that contain getdefault or variants, > >% egrep -l "intDefault|booleanDefault|getdefault" *.c|fmt >audio.c cowmain.c defaults.c defwin.c docwin.c findslot.c gnu_win32.c >input.c main.c newwin.c parsemeta.c playback.c playerlist.c sound.c >winsprite.c x11sprite.c x11window.c > >2) total number of files, > >% egrep -l "intDefault|booleanDefault|getdefault" *.c|wc --lines > 17 > >3) number of calls or parameters to investigate, > >% egrep "intDefault|booleanDefault|getdefault" *.c|wc --lines > 182 >% cat *.c|egrep "intDefault|booleanDefault|getdefault"|sort|uniq|wc --lines > 165 >% cat *.c|egrep "intDefault|booleanDefault|getdefault"|cut -f2 -d\"|sort|uniq|more|wc --lines > 154 > > >What might not be caught by an semi-automatic analysis is calls to >getdefault() that are conditional. One could argue that such calls >are not for important parameters! From mark at mark.mielke.cc Fri Dec 7 10:22:45 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207012700.G18897@mark.mielke.cc>; from mark@mielke.cc on Fri, Dec 07, 2001 at 01:27:00AM -0500 References: <20011205164213.B32243@us.netrek.org> <20011206111810.D32243@us.netrek.org> <20011205202354.B13350@mark.mielke.cc> <20011206135020.I32243@us.netrek.org> <20011205233838.H13350@mark.mielke.cc> <20011207092718.M32243@us.netrek.org> <20011207012700.G18897@mark.mielke.cc> Message-ID: <20011207112245.B20905@mark.mielke.cc> On Fri, Dec 07, 2001 at 01:27:00AM -0500, Mark Mielke wrote: > On Fri, Dec 07, 2001 at 09:27:18AM +1100, James Cameron wrote: > > - Netrek is not a place in which we should demonstrate our coding > > prowess for an examiner. We're not a training ground. > So leave it as is than. Just as many people misunderstand event loops > as misunderstand threading. Another major benefit of the current model, is that it is quite easy to write new programs (chkplayers, xsg, xtkill, ...) and plug them in. Such would be quite a deal more difficult with either threaded code, or an event driven system, unless the memory was left as shared memory. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From Darryl_Palmer_Jr at acm.org Fri Dec 7 11:29:15 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Bots and bot teams In-Reply-To: <006d01c17eeb$9d5cbf00$3b824b42@san.rr.com> Message-ID: The idea was to start up some Robotic Netrek League to compete against robo-soccer. If we put the infrastructure in their then people looking to do a undergraduate or master's thesis in Artificial Intelligence can easily use it. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Daniel Damouth I would really like to have a go at it, but I'm afraid of starting something I won't be able to follow through on. Perhaps if it were a competition... say, Freebot gets released for everyone to use, and we have a robot team ladder system, or even just periodic contests. We could put together a basic downloadable Freebot team, make it available, and people could have fun tweaking or developing from there. Dan Damouth -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011207/d183d99a/smime.bin From Darryl_Palmer_Jr at acm.org Fri Dec 7 11:47:04 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207015328.H18897@mark.mielke.cc> Message-ID: I see what you are thinking. Should the scenarios just be some simple script that displays messages and expects that certain actions or conditions occur in an amount of time? For example if it says press '5' for warp 5, should it disable most of the other keys other than 5? If we have bots anyway, should have a way of having a "ghost" ship demonstrating certain manuevers and actions? For some things it doesn't make sense, but for escorting or synching we can either script the escorting and synching demonstration or playback a netrek game that demonstrates it. Is it necessary to be able to have a floating cursor or to change the colors on the player's screen to draw his attention to certain things? Darryl -----Original Message----- The final conclusion could throw a whole bunch of the techniques together with very few 'pause' messages. Upon completion, they could have their name registered in some Netrek academy registry available online or something. Think this would be useful? mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011207/a52a4867/smime.bin From doosh at inl.org Fri Dec 7 12:41:53 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Fri, Dec 07, 2001 at 11:47:04AM -0600 References: <20011207015328.H18897@mark.mielke.cc> Message-ID: <20011207104153.A72168@inl.org> On Fri, Dec 07, 2001 at 11:47:04AM -0600, Darryl Palmer Jr wrote: > I see what you are thinking. Should the scenarios just be some simple > script that displays messages and expects that certain actions or > conditions occur in an amount of time? For example if it says press '5' > for warp 5, should it disable most of the other keys other than 5? It shouldn't say warp 5, it should say maxwarp. Let's not get people into bad habits. > If we have bots anyway, should have a way of having a "ghost" ship > demonstrating certain manuevers and actions? For some things it doesn't > make sense, but for escorting or synching we can either script the > escorting and synching demonstration or playback a netrek game that > demonstrates it. > > Is it necessary to be able to have a floating cursor or to change the > colors on the player's screen to draw his attention to certain things? It certainly would be nice. -Tom From mark at mark.mielke.cc Fri Dec 7 12:46:45 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Fri, Dec 07, 2001 at 11:47:04AM -0600 References: <20011207015328.H18897@mark.mielke.cc> Message-ID: <20011207134645.A21435@mark.mielke.cc> On Fri, Dec 07, 2001 at 11:47:04AM -0600, Darryl Palmer Jr wrote: > I see what you are thinking. Should the scenarios just be some simple > script that displays messages and expects that certain actions or > conditions occur in an amount of time? For example if it says press '5' > for warp 5, should it disable most of the other keys other than 5? In other games, most other behaviour is disabled to ensure that the player does not get confused. Yes, the script should expect certain conditions to be met before proceeding. > If we have bots anyway, should have a way of having a "ghost" ship > demonstrating certain manuevers and actions? For some things it doesn't > make sense, but for escorting or synching we can either script the > escorting and synching demonstration or playback a netrek game that > demonstrates it. This would be quite cool, especially for the more advanced topics. It could show the player how to do it, and then ask the player to do it themselves. I.e. lock on the planet, orbit it, beam down armies, take it. The planet could be reset to 3 armies or whatever, and the player could be asked to do the same. > Is it necessary to be able to have a floating cursor or to change the > colors on the player's screen to draw his attention to certain things? This would definately be nice. The existing hilighting code may be sufficient. An expanding halo around the planet? I would be willing to put in time on this project as well. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Fri Dec 7 16:11:00 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207104153.A72168@inl.org>; from doosh@inl.org on Fri, Dec 07, 2001 at 10:41:53AM -0800 References: <20011207015328.H18897@mark.mielke.cc> <20011207104153.A72168@inl.org> Message-ID: <20011207171100.A22173@mark.mielke.cc> On Fri, Dec 07, 2001 at 10:41:53AM -0800, Tom Holub wrote: > On Fri, Dec 07, 2001 at 11:47:04AM -0600, Darryl Palmer Jr wrote: > > I see what you are thinking. Should the scenarios just be some simple > > script that displays messages and expects that certain actions or > > conditions occur in an amount of time? For example if it says press '5' > > for warp 5, should it disable most of the other keys other than 5? > It shouldn't say warp 5, it should say maxwarp. Let's not get people > into bad habits. Let them get a handle on their ship before you sic a base on them. Once the concepts are down, techniques can be taught. Anyways... they shouldn't stick with maxwarp. Especially with a DD, I've found toggling between 4, repair, and maxwarp to be quite effective. (Oops... this may have re-opened the debate about whether a DD is effective against a clued opponent except as a runner scum... hehe) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From doosh at inl.org Fri Dec 7 17:28:09 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207171100.A22173@mark.mielke.cc>; from mark@mark.mielke.cc on Fri, Dec 07, 2001 at 05:11:00PM -0500 References: <20011207015328.H18897@mark.mielke.cc> <20011207104153.A72168@inl.org> <20011207171100.A22173@mark.mielke.cc> Message-ID: <20011207152809.A90119@inl.org> On Fri, Dec 07, 2001 at 05:11:00PM -0500, Mark Mielke wrote: > On Fri, Dec 07, 2001 at 10:41:53AM -0800, Tom Holub wrote: > > On Fri, Dec 07, 2001 at 11:47:04AM -0600, Darryl Palmer Jr wrote: > > > I see what you are thinking. Should the scenarios just be some simple > > > script that displays messages and expects that certain actions or > > > conditions occur in an amount of time? For example if it says press '5' > > > for warp 5, should it disable most of the other keys other than 5? > > It shouldn't say warp 5, it should say maxwarp. Let's not get people > > into bad habits. > > Let them get a handle on their ship before you sic a base on them. I didn't say anything about a base. There is no reason for anyone to choose warp 5 in a ship with full fuel. The secnarios shouldn't teach people how to do things they shouldn't do, especially since failure to use maxwarp is one of the most common newbie errors. > Anyways... they shouldn't stick with maxwarp. Especially with a DD, > I've found toggling between 4, repair, and maxwarp to be quite > effective. (Oops... this may have re-opened the debate about whether a > DD is effective against a clued opponent except as a runner > scum... hehe) Actually, I think it closed the debate about whether Mark Mielke has any clue at all. -Tom From mark at mark.mielke.cc Fri Dec 7 18:43:28 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207152809.A90119@inl.org>; from doosh@inl.org on Fri, Dec 07, 2001 at 03:28:09PM -0800 References: <20011207015328.H18897@mark.mielke.cc> <20011207104153.A72168@inl.org> <20011207171100.A22173@mark.mielke.cc> <20011207152809.A90119@inl.org> Message-ID: <20011207194328.A22626@mark.mielke.cc> On Fri, Dec 07, 2001 at 03:28:09PM -0800, Tom Holub wrote: > On Fri, Dec 07, 2001 at 05:11:00PM -0500, Mark Mielke wrote: > > Let them get a handle on their ship before you sic a base on them. > I didn't say anything about a base. > There is no reason for anyone to choose warp 5 in a ship with full fuel. > The secnarios shouldn't teach people how to do things they shouldn't do, > especially since failure to use maxwarp is one of the most common newbie > errors. You don't necessarily teach somebody to program by having them write an SGML parser. Rather, have them do something silly like counting to 10. "Hello World\n" is just such an example. You teach people what tools they have available, and *then* you show them how to make best use of them. > > Anyways... they shouldn't stick with maxwarp. Especially with a DD, > > I've found toggling between 4, repair, and maxwarp to be quite > > effective. (Oops... this may have re-opened the debate about whether a > > DD is effective against a clued opponent except as a runner > > scum... hehe) > Actually, I think it closed the debate about whether Mark Mielke has any > clue at all. You are so easy to play. It's a wonder that you consider yourself the self-proclaimed expert. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From doosh at inl.org Fri Dec 7 09:56:25 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <020f01c17edb$d7bcd960$0200a8c0@lehman.com>; from brian@thePaulsens.com on Thu, Dec 06, 2001 at 11:58:23PM -0500 References: <020f01c17edb$d7bcd960$0200a8c0@lehman.com> Message-ID: <20011207075625.A57462@inl.org> On Thu, Dec 06, 2001 at 11:58:23PM -0500, Brian Paulsen wrote: > You're not the only one. I thought this got fixed long ago when Todd's > borgs showed how well this tactic worked. His explanation of that was a hoax--his borgs never had this capability. Apparently the server change was a hoax as well. -Tom From doosh at inl.org Fri Dec 7 10:03:26 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Netrek? Open source? Encouragement? In-Reply-To: <20011207010413.F18897@mark.mielke.cc>; from mark@mark.mielke.cc on Fri, Dec 07, 2001 at 01:04:13AM -0500 References: <20011205181851.A11036@mark.mielke.cc> <20011205213643.D13350@mark.mielke.cc> <20011205233435.C48954@inl.org> <20011206122904.B16413@mark.mielke.cc> <20011206144534.B170270@cecum.vec.wfubmc.edu> <20011207010413.F18897@mark.mielke.cc> Message-ID: <20011207080326.B57462@inl.org> On Fri, Dec 07, 2001 at 01:04:13AM -0500, Mark Mielke wrote: > > This has incredible potential even for dog-fights. Why have two ships > torping an incoming ship independently, when the two ships could > alternate torpedoes creating an impenetrable wall of torpedoes, while > minimizing fuel consumption? I wonder how easy it would be for an INL > team to take planets, if they can't manage to get a single kill? Gee...what happens when the bots run out of fuel? It's always possible to get kills in real netrek situations. I often play games against teams where I could dominate everyone on the other team in a dogfight--winning 9 of 10 or more. My ratio in real games is usually between 1.5 and 2. > I have a vision. Unfortunately, I have a restricted time > budget. And, no fucking clue. -Tom From doosh at inl.org Fri Dec 7 20:29:46 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207194328.A22626@mark.mielke.cc>; from mark@mark.mielke.cc on Fri, Dec 07, 2001 at 07:43:28PM -0500 References: <20011207015328.H18897@mark.mielke.cc> <20011207104153.A72168@inl.org> <20011207171100.A22173@mark.mielke.cc> <20011207152809.A90119@inl.org> <20011207194328.A22626@mark.mielke.cc> Message-ID: <20011207182946.A1432@inl.org> On Fri, Dec 07, 2001 at 07:43:28PM -0500, Mark Mielke wrote: > On Fri, Dec 07, 2001 at 03:28:09PM -0800, Tom Holub wrote: > > On Fri, Dec 07, 2001 at 05:11:00PM -0500, Mark Mielke wrote: > > > Let them get a handle on their ship before you sic a base on them. > > I didn't say anything about a base. > > There is no reason for anyone to choose warp 5 in a ship with full fuel. > > The secnarios shouldn't teach people how to do things they shouldn't do, > > especially since failure to use maxwarp is one of the most common newbie > > errors. > > You don't necessarily teach somebody to program by having them write > an SGML parser. > > Rather, have them do something silly like counting to 10. "Hello World\n" > is just such an example. > > You teach people what tools they have available, and *then* you show > them how to make best use of them. You don't teach people to program "Hello World" using goto's. -Tom From mark at mark.mielke.cc Fri Dec 7 10:16:17 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:50 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207170506.S32243@us.netrek.org>; from quozl@us.netrek.org on Fri, Dec 07, 2001 at 05:05:06PM +1100 References: <20011206173121.A9564@inl.org> <20011206191850.A16402@inl.org> <20011207170506.S32243@us.netrek.org> Message-ID: <20011207111617.A20905@mark.mielke.cc> On Fri, Dec 07, 2001 at 05:05:06PM +1100, James Cameron wrote: > On Thu, Dec 06, 2001 at 07:18:50PM -0800, Tom Holub wrote: > > What I'm saying is that I think it could have an effect on human players. > > If there are two base defenders and a base trying to phaserlock cloakers, > > they are going to react differently if they're all getting the same > > incorrect position, compared to if they're all getting different incorrect > > positions. > Yeah, okay, I agree. I withdraw it. The galaxy is 100,000 units (GWIDTH) wide and tall. The cloaker position is given as up to +/- 1,000 of the actual location. The "size" of the "strategic and tactical windows" (GWINSIDE/TWINSIDE) is 500 pixels. As far as I am aware, a Netrek distance 'unit' is exactly one tactical window pixel size. Clients without 'enhancements' only show cloakers on the galactic. (if the cloaking phase is not complete, the information is not yet restricted) The standard code in map.c has always used the equation: dx = j->p_x * GWINSIDE / GWIDTH; dy = j->p_y * GWINSIDE / GWIDTH; to draw the players. The cloaker code currently generater adds -1000..999 to both p_x and p_y. This leaves -1000, -500, 0, 500 offsets to show on each axis in the galactic. 4 possible pixels for each axis, with the 3rd pixel being the most accurate choice. It may be desirable to choose one of the 16 (4x4) possible rounded locations, instead of a any position within the grid. I suspect that even this could be taken advantage of, however, so don't add it to your list just yet. :-) One thing of note... was anybody else aware that cloakers have a 25% greater chance of appearing above the actual location of the player, and a 25% greater chance of appearing to the left of the player? To me, this seems a little wrong. I suspect the code in genspkt.c should not read: cpl->x=htonl(pl->p_x+(random() % 2000)-1000); cpl->y=htonl(pl->p_y+(random() % 2000)-1000); But rather, should allow a 1/8 chance that it shows up 2 to the left, and a 1/8 chance that it shows up 2 to the right, instead of 1/4 chance that it shows 2 to the left. (Same for up/down): cpl->x=htonl(pl->p_x+(random() % 1999)-750); cpl->y=htonl(pl->p_y+(random() % 1999)-750); This actually 'fixes' it for users, not for bots. Now, I'm certain that this won't be 'fixed', as all those people that phasered at that certain place on the '??' after realizing that they usually missed when aiming straight at its center, have learned that it isn't the center you should aim for... therefore game behaviour would change... (also, there may be something strange about fonts that cause '??' to be an even-number set of pixels wide and/or tall, that might cause rounding during the rendering process to minimize the effect) But this is just another one of my "off by 1" complaints against the original Netrek code. Nothing major... :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Fri Dec 7 21:07:38 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] Netrek? Open source? Encouragement? In-Reply-To: <20011207080326.B57462@inl.org>; from doosh@inl.org on Fri, Dec 07, 2001 at 08:03:26AM -0800 References: <20011205181851.A11036@mark.mielke.cc> <20011205213643.D13350@mark.mielke.cc> <20011205233435.C48954@inl.org> <20011206122904.B16413@mark.mielke.cc> <20011206144534.B170270@cecum.vec.wfubmc.edu> <20011207010413.F18897@mark.mielke.cc> <20011207080326.B57462@inl.org> Message-ID: <20011207220738.B22626@mark.mielke.cc> On Fri, Dec 07, 2001 at 08:03:26AM -0800, Tom Holub wrote: > On Fri, Dec 07, 2001 at 01:04:13AM -0500, Mark Mielke wrote: > > This has incredible potential even for dog-fights. Why have two ships > > torping an incoming ship independently, when the two ships could > > alternate torpedoes creating an impenetrable wall of torpedoes, while > > minimizing fuel consumption? I wonder how easy it would be for an INL > > team to take planets, if they can't manage to get a single kill? > Gee...what happens when the bots run out of fuel? They'll certainly run out of fuel later if they co-ordinate, then if they do not. Slow down and think about it. > > I have a vision. Unfortunately, I have a restricted time > > budget. > And, no fucking clue. Your entire line of arguments almost always appear to rest around such statements as they above. I thought you didn't care how I wasted my time? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mindmeld at bunkerhill.dyndns.org Fri Dec 7 21:22:47 2001 From: mindmeld at bunkerhill.dyndns.org (Gerard Lim) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] continuousMouse Message-ID: <20011207222247.A1441@bunkerhill.dyndns.org> There's been a feature that's missing in the UNIX version of COW that is present in the win32 version, which is support for continuousMouse (ie. if you press a mouse button and keep it down, it will behave as if you have pressed it multiple times). I've found the cause, which is shown in the diff below. Basically if a MouseMotionEvent occurs, it wasn't checking the right event (it was checking 'button', which is a MouseButtonEvent (ie for mouse clicks, but not movement). The right event is 'motion'. Also, I took out some dead code (it seems to be useless) from input.c::buttonaction(), which returns without processing the event if the event type is W_EV_CM_BUTTON (a mouse motion event), this prevented the correct processing of motion events, since it returns without doing anything. If it's ok with everyone I would like to commit this. (PLEASE so I don't have to reboot to windows every time I want to trek ;)) gerard Index: input.c =================================================================== RCS file: /cvsroot/netrek/client/cow/input.c,v retrieving revision 1.7 diff -c -r1.7 input.c *** input.c 2001/08/21 20:52:15 1.7 --- input.c 2001/12/08 03:05:12 *************** *** 1192,1204 **** } } - #ifdef MOTION_MOUSE - if ((data->type == W_EV_CM_BUTTON) && /* KOC - 10/18/95 */ - (!motion_mouse_enablable) && /* Hack for */ - (data->key != W_RBUTTON)) /* continuous_steer */ - return; - #endif - if (data->Window == infow) { int x, y; --- 1192,1197 ---- Index: x11window.c =================================================================== RCS file: /cvsroot/netrek/client/cow/x11window.c,v retrieving revision 1.5 diff -c -r1.5 x11window.c *** x11window.c 2001/08/21 20:52:15 1.5 --- x11window.c 2001/12/08 03:05:21 *************** *** 1606,1639 **** } #endif ! switch (button->button & 0xf) { ! case Button3: wevent->key = W_RBUTTON; break; ! case Button1: wevent->key = W_LBUTTON; break; ! case Button2: wevent->key = W_MBUTTON; break; #ifdef Button4 ! case Button4: wevent->key = W_WUBUTTON; break; #endif #ifdef Button5 ! case Button5: wevent->key = W_WDBUTTON; break; #endif #ifdef Button6 ! case Button6: wevent->key = W_X1BUTTON; break; #endif #ifdef Button7 ! case Button7: wevent->key = W_X2BUTTON; break; #endif --- 1606,1639 ---- } #endif ! switch (motion->state) { ! case Button3Mask: wevent->key = W_RBUTTON; break; ! case Button1Mask: wevent->key = W_LBUTTON; break; ! case Button2Mask: wevent->key = W_MBUTTON; break; #ifdef Button4 ! case Button4Mask: wevent->key = W_WUBUTTON; break; #endif #ifdef Button5 ! case Button5Mask: wevent->key = W_WDBUTTON; break; #endif #ifdef Button6 ! case Button6Mask: wevent->key = W_X1BUTTON; break; #endif #ifdef Button7 ! case Button7Mask: wevent->key = W_X2BUTTON; break; #endif From mark at mark.mielke.cc Fri Dec 7 21:40:59 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207182946.A1432@inl.org>; from doosh@inl.org on Fri, Dec 07, 2001 at 06:29:46PM -0800 References: <20011207015328.H18897@mark.mielke.cc> <20011207104153.A72168@inl.org> <20011207171100.A22173@mark.mielke.cc> <20011207152809.A90119@inl.org> <20011207194328.A22626@mark.mielke.cc> <20011207182946.A1432@inl.org> Message-ID: <20011207224059.D22626@mark.mielke.cc> On Fri, Dec 07, 2001 at 06:29:46PM -0800, Tom Holub wrote: > On Fri, Dec 07, 2001 at 07:43:28PM -0500, Mark Mielke wrote: > > You teach people what tools they have available, and *then* you show > > them how to make best use of them. > You don't teach people to program "Hello World" using goto's. You have a way of making very simple statements that appear clever, and assuming that this is sufficient to make your argument. There is nothing inherently wrong with travelling at speed 5, but if you really have bee up your bonnet about it fine, use 4. The reason I suggested a smaller warp, was because somebody who is new to the game, who has never even seen a ship move before, may be startled and confused by their ship screaming across the galaxy only to find themselves ETEMP'd a few seconds later. Also, for the purpose of the 'beginner' learning excercises, it would be nice to not have them trapsing around the galaxy. Each lessons leads directly into the next lesson. In the beginning, we want them to stick around known locations, such as Earth. Why? So that when we tell them to 'lock on to Deneb', it will be visible on their tactical screen when we ask them to do it. If they are *anywhere* in the galaxy, they'll have to scan through 40 planets to find "Deb". One day you should pulls those bees out of your bonnet. Most types of bees have stingers that can inflict a fair amount of pain. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From xyzzy at speakeasy.org Fri Dec 7 21:47:24 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011207111617.A20905@mark.mielke.cc> Message-ID: On Fri, 7 Dec 2001, Mark Mielke wrote: > The galaxy is 100,000 units (GWIDTH) wide and tall. The cloaker > position is given as up to +/- 1,000 of the actual location. The > "size" of the "strategic and tactical windows" (GWINSIDE/TWINSIDE) is > 500 pixels. As far as I am aware, a Netrek distance 'unit' is exactly > one tactical window pixel size. Clients without 'enhancements' only Nope. Think about is this way, if the galactic is 100,000 units and 500 pixels, than each galactic pixel is 200 units wide. +-1000 units for cloaker positions is 5 pixels in either direction. From ssheldon at sodablue.org Fri Dec 7 22:40:35 2001 From: ssheldon at sodablue.org (Steve Sheldon) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: <20011207222247.A1441@bunkerhill.dyndns.org> Message-ID: <000001c17fa2$7aef7ef0$8400000a@inside.sodablue.com> Before you commit this you best make sure that ContinuousMouse can be turned off. I fixed a bug in my NetrekNT source fork a while back where continuousMouse was not listening to the featurespackets from the server. It was simply enabling it by default. Well I thought this sucked, because I don't like continuousmouse and had no way to turn it off. So I made sure it responded to the features packet correctly, and also responded to the netrekrc default setting. For people who are not used to the behavior of continuousmouse, it is extremely frustrating to play with it on. > -----Original Message----- > From: vanilla-list-admin@us.netrek.org > [mailto:vanilla-list-admin@us.netrek.org] On Behalf Of Gerard Lim > Sent: Friday, December 07, 2001 9:23 PM > To: vanilla-list@us.netrek.org > Subject: [Vanilla List] continuousMouse > > > There's been a feature that's missing in the UNIX version of > COW that is present in the win32 version, which is support > for continuousMouse (ie. if you press a mouse button and keep > it down, it will behave as if you have pressed it multiple times). > > > I've found the cause, which is shown in the diff below. > Basically if a MouseMotionEvent occurs, it wasn't checking > the right event (it was checking 'button', which is a > MouseButtonEvent (ie for mouse clicks, but not movement). > The right event is 'motion'. > > Also, I took out some dead code (it seems to be useless) from > input.c::buttonaction(), which returns without processing the event > if the event type is W_EV_CM_BUTTON (a mouse motion event), > this prevented the correct processing of motion events, since > it returns without doing anything. > > If it's ok with everyone I would like to commit this. (PLEASE > so I don't have to reboot to windows every time I want to trek ;)) > > gerard > > > > > Index: input.c > =================================================================== > RCS file: /cvsroot/netrek/client/cow/input.c,v > retrieving revision 1.7 > diff -c -r1.7 input.c > *** input.c 2001/08/21 20:52:15 1.7 > --- input.c 2001/12/08 03:05:12 > *************** > *** 1192,1204 **** > } > } > > - #ifdef MOTION_MOUSE > - if ((data->type == W_EV_CM_BUTTON) && /* KOC > - 10/18/95 */ > - (!motion_mouse_enablable) && /* Hack for > */ > - (data->key != W_RBUTTON)) /* > continuous_steer */ > - return; > - #endif > - > if (data->Window == infow) > { > int x, y; > --- 1192,1197 ---- > Index: x11window.c > =================================================================== > RCS file: /cvsroot/netrek/client/cow/x11window.c,v > retrieving revision 1.5 > diff -c -r1.5 x11window.c > *** x11window.c 2001/08/21 20:52:15 1.5 > --- x11window.c 2001/12/08 03:05:21 > *************** > *** 1606,1639 **** > } > #endif > > ! switch (button->button & 0xf) > { > ! case Button3: > wevent->key = W_RBUTTON; > break; > ! case Button1: > wevent->key = W_LBUTTON; > break; > ! case Button2: > wevent->key = W_MBUTTON; > break; > #ifdef Button4 > ! case Button4: > wevent->key = W_WUBUTTON; > break; > #endif > #ifdef Button5 > ! case Button5: > wevent->key = W_WDBUTTON; > break; > #endif > #ifdef Button6 > ! case Button6: > wevent->key = W_X1BUTTON; > break; > #endif > #ifdef Button7 > ! case Button7: > wevent->key = W_X2BUTTON; > break; > #endif > --- 1606,1639 ---- > } > #endif > > ! switch (motion->state) > { > ! case Button3Mask: > wevent->key = W_RBUTTON; > break; > ! case Button1Mask: > wevent->key = W_LBUTTON; > break; > ! case Button2Mask: > wevent->key = W_MBUTTON; > break; > #ifdef Button4 > ! case Button4Mask: > wevent->key = W_WUBUTTON; > break; > #endif > #ifdef Button5 > ! case Button5Mask: > wevent->key = W_WDBUTTON; > break; > #endif > #ifdef Button6 > ! case Button6Mask: > wevent->key = W_X1BUTTON; > break; > #endif > #ifdef Button7 > ! case Button7Mask: > wevent->key = W_X2BUTTON; > break; > #endif > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-> time.com/mailman/listinfo/vanilla-list > > From mark at mark.mielke.cc Sat Dec 8 01:07:52 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from xyzzy@speakeasy.org on Fri, Dec 07, 2001 at 07:47:24PM -0800 References: <20011207111617.A20905@mark.mielke.cc> Message-ID: <20011208020752.E22626@mark.mielke.cc> On Fri, Dec 07, 2001 at 07:47:24PM -0800, Trent Piepho wrote: > On Fri, 7 Dec 2001, Mark Mielke wrote: > > The galaxy is 100,000 units (GWIDTH) wide and tall. The cloaker > > position is given as up to +/- 1,000 of the actual location. The > > "size" of the "strategic and tactical windows" (GWINSIDE/TWINSIDE) is > > 500 pixels. As far as I am aware, a Netrek distance 'unit' is exactly > > one tactical window pixel size. Clients without 'enhancements' only > Nope. Think about is this way, if the galactic is 100,000 units and 500 > pixels, than each galactic pixel is 200 units wide. +-1000 units for cloaker > positions is 5 pixels in either direction. Hmm... sorry... Does this not still lean towards the left or up, simply because of rounding? Should the client perform better rounding than stripping the remainder? Or is it fixed in stone, and we wouldn't want to change it? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From quozl at us.netrek.org Sat Dec 8 02:43:09 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: <000001c17fa2$7aef7ef0$8400000a@inside.sodablue.com>; from ssheldon@sodablue.org on Fri, Dec 07, 2001 at 10:40:35PM -0600 References: <20011207222247.A1441@bunkerhill.dyndns.org> <000001c17fa2$7aef7ef0$8400000a@inside.sodablue.com> Message-ID: <20011208194309.W32243@us.netrek.org> Gerard, Subject to it working properly with the feature packet from a server, I have no problems with the patch. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Sat Dec 8 02:47:16 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:51 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011208020752.E22626@mark.mielke.cc>; from mark@mark.mielke.cc on Sat, Dec 08, 2001 at 02:07:52AM -0500 References: <20011207111617.A20905@mark.mielke.cc> <20011208020752.E22626@mark.mielke.cc> Message-ID: <20011208194716.X32243@us.netrek.org> On Sat, Dec 08, 2001 at 02:07:52AM -0500, Mark Mielke wrote: > Or is it fixed in stone, and we wouldn't want to change it? I'm quite happy to store away an #ifdef'd change that would be used by expert server owners who wish to test cooperating robots as part of an academic exercise ... but it won't likely ever be defined on the main servers used for pickup play. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From rutabega20 at hotmail.com Sat Dec 8 02:58:06 2001 From: rutabega20 at hotmail.com (Gerard Lim) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] continuousMouse Message-ID: I've already tested it. continuousMouse may be set to 'off' in the netrekrc if you don't want it. gerard >From: "Steve Sheldon" >Reply-To: vanilla-list@us.netrek.org >To: >Subject: RE: [Vanilla List] continuousMouse >Date: Fri, 7 Dec 2001 22:40:35 -0600 > >Before you commit this you best make sure that ContinuousMouse can be >turned off. > >I fixed a bug in my NetrekNT source fork a while back where >continuousMouse was not listening to the featurespackets from the >server. It was simply enabling it by default. > >Well I thought this sucked, because I don't like continuousmouse and had >no way to turn it off. So I made sure it responded to the features >packet correctly, and also responded to the netrekrc default setting. > >For people who are not used to the behavior of continuousmouse, it is >extremely frustrating to play with it on. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From quozl at us.netrek.org Sat Dec 8 06:58:11 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: ; from rutabega20@hotmail.com on Sat, Dec 08, 2001 at 03:58:06AM -0500 References: Message-ID: <20011208235811.Z32243@us.netrek.org> On Sat, Dec 08, 2001 at 03:58:06AM -0500, Gerard Lim wrote: > I've already tested it. continuousMouse may be set to 'off' in > the netrekrc if you don't want it. Have you tested it with a server that has the continuousMouse feature packet set to false? This should cause the setting in the netrekrc to be ignored, forcing it off. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From xyzzy at speakeasy.org Sat Dec 8 07:47:33 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: <20011208194309.W32243@us.netrek.org> Message-ID: On Sat, 8 Dec 2001, James Cameron wrote: > Gerard, > > Subject to it working properly with the feature packet from a server, I > have no problems with the patch. That's the problem. The windows clients ignore the feature packet from the server, and use continuous mouse anyway. Most (all) servers have continuous mouse turned off, so all windows clients are pretty much borgs in this regard. I think there are really two options to this. The first is to revoke the RSA key of all clients which ignore the server's continuous mouse setting, since they are borgs. I don't think this is a very good idea, as it will cause a lot of problems with people being unable to connect. The second is to decide that continuous mouse isn't a server controlled feature, and let unix clients ignore the server setting just like the windows clients. Since most players have continuous mouse, it can't be that borg of a feature. From doosh at inl.org Sat Dec 8 10:11:45 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] Scenarios In-Reply-To: <20011207224059.D22626@mark.mielke.cc>; from mark@mark.mielke.cc on Fri, Dec 07, 2001 at 10:40:59PM -0500 References: <20011207015328.H18897@mark.mielke.cc> <20011207104153.A72168@inl.org> <20011207171100.A22173@mark.mielke.cc> <20011207152809.A90119@inl.org> <20011207194328.A22626@mark.mielke.cc> <20011207182946.A1432@inl.org> <20011207224059.D22626@mark.mielke.cc> Message-ID: <20011208081145.A34504@inl.org> On Fri, Dec 07, 2001 at 10:40:59PM -0500, Mark Mielke wrote: > On Fri, Dec 07, 2001 at 06:29:46PM -0800, Tom Holub wrote: > > On Fri, Dec 07, 2001 at 07:43:28PM -0500, Mark Mielke wrote: > > > You teach people what tools they have available, and *then* you show > > > them how to make best use of them. > > You don't teach people to program "Hello World" using goto's. > > There is nothing inherently wrong with travelling at speed 5, but if you > really have bee up your bonnet about it fine, use 4. There is only one speed to choose when starting from a full stop with a full tank of gas--maximum warp. Any other choice is an error. Any scenario should not encourage errors. > them trapsing around the galaxy. Each lessons leads directly into the > next lesson. In the beginning, we want them to stick around known > locations, such as Earth. Why? So that when we tell them to 'lock on > to Deneb', it will be visible on their tactical screen when we ask > them to do it. The way most games do scenarios, you accomplish one, get an acknowledgement, and start fresh with the next one. -Tom From mark at mark.mielke.cc Sat Dec 8 11:47:39 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011208194716.X32243@us.netrek.org>; from quozl@us.netrek.org on Sat, Dec 08, 2001 at 07:47:16PM +1100 References: <20011207111617.A20905@mark.mielke.cc> <20011208020752.E22626@mark.mielke.cc> <20011208194716.X32243@us.netrek.org> Message-ID: <20011208124739.A25755@mark.mielke.cc> On Sat, Dec 08, 2001 at 07:47:16PM +1100, James Cameron wrote: > On Sat, Dec 08, 2001 at 02:07:52AM -0500, Mark Mielke wrote: > > Or is it fixed in stone, and we wouldn't want to change it? > I'm quite happy to store away an #ifdef'd change that would be used > by expert server owners who wish to test cooperating robots as part of > an academic exercise ... but it won't likely ever be defined on the > main servers used for pickup play. In this specific case, we wandered off robot talk to another off by almost 1 Netrek flaw. I mentioned how the server does +/- 1000 with the intention of putting '??' on the galactic off by a few pixels, but that the algorithm used to do so did not take into account the fact that all clients round down, instead of rounding evenly. My original claim was that 25% of the time, the '??' would show up more to the top, and that 25% of the time, the '??' would show up more to the left. Trent corrected my numbers. There isn't 4 possible pixel positions on the galactic for a cloaker that isn't moving. Each pixel represents a distance of 200, so the intention is that there is actually the potential of being "off by up to 5 pixels in either direction", offering 10 potential pixels that the cloaker could be displayed at. Unfortunately, the problem still remains: (Range is -1000..999) -1000, -800, -600, -400, -200, 0, 200, 400, 600, 800 5 4 3 2 1 0 1 2 3 4 This time, however, after Trent's correction, the issue is somewhat reduced. Instead of the extra location being 1 of 4 positions, it is 1 of 10 positions. The client may draw the ship up to 5 pixels left or up from the actual location, but only 4 pixels down or right from the actual location. The three options, of course, are: 1) Leave things as they are -- nobody cares, or it might affect gameplay. 2) Fix the server to know how the client rounds, and modify the position generating algorithym to skew the numbers to the positive by 100. Instead of 10% of the time it being off by 5 to the left, have it be 5% of the time off by 5 to the left, and 5% of the time off by 5 to the right. 3) Fix the client to round. (The only reason why this might not be advisable is that the client doesn't round anything... this includes planets, ships, players, torpedoes, ... - suddenly adding rounding for one item would put the location of the other items off by up to one pixel) As it is, the robot doesn't care about pixels on the galactic, so this does not directly reply to it. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From rutabega20 at hotmail.com Sat Dec 8 12:35:50 2001 From: rutabega20 at hotmail.com (Gerard Lim) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] continuousMouse Message-ID: I wasn't aware that this is a server controlled feature. I just took it for granted that the feature is one of those things that are available in COW and nothing else, since I've been using it for years on blessed servers with no problems. The only reason I even use it is because my hand will hurt if I have to click lots of times on the mouse. But expiring all clients will be a problem as will forcing people who will upgrade the client to change their playing style (like using a new keymap!) There's also the equivalent of keyrepeat (not an option in the netrekrc AFAIK), where pressing a key will have the effect of pressing it many times (or is that server controlled as well?) I know some players use this technique instead of continuousMouse. gerard >From: Trent Piepho >Reply-To: vanilla-list@us.netrek.org >To: vanilla-list@us.netrek.org >Subject: Re: [Vanilla List] continuousMouse >Date: Sat, 8 Dec 2001 05:47:33 -0800 (PST) > >On Sat, 8 Dec 2001, James Cameron wrote: > > Gerard, > > > > Subject to it working properly with the feature packet from a server, I > > have no problems with the patch. > >That's the problem. The windows clients ignore the feature packet from the >server, and use continuous mouse anyway. Most (all) servers have >continuous >mouse turned off, so all windows clients are pretty much borgs in this >regard. >I think there are really two options to this. > >The first is to revoke the RSA key of all clients which ignore the server's >continuous mouse setting, since they are borgs. I don't think this is a >very >good idea, as it will cause a lot of problems with people being unable to >connect. > >The second is to decide that continuous mouse isn't a server controlled >feature, and let unix clients ignore the server setting just like the >windows >clients. Since most players have continuous mouse, it can't be that borg >of >a feature. > > >_______________________________________________ >vanilla-list mailing list >vanilla-list@us.netrek.org >https://mailman.real-time.com/mailman/listinfo/vanilla-list _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From 007 at freemail.at Sat Dec 8 13:15:50 2001 From: 007 at freemail.at (Kurt Siegl) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: References: Message-ID: <200112081909.UAA17253@mx0.atnet.at> On Saturday 08 December 2001 14:47, Trent Piepho wrote: > On Sat, 8 Dec 2001, James Cameron wrote: > > Subject to it working properly with the feature packet from a server, I > > have no problems with the patch. > > That's the problem. The windows clients ignore the feature packet from the > server, and use continuous mouse anyway. Most (all) servers have > continuous mouse turned off, so all windows clients are pretty much borgs > in this regard. I think there are really two options to this. > > The first is to revoke the RSA key of all clients which ignore the server's > continuous mouse setting, since they are borgs. I don't think this is a > very good idea, as it will cause a lot of problems with people being unable > to connect. > > The second is to decide that continuous mouse isn't a server controlled > feature, and let unix clients ignore the server setting just like the > windows clients. Since most players have continuous mouse, it can't be > that borg of a feature. We will have to fix the bug in the windows client and use the server settings. COW client policy is: 1) Whenever there are features in question COW will either not use them or allow them with server controlled features. 2) Whenever there are server controlled features COW must use them. The rules are particulary importaint for using COW in INL or other league games. Kurt (007) COW sourcekeeper -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@freemail.at Tel (ISDN): *(7225)7017 URL: http://members.aon.at/presents/siegl/kurt/ From xyzzy at speakeasy.org Sat Dec 8 17:57:47 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: <200112081909.UAA17260@mx0.atnet.at> Message-ID: On Sat, 8 Dec 2001, Kurt Siegl wrote: > > feature, and let unix clients ignore the server setting just like the > > windows clients. Since most players have continuous mouse, it can't be > > that borg of a feature. > > We will have to fix the bug in the windows client and use the server settings. So I take it that you are for revoking the keys used by probably 80% of the current netrek players? From quozl at us.netrek.org Sat Dec 8 19:00:59 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:52 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011208124739.A25755@mark.mielke.cc>; from mark@mark.mielke.cc on Sat, Dec 08, 2001 at 12:47:39PM -0500 References: <20011207111617.A20905@mark.mielke.cc> <20011208020752.E22626@mark.mielke.cc> <20011208194716.X32243@us.netrek.org> <20011208124739.A25755@mark.mielke.cc> Message-ID: <20011209120059.A32243@us.netrek.org> Think long term. Code the server to adjust to the correct behaviour over a period of four years. Keep both camps happy. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Sat Dec 8 19:13:00 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: ; from xyzzy@speakeasy.org on Sat, Dec 08, 2001 at 03:57:47PM -0800 References: <200112081909.UAA17260@mx0.atnet.at> Message-ID: <20011209121300.C32243@us.netrek.org> On Sat, Dec 08, 2001 at 03:57:47PM -0800, Trent Piepho wrote: > So I take it that you are for revoking the keys used by probably 80% of the > current netrek players? That's a stupid idea, Trent. Why don't you write to each of the server gods instead and make sure they have continuousMouse enabled in their .feature files, and issue a patch to the server code base so that future servers have it enabled? -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From ssheldon at sodablue.org Sat Dec 8 20:05:03 2001 From: ssheldon at sodablue.org (Steve Sheldon) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: Message-ID: <000201c18055$eb441e50$8400000a@inside.sodablue.com> Trent Piepho: > On Sat, 8 Dec 2001, Kurt Siegl wrote: > > > feature, and let unix clients ignore the server setting just like > > > the windows clients. Since most players have continuous > mouse, it > > > can't be that borg of a feature. > > > > We will have to fix the bug in the windows client and use > the server > > settings. > > So I take it that you are for revoking the keys used by > probably 80% of the current netrek players? Naw, it's been fixed in my NetrekNT branch since 11-Jan-99. I found what I did. It was in mswindow.c. Basically the problem was that the features packet was setting a variable motion_mouse_enablable, but it wasn't being validated in the mouse handling routines. Here's the code fragment from my fix: #if defined(MOTION_MOUSE) || defined(XTRA_MESSAGE_UI) // SRS placed this here to fix the not being able to disable continuous mouse functions if (!motion_mouse || (!motion_mouse_enablable && !motion_mouse_steering)) return (0); if ((win->type != WIN_GRAPH) || (hwnd != LastPressHwnd)) return(0); // only allow in graphics windows and must be the window last clicked in // (the latter avoids a bug where Windows sends a mousemove message // to a window exposed when the one on top is hidden/destroyed) To be honest, I think it works but I really hate the way I fixed it as it's not readable code. The feature packets is another section of code I wanted to rewrite in a clear and consistent manner. From xyzzy at speakeasy.org Sat Dec 8 20:25:38 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: <20011208124739.A25755@mark.mielke.cc> Message-ID: On Sat, 8 Dec 2001, Mark Mielke wrote: > Unfortunately, the problem still remains: (Range is -1000..999) > > -1000, -800, -600, -400, -200, 0, 200, 400, 600, 800 > 5 4 3 2 1 0 1 2 3 4 > > This time, however, after Trent's correction, the issue is somewhat > reduced. Instead of the extra location being 1 of 4 positions, it is > 1 of 10 positions. The client may draw the ship up to 5 pixels left > or up from the actual location, but only 4 pixels down or right from > the actual location. You are still wrong here. Each of those 10 positions isn't equally likely. If the random number is 0-199, you get 0 pixels off. If it's 200-399 you get 1 pixel right. The only way to get 5 pixels left, is if the random number is exactly -1000. Four pixels to the left is 200 times more common than 5 pixels to the left. You are only going to get the 5 pixel case off 0.05% of the time. You also aren't taking into account that the initial position of the ship isn't going to be 0. You might have it be 1 or 199, in which case the rounding comes out differently. From xyzzy at speakeasy.org Sun Dec 9 00:31:23 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: <20011209121300.C32243@us.netrek.org> Message-ID: On Sun, 9 Dec 2001, James Cameron wrote: > On Sat, Dec 08, 2001 at 03:57:47PM -0800, Trent Piepho wrote: > > So I take it that you are for revoking the keys used by probably 80% of the > > current netrek players? > > That's a stupid idea, Trent. Why don't you write to each of the server > gods instead and make sure they have continuousMouse enabled in their > .feature files, and issue a patch to the server code base so that future > servers have it enabled? So why is it that windows clients can have continuous mouse turned on but unix clients can't? From 007 at freemail.at Sun Dec 9 03:41:12 2001 From: 007 at freemail.at (Kurt Siegl) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: References: Message-ID: <200112090933.KAA23871@mx0.atnet.at> On Sunday 09 December 2001 00:57, Trent Piepho wrote: > On Sat, 8 Dec 2001, Kurt Siegl wrote: > > > feature, and let unix clients ignore the server setting just like the > > > windows clients. Since most players have continuous mouse, it can't be > > > that borg of a feature. > > > > We will have to fix the bug in the windows client and use the server > > settings. > > So I take it that you are for revoking the keys used by probably 80% of the > current netrek players? No, it's just a bug. It's not that serious that we should revoke the key. But for the next release it must be definitly fixed. I'm only against introducing a bug as a feature. Kurt -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@freemail.at Tel (ISDN): *(7225)7017 URL: http://members.aon.at/presents/siegl/kurt/ From xyzzy at speakeasy.org Sun Dec 9 05:45:43 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: <200112090933.KAA23870@mx0.atnet.at> Message-ID: On Sun, 9 Dec 2001, Kurt Siegl wrote: > On Sunday 09 December 2001 00:57, Trent Piepho wrote: > > On Sat, 8 Dec 2001, Kurt Siegl wrote: > > > > feature, and let unix clients ignore the server setting just like the > > > > windows clients. Since most players have continuous mouse, it can't be > > > > that borg of a feature. > > > > > > We will have to fix the bug in the windows client and use the server > > > settings. > > > > So I take it that you are for revoking the keys used by probably 80% of the > > current netrek players? > > No, it's just a bug. It's not that serious that we should revoke the key. But > for the next release it must be definitly fixed. > > I'm only against introducing a bug as a feature. If it's not serious enough to revoke the key, then why is it serious to not allow other clients to do? I get requests form people asking me to add continuous mouse into paradise 2000 because they miss it from their windows client. It sounds to me like you're saying that continuous mouse is borg, unless you use windows, then it's not borg enough to matter. Or is there some kind of statute of limitations on borgs, so if you RSA bless a borg and no one complains then you can't revoke the key when people do notice? From 007 at freemail.at Sun Dec 9 07:11:05 2001 From: 007 at freemail.at (Kurt Siegl) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] continuousMouse In-Reply-To: References: Message-ID: <200112091303.OAA24475@mx0.atnet.at> On Sunday 09 December 2001 12:45, Trent Piepho wrote: > > No, it's just a bug. It's not that serious that we should revoke the key. > > But for the next release it must be definitly fixed. > > > > I'm only against introducing a bug as a feature. > > If it's not serious enough to revoke the key, then why is it serious to not > allow other clients to do? I get requests form people asking me to add > continuous mouse into paradise 2000 because they miss it from their windows > client. > > It sounds to me like you're saying that continuous mouse is borg, unless > you use windows, then it's not borg enough to matter. Or is there some > kind of statute of limitations on borgs, so if you RSA bless a borg and no > one complains then you can't revoke the key when people do notice? I do not imply, continuous mouse is a borg feature. Fact is it is a questionable feature, where people have different opinion on whether it is borgish or not. And COW policy is that it is a client out of any questions. So that's why we introduced the feature packets, to let the server GOD decide what he thinks is borgish or not. To be pragmatic, for a questionable feature like this, we should not react so hard to remove the keys imediatly, but we should fix it to eliminate any possible doubt for future. Lateron we still may decide on removing the old keys. So the better way is to convince the server GODs to turn the feature on, on the server. Kurt -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@freemail.at Tel (ISDN): *(7225)7017 URL: http://members.aon.at/presents/siegl/kurt/ From mark at mark.mielke.cc Sun Dec 9 11:28:09 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] Growing Netrek - Measures In-Reply-To: ; from xyzzy@speakeasy.org on Sat, Dec 08, 2001 at 06:25:38PM -0800 References: <20011208124739.A25755@mark.mielke.cc> Message-ID: <20011209122809.A5311@mark.mielke.cc> On Sat, Dec 08, 2001 at 06:25:38PM -0800, Trent Piepho wrote: > On Sat, 8 Dec 2001, Mark Mielke wrote: > > Unfortunately, the problem still remains: (Range is -1000..999) > > -1000, -800, -600, -400, -200, 0, 200, 400, 600, 800 > > 5 4 3 2 1 0 1 2 3 4 > > This time, however, after Trent's correction, the issue is somewhat > > reduced. Instead of the extra location being 1 of 4 positions, it is > > 1 of 10 positions. The client may draw the ship up to 5 pixels left > > or up from the actual location, but only 4 pixels down or right from > > the actual location. > You are still wrong here. Each of those 10 positions isn't equally likely. > If the random number is 0-199, you get 0 pixels off. If it's 200-399 you get > 1 pixel right. The only way to get 5 pixels left, is if the random number is > exactly -1000. Four pixels to the left is 200 times more common than > 5 pixels to the left. You are only going to get the 5 pixel case off > 0.05% of the time. Rounding is down, not 'towards 0'. Their is 1/10 chance that the number will be -1000..-801. Correct? That entire range is -5 pixels. The next range is -800..-601, and is -4 pixels. -600..-401 is -3 pixels, -400..-201 is -2 pixels, -200..-1 is -1 pixel, 0..199 is 0, 200..399 is +1 pixel, 400..599 is +2 pixels, 600..799 is +3 pixels, 800..999 is +4 pixels. There is one more possibility out of 10 that the ship will show up far to the left on the X axis, and one more possibility out of 10 that the ship will show up far to the top on Y axis. (This, suggesting that there is a 1 in 100 chance that the ship could show up 7 pixels distance to the topleft, but only a 1 in 100 chance that the ship could show up 5.6 pixels distance to the bottomright) Out of 100 possible positions (10x10), that the ship could equally be displayed at, 1 position is accurate, 16 positions are in the bottom right sector, 10+10-2=18 positions are on an axis, 100-1-16-18=65 positions are in the other 3 sectors. 3x16=48. 48 is quite shy of 65. > You also aren't taking into account that the initial position of the ship > isn't going to be 0. You might have it be 1 or 199, in which case the > rounding comes out differently. This is the argument that invalidates my argument. If the position is +100, it is already 1/20 chance of being -5, and 1/20 of being +5. If the position is +199, ~1/10 chance of being +5 and ~0 chance of being -5, etc. Hmm... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Sun Dec 9 21:52:12 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots Message-ID: <20011209225212.A7043@mark.mielke.cc> I actually started coding away. As I intend all 'bots to function as appendages to a single unit, I've had to take a look at socket code. Almost all of it will have to re-written. The reason? Almost all the code assumes access to global variables. With up to 8 players functioning from a single process, this simply will not do. This isn't as bad as it seems. The only reason the current code is so complicated, I believe, is due to the large amount of legacy code that is interspersed with new code. Even after years of evolution, while the code definately looks a lot prettier in many areas, one can see remnants of xtrek. Other insertions into the code, such as colourful language under certain conditions, remain mildly amusing. :-) The code will be broken into layers, with each layer represented by one or more thread. The kernel will be used to schedule the priorities of the layers, to allow the code itself to be as streamlined as possible. As a sample for how this will work, ranking tentative layers from highest priority to lowest priority: - data processing + will take data off the server sockets, populate the client specific structures, then update the global structures. + will notify other layers of interesting observations that may warrant more immediate attention. - combat engine (may be broken up if responsiveness would not suffer) NOTE: Any of these functions may be specifically disabled by the targetting layer on a ship by ship basis. + will ensure that the shield is up when advantageous, and down when advantageous. (shield takes up fuel and does not allow hull damage to be repaired) + will deal with temporary overrides to velocity to evade torps, plasmas, or phaser range for all ships. The preference is to maintain the target velocity. If a combat excursion affects the ability for a ship to arrive at a target on schedule, the targetting layer will be notified. + will tractor/repress team mates to effect lateral movement, and/or to temporarily improve acceleration. + will tractor/repress enemies orbitting a planet that may offer them an advantage. Advantages include, but are not limited to: beaming down armies, beaming up armies, bombing, making use of a friendly repair resource, making use of a friendly fuel resource, moving away from our position around the orbit of the planet. + will tractor/repress enemies to adjust enemy positions to be more suitable. This would include pressing a ship closer to a team mate to allow them to phaser the ship, pushing them closer to a torp stream or plasma that would otherwise miss because the player altered course unexpectedly, to pull a ship closer for any of these reasons, to press or tractor a ship away from one of our own if it is scheduled to explode. + will schedule torp patterns for all ships. + will schedule phaser blasts for all ships. This may include phasering an enemy plasma, if it judged that it's trajectory puts it in line with one of our ships that cannot dodge, or does not wish to dodge. The enemy plasma may also be phasered if it is in proximity to another enemy ship. + will schedule plasma shot for all ships. + will schedule the detonation of enemy torpedoes by all ships to minimize damage for the entire unit. (i.e. less valuable ships will choose to accept damage before more valuable ships - if two ships are escorting, they may take turns detonating to ensure that they both continue living) + will detonate any specific torpedoes that will not do damage, if it is judged that a new torpedo may be necessary by the next update, and the 'targetting computers' have reached the limit of 8 torpedoes. + will cloak if advantageous, or uncloak if advantageous. + will toggle between repair/maxwarp if hull damage is present, and it is possible to maintain the target velocity. + if especially damaged, the ship may enter repair state. The targetting layer will be notified. - targetting + will accept list of objectives from strategy layer, and determine among our available set of ships, which is capable of best achieving the top few set of objectives. Several ships may be assigned to an objective, or one ship may be assigned to an objective. If an objective is not possible, either because certain criteria are not met (i.e. to take the planet, at least one of our ships needs to obtain a few kills and beam up some armies), the objective may be temporarily overlooked, or the criteria may be tackled. + ships will be assigned specific courses, velocities. The targetting layer will perform ship synchronization, as for example, ogging of an SB. + once a target is achieved, the targetting layer may perform an action of its own. For example, if a target is 'lock on Den', then when the ship arrives at Den, the targetting layer may initiate bombing/beamup/beamdown. + the targetting layer may perform tactical suicide. If an enemy bomber is near the home planet, the targetting layer may instruct an especially damaged ship with few kills or armies to cruise into a torpedo stream, or orbit a nearby enemy planet. - defensive analysis + will analyze motion and actions of enemy ships, attempting to discern enemy targets, potential enemy targets, or enemy ships that should be eliminated (they may have armies, or kills, or they may be too powerful (SB), or they may be too causing us trouble). Summary is in the form of a list of objectives, such as 'guard Den', 'ogg F7', 'escort R5'. The objectives will be a little more detailed, such as: 'guard area (x1, y1)-(x2, y2) stationed around (x3, y3)' or: 'escort R5 (dx1, dy1)-(dx2, dy2) stationed around (dx3, dy3)'. + if interesting information is available, the strategy layer may be notified - offensive analysis + will analyze the existing set of planets and enemy ships, to determine the order that the planets should be taken. + if interesting information is available, the strategy layer may be notified - strategy + will take objectives from offensive analysis and defensive analysis, weigh them, vary them according to experience, and present the combined list that is used by the targetting layer. At each stage, several strategies may be employed, or variations of several strategies may be employed. Characteristics of enemy players will be maintained to ensure that a strategy that rarely succeeds against a certain player, will not be employed again. This applies to general strategy, but it also applies to such things as torpedo patterns. Traditional robots employ a single algorithm for launching torpedoes. While the algorithms used are often quite difficult to combat, for especially clued players, patterns can be determined and exploited. As an example, a clued player may find that it is easier for their style of play to kill a robot by plinking them. In this case, the robot would take note of this, and *all* robots may choose to get into close quarters when combatting that specific player. They all 'learn' from each others mistakes, allowing the team to quickly adapt even with no prior history. Certain players may be judged as being exceptionally excellent dog-fighters, in which case, a single bot would avoid ever being on the same tactical screen as the player, and the team would only ever attack the player if two or more robots were available. All of these observations will take into account the class of ships. I.e. perhaps the SC would realize that it should never go against "Captain Ogger" if he has a BB, but with BB vs. BB, the robot is safe. In this case, all SC's would give "Captain Ogger" an extremely wide berth, while all BB's would go straight in for the kill. Also, the robot team would not assume that 'ability to kill' a player means success. If the robot ship is left crippled, or out of fuel, this is not a success. If, in the above case, the SC robot could destroy "Captain Ogger" every time, but always be left with an empty tank of fuel, the SC robots would still give "Captain Ogger" wide berth, although perhaps not as wide of one. Robot plinkers can be just as effective as human plinkers... :-) After I have a functional baseline, or even before, does anybody want to help out? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From ddamout1 at san.rr.com Mon Dec 10 00:04:07 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011209225212.A7043@mark.mielke.cc> Message-ID: <000701c18140$7aefa3e0$3b824b42@san.rr.com> From: "Mark Mielke" intelligent 'bots > I actually started coding away. As I intend all 'bots to function as > appendages to a single unit, I've had to take a look at socket code. What is the point of designing a robot team that cheats by communicating through sockets instead of normal messaging? The bots will be playing a different game than the humans. Why don't you add some socket code in the server to give your bots more information, while you're at it? Or just give them 300 shields and hull, and gonzo phasers. Dan Damouth From mark at mark.mielke.cc Mon Dec 10 08:03:22 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <000701c18140$7aefa3e0$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Sun, Dec 09, 2001 at 10:04:07PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> Message-ID: <20011210090322.A9562@mark.mielke.cc> On Sun, Dec 09, 2001 at 10:04:07PM -0800, Daniel Damouth wrote: > From: "Mark Mielke" > intelligent 'bots > > I actually started coding away. As I intend all 'bots to function as > > appendages to a single unit, I've had to take a look at socket code. > What is the point of designing a robot team that cheats by communicating > through sockets instead of normal messaging? The bots will be playing a > different game than the humans. > > Why don't you add some socket code in the server to give your bots more > information, while you're at it? Or just give them 300 shields and hull, > and gonzo phasers. Define 'cheats'. Does 'cheats' mean that rules are violated? By running client side, no rules are violated. In *ANY* game, the ability to win, in terms of potential, can be expressed entirely on how well one is able to exploit the given ruleset to ones advantage. Is "butt-torping" cheating? Perhaps many people look down on it, but is it truly cheating? Is the fact that a few people have found an element of the game that 'runs' in their favour 'cheating'? Why not? Because the intrique is in tackling the problem space. If the 'bots choose to live under horrible restrictions such as 'you can never ever fire a torpedo backwards if you are going faster than warp 4, because some people might consider this cheating', they will never win. Human players do such things all the time. The 'bots have to make up for how 'dynamic' human players are *somehow*. Accuracy and efficiency is where the 'bots have a chance. Is there a problem with the 'bots making use of information more efficiently than human players possibly could? Two netrek players who sit in the same room can say "I'm coming up from behind him, distract while I ogg". Is this not 'communicating on a channel other than the messaging protocol'? Are you worried? :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Mon Dec 10 08:43:29 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <000701c18140$7aefa3e0$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Sun, Dec 09, 2001 at 10:04:07PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> Message-ID: <20011210094329.B9562@mark.mielke.cc> I forgot to mention this in my last message... On Sun, Dec 09, 2001 at 10:04:07PM -0800, Daniel Damouth wrote: > From: "Mark Mielke" > intelligent 'bots > > I actually started coding away. As I intend all 'bots to function as > > appendages to a single unit, I've had to take a look at socket code. > What is the point of designing a robot team that cheats by communicating > through sockets instead of normal messaging? The bots will be playing a > different game than the humans. A different game? Isn't that what makes Netrek so interesting? With so many variables, it is not often that one will see the 'same game', twice. The planets will not be taken in the same order, the same number of armies are not initially bombed in the same length of time, etc. It is the *same game*, in that both games are Netrek. Both sets of clients are forced to follow "THE" rules, in that they must all pass through the ntserv interface. The fact that humans would rarely be capable of synchronization at such a granular level may mean a significant advantage for the robot team, but is this really morally wrong somehow? Should the robot team restrict itself to "reflexes that a human could make"? (i.e. purposefully don't notice the plasma, if the way it is drawn on the COW client makes it invisible on top of the enemy ship... wait until it gets closer...) What kind of restrictions are these? The "rules" of Netrek are defined in the server that this mailing list was created for. There is no "rule" that says that team mates cannot share information either through talking to each other (on the phone, or across the room), or through datastream. A human can relay a rather complicated message through the messaging system such as "ogg F4, sync on R2". They can often generate these messages using macros. A human player can parse the message, use a little bit of interpretation regarding where and how they should be positioned, and jump into it, with the confidence that they will be able to deal with any situation that arises by carefully watching their opponents. Other than inefficiency, this is no different than 'bots communicating with each other, or further, a single 'bot manipulation all ships. As I mentioned before, one of the primary problems with 'bots of the past, is the scheduling of available resources. Two robots should never bomb the same planet at the same time unless it is determined that sufficient armies exist on that planet, and that there is a time window that requires two robots to performing bombing in order to complete successfully instead of one. Human players instinctly know this, and when they see somebody ahead of them, will usually choose correctly as to who remains and bombs, and who tackles another planet. The 'bots don't know *anything* instinctively. Programming them to think ahead by several planets, and several enemy moves, and then distributing the work appropriately is only more efficient. It isn't really any worse than having a Captain of the team who is an observer, messaging the team "Ok, R2... you take Hyd, and R3, you bomb Ear." It's just more efficient. Would you expect a robot team to be more efficient, or less efficient, than a human team? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From netrek at shentel.net Mon Dec 10 14:36:29 2001 From: netrek at shentel.net (Shaun Foley) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <20011210090322.A9562@mark.mielke.cc> Message-ID: <002001c181ba$59a26680$f11d6fcc@sfoley> I think the socket communication could be classified in a category similar to the continuousMouse. It may be borgish, perhaps not, but due to the questionable nature, it may be better to remove it. I think it would be helpful if they used normal message boards, however, since it would make observing/reviewing these games much more interesting. Who wants to stare at an empty team board the entire game? -Shaun ===== > On Sun, Dec 09, 2001 at 10:04:07PM -0800, Daniel Damouth wrote: > > From: "Mark Mielke" > > intelligent 'bots > > > I actually started coding away. As I intend all 'bots to function as > > > appendages to a single unit, I've had to take a look at socket code. > > What is the point of designing a robot team that cheats by communicating > > through sockets instead of normal messaging? The bots will be playing a > > different game than the humans. > > > > Why don't you add some socket code in the server to give your bots more > > information, while you're at it? Or just give them 300 shields and hull, > > and gonzo phasers. > > Define 'cheats'. Does 'cheats' mean that rules are violated? > > By running client side, no rules are violated. In *ANY* game, the ability > to win, in terms of potential, can be expressed entirely on how well one > is able to exploit the given ruleset to ones advantage. > > Is "butt-torping" cheating? Perhaps many people look down on it, but is it > truly cheating? Is the fact that a few people have found an element of the > game that 'runs' in their favour 'cheating'? > > Why not? Because the intrique is in tackling the problem space. If the > 'bots choose to live under horrible restrictions such as 'you can > never ever fire a torpedo backwards if you are going faster than warp > 4, because some people might consider this cheating', they will never > win. Human players do such things all the time. The 'bots have to make up > for how 'dynamic' human players are *somehow*. Accuracy and efficiency is > where the 'bots have a chance. Is there a problem with the 'bots making > use of information more efficiently than human players possibly could? > > Two netrek players who sit in the same room can say "I'm coming up > from behind him, distract while I ogg". Is this not 'communicating on > a channel other than the messaging protocol'? > > Are you worried? :-) > > mark From mark at mark.mielke.cc Mon Dec 10 16:11:07 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <002001c181ba$59a26680$f11d6fcc@sfoley>; from netrek@shentel.net on Mon, Dec 10, 2001 at 03:36:29PM -0500 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <20011210090322.A9562@mark.mielke.cc> <002001c181ba$59a26680$f11d6fcc@sfoley> Message-ID: <20011210171107.A11641@mark.mielke.cc> On Mon, Dec 10, 2001 at 03:36:29PM -0500, Shaun Foley wrote: > I think the socket communication could be classified in a category similar > to the continuousMouse. It may be borgish, perhaps not, but due to the > questionable nature, it may be better to remove it. I think it would be > helpful if they used normal message boards, however, since it would make > observing/reviewing these games much more interesting. Who wants to stare > at an empty team board the entire game? Hehe... thing is... this beast, whatever it is, will definately be 'borg'. Not 'borgish'. When it comes to 'isn't this feature a little borgish?' when adding to a 'borg', the answer becomes somewhat amusing... :-) As for 'who wants to stare at an empty team board', it wouldn't be hard at all for each ship to announce targets as they accept them. F4->FED Moving to Den F2->FED Ogging R2... F4->FED In position around Den. Guarding it with my life! mark > ===== > > > On Sun, Dec 09, 2001 at 10:04:07PM -0800, Daniel Damouth wrote: > > > From: "Mark Mielke" > > > intelligent 'bots > > > > I actually started coding away. As I intend all 'bots to function as > > > > appendages to a single unit, I've had to take a look at socket code. > > > What is the point of designing a robot team that cheats by communicating > > > through sockets instead of normal messaging? The bots will be playing a > > > different game than the humans. > > > > > > Why don't you add some socket code in the server to give your bots more > > > information, while you're at it? Or just give them 300 shields and > hull, > > > and gonzo phasers. > > > > Define 'cheats'. Does 'cheats' mean that rules are violated? > > > > By running client side, no rules are violated. In *ANY* game, the ability > > to win, in terms of potential, can be expressed entirely on how well one > > is able to exploit the given ruleset to ones advantage. > > > > Is "butt-torping" cheating? Perhaps many people look down on it, but is it > > truly cheating? Is the fact that a few people have found an element of the > > game that 'runs' in their favour 'cheating'? > > > > Why not? Because the intrique is in tackling the problem space. If the > > 'bots choose to live under horrible restrictions such as 'you can > > never ever fire a torpedo backwards if you are going faster than warp > > 4, because some people might consider this cheating', they will never > > win. Human players do such things all the time. The 'bots have to make up > > for how 'dynamic' human players are *somehow*. Accuracy and efficiency is > > where the 'bots have a chance. Is there a problem with the 'bots making > > use of information more efficiently than human players possibly could? > > > > Two netrek players who sit in the same room can say "I'm coming up > > from behind him, distract while I ogg". Is this not 'communicating on > > a channel other than the messaging protocol'? > > > > Are you worried? :-) > > > > mark > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From xyzzy at speakeasy.org Mon Dec 10 16:29:15 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:53 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <002001c181ba$59a26680$f11d6fcc@sfoley> Message-ID: On Mon, 10 Dec 2001, Shaun Foley wrote: > I think the socket communication could be classified in a category similar > to the continuousMouse. It may be borgish, perhaps not, but due to the > questionable nature, it may be better to remove it. I think it would be > helpful if they used normal message boards, however, since it would make > observing/reviewing these games much more interesting. Who wants to stare > at an empty team board the entire game? This is getting silly. Next you're going to say the it's unfair for a robot to communicate directly with the server. They have to run a normal blessed client and use image and shape recognition on the client's display to play. They also have to use fake mouse motion events to play, otherwise they could torp and phaser in two directions at the same time. And they need to speak english to communicate. If they just uuecode binary data and send that over the message system it's cheating. From brian at thePaulsens.com Mon Dec 10 12:04:41 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011209225212.A7043@mark.mielke.cc> Message-ID: <029c01c181a5$2caff300$0200a8c0@lehman.com> I'm not sure you really want to do that. One strange seg fault could crash the whole system. A better approach is to have the brains of the operation be a separate process that each of the bots communicate with. This would allow you to put the bot brains on to a separate machine (for CPU reasons) and then divide the bots up on to other machines. If one bot crashes, you don't lose 7 others along with it. Also, you then don't have to worry about people using global variables. Cleaning up the code is going to be a major project and really isn't worth it. Brian ----- Original Message ----- From: "Mark Mielke" To: Sent: Sunday, December 09, 2001 10:52 PM Subject: [Vanilla List] organized, intelligent 'bots > I actually started coding away. As I intend all 'bots to function as > appendages to a single unit, I've had to take a look at socket code. > > Almost all of it will have to re-written. The reason? Almost all the > code assumes access to global variables. With up to 8 players > functioning from a single process, this simply will not do. > > This isn't as bad as it seems. The only reason the current code is so > complicated, I believe, is due to the large amount of legacy code that > is interspersed with new code. Even after years of evolution, while > the code definately looks a lot prettier in many areas, one can see > remnants of xtrek. Other insertions into the code, such as colourful > language under certain conditions, remain mildly amusing. :-) > > The code will be broken into layers, with each layer represented by > one or more thread. The kernel will be used to schedule the priorities > of the layers, to allow the code itself to be as streamlined as > possible. As a sample for how this will work, ranking tentative layers > from highest priority to lowest priority: > > - data processing > + will take data off the server sockets, populate the client > specific structures, then update the global structures. > + will notify other layers of interesting observations that may > warrant more immediate attention. > - combat engine (may be broken up if responsiveness would not suffer) > NOTE: Any of these functions may be specifically disabled by > the targetting layer on a ship by ship basis. > + will ensure that the shield is up when advantageous, and down > when advantageous. (shield takes up fuel and does not allow hull > damage to be repaired) > + will deal with temporary overrides to velocity to evade torps, > plasmas, or phaser range for all ships. The preference is to > maintain the target velocity. If a combat excursion affects > the ability for a ship to arrive at a target on schedule, the > targetting layer will be notified. > + will tractor/repress team mates to effect lateral movement, and/or > to temporarily improve acceleration. > + will tractor/repress enemies orbitting a planet that may offer them > an advantage. Advantages include, but are not limited to: beaming > down armies, beaming up armies, bombing, making use of a > friendly repair resource, making use of a friendly fuel resource, > moving away from our position around the orbit of the planet. > + will tractor/repress enemies to adjust enemy positions to > be more suitable. This would include pressing a ship closer to > a team mate to allow them to phaser the ship, pushing them closer > to a torp stream or plasma that would otherwise miss because the > player altered course unexpectedly, to pull a ship closer for any > of these reasons, to press or tractor a ship away from one of our > own if it is scheduled to explode. > + will schedule torp patterns for all ships. > + will schedule phaser blasts for all ships. This may include > phasering an enemy plasma, if it judged that it's trajectory > puts it in line with one of our ships that cannot dodge, or > does not wish to dodge. The enemy plasma may also be phasered > if it is in proximity to another enemy ship. > + will schedule plasma shot for all ships. > + will schedule the detonation of enemy torpedoes by all ships > to minimize damage for the entire unit. (i.e. less valuable > ships will choose to accept damage before more valuable ships - > if two ships are escorting, they may take turns detonating to > ensure that they both continue living) > + will detonate any specific torpedoes that will not do damage, if > it is judged that a new torpedo may be necessary by the next update, > and the 'targetting computers' have reached the limit of 8 > torpedoes. > + will cloak if advantageous, or uncloak if advantageous. > + will toggle between repair/maxwarp if hull damage is present, > and it is possible to maintain the target velocity. > + if especially damaged, the ship may enter repair state. The > targetting layer will be notified. > - targetting > + will accept list of objectives from strategy layer, and determine > among our available set of ships, which is capable of best > achieving the top few set of objectives. Several ships may be > assigned to an objective, or one ship may be assigned to an > objective. If an objective is not possible, either because certain > criteria are not met (i.e. to take the planet, at least one > of our ships needs to obtain a few kills and beam up some armies), > the objective may be temporarily overlooked, or the criteria > may be tackled. > + ships will be assigned specific courses, velocities. The targetting > layer will perform ship synchronization, as for example, ogging of > an SB. > + once a target is achieved, the targetting layer may perform an > action of its own. For example, if a target is 'lock on Den', then > when the ship arrives at Den, the targetting layer may initiate > bombing/beamup/beamdown. > + the targetting layer may perform tactical suicide. If an enemy > bomber is near the home planet, the targetting layer may instruct > an especially damaged ship with few kills or armies to cruise > into a torpedo stream, or orbit a nearby enemy planet. > - defensive analysis > + will analyze motion and actions of enemy ships, attempting to > discern enemy targets, potential enemy targets, or enemy ships > that should be eliminated (they may have armies, or kills, or they > may be too powerful (SB), or they may be too causing us trouble). > Summary is in the form of a list of objectives, such as 'guard Den', > 'ogg F7', 'escort R5'. > The objectives will be a little more detailed, such as: > 'guard area (x1, y1)-(x2, y2) stationed around (x3, y3)' > or: > 'escort R5 (dx1, dy1)-(dx2, dy2) stationed around (dx3, dy3)'. > + if interesting information is available, the strategy layer may > be notified > - offensive analysis > + will analyze the existing set of planets and enemy ships, to > determine the order that the planets should be taken. > + if interesting information is available, the strategy layer may > be notified > - strategy > + will take objectives from offensive analysis and defensive analysis, > weigh them, vary them according to experience, and present the > combined list that is used by the targetting layer. > > At each stage, several strategies may be employed, or variations of > several strategies may be employed. Characteristics of enemy players > will be maintained to ensure that a strategy that rarely succeeds > against a certain player, will not be employed again. This applies to > general strategy, but it also applies to such things as torpedo > patterns. > > Traditional robots employ a single algorithm for launching > torpedoes. While the algorithms used are often quite difficult to > combat, for especially clued players, patterns can be determined and > exploited. As an example, a clued player may find that it is easier > for their style of play to kill a robot by plinking them. In this > case, the robot would take note of this, and *all* robots may choose > to get into close quarters when combatting that specific player. They > all 'learn' from each others mistakes, allowing the team to quickly > adapt even with no prior history. > > Certain players may be judged as being exceptionally excellent > dog-fighters, in which case, a single bot would avoid ever being on > the same tactical screen as the player, and the team would only ever > attack the player if two or more robots were available. All of these > observations will take into account the class of ships. I.e. perhaps > the SC would realize that it should never go against "Captain Ogger" > if he has a BB, but with BB vs. BB, the robot is safe. In this case, > all SC's would give "Captain Ogger" an extremely wide berth, while all > BB's would go straight in for the kill. > > Also, the robot team would not assume that 'ability to kill' a player > means success. If the robot ship is left crippled, or out of fuel, > this is not a success. If, in the above case, the SC robot could > destroy "Captain Ogger" every time, but always be left with an empty > tank of fuel, the SC robots would still give "Captain Ogger" wide > berth, although perhaps not as wide of one. Robot plinkers can be just > as effective as human plinkers... :-) > > After I have a functional baseline, or even before, does anybody want > to help out? > > mark > > -- > mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ > . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder > |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | > | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada > > One ring to rule them all, one ring to find them, one ring to bring them all > and in the darkness bind them... > > http://mark.mielke.cc/ > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From brian at thePaulsens.com Mon Dec 10 12:05:03 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> Message-ID: <029e01c181a5$3123c7e0$0200a8c0@lehman.com> Why would messaging through sockets be cheating? Surely, we don't consider INL teams sitting all in one room to be cheating, do we? Why should they be allowed to communicate outside the normal messaging system, but bots can't? Brian ----- Original Message ----- From: "Daniel Damouth" To: Sent: Monday, December 10, 2001 1:04 AM Subject: Re: [Vanilla List] organized, intelligent 'bots > From: "Mark Mielke" > intelligent 'bots > > > > I actually started coding away. As I intend all 'bots to function as > > appendages to a single unit, I've had to take a look at socket code. > > What is the point of designing a robot team that cheats by communicating > through sockets instead of normal messaging? The bots will be playing a > different game than the humans. > > Why don't you add some socket code in the server to give your bots more > information, while you're at it? Or just give them 300 shields and hull, > and gonzo phasers. > > Dan Damouth > > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From mark at mark.mielke.cc Mon Dec 10 18:03:44 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <029c01c181a5$2caff300$0200a8c0@lehman.com>; from brian@thePaulsens.com on Mon, Dec 10, 2001 at 01:04:41PM -0500 References: <20011209225212.A7043@mark.mielke.cc> <029c01c181a5$2caff300$0200a8c0@lehman.com> Message-ID: <20011210190344.B11641@mark.mielke.cc> On Mon, Dec 10, 2001 at 01:04:41PM -0500, Brian Paulsen wrote: > I'm not sure you really want to do that. One strange seg fault could crash > the whole system. This is certainly true. > A better approach is to have the brains of the operation > be a separate process that each of the bots communicate with. This would > allow you to put the bot brains on to a separate machine (for CPU reasons) > and then divide the bots up on to other machines. If one bot crashes, you > don't lose 7 others along with it. I wish to ensure a minimal response time, even taking into account the fact that all data will be piped through a single process. If the slave is on a different machine than the brain, the one layer removed that may improve stability, sacrifices efficiency and responsiveness. I don't need stability, if the process doesn't crash. Also, the slaves will not have sufficient intelligence to function on their own. If the brain segfaults, the clients are left to wander on their current course anyways. An elaborate mechanism could be constructed to allow the brain to 'resume' control of the clients... but I would prefer to squash segfaults, than spend time attempting to prepare for all eventualities. I intend for my attempt to succeed, because it does boldly accept challenges that have previously imposed restrictions, and twist them into an advantage. I also intend to have the bot teams run simulations for several hundred hours between themselves before daring to introduce them to the INL. :-) > Also, you then don't have to worry about people using global variables. > Cleaning up the code is going to be a major project and really isn't worth > it. Most of the code is actually quite simple. I plan to have the basic functions complete in only a few hours of work. It won't be today, but we'll see about Wednesday. I will make every attempt to ensure that the results of the effort can be re-used by others. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From doosh at inl.org Mon Dec 10 19:48:11 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011210190344.B11641@mark.mielke.cc>; from mark@mark.mielke.cc on Mon, Dec 10, 2001 at 07:03:44PM -0500 References: <20011209225212.A7043@mark.mielke.cc> <029c01c181a5$2caff300$0200a8c0@lehman.com> <20011210190344.B11641@mark.mielke.cc> Message-ID: <20011210174811.A5035@inl.org> On Mon, Dec 10, 2001 at 07:03:44PM -0500, Mark Mielke wrote: > > I will make every attempt to ensure that the results of the effort can > be re-used by others. Great. When you print it out, remember that I prefer the "double roll" MD-brand toilet paper. -Tom From Darryl_Palmer_Jr at acm.org Mon Dec 10 20:08:03 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011210190344.B11641@mark.mielke.cc> Message-ID: I guess the question come back to what our are individual goals. One of my goals was to create a totally autonomous netrek team that could beat the best the INL could muster, but it wasn't the most important one. The most important goal I had was to setup a league and the infrastructure to allow other people to write their own bots and compete with them. We are not the first ones that thought of creating bots for netreks, and other people have made bots before. But then how many of these bots are currently maintained, and did the creation of these bots lead to more people playing netrek or even more people creating bots? I don't want this endeavor to reach a dead-end like most of the previous work. If we create a robotic netrek league, we can push having different classifications of bots and allowing team plus individual entry. Because we would have a league, it wouldn't matter that much if people drop out later on, and by making it more public we might be able to sucker the public in general to participate in our competitions. Who knows, someone could probably sucker their local IEEE, ACM, AAAI, or AUVS to sponser something like that. How many years are we planning on participating in this endeavor? And will we still participate if we beat an INL team, or on the other hand, never even getting close to beating a chaos team? Darryl -----Original Message----- I also intend to have the bot teams run simulations for several hundred hours between themselves before daring to introduce them to the INL. :-) > Also, you then don't have to worry about people using global variables. > Cleaning up the code is going to be a major project and really isn't worth > it. Most of the code is actually quite simple. I plan to have the basic functions complete in only a few hours of work. It won't be today, but we'll see about Wednesday. I will make every attempt to ensure that the results of the effort can be re-used by others. mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011210/3f730db2/smime.bin From Darryl_Palmer_Jr at acm.org Mon Dec 10 20:13:41 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <029c01c181a5$2caff300$0200a8c0@lehman.com> Message-ID: The best approach is to keep the brains in your head, and have a human observer control the entire team through messaging. This will allow the bots to only handle low-level activities, and while this doesn't classify as a fully autonomous team, they are still not borgs but bots. You gain an advantage of being able to just watch the galactic and play the role of "commander," while the bot grunts do the work. In fact, there might be no reason at all to look at the local window. Darryl -----Original Message----- From: vanilla-list-admin@us.netrek.org [mailto:vanilla-list-admin@us.netrek.org]On Behalf Of Brian Paulsen Sent: Monday, December 10, 2001 12:05 PM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] organized, intelligent 'bots I'm not sure you really want to do that. One strange seg fault could crash the whole system. A better approach is to have the brains of the operation be a separate process that each of the bots communicate with. This would allow you to put the bot brains on to a separate machine (for CPU reasons) and then divide the bots up on to other machines. If one bot crashes, you don't lose 7 others along with it. Also, you then don't have to worry about people using global variables. Cleaning up the code is going to be a major project and really isn't worth it. Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011210/f118a9fa/smime.bin From ddamout1 at san.rr.com Mon Dec 10 22:09:58 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> Message-ID: <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> From: "Brian Paulsen" > Why would messaging through sockets be cheating? Surely, we don't consider > INL teams sitting all in one room to be cheating, do we? Why should they be > allowed to communicate outside the normal messaging system, but bots can't? Sophisticated methods of communicating, such as beeplite, are considered cheating/borgish. And what he's suggesting goes way beyond beeplite. If I built any special socket code into my team's clients, it would not be INL/WNL legal. It would be blatant cheating. There is no way humans can do what he describes. Even sitting right next to someone doesn't come close. Dan Damouth From mark at mark.mielke.cc Mon Dec 10 22:06:46 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: ; from Darryl_Palmer_Jr@acm.org on Mon, Dec 10, 2001 at 08:13:41PM -0600 References: <029c01c181a5$2caff300$0200a8c0@lehman.com> Message-ID: <20011210230646.A12345@mark.mielke.cc> On Mon, Dec 10, 2001 at 08:13:41PM -0600, Darryl Palmer Jr wrote: > The best approach is to keep the brains in your head, and have a human > observer control the entire team through messaging. This will allow the > bots to only handle low-level activities, and while this doesn't classify > as a fully autonomous team, they are still not borgs but bots. You gain > an advantage of being able to just watch the galactic and play the role of > "commander," while the bot grunts do the work. In fact, there might be no > reason at all to look at the local window. It may be difficult to dynamically manage 5 or more separate objectives from a message window. Then again, perhaps that would be the mark of a true commander... I still want a team that functions completely independent of human instruction. However, I don't see any harm in ensuring that the code properly separates the low-level combat and targetting engines from the higher level objective determination code. If properly implemented, this would allow for the objective determination code to function independently, or for it to only accept instructions from an observing "commander". This applies to lower levels as well. Specific defensive patterns or offensive patterns could be inserted into the code that normally 'adapts' as a form of override. The observing commander could instruct the team to "F3,F4,F5: ogg R2 using pattern delta-5, sync on F4". Specifically, this would aid in the implementation and debugging of individual patterns. It would also look very startrek-like to an observer. After all, isn't it the computers job to target enemies? :-) In the future, who in their right mind would always disable the auto-pilot? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Mon Dec 10 22:21:15 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011210174811.A5035@inl.org>; from doosh@inl.org on Mon, Dec 10, 2001 at 05:48:11PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <029c01c181a5$2caff300$0200a8c0@lehman.com> <20011210190344.B11641@mark.mielke.cc> <20011210174811.A5035@inl.org> Message-ID: <20011210232115.B12345@mark.mielke.cc> On Mon, Dec 10, 2001 at 05:48:11PM -0800, Tom Holub wrote: > On Mon, Dec 10, 2001 at 07:03:44PM -0500, Mark Mielke wrote: > > I will make every attempt to ensure that the results of the effort can > > be re-used by others. > Great. When you print it out, remember that I prefer the "double > roll" MD-brand toilet paper. You'll need it. That is, after you shit your pants after witnessing the robots descend upon your planets, and destroy them, one by one. :-) If they do manage to be good enough, which is still up for discussion after witnessing them, pending initial implementation, I will program in a special mode especially for you designed specifically to IND all of your planets... one by one. No takes. I don't expect that such a mode would succeed against an especially clued INL team, however, I don't see why it wouldn't succeed against most players. Consider it a major 'handicap' for the bots. I am very intrigued to witness the results of this endeavour. At this point in time, I am curious as to whether your cynicism will change, or remain? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Mon Dec 10 22:28:01 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011210190344.B11641@mark.mielke.cc>; from mark@mielke.cc on Mon, Dec 10, 2001 at 07:03:44PM -0500 References: <20011209225212.A7043@mark.mielke.cc> <029c01c181a5$2caff300$0200a8c0@lehman.com> <20011210190344.B11641@mark.mielke.cc> Message-ID: <20011210232801.C12345@mark.mielke.cc> On Mon, Dec 10, 2001 at 07:03:44PM -0500, Mark Mielke wrote: > On Mon, Dec 10, 2001 at 01:04:41PM -0500, Brian Paulsen wrote: > > A better approach is to have the brains of the operation > > be a separate process that each of the bots communicate with. This would > > allow you to put the bot brains on to a separate machine (for CPU reasons) > > and then divide the bots up on to other machines. If one bot crashes, you > > don't lose 7 others along with it. > I wish to ensure a minimal response time, even taking into account the > fact that all data will be piped through a single process. If the > slave is on a different machine than the brain, the one layer removed > that may improve stability, sacrifices efficiency and responsiveness. Another point of interest, is that Netrek has a built in method of 'resuming' normal operation. The ntserv process will actually contact the local client on the "next socket" that was specified when the version information was sent to the server. If the "brain" maintained a persistence cache of information that could not be quickly derived from a request for a full update upon reconnect, including at least the list of "next socket"s for which the Netrek server would contact, the "brain" could pick up where it left off when restarted. Wrap the "brain" process with a script that executed the "brain" process over and over again, and the problem may actually be solved. It certainly beats waiting for dead clients to ghostbust... :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Mon Dec 10 23:37:14 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:54 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <002e01c181f9$b2bc28c0$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Mon, Dec 10, 2001 at 08:09:58PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> Message-ID: <20011211003714.D12345@mark.mielke.cc> On Mon, Dec 10, 2001 at 08:09:58PM -0800, Daniel Damouth wrote: > From: "Brian Paulsen" > > Why would messaging through sockets be cheating? Surely, we don't > > consider INL teams sitting all in one room to be cheating, do we? > > Why should they be allowed to communicate outside the normal > > messaging system, but bots can't? > Sophisticated methods of communicating, such as beeplite, are considered > cheating/borgish. And what he's suggesting goes way beyond beeplite. If I > built any special socket code into my team's clients, it would not be > INL/WNL legal. It would be blatant cheating. > > There is no way humans can do what he describes. Even sitting right next to > someone doesn't come close. > By the same token, it would be impossible for a robot player, given current technology to truly adapt to situations whose variables could not be determined at compile time. Does this make the human player a cheater? You may be able to swivel your hand to torp in one direction, and phaser in another, faster than I can. Does this mean that you are cheating, merely because I am incapable of having as quick reflexes as you do? The 'rules' of Netrek are quite well defined. They can be found in the vanilla source code maintained by this list. The only additional rules, as configured by server administrators, is that the computer cannot be used to 'aid' a player in such ways as may be considered 'cheating' by the server administrator. As it is, it is a *given* that a server administrator that chose to allow a fully automated robot on the server, would do so under the full knowledge that server rules will be exploited to the best of abilities by the robot, and as implemented by the robot designers. In a 'robot league', I would consider the intervention of a *human* player, potentially 'cheating'. Those who play the game according to tradition, are restricted by tradition. Those who exploit the rules to their advantage, have the maximum potential to win. The robots won't be snivelling and crying because they don't have the mental capacity to adapt with as much potential as a human player. What gives humans the right to snivel and cry, because they cannot match the reflexes, or organization potential, of a computer? Consider the true tradition of Netrek. It is based off Star Trek. What is the greatest enemy of all non-Q entities in the galaxy? :-) The borg. Why? Because they do not live by the same rules as the rest of the species in the Universe. Where humanity thrives on independence, the borg thrive on the collective. In the true sense of the word, and the concept, the implementation I am suggesting truly is a mirror of this 'collective' as defined by Star Trek. The abilities of this 'collective' strongly match technologies that are described in Star Trek. Do you fear the borg? :-) Starfleet certainly does... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From Darryl_Palmer_Jr at acm.org Tue Dec 11 00:15:00 2001 From: Darryl_Palmer_Jr at acm.org (Darryl Palmer Jr) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011210230646.A12345@mark.mielke.cc> Message-ID: I don't think there will be that many objectives to keep track of. If there are then we of course have 2 observer slots, but then having two commanders may be worse than having one. Is it possible to adapt conventional three-dimensional fighting tactics to a two-dimensional game? If it is, then we might just be able to consult "public" sources of aircract tactics, such as "Fighter Combat" by Robert Shaw, and adapt them to Netrek. The biggest problem with having a commander is that there are at least 8 individuals on the other team. The biggest benefit is that there are at least 8 individuals on the other team. The bots can think as a collective, it doesn't matter if they have direct socket connections or not. Because we programmed the bots, we can exchange enough context information in the form of normal messages to allow the other bots to know its state. We also have another advantage, we have the source to the INL. The bots know the way that the universe works, so they can better predict outcomes. We know how fast the ships move, how fast the ships turn, what rate their engines and weapons cool. It is possible to come up with a threat evaluator, that takes the guesstimate/estimated enemies ship condition into account along with that players personal track record against various bots or strategies. Darryl -----Original Message----- It may be difficult to dynamically manage 5 or more separate objectives from a message window. Then again, perhaps that would be the mark of a true commander... I still want a team that functions completely independent of human instruction. However, I don't see any harm in ensuring that the code properly separates the low-level combat and targetting engines from the higher level objective determination code. If properly implemented, this would allow for the objective determination code to function independently, or for it to only accept instructions from an observing "commander". This applies to lower levels as well. Specific defensive patterns or offensive patterns could be inserted into the code that normally 'adapts' as a form of override. The observing commander could instruct the team to "F3,F4,F5: ogg R2 using pattern delta-5, sync on F4". Specifically, this would aid in the implementation and debugging of individual patterns. It would also look very startrek-like to an observer. After all, isn't it the computers job to target enemies? :-) In the future, who in their right mind would always disable the auto-pilot? mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3043 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011211/938f5edb/smime.bin From doosh at inl.org Tue Dec 11 01:08:08 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011210232115.B12345@mark.mielke.cc>; from mark@mark.mielke.cc on Mon, Dec 10, 2001 at 11:21:15PM -0500 References: <20011209225212.A7043@mark.mielke.cc> <029c01c181a5$2caff300$0200a8c0@lehman.com> <20011210190344.B11641@mark.mielke.cc> <20011210174811.A5035@inl.org> <20011210232115.B12345@mark.mielke.cc> Message-ID: <20011210230808.A22975@inl.org> On Mon, Dec 10, 2001 at 11:21:15PM -0500, Mark Mielke wrote: > > If they do manage to be good enough, which is still up for discussion > after witnessing them, pending initial implementation, I will program > in a special mode especially for you designed specifically to IND all > of your planets... one by one. No takes. I don't expect that such a > mode would succeed against an especially clued INL team, however, I > don't see why it wouldn't succeed against most players. Consider it a > major 'handicap' for the bots. I am very intrigued to witness the > results of this endeavour. > > At this point in time, I am curious as to whether your cynicism will > change, or remain? How about this: you give me a call when you manage to get them going faster than warp 5. -Tom From ddamout1 at san.rr.com Tue Dec 11 01:51:58 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] the rules of netrek References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> Message-ID: <004001c18218$b6221f00$3b824b42@san.rr.com> From: "Mark Mielke" > On Mon, Dec 10, 2001 at 08:09:58PM -0800, Daniel Damouth wrote: > > From: "Brian Paulsen" > > > Why would messaging through sockets be cheating? Surely, we don't > > > consider INL teams sitting all in one room to be cheating, do we? > > > Why should they be allowed to communicate outside the normal > > > messaging system, but bots can't? > > Sophisticated methods of communicating, such as beeplite, are considered > > cheating/borgish. And what he's suggesting goes way beyond beeplite. If I > > built any special socket code into my team's clients, it would not be > > INL/WNL legal. It would be blatant cheating. > > > > There is no way humans can do what he describes. Even sitting right next to > > someone doesn't come close. > > > > By the same token, it would be impossible for a robot player, given > current technology to truly adapt to situations whose variables could > not be determined at compile time. No, it's not impossible, not even with current technology. But it's also not necessary, if all you want is a robot team that can beat humans. > Does this make the human player a cheater? > > You may be able to swivel your hand to torp in one direction, and phaser > in another, faster than I can. Does this mean that you are cheating, merely > because I am incapable of having as quick reflexes as you do? > > The 'rules' of Netrek are quite well defined. They can be found in the > vanilla source code maintained by this list. The only additional > rules, as configured by server administrators, is that the computer > cannot be used to 'aid' a player in such ways as may be considered > 'cheating' by the server administrator. As it is, it is a *given* that > a server administrator that chose to allow a fully automated robot on > the server, would do so under the full knowledge that server rules > will be exploited to the best of abilities by the robot, and as > implemented by the robot designers. Well, sure, if you're going to change the rules, or find a server god willing to do so, then the bots won't be cheating. But why not play the same game the humans are playing? I.e. use INL rules. Not only is it a more interesting challenge, but it also would make human vs. bot games meaningful. Are you interested in pitting your bots vs. human teams? If so, do the human teams get to modify their clients to instantly exchange information? There are tons of advantages to be had that way, but no real point in doing so because on any normal server, and in any human league, it would be considered cheating. > In a 'robot league', I would consider the intervention of a *human* > player, potentially 'cheating'. I'd agree, although it might potentially be interesting to have a "no holds barred" league, with any combination of human/bot/borg players. (This reminds of the strategy/simulation game "empire", in which players are allowed to write any kind of client they want.) > Those who play the game according to tradition, are restricted by > tradition. Those who exploit the rules to their advantage, have the > maximum potential to win. I agree, but changing the rules to favor the bots just doesn't seem interesting to me, unless you let the humans play under the same rules, and the community realized a long time ago that allowing client developers to automate functions was not a good direction for netrek to evolve in. Generally speaking, making the clients smarter dumbs down the game. > The robots won't be snivelling and crying because they don't have the > mental capacity to adapt with as much potential as a human player. What > gives humans the right to snivel and cry, because they cannot match the > reflexes, or organization potential, of a computer? > > Consider the true tradition of Netrek. It is based off Star Trek. What > is the greatest enemy of all non-Q entities in the galaxy? :-) The > borg. Why? Because they do not live by the same rules as the rest of > the species in the Universe. Where humanity thrives on independence, > the borg thrive on the collective. > > In the true sense of the word, and the concept, the implementation I > am suggesting truly is a mirror of this 'collective' as defined by > Star Trek. The abilities of this 'collective' strongly match > technologies that are described in Star Trek. Most commercial human-vs.-computer strategy games take the some approach, which can be described as "the only way to challenge the human player is to play under different rules". For example, in Civilization, the computer has to cheat extensively to challenge the human player at higher difficulty levels. Nobody really likes the fact that the computer has to cheat. > Do you fear the borg? :-) Starfleet certainly does... The Borg were one of the few actually alien aliens in Star Trek, before the writers gutted the concept by introducing individuals and/or turning them into insects. The day I saw the movie with that stupid Borg Queen was the last day I ever went to a Star Trek movie. Dan Damouth From mark at mark.mielke.cc Tue Dec 11 07:29:12 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] the rules of netrek In-Reply-To: <004001c18218$b6221f00$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Mon, Dec 10, 2001 at 11:51:58PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> Message-ID: <20011211082912.A14788@mark.mielke.cc> On Mon, Dec 10, 2001 at 11:51:58PM -0800, Daniel Damouth wrote: > Well, sure, if you're going to change the rules, or find a server god > willing to do so, then the bots won't be cheating. But why not play the > same game the humans are playing? I.e. use INL rules. Not only is it a > more interesting challenge, but it also would make human vs. bot games > meaningful. No 'rules' have been changed. 'Rules' will be exploited. I'm not certain that exploitation of a ruleset is synanymous with cheating, or changing the rules. Is butt-torping illegal in the INL? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From brian at thePaulsens.com Mon Dec 10 22:08:40 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots References: Message-ID: <000301c1824c$716ed9a0$0200a8c0@hermes> I'm willing to keep a bot hanging around on a server that others can compete against. Does anybody have a good server that would accept bots? Brian ----- Original Message ----- From: "Darryl Palmer Jr" To: Sent: Monday, December 10, 2001 9:08 PM Subject: RE: [Vanilla List] organized, intelligent 'bots > I guess the question come back to what our are individual goals. One of > my goals was to create a totally autonomous netrek team that could beat > the best the INL could muster, but it wasn't the most important one. The > most important goal I had was to setup a league and the infrastructure to > allow other people to write their own bots and compete with them. We are > not the first ones that thought of creating bots for netreks, and other > people have made bots before. But then how many of these bots are > currently maintained, and did the creation of these bots lead to more > people playing netrek or even more people creating bots? > > I don't want this endeavor to reach a dead-end like most of the previous > work. If we create a robotic netrek league, we can push having different > classifications of bots and allowing team plus individual entry. Because > we would have a league, it wouldn't matter that much if people drop out > later on, and by making it more public we might be able to sucker the > public in general to participate in our competitions. Who knows, someone > could probably sucker their local IEEE, ACM, AAAI, or AUVS to sponser > something like that. > > How many years are we planning on participating in this endeavor? And > will we still participate if we beat an INL team, or on the other hand, > never even getting close to beating a chaos team? > > > Darryl > > -----Original Message----- > I also intend to have the bot teams run simulations for several > hundred hours between themselves before daring to introduce them to the > INL. :-) > > > Also, you then don't have to worry about people using global variables. > > Cleaning up the code is going to be a major project and really isn't > worth > > it. > > Most of the code is actually quite simple. I plan to have the basic > functions complete in only a few hours of work. It won't be today, but > we'll see about Wednesday. > > I will make every attempt to ensure that the results of the effort can > be re-used by others. > > mark > From jeffno at ccs.neu.edu Tue Dec 11 07:08:11 2001 From: jeffno at ccs.neu.edu (Jeffrey Nowakowski) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> from "Daniel Damouth" at Dec 10, 2001 08:09:58 PM Message-ID: <20011211130811.C65DF172B5@denali.ccs.neu.edu> "Daniel Damouth" wrote: > > Sophisticated methods of communicating, such as beeplite, are considered > cheating/borgish. You can't use "borgish" as a criteria of what to put/not put into a robot team. By it's very nature the robot is "borgish". As long as the robot isn't getting any special help from the server it isn't cheating. -Jeff From brian at thePaulsens.com Tue Dec 11 08:37:34 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] the rules of netrek References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> Message-ID: <009d01c18251$5fc82a80$0200a8c0@hermes> Let's start with the communication through sockets. Clearly, some communication through sockets should be allowed. For example, if I have one master brain process and all of the bots communicate with that to determine strategy, that should be completely legal. A perfect analogy is that INL teams can sit in one room and maybe somebody else is watching what is going on and yelling out things (like F5 just picked up!) Now, let's talk about communicating cloaker positions (I think this is what bothers you). Surely, anybody can type into the message board the position of the cloaker. If I type in the position over the regular message board, can't others read it? So what if the "mere" humans can't do anything with it? Now, any bot can read the message board and use that information in helping to decide where the cloaker is. Since we are using the regular message board and providing information that everybody has access to, is this now illegal? Just because the bot can process the information faster and actually do something with it makes it illegal? Now, if we combine the two, does that make it illegal? Here's some other ideas... We are engaged in a heavy dogfight of 3 vs. 3. I know that I'm about to run into a stream of torps that I can't possibly avoid. Unless... perhaps if I use some communication method to ask my fellow bots to help tractor/pressor me. We calculate that if my fellow teammates pressor me, I can avoid being hit by the torps. Would that be illegal? How would that be different than a friendly human SB noticing that I'm in trouble and giving me a friendly T/P? The bots keep track of enemy damage (calculating it shouldn't be too difficult) and communicate that so that the bots always know how much fuel/damage an enemy player has. Is that illegal? I think there's many things that the bots can do that most humans either can't or they would have difficulty communicating that to teammates. Who's to say which is illegal and which aren't? What I find fascinating is that if the messaging is done right, the strength of the bot team is greater than the bot parts. In other words, an individual bot would pretty much have to rely on the same restrictions that a normal human would because it would have no one to communicate with. ----- Original Message ----- From: "Daniel Damouth" To: Sent: Tuesday, December 11, 2001 2:51 AM Subject: Re: [Vanilla List] the rules of netrek > From: "Mark Mielke" > > > > On Mon, Dec 10, 2001 at 08:09:58PM -0800, Daniel Damouth wrote: > > > From: "Brian Paulsen" > > > > Why would messaging through sockets be cheating? Surely, we don't > > > > consider INL teams sitting all in one room to be cheating, do we? > > > > Why should they be allowed to communicate outside the normal > > > > messaging system, but bots can't? > > > Sophisticated methods of communicating, such as beeplite, are considered > > > cheating/borgish. And what he's suggesting goes way beyond beeplite. > If I > > > built any special socket code into my team's clients, it would not be > > > INL/WNL legal. It would be blatant cheating. > > > > > > There is no way humans can do what he describes. Even sitting right > next to > > > someone doesn't come close. > > > > > > > By the same token, it would be impossible for a robot player, given > > current technology to truly adapt to situations whose variables could > > not be determined at compile time. > > No, it's not impossible, not even with current technology. But it's also > not necessary, if all you want is a robot team that can beat humans. > > > Does this make the human player a cheater? > > > > You may be able to swivel your hand to torp in one direction, and phaser > > in another, faster than I can. Does this mean that you are cheating, > merely > > because I am incapable of having as quick reflexes as you do? > > > > The 'rules' of Netrek are quite well defined. They can be found in the > > vanilla source code maintained by this list. The only additional > > rules, as configured by server administrators, is that the computer > > cannot be used to 'aid' a player in such ways as may be considered > > 'cheating' by the server administrator. As it is, it is a *given* that > > a server administrator that chose to allow a fully automated robot on > > the server, would do so under the full knowledge that server rules > > will be exploited to the best of abilities by the robot, and as > > implemented by the robot designers. > > Well, sure, if you're going to change the rules, or find a server god > willing to do so, then the bots won't be cheating. But why not play the > same game the humans are playing? I.e. use INL rules. Not only is it a > more interesting challenge, but it also would make human vs. bot games > meaningful. > > Are you interested in pitting your bots vs. human teams? If so, do the > human teams get to modify their clients to instantly exchange information? > There are tons of advantages to be had that way, but no real point in doing > so because on any normal server, and in any human league, it would be > considered cheating. > > > In a 'robot league', I would consider the intervention of a *human* > > player, potentially 'cheating'. > > I'd agree, although it might potentially be interesting to have a "no holds > barred" league, with any combination of human/bot/borg players. (This > reminds of the strategy/simulation game "empire", in which players are > allowed to write any kind of client they want.) > > > Those who play the game according to tradition, are restricted by > > tradition. Those who exploit the rules to their advantage, have the > > maximum potential to win. > > I agree, but changing the rules to favor the bots just doesn't seem > interesting to me, unless you let the humans play under the same rules, and > the community realized a long time ago that allowing client developers to > automate functions was not a good direction for netrek to evolve in. > Generally speaking, making the clients smarter dumbs down the game. > > > The robots won't be snivelling and crying because they don't have the > > mental capacity to adapt with as much potential as a human player. What > > gives humans the right to snivel and cry, because they cannot match the > > reflexes, or organization potential, of a computer? > > > > Consider the true tradition of Netrek. It is based off Star Trek. What > > is the greatest enemy of all non-Q entities in the galaxy? :-) The > > borg. Why? Because they do not live by the same rules as the rest of > > the species in the Universe. Where humanity thrives on independence, > > the borg thrive on the collective. > > > > In the true sense of the word, and the concept, the implementation I > > am suggesting truly is a mirror of this 'collective' as defined by > > Star Trek. The abilities of this 'collective' strongly match > > technologies that are described in Star Trek. > > Most commercial human-vs.-computer strategy games take the some approach, > which can be described as "the only way to challenge the human player is to > play under different rules". For example, in Civilization, the computer has > to cheat extensively to challenge the human player at higher difficulty > levels. Nobody really likes the fact that the computer has to cheat. > > > Do you fear the borg? :-) Starfleet certainly does... > > The Borg were one of the few actually alien aliens in Star Trek, before the > writers gutted the concept by introducing individuals and/or turning them > into insects. The day I saw the movie with that stupid Borg Queen was the > last day I ever went to a Star Trek movie. > > Dan Damouth > > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From ddamout1 at san.rr.com Tue Dec 11 09:18:03 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> Message-ID: <000d01c18257$076e0160$3b824b42@san.rr.com> From: "Jeffrey Nowakowski" > "Daniel Damouth" wrote: > > > > Sophisticated methods of communicating, such as beeplite, are considered > > cheating/borgish. > > You can't use "borgish" as a criteria of what to put/not put into a > robot team. By it's very nature the robot is "borgish". As long as > the robot isn't getting any special help from the server it isn't > cheating. There are plenty of ways to cheat that don't involve the server. A big reason for having "blessed" clients is to prevent the kind of cheating that Mark's bots will do. If a robot is doing things that are illegal for a human to do, such as communicating through sockets with other clients, it is cheating. Dan Damouth From ddamout1 at san.rr.com Tue Dec 11 09:20:48 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] the rules of netrek References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> <20011211082912.A14788@mark.mielke.cc> Message-ID: <001701c18257$699c4860$3b824b42@san.rr.com> ----- Original Message ----- From: "Mark Mielke" To: Sent: Tuesday, December 11, 2001 5:29 AM Subject: Re: [Vanilla List] the rules of netrek > On Mon, Dec 10, 2001 at 11:51:58PM -0800, Daniel Damouth wrote: > > Well, sure, if you're going to change the rules, or find a server god > > willing to do so, then the bots won't be cheating. But why not play the > > same game the humans are playing? I.e. use INL rules. Not only is it a > > more interesting challenge, but it also would make human vs. bot games > > meaningful. > > No 'rules' have been changed. 'Rules' will be exploited. If no rules have been changed, then my client should be able to tell other clients everything it is seeing, and vice-versa. Why do you think that feature is not allowed in any blessed clients? (Because it's a rule). > I'm not certain that exploitation of a ruleset is synanymous with > cheating, or changing the rules. Is butt-torping illegal in the INL? Butt torping is allowed, but socket communication between clients is not. That's what rules are; they allow some things, but not others. Dan Damouth From doosh at inl.org Tue Dec 11 10:44:07 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] the rules of netrek In-Reply-To: <009d01c18251$5fc82a80$0200a8c0@hermes>; from brian@thePaulsens.com on Tue, Dec 11, 2001 at 09:37:34AM -0500 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> <009d01c18251$5fc82a80$0200a8c0@hermes> Message-ID: <20011211084407.B50365@inl.org> On Tue, Dec 11, 2001 at 09:37:34AM -0500, Brian Paulsen wrote: > > Now, let's talk about communicating cloaker positions (I think this is what > bothers you). Surely, anybody can type into the message board the position > of the cloaker. If I type in the position over the regular message board, > can't others read it? So what if the "mere" humans can't do anything with > it? Well, if you had a client that could show other players, on their tactical, where your client is displaying the cloaker, by a beep-lite macro for example, yes, I think most people would think that's cheating. But I don't think it's really important for robot players; the problems of robot players have nothing to do with tactical combat. -Tom From doosh at inl.org Tue Dec 11 10:40:43 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] the rules of netrek In-Reply-To: <004001c18218$b6221f00$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Mon, Dec 10, 2001 at 11:51:58PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> Message-ID: <20011211084043.A50365@inl.org> On Mon, Dec 10, 2001 at 11:51:58PM -0800, Daniel Damouth wrote: > > Most commercial human-vs.-computer strategy games take the some approach, > which can be described as "the only way to challenge the human player is to > play under different rules". For example, in Civilization, the computer has > to cheat extensively to challenge the human player at higher difficulty > levels. Nobody really likes the fact that the computer has to cheat. "Cheating" by having one brain controlling 8 ships on the same team is a lot different than cheating by having all the other races in the game gang up on you, or by changing the resource allocation rules. I think it's the wrong focus for the project and I don't think it will provide useful returns, but I don't think it's philisophically a big problem. -Tom From mark at mark.mielke.cc Tue Dec 11 11:41:53 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <000d01c18257$076e0160$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Tue, Dec 11, 2001 at 07:18:03AM -0800 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> Message-ID: <20011211124153.A15573@mark.mielke.cc> On Tue, Dec 11, 2001 at 07:18:03AM -0800, Daniel Damouth wrote: > From: "Jeffrey Nowakowski" > > You can't use "borgish" as a criteria of what to put/not put into a > > robot team. By it's very nature the robot is "borgish". As long as > > the robot isn't getting any special help from the server it isn't > > cheating. > If a robot is doing things that are illegal for a human to do, such as > communicating through sockets with other clients, it is cheating. You do realize that what you are suggesting, is that if a person opens an IRC window to speak to his other team mates (IRC uses TCP/IP), that this team is now "cheating" under your definition of the term. Heck, all of ICQ / MSN / AIM use "sockets" to communicate. Is it illegal for a human player to make use of any of these mechanisms of communication? You know... perhaps if the Robots communicated using audio only, you would consider it legal? I.e. if the robots were all attached to separate microphone/speaker pairs, and the microphone/speakers were kept in a single room. Or, as somebody else suggested, would you demand that they used the English language to communicate with each other? If they *did* use the English language, and voice recognition software, would it be illegal for them to speak at upwards of 600 words per minute? This is pure insanity, Daniel. You are trying to bind my hands together on this one. At least Tom doesn't think it's cheating. He just thinks it won't work, or that it isn't worth the effort. :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Tue Dec 11 11:44:53 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <000301c1824c$716ed9a0$0200a8c0@hermes>; from brian@thePaulsens.com on Mon, Dec 10, 2001 at 11:08:40PM -0500 References: <000301c1824c$716ed9a0$0200a8c0@hermes> Message-ID: <20011211124453.B15573@mark.mielke.cc> On Mon, Dec 10, 2001 at 11:08:40PM -0500, Brian Paulsen wrote: > I'm willing to keep a bot hanging around on a server that others can compete > against. Does anybody have a good server that would accept bots? I'm going to have a business Internet connection installed in my home in 2 days. If everything works well, I'll run it myself. Of course, if the 'bots just plain suck, like most of the other 'bots that have existed, this won't be an issue. If they don't suck, people can pound of them whenever they want. :-) mark > ----- Original Message ----- > From: "Darryl Palmer Jr" > To: > Sent: Monday, December 10, 2001 9:08 PM > Subject: RE: [Vanilla List] organized, intelligent 'bots > > > > I guess the question come back to what our are individual goals. One of > > my goals was to create a totally autonomous netrek team that could beat > > the best the INL could muster, but it wasn't the most important one. The > > most important goal I had was to setup a league and the infrastructure to > > allow other people to write their own bots and compete with them. We are > > not the first ones that thought of creating bots for netreks, and other > > people have made bots before. But then how many of these bots are > > currently maintained, and did the creation of these bots lead to more > > people playing netrek or even more people creating bots? > > > > I don't want this endeavor to reach a dead-end like most of the previous > > work. If we create a robotic netrek league, we can push having different > > classifications of bots and allowing team plus individual entry. Because > > we would have a league, it wouldn't matter that much if people drop out > > later on, and by making it more public we might be able to sucker the > > public in general to participate in our competitions. Who knows, someone > > could probably sucker their local IEEE, ACM, AAAI, or AUVS to sponser > > something like that. > > > > How many years are we planning on participating in this endeavor? And > > will we still participate if we beat an INL team, or on the other hand, > > never even getting close to beating a chaos team? > > > > > > Darryl > > > > -----Original Message----- > > I also intend to have the bot teams run simulations for several > > hundred hours between themselves before daring to introduce them to the > > INL. :-) > > > > > Also, you then don't have to worry about people using global variables. > > > Cleaning up the code is going to be a major project and really isn't > > worth > > > it. > > > > Most of the code is actually quite simple. I plan to have the basic > > functions complete in only a few hours of work. It won't be today, but > > we'll see about Wednesday. > > > > I will make every attempt to ensure that the results of the effort can > > be re-used by others. > > > > mark > > > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From brian at thePaulsens.com Tue Dec 11 14:11:05 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:55 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <000301c1824c$716ed9a0$0200a8c0@hermes> <20011211124453.B15573@mark.mielke.cc> Message-ID: <004601c18280$7e597060$0200a8c0@lehman.com> Ok, I'm taking a little offense here... Are you building your bot from scratch, or are you using somebody else's code as a starting point? The reason I ask is that I haven't seen that many bots that "just plain suck" I've seen many bots (mine included) that play quite well and have given INL teams a struggle. It's just that there are many complexities to the game and it's difficult to code all of the strategy in that is necessary to beat an INL team. I'd be very curious to see how well your bots do if you are starting from scratch. Brian ----- Original Message ----- From: "Mark Mielke" To: Sent: Tuesday, December 11, 2001 12:44 PM Subject: Re: [Vanilla List] organized, intelligent 'bots > On Mon, Dec 10, 2001 at 11:08:40PM -0500, Brian Paulsen wrote: > > I'm willing to keep a bot hanging around on a server that others can compete > > against. Does anybody have a good server that would accept bots? > > I'm going to have a business Internet connection installed in my home > in 2 days. If everything works well, I'll run it myself. > > Of course, if the 'bots just plain suck, like most of the other 'bots > that have existed, this won't be an issue. If they don't suck, people > can pound of them whenever they want. :-) > > mark > > > > > ----- Original Message ----- > > From: "Darryl Palmer Jr" > > To: > > Sent: Monday, December 10, 2001 9:08 PM > > Subject: RE: [Vanilla List] organized, intelligent 'bots > > > > > > > I guess the question come back to what our are individual goals. One of > > > my goals was to create a totally autonomous netrek team that could beat > > > the best the INL could muster, but it wasn't the most important one. The > > > most important goal I had was to setup a league and the infrastructure to > > > allow other people to write their own bots and compete with them. We are > > > not the first ones that thought of creating bots for netreks, and other > > > people have made bots before. But then how many of these bots are > > > currently maintained, and did the creation of these bots lead to more > > > people playing netrek or even more people creating bots? > > > > > > I don't want this endeavor to reach a dead-end like most of the previous > > > work. If we create a robotic netrek league, we can push having different > > > classifications of bots and allowing team plus individual entry. Because > > > we would have a league, it wouldn't matter that much if people drop out > > > later on, and by making it more public we might be able to sucker the > > > public in general to participate in our competitions. Who knows, someone > > > could probably sucker their local IEEE, ACM, AAAI, or AUVS to sponser > > > something like that. > > > > > > How many years are we planning on participating in this endeavor? And > > > will we still participate if we beat an INL team, or on the other hand, > > > never even getting close to beating a chaos team? > > > > > > > > > Darryl > > > > > > -----Original Message----- > > > I also intend to have the bot teams run simulations for several > > > hundred hours between themselves before daring to introduce them to the > > > INL. :-) > > > > > > > Also, you then don't have to worry about people using global variables. > > > > Cleaning up the code is going to be a major project and really isn't > > > worth > > > > it. > > > > > > Most of the code is actually quite simple. I plan to have the basic > > > functions complete in only a few hours of work. It won't be today, but > > > we'll see about Wednesday. > > > > > > I will make every attempt to ensure that the results of the effort can > > > be re-used by others. > > > > > > mark > > > > > > > _______________________________________________ > > vanilla-list mailing list > > vanilla-list@us.netrek.org > > https://mailman.real-time.com/mailman/listinfo/vanilla-list > > -- > mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ > . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder > |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | > | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada > > One ring to rule them all, one ring to find them, one ring to bring them all > and in the darkness bind them... > > http://mark.mielke.cc/ > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From doosh at inl.org Tue Dec 11 13:46:53 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011211124153.A15573@mark.mielke.cc>; from mark@mark.mielke.cc on Tue, Dec 11, 2001 at 12:41:53PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> Message-ID: <20011211114653.A67104@inl.org> On Tue, Dec 11, 2001 at 12:41:53PM -0500, Mark Mielke wrote: > On Tue, Dec 11, 2001 at 07:18:03AM -0800, Daniel Damouth wrote: > > From: "Jeffrey Nowakowski" > > > You can't use "borgish" as a criteria of what to put/not put into a > > > robot team. By it's very nature the robot is "borgish". As long as > > > the robot isn't getting any special help from the server it isn't > > > cheating. > > If a robot is doing things that are illegal for a human to do, such as > > communicating through sockets with other clients, it is cheating. > > You do realize that what you are suggesting, is that if a person opens > an IRC window to speak to his other team mates (IRC uses TCP/IP), that > this team is now "cheating" under your definition of the term. You're an idiot. > At least Tom doesn't think it's cheating. He just thinks it won't work, > or that it isn't worth the effort. :-) There are a lot of things robots do that really are cheating. For example, they always know the speed of other ships on their tactical, and they have the equivalent of "show cloakers on tactical". It's not really possible to hold them to human standards; they process information differently. -Tom From ahn at vec.wfubmc.edu Tue Dec 11 15:25:27 2001 From: ahn at vec.wfubmc.edu (Dave Ahn) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011211124153.A15573@mark.mielke.cc>; from mark@mark.mielke.cc on Tue, Dec 11, 2001 at 12:41:53PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> Message-ID: <20011211162527.A176784@cecum.vec.wfubmc.edu> On Tue, Dec 11, 2001 at 12:41:53PM -0500, Mark Mielke wrote: > > Heck, all of ICQ / MSN / AIM use "sockets" to communicate. Is it illegal > for a human player to make use of any of these mechanisms of communication? There is a difference between improving the interpretation of the same information that is available to every player and gaining new information that is not supposed to be available to every player. The more you rely on the latter to build your robot team, the less credible and interesting your experiment becomes. Consider this example. Human players often call "Fa is free beer" to indicate a damaged ship. Suppose that your robot team kept a global and up-to-date list of all ship stats that are shared by all robots and used it to guide the team strategy. Would it work? Probably. Is it "fair?" Probably not. Is it impressive? No. An important part of the netrek game is the ambiguity and the unknown. Entire games are won on the basis of a fake warp-1 SB that draws oggs at the end of regulation while teammates drop for the win. If you have to rely on GOD-MODE to make up for the insufficient AI heuristics in your robots who are unable to function under the same conditions as humans, then your project is simply a math exercise. If I were writing an AI robot, I would modify the Vanilla code to allow observers to pilot a ship and get it installed on a public server. I would then create an AI robot that could fly the ship to be at the right place at the right time and send a message to the team saying, "I should be here, doing this." If the robot were correct at least 50% of the time, it'd be very impressive. -- Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center When you were born, you cried and the world rejoiced. Try to live your life so that when you die, you will rejoice and the world will cry. -1/2 jj^2 From mark at mark.mielke.cc Tue Dec 11 15:25:10 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <004601c18280$7e597060$0200a8c0@lehman.com>; from brian@thePaulsens.com on Tue, Dec 11, 2001 at 03:11:05PM -0500 References: <000301c1824c$716ed9a0$0200a8c0@hermes> <20011211124453.B15573@mark.mielke.cc> <004601c18280$7e597060$0200a8c0@lehman.com> Message-ID: <20011211162510.D15573@mark.mielke.cc> On Tue, Dec 11, 2001 at 03:11:05PM -0500, Brian Paulsen wrote: > Are you building your bot from scratch, or are you using somebody else's > code as a starting point? The reason I ask is that I haven't seen that many > bots that "just plain suck" I've seen many bots (mine included) that play > quite well and have given INL teams a struggle. It's just that there are > many complexities to the game and it's difficult to code all of the strategy > in that is necessary to beat an INL team. It isn't exactly from scratch. I diddled with this sort of thing 10 years ago. It is from scratch from a coding perspective. Many 'bots, including the "Grandfather borg", while well done, were quite exploitable. You just had to spend a few more minutes in the game not caring about dying, choosing instead to watch how the bot kills you. After a while, it is quite easy to find their flaws and exploit them. That being said, I would appreciate your input, or even code. The only reason the code is starting from 'scratch', is that it is not likely to be in a form that is compatible with anything that currently exists. Often code can be incorporated without limiting one to cut+paste functionality. > I'd be very curious to see how well your bots do if you are starting from > scratch. I am, as well. (Curious) Especially if you have a functioning set of bots that can compete against it. Priority 1 is to beat existing bots. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From brian at thePaulsens.com Tue Dec 11 16:41:02 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211114653.A67104@inl.org> Message-ID: <014201c18294$f93bc8a0$0200a8c0@lehman.com> There's only one thing that bots do that humans really can't, and I believe I took that code out of my bot because I considered it cheating (also, I couldn't decide if it's a good idea to use it) They can det their own torps individually. Regular humans have to detonate all or none. Other than that, I really don't consider anything else a bot does as cheating. Always knowing an opponent's speed? Please... what bot author in their right mind would use the speed information from the server? It's far better to calculate the person's speed so that you can figure out if he's being tractored or pressored. Also, you are immune from server gods who decide they want to mess with bots by removing the speed info. Finally, a good player doesn't need to see the person's speed to know what it is. After a few thousand hours of playing, you can quickly determine from eyesight what speed the guy is going. Brian ----- Original Message ----- From: "Tom Holub" To: Sent: Tuesday, December 11, 2001 2:46 PM Subject: Re: [Vanilla List] organized, intelligent 'bots > On Tue, Dec 11, 2001 at 12:41:53PM -0500, Mark Mielke wrote: > > On Tue, Dec 11, 2001 at 07:18:03AM -0800, Daniel Damouth wrote: > > > From: "Jeffrey Nowakowski" > > > > You can't use "borgish" as a criteria of what to put/not put into a > > > > robot team. By it's very nature the robot is "borgish". As long as > > > > the robot isn't getting any special help from the server it isn't > > > > cheating. > > > If a robot is doing things that are illegal for a human to do, such as > > > communicating through sockets with other clients, it is cheating. > > > > You do realize that what you are suggesting, is that if a person opens > > an IRC window to speak to his other team mates (IRC uses TCP/IP), that > > this team is now "cheating" under your definition of the term. > > You're an idiot. > > > At least Tom doesn't think it's cheating. He just thinks it won't work, > > or that it isn't worth the effort. :-) > > There are a lot of things robots do that really are cheating. For example, > they always know the speed of other ships on their tactical, and they > have the equivalent of "show cloakers on tactical". It's not really > possible to hold them to human standards; they process information > differently. > -Tom > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From brian at thePaulsens.com Tue Dec 11 16:40:59 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <000301c1824c$716ed9a0$0200a8c0@hermes> <20011211124453.B15573@mark.mielke.cc> <004601c18280$7e597060$0200a8c0@lehman.com> <20011211162510.D15573@mark.mielke.cc> Message-ID: <014101c18294$f921d800$0200a8c0@lehman.com> Let me know when you want to compete. I have FreeBot up and going again. Brian ----- Original Message ----- From: "Mark Mielke" To: Sent: Tuesday, December 11, 2001 4:25 PM Subject: Re: [Vanilla List] organized, intelligent 'bots > On Tue, Dec 11, 2001 at 03:11:05PM -0500, Brian Paulsen wrote: > > Are you building your bot from scratch, or are you using somebody else's > > code as a starting point? The reason I ask is that I haven't seen that many > > bots that "just plain suck" I've seen many bots (mine included) that play > > quite well and have given INL teams a struggle. It's just that there are > > many complexities to the game and it's difficult to code all of the strategy > > in that is necessary to beat an INL team. > > It isn't exactly from scratch. I diddled with this sort of thing 10 > years ago. It is from scratch from a coding perspective. > > Many 'bots, including the "Grandfather borg", while well done, were > quite exploitable. You just had to spend a few more minutes in the > game not caring about dying, choosing instead to watch how the bot > kills you. After a while, it is quite easy to find their flaws and > exploit them. > > That being said, I would appreciate your input, or even code. The only > reason the code is starting from 'scratch', is that it is not likely > to be in a form that is compatible with anything that currently exists. > > Often code can be incorporated without limiting one to cut+paste > functionality. > > > I'd be very curious to see how well your bots do if you are starting from > > scratch. > > I am, as well. (Curious) > > Especially if you have a functioning set of bots that can compete > against it. Priority 1 is to beat existing bots. > > mark > > -- > mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ > . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder > |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | > | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada > > One ring to rule them all, one ring to find them, one ring to bring them all > and in the darkness bind them... > > http://mark.mielke.cc/ > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From brian at thePaulsens.com Tue Dec 11 16:41:04 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> Message-ID: <014301c18294$f95bd3c0$0200a8c0@lehman.com> I'm not exactly sure how you make the cutoff. Let's say that you are writing a bot and you want to be able to allow it to say, "Fa is free beer". How are you going to do this? You are going to keep track of how much phaser damage you inflicted on him plus how much torp damage you inflicted. Let's say you are a stickler for details. You then also calculate how much damage he took from torps that were detted plus torps that hit nearby teammates. You then also keep track of his repair rates. Finally, you include damage for planets that he's flying nearby. You have it worked out so that you can estimate within 5 points of where his shields and hull are. Now, when you are done with the dogfight, what are you going to call out? "Fa is free beer" or "Fa has 0% shields, 31% hull, and 22% fuel"? Let's say that the bot was playing by itself with other human teammates. Which would you rather hear? Hell, let's say that you designed some macros to send this information out. A good player can probably estimate with 20 points what the person's combined shields and hull are at and the fuel can probably be estimated within 1000. If I had macros to send out info like "Fa is without shields and under 25% hull and 25% fuel" would that be cheating? What if I was a super speed typist and got very good at estimating a person's damage? Would I not be able to communicate this info with my team? What if I was in a room with a teammate? Would I have to type this over the message board or could I just load my speech program (sarcasm alert) and "speak" the information and hope that his "voice recognition" program could properly decipher my meaning? I think that applying human ways of doing this to how bots should work is somewhat unfair and pointless. Do we feel that computers cheat at chess because they just look many moves ahead using a brute-force alpha-beta pruning technique rather than actually analyze a position? Now, in practicality, I agree with you on many points. One, a bot has to be smart enough to do the right things even with playing with human teammates. Why? Well, because I had some generous server gods who let me put FreeBot on their server to do some testing. If I required teammates to open up a socket connection to communicate with the bot, I think that would've come to a halt fairly quickly. Personally, I'm intrigued by how a bot performs with human teammates. If it can do that well, having it perform with fellow bot teammates shouldn't be much more difficult. Brian ----- Original Message ----- From: "Dave Ahn" To: Sent: Tuesday, December 11, 2001 4:25 PM Subject: Re: [Vanilla List] organized, intelligent 'bots > On Tue, Dec 11, 2001 at 12:41:53PM -0500, Mark Mielke wrote: > > > > Heck, all of ICQ / MSN / AIM use "sockets" to communicate. Is it illegal > > for a human player to make use of any of these mechanisms of communication? > > There is a difference between improving the interpretation of the same > information that is available to every player and gaining new information > that is not supposed to be available to every player. The more you rely > on the latter to build your robot team, the less credible and interesting > your experiment becomes. > > Consider this example. Human players often call "Fa is free beer" to > indicate a damaged ship. Suppose that your robot team kept a global and > up-to-date list of all ship stats that are shared by all robots and used it > to guide the team strategy. Would it work? Probably. Is it "fair?" > Probably not. Is it impressive? No. > > An important part of the netrek game is the ambiguity and the unknown. > Entire games are won on the basis of a fake warp-1 SB that draws oggs at > the end of regulation while teammates drop for the win. If you have to > rely on GOD-MODE to make up for the insufficient AI heuristics in your > robots who are unable to function under the same conditions as humans, > then your project is simply a math exercise. > > If I were writing an AI robot, I would modify the Vanilla code to allow > observers to pilot a ship and get it installed on a public server. I > would then create an AI robot that could fly the ship to be at the > right place at the right time and send a message to the team saying, > "I should be here, doing this." If the robot were correct at least 50% > of the time, it'd be very impressive. > > -- > Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center > > When you were born, you cried and the world rejoiced. Try to live your life > so that when you die, you will rejoice and the world will cry. -1/2 jj^2 > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From xyzzy at speakeasy.org Tue Dec 11 18:49:28 2001 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] the rules of netrek In-Reply-To: <001701c18257$699c4860$3b824b42@san.rr.com> Message-ID: On Tue, 11 Dec 2001, Daniel Damouth wrote: > > > same game the humans are playing? I.e. use INL rules. Not only is it a > > > more interesting challenge, but it also would make human vs. bot games > > > meaningful. > > > > No 'rules' have been changed. 'Rules' will be exploited. > > If no rules have been changed, then my client should be able to tell other > clients everything it is seeing, and vice-versa. Why do you think that > feature is not allowed in any blessed clients? (Because it's a rule). That is just stupid. It's like saying playing in the same room is cheating because you can talk to each other, and you can't speak to other players with normal clients. From mark at mark.mielke.cc Tue Dec 11 18:33:32 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <014301c18294$f95bd3c0$0200a8c0@lehman.com>; from brian@thePaulsens.com on Tue, Dec 11, 2001 at 05:41:04PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> Message-ID: <20011211193332.A16802@mark.mielke.cc> I'm done with the discussion of cheating vs. non-cheating. It's entirely pointless. It is obvious that a bot should attempt to exploit its skills, and minimize its weaknesses. It is also obvious that the real reason that server Gods choose to disable certain configurable features for clients connected to their server, because they feel that a computer-aided ensign human has the potential to be better than a non-computer-aided commander. Why? Because they get the best of both worlds. Science fiction novels and movies have made references to this throughout modern history. It is no fun playing a game, if you can't compete with the other guy, because half of his skill isn't skill at all. What is truly not cheating, is an independent bot. The human 'advantage' is removed. Independent bots that cannot organize within themselves, almost always end up sucking. Why? Because *any* disorganized team usually sucks. What will my experiment prove, or not prove? It will allow the complexities of Netrek to be properly quantified. What does this give to people who play Netrek just for the fun of it? Absolutely nothing. What does it give to the more academic players who are actually interested in the details of the game? Intrigue. It isn't about being impressive, or about winning. It is about learning. Tom thinks it isn't possible, or that it won't be effective. Other people think it is the ultimate cheat. How is this range of opinion possible? Because it hasn't been done. K... back to Brian, and my response to him... On Tue, Dec 11, 2001 at 05:41:04PM -0500, Brian Paulsen wrote: > Now, in practicality, I agree with you on many points. One, a bot has to be > smart enough to do the right things even with playing with human teammates. > Why? Well, because I had some generous server gods who let me put FreeBot > on their server to do some testing. If I required teammates to open up a > socket connection to communicate with the bot, I think that would've come to > a halt fairly quickly. Personally, I'm intrigued by how a bot performs with > human teammates. If it can do that well, having it perform with fellow bot > teammates shouldn't be much more difficult. Initially I don't plan on ensuring that this will work, however, I've left room for this in the implementation. The targetting layer decides who is best qualified to do what. If it can guess that a human team mate, is already pursuing this goal, or if there is some way for it to understand simple messages sent by the human team mate such as "escort me to Den", this can be accomplished. A potentially interesting twist to this may be... how well would 8 separate robots work, each guiding only themselves, communicating using simple netrek messaging, vs. how well do they perform as a true collective? I don't want to set the bar too high for initial implementation, but I also don't want to cross off the above possibility. A bot team that could function as a collective, a set of two or three sub-collectives, or all complete individuals. *I* am intrigued. I don't really care if anybody else is, although I certainly look forward to working with those who are similarly intrigued. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From quozl at us.netrek.org Tue Dec 11 23:08:12 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011211193332.A16802@mark.mielke.cc>; from mark@mark.mielke.cc on Tue, Dec 11, 2001 at 07:33:32PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@ Message-ID: <20011212160812.G32243@us.netrek.org> On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > It is also obvious that the real reason that server Gods choose to > disable certain configurable features for clients connected to their > server, because they feel that a computer-aided ensign human has the > potential to be better than a non-computer-aided commander. No, you misunderstand. The real reason is that the players demand the perception of fairness of play, and we don't want to annoy them. There are no such technical reasons that you put forth. It is all a matter of perception. Reality, or scientific proof, is irrelevant. It took me a little while to catch on, but as I managed the server continuum.us.netrek.org, I found that I must listen to perception far more than technical arguments. I think you might benefit from the same practice. I understand your arguments, it is just that they are not relevant to my decision making process as the server diety. I'm looking forward to seeing your robots. You can clearly type quite fast and with a low defect rate, and that is a useful skill for a coder. ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From doosh at inl.org Wed Dec 12 00:13:49 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011211193332.A16802@mark.mielke.cc>; from mark@mark.mielke.cc on Tue, Dec 11, 2001 at 07:33:32PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> Message-ID: <20011211221349.A20260@inl.org> On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > Tom thinks it isn't possible, or that it won't be effective. Wrong. I think you're an idiot. It is certainly possible to create a netrek robot that could beat the best human team. It's a very difficult problem, and not one anyone's going to solve by concentrating on tactical improvements. (It's not one you personally are going to solve by any methods). -Tom From mark at mark.mielke.cc Wed Dec 12 03:11:13 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011211221349.A20260@inl.org>; from doosh@inl.org on Tue, Dec 11, 2001 at 10:13:49PM -0800 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> Message-ID: <20011212041113.A18767@mark.mielke.cc> On Tue, Dec 11, 2001 at 10:13:49PM -0800, Tom Holub wrote: > On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > Tom thinks it isn't possible, or that it won't be effective. > Wrong. I think you're an idiot. It is certainly possible to create a > netrek robot that could beat the best human team. It's a very difficult > problem, and not one anyone's going to solve by concentrating on tactical > improvements. (It's not one you personally are going to solve by any > methods). Tactical improvements are the butter between the bread. If the robot can't fight, it can't get a kill. If it can't get a kill, it can't take a planet. 'nuff said... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Wed Dec 12 03:47:23 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011212160812.G32243@us.netrek.org>; from quozl@us.netrek.org on Wed, Dec 12, 2001 at 04:08:12PM +1100 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@ <20011211193332.A16802@mark.mielke.cc> <20011212160812.G32243@us.netrek.org> Message-ID: <20011212044723.B18767@mark.mielke.cc> On Wed, Dec 12, 2001 at 04:08:12PM +1100, James Cameron wrote: > On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > It is also obvious that the real reason that server Gods choose to > > disable certain configurable features for clients connected to their > > server, because they feel that a computer-aided ensign human has the > > potential to be better than a non-computer-aided commander. > No, you misunderstand. The real reason is that the players demand the > perception of fairness of play, and we don't want to annoy them. > There are no such technical reasons that you put forth. It is all a > matter of perception. Reality, or scientific proof, is irrelevant. > > It took me a little while to catch on, but as I managed the server > continuum.us.netrek.org, I found that I must listen to perception far > more than technical arguments. I think you might benefit from the same > practice. > > I understand your arguments, it is just that they are not relevant to > my decision making process as the server diety. I don't expect the robots to ever be valid on continuum. I was expecting something more along the lines of a "hockey" server, a "chaos" server, a "bronco" server, and a "robot challenge" server. I may run the "robot challenge" server myself. If people want to play against robots, they know what they are getting into. If they want to stick to human players, continuum is around to suit their needs. :-) It isn't that I don't understand. It's that I assumed that the 'bots would never be allowed on continuum. I wouldn't even want to have this policy be changed. > I'm looking forward to seeing your robots. You can clearly type quite > fast and with a low defect rate, and that is a useful skill for a coder. If it takes too long to write down in a text file, it may get forgotten. :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From doosh at inl.org Wed Dec 12 10:17:45 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011212041113.A18767@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 12, 2001 at 04:11:13AM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> Message-ID: <20011212081745.B57105@inl.org> On Wed, Dec 12, 2001 at 04:11:13AM -0500, Mark Mielke wrote: > On Tue, Dec 11, 2001 at 10:13:49PM -0800, Tom Holub wrote: > > On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > > Tom thinks it isn't possible, or that it won't be effective. > > Wrong. I think you're an idiot. It is certainly possible to create a > > netrek robot that could beat the best human team. It's a very difficult > > problem, and not one anyone's going to solve by concentrating on tactical > > improvements. (It's not one you personally are going to solve by any > > methods). > > Tactical improvements are the butter between the bread. > > If the robot can't fight, it can't get a kill. If it can't get a kill, > it can't take a planet. The robot code written in 1986 is good enough to get kills. -Tom From mark at mark.mielke.cc Wed Dec 12 13:04:47 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:56 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011212081745.B57105@inl.org>; from doosh@inl.org on Wed, Dec 12, 2001 at 08:17:45AM -0800 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> Message-ID: <20011212140447.A20583@mark.mielke.cc> On Wed, Dec 12, 2001 at 08:17:45AM -0800, Tom Holub wrote: > On Wed, Dec 12, 2001 at 04:11:13AM -0500, Mark Mielke wrote: > > On Tue, Dec 11, 2001 at 10:13:49PM -0800, Tom Holub wrote: > > > On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > > > Tom thinks it isn't possible, or that it won't be effective. > > > Wrong. I think you're an idiot. It is certainly possible to create a > > > netrek robot that could beat the best human team. It's a very difficult > > > problem, and not one anyone's going to solve by concentrating on tactical > > > improvements. (It's not one you personally are going to solve by any > > > methods). > > Tactical improvements are the butter between the bread. > > If the robot can't fight, it can't get a kill. If it can't get a kill, > > it can't take a planet. > The robot code written in 1986 is good enough to get kills. It is my understanding that this code cheats. Ever since they added the ability for a robot to run out of fuel, the robots have sucked quite a bit more. Things like robots having access to "straight" torpedoes, that don't wobble, I definately consider to be cheating. You suggest that the Netrek problem space is complex. I can't argue with this, as I agree. This doesn't mean that you focus on strategy, and neglect combat. The entire problem space must be analyzed. As an example, if the robots do not do an extremely good job under low fuel conditions, including such things as *not* running, how will they ever deal with LPS against the other team? Some might suggest that it is not necessary, as INL games have a timer. As long as more planets are held for the period of time, they win. The thing is -- I don't particularly care about the INL component. Beating good humans just means that the thing is working. They are guinea pigs more than anything. If it can't beat them, it hasn't reached its full potential. The true intrigue is in the methods, and in the consistency. Will the 'bot team function well under all circumstances? All circumstances definately includes combat. A team that can dog-fight incredibly well, but is not as capable in the strategy department, still have an excellent chance of winning against a team that cannot dog-fight very well, but are quite profficient in terms of strategy. It's the whole analogy of a boxer getting into fight with a martial arts expert. Who will win? It is really definately hard to say. From BPaulsen at lehman.com Wed Dec 12 13:10:16 2001 From: BPaulsen at lehman.com (Paulsen, Brian) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots Message-ID: I agree. Getting kills is easy even if you are a lousy dogfighter. Good dogfighting is important for many reasons, but generating kills so that you can take planets is not one of them. Good dogfighting is useful for planet defense and escorting. -----Original Message----- From: Tom Holub [mailto:doosh@inl.org] Sent: Wednesday, December 12, 2001 11:18 AM To: vanilla-list@us.netrek.org Subject: Re: [Vanilla List] organized, intelligent 'bots On Wed, Dec 12, 2001 at 04:11:13AM -0500, Mark Mielke wrote: > On Tue, Dec 11, 2001 at 10:13:49PM -0800, Tom Holub wrote: > > On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > > Tom thinks it isn't possible, or that it won't be effective. > > Wrong. I think you're an idiot. It is certainly possible to create a > > netrek robot that could beat the best human team. It's a very difficult > > problem, and not one anyone's going to solve by concentrating on tactical > > improvements. (It's not one you personally are going to solve by any > > methods). > > Tactical improvements are the butter between the bread. > > If the robot can't fight, it can't get a kill. If it can't get a kill, > it can't take a planet. The robot code written in 1986 is good enough to get kills. -Tom _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. From quozl at us.netrek.org Wed Dec 12 16:20:19 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011212140447.A20583@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 12, 2001 at 02:04:47PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> <20011212140447.A20583@mark.mielke.cc> Message-ID: <20011213092019.J32243@us.netrek.org> On Wed, Dec 12, 2001 at 02:04:47PM -0500, Mark Mielke wrote: > On Wed, Dec 12, 2001 at 08:17:45AM -0800, Tom Holub wrote: > > On Wed, Dec 12, 2001 at 04:11:13AM -0500, Mark Mielke wrote: > > > On Tue, Dec 11, 2001 at 10:13:49PM -0800, Tom Holub wrote: > > > > On Tue, Dec 11, 2001 at 07:33:32PM -0500, Mark Mielke wrote: > > > > > Tom thinks it isn't possible, or that it won't be effective. > > > > Wrong. I think you're an idiot. It is certainly possible to create a > > > > netrek robot that could beat the best human team. It's a very difficult > > > > problem, and not one anyone's going to solve by concentrating on tactical > > > > improvements. (It's not one you personally are going to solve by any > > > > methods). > > > Tactical improvements are the butter between the bread. > > > If the robot can't fight, it can't get a kill. If it can't get a kill, > > > it can't take a planet. > > The robot code written in 1986 is good enough to get kills. > It is my understanding that this code cheats. Have you reviewed the code of both robots shipped in the Vanilla code? I'm beginning to think you've only looked at the server side one, not the client side one. The client side design doesn't use shared memory. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From mark at mark.mielke.cc Wed Dec 12 17:01:59 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011213092019.J32243@us.netrek.org>; from quozl@us.netrek.org on Thu, Dec 13, 2001 at 09:20:19AM +1100 References: <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> <20011212140447.A20583@mark.mielke.cc> <20011213092019.J32243@us.netrek.org> Message-ID: <20011212180159.C20583@mark.mielke.cc> On Thu, Dec 13, 2001 at 09:20:19AM +1100, James Cameron wrote: > On Wed, Dec 12, 2001 at 02:04:47PM -0500, Mark Mielke wrote: > > > > Tactical improvements are the butter between the bread. > > > > If the robot can't fight, it can't get a kill. If it can't get a kill, > > > > it can't take a planet. > > > The robot code written in 1986 is good enough to get kills. > > It is my understanding that this code cheats. > Have you reviewed the code of both robots shipped in the Vanilla code? > I'm beginning to think you've only looked at the server side one, not > the client side one. The client side design doesn't use shared memory. This would be correct. I'll look for the client side one. It hasn't existed since 1986 though, has it? Because I don't remember ever seeing it in any of the code from around 1992... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From mark at mark.mielke.cc Wed Dec 12 17:21:43 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011213092019.J32243@us.netrek.org>; from quozl@us.netrek.org on Thu, Dec 13, 2001 at 09:20:19AM +1100 References: <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> <20011212140447.A20583@mark.mielke.cc> <20011213092019.J32243@us.netrek.org> Message-ID: <20011212182143.D20583@mark.mielke.cc> On Thu, Dec 13, 2001 at 09:20:19AM +1100, James Cameron wrote: > On Wed, Dec 12, 2001 at 02:04:47PM -0500, Mark Mielke wrote: > > > The robot code written in 1986 is good enough to get kills. > > It is my understanding that this code cheats. > Have you reviewed the code of both robots shipped in the Vanilla code? > I'm beginning to think you've only looked at the server side one, not > the client side one. The client side design doesn't use shared memory. They are very cute. :-) Not extremely effective, but definately cute. :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From doosh at inl.org Wed Dec 12 17:52:50 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011212140447.A20583@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 12, 2001 at 02:04:47PM -0500 References: <20011211130811.C65DF172B5@denali.ccs.neu.edu> <000d01c18257$076e0160$3b824b42@san.rr.com> <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> <20011212140447.A20583@mark.mielke.cc> Message-ID: <20011212155250.A2726@inl.org> On Wed, Dec 12, 2001 at 02:04:47PM -0500, Mark Mielke wrote: > On Wed, Dec 12, 2001 at 08:17:45AM -0800, Tom Holub wrote: > > This doesn't mean that you focus on strategy, and neglect combat. The > entire problem space must be analyzed. As an example, if the robots do > not do an extremely good job under low fuel conditions, including such > things as *not* running, how will they ever deal with LPS against the > other team? Why don't you worry about not getting genocided before you worry about how to crack core. > The true intrigue is in the methods, and in the consistency. Will the > 'bot team function well under all circumstances? All circumstances > definately includes combat. A team that can dog-fight incredibly well, > but is not as capable in the strategy department, still have an > excellent chance of winning against a team that cannot dog-fight very > well, but are quite profficient in terms of strategy. No, they won't. > to adapt, the next best thing is to improve the small points. If a > robot can kill 3 good players before dying, instead of 2, this may be > the difference for 3 robots trying to take a planet with 6 defenders > between succeeding and failing. If only 3 robots are necessary, even with > 6 defenders, this allows 5 other robots to be doing other, more useful, > things. Not if you haven't taught them what is useful or not. > You know... I suspect you may be believing that I am suggesting I am > some sort of expert in Netrek. I'm not. Gee, thanks for that clarification. > dog-fighting, nor is it strategic movement of troops. My profession is > in design, innovation, and implementation of software. Rather than > sitting out and telling me how twinky I am, you could be very useful > as a technical advisor, if you didn't have the time, or inclination to > take part in the actual coding. How about this--I could advise you to not worry about stupid shit like trying to improve phaserlocking, because it won't improve the game play of your robots in any noticable way. And you can ignore me. See, I'm already your technical advisor. > team. However, it is just possible that I can design the necessary > infrastructure to do so. With a little input from people such as > yourself, the chance of success improves dramatically. Not if you refuse to listen. -Tom From quozl at us.netrek.org Wed Dec 12 17:41:40 2001 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011212182143.D20583@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Dec 12, 2001 at 06:21:43PM -0500 References: <20011211124153.A15573@mark.mielke.cc> <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> <20011212140447.A20583@mark.mielke.cc> <20011213092019.J32243@us.netrek.org> <20011212182143.D20583@mark.mielke.cc> Message-ID: <20011213104140.L32243@us.netrek.org> On Wed, Dec 12, 2001 at 06:21:43PM -0500, Mark Mielke wrote: > On Thu, Dec 13, 2001 at 09:20:19AM +1100, James Cameron wrote: > > On Wed, Dec 12, 2001 at 02:04:47PM -0500, Mark Mielke wrote: > > > > The robot code written in 1986 is good enough to get kills. > > > It is my understanding that this code cheats. > > Have you reviewed the code of both robots shipped in the Vanilla code? > > I'm beginning to think you've only looked at the server side one, not > > the client side one. The client side design doesn't use shared memory. > They are very cute. :-) Not extremely effective, but definately cute. :-) Well, if you can get something better going by 7th Jan we'll use it on our outback computer games night. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From mark at mark.mielke.cc Wed Dec 12 20:04:01 2001 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots In-Reply-To: <20011213104140.L32243@us.netrek.org>; from quozl@us.netrek.org on Thu, Dec 13, 2001 at 10:41:40AM +1100 References: <20011211162527.A176784@cecum.vec.wfubmc.edu> <014301c18294$f95bd3c0$0200a8c0@lehman.com> <20011211193332.A16802@mark.mielke.cc> <20011211221349.A20260@inl.org> <20011212041113.A18767@mark.mielke.cc> <20011212081745.B57105@inl.org> <20011212140447.A20583@mark.mielke.cc> <20011213092019.J32243@us.netrek.org> <20011212182143.D20583@mark.mielke.cc> <20011213104140.L32243@us.netrek.org> Message-ID: <20011212210401.G20583@mark.mielke.cc> On Thu, Dec 13, 2001 at 10:41:40AM +1100, James Cameron wrote: > On Wed, Dec 12, 2001 at 06:21:43PM -0500, Mark Mielke wrote: > > On Thu, Dec 13, 2001 at 09:20:19AM +1100, James Cameron wrote: > > > On Wed, Dec 12, 2001 at 02:04:47PM -0500, Mark Mielke wrote: > > > > > The robot code written in 1986 is good enough to get kills. > > > > It is my understanding that this code cheats. > > > Have you reviewed the code of both robots shipped in the Vanilla code? > > > I'm beginning to think you've only looked at the server side one, not > > > the client side one. The client side design doesn't use shared memory. > > They are very cute. :-) Not extremely effective, but definately cute. :-) > Well, if you can get something better going by 7th Jan we'll use it on > our outback computer games night. I will try. The "not extremely effective" comment was not intended to be a slight. They are missing the same component that I found missing many years ago in my own 'bots. They analyze the situation to determine what they should do, but they do not analyze the situation to determine exactly what they should do out of several options, nor do they learn from experience. Also, they are not very well organized, causing such things as three robots to speed to a planet with 5 armies on it, all to cloak and zoom in to bomb that one little army. They are reasonably good dog-fighters. Problem is, I can go to a planet with fuel, beam down some armies, and 4 or 5 of them will all cloak and speed towards me. I just have to scatter a few torpedoes to find them, and often exploding one will explode all 3. :-) This is the kind of thing I want to squash in the bots I intend to write. They shouldn't make the same mistakes 10X in a row. Anyways, 'twill be fun. What is 'outback' computer games night? Everybody moves their computers outside so they can watch the smoke in the sky from the forest fires while they play? :-) mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From Hotdeals at operamail.com Wed Dec 12 21:55:39 2001 From: Hotdeals at operamail.com (Hotdeals@operamail.com) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] Christmas Shopping Message-ID: <200112130353.fBD3rcb00420@esus.mc.mpls.visi.com> An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011212/25fc1ae5/attachment.htm From ddamout1 at san.rr.com Wed Dec 12 21:59:05 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] the rules of netrek References: Message-ID: <001701c1838a$844626c0$3b824b42@san.rr.com> From: "Trent Piepho" ] the rules of netrek > On Tue, 11 Dec 2001, Daniel Damouth wrote: > > > > same game the humans are playing? I.e. use INL rules. Not only is it a > > > > more interesting challenge, but it also would make human vs. bot games > > > > meaningful. > > > > > > No 'rules' have been changed. 'Rules' will be exploited. > > > > If no rules have been changed, then my client should be able to tell other > > clients everything it is seeing, and vice-versa. Why do you think that > > feature is not allowed in any blessed clients? (Because it's a rule). > > That is just stupid. It's like saying playing in the same room is cheating > because you can talk to each other, and you can't speak to other players with > normal clients. The difference is, speaking to each other in the room has never been illegal, but clients directly exchanging information has always been. But my primary problem with it isn't because it's against the rules, per se, but because robots competing against humans using machinelike advantages is just not as interesting as robots using intelligence and strategy. I've made it as clear as I can, and I'm dropping it unless I hear a new argument :) Dan From ddamout1 at san.rr.com Wed Dec 12 22:03:58 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] the rules of netrek References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> <20011211084043.A50365@inl.org> Message-ID: <001801c1838b$30c51640$3b824b42@san.rr.com> From: "Tom Holub" > On Mon, Dec 10, 2001 at 11:51:58PM -0800, Daniel Damouth wrote: > > > > Most commercial human-vs.-computer strategy games take the some approach, > > which can be described as "the only way to challenge the human player is to > > play under different rules". For example, in Civilization, the computer has > > to cheat extensively to challenge the human player at higher difficulty > > levels. Nobody really likes the fact that the computer has to cheat. > > "Cheating" by having one brain controlling 8 ships on the same team is > a lot different than cheating by having all the other races in the game > gang up on you, or by changing the resource allocation rules. I think > it's the wrong focus for the project and I don't think it will provide > useful returns, but I don't think it's philisophically a big problem. I don't care if one robot is controlling the others through the message board, like a human captain directing a team. They can use any organizational structures they want, just as a human team can. And they will still have a huge speed advantage in communicating. But if the robots get to communicate cloaker positions and all the other tactical information through direct client-to-client sockets, then they aren't playing with the same rules as a human team with blessed clients. That's all. Dan Damouth From doosh at inl.org Wed Dec 12 23:32:13 2001 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] the rules of netrek In-Reply-To: <001801c1838b$30c51640$3b824b42@san.rr.com>; from ddamout1@san.rr.com on Wed, Dec 12, 2001 at 08:03:58PM -0800 References: <20011209225212.A7043@mark.mielke.cc> <000701c18140$7aefa3e0$3b824b42@san.rr.com> <029e01c181a5$3123c7e0$0200a8c0@lehman.com> <002e01c181f9$b2bc28c0$3b824b42@san.rr.com> <20011211003714.D12345@mark.mielke.cc> <004001c18218$b6221f00$3b824b42@san.rr.com> <20011211084043.A50365@inl.org> <001801c1838b$30c51640$3b824b42@san.rr.com> Message-ID: <20011212213213.A26870@inl.org> On Wed, Dec 12, 2001 at 08:03:58PM -0800, Daniel Damouth wrote: > > But if the robots get to communicate cloaker positions and all the other > tactical information through direct client-to-client sockets, then they > aren't playing with the same rules as a human team with blessed clients. > That's all. They're not playing with the same rules, anyway. For example, humans can only display cloaker position on the galactic map; robots can see them just as well as they see any other ship. Some things are fundamentally different--you can't really hold robots to the same standard. -Tom From ddamout1 at san.rr.com Thu Dec 13 00:38:13 2001 From: ddamout1 at san.rr.com (Daniel Damouth) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <000301c1824c$716ed9a0$0200a8c0@hermes> <20011211124453.B15573@mark.mielke.cc> <004601c18280$7e597060$0200a8c0@lehman.com> Message-ID: <006301c183a0$bd78c860$3b824b42@san.rr.com> From: "Brian Paulsen" > Ok, I'm taking a little offense here... > > Are you building your bot from scratch, or are you using somebody else's > code as a starting point? The reason I ask is that I haven't seen that many > bots that "just plain suck" I've seen many bots (mine included) that play > quite well and have given INL teams a struggle. Is this really true? When were these games played? I'm sure I would have been interested in playing, but I have no recollection of them in my 8 years. My understanding was the robots we've seen can be better than humans at dogfighting, but nothing else, and suck at actually winning games. Dan Damouth From brian at thePaulsens.com Thu Dec 13 13:44:07 2001 From: brian at thePaulsens.com (Brian Paulsen) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] organized, intelligent 'bots References: <000301c1824c$716ed9a0$0200a8c0@hermes> <20011211124453.B15573@mark.mielke.cc> <004601c18280$7e597060$0200a8c0@lehman.com> <006301c183a0$bd78c860$3b824b42@san.rr.com> Message-ID: <028401c1840e$9c7c87a0$0200a8c0@lehman.com> Most of the games that I've seen and participated in were games against sfop, which was Scott Drellishak's creation. Scott had about 3 tournaments that I was a part of, and we had some of the top players as the opponents. It wasn't an INL team per se, but it was about 8 of the top 20 players at the time. Yes, we genocided sfop on each game, but sometimes it took over an hour to win. When you consider that this squad of players could probably genocide some of the weaker INL teams in a shorter timeframe, I think the sfops put up a good showing. Maybe "gave INL teams a struggle" is a bit of an exaggeration, but by no means did sfop "just plain suck". If Scott had more free time to develop his bot, I wouldn't be surprised at all to see an sfop team winning against anybody you would want to throw at it. By the way these games were played in the Spring of 1992. Brian ----- Original Message ----- From: "Daniel Damouth" To: Sent: Thursday, December 13, 2001 1:38 AM Subject: Re: [Vanilla List] organized, intelligent 'bots > From: "Brian Paulsen" > > > > Ok, I'm taking a little offense here... > > > > Are you building your bot from scratch, or are you using somebody else's > > code as a starting point? The reason I ask is that I haven't seen that > many > > bots that "just plain suck" I've seen many bots (mine included) that play > > quite well and have given INL teams a struggle. > > Is this really true? When were these games played? I'm sure I would have > been interested in playing, but I have no recollection of them in my 8 > years. > > My understanding was the robots we've seen can be better than humans at > dogfighting, but nothing else, and suck at actually winning games. > > Dan Damouth > > > _______________________________________________ > vanilla-list mailing list > vanilla-list@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-list > From Storybag at aol.com Fri Dec 14 13:58:39 2001 From: Storybag at aol.com (Storybag@aol.com) Date: Wed Jan 12 00:52:57 2005 Subject: [Vanilla List] are you selling Message-ID: <17d.baa96b.294bb3ef@aol.com> I would like to find out about buying the the vanilla patch.Are they being sold in USA? Linda Spitzer Just for the Tell of It http://www.miamistorytellersguild.com/linda_spitzer.htm From banks111111hk at yahoo.com.hk Sat Dec 15 00:53:12 2001 From: banks111111hk at yahoo.com.hk (Paul Mac Arthur (Rapid Internet Marketing Newsletter)) Date: Wed Jan 12 00:52:58 2005 Subject: [Vanilla List] Chase Visa Card, Verisign Thawte Certificate, Rapid Traffic and Eif Services for all the readers. Message-ID: <200112142252.fBEMqnc30702@enchanter.real-time.com> An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011214/827684eb/attachment.html From Heather19f at aol.com Sun Dec 30 20:35:52 2001 From: Heather19f at aol.com (Heather19f@aol.com) Date: Wed Jan 12 00:52:58 2005 Subject: [Vanilla List] hey hey Message-ID: <20011231023552.10801.qmail@vs00.tvsecure.com> Below is the result of your feedback form. It was submitted by (Heather19f@aol.com) on Sunday, December 30, 2001 at 18:35:52 --------------------------------------------------------------------------- message: Hi, my name is Heather and I am a 19 year old female from San Diego, California. Ever since my 14th birthday, I have been really sexually active, but I am still a virgin. Now I am 19 and away from home, attending school at San Diego State University and sharing a dorm with four of my girlfriends and are all VERY turned on to meet a guy and satisfy ALL of his pleasures. To see our sexy pictures we took just last week and to meet some other couples, go to our site
< a href="http://www.lllil.com/heather/livewebcam">http://www.lllil.com/heather/livewebcam

-1811 --------------------------------------------------------------------------- Senders IP address: 141.158.32.239 Submitted Sunday, December 30, 2001 at 18:35:52 PST: /home/httpd/cgi-bin/vs00000/formmail/formmail.pl From return at trafficmagnet.net Fri Dec 21 06:23:21 2001 From: return at trafficmagnet.net (Christine Hall) Date: Wed Jan 12 00:53:34 2005 Subject: [META] METASERVER.US.NETREK.ORG:1080 Message-ID: <200112211225.fBLCPjD01310@ns4.trafficnet.net> An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011221/683629c3/attachment.html From banks111111hk at yahoo.com.hk Mon Dec 24 15:05:29 2001 From: banks111111hk at yahoo.com.hk (Paul Mac Arthur (Rapid Internet Marketing Newsletter)) Date: Wed Jan 12 00:53:34 2005 Subject: [META] AMEX and Chase Visa Card, Verisign Certificate, Rapid Traffic and Eif Services for all the readers.At 20% better conditions Message-ID: <200112241311.fBODBa509388@sprite.real-time.com> An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20011224/bca84ec8/attachment.htm