From jeffno at ccs.neu.edu Thu Jun 1 07:40:31 2006 From: jeffno at ccs.neu.edu (Jeff Nowakowski) Date: Thu, 01 Jun 2006 08:40:31 -0400 Subject: [netrek-dev] Obscure host feature Message-ID: <1149165631.15141.22.camel@localhost.localdomain> Years ago I used to run a hockey server. On that server I had some custom code that would obscure the host of the player. The idea was that security-wise it is not a good idea to list IP addresses to all game players, given that there are often heated arguments and an IP address is a good start for any kind of network attack. However, IP addresses are useful for players to recognise other players (like "player foo always plays from bar.isp"), and also to report problem players to an administrator. So what I did was to "x" out the hostname for a string address, or the last two fields for a numeric address. For example: 127.0.0.1 --> 127.0.x.x foo.bar.com --> x.bar.com I'm offering the patch here, in case somebody thinks it's a good idea and wants to apply it. However, note: This code is years old. Some work will have to be done to apply it, though not much, I think. I don't play netrek any more or run a server, so I have no interest in doing this work myself. I have attached the original main.c from years ago and the patched main.c. I've also included the diff. -Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c Type: text/x-csrc Size: 23862 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060601/4924f502/attachment-0001.c -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c.diff Type: text/x-patch Size: 2844 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060601/4924f502/attachment-0001.bin -------------- next part -------------- /* * main.c */ #include "copyright.h" #include #include #include #include #include #include #include #include #include #include #include #include "defs.h" #include INC_STRINGS #include INC_UNISTD #include INC_SYS_WAIT #include "struct.h" #include "data.h" #include "packets.h" #include "../patchlevel.h" #define SVERS #include "../version.h" #ifdef SENDFLAGS #include "../cflags.h" #endif #include "proto.h" #ifndef TRUE #define TRUE 1 #define FALSE 0 #endif /* file scope prototypes */ static void reaper(int); static void printUsage(char *prog); static void sendMotd(void); static void sendConfigMsg(void); static void printStats(void); static int checkbanned(char *login, char *host); int ignored[MAXPLAYER]; /* change 7/24/91 TC */ int indie = 0; /* always be indie 8/28/91 TC */ int living = 1; /* our ship is living, reset by death */ int main(int argc, char **argv) { int team, s_type, w_queue = 0; int pno; int usage = 0; int err = 0; char *name, *ptr; struct passwd *pwent; int callHost=0; time_t starttime; int i; register struct player *j; /* for traipsing through the playerlist */ extern void forceShutdown (); char pseudo[PSEUDOSIZE]; /* Was a global - MK 9/30/94 */ getpath(); /* added 11/6/92 DRG */ errors = open(Error_File, O_WRONLY | O_APPEND | O_CREAT, 0644); dup2(errors,2); setbuf(stderr, NULL); dup2(errors,1); setbuf(stdout, NULL); name = *argv++; argc--; if ((ptr = RINDEX(name,'/')) != NULL) name = ptr + 1; while (*argv) { if (**argv == '-') ++*argv; else break; argc--; ptr = *argv++; while (*ptr) { switch (*ptr) { case 'u': usage++; break; case 'i': indie++; break; /* 8/28/91 TC */ case 'q': w_queue=atoi(*argv); argv++; argc--; break; case 's': xtrekPort=atoi(*argv); callHost=1; argv++; argc--; break; #ifdef OBSERVERS case 'O': Observer = 1; clueVerified = 1; break; #endif case 'd': host = *argv; argc--; argv++; break; default: ERROR(1,("%s: unknown option '%c'\n", name, *ptr)); err++; break; } ptr++; } } if (usage || err) { printUsage(name); exit(err); } /* accept host name from newstartd */ if (argc > 0) host = argv[0]; srandom((int)getpid() * time((time_t *) 0)); /* avoid having daemon (started by openmem) inherit our socket */ fcntl(0, F_SETFD, FD_CLOEXEC); /* this finds the shared memory information */ openmem(1); readsysdefaults(); #ifdef FEATURE_PACKETS readFeatures(); #endif me = NULL; /* UDP fix (?) */ if (callHost) { if (!connectToClient(host,xtrekPort)) { exit(0); } } else { sock=0; /* newstartd gives us our connection on 0 */ checkSocket(); setNoDelay(sock); initClientData(); /* "normally" called by connectToClient() */ } starttime=time(NULL); while (userVersion==0) { time_t t; /* Waiting for user to send his version number. * We give him thirty seconds to do so... */ if (isClientDead()) { ERROR(2,("ntserv/main.c: disconnect waiting for version packet from %s\n", host)); exit(1); } if (starttime+30 < time(&t)) { ERROR(2,("ntserv/main.c: no version packet received from %s\n", host)); exit(1); } socketPause(starttime+30-t); readFromClient(); } if (!checkVersion()) { ERROR(2,("ntserv/main.c: bad version packet from %s\n", host)); exit(1); } SIGNAL(SIGALRM, SIG_IGN); SIGNAL(SIGTERM, forceShutdown); SIGNAL(SIGPIPE, SIG_IGN); sendMotd(); pno = findslot(w_queue); if (pno < 0) { /* trigger client's "Sorry, but you cannot play xtrek now. Try again later." */ struct badversion_spacket packet; packet.type = SP_BADVERSION; packet.why = 1; sendClientPacket (&packet); flushSockBuf (); ERROR(2,("ntserv/main.c: Quitting: No slot available on queue %d\n",w_queue)); /* print some appropriate message */ exit(1); } me = &players[pno]; me->p_process = getpid (); me->p_timerdelay = defskip; me->p_mapchars[0] = 'X'; me->p_mapchars[1] = shipnos[pno]; me->p_mapchars[2] = '\0'; me->p_whydead=KLOGIN; myship = &me->p_ship; mystats = &me->p_stats; lastm = mctl->mc_current; SIGNAL(SIGINT, SIG_IGN); (void) SIGNAL(SIGCHLD, reaper); /* erase prior slot login identity */ me->p_login[0] = '\0'; /* We set these so we won't bother updating him on the location of the * other players in the galaxy which he is not near. There is no * real harm to doing this, except that he would then get more information * than he deserves. * It is kind of a hack, but should be harmless. */ me->p_x= -100000; me->p_y= -100000; me->p_team=0; updateSelf(FALSE); /* so he gets info on who he is */ /* updateSelf(TRUE) shouldn't be necessary */ updateShips(); updatePlanets(); flushSockBuf(); /* Get login name */ if ((pwent = getpwuid(getuid())) != NULL) STRNCPY(login, pwent->pw_name, NAME_LEN); else STRNCPY(login, "Bozo", NAME_LEN); login[NAME_LEN - 1] = '\0'; strcpy(pseudo, "Guest"); strcpy(me->p_name, pseudo); me->p_team=ALLTEAM; getname(); strcpy(pseudo, me->p_name); ERROR(7,("%s: is %s@%s as %s\n", me->p_mapchars, login, host, pseudo)); keeppeace = (me->p_stats.st_flags / ST_KEEPPEACE) & 1; /* showgalactic = 1 + (me->p_stats.st_flags / ST_GALFREQUENT) & 1;*/ /* Set p_hostile to hostile, so if keeppeace is on, the guy starts off hating everyone (like a good fighter should) */ me->p_hostile = (FED|ROM|KLI|ORI); me->p_war = me->p_hostile; s_type = CRUISER; me->p_planets=0; me->p_genoplanets=0; me->p_armsbomb=0; me->p_genoarmsbomb=0; STRNCPY(me->p_login, login, NAME_LEN); me->p_login[NAME_LEN - 1] = '\0'; { int i; for (i = 0; i < MAXPLAYER; i++) ignored[i] = 0; } #ifdef REVERSED_HOSTNAMES if (strlen(host) >= NAME_LEN) { STRNCPY(me->p_monitor, host + (strlen(host) - NAME_LEN + 1), NAME_LEN); /* The # denotes truncation */ me->p_monitor[0] = '#'; } else #endif STRNCPY(me->p_monitor, host, NAME_LEN); me->p_monitor[NAME_LEN - 1] = '\0'; #ifdef FULL_HOSTNAMES /* assume this is only place p_monitor is set, and mirror accordingly */ /* 4/13/92 TC */ STRNCPY(me->p_full_hostname, host, sizeof(me->p_full_hostname)); me->p_full_hostname[sizeof(me->p_full_hostname) - 1] = '\0'; #endif logEntry(); /* moved down to get login/monitor 2/12/92 TMC */ #ifdef PING /* 0 might just be legit for a local player */ me->p_avrt = -1; me->p_stdv = -1; me->p_pkls_c_s = -1; me->p_pkls_s_c = -1; #endif #ifdef LTD_STATS startTkills = ltd_kills(me, LTD_TOTAL); startTlosses = ltd_deaths(me, LTD_TOTAL); startTarms = ltd_armies_bombed(me, LTD_TOTAL); startTplanets = ltd_planets_taken(me, LTD_TOTAL); startTticks = ltd_ticks(me, LTD_TOTAL); startSBkills = ltd_kills(me, LTD_SB); startSBlosses = ltd_deaths(me, LTD_SB); startSBticks = ltd_ticks(me, LTD_SB); #else startTkills = me->p_stats.st_tkills; startTlosses = me->p_stats.st_tlosses; startTarms = me->p_stats.st_tarmsbomb; startTplanets = me->p_stats.st_tplanets; startTticks = me->p_stats.st_tticks; startSBkills = me->p_stats.st_sbkills; startSBlosses = me->p_stats.st_sblosses; startSBticks = me->p_stats.st_sbticks; #endif /* LTD_STATS */ for (;;) { /* give the player the motd and find out which team he wants */ if (me->p_status != PALIVE) { me->p_x= -100000; me->p_y= -100000; updateSelf(FALSE); /* updateSelf(TRUE) isn't necessary */ updateShips(); teamPick= -1; flushSockBuf(); getEntry(&team, &s_type); repCount=0; /* Make sure he gets an update immediately */ } if (team == -1) { exitGame(); } if(CheckBypass(login,host,Bypass_File)==TRUE) bypassed=1; else bypassed=0; if (indie) team = 4; /* force to independent 8/28/91 TC */ redrawall = 1; for (i = 0; i <= MAX_CP_PACKETS; i++) FD_SET (i, &inputMask); /* Allow all input now */ enter(team, 0, pno, s_type, pseudo); #ifndef DEBUG for (i = 1; i < NSIG; i++) { SIGNAL(i, SIG_IGN); } #endif /* +++ 2.6pl2 kantner at hot.caltech.edu 22-NOV-1994 09:46:00.74 */ /* ** The daemon sends ntserv a SIGTERM after the slot is freed during a ** ghostbust. Without this line the SIGTERM does nothing. The slot is ** marked free, but really isn't. Someone else joins the slot, and a ** copilot is formed. */ SIGNAL(SIGTERM, forceShutdown); /* --- */ SIGNAL(SIGILL, SIG_DFL); /* since illegal instruction is so rare this is an useful one to use to make core files for debugging ie. kill -SIGILL */ #ifdef OBSERVERS if (Observer) { me->p_status = POBSERV; /* put observer in game */ new_warning(UNDEF,"Lock onto a teammate or planet to see the action."); pmessage(me->p_no, MINDIV, addr_mess(me->p_no,MINDIV), "Lock onto a teammate or planet to see the action."); } else #endif me->p_status = PALIVE; /* Put player in game */ me->p_ghostbuster = 0; if (checkbanned(login, host) == TRUE) { FILE *logfile; time_t curtime; pmessage(0, MALL, "GOD->ALL","%s (%s@%s) is banned from the game.", me->p_name, me->p_login, host); new_warning(UNDEF,"You are banned from the game."); me->p_explode=100; me->p_status=PEXPLODE; me->p_whydead=KQUIT; /* make him self destruct */ me->p_whodead=0; logfile=fopen(LogFileName, "a"); if (logfile) { curtime=time(NULL); fprintf(logfile, "Banned and exiting: %s (%s@%s), (%c), %s", me->p_name, me->p_login, host, shipnos[me->p_no], ctime(&curtime) ); fclose(logfile); } } #ifdef VOTING /* reset eject voting to avoid inheriting this slot's last occupant's */ /* escaped fate just in case the last vote comes through after the */ /* old guy quit and the new guy joined -Villalpando req. by Cameron */ for (i = 0, j = &players[i]; i < MAXPLAYER; i++, j++) j->voting[me->p_no] = -1; #endif /* Get input until the player quits or dies */ living++; while (living) input(); } } void exitGame(void) { char addrbuf[20]; if (me != NULL && me->p_team != ALLTEAM) { sprintf(addrbuf, " %c%c->ALL", teamlet[me->p_team], shipnos[me->p_no]); #ifndef FULL_HOSTNAMES /* old-style leaving message 4/13/92 TC */ pmessage2(0, MALL | MLEAVE, addrbuf, me->p_no, "%s %s (%s) leaving the game (%.16s@%.16s)", ranks[me->p_stats.st_rank].name, me->p_name, me->p_mapchars, me->p_login, me->p_monitor); #else /* new-style leaving message 4/13/92 TC */ pmessage2(0, MALL | MLEAVE, addrbuf, me->p_no, "%s %s (%s) leaving game (%.16s@%.32s)", ranks[me->p_stats.st_rank].name, me->p_name, me->p_mapchars, me->p_login, me->p_full_hostname); #endif me->p_stats.st_flags &= ~ST_CYBORG; /* clear this flag 8/27/91 TC */ savestats(); printStats(); } if (me) { if(me->p_process != getpid()){ ERROR(1,( "main/exitGame: process exiting from co-pilot!\n")); ERROR(1,( "%d != pid: %d\n", (int) me->p_process, (int) getpid())); fflush(stderr); exit(0); } freeslot(me); } exit(0); } static void printUsage(char *prog) { char *text = "\ Usage: %s [-u] [-q n] [-i] [-O] [-s n] [-d a]\n\ -u displays program usage\n\ -q n specifies queue number to join\n\ -i player is to be independant\n\ -O player is to be an observer\n\ \n\ Manual Connection\n\ -s n call client on socket number 'n'\n\ -d a call client on machine address 'a'\n"; ERROR(1,(text,prog)); } static void sendMotd(void) { FILE *motd; char buf[100]; /* big enough... */ char motd_file[255]; time_t curtime; struct tm *tmstruct; int hour; #ifdef SENDPATCHLEVEL sprintf(buf, "Welcome to %s, patchlevel %d", serv_version, PATCHLEVEL); sendMotdLine(buf); #endif #ifdef SENDFLAGS sendMotdLine("Compiler option flags used for this server:"); sendMotdLine(cflags); sendMotdLine(" "); #endif time(&curtime); tmstruct = localtime(&curtime); if (!(hour = tmstruct->tm_hour%12)) hour = 12; sprintf(buf,"Connection to server established at %d:%02d%s.", hour, tmstruct->tm_min, tmstruct->tm_hour >= 12 ? "pm" : "am"); if (!time_access()) { strcat(buf, " WE'RE CLOSED. SEE HOURS BELOW."); sendMotdLine(buf); sendMotdLine(" "); } strcpy(motd_file,Motd_Path); if (clue) /* added 2/6/93 NBT */ strcat(motd_file,N_MOTD_CLUE); else strcat(motd_file,Motd); /* the following will read a motd */ if ((motd = fopen(motd_file, "r")) != NULL) { while (fgets(buf, sizeof (buf), motd) != NULL) { buf[strlen(buf)-1] = '\0'; sendMotdLine(buf); } (void) fclose(motd); } if (show_sysdef) sendConfigMsg(); } static void sendConfigMsg(void) { register int i, flag; char buf[100]; /* big enough... */ extern char *shiptypes[]; /* ATM: send current configuration info as well */ sendMotdLine(STATUS_TOKEN); /* indicate start of config info */ if (clue) sendMotdLine("Clue verification enabled"); sprintf(buf, "%-30s: ", "Binary Verification"); switch (binconfirm) { case 0: strcat(buf, "disabled"); break; case 1: strcat(buf, "enabled, RSA only"); break; case 2: strcat(buf, "enabled, RSA and reserved.c"); break; } sendMotdLine(buf); if (tournplayers > 8) sprintf(buf, "%-30s: disabled", "Tournament Mode"); else sprintf(buf, "%-30s: %d players / side","Tournament Mode",tournplayers); sendMotdLine(buf); sprintf(buf, "%-30s: ", "Ships Allowed"); for (i = 0; i < NUM_TYPES; i++) { if (i == ATT) continue; if (shipsallowed[i]) { strcat(buf, shiptypes[i]); strcat(buf, " "); } } sendMotdLine(buf); sprintf(buf, "%-30s: %s", "Tractor/Pressor Beams", weaponsallowed[WP_TRACTOR] ? "enabled" : "disabled"); sendMotdLine(buf); sprintf(buf, "%-30s: %s", "Plasma Torpedoes", weaponsallowed[WP_PLASMA] ? "enabled" : "disabled"); sendMotdLine(buf); if (weaponsallowed[WP_PLASMA]) { sprintf(buf, "%-30s: %d", "Kills Required for Plasma", plkills); sendMotdLine(buf); } #ifdef nodef sprintf(buf, "%-30s: %s", "Scanning Beams", weaponsallowed[WP_SCANNER] ? "enabled" : "disabled"); sendMotdLine(buf); #endif if (shipsallowed[STARBASE]) { sprintf(buf, "%-30s: %s (%d)", "Rank Required for SB", ranks[sbrank].name, sbrank); sendMotdLine(buf); } sprintf(buf, "%-30s: %d", "Planets Required for SB", sbplanets); sendMotdLine(buf); sprintf(buf, "%-30s: ", "Hidden Mode"); switch (hiddenenemy) { case 0: strcat(buf, "inactive"); break; case 1: strcat(buf, "tournament only"); break; case 2: strcat(buf, "active"); break; } sendMotdLine(buf); flag = 0; /* see if non-home worlds are allowable entry points */ for (i = 0; i < MAXPLANETS; i++) { if (startplanets[i] && (i % 10)) { flag = 1; break; } } sprintf(buf, "%-30s: %s", "Multiple Entry Planets", flag ? "yes" : "no"); sendMotdLine(buf); sprintf(buf, "%-30s: %s", "Chaos Mode", chaos ? "enabled" : "disabled"); sendMotdLine(buf); #ifdef TORPCONFIG sprintf(buf, "%-30s: %s", "Vector Torps", vectortorps ? "yes" : "no"); sendMotdLine(buf); #endif sprintf(buf,"%-30s: ", "Hunter Killer"); if (killer) strcat(buf, "Yes"); else strcat(buf, "No"); sendMotdLine(buf); #ifdef CHECKMESG sprintf(buf, "%-30s: ", "Message to GOD Log"); if(loggod) strcat(buf, "Yes"); else strcat(buf, "No"); sendMotdLine(buf); #endif #ifdef SB_TRANSWARP sprintf(buf, "%-30s: ", "SB Transwarp"); if (twarpMode) strcat(buf, "Yes"); else strcat(buf, "No"); sendMotdLine(buf); #else sprintf(buf, "%-30s: No", "SB Transwarp"); sendMotdLine(buf); #endif sprintf(buf, "%-30s: %d", "Surrender Counter", surrenderStart); sendMotdLine(buf); } int CheckBypass(char *login, char *host, char *file) { FILE *bypassfile; char log_buf[64], host_buf[64], line_buf[160]; char *position; int num1; int Hits=0; if ((bypassfile = fopen(file, "r")) == NULL) { ERROR(1,( "No bypass file %s\n", file)); fflush(stderr); return(FALSE); } while(fgets(line_buf, 160, bypassfile) != NULL) { /* Split line up */ if((*line_buf=='#')||(*line_buf=='\n')) continue; if ((position = (char *) RINDEX(line_buf, '@')) == 0) { ERROR(1,( "Bad line in bypass file\n")); fflush(stderr); continue; } num1 = position - line_buf; STRNCPY(log_buf, line_buf, num1); /* copy login name into log_buf */ log_buf[num1] = '\0'; STRNCPY(host_buf, position + 1, 64); /* copy host name into host_buf */ /* Cut off any extra spaces on the host buffer */ position = host_buf; while (!isspace((int) (*position))) position++; *position = '\0'; /* ERROR(1,( "Login: <%s>; host: <%s>\n", login, host)); ERROR(1,(" Checking Bypass <%s> and <%s>.\n",log_buf,host_buf)); */ if (*log_buf=='*') Hits=1; else if (!strcasecmp(login, log_buf)){ Hits=1; } if(Hits==1) { if (*host_buf == '*'){ /* Bypass any host */ Hits++; break; /* break out now. otherwise Hits will get reset to one */ } else if (!strcasecmp(host,host_buf) || /* Bypass subdomains */ (strstr(host,host_buf)!=NULL)) { /* (eg, "*@usc.edu" */ Hits++; break; /* break out now. otherwise Hits will get reset to one */ } } } fclose(bypassfile); if(Hits>=2) { /* ERROR(1,("Bypassing %s@%s\n",login,host)); fflush(stderr); */ return(TRUE); } else{ /* ERROR(1,("NOT Bypassing %s@%s\n",login,host)); */ return(FALSE); } } /*ARGSUSED*/ /* some systems pass the signal when caught */ static void reaper(int sig) { WAIT_TYPE stat=0; static int pid; MZERO( &stat, sizeof(WAIT_TYPE) ); while ((pid = WAIT3(&stat, WNOHANG, 0)) > 0) ; HANDLE_SIG(SIGCHLD,reaper); /* added the below code to catch the reason for a child dying - NBT 9/28/92 */ if (!WIFEXITED(stat)) ERROR(1,("Process # %d signal caught\n",pid)); if (WEXITSTATUS(stat)) ERROR(1,("exited with state %d\n",stat)); if (WIFSIGNALED(stat)) ERROR(1,("exited because of signal\n")); if (WTERMSIG(stat)) ERROR(1,("signal state %d\n",stat)); #ifdef WCOREDUMP if (WCOREDUMP(stat)) ERROR(1,("core image made\n")); #endif if (WIFSTOPPED(stat)) ERROR(1,("stopped\n")); if (WSTOPSIG(stat)) ERROR(1,("stop signal was %d\n",stat)); } static void printStats(void) { FILE *logfile; time_t curtime; logfile=fopen(LogFileName, "a"); if (!logfile) return; curtime=time(NULL); fprintf(logfile, "Leaving: %-16s (%c%c) %3dP %3dA %3dW/%3dL %3dmin %2d\n\t<%s@%s> %s", me->p_name, teamlet[me->p_team], shipnos[me->p_no], #ifdef LTD_STATS ltd_planets_taken(me, LTD_TOTAL) - startTplanets, ltd_armies_bombed(me, LTD_TOTAL) - startTarms, ltd_kills(me, LTD_TOTAL) - startTkills, ltd_deaths(me, LTD_TOTAL) - startTlosses, (ltd_ticks(me, LTD_TOTAL) - startTticks)/600, #else me->p_stats.st_tplanets - startTplanets, me->p_stats.st_tarmsbomb - startTarms, me->p_stats.st_tkills - startTkills, me->p_stats.st_tlosses - startTlosses, (me->p_stats.st_tticks - startTticks)/600, #endif /* LTD_STATS */ numPlanets(me->p_team), me->p_login, #ifndef FULL_HOSTNAMES me->p_monitor, #else me->p_full_hostname, #endif ctime(&curtime)); fclose(logfile); } static int checkbanned(char *login, char *host) { FILE *bannedfile; char log_buf[64], host_buf[64], line_buf[160]; char *position; int num1; int Hits=0; /* Hits==2 means we're banned */ if ((bannedfile = fopen(Banned_File, "r")) == NULL) { ERROR(1,( "No banned file %s\n", Banned_File)); fflush(stderr); return(FALSE); } while(fgets(line_buf, 160, bannedfile) != NULL) { /* Split line up */ if((*line_buf=='#')||(*line_buf=='\n')) continue; if ((position = (char *) RINDEX(line_buf, '@')) == 0) { ERROR(1,( "Bad line in banned file\n")); fflush(stderr); continue; } num1 = position - line_buf; STRNCPY(log_buf, line_buf, num1); /* copy login name into log_buf */ log_buf[num1] = '\0'; STRNCPY(host_buf, position + 1, 64); /* copy host name into host_buf */ /* Cut off any extra spaces on the host buffer */ position = host_buf; while (!isspace(*position)) position++; *position = '\0'; /* ERROR(1,( "Login: <%s>; host: <%s>\n", login, host)); ERROR(1,(" Checking Banned <%s> and <%s>.\n",log_buf,host_buf)); */ if(*log_buf=='*') Hits=1; else if (!strcmp(login, log_buf)) Hits=1; if(Hits==1) { if (*host_buf == '*'){ /* Lock out any host */ Hits++; break; /* break out now. otherwise Hits will get reset to one */ } else if(strstr(host,host_buf)!=NULL){ /* Lock out subdomains (eg, "*@usc .edu" */ Hits++; break; /* break out now. otherwise Hits will get reset to one */ } else if (!strcmp(host, host_buf)){ /* Lock out specific host */ Hits++; break; /* break out now. otherwise Hits will get reset to one */ } } } fclose(bannedfile); if(Hits>=2) return(TRUE); else return(FALSE); } /* ARGSUSED */ void message_flag(struct message *cur, char *address) { /* This is to prevent false sending with SP_S_WARNING */ cur->args[0] = DINVALID; } From netrek at gmail.com Thu Jun 1 09:51:57 2006 From: netrek at gmail.com (Zach) Date: Thu, 1 Jun 2006 14:51:57 +0000 Subject: [netrek-dev] Obscure host feature In-Reply-To: <1149165631.15141.22.camel@localhost.localdomain> References: <1149165631.15141.22.camel@localhost.localdomain> Message-ID: Hey Jeff, I think this patch would be a great addition to Vanilla. Zach From niclas at acc.umu.se Fri Jun 2 18:02:15 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sat, 3 Jun 2006 01:02:15 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: On Mon, 29 May 2006, William Balcerski wrote: > 1) Ship headings to 256 with SP2 > Cons: Can one argue more accurate ship headings gives an unfair > advantage in dogfighting? Yes. It makes old clients obsolete. > 2) Ability to bomb enemy 3rd space planets in your T-mode opponent's > space > Cons: Can't think of any It makes it okay to ruin the game by doing the 3rd space / 3rd race bullshit. > 3) Have server send info on torp and plasma fuses > > Cons: Possible borgish behavior to make torps visibly fuse out as they > reach end of life cycle, perhaps by blinking? Yes, it's borgish. It gives info that no other client has even given that gives very unfair advantages to the players that choose the client with this super feature. > Of course, any clued player will pretty much know when a torp is going > to expire anyways. Only if you saw the torp fired and even then you can't be more sure than a couple of centimeters plus or minus. --Niclas From niclas at acc.umu.se Fri Jun 2 18:04:07 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sat, 3 Jun 2006 01:04:07 +0200 (MEST) Subject: [netrek-dev] DI & Rank In-Reply-To: <20060530224543.GA6808@us.netrek.org> References: <20060530224543.GA6808@us.netrek.org> Message-ID: On Wed, 31 May 2006, James Cameron wrote: > Someone has proposed: > > "... rank be available when stats are four grades below those required > (if not generally, then at least for Admiral). As per the standard > description, if your stats are one below the cutoff, then 2x DI is > required to achieve the higher rank." > > Opinions? I don't think it's a good idea. I think you should leave rank alone or more people will be playing like morons (trying to scum rank) more of the time than we have now. --Niclas From williamb at its.caltech.edu Fri Jun 2 20:02:31 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Fri, 2 Jun 2006 18:02:31 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: > > 1) Ship headings to 256 with SP2 > > Cons: Can one argue more accurate ship headings gives an unfair > > advantage in dogfighting? > > Yes. It makes old clients obsolete. > Well, headings for other ships are sent to 256 positions with long packets already, and your own heading is already sent to 256 positions with short packets. So I guess that means my client (with long packets on) makes all old clients obsolete? Cause you can see all ships to 256 positions (not just your own)? > > 2) Ability to bomb enemy 3rd space planets in your T-mode opponent's > > space > > Cons: Can't think of any > > It makes it okay to ruin the game by doing the 3rd space / 3rd race > bullshit. > Speaking as a 3rd space scummer, this change would not influence my behavior (i.e. make it more acceptable), then again maybe I'm not the person to ask. > > 3) Have server send info on torp and plasma fuses > > > > Cons: Possible borgish behavior to make torps visibly fuse out as they > > reach end of life cycle, perhaps by blinking? > > Yes, it's borgish. It gives info that no other client has even given that > gives very unfair advantages to the players that choose the client with > this super feature. > > > Of course, any clued player will pretty much know when a torp is going > > to expire anyways. > > Only if you saw the torp fired and even then you can't be more sure than a > couple of centimeters plus or minus. > Actually I think the best way might just be to send a one time flag or variable that indicates the torp as "new", at the update the torp is fired,just as is done for phasers I believe. That way the client can know where the torp sound events is generated from, and you don't have the borg issue. Though I should point out, with some work the client could be made to track all torps (by arraying them, and making a best guess as to which torp corresponds to the torp they drew last update, which will usually be accurate as the client is given torp's owner and torp heading), and then the client could keep track of things like torp fuse. Bill From netrek at gmail.com Fri Jun 2 20:33:49 2006 From: netrek at gmail.com (Zach) Date: Sat, 3 Jun 2006 01:33:49 +0000 Subject: [netrek-dev] pmessage? Message-ID: I'm trying to find the function definition of pmessage. I did "grep -R pmessage *" from the top directory (Vanilla) and I found the function prototype in include/proto.h, but I could not find the function definition anywhere! Can a function be used with just a prototype? Also what does it mean if a function argument is "..." ? I thought every function needed a prototype and a definition. Zach From carlos at jpl.nasa.gov Fri Jun 2 20:45:26 2006 From: carlos at jpl.nasa.gov (Carlos Y. Villalpando) Date: Fri, 2 Jun 2006 18:45:26 -0700 Subject: [netrek-dev] pmessage? In-Reply-To: References: Message-ID: <20060603014526.GA3872@carlos-desktop> Quoting Zach : > > I'm trying to find the function definition of pmessage. I did "grep -R > pmessage *" from the top directory (Vanilla) and I found the function > prototype in include/proto.h, View include/proto.h, and right above the prototype, it's documented to be in ntserv/smessage.c > Can a function be used with just a prototype? No, you'll get a linker error. > Also what does it mean if a function argument is "..." ? I thought > every function needed a prototype and a definition. That's the syntax for varargs. When the number of arguments can be variable, there's stack manipulation tools for pulling off the arguments one by one. --Carlos V. From xyzzy at speakeasy.org Fri Jun 2 22:09:30 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Fri, 2 Jun 2006 20:09:30 -0700 (PDT) Subject: [netrek-dev] pmessage? In-Reply-To: <20060603014526.GA3872@carlos-desktop> References: <20060603014526.GA3872@carlos-desktop> Message-ID: On Fri, 2 Jun 2006, Carlos Y. Villalpando wrote: > That's the syntax for varargs. When the number of arguments can be > variable, there's stack manipulation tools for pulling off the > arguments one by one. To be pedantic, that's the syntax for stdargs. For varargs, the syntax is different: void somefunction() va_dcl { va_list ap; /* code */ } From williamb at its.caltech.edu Sat Jun 3 04:31:13 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Sat, 3 Jun 2006 04:31:13 -0500 Subject: [netrek-dev] darcs patch: ATT and invalid ship fixes Message-ID: <200606030931.k539VDI7007485@omen.digital-genesis.com> Sat Jun 3 04:26:50 CDT 2006 williamb at its.caltech.edu * ATT and invalid ship fixes * getentry.c, main.c: allow listing of ATT on features screen, and allow player to select ATT from entry window if ship is defined in sysdef as a valid ship. Also fixes incorrect error message in the case of invalid ship type. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 32299 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060603/5c44c2b4/attachment-0001.bin From netrek at gmail.com Sat Jun 3 05:03:23 2006 From: netrek at gmail.com (Zach) Date: Sat, 3 Jun 2006 10:03:23 +0000 Subject: [netrek-dev] pmessage? In-Reply-To: References: <20060603014526.GA3872@carlos-desktop> Message-ID: Thanks guys I found what I need. Zach From niclas at acc.umu.se Sat Jun 3 09:18:02 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sat, 3 Jun 2006 16:18:02 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: On Fri, 2 Jun 2006, William Balcerski wrote: >>> 1) Ship headings to 256 with SP2 >>> Cons: Can one argue more accurate ship headings gives an unfair >>> advantage in dogfighting? >> >> Yes. It makes old clients obsolete. > > Well, headings for other ships are sent to 256 positions with long packets > already, and your own heading is already sent to 256 positions with short > packets. So I guess that means my client (with long packets on) makes all > old clients obsolete? Cause you can see all ships to 256 positions (not > just your own)? I do the head fake all the time, where you position your ship very close to the next ship position so that you can turn very quickly and the enemy won't know what hit them, or when you move to a next ship position but don't move any further than just to where the ship changes position and then move back to the previous position quickly. This move will be impossible agains someone playing with your client. --Niclas From williamb at its.caltech.edu Sat Jun 3 12:40:36 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Sat, 3 Jun 2006 10:40:36 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: > I do the head fake all the time, where you position your ship very close > to the next ship position so that you can turn very quickly and the enemy > won't know what hit them, or when you move to a next ship position but > don't move any further than just to where the ship changes position and > then move back to the previous position quickly. This move will be > impossible agains someone playing with your client. > > --Niclas To the edge of the 16 or 32 bitmap set position? Your own position displays to 32 positions regardless of packet type, for all modern clients. I find it pretty hard to do what you described in a normal situation with 32 position bitmaps..it's a bit more feasible if you only display your ship to 16 positions. I think any decision must be made in light of what data is currently available to clients, and what clients can do...95%+ of current players can display other ships to 32 pos. if they so choose, maybe this argument was more valid when clients could only display to 16 positions, but I just don't see it anymore. Bill From niclas at acc.umu.se Sat Jun 3 12:56:33 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sat, 3 Jun 2006 19:56:33 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: On Sat, 3 Jun 2006, William Balcerski wrote: >> I do the head fake all the time, where you position your ship very close >> to the next ship position so that you can turn very quickly and the enemy >> won't know what hit them, or when you move to a next ship position but >> don't move any further than just to where the ship changes position and >> then move back to the previous position quickly. This move will be >> impossible agains someone playing with your client. > > To the edge of the 16 or 32 bitmap set position? Your own position > displays to 32 positions regardless of packet type My client only displays 16 positions. > 95%+ of current players can display other ships to 32 pos. Where do you get your statistics? > choose, maybe this argument was more valid when clients could only > display to 16 positions, but I just don't see it anymore. What's the logic behind that reasoning? The difference between 16 and 32 is far less than between 32 and 256 any way you cut it. --Niclas From williamb at its.caltech.edu Sat Jun 3 13:58:49 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Sat, 3 Jun 2006 11:58:49 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: > > 95%+ of current players can display other ships to 32 pos. > > Where do you get your statistics? > Sending pig call to get client information from players, and noting which ones use 32 bitmap sets. > What's the logic behind that reasoning? The difference between 16 and 32 > is far less than between 32 and 256 any way you cut it. > Statistically maybe, but not to the human eye. The difference between 16 and 32 is far more noticeable than between 32 and 256. From niclas at acc.umu.se Sat Jun 3 15:43:06 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sat, 3 Jun 2006 22:43:06 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: On Sat, 3 Jun 2006, William Balcerski wrote: >>> 95%+ of current players can display other ships to 32 pos. >> >> Where do you get your statistics? > > Sending pig call to get client information from players, and noting which > ones use 32 bitmap sets. Care to share your findings? How many players clients have you checked and during what period of time have you done this? It doesn't work on continuum anymore, so where have you done this? >> What's the logic behind that reasoning? The difference between 16 and 32 >> is far less than between 32 and 256 any way you cut it. > > Statistically maybe, but not to the human eye. The difference between 16 > and 32 is far more noticeable than between 32 and 256. You state this like it's a fact, do you think that it's a fact and if so what are your references? I strongly disagree. Between 16 and 32 there's "only" twice as many positions. In the 16 position setup there's four positions in a 90 degree turn, in 32 there's eight. That's a big noticable difference, but with 256 positions there's an amazing 64 positions in a 90 degree turn, so with 256 positions the ship moves virtually seemless, so all the position fake moves are useless. So anyone playing with a client that has 256 ship position is unaffected by the, very difficult, position fake move. One might argue (which you are not) that it's so much prettier with 256 ship positions and that it's okay to have clients with that many ship positions just because it makes the game prettier and therefore draws more people, like when we went from 5 to 10 updates per second (which really screwed with dogfighting and made it a lot easier for poor dogfighters). That's a more legitimate argument, and if that's the way the developers want the game to go it's an easy call to make. --Niclas From williamb at its.caltech.edu Sat Jun 3 18:38:51 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Sat, 3 Jun 2006 16:38:51 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: > Care to share your findings? How many players clients have you checked and > during what period of time have you done this? > > It doesn't work on continuum anymore, so where have you done this? Sending 5 spaces to all board still works to get client info from all players. Right off the bat, 75% of players use Netrek XP or Netrek XP Mod, which has 32 pos bitmaps. Current COW and Paradise users also have 32 pos bitmaps. Current game on continuum: 12 Netrek XP or XP Mod 3 Netrek XP 2006 1 Netrek 1999 3 Paradise 2000rc5 1 Paradise/Tedturner 1.3.1 1 COW 2.02 2 COW 2.10 32 view pixmaps were put in COW as of 3.00, so those 3 players don't have em, But if they used the latest version of their client, they would as well. Same for the 1 Tedturner user (the lastest version of Paradise has em). The other 19 users have the 32 pixmap sets. > I strongly disagree. Between 16 and 32 there's "only" twice as many > positions. In the 16 position setup there's four positions in a 90 degree > turn, in 32 there's eight. That's a big noticable difference, but with 256 > positions there's an amazing 64 positions in a 90 degree turn, so with 256 > positions the ship moves virtually seemless, so all the position fake > moves are useless. So anyone playing with a client that has 256 ship > position is unaffected by the, very difficult, position fake move. In a dogfight you can't turn to the degree, maybe if you are a borg but no one is that good ;P. I've played with the client in both 32 position mode and 256 position mode, I really don't notice the difference in combat. It's more noticeable during orbiting, or when you are going at high warp. > One might argue (which you are not) that it's so much prettier with 256 > ship positions and that it's okay to have clients with that many ship > positions just because it makes the game prettier and therefore draws more > people, like when we went from 5 to 10 updates per second (which really > screwed with dogfighting and made it a lot easier for poor dogfighters). > That's a more legitimate argument, and if that's the way the developers > want the game to go it's an easy call to make. > Thought about using that argument but it didn't address the concern you brought up. But yes that's the way I'd like to go, I want to make the client look better, that includes smoother ship turning, higher resolution bitmaps, larger tactical window, etc. From niclas at acc.umu.se Sat Jun 3 19:03:05 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sun, 4 Jun 2006 02:03:05 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: On Sat, 3 Jun 2006, William Balcerski wrote: >> Care to share your findings? How many players clients have you checked and >> during what period of time have you done this? >> >> It doesn't work on continuum anymore, so where have you done this? > > Sending 5 spaces to all board still works to get client info from all > players. Right off the bat, 75% of players use Netrek XP or Netrek XP > Mod, which has 32 pos bitmaps. Current COW and Paradise users also have > 32 pos bitmaps. > > Current game on continuum: Okay, I was just interested in where you got those numbers. You made it sound like you were stating a fact, but what you were really stating was your estimation. Sure, a vast majority of players today use a client with 32 ship pos for enemy ships. I don't think it's the "95%+" you're advocating (and with the "statistics" taken from one single game on continuum you've shown that it's actually less than that numer), but the exact percentage isn't very important. Still, going from 32 positions to 256 is huge any way you look at it (and that's a fact). > It's more noticeable during orbiting, or when you are going at high warp. Yeah, in hockey it's huge. --Niclas From ahn at orion.netrek.org Sat Jun 3 20:36:20 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Sat, 3 Jun 2006 21:36:20 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: <20060604013620.GA13787@orion.netrek.org> On Sun, Jun 04, 2006 at 02:03:05AM +0200, Niclas Fredriksson wrote: > > Sure, a vast majority of players today use a client with 32 ship pos for > enemy ships. I don't think it's the "95%+" you're advocating (and with > the "statistics" taken from one single game on continuum you've shown > that it's actually less than that numer), but the exact percentage isn't > very important. Still, going from 32 positions to 256 is huge any way you > look at it (and that's a fact). > > > It's more noticeable during orbiting, or when you are going at high warp. > > Yeah, in hockey it's huge. I remember when the "then-new" clients added 32 ship position support, and there was an outcry of dismay about how borgish it was. The same was true of the 10 updates per second change. But neither of those changes resulted in clued players losing their edge or newbies becoming clued. Yes, you can make the argument that going from 16->32->256 is a huge change that may eliminate some ambiguity about ship heading (and all the "advantages" associated with exploiting that ambiguity), but the bottom line is that, overall, such a change probably wouldn't make any difference for most players. The reality is that old, unmaintained clients like COW 2.x, BRMH (is BRM even compatible anymore?), Paradise, TedTurner, etc. are falling by the wayside. While I don't like the idea of making such clients obsolete, it's probably better for Netrek's future to focus development efforts on just one or a few that are being actively maintained. Frankly, I find the continued "forking" of the COW derivative clients to be unfortunate, as all those enhancements and bug fixes in SWINE/Netrek 1999/2000/XP/XP Mod/XP 2006 should really be directly in COW. There should be just "one" netrek client, perhaps with different "skins" to support the look and feel of other clients. But this is the nature of open source, and it's better to have a fork with continued development than no development at all. Others may disagree with my opinion about consolidation. Anyway, perhaps a reasonable compromise is to sysdef and feature packet the 256 position ship support. That way, the choice to disable this feature is available for INL, hockey and other servers as appropriate. From quozl at us.netrek.org Sat Jun 3 20:53:43 2006 From: quozl at us.netrek.org (James Cameron) Date: Sun, 4 Jun 2006 11:53:43 +1000 Subject: [netrek-dev] pmessage? In-Reply-To: References: <20060603014526.GA3872@carlos-desktop> Message-ID: <20060604015343.GA4671@us.netrek.org> Zach, Also look at the cgvg package on Debian. Usage: % cg pmessage Shows you references to pmessage in the code, assuming you are in the source tree. Then use vg and one of the match numbers to start vi on the match you want. % vg 25 If you're an emacs fan, ctags or etags will be installed, and they are useful for exploring definitions using M-. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From niclas at acc.umu.se Sat Jun 3 21:02:07 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sun, 4 Jun 2006 04:02:07 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060604013620.GA13787@orion.netrek.org> References: <20060604013620.GA13787@orion.netrek.org> Message-ID: On Sat, 3 Jun 2006, Dave Ahn wrote: > I remember when the "then-new" clients added 32 ship position support, > and there was an outcry of dismay about how borgish it was. The same > was true of the 10 updates per second change. But neither of those > changes resulted in clued players losing their edge or newbies becoming > clued. I'm not talking about clued players losing their edge or newbies becoming clued, but it's a fact that the change from 5 to 10 UPS made the gap between great and poor dogfighters a lot smaller. --Niclas From quozl at us.netrek.org Sat Jun 3 21:14:15 2006 From: quozl at us.netrek.org (James Cameron) Date: Sun, 4 Jun 2006 12:14:15 +1000 Subject: [netrek-dev] Clue Development Message-ID: <20060604021415.GB4671@us.netrek.org> Karthik and I discussed the state of Netrek generally last night. The major demotivator we have for clue at the moment is the lack of new clue, or lack of development interest among the newbies. Clue is defined as the ability to play as a team contributor during a game. Clue is what makes Netrek really fun. Clue play with clue because it's fun. Clue avoid playing with newbies because of the let-down. Newbies are appearing regularly, presumably through random surfing. But few are developing into clue. Those that show signs of enjoying play with clue are prime targets for development. So we need to make more clue from newbies. We can code all we like, but unless we can get this to happen, Netrek will be less fun. The methods we used in the past for developing clue were university computer labs, corporate teams (Digital, Sun), the INL, and the Draft League. I'll add that Stephen and I have been doing a yearly clue development in the form of a time slot or two in an IT oriented kids holiday camp, but without an INL or Draft to feed these guys into, the effort isn't returning as much as I'd hope. These development methods reinforced the behaviours necessary for team play. The basic stats model doesn't reinforce this, although it has some usefulness. So there's lots of things we can do to improve the situation. For the moment, what I'm thinking is: 1. every service provided to the netrek community should have two gatekeepers, so that the service can continue despite someone dropping out, ... if a service only has one gatekeeper then it should be said to be degraded and in need of fixing, like a RAID set with a dead disk, 2. newbies need to be rewarded for team play somehow, to encourage them to develop toward clue, the stats model we have rewards the wrong things, 3. clue need to be told when other clue are present (metaserver, RSS feeds, e-mail notifications, cell phone text messages, whatever it takes), 4. the meta-node clue, the ones who persist with helping the newbies, need to be supported by the rest of the clue. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060604/fe1a59da/attachment.pgp From ahn at orion.netrek.org Sat Jun 3 22:14:43 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Sat, 3 Jun 2006 23:14:43 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060604013620.GA13787@orion.netrek.org> Message-ID: <20060604031443.GA13906@orion.netrek.org> On Sun, Jun 04, 2006 at 04:02:07AM +0200, Niclas Fredriksson wrote: > > I'm not talking about clued players losing their edge or newbies becoming > clued, but it's a fact that the change from 5 to 10 UPS made the gap > between great and poor dogfighters a lot smaller. 10 UPS gives everyone more information to use regardless of whether the player is a great or poor dogfighter. It is "easier" to dodge torps at 10 UPS because a player can see it coming more clearly than at 5 UPS. The "gap" between a great and poor dogfighter stayed the same (a guy who can't react fast enough at 5 UPS also can't react at 10 UPS), but the 10 UPS allows those players with the potential to be better dogfighters to get there more "easily." Frankly, I think this is mostly a good thing, because killing weak dogfighters repeatedly isn't that much fun, and the most interesting aspect of Netrek isn't dogfighting but rather teamwork and team strategy, neither of which are affected by 10 UPS, 256 ship positions, or other technical details. From niclas at acc.umu.se Sat Jun 3 22:24:51 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sun, 4 Jun 2006 05:24:51 +0200 (MEST) Subject: [netrek-dev] Clue Development In-Reply-To: <20060604021415.GB4671@us.netrek.org> References: <20060604021415.GB4671@us.netrek.org> Message-ID: On Sun, 4 Jun 2006, James Cameron wrote: > 2. newbies need to be rewarded for team play somehow, to encourage them > to develop toward clue, the stats model we have rewards the wrong > things, The reward has always been winning. > 3. clue need to be told when other clue are present (metaserver, RSS > feeds, e-mail notifications, cell phone text messages, whatever it > takes), That would be really cool. All hockey players (who want to) should get cell phone text messages whenever there's t-mode (non t-mode scummed) on the hockey server. It would be more difficult to get the bronco clue alert thing going. You'd have to define who's clue and who's not, or maybe have everyone make a list of players they like to play with and whenever n or more of those people are on a server, they get a text message. But then there's the difficulty of what it should trigger on. Logins? They change all the time. Character names? Some old clues (like arizzi) mostly play as guest. And then there's the cost. Who should be paying for a text message service? The text message service is easy to build, but there's not a single one out there that doesn't cost money. But still, it's a cool idea. --Niclas From ahn at orion.netrek.org Sat Jun 3 23:00:24 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Sun, 4 Jun 2006 00:00:24 -0400 Subject: [netrek-dev] Clue Development In-Reply-To: <20060604021415.GB4671@us.netrek.org> References: <20060604021415.GB4671@us.netrek.org> Message-ID: <20060604040024.GB13906@orion.netrek.org> On Sun, Jun 04, 2006 at 12:14:15PM +1000, James Cameron wrote: > > The major demotivator we have for clue at the moment is the lack of new > clue, or lack of development interest among the newbies. I think this has been discussed several times over the last decade and more, and the conclusion has pretty much always been the same: newbies don't have the patience to learn a sophisticated game that has a 1980's look when there is an abundance of competition from modern games; and, clues don't have the patience, interest or time to tolerate the inevitably irritating behavior of newbies. > 1. every service provided to the netrek community should have two > gatekeepers, so that the service can continue despite someone dropping > out, ... if a service only has one gatekeeper then it should be said to > be degraded and in need of fixing, like a RAID set with a dead disk, I've personally had a hard time getting sufficient volunteers to support the Netrek community infrastructure. Those who are active in the community tend to prefer to stay low key or simply are uninterested in pooling resources, so what remains are a few people with little time charged with maintaining too many services. I don't see this changing anytime soon. > 2. newbies need to be rewarded for team play somehow, to encourage them > to develop toward clue, the stats model we have rewards the wrong > things, Cluefulness has never been about statistics, so I don't think a change in the model would have any impact. > 3. clue need to be told when other clue are present (metaserver, RSS > feeds, e-mail notifications, cell phone text messages, whatever it > takes), This is not that hard to implement, but do you think it actually would help? Back in the final days before my retirement, my problem was always the lack of time, not the lack of other clues on the servers. I used to organize MNN, Monday Night Netrek, which was successful for a while, so perhaps something regularly scheduled like that would help to bring clue together. Are there even any of us crusty old geezers left on this list? I might even break down and install a Netrek client if I knew that my old INL and WNL buddies were online. Ah, those were the days... From netrek at gmail.com Sat Jun 3 23:35:46 2006 From: netrek at gmail.com (Zach) Date: Sun, 4 Jun 2006 00:35:46 -0400 Subject: [netrek-dev] pmessage? In-Reply-To: <20060604015343.GA4671@us.netrek.org> References: <20060603014526.GA3872@carlos-desktop> <20060604015343.GA4671@us.netrek.org> Message-ID: On 6/3/06, James Cameron wrote: > Zach, > > Also look at the cgvg package on Debian. > Usage: > > % cg pmessage Cool thanks for the tip. Zach From netrek at gmail.com Sat Jun 3 23:41:08 2006 From: netrek at gmail.com (Zach) Date: Sun, 4 Jun 2006 00:41:08 -0400 Subject: [netrek-dev] Clue Development In-Reply-To: <20060604021415.GB4671@us.netrek.org> References: <20060604021415.GB4671@us.netrek.org> Message-ID: I'd like to propose we find a way to make clue games happen again. We haven't had a single clue pickup game in over a year! That's really sad. I think we could even sustain a draft league if people are motivated and pro-active about organizing/captaining teams. I think we could at the very least shoot for 1 clue pickup game a month to start off. Maybe allow server mod to announce clue pickup games. Newbies will then ask "What are clue games?" etc... Zach From netrek at gmail.com Sat Jun 3 23:46:14 2006 From: netrek at gmail.com (Zach) Date: Sun, 4 Jun 2006 00:46:14 -0400 Subject: [netrek-dev] Clue Development In-Reply-To: <20060604040024.GB13906@orion.netrek.org> References: <20060604021415.GB4671@us.netrek.org> <20060604040024.GB13906@orion.netrek.org> Message-ID: On 6/4/06, Dave Ahn wrote: > > Are there even any of us crusty old geezers left on this list? I might > even break down and install a Netrek client if I knew that my old INL > and WNL buddies were online. Ah, those were the days... I date back to '94 but that's nothing using the Holub time metric ;-) Yeah I also really miss the old days. Playing with friends IN PERSON was the best. It was also best way to get immediate feedback/help/instruction/communication. Regarding the game interface I think you're right and netrek is no longer cutting edge and it was never eye or ear candy so we have to promote the strengths which are team play, strategic/tactical challenges, fairly low overhead on network utilization, etc... Zach From darius at dons.net.au Sun Jun 4 01:33:40 2006 From: darius at dons.net.au (Daniel O'Connor) Date: Sun, 4 Jun 2006 16:03:40 +0930 Subject: [netrek-dev] Clue Development In-Reply-To: <20060604040024.GB13906@orion.netrek.org> References: <20060604021415.GB4671@us.netrek.org> <20060604040024.GB13906@orion.netrek.org> Message-ID: <200606041603.49042.darius@dons.net.au> On Sunday 04 June 2006 13:30, Dave Ahn wrote: > I think this has been discussed several times over the last decade and > more, and the conclusion has pretty much always been the same: newbies > don't have the patience to learn a sophisticated game that has a 1980's > look when there is an abundance of competition from modern games; and, > clues don't have the patience, interest or time to tolerate the > inevitably irritating behavior of newbies. I have seen exactly this pattern in most non-trivial but popular games, eg Team Fortress, Tribes, etc.. It tends to devolve into a state where the clue pool diminishes through attrition and is not replaced fast enough by newbies because of the scary old people who don't tolerate people who haven't played for the last 5 years solid. As a newbie it's not much fun getting repeatedly thrashed by people that are so far above you in skill you can only kill them one time in 10. One benefit netrek has is that it IS cheap in both cost and hardware requirements compared to, say, Battlefield 2 (which is at least as complicated strategy wise) :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060604/b4d828a5/attachment.pgp From niclas at acc.umu.se Sun Jun 4 07:52:54 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sun, 4 Jun 2006 14:52:54 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060604031443.GA13906@orion.netrek.org> References: <20060604013620.GA13787@orion.netrek.org> <20060604031443.GA13906@orion.netrek.org> Message-ID: On Sat, 3 Jun 2006, Dave Ahn wrote: > On Sun, Jun 04, 2006 at 04:02:07AM +0200, Niclas Fredriksson wrote: >> >> I'm not talking about clued players losing their edge or newbies becoming >> clued, but it's a fact that the change from 5 to 10 UPS made the gap >> between great and poor dogfighters a lot smaller. > > 10 UPS gives everyone more information to use regardless of whether the > player is a great or poor dogfighter. It is "easier" to dodge torps at > 10 UPS because a player can see it coming more clearly than at 5 UPS. Yes. > The "gap" between a great and poor dogfighter stayed the same (a guy who > can't react fast enough at 5 UPS also can't react at 10 UPS) No. The good dogfighters needed less time to find a hole to dodge through a cloud of torps at 5 UPS. At 10 UPS the good dogfighters could still dodge as well but the poor dogfighters got huge help and started to dodge much better. --Niclas From jimmyhua73 at yahoo.com Sun Jun 4 10:59:32 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 08:59:32 -0700 (PDT) Subject: [netrek-dev] Clue Development In-Reply-To: <20060604021415.GB4671@us.netrek.org> Message-ID: <20060604155932.46480.qmail@web35312.mail.mud.yahoo.com> I'm not going to debate how clue becomes clue. But there is no question, the more new players there are, the more clue will rise from it. Bottom line is we need a bigger new player base. Continuum seems to be the only game in town. The wait queue on there is big. All other servers are either empty or don't have enough people for anykind of meaningful game. There's almost enough to support a second server. Maybe we should have a newbie-like second server for the leftover players (play against the robots). I've been working on the robots, and the newbie server. It's more configurable than it ever was. Hopefully someone with good internet access could start another one up, hopefully not in India. The current newbie setup, players are forced to join whatever random team Merlin chooses. As netrek is a very social game, I think humans should be allowed to join the majority human team (or whatever team they want), and have a general humans vs. bots game. Since newbie robots are programmed to ignore everyone and do their thing, I think it's important that team play be developed by allowing the humans to "gang up" on the robots. Then, we can make the robots alot tougher ;-P. Anyways, who agrees or disagrees or has some form of opinion about my opinion? I've got the code that will make Merlin work the way I want it to. I'm just wondering if the majority of other developers see it my way or not. Otherwise, Merlin as is... is quite bug free :-). And, it's obvious someone programmed him this way so the humans will be spread evenly or almost evenly amongst the robots. Jimmy --- James Cameron wrote: > Karthik and I discussed the state of Netrek > generally last night. > > The major demotivator we have for clue at the moment > is the lack of new > clue, or lack of development interest among the > newbies. > > Clue is defined as the ability to play as a team > contributor during a > game. Clue is what makes Netrek really fun. Clue > play with clue > because it's fun. Clue avoid playing with newbies > because of the > let-down. > > Newbies are appearing regularly, presumably through > random surfing. But > few are developing into clue. Those that show signs > of enjoying play > with clue are prime targets for development. > > So we need to make more clue from newbies. We can > code all we like, but > unless we can get this to happen, Netrek will be > less fun. > > The methods we used in the past for developing clue > were university > computer labs, corporate teams (Digital, Sun), the > INL, and the Draft > League. > > I'll add that Stephen and I have been doing a yearly > clue development in > the form of a time slot or two in an IT oriented > kids holiday camp, but > without an INL or Draft to feed these guys into, the > effort isn't > returning as much as I'd hope. > > These development methods reinforced the behaviours > necessary for team > play. The basic stats model doesn't reinforce this, > although it has > some usefulness. > > So there's lots of things we can do to improve the > situation. > > For the moment, what I'm thinking is: > > 1. every service provided to the netrek community > should have two > gatekeepers, so that the service can continue > despite someone dropping > out, ... if a service only has one gatekeeper then > it should be said to > be degraded and in need of fixing, like a RAID set > with a dead disk, > > 2. newbies need to be rewarded for team play > somehow, to encourage them > to develop toward clue, the stats model we have > rewards the wrong > things, > > 3. clue need to be told when other clue are present > (metaserver, RSS > feeds, e-mail notifications, cell phone text > messages, whatever it > takes), > > 4. the meta-node clue, the ones who persist with > helping the newbies, > need to be supported by the rest of the clue. > > -- > James Cameron mailto:quozl at us.netrek.org > http://quozl.netrek.org/ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From jimmyhua73 at yahoo.com Sun Jun 4 11:29:56 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 09:29:56 -0700 (PDT) Subject: [netrek-dev] More minor Administrativa printf on robotd/ Message-ID: <20060604162956.13423.qmail@web35309.mail.mud.yahoo.com> Hello, I went through all the printfs, mprintfs, and mfprintfs, in robotd, and asked myself the question. Is this an error message I'd like to see in the /var/ERRORS file? If the answer was yes, mprintfs and mfprintfs were converted to printfs and fprintfs(stderr,"");... If the answer was no, printfs and fprintfs were converted toe mprintf and mfprintf.... Anyways, here's the patch for this. It reduces the size, of generated file /var/ERRORS, and the errors it does produce, I'd be interested in, as those point to SIGSEV's that got caught, but a bandaid was put around them. Of course there are still more "bugs" in robotd, but most seem to be behavioral issues. Like, robots love to keep trying to refit to something else. What's worse is if their homeplanet is taken over, they go into this loop and eventually blow-up on their homeplanet. I will figure out what is causing this one of these days. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: robotd-printf.dpatch Type: application/octet-stream Size: 3593 bytes Desc: 3606011302-robotd-printf.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060604/75fb4e77/attachment.obj From netrek at gmail.com Sun Jun 4 11:46:06 2006 From: netrek at gmail.com (Zach) Date: Sun, 4 Jun 2006 16:46:06 +0000 Subject: [netrek-dev] Clue Development In-Reply-To: <20060604155932.46480.qmail@web35312.mail.mud.yahoo.com> References: <20060604021415.GB4671@us.netrek.org> <20060604155932.46480.qmail@web35312.mail.mud.yahoo.com> Message-ID: It defies logic but for years now I've witnessed players absolutely refusing to start up another game on pickled or somewhere else even when continuum has 6, 8 even 11 players on queue! It's foolish but that's reallity. I think the only way to solve this is to make change to Vanilla to force people onto another server when they enter the queue so that way they will still be on the queue if they want but if they see there is enough people for t-mode on pickled for example they'll likely stay with enough encouragement. It could even print a message like "Continuum is full, entering wait queue. Meanwhile taking you to Pickled - Remember you just need 4x4 for t-mode." Something like that. Zach On 6/4/06, Jimmy Huang wrote: > I'm not going to debate how clue becomes clue. > > But there is no question, the more new players there > are, the more clue will rise from it. > > Bottom line is we need a bigger new player base. > Continuum seems to be the only game in town. The wait > queue on there is big. All other servers are either > empty or don't have enough people for anykind of > meaningful game. > > There's almost enough to support a second server. > Maybe we should have a newbie-like second server for > the leftover players (play against the robots). > > I've been working on the robots, and the newbie > server. It's more configurable than it ever was. > Hopefully someone with good internet access could > start another one up, hopefully not in India. > > The current newbie setup, players are forced to join > whatever random team Merlin chooses. As netrek is a > very social game, I think humans should be allowed to > join the majority human team (or whatever team they > want), and have a general humans vs. bots game. > > Since newbie robots are programmed to ignore everyone > and do their thing, I think it's important that team > play be developed by allowing the humans to "gang up" > on the robots. Then, we can make the robots alot > tougher ;-P. > > Anyways, who agrees or disagrees or has some form of > opinion about my opinion? I've got the code that will > make Merlin work the way I want it to. I'm just > wondering if the majority of other developers see it > my way or not. Otherwise, Merlin as is... is quite > bug free :-). And, it's obvious someone programmed > him this way so the humans will be spread evenly or > almost evenly amongst the robots. > > Jimmy > > > --- James Cameron wrote: > > > Karthik and I discussed the state of Netrek > > generally last night. > > > > The major demotivator we have for clue at the moment > > is the lack of new > > clue, or lack of development interest among the > > newbies. > > > > Clue is defined as the ability to play as a team > > contributor during a > > game. Clue is what makes Netrek really fun. Clue > > play with clue > > because it's fun. Clue avoid playing with newbies > > because of the > > let-down. > > > > Newbies are appearing regularly, presumably through > > random surfing. But > > few are developing into clue. Those that show signs > > of enjoying play > > with clue are prime targets for development. > > > > So we need to make more clue from newbies. We can > > code all we like, but > > unless we can get this to happen, Netrek will be > > less fun. > > > > The methods we used in the past for developing clue > > were university > > computer labs, corporate teams (Digital, Sun), the > > INL, and the Draft > > League. > > > > I'll add that Stephen and I have been doing a yearly > > clue development in > > the form of a time slot or two in an IT oriented > > kids holiday camp, but > > without an INL or Draft to feed these guys into, the > > effort isn't > > returning as much as I'd hope. > > > > These development methods reinforced the behaviours > > necessary for team > > play. The basic stats model doesn't reinforce this, > > although it has > > some usefulness. > > > > So there's lots of things we can do to improve the > > situation. > > > > For the moment, what I'm thinking is: > > > > 1. every service provided to the netrek community > > should have two > > gatekeepers, so that the service can continue > > despite someone dropping > > out, ... if a service only has one gatekeeper then > > it should be said to > > be degraded and in need of fixing, like a RAID set > > with a dead disk, > > > > 2. newbies need to be rewarded for team play > > somehow, to encourage them > > to develop toward clue, the stats model we have > > rewards the wrong > > things, > > > > 3. clue need to be told when other clue are present > > (metaserver, RSS > > feeds, e-mail notifications, cell phone text > > messages, whatever it > > takes), > > > > 4. the meta-node clue, the ones who persist with > > helping the newbies, > > need to be supported by the rest of the clue. > > > > -- > > James Cameron mailto:quozl at us.netrek.org > > http://quozl.netrek.org/ > > > _______________________________________________ > > netrek-dev mailing list > > netrek-dev at us.netrek.org > > > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From jimmyhua73 at yahoo.com Sun Jun 4 11:47:18 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 09:47:18 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. Message-ID: <20060604164718.78973.qmail@web35308.mail.mud.yahoo.com> This doesn't help make the robots any smarter per se, but it does give the new player more to do in a newbie server. Not only taking makes a big difference now, but defending planets or ogging carriers will also now make a difference. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: bots-dont-carry.dpatch Type: application/octet-stream Size: 4186 bytes Desc: 235545595-bots-dont-carry.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060604/3ad4ec8c/attachment.obj From niclas at acc.umu.se Sun Jun 4 13:11:31 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sun, 4 Jun 2006 20:11:31 +0200 (MEST) Subject: [netrek-dev] Clue Development In-Reply-To: <20060604155932.46480.qmail@web35312.mail.mud.yahoo.com> References: <20060604155932.46480.qmail@web35312.mail.mud.yahoo.com> Message-ID: On Sun, 4 Jun 2006, Jimmy Huang wrote: > Anyways, who agrees or disagrees or has some form of > opinion about my opinion? A newbie server with smarter robots would be a good thing. Just make sure it's impossible for non-newbies to rank scum there (by for instance resetting everyone's stats every midnight or something like that). --Niclas From ahn at orion.netrek.org Sun Jun 4 13:18:33 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Sun, 4 Jun 2006 14:18:33 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060604013620.GA13787@orion.netrek.org> <20060604031443.GA13906@orion.netrek.org> Message-ID: <20060604181833.GA15012@orion.netrek.org> On Sun, Jun 04, 2006 at 02:52:54PM +0200, Niclas Fredriksson wrote: > > > The "gap" between a great and poor dogfighter stayed the same (a guy who > > can't react fast enough at 5 UPS also can't react at 10 UPS) > > No. The good dogfighters needed less time to find a hole to dodge through > a cloud of torps at 5 UPS. At 10 UPS the good dogfighters could still > dodge as well but the poor dogfighters got huge help and started to dodge > much better. In this context, a good dogfighter needs less information, not less time, to find a hole to dodge through a cloud of torps, because he can estimate the position, speed, and direction of the torps inbetween the updates. Sorry, but 5->10 UPS doesn't somehow make a dogfighter's fingers physically move faster whether he's good or poor. Therefore, a guy who can't react fast enough at 5 UPS also can't react at 10 UPS, so the gap remains the same. Poor dogfighters do get help from the added updates, and those who can react fast enough but do not have the skill to interpolate between updates can potentially dodge better. In other words, the gap becomes easier to cross for those people (but not everyone). I've seen a good number of newbies or semi-clues improve their dodging abilities at 10 UPS, but I've seen just as many, if not more, who did not improve at all. Maybe your observation has been different. We're mostly quibbling over semantics here, and I generally agree that 10 UPS does allow average dogfighters to become slightly better, but I don't consider this change to be as earthshattering as you make it out to be, at least in terms of pickup or league play. From xyzzy at speakeasy.org Sun Jun 4 13:37:18 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Sun, 4 Jun 2006 11:37:18 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. In-Reply-To: <20060604164718.78973.qmail@web35308.mail.mud.yahoo.com> References: <20060604164718.78973.qmail@web35308.mail.mud.yahoo.com> Message-ID: On Sun, 4 Jun 2006, Jimmy Huang wrote: > This doesn't help make the robots any smarter per se, > but it does give the new player more to do in a newbie > server. > > Not only taking makes a big difference now, but > defending planets or ogging carriers will also now > make a difference. I don't think sending the orbit flag to all players is a good idea. From niclas at acc.umu.se Sun Jun 4 14:13:59 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Sun, 4 Jun 2006 21:13:59 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060604181833.GA15012@orion.netrek.org> References: <20060604013620.GA13787@orion.netrek.org> <20060604031443.GA13906@orion.netrek.org> <20060604181833.GA15012@orion.netrek.org> Message-ID: On Sun, 4 Jun 2006, Dave Ahn wrote: > On Sun, Jun 04, 2006 at 02:52:54PM +0200, Niclas Fredriksson wrote: >> >>> The "gap" between a great and poor dogfighter stayed the same (a guy who >>> can't react fast enough at 5 UPS also can't react at 10 UPS) >> >> No. The good dogfighters needed less time to find a hole to dodge through >> a cloud of torps at 5 UPS. At 10 UPS the good dogfighters could still >> dodge as well but the poor dogfighters got huge help and started to dodge >> much better. > > In this context, a good dogfighter needs less information, not less > time, to find a hole to dodge through a cloud of torps, because he can > estimate the position, speed, and direction of the torps inbetween the > updates. In this context, time is information. With more UPS comes more information per time unit. > Sorry, but 5->10 UPS doesn't somehow make a dogfighter's > fingers physically move faster whether he's good or poor. I never claimed that. It gives more information to all players, even those who before the 5->10 change were great dogfighters who had acquired the skill to "read" enemy movements and angles and with the 5->10 change all players could dodge by just waiting to see where the torps were going and then find the hole as opposed to assuming where torps 4-8 would go after watching where torps 1-3 were going. > I've seen a good number of newbies or semi-clues improve their dodging > abilities at 10 UPS, but I've seen just as many, if not more, who did > not improve at all. Maybe your observation has been different. The change in how people were dogfighting was huge. > We're mostly quibbling over semantics here, and I generally agree that > 10 UPS does allow average dogfighters to become slightly better, but I > don't consider this change to be as earthshattering as you make it out > to be, at least in terms of pickup or league play. Well, maybe that's cause you haven't played more than a handful of hours since the 5->10 change. :) --Niclas From jimmyhua73 at yahoo.com Sun Jun 4 17:51:22 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 15:51:22 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. In-Reply-To: Message-ID: <20060604225122.30997.qmail@web35301.mail.mud.yahoo.com> --- Trent Piepho wrote: > On Sun, 4 Jun 2006, Jimmy Huang wrote: > > This doesn't help make the robots any smarter per > se, > > but it does give the new player more to do in a > newbie > > server. > > > > Not only taking makes a big difference now, but > > defending planets or ogging carriers will also now > > make a difference. > > I don't think sending the orbit flag to all players > is a good idea. I asked for people's opinions about that a few days ago, and didn't get much of a response. Ssssoo, I took the path of least resistance ;-P. I changed 1 line of code that I knew would work, vs. trying some #ifdef nodefs in the bot code (the next path of least resistance).... Anyhow, I'll try the #ifdefs and see if they work. Jimmy From netrek at gmail.com Sun Jun 4 18:30:50 2006 From: netrek at gmail.com (Zach) Date: Sun, 4 Jun 2006 23:30:50 +0000 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060604013620.GA13787@orion.netrek.org> <20060604031443.GA13906@orion.netrek.org> <20060604181833.GA15012@orion.netrek.org> Message-ID: It would be interesting to see how top tier dogfighters (karthik, pog) would do playing in a very high latency scenario (say 500ms) and with 1% ploss. I think a different skill set is involved when one plays under such circumstances. I've noticed this myself playing on dialup for years. Your brain might know what SHOULD happen under ideal conditions but due to network factors you must add an additional layer of calculating and over time you learn for example the difference between deaccelerating from maxwarp at 300ms versus 30ms, in particular I've noticed phaser accuracy is very much affected by high latency. Packet loss in the 2 to 3% range adds a whole other layer of complexity as well. Zach From jimmyhua73 at yahoo.com Sun Jun 4 19:33:42 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 17:33:42 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. In-Reply-To: <20060604225122.30997.qmail@web35301.mail.mud.yahoo.com> Message-ID: <20060605003342.79363.qmail@web35310.mail.mud.yahoo.com> Oh tested them out, It looks like Hadley's robots do have code that will track armies well, even without the PFORBIT flag. But you have to uncomment them out. Anyways, it will work. I'm going to wait for quozl's? e-mail before I send a patch so I'll know what kind of patch to send. Jimmy --- Jimmy Huang wrote: > --- Trent Piepho wrote: > > On Sun, 4 Jun 2006, Jimmy Huang wrote: > > > This doesn't help make the robots any smarter > per > > se, > > > but it does give the new player more to do in a > > newbie > > > server. > > > > > > Not only taking makes a big difference now, but > > > defending planets or ogging carriers will also > now > > > make a difference. > > > > I don't think sending the orbit flag to all > players > > is a good idea. > > I asked for people's opinions about that a few days > ago, and didn't get much of a response. > > Ssssoo, I took the path of least resistance ;-P. I > changed 1 line of code that I knew would work, vs. > trying some #ifdef nodefs in the bot code (the next > path of least resistance).... > > Anyhow, I'll try the #ifdefs and see if they work. > > > Jimmy > > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From jimmyhua73 at yahoo.com Sun Jun 4 19:49:33 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 17:49:33 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. In-Reply-To: <20060605003342.79363.qmail@web35310.mail.mud.yahoo.com> Message-ID: <20060605004933.41886.qmail@web35305.mail.mud.yahoo.com> > Oh tested them out, > > It looks like Hadley's robots do have code that will > track armies well, even without the PFORBIT flag. > But > you have to uncomment them out. > > Anyways, it will work. > > I'm going to wait for quozl's? e-mail before I send > a patch so I'll know what kind of patch to send. With the PFORBIT flag the robots can sense you pick even if you are cloaked. For some reason the other one isn't as good. But I'm sure that can be fixed with some tweaking. Jimmy From xyzzy at speakeasy.org Sun Jun 4 21:38:39 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Sun, 4 Jun 2006 19:38:39 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. In-Reply-To: <20060605004933.41886.qmail@web35305.mail.mud.yahoo.com> References: <20060605004933.41886.qmail@web35305.mail.mud.yahoo.com> Message-ID: On Sun, 4 Jun 2006, Jimmy Huang wrote: > > Oh tested them out, > > > > It looks like Hadley's robots do have code that will > > track armies well, even without the PFORBIT flag. > > But > > you have to uncomment them out. > > > > Anyways, it will work. > > > > I'm going to wait for quozl's? e-mail before I send > > a patch so I'll know what kind of patch to send. > > With the PFORBIT flag the robots can sense you pick > even if you are cloaked. For some reason the other one > isn't as good. But I'm sure that can be fixed with > some tweaking. If you are cloaked and outside of visibility radius, then you can't be seen. The only way to figure out if you are picking is to look for players with kills and bases who aren't elsewhere when a known planet's armies go down. From jimmyhua73 at yahoo.com Mon Jun 5 01:32:29 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 4 Jun 2006 23:32:29 -0700 (PDT) Subject: [netrek-dev] robots don't carry logic. In-Reply-To: Message-ID: <20060605063229.67461.qmail@web35315.mail.mud.yahoo.com> --- Trent Piepho wrote: > If you are cloaked and outside of visibility radius, > then you can't be seen. > The only way to figure out if you are picking is to > look for players with > kills and bases who aren't elsewhere when a known > planet's armies go down. Between human players.... If a teammate is bombing the planet, you will know the armies disappeared due to bombing as he will mentioned it on the message board (especially if it was a difficult bomb). Armies magically disappearing from the galactic can only be explained by 3 scenarios (usually) 1. plague (rare) 2. enemy starbase pickup but all your teammates are too far away to detect it. 3. Some player with kills that was recently "close" to the planet picked it up. Good players keep track of 2 and 3 well. So even if they are invisible, by memory we know where they "are/were" The robots need to "witness" a pickup before they will register it. AKA, enemy is going warp 0, on the planet, probably orbiting and not invisible. Witness armies reducing on planet. You could simply cloak on green alert, and beam-up, and uncloak and the robots never catch that you carried. A real player would see this, know that you are carrying, and wonder why did you even bother to cloak so you can be "invisible" for 2 seconds. The key is to keep track of stale information and to track how stale it is. Player with 2 kills went invisible 4 updates ago and planet armies decremented by 1? His last known position close to planet with armies? Most definitely carries.... The robots have so much compute time to figure out the possibilities, that they should be just as galactically aware as a clued observer coaching the team. Jimmy From quozl at us.netrek.org Mon Jun 5 18:58:53 2006 From: quozl at us.netrek.org (James Cameron) Date: Tue, 6 Jun 2006 09:58:53 +1000 Subject: [netrek-dev] More minor Administrativa printf on robotd/ In-Reply-To: <20060604162956.13423.qmail@web35309.mail.mud.yahoo.com> References: <20060604162956.13423.qmail@web35309.mail.mud.yahoo.com> Message-ID: <20060605235853.GD4841@us.netrek.org> G'day Jimmy, Thanks for the patch, but why change from mprintf to printf at all? mprintf has a feature that printf does not have: if(!read_stdin) return; mfprintf has it as well. You are removing this feature. While I don't know of any, there may be scripts out there that depend on the robot not writing anything if the "-b" option is used. Would it be better for the Newbie server mode to start with "-b" option? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From jimmyhua73 at yahoo.com Mon Jun 5 20:10:40 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Mon, 5 Jun 2006 18:10:40 -0700 (PDT) Subject: [netrek-dev] More minor Administrativa printf on robotd/ In-Reply-To: <20060605235853.GD4841@us.netrek.org> Message-ID: <20060606011040.95400.qmail@web35307.mail.mud.yahoo.com> Hi James, Newbie server mode does start with the -b option. And you are right that mprintf/mfprintf is better as it won't generate messages in the logfile when run in newbie mode. However, I noticed ALOT of printfs in the robotd code. So I started to wonder why. The only thing I could figure is, there should be some error messages that end up in the log no matter what, or it could be a simple oversite. I looked in the var/ERRORS file, and found a bunch of messages I am not interested in getting, as they really weren't errors at all. Robots coming in, robots leaving. After looking at the various printfs. I concluded that most of these would only print if the robot is in debug mode. The 2-3 that I changed to a straight printf or fprintf is when a SIGSEV should have occurred, but it was bandaided (not by me). I think the code is fixed, as I've been running the newbie server for hours and hours and hours, and have yet run into these error messages. But it's there in case someone does :-P. Jimmy --- James Cameron wrote: > G'day Jimmy, > > Thanks for the patch, but why change from mprintf to > printf at all? > > mprintf has a feature that printf does not have: > > if(!read_stdin) > return; > > mfprintf has it as well. > > You are removing this feature. > > While I don't know of any, there may be scripts out > there that depend on > the robot not writing anything if the "-b" option is > used. > > Would it be better for the Newbie server mode to > start with "-b" option? > > -- > James Cameron mailto:quozl at us.netrek.org > http://quozl.netrek.org/ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From williamb at its.caltech.edu Mon Jun 5 19:42:48 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Mon, 5 Jun 2006 17:42:48 -0700 (PDT) Subject: [netrek-dev] Need help figuring out strangeness in short packets with whydead info Message-ID: As I mentioned in an earlier posting, whydead information for observers on genocide is not sent correctly, with short packets on. Well, I did some more digging, and found the problem is much more general. With short packets on, for all players, on the first update where player status changes, whydead information is not sent. Only on the 2nd update is this info sent. Now for regular players, this is never a problem, as they get several explosion updates on geno, so on the 2nd explosion frame they get the proper whydead. But observers just go to the quit screen, so they don't get the proper whydead. For a player, on geno he goes from p_alive, then to 10 updates of p_explode, and finally p_outfit, with p_whydead updated on 2nd explosion update. For an observer, on geno he goes from p_alive to p_outfit, with p_whydead being sent on next update. However, at this point the client has already interpretted the death message, and is sending the "killed by something unknown" message to the login screen. The p_outfit is set at the top of the death() function. On player death, an update to client is given with updateClient, and this *should* be sending the right whydead. And it does when long packets are on. I tried my best to figure out what's going on - I thought maybe the information wasn't being sent at all, but it eventually is sent. I thought the packet which sends it might be skipped, but I don't think so. The best conclusion I can some up with, is that since player status and whydead are in 2 different packets with SP, vs. in the same packet with long packets, there is some timing problem. I just can't figure out why. Bill From williamb at its.caltech.edu Mon Jun 5 18:05:47 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Mon, 5 Jun 2006 16:05:47 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: Just a followup to my 95% estimate, current client data on continuum: 12 XP Mod 3 XP 2006 So 100% right now :). It's probably more like 90-95% of users that use XP Mod, XP 2006, or Paradise 2000. > Current game on continuum: > 12 Netrek XP or XP Mod > 3 Netrek XP 2006 > 1 Netrek 1999 > 3 Paradise 2000rc5 > 1 Paradise/Tedturner 1.3.1 > 1 COW 2.02 > 2 COW 2.10 From ahn at orion.netrek.org Mon Jun 5 20:29:03 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Mon, 5 Jun 2006 21:29:03 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: <20060606012903.GA17953@orion.netrek.org> On Mon, Jun 05, 2006 at 04:05:47PM -0700, William Balcerski wrote: > Just a followup to my 95% estimate, current client data on continuum: > 12 XP Mod > 3 XP 2006 > > So 100% right now :). It's probably more like 90-95% of users that use XP > Mod, XP 2006, or Paradise 2000. It would be more useful to look at the server logs for continuum, hockey and other servers over the last year or two. From niclas at acc.umu.se Tue Jun 6 09:56:31 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Tue, 6 Jun 2006 16:56:31 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: Message-ID: On Mon, 5 Jun 2006, William Balcerski wrote: > Just a followup to my 95% estimate, current client data on continuum: The reason why I reacted was that it wasn't an "estimate" the way you presented it. You presented it as a fact[1], and it's really poor debating technique to present your own estimations as known facts. > So 100% right now It was 0% earlier today when I looked. --Niclas [1] "95%+ of current players can display other ships to 32 pos" From williamb at its.caltech.edu Tue Jun 6 15:12:52 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Tue, 6 Jun 2006 15:12:52 -0500 Subject: [netrek-dev] darcs patch: Twarp message fix (and 1 more) Message-ID: <200606062012.k56KCqeU014919@omen.digital-genesis.com> Tue Jun 6 15:06:52 CDT 2006 williamb at its.caltech.edu * Twarp message fix * transwarp.c: Fixes outdated reference to transwarp hours. Tue Jun 6 15:08:21 CDT 2006 williamb at its.caltech.edu * Chaos mode starbase enhancements * orbit.c, transwarp.c: Allows starbases to transwarp to and dock with other bases if chaos mode is activated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 32455 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060606/bb2477ee/attachment-0001.bin From netrek at gmail.com Wed Jun 7 22:31:34 2006 From: netrek at gmail.com (Zach) Date: Wed, 7 Jun 2006 23:31:34 -0400 Subject: [netrek-dev] ban abuse on continuum Message-ID: I call for a moratorium on the use of the new ban feature on continuum. As I feared it is being used capriciously and vindictively without proper warrant just as had happened with the eject feature. There are lots of newbies playing and when they see someone being banned they are just blindly voting along with the ban. Players are banning other players because they don't like them or some silly reason that has nothing to do with an offense that would justify a ban. Certain cliques of players are also banning people just so they can get their friends in from the wait queue. This is totally unacceptable and the server administrators should take swift action to correct this abuse behaviour. I propose the ban be disabled completely or else amend the code so that ban will only pass with a SERVER majority vote instead of just a TEAM majority vote. It's not that often a player is truly acting in a way that deserves a ban. Zach From williamb at its.caltech.edu Thu Jun 8 17:38:34 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Thu, 8 Jun 2006 17:38:34 -0500 Subject: [netrek-dev] darcs patch: Cross-transwarp check Message-ID: <200606082238.k58McYB2007245@omen.digital-genesis.com> Thu Jun 8 17:37:09 CDT 2006 williamb at its.caltech.edu * Cross-transwarp check * transwarp.c: Prevent transwarping to a base that is already in transwarp. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 31858 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060608/98d07d65/attachment-0001.bin From xyzzy at speakeasy.org Thu Jun 8 18:18:11 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Thu, 8 Jun 2006 16:18:11 -0700 (PDT) Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: <200606082238.k58McYB2007245@omen.digital-genesis.com> References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: On Thu, 8 Jun 2006 williamb at its.caltech.edu wrote: > Thu Jun 8 17:37:09 CDT 2006 williamb at its.caltech.edu > * Cross-transwarp check > * transwarp.c: Prevent transwarping to a base that is already in transwarp. Why? With transwarp fling, you can do a multi-level fling with multiple bases each twarping to the one before. From williamb at its.caltech.edu Thu Jun 8 18:46:59 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Thu, 8 Jun 2006 16:46:59 -0700 (PDT) Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: Well, for one I don't think it makes sense to be able to transwarp to a ship that's already in transwarp. Two, something horribly buggy happens. When the two bases twarp to each other, and they finally meet up and dock, they immediately move at warp 60 out of the bounds of the galaxy. Not sure why. That was further reinforcement to my belief that nature did not intend bases to transwarp to each other! Bill On Thu, 8 Jun 2006, Trent Piepho wrote: > On Thu, 8 Jun 2006 williamb at its.caltech.edu wrote: > > Thu Jun 8 17:37:09 CDT 2006 williamb at its.caltech.edu > > * Cross-transwarp check > > * transwarp.c: Prevent transwarping to a base that is already in transwarp. > > Why? With transwarp fling, you can do a multi-level fling with multiple bases > each twarping to the one before. > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > From stephen.thorne at gmail.com Thu Jun 8 21:05:24 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Fri, 9 Jun 2006 12:05:24 +1000 Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: <3e8ca5c80606081905h35beaaddt1ae00c3106a84559@mail.gmail.com> On 6/9/06, William Balcerski wrote: > Well, for one I don't think it makes sense to be able to transwarp to a > ship that's already in transwarp. Two, something horribly buggy happens. > When the two bases twarp to each other, and they finally meet up and dock, > they immediately move at warp 60 out of the bounds of the galaxy. Not > sure why. That was further reinforcement to my belief that nature did not > intend bases to transwarp to each other! Heh. I like the imagery. Patch taken, applied, pushed, etc. I've just moved house so I'm still behind on patches. If there's osmething urgent, tell me. :) -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From xyzzy at speakeasy.org Thu Jun 8 23:39:09 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Thu, 8 Jun 2006 21:39:09 -0700 (PDT) Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: On Thu, 8 Jun 2006, William Balcerski wrote: > Well, for one I don't think it makes sense to be able to transwarp to a > ship that's already in transwarp. Two, something horribly buggy happens. Does this only happen if two bases transwarp to each other? It's probably because they are each trying to move to the docking port. I think if you have 0 who is twarping to 1 who is twarping to 2 and so on it is ok. From williamb at its.caltech.edu Fri Jun 9 00:30:06 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Thu, 8 Jun 2006 22:30:06 -0700 (PDT) Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: > Does this only happen if two bases transwarp to each other? It's probably > because they are each trying to move to the docking port. I think if you > have 0 who is twarping to 1 who is twarping to 2 and so on it is ok. > Right, it happens when 0 warps to 1, while 1 warps to 0. 0 warping to 1, and 1 warping to 2 does not cause the problem. If 0 warps to 1, 1 warps to 2, and 2 warps to 0, it will bug depending on the order of base arrivals. Of course turning off transwarping to transwarping bases avoids this mess. Another horribly buggy thing I've been noticing while playing around with bases and ATTs is that darn warp 15 = cloak thing. Bases seems to twarp at a steady speed of warp 15, so they stay cloaked pretty much the whole time. You can also turn your ATT into permacloak by moving at warp 15. From stephen.thorne at gmail.com Fri Jun 9 00:37:11 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Fri, 9 Jun 2006 15:37:11 +1000 Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: <3e8ca5c80606082237p5d63a15ge2fcccf59efa0eb@mail.gmail.com> On 6/9/06, William Balcerski wrote: > Another horribly buggy thing I've been noticing while playing around with > bases and ATTs is that darn warp 15 = cloak thing. Bases seems to twarp at > a steady speed of warp 15, so they stay cloaked pretty much the whole time. > You can also turn your ATT into permacloak by moving at warp 15. Warp15==Cloak seems to be a fundamental misdesign to me. How much work would be required to remove it using a feature packet? -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From xyzzy at speakeasy.org Fri Jun 9 02:13:53 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Fri, 9 Jun 2006 00:13:53 -0700 (PDT) Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: <3e8ca5c80606082237p5d63a15ge2fcccf59efa0eb@mail.gmail.com> References: <200606082238.k58McYB2007245@omen.digital-genesis.com> <3e8ca5c80606082237p5d63a15ge2fcccf59efa0eb@mail.gmail.com> Message-ID: On Fri, 9 Jun 2006, Stephen Thorne wrote: > On 6/9/06, William Balcerski wrote: > > Another horribly buggy thing I've been noticing while playing around with > > bases and ATTs is that darn warp 15 = cloak thing. Bases seems to twarp at > > a steady speed of warp 15, so they stay cloaked pretty much the whole time. > > You can also turn your ATT into permacloak by moving at warp 15. > > Warp15==Cloak seems to be a fundamental misdesign to me. > > How much work would be required to remove it using a feature packet? Already is a feature packet. From williamb at its.caltech.edu Fri Jun 9 05:39:04 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Fri, 9 Jun 2006 03:39:04 -0700 (PDT) Subject: [netrek-dev] darcs patch: Cross-transwarp check In-Reply-To: References: <200606082238.k58McYB2007245@omen.digital-genesis.com> Message-ID: Maybe the default setting should be OFF for the cloak transwarp feature? Certainly causes a lot of problems, such as with the hockey puck on hockey servers, or base twarping, or unwanted rapid cloak/decloak sound events. Bill From williamb at its.caltech.edu Fri Jun 9 05:54:26 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Fri, 9 Jun 2006 03:54:26 -0700 (PDT) Subject: [netrek-dev] ban abuse on continuum Message-ID: Zach, I disagree with your post. First I think you need to realize that the option can very well be turned off, and configured, by the server admin, thus a request to "disable completely" the "totally unacceptable" ban feature is a request that should be sent to the server god. Granted there are several problems with ban in it's current state, not limited to: 1) Only takes 2 votes to ban, if 2 players constitute majority on team 2) Same IP can register multiple ban votes 3) Banned observers can still send messages (not sure if this is intentional or not) I think in theory it's good to have the ability for the players to have options to remove abusive and/or disruptive players. Of course in practice it doesn't always work out this way, and yes it is and will be abused, just like eject. And with the netrek community being so small, with only 1 server that sees regular T-mode games, the potential for abuse is even higher. On the other hand, letting the players doing the policing rather than having them bother the server gods with their squabbles seems the best solution from an administrative point of view. As for server majority vs team majority, no this isn't a good idea, because why should the other team be forced to deal with your team's problems. From jimmyhua73 at yahoo.com Fri Jun 9 18:48:45 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Fri, 9 Jun 2006 16:48:45 -0700 (PDT) Subject: [netrek-dev] Improved Army Tracking in robotd Message-ID: <20060609234845.46590.qmail@web35303.mail.mud.yahoo.com> Hello, This is still a work in progress, but I thought I'd share out the code, and get some peer review before I send in the final dpatch with documentation. Basically, PFORBIT player flag is no longer being sent by the netrek server. Newbie robots needed this in order to detect people picking up armies to take planets. Robots were not ogging carriers except through the human carries logic. There was some code already in the robot that just needed to be uncommented out to start tracking carriers again. But, it was easily fooled. You can simply cloak and pick. Or be invisible and pick, and the robots would not know you carried. Added some more agressive logic so that robots won't be fooled. BUT, it's not the logic I wanted to put in. My original concept was: Track all planets. If enemy planet count started decreasing, assume the closest or bunch of closest enemies with kills are picking them up. Based on enemy's last known positions. The concept I ended up writing was: Track all invisible/cloaked players, based on last known position. Attach closest planet into their struct. If the closest_planet army count was dropping, assume they are picking up. You can fool the bots by cloaking or going invisible near one planet, and flying other to another one to pick. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: robotd-army-tracking.dpatch Type: application/octet-stream Size: 10184 bytes Desc: 1353718720-robotd-army-tracking.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060609/50b86fc7/attachment.obj From jimmyhua73 at yahoo.com Fri Jun 9 19:02:28 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Fri, 9 Jun 2006 17:02:28 -0700 (PDT) Subject: [netrek-dev] Improved Army Tracking in robotd In-Reply-To: <20060609234845.46590.qmail@web35303.mail.mud.yahoo.com> Message-ID: <20060610000228.67815.qmail@web35311.mail.mud.yahoo.com> --- Jimmy Huang wrote: > You can fool the bots by cloaking or going invisible > near one planet, and flying other to another one to > pick. I guess the good news is that this logic is as good as the programmer who plays netrek. I GET FOOLED ALOT, when other players do this against me too... Of course, with the bots, they gets fooled everytime, but that's another story. Jimmy From jimmyhua73 at yahoo.com Fri Jun 9 19:34:22 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Fri, 9 Jun 2006 17:34:22 -0700 (PDT) Subject: [netrek-dev] Observers can't get in while trek/sysdef NEWBIE=1 Message-ID: <20060610003422.77104.qmail@web35305.mail.mud.yahoo.com> Hi, Here's a bug I found. When you set in sydef NEWBIE=1, and everything else works, I just noticed, that Observers can't get in through port 2593, even if there are alot of slots available. All this time I've been using xsg to monitor robot behavior, but for army tracking, looking at them from their point of view was more advantageous. Anyways, for those who are more familiar with this part of the code, can you fix? Thanks. Jimmy From jimmyhua73 at yahoo.com Mon Jun 12 02:27:20 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Mon, 12 Jun 2006 00:27:20 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch Message-ID: <20060612072720.97343.qmail@web35306.mail.mud.yahoo.com> The original problem was: robots were not tracking enemy players from picking up as the server was no longer sending the PFORBIT, PFBEAMUP, PFBEAMDOWN status flags. My previous patch was to change the server to send at least the PFORBIT flag. As my previous patch was unofficially shot down, here is my solution. Also included are a bunch of improvements as to how the robots track carriers. Also included are a new toggle switch, robdc - robots don't carry. This shorts circuits alot of this logic, Forcing real players to need to ogg the robots, as the robots won't ogg other robots. As this feature is controversial, it is turned off by default. I didn't get alot of comments when I sent the draft patch out. It compiles, and runs for hours and hours and hours. Robots track enemy carriers better. Hoping this patch gets accepted. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: robotd-army-tracking.dpatch Type: application/octet-stream Size: 14486 bytes Desc: 1353718720-robotd-army-tracking.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060612/84d423c0/attachment.obj From xyzzy at speakeasy.org Mon Jun 12 02:59:41 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Mon, 12 Jun 2006 00:59:41 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060612072720.97343.qmail@web35306.mail.mud.yahoo.com> References: <20060612072720.97343.qmail@web35306.mail.mud.yahoo.com> Message-ID: On Mon, 12 Jun 2006, Jimmy Huang wrote: > Also included are a bunch of improvements as to how > the robots track carriers. > > Also included are a new toggle switch, robdc - robots > don't carry. This shorts circuits alot of this logic, > Forcing real players to need to ogg the robots, as the > robots won't ogg other robots. It would be a lot easier if you could use darc's nifty interactive patch selector to make a patch that only does one thing. This is a pretty standard rule for software development. I've even been told to put each patch of a related group of patches into a separate email, to make replying to an individual patch easier. A nice feature of darcs (it's only nice feature, IMHO) is that is makes this very easy to do. If darcs shows you a hunk like this: hunk ./Vanilla/robotd/update_players.c 150 - p->closest_pl = closest_planet(j, &pldist, p->closest_pl); - p->closest_pl_dist = pldist; + p->closest_pl = closest_planet(j, &pldist, p->closest_pl); + p->closest_pl_dist = pldist; } if(j->p_flags & PFBOMB) I'm not even sure what changed. Did you change some tabs to spaces? Add or remove trailing whitespace? It's obviously got nothing to do with your patch, so when darcs asks you if you want to include it, say no. From jimmyhua73 at yahoo.com Mon Jun 12 10:21:59 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Mon, 12 Jun 2006 08:21:59 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: Message-ID: <20060612152159.92881.qmail@web35303.mail.mud.yahoo.com> --- Trent Piepho wrote: > It would be a lot easier if you could use darc's > nifty interactive patch > selector to make a patch that only does one thing. > This is a pretty > standard rule for software development. I've even > been told to put each > patch of a related group of patches into a separate > email, to make replying > to an individual patch easier. I like to grab the latest tree. darcs get. And work off that and make small changes. Unfortunately, stuff just started to pile. > hunk ./Vanilla/robotd/update_players.c 150 > - p->closest_pl = closest_planet(j, &pldist, > p->closest_pl); > - p->closest_pl_dist = pldist; > + p->closest_pl = closest_planet(j, &pldist, > p->closest_pl); > + p->closest_pl_dist = pldist; > } I didn't know what to make of that either! I *think* I converted some tabs into spaces. When I saw that, the indent looked different in my screen, so I included it, as the indent looked good last time I looked at the code. > I'm not even sure what changed. Did you change some > tabs to spaces? Add > or remove trailing whitespace? It's obviously got > nothing to do with your > patch, so when darcs asks you if you want to include > it, say no. Okay, if it looks identical, don't put it in a patch. Jimmy From stephen.thorne at gmail.com Mon Jun 12 18:12:47 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Tue, 13 Jun 2006 09:12:47 +1000 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060612152159.92881.qmail@web35303.mail.mud.yahoo.com> References: <20060612152159.92881.qmail@web35303.mail.mud.yahoo.com> Message-ID: <3e8ca5c80606121612k7525607fl9af7c8615e975155@mail.gmail.com> On 6/13/06, Jimmy Huang wrote: > I didn't know what to make of that either! I *think* I > converted some tabs into spaces. When I saw that, the > indent looked different in my screen, so I included > it, as the indent looked good last time I looked at > the code. Please unrecord and re-record this patch. Name the patch slighty differently, and resubmit. Thanks. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From jimmyhua73 at yahoo.com Tue Jun 13 04:53:14 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Tue, 13 Jun 2006 02:53:14 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <3e8ca5c80606121612k7525607fl9af7c8615e975155@mail.gmail.com> Message-ID: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> --- Stephen Thorne wrote: > Please unrecord and re-record this patch. Name the > patch slighty > differently, and resubmit. Thanks. Done. Removed the non-change. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: robotd-improved-army-tracking.dpatch Type: application/octet-stream Size: 14526 bytes Desc: 439668532-robotd-improved-army-tracking.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060613/25caef05/attachment.obj From stephen.thorne at gmail.com Tue Jun 13 05:32:52 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Tue, 13 Jun 2006 20:32:52 +1000 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> References: <3e8ca5c80606121612k7525607fl9af7c8615e975155@mail.gmail.com> <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> Message-ID: <3e8ca5c80606130332h77570a97q9f805a7661b5d396@mail.gmail.com> On 6/13/06, Jimmy Huang wrote: > --- Stephen Thorne wrote: > > Please unrecord and re-record this patch. Name the > > patch slighty > > differently, and resubmit. Thanks. > > Done. Removed the non-change. Taken. There was still a few more whitespace changes that I'd have liked. (added lines, etc). Try and see if you can minimise these in future. :) -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From xyzzy at speakeasy.org Tue Jun 13 15:15:22 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 13 Jun 2006 13:15:22 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> Message-ID: On Tue, 13 Jun 2006, Jimmy Huang wrote: > --- Stephen Thorne wrote: > > Please unrecord and re-record this patch. Name the > > patch slighty > > differently, and resubmit. Thanks. > > Done. Removed the non-change. How about actually going though the entire patch, and actually thinking about each hunk? When I look at the patch, I do this, why can't you do it too? You have at least three completely different things being done in one patch, and at least half a dozen hunks that are just random changes to unrelated code. p_mapchars isn't a string, it's just two characters with no null termination. You can't print it with %s. From stephen.thorne at gmail.com Tue Jun 13 16:51:37 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Wed, 14 Jun 2006 07:51:37 +1000 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> Message-ID: <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> On 6/14/06, Trent Piepho wrote: > p_mapchars isn't a string, it's just two characters with no null termination. > You can't print it with %s. You can't? A quick grep in the source shows 58 occurances of printing p_mapchars with %s. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From jimmyhua73 at yahoo.com Tue Jun 13 20:01:22 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Tue, 13 Jun 2006 18:01:22 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> Message-ID: <20060614010122.96160.qmail@web35306.mail.mud.yahoo.com> --- Stephen Thorne wrote: > On 6/14/06, Trent Piepho > wrote: > > p_mapchars isn't a string, it's just two > characters with no null termination. > > You can't print it with %s. > > You can't? A quick grep in the source shows 58 > occurances of printing > p_mapchars with %s. Hehehe. It's not that you can't, It's more of a you shouldn't. the gcc compiler is smart enough to figure it out. But if we tried a different c compiler (which may implement char mapchar[2] differently), it may not. If anyone's used the Borland-C compiler. You'd know what I'd mean. You can mix-up references, pointers and references to pointers, and the darned code would still work! It's like black magic. Try the same code with gcc, and it would instantly SIGSEV. I guess there goes Trent's illusion that Hadley's code was divine and saintly :-P. Jimmy From xyzzy at speakeasy.org Tue Jun 13 22:28:33 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 13 Jun 2006 20:28:33 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> Message-ID: On Wed, 14 Jun 2006, Stephen Thorne wrote: > On 6/14/06, Trent Piepho wrote: > > p_mapchars isn't a string, it's just two characters with no null termination. > > You can't print it with %s. > > You can't? A quick grep in the source shows 58 occurances of printing > p_mapchars with %s. All bugs. Look at struct.h: ./struct.h: char p_mapchars[2]; /* Cache for map window image */ From xyzzy at speakeasy.org Tue Jun 13 22:35:30 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 13 Jun 2006 20:35:30 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060614010122.96160.qmail@web35306.mail.mud.yahoo.com> References: <20060614010122.96160.qmail@web35306.mail.mud.yahoo.com> Message-ID: On Tue, 13 Jun 2006, Jimmy Huang wrote: > Hehehe. > > It's not that you can't, It's more of a you shouldn't. No, you are completely wrong. It's not null terminated. It will print p_ship until it gets to a byte that happens to be zero. It has nothing to do with compilers. Try setting the phaser damage to more than 255 and see what happens when you print it p_mapchars with a %s. > If anyone's used the Borland-C compiler. You'd know > what I'd mean. You can mix-up references, pointers and > references to pointers, and the darned code would > still work! It's like black magic. Try the same code > with gcc, and it would instantly SIGSEV. There is no black magic, if you know what you are doing. > I guess there goes Trent's illusion that Hadley's code > was divine and saintly :-P. I've fixed more bugs in Hadley's code that you have. From jimmyhua73 at yahoo.com Tue Jun 13 23:31:32 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Tue, 13 Jun 2006 21:31:32 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: Message-ID: <20060614043132.34957.qmail@web35313.mail.mud.yahoo.com> --- Trent Piepho wrote: > No, you are completely wrong. It's not null > terminated. It will print p_ship > until it gets to a byte that happens to be zero. It > has nothing to do with > compilers. Try setting the phaser damage to more > than 255 and see what > happens when you print it p_mapchars with a %s. It'd probably be easier to set phaser damage to some negative number to test. > There is no black magic, if you know what you are > doing. I guess Hadley didn't know what he was doing when he wrote in the other 48 instances of printf ("%s \n", p_mapchars); > I've fixed more bugs in Hadley's code that you have. Okay that's nice. As I personally don't program, I'm not really interested in fixing bugs. I want Hadley's bots to play better in a pickup style game. I tried this: #include main() { char mapchar[2]; memcpy (mapchar,"ab",2); printf ("%s \n",&mapchar); } As is turns out, Trent is right, and gcc isn't too smart. But, if you stuck a strncpy instead of memcopy. gcc will stick a \0 right at the end, even though there's no way it should have been allowed to do it. Anyways, it's not the end of the world. And now we can fix it everywhere else in the code that it happens. In fact, I don't have a c manual anywhere. I assume the correct way would be: printf ("%c%c \n",mapchar[0],mapchar[1]); Jimmy From darius at dons.net.au Tue Jun 13 23:48:29 2006 From: darius at dons.net.au (Daniel O'Connor) Date: Wed, 14 Jun 2006 14:18:29 +0930 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060614043132.34957.qmail@web35313.mail.mud.yahoo.com> References: <20060614043132.34957.qmail@web35313.mail.mud.yahoo.com> Message-ID: <200606141418.29903.darius@dons.net.au> On Wednesday 14 June 2006 14:01, Jimmy Huang wrote: > As is turns out, Trent is right, and gcc isn't too > smart. This isn't gcc's fault. Your char array isn't a valid string so expecting tools like str* and printf %s to work is foolish. Arguably GCC should warn you about it but it doesn't. > I assume the correct way would be: > > printf ("%c%c \n",mapchar[0],mapchar[1]); Yep. Or printf ("%.2s \n",mapchar); man 3 printf is your friend :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060614/9fd17044/attachment.pgp From stephen.thorne at gmail.com Tue Jun 13 23:52:24 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Wed, 14 Jun 2006 14:52:24 +1000 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> Message-ID: <3e8ca5c80606132152s494cb3f9y6adc370b840556a@mail.gmail.com> On 6/14/06, Trent Piepho wrote: > > You can't? A quick grep in the source shows 58 occurances of printing > > p_mapchars with %s. > > All bugs. Look at struct.h: > ./struct.h: char p_mapchars[2]; /* Cache for map window image */ Excellent. Patches accepted. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From ahn at orion.netrek.org Tue Jun 13 23:52:51 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed, 14 Jun 2006 00:52:51 -0400 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> Message-ID: <20060614045251.GA7406@orion.netrek.org> On Tue, Jun 13, 2006 at 08:28:33PM -0700, Trent Piepho wrote: > On Wed, 14 Jun 2006, Stephen Thorne wrote: > > > On 6/14/06, Trent Piepho wrote: > > > p_mapchars isn't a string, it's just two characters with no null termination. > > > You can't print it with %s. > > > > You can't? A quick grep in the source shows 58 occurances of printing > > p_mapchars with %s. > > All bugs. Look at struct.h: > ./struct.h: char p_mapchars[2]; /* Cache for map window image */ Actually, a grep shows: include/struct.h: char p_mapchars[3]; /* Cache for map window image, i.e. "R0" */ ntserv/main.c: me->p_mapchars[0] = 'X'; ntserv/main.c: me->p_mapchars[1] = shipnos[pno]; ntserv/main.c: me->p_mapchars[2] = '\0'; And the various *printf's are of the form: sprintf(k->p_longname, "%s (%s)", k->p_name, k->p_mapchars); which are quite legitimate and not bugs at all since the p_mapchars is NULL teriminated. The robot code does use a 2 byte local mapchars: inl.c: char mapchars[2]; But uses strncpy to copy the local mapchars to the player struct: inl.c: STRNCPY(winners[k].mapchars, j->p_mapchars, 2); I've not bothered looking through the code any further at the moment, and there may very well be bugs related to improper usage of a non-NULL terminated mapchars, however I'd have to disagree that all 58 occurances of printing p_mapchars with %s are bugs. As for GCC tolerating non-NULL-terminated strings, that's just silly conjecture. The compiled program will print characters until it reaches a NULL or an exception condition at which point a SIGSEGV/SIGILL/etc signal is raised depending on context. It is possible due to sheer luck that buggy *printf code may function correctly as intended because of compiler behavior in zeroing out unused memory segments (very common in debug mode), including the unused structure padding bytes in X-byte aligned architectures. However, the likelihood of such buggy code to go undiscovered for years (like Vanilla) is rather small. From xyzzy at speakeasy.org Wed Jun 14 00:07:55 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 13 Jun 2006 22:07:55 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060614043132.34957.qmail@web35313.mail.mud.yahoo.com> References: <20060614043132.34957.qmail@web35313.mail.mud.yahoo.com> Message-ID: On Tue, 13 Jun 2006, Jimmy Huang wrote: > > doing. > > I guess Hadley didn't know what he was doing when he > wrote in the other 48 instances of printf ("%s \n", > p_mapchars); There aren't 48 other occurances, just 16. There is no version history, so they may not have been written by Hadley, but could have been by a neophyte such as yourself. But they are all bugs, anyone who knows C programming will know exactly what is wrong as soon as they see the definition of p_mapchars. > > I've fixed more bugs in Hadley's code that you have. > > Okay that's nice. As I personally don't program, I'm > not really interested in fixing bugs. I want Hadley's > bots to play better in a pickup style game. You acted as if I had some some belief that Hadley's code could not have bugs. Obviously I'm well aware that it is not perfect if I've been fixing bugs in it. > I tried this: > > #include > > main() > { > char mapchar[2]; > memcpy (mapchar,"ab",2); > printf ("%s \n",&mapchar); > } > > As is turns out, Trent is right, and gcc isn't too > smart. It has nothing to do with the compiler. It is doing exactly what it is supposed to do. > But, if you stuck a strncpy instead of memcopy. gcc > will stick a \0 right at the end, even though there's > no way it should have been allowed to do it. C doesn't do range checking on arrays. If you call strncpy and tell it to overwrite the end of an array, which is what you are doing, then it will. Try compiling this _without_ optimization: main() { int y; char x[2]; y = 0x12345678; strncpy(x, "ab", 3); printf("x = %s y = %x\n", x, y); } > In fact, I don't have a c manual anywhere. There are lots on the web. > > I assume the correct way would be: > > printf ("%c%c \n",mapchar[0],mapchar[1]); It would be better to do what is done in the server code, and just null terminate p_mapchars so that it's less cumbersome to print out. From ahn at orion.netrek.org Wed Jun 14 00:17:36 2006 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed, 14 Jun 2006 01:17:36 -0400 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060614045251.GA7406@orion.netrek.org> References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> <20060614045251.GA7406@orion.netrek.org> Message-ID: <20060614051736.GA7538@orion.netrek.org> On Wed, Jun 14, 2006 at 12:52:51AM -0400, Dave Ahn wrote: > > The robot code does use a 2 byte local mapchars: > inl.c: char mapchars[2]; > > But uses strncpy to copy the local mapchars to the player struct: > inl.c: STRNCPY(winners[k].mapchars, j->p_mapchars, 2); Go figure I'd make a silly mistake. What I meant was that it uses strncpy to copy the local struct's p_mapchars to mapchars. Anyway, my point is that at cursory glance, some care seems to have been taken to ensure that p_mapchars and mapchars are used correctly without overruning the bounds. From xyzzy at speakeasy.org Wed Jun 14 02:17:10 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed, 14 Jun 2006 00:17:10 -0700 (PDT) Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: <20060614045251.GA7406@orion.netrek.org> References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> <20060614045251.GA7406@orion.netrek.org> Message-ID: On Wed, 14 Jun 2006, Dave Ahn wrote: > On Tue, Jun 13, 2006 at 08:28:33PM -0700, Trent Piepho wrote: > > On Wed, 14 Jun 2006, Stephen Thorne wrote: > > > On 6/14/06, Trent Piepho wrote: > > > > p_mapchars isn't a string, it's just two characters with no null termination. > > > > You can't print it with %s. > > > > > > You can't? A quick grep in the source shows 58 occurances of printing > > > p_mapchars with %s. > > > > All bugs. Look at struct.h: > > ./struct.h: char p_mapchars[2]; /* Cache for map window image */ > > Actually, a grep shows: > > include/struct.h: char p_mapchars[3]; /* Cache for map window image, i.e. "R0" */ That's the server, not Hadley's robot. The robot doesn't have null terminated p_mapchars, while the server does (now, didn't used to long ago). Only the 16 occurences of p_mapchars getting printed with %s in Hadley's robot source code are bugs. I guess the 58 number Stephen came up with if for all the Vanilla code, I thought he was just talking about the bot code, as that was what was being discussed. The other robots like the inl bot or puck are completely different code, and use the exact same p_mapchars data as the server, since it's in the shared memory segment. From stephen.thorne at gmail.com Wed Jun 14 03:26:23 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Wed, 14 Jun 2006 18:26:23 +1000 Subject: [netrek-dev] robotd-army-tracking.dpatch In-Reply-To: References: <20060613095314.70775.qmail@web35313.mail.mud.yahoo.com> <3e8ca5c80606131451o4aa9fc60p33d53216f312a262@mail.gmail.com> <20060614045251.GA7406@orion.netrek.org> Message-ID: <3e8ca5c80606140126v8645fd4l8b036e380a2f0f51@mail.gmail.com> On 6/14/06, Trent Piepho wrote: > That's the server, not Hadley's robot. The robot doesn't have null terminated > p_mapchars, while the server does (now, didn't used to long ago). > > Only the 16 occurences of p_mapchars getting printed with %s in Hadley's robot > source code are bugs. I guess the 58 number Stephen came up with if for all > the Vanilla code, I thought he was just talking about the bot code, as that > was what was being discussed. > > The other robots like the inl bot or puck are completely different code, and > use the exact same p_mapchars data as the server, since it's in the shared > memory segment. Yay, thanks for clearing up the confusion Trent, I appreciate it. When someone gets around to fixing this, they can look back at this discussion and see why the problem exists. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From jimmyhua73 at yahoo.com Wed Jun 14 05:01:40 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Wed, 14 Jun 2006 03:01:40 -0700 (PDT) Subject: [netrek-dev] printf("%s \n" p_mapchars); bug Message-ID: <20060614100140.92581.qmail@web35308.mail.mud.yahoo.com> Here's the fix that Trent was alluding to to make mapchars NULL terminated, so we don't have to fix the other pile of incorrect code. Changed 2 lines in 2 files. I think it covers it. If not, let me know as the robot will never crash even if it is wrong, unless we decide to activate the debug mode :) :-P. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: null-terminate-mapchars.dpatch Type: application/octet-stream Size: 3237 bytes Desc: 1301811185-null-terminate-mapchars.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060614/4f3acaba/attachment.obj From stephen.thorne at gmail.com Wed Jun 14 05:28:51 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Wed, 14 Jun 2006 20:28:51 +1000 Subject: [netrek-dev] printf("%s \n" p_mapchars); bug In-Reply-To: <20060614100140.92581.qmail@web35308.mail.mud.yahoo.com> References: <20060614100140.92581.qmail@web35308.mail.mud.yahoo.com> Message-ID: <3e8ca5c80606140328vc289c17l6d83fdd90d612e33@mail.gmail.com> On 6/14/06, Jimmy Huang wrote: > Here's the fix that Trent was alluding to to make > mapchars NULL terminated, so we don't have to fix the > other pile of incorrect code. > > Changed 2 lines in 2 files. I think it covers it. If > not, let me know as the robot will never crash even if > it is wrong, unless we decide to activate the debug > mode :) Whoops. You've managed to use spaces in a file that was using tabs. I've applied a patch over the top to get the spaces right. Are you using a text editor that will allow you to detect the difference? -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From stephen.thorne at gmail.com Wed Jun 14 05:36:37 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Wed, 14 Jun 2006 20:36:37 +1000 Subject: [netrek-dev] darcs patch: ATT and invalid ship fixes In-Reply-To: <200606030931.k539VDI7007485@omen.digital-genesis.com> References: <200606030931.k539VDI7007485@omen.digital-genesis.com> Message-ID: <3e8ca5c80606140336i692965dbyb2afac44c2b03740@mail.gmail.com> On 6/3/06, williamb at its.caltech.edu wrote: > Sat Jun 3 04:26:50 CDT 2006 williamb at its.caltech.edu > * ATT and invalid ship fixes > * getentry.c, main.c: allow listing of ATT on features screen, and allow player to select > ATT from entry window if ship is defined in sysdef as a valid ship. Also fixes incorrect > error message in the case of invalid ship type. Taken, thankyou. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From stephen.thorne at gmail.com Wed Jun 14 05:35:02 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Wed, 14 Jun 2006 20:35:02 +1000 Subject: [netrek-dev] darcs patch: Twarp message fix (and 1 more) In-Reply-To: <200606062012.k56KCqeU014919@omen.digital-genesis.com> References: <200606062012.k56KCqeU014919@omen.digital-genesis.com> Message-ID: <3e8ca5c80606140335i26c50fd6u18915b86f4e2029a@mail.gmail.com> On 6/7/06, williamb at its.caltech.edu wrote: > Tue Jun 6 15:06:52 CDT 2006 williamb at its.caltech.edu > * Twarp message fix > * transwarp.c: Fixes outdated reference to transwarp hours. > > Tue Jun 6 15:08:21 CDT 2006 williamb at its.caltech.edu > * Chaos mode starbase enhancements > * orbit.c, transwarp.c: Allows starbases to transwarp to and dock with other > bases if chaos mode is activated. Patches taken. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From jimmyhua73 at yahoo.com Wed Jun 14 05:53:00 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Wed, 14 Jun 2006 03:53:00 -0700 (PDT) Subject: [netrek-dev] printf("%s \n" p_mapchars); bug In-Reply-To: <3e8ca5c80606140328vc289c17l6d83fdd90d612e33@mail.gmail.com> Message-ID: <20060614105300.41462.qmail@web35314.mail.mud.yahoo.com> --- Stephen Thorne wrote: > Whoops. You've managed to use spaces in a file that > was using tabs. > I've applied a patch over the top to get the spaces > right. Are you > using a text editor that will allow you to detect > the difference? Well, I can detect the difference but not easily see it (move my cursor over, left arrow, right arrow, see if it jumps around etc etc) I've got my emacs setup to convert tabs into spaces where-ever possible. Are you saying you prefer tabs+spaces combo for the proper indent? I prefer just plain spaces, as I found out my xterm windows don't always display the indent properly with the tab+space combo. Anyways, let me know, I can always change my emacs settings. Jimmy From xyzzy at speakeasy.org Wed Jun 14 15:55:02 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed, 14 Jun 2006 13:55:02 -0700 (PDT) Subject: [netrek-dev] printf("%s \n" p_mapchars); bug In-Reply-To: <20060614105300.41462.qmail@web35314.mail.mud.yahoo.com> References: <20060614105300.41462.qmail@web35314.mail.mud.yahoo.com> Message-ID: On Wed, 14 Jun 2006, Jimmy Huang wrote: > > I've got my emacs setup to convert tabs into spaces > where-ever possible. Are you saying you prefer > tabs+spaces combo for the proper indent? tabs+spaces is much more common, and what most of the netrek code uses. From jimmyhua73 at yahoo.com Fri Jun 16 04:29:14 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Fri, 16 Jun 2006 02:29:14 -0700 (PDT) Subject: [netrek-dev] Newbie mode and observer ports Message-ID: <20060616092914.11586.qmail@web35302.mail.mud.yahoo.com> Hello, I figured out the problem. The problem turned out to be that the ports file needed to be configured differently than what it suggests. Anyways, I'll send a darcs patch over to make newbie observers make more sense. Jimmy From jimmyhua73 at yahoo.com Fri Jun 16 04:40:30 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Fri, 16 Jun 2006 02:40:30 -0700 (PDT) Subject: [netrek-dev] change sample_ports Message-ID: <20060616094030.99455.qmail@web35310.mail.mud.yahoo.com> Hi, I thought newbie observers had a bug, but it turns out I was just configuring the ports file incorrectly. I figured this out by reading findslot.c and various other ntserv code. I made some changes in the sample_ports file so people can know how to setup observer ports in a newbie server without having to read through the code. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: newbie-observer-ports.dpatch Type: application/octet-stream Size: 5095 bytes Desc: 3182253097-newbie-observer-ports.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060616/53de3144/attachment.obj From stephen.thorne at gmail.com Sat Jun 17 19:12:10 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Sun, 18 Jun 2006 10:12:10 +1000 Subject: [netrek-dev] change sample_ports In-Reply-To: <20060616094030.99455.qmail@web35310.mail.mud.yahoo.com> References: <20060616094030.99455.qmail@web35310.mail.mud.yahoo.com> Message-ID: <3e8ca5c80606171712j6350c1ax17eb9b66942f0220@mail.gmail.com> On 6/16/06, Jimmy Huang wrote: > I made some changes in the sample_ports file so people > can know how to setup observer ports in a newbie > server without having to read through the code. Taken. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From williamb at its.caltech.edu Mon Jun 19 19:55:00 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Mon, 19 Jun 2006 19:55:00 -0500 Subject: [netrek-dev] darcs patch: xtkill ship change fixes Message-ID: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> Mon Jun 19 19:50:09 CDT 2006 williamb at its.caltech.edu * xtkill ship change fixes * tools/xtkill.c: Adds the ability to set ship to galaxy class, removes unneccessary ship size change for ATT, and updates the list of valid ship types to include the super SC with 1 point torps (this was missing from list of valid ship types). M ./Vanilla/tools/xtkill.c -8 +5 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 32553 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060619/c25ddb0f/attachment-0001.bin From stephen.thorne at gmail.com Mon Jun 19 21:12:48 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Tue, 20 Jun 2006 12:12:48 +1000 Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> Message-ID: <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> On 6/20/06, williamb at its.caltech.edu wrote: > Mon Jun 19 19:50:09 CDT 2006 williamb at its.caltech.edu > * xtkill ship change fixes > * tools/xtkill.c: Adds the ability to set ship to galaxy class, removes unneccessary > ship size change for ATT, and updates the list of valid ship types to include > the super SC with 1 point torps (this was missing from list of valid ship types). > M ./Vanilla/tools/xtkill.c -8 +5 I've pushed this to the 'shiny' repo, but I'd like confirmation from someone else that the shipsize change should be removed before I push it to netrek.org. Why was it there? -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From quozl at us.netrek.org Mon Jun 19 23:39:53 2006 From: quozl at us.netrek.org (James Cameron) Date: Tue, 20 Jun 2006 14:39:53 +1000 Subject: [netrek-dev] Need help figuring out strangeness in short packets with whydead info In-Reply-To: References: Message-ID: <20060620043953.GH10212@us.netrek.org> On Mon, Jun 05, 2006 at 05:42:48PM -0700, William Balcerski wrote: > The best conclusion I can some up with, is that since player status > and whydead are in 2 different packets with SP, vs. in the same packet > with long packets, there is some timing problem. I just can't figure > out why. Are they both being sent in TCP, or a cross between UDP and TCP? UDP packets can overtake the TCP stream. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From williamb at its.caltech.edu Tue Jun 20 03:03:03 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Tue, 20 Jun 2006 01:03:03 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> Message-ID: > I've pushed this to the 'shiny' repo, but I'd like confirmation from > someone else that the shipsize change should be removed before I push > it to netrek.org. Why was it there? > Up until recently, AT size was defined as 28 by 28 for whatever reason (probably because clients didn't come with AT bitmaps, so the mismatch ship size/shield overlay made the CA bitmap function as AT). I changed this in a patch last month called ATT fixes, to 20 by 20, which is normal ship size. Thus, the lines changing ship size to 20 by 20 in xtkill were unnecessary. Bill From xyzzy at speakeasy.org Tue Jun 20 04:02:08 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 20 Jun 2006 02:02:08 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> Message-ID: On Tue, 20 Jun 2006, William Balcerski wrote: > > I've pushed this to the 'shiny' repo, but I'd like confirmation from > > someone else that the shipsize change should be removed before I push > > it to netrek.org. Why was it there? > > > Up until recently, AT size was defined as 28 by 28 for whatever reason > (probably because clients didn't come with AT bitmaps, so the mismatch > ship size/shield overlay made the CA bitmap function as AT). I changed > this in a patch last month called ATT fixes, to 20 by 20, which is normal > ship size. Thus, the lines changing ship size to 20 by 20 in xtkill were > unnecessary. The original ATT bitmap, the one from the paradise client, is larger than a normal ship. From williamb at its.caltech.edu Tue Jun 20 04:44:26 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Tue, 20 Jun 2006 02:44:26 -0700 (PDT) Subject: [netrek-dev] Need help figuring out strangeness in short packets with whydead info In-Reply-To: <20060620043953.GH10212@us.netrek.org> References: <20060620043953.GH10212@us.netrek.org> Message-ID: > Are they both being sent in TCP, or a cross between UDP and TCP? UDP > packets can overtake the TCP stream. > Nice call, turning off UDP on the observer now gives him the proper whydead with short packets on. Now to figure out a fix :). Thanks! Bill From williamb at its.caltech.edu Tue Jun 20 05:50:34 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Tue, 20 Jun 2006 05:50:34 -0500 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf Message-ID: <200606201050.k5KAoY3o002535@omen.digital-genesis.com> Tue Jun 20 05:44:36 CDT 2006 williamb at its.caltech.edu * Adding packet priority to sndSSelf * genspkt.c: Certain SndSSelf packets get marked as critical, as is done with SndSelf, so that information like player whydead is sent as high priority. Fixes problem where players would not get proper whydead on game end, most noticeable for observers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 33644 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060620/58244c25/attachment-0001.bin From xyzzy at speakeasy.org Tue Jun 20 06:30:15 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 20 Jun 2006 04:30:15 -0700 (PDT) Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: <200606201050.k5KAoY3o002535@omen.digital-genesis.com> References: <200606201050.k5KAoY3o002535@omen.digital-genesis.com> Message-ID: On Tue, 20 Jun 2006 williamb at its.caltech.edu wrote: > Tue Jun 20 05:44:36 CDT 2006 williamb at its.caltech.edu > * Adding packet priority to sndSSelf > * genspkt.c: Certain SndSSelf packets get marked as critical, as is done with SndSelf, > so that information like player whydead is sent as high priority. Fixes problem > where players would not get proper whydead on game end, most noticeable for > observers. You have two bugs in this patch. From stephen.thorne at gmail.com Tue Jun 20 07:50:39 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Tue, 20 Jun 2006 22:50:39 +1000 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: References: <200606201050.k5KAoY3o002535@omen.digital-genesis.com> Message-ID: <3e8ca5c80606200550t1202abefr62839e19616f85c0@mail.gmail.com> On 6/20/06, Trent Piepho wrote: > You have two bugs in this patch. You seem to have managed to hit send before finishing your email. I wonder if you could spend a moment and remember what those two bugs are? -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From williamb at its.caltech.edu Tue Jun 20 16:52:24 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Tue, 20 Jun 2006 16:52:24 -0500 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf Message-ID: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> Tue Jun 20 16:48:48 CDT 2006 williamb at its.caltech.edu * Adding packet priority to sndSSelf * genspkt.c: Certain sndSSelf packets get marked as critical, as is done with SndSelf, so that information like player whydead is sent as high priority. Fixes problem where players would not get proper whydead on game end, most noticeable for observers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 33621 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060620/a79d36d6/attachment-0001.bin From netrek at gmail.com Tue Jun 20 18:05:02 2006 From: netrek at gmail.com (Zach) Date: Tue, 20 Jun 2006 19:05:02 -0400 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> Message-ID: On 6/20/06, williamb at its.caltech.edu wrote: > Tue Jun 20 16:48:48 CDT 2006 williamb at its.caltech.edu > * Adding packet priority to sndSSelf > * genspkt.c: Certain sndSSelf packets get marked as critical, as is done with SndSelf, > so that information like player whydead is sent as high priority. Fixes problem > where players would not get proper whydead on game end, most noticeable for > observers. I noticed that when a geno happens I have to start up cilent and login again to re-enter. All the race windows are struck out and won't allow me to rejoin. Not sure if this is client or server issue. Zach From quozl at us.netrek.org Tue Jun 20 18:47:32 2006 From: quozl at us.netrek.org (James Cameron) Date: Wed, 21 Jun 2006 09:47:32 +1000 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> Message-ID: <20060620234732.GA4780@us.netrek.org> On Tue, Jun 20, 2006 at 04:52:24PM -0500, williamb at its.caltech.edu wrote: > Tue Jun 20 16:48:48 CDT 2006 williamb at its.caltech.edu > * Adding packet priority to sndSSelf This patch name is incorrect. It should be "show observers the geno" or some other user-visible description. See the STYLE file. If you have any doubt as to what goes here, imagine you are describing it to non-coding Netrek clue in a message to the ALL board in the game. > * genspkt.c: Certain sndSSelf packets get marked as critical, > as is done with SndSelf, so that information like player > whydead is sent as high priority. Fixes problem where players > would not get proper whydead on game end, most noticeable for > observers. This change log entry did not note the changed function in full. See http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html for standards. We need to be able to find the change later using the change log *or* whatever repository we have at the time. It also doesn't show any results of research or testing ... like is this change tested, did you verify that the packet order was wrong, how was it wrong, did your change fix it, how did it fix it ... > hunk ./Vanilla/ntserv/genspkt.c 1041 > + if (commMode == COMM_UDP) { > + if ( ntohl(youp->flags) != pl->p_flags || > + youp->armies != pl->p_armies || > + youp->swar != pl->p_swar) { > + youp->type=SP_S_YOU | 0x40; /* mark as semi-critical */ > + } > + if ( youp->whydead != pl->p_whydead || > + youp->whodead != pl->p_whodead || > + youp->pnum != pl->p_no) { > + youp->type=SP_S_YOU | 0x80; /* mark as critical */ > + } > + } This segment of code looks similar to the code in sndSelf, but it has differences as well. 1. if the code is meant to do the same thing, add a new static function, such as sp_s_you_criticality() or something, and call that function from both places that do this same thing ... this is called factoring, 2. if the code is not meant to do the same thing, then make it clearer why there are differences. It might also be time to make 0x40 and 0x80 more formally declared. Interesting that it causes server packets to be restricted to 0-63 type codes, wasting bits in the type char. Perhaps some day we should change sendClientPacket to remove this prioritisation overload. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From williamb at its.caltech.edu Tue Jun 20 21:17:35 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Tue, 20 Jun 2006 19:17:35 -0700 (PDT) Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: <20060620234732.GA4780@us.netrek.org> References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> <20060620234732.GA4780@us.netrek.org> Message-ID: > It also doesn't show any results of research or testing ... like is this > change tested, did you verify that the packet order was wrong, how was > it wrong, did your change fix it, how did it fix it ... From quozl at us.netrek.org Wed Jun 21 03:58:32 2006 From: quozl at us.netrek.org (James Cameron) Date: Wed, 21 Jun 2006 18:58:32 +1000 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> <20060620234732.GA4780@us.netrek.org> Message-ID: <20060621085832.GA6561@us.netrek.org> On Tue, Jun 20, 2006 at 07:17:35PM -0700, William Balcerski wrote: > From what I can tell, [...] All useful response, thanks ... but it should be in the patch, since the mailing list is a separate thing to the change log or repository. Just amend your patch. > Yes it is meant to do the same thing, I can factorize it, however there is > one line I am not sure of. In the updateSelf function, the way it > determines whether to use sndSelf or sndSSelf is by the following: > > if(send_short && me->p_fuel < 61000 ) { /* A little margin ... */ Fuel is being sent as a 16-bit unsigned quantity (u_short). It may change between the time it is tested here and the time it is placed in the short packet. It seems reasonable to check it against a margin rather than 65536. It was clear to me, but it may not be clear to everyone. Maybe you should change the comment to be more clear. > I am not sure why it looks at fuel, whereas for other places in the code > it just checks send_short. Because if fuel is too large, short packets are not appropriate. > Regarding the semicritical packets (0x40), I can't figure out how the > sendSC function works either :). Specifically, what line checks to send > the packet only if sequence number is 0x40? Line 750: case SP_YOU|0x40: /* ??? what is this? */ Clearly a hack. ;-0 -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Wed Jun 21 04:15:56 2006 From: quozl at us.netrek.org (James Cameron) Date: Wed, 21 Jun 2006 19:15:56 +1000 Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> Message-ID: <20060621091556.GB6561@us.netrek.org> On Tue, Jun 20, 2006 at 02:02:08AM -0700, Trent Piepho wrote: > The original ATT bitmap, the one from the paradise client, is larger > than a normal ship. So shouldn't this bitmap be placed in the other clients and the server left as it was? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From williamb at its.caltech.edu Wed Jun 21 04:34:30 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Wed, 21 Jun 2006 02:34:30 -0700 (PDT) Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: <20060621085832.GA6561@us.netrek.org> References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> <20060620234732.GA4780@us.netrek.org> <20060621085832.GA6561@us.netrek.org> Message-ID: > Fuel is being sent as a 16-bit unsigned quantity (u_short). It may > change between the time it is tested here and the time it is placed in > the short packet. It seems reasonable to check it against a margin > rather than 65536. > Hmm I guess what I was trying to get at was, if fuel were ever larger than an unsigned int could hold, there would be problems in numerous places, especially client side as they would not be able to accept fuel as a long int. So the margin check would have no impact. > Line 750: > > case SP_YOU|0x40: /* ??? what is this? */ > > Clearly a hack. ;-0 > I wonder whose comment that is? Heh. I think you misunderstood the question though. In that long switch list, lines 746-772, numerous types eventually get sent to sendSC() at line 798. What in the sendSC() function determines which of those types are critical? Bill From williamb at its.caltech.edu Wed Jun 21 04:40:04 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Wed, 21 Jun 2006 02:40:04 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: <20060621091556.GB6561@us.netrek.org> References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: On Wed, 21 Jun 2006, James Cameron wrote: > On Tue, Jun 20, 2006 at 02:02:08AM -0700, Trent Piepho wrote: > > The original ATT bitmap, the one from the paradise client, is larger > > than a normal ship. > > So shouldn't this bitmap be placed in the other clients and the server > left as it was? > Anyone know if there any bronco clients that use the 28x28 AT bitmap? I checked COW, gltrek, Ted Turner/BRMH, and Netrek XP, they all use 20x20 for the AT. I imagine Paradise does as well, having 1 ship bitmap being different size than the others doesn't work so well with the concactenated bitmap sets used by todays clients. Bill From xyzzy at speakeasy.org Wed Jun 21 14:42:40 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed, 21 Jun 2006 12:42:40 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: On Wed, 21 Jun 2006, William Balcerski wrote: > On Wed, 21 Jun 2006, James Cameron wrote: > > > On Tue, Jun 20, 2006 at 02:02:08AM -0700, Trent Piepho wrote: > > > The original ATT bitmap, the one from the paradise client, is larger > > > than a normal ship. > > > > So shouldn't this bitmap be placed in the other clients and the server > > left as it was? > > > Anyone know if there any bronco clients that use the 28x28 AT bitmap? I > checked COW, gltrek, Ted Turner/BRMH, and Netrek XP, they all use 20x20 for > the AT. I imagine Paradise does as well, having 1 ship bitmap being Ted Turner and BRMH are totally different clients. Paradise does use the 28x28 bitmap. From williamb at its.caltech.edu Wed Jun 21 16:00:15 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Wed, 21 Jun 2006 14:00:15 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: > Ted Turner and BRMH are totally different clients. Paradise does use > the 28x28 bitmap. > Just to clarify, by Paradise do you mean the old Paradise client (I think last version is 2.99), or Paradise 2000? And does the old Paradise client even work on bronco servers? Also, the documenation says that client is retired, and the successor is Ted Turner, which does use 20x20 for AT. From xyzzy at speakeasy.org Wed Jun 21 19:19:29 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed, 21 Jun 2006 17:19:29 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: On Wed, 21 Jun 2006, William Balcerski wrote: > > Ted Turner and BRMH are totally different clients. Paradise does use > > the 28x28 bitmap. > > > Just to clarify, by Paradise do you mean the old Paradise client (I think > last version is 2.99), or Paradise 2000? And does the old Paradise client > even work on bronco servers? Also, the documenation says that client is > retired, and the successor is Ted Turner, which does use 20x20 for AT. The old paradise client works fine on bronco servers and it does use the larger bitmap. It's where the ATT came from originally. Tedturner does come with a 28x28 ATT bitmap, from AT.xbm in TedTuner-1.3.1 source. #define att_width 28 #define att_height 448 From quozl at us.netrek.org Wed Jun 21 19:40:07 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 22 Jun 2006 10:40:07 +1000 Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> <20060620234732.GA4780@us.netrek.org> <20060621085832.GA6561@us.netrek.org> Message-ID: <20060622004007.GB7300@us.netrek.org> On Wed, Jun 21, 2006 at 02:34:30AM -0700, William Balcerski wrote: > Hmm I guess what I was trying to get at was, if fuel were ever larger than > an unsigned int could hold, there would be problems in numerous places, > especially client side as they would not be able to accept fuel as a long > int. So the margin check would have no impact. So what? It's still useful, as it would prevent short packets from being used in the event a larger fuel was used. In the SP_YOU packet it is sent as a LONG. > I wonder whose comment that is? Heh. I think you misunderstood the > question though. In that long switch list, lines 746-772, numerous types > eventually get sent to sendSC() at line 798. What in the sendSC() > function determines which of those types are critical? No, sendSC() is only used if DOUBLE_UDP is defined, and that's a diagnostic tool not normally defined. socket.c has an #undef for it. So sendSC() is not relevant. The long switch statement determines if a packet is sent by UDP or TCP. See the gwrite() call on line 786 for UDP, and the call on line 821 for TCP. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From williamb at its.caltech.edu Wed Jun 21 19:50:49 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Wed, 21 Jun 2006 17:50:49 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: > The old paradise client works fine on bronco servers and it does > use the larger bitmap. It's where the ATT came from originally. > > Tedturner does come with a 28x28 ATT bitmap, from AT.xbm in > TedTuner-1.3.1 source. > #define att_width 28 > #define att_height 448 > Ah, I see now where that was, it's the Ind AT that is 28x28 in paradise and Ted Turner. However, for Fed/Rom/Kli/Ori, it uses a 20x20 bitmap for the AT. For Paradise-2000, I imagine you use 20x20 for the 32 position AT bitmaps for Fed/Rom/Kli/Ori? But which size do you use for the Ind AT? I think I finally understand why, in the xtkill code, it set the player ship size to 20x20 when you give them an AT. It's because all clients use 20x20 for player ATs, it's just that the Ind ATs may be 28x28. However, with the last few AT patches, I removed all the obstacles that prevented a player from refitting into or choosing an AT from team select screen (provided the ship is a valid ship type in the sysdef file). I am wondering, in what case would there actually be a 28x28 AT used? If the server god was in game as Ind, and gave himself AT with xtkill, the code would still have set his ship size to 20x20. Unless there is another way to generate an Ind AT? I still think the default ship size should stay at 20x20. The use of tiled bitmap sets has led to all ship art being drawn the same size. I think every released, actively developed client today uses the tiled bitmaps. Bill From netrek at gmail.com Wed Jun 21 20:24:06 2006 From: netrek at gmail.com (Zach) Date: Wed, 21 Jun 2006 21:24:06 -0400 Subject: [netrek-dev] geno? Message-ID: I noticed that when a geno happens I have to start up cilent and login again to re-enter. All the race windows are struck out and won't allow me to rejoin. Not sure if this is client or server issue. Zach From williamb at its.caltech.edu Wed Jun 21 20:47:46 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Wed, 21 Jun 2006 20:47:46 -0500 Subject: [netrek-dev] darcs patch: Show geno messages for observers Message-ID: <200606220147.k5M1lkYB007013@omen.digital-genesis.com> Wed Jun 21 20:35:21 CDT 2006 williamb at its.caltech.edu * Show geno messages for observers * genspkt.c (sndSelf and sndSSelf): Factorized check for whether packet should be marked as critical. (check_sendself_critical): New function. Player status (via sndPStatus) is sent before player whydead (via sndSelf or sndSSelf). When whydead changes, the packet must be marked as critical in order for that information to arrive first, so that observers can get a proper whydead message upon genocide. This was previously done for just sndSelf, but with this patch, both sndSelf and sndSSelf now do it, and observers get geno messages with short packets on. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 35593 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060621/1eef3129/attachment-0001.bin From xyzzy at speakeasy.org Wed Jun 21 20:54:22 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed, 21 Jun 2006 18:54:22 -0700 (PDT) Subject: [netrek-dev] darcs patch: Adding packet priority to sndSSelf In-Reply-To: <20060622004007.GB7300@us.netrek.org> References: <200606202152.k5KLqOlD026933@omen.digital-genesis.com> <20060620234732.GA4780@us.netrek.org> <20060621085832.GA6561@us.netrek.org> <20060622004007.GB7300@us.netrek.org> Message-ID: On Thu, 22 Jun 2006, James Cameron wrote: > On Wed, Jun 21, 2006 at 02:34:30AM -0700, William Balcerski wrote: > > Hmm I guess what I was trying to get at was, if fuel were ever larger than > > an unsigned int could hold, there would be problems in numerous places, > > especially client side as they would not be able to accept fuel as a long > > int. So the margin check would have no impact. > > So what? It's still useful, as it would prevent short packets from > being used in the event a larger fuel was used. In the SP_YOU packet it > is sent as a LONG. I think Bill does not understand the one packet uses a short and the other uses a long. > > The long switch statement determines if a packet is sent by UDP or TCP. > See the gwrite() call on line 786 for UDP, and the call on line 821 for > TCP. Bill forgot to update this switch statement in his patch. From xyzzy at speakeasy.org Wed Jun 21 20:58:36 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed, 21 Jun 2006 18:58:36 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: On Wed, 21 Jun 2006, William Balcerski wrote: > > The old paradise client works fine on bronco servers and it does > > use the larger bitmap. It's where the ATT came from originally. > > > > Tedturner does come with a 28x28 ATT bitmap, from AT.xbm in > > TedTuner-1.3.1 source. > > #define att_width 28 > > #define att_height 448 > > > Ah, I see now where that was, it's the Ind AT that is 28x28 in paradise > and Ted Turner. However, for Fed/Rom/Kli/Ori, it uses a 20x20 bitmap for > the AT. For Paradise-2000, I imagine you use 20x20 for the 32 position AT > bitmaps for Fed/Rom/Kli/Ori? But which size do you use for the Ind AT? No, that's wrong. TedTurner-1.3.1 doesn't acutually have 20x20 ATT bitmaps, those are just copies of the GA bitmaps. Paradise 2000 and the old paradise client, which a few people still use, only has 28x28 bitmaps for ATT. > I still think the default ship size should stay at 20x20. The use of > tiled bitmap sets has led to all ship art being drawn the same size. I > think every released, actively developed client today uses the tiled bitmaps. You are wrong. From williamb at its.caltech.edu Wed Jun 21 21:23:56 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Wed, 21 Jun 2006 21:23:56 -0500 Subject: [netrek-dev] darcs patch: Semi-critical update fix Message-ID: <200606220223.k5M2NuNn010596@omen.digital-genesis.com> Wed Jun 21 21:21:26 CDT 2006 williamb at its.caltech.edu * Semi-critical update fix * socket.c (updateClient): clarifies purpose of packet type check against 0x40, adds check for SP_S_YOU case. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 33168 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060621/1839126f/attachment-0001.bin From williamb at its.caltech.edu Wed Jun 21 21:35:49 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Wed, 21 Jun 2006 19:35:49 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: > No, that's wrong. TedTurner-1.3.1 doesn't acutually have 20x20 ATT bitmaps, > those are just copies of the GA bitmaps. Paradise 2000 and the old paradise > client, which a few people still use, only has 28x28 bitmaps for ATT. > Hmm, if you are a Fed ATT, what bitmap does it display then (in Paradise 2000)? Curious also, does Paradise 2000 have 32 positions for ATT, or just 16? > > I still think the default ship size should stay at 20x20. The use of > > tiled bitmap sets has led to all ship art being drawn the same size. I > > think every released, actively developed client today uses the tiled bitmaps. > > You are wrong. > Way to be tact, but eh shouldn't expect that from you. Anyways, from what I can tell, the ship defined with and height in getships.c doesn't do a whole lot. Torp explosion distance is still the same, regardless of how big the ship is defined as - that seems to me the most crucial reason why the 20x20 ATT should be standard. If ship drawn at 28x28, torps will just pass through the outer portions of the ship. Furthermore, in robotd/getship.c, ATT has always been defined as 20x20. So there are at least 2 places in the code (robot getship, plus xtkill) where it sets ATT size to 20x20. And 1 case where it set it to 28x28 (ntserv getship). Seems to me they should all be the same. Bill From quozl at us.netrek.org Wed Jun 21 21:57:29 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 22 Jun 2006 12:57:29 +1000 Subject: [netrek-dev] geno? In-Reply-To: References: Message-ID: <20060622025729.GE11858@us.netrek.org> That's not what I get. Check your versions. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Thu Jun 22 00:18:56 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 22 Jun 2006 15:18:56 +1000 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060606012903.GA17953@orion.netrek.org> References: <20060606012903.GA17953@orion.netrek.org> Message-ID: <20060622051856.GH11858@us.netrek.org> On Mon, Jun 05, 2006 at 09:29:03PM -0400, Dave Ahn wrote: > It would be more useful to look at the server logs for continuum, hockey > and other servers over the last year or two. 2004-05 to 2006-05 on continuum ... for the small amount of time that RSA was actually enabled ... % egrep "^Client: " logfile | cut -f1-3 -d: | sort | uniq -c | sort -rn 167204 Client: NetrekXP Mod. Arch: Win32. Player 14753 Client: NetrekXP. Arch: Win32. Player 13380 Client: Client Of Win. Arch: Intel/Win32. Player 8386 Client: Paradise 2000. Arch: i386/Linux. Player 7664 Client: Netrek2000. Arch: Win32. Player 4821 Client: BRMH 2.4. Arch: x86/Linux. Player 2133 Client: Client Of Win v3. Arch: gnu_win32 / Cygnus GNU Win32 ke. Player 1536 Client: TedTurner-1.3.1. Arch: PowerPC/Darwin/X11. Player 1232 Client: Client Of Win v3. Arch: Linux libc 5.x / Color Release. Player 814 Client: BRMH 2.4. Arch: SPARC/Solaris 2.6. Player 750 Client: Client Of Win v3. Arch: unix / RedHat 7.2 RPM Key. Player 722 Client: Client Of Win v3. Arch: Zen Penguin Linux. Player 556 Client: BRMH 2.4. Arch: PowerPC/Mac OS X (Darwin 7.2). Player 410 Client: BRMH 2.4. Arch: SPARC/Linux 2.2. Player 388 Client: Client Of Win. Arch: linux_ix86 ELF - stable. Player 349 Client: Paradise 2.99. Arch: SGI/IRIX 6.2. Player 334 Client: Paradise 2.99. Arch: i386/Linux 2.2. Player 199 Client: Client Of Win v3. Arch: NetBSD/i386 ELF (1.5+). Player 175 Client: Client Of Win. Arch: Sun-4/Solaris-2.3. Player 115 Client: BRMH 2.4. Arch: x86/FreeBSD 3.1. Player 111 Client: Paradise 2.99. Arch: Sparc/Solaris 2.7. Player 107 Client: BRMH 2.4. Arch: PowerPC/Linux. Player 59 Client: Client Of Win. Arch: linux ELF/POSIX / XFree 3.1.1. Player 57 Client: BRM-Hadley. Arch: x86/linux. Player 54 Client: Client Of Win v3. Arch: Solaris2.6 / Cow 3.0pl3. Player 53 Client: Client Of Win v3. Arch: Linux / RedHat RPM Key. Player 35 Client: BRM-Hadley. Arch: FreeBSD 2.1. Player 34 Client: BRMH 2.4. Arch: SGI/IRIX 6.2. Player 33 Client: BRMH-2.3. Arch: DEC-ALPHA / OSF1 V4.0. Player 22 Client: COW-lite. Arch: PC / Win32. Player 12 Client: BRM-Hadley. Arch: Sun4 / SunOS 4.1.2. Player 10 Client: Client Of Win v3. Arch: FreeBSD / 4.7-STABLE. Player 8 Client: BRMH 2.4. Arch: sun4/SunOS 4.1.4. Player 5 Client: Paradise 2.99. Arch: i386/FreeBSD 4.0. Player 5 Client: BRMH 2.4. Arch: SGI/IRIX64 6.5. Player 4 Client: BRM-Hadley. Arch: HP700 / HP-UX. Player 3 Client: BRM-Hadley. Arch: SGI / 4.0.5. Player 2 Client: JTrek 0.94beta. Arch: Java 1.1. Player 1 Client: BRM-Hadley. Arch: x86/Linux. Player 1 Client: BRM-Hadley. Arch: Sun4 / Solaris. Player 1 Client: BRM-Hadley. Arch: RS6000 / AIX 3.2.5. Player -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060622/bfe79008/attachment.pgp From netrek at gmail.com Thu Jun 22 00:27:59 2006 From: netrek at gmail.com (Zach) Date: Thu, 22 Jun 2006 01:27:59 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060622051856.GH11858@us.netrek.org> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> Message-ID: Wish we had logs like this from years ago. Would be cool to see ULTRIX, MVS, VMS in there! heh Zach From williamb at its.caltech.edu Thu Jun 22 01:04:50 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Wed, 21 Jun 2006 23:04:50 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060622051856.GH11858@us.netrek.org> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> Message-ID: > 2004-05 to 2006-05 on continuum ... for the small amount of time that > RSA was actually enabled ... > > So out of roughly 225000 connections, 8000-9000 or so use clients without 32 position bitmaps, hence my original statement of 95+% proved to be quite accurate! Bill From quozl at us.netrek.org Thu Jun 22 02:41:22 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 22 Jun 2006 17:41:22 +1000 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> Message-ID: <20060622074122.GK11858@us.netrek.org> On Wed, Jun 21, 2006 at 11:04:50PM -0700, William Balcerski wrote: > So out of roughly 225000 connections, 8000-9000 or so use clients without > 32 position bitmaps, hence my original statement of 95+% proved to be > quite accurate! In addition, clue tend to be older and more likely to be using one of the older clients. This is always a question; listen to the masses, or listen to the clue? 216,000 lemmings can't be wrong. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From xyzzy at speakeasy.org Thu Jun 22 02:51:55 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Thu, 22 Jun 2006 00:51:55 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: On Wed, 21 Jun 2006, William Balcerski wrote: > > No, that's wrong. TedTurner-1.3.1 doesn't acutually have 20x20 ATT bitmaps, > > those are just copies of the GA bitmaps. Paradise 2000 and the old paradise > > client, which a few people still use, only has 28x28 bitmaps for ATT. > > > Hmm, if you are a Fed ATT, what bitmap does it display then (in Paradise > 2000)? Curious also, does Paradise 2000 have 32 positions for ATT, or > just 16? Just 1, like a base. It is a deathstar aka AT&T logo. There is only one ATT bitmap. It hardly seems worthwhile for different bitmaps for each race for a ship you never see. > > You are wrong. > > > Way to be tact, but eh shouldn't expect that from you. Anyways, from what I have no idea why you expect anyone to any tact with you after all you have done. > I can tell, the ship defined with and height in getships.c doesn't do a > whole lot. Torp explosion distance is still the same, regardless of how It doesn't do anything. It's a leftover xtrek artifact of when the client and server were a single program. Only xsg uses it now. It should just be removed, except that would break xsg. It should be the size of the bitmap that xsg is using. Different ship sizes is a Paradise feature that didn't make into bronco. From netrek at gmail.com Thu Jun 22 03:02:13 2006 From: netrek at gmail.com (Zach) Date: Thu, 22 Jun 2006 04:02:13 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060622074122.GK11858@us.netrek.org> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> Message-ID: On 6/22/06, James Cameron wrote: > > In addition, clue tend to be older and more likely to be using one of > the older clients. > > This is always a question; listen to the masses, or listen to the clue? > > 216,000 lemmings can't be wrong. Heh just look at popularity of Microsoft and their products lol~ Or the abysmal state of pop music or.... Quite often what is popular is not what is best. Zach From williamb at its.caltech.edu Thu Jun 22 05:54:28 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Thu, 22 Jun 2006 03:54:28 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: References: <200606200055.k5K0t0XG003210@omen.digital-genesis.com> <3e8ca5c80606191912v61357301hbb055d73bdfcb159@mail.gmail.com> <20060621091556.GB6561@us.netrek.org> Message-ID: > Just 1, like a base. It is a deathstar aka AT&T logo. There is only one ATT > bitmap. It hardly seems worthwhile for different bitmaps for each race for a > ship you never see. > Now that ATTs can be used by players, I turn em on sometimes if people want them on my server (the chaos server), so those with NetrekXP mod and 2006 can get nice ATT bitmaps :). Especially NetrekXP 2006! > removed, except that would break xsg. It should be the size of the bitmap > that xsg is using. > Sounds good to me. From xsg/bitmaps.h: #define att_width 20 #define att_height 20 Guess we agree after all :). From chronosws at comcast.net Thu Jun 22 11:28:07 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Thu, 22 Jun 2006 09:28:07 -0700 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> Message-ID: <449AC517.6030902@comcast.net> Zach wrote: >On 6/22/06, James Cameron wrote: > > >>In addition, clue tend to be older and more likely to be using one of >>the older clients. >> >>This is always a question; listen to the masses, or listen to the clue? >> >>216,000 lemmings can't be wrong. >> >> > >Heh just look at popularity of Microsoft and their products lol~ Or >the abysmal state of pop music or.... Quite often what is popular is >not what is best. > >Zach > > I've always been disappointed at the decline of Netrek (I started myself back in 92 in college) but the client presentation has always felt like one of the largest factors in turning off new players to me (I have no studies to prove it, this is a gut feeling.) Personally, I think you draw them in with cool graphics and sound (first impressions, right?) and keep them with the stellar game play. I know there have been many client forks, but even the NetrekXP ones have just been mildly warmed over rehashes of COW clients, and certainly not up to the standards a modern gamer would expect. Is the community even willing to give the game the good, hard look it deserves to bring it up to the 21st century? P.S. I am fairly new to the mailing list and am still catching up on back postings, so if this has already been hashed out I apologize. From netrek at gmail.com Thu Jun 22 14:45:51 2006 From: netrek at gmail.com (Zach) Date: Thu, 22 Jun 2006 15:45:51 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449AC517.6030902@comcast.net> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> Message-ID: On 6/22/06, Cliff Hudson wrote: > I've always been disappointed at the decline of Netrek (I started myself > back in 92 in college) but the client presentation has always felt like Welcome Cliff. What handle did you play as primarily? I've been playing since '94. Welcome to the list. Are you a programmer? > one of the largest factors in turning off new players to me (I have no > studies to prove it, this is a gut feeling.) Personally, I think you > draw them in with cool graphics and sound (first impressions, right?) > and keep them with the stellar game play. I know there have been many > client forks, but even the NetrekXP ones have just been mildly warmed > over rehashes of COW clients, and certainly not up to the standards a > modern gamer would expect. Is the community even willing to give the > game the good, hard look it deserves to bring it up to the 21st century? I agree. What ideas do you have that a modern client should encapsulate? Zach From chronosws at comcast.net Thu Jun 22 15:52:57 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Thu, 22 Jun 2006 13:52:57 -0700 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> Message-ID: <449B0329.3010103@comcast.net> Zach wrote: >On 6/22/06, Cliff Hudson wrote: > > >>I've always been disappointed at the decline of Netrek (I started myself >>back in 92 in college) but the client presentation has always felt like >> >> > >Welcome Cliff. > >What handle did you play as primarily? I've been playing since '94. >Welcome to the list. >Are you a programmer? > > Back then, I played under a variant of the handle chronos (I can't remember which one now though, since the name was always taken and I have so many variants. If you look through server logs, I logged on from WSU in Washington State) More recently I have played under ChronosWS, but now I use Jahnweh (no collisions, same handle I use in Eve Online.) I am a developer (8 years C/C++ dev work for Microsoft (Windows/DirectX) and a startup called Wildseed (Linux)) and a program manager (1 year at AOL when Wildseed was acquired.) > > >>one of the largest factors in turning off new players to me (I have no >>studies to prove it, this is a gut feeling.) Personally, I think you >>draw them in with cool graphics and sound (first impressions, right?) >>and keep them with the stellar game play. I know there have been many >>client forks, but even the NetrekXP ones have just been mildly warmed >>over rehashes of COW clients, and certainly not up to the standards a >>modern gamer would expect. Is the community even willing to give the >>game the good, hard look it deserves to bring it up to the 21st century? >> >> > >I agree. What ideas do you have that a modern client should encapsulate? > >Zach > > > I have several ideas. As I said, I believe the game play for Netrek is excellent, and I think changing that directly is not appropriate. Some things which strike me as needing work, looking from an 'attract new players perspective', are: (NOTE: When speaking of the client, I am referring to the NetrekXP 2006 client, V1.0) - 10 updates/sec. Because the client does not interpolate between server updates, gameplay appears 'choppy'. This is probably the area where I would most be inclined to change the server, moving to an event-based network protocol with sync rather than a updates/sec protocol. - Graphics. In general the bitmapped graphics look dated. Now I have the utmost respect for those who have come along and tried to give the game a more updated look with new bitmaps (Pascal comes to mind recently) but it's not just the bitmaps. Smothing out movements (vis-a-vis smooth ship rotations) and better effects (explosions with particle effects, maybe some lighting, trails off the torps or plasmas) are the top things which come to hmind. - Playfield. I've always felt the tactical should be much larger. Obviously the galactic is very important and its ability to convey information should not be diminished, but perhaps it could be made as an overlay, or hidden under some circumstances, etc to give the player more tactical screen real estate (even if no real additional information is disphhlayed on the tactical.) - Sound. Netrek has always been weak on this front. We all know that it sounds like what it is - developers grabbed some wavs from their favorite Star Trek-themed source and slapped a playSound() call in the right places in the code. What needs to happen is someone who is good at manipulating sound files needs to fix these up, balance their levels and integrate them into an overall sound scheme for the game. A bit of background noise (the hum of the ship) wouldn't hurt. To be fair, recent clients have done a better job with some of the sounds (shields sound good, for instance,) but others leave much to be desired (the login WAV on NetrekXP 2006 for instance seems jarring, the cloaking sound takes WAY too long compared to the cloak animation time, phaser blast sound is slightly delayed compared to the graphics.) - Configuration. RC files died in the 90s, at least as a primary method of users configuring applications. There needs to be a proper configuration UI, including a modern keymapping system. Obviously keys can be remapped using the help screen, but this fact is a bit opaque to new players and provides no instruction. The ability to move windows in the client is nice, but quite possibly misguided, especially since you can do it while in combat. There are probably a limited number of genuinely useful configurations, and it may be wise to make it so you can't create dumb ones (for instance, where the galactic is partially obscured by the tactical.) These will obviously seem like minor issues to devs and hardcore players, but I believe new players will expect more polish from a game which is ostensibly 20 years old in its present form. - Window decoration. Now maybe this can be turned on and I simply haven't looked for the switch, but by default the game should be using the OS standard window decorations for the main window, so that it can be resized, closed, minimized, etc. Having a game window without a title bar (as appears on NetrekXP 2006) looks VERY strange. Overall, the client needs to be polished. It looks and feels rough because it was made by developers for hard core gamers, and for those two groups it large meets its presentation goals. But if I put this in front of a new person, the first thing they think is that it looks awfully old (and therefore must not be very interesting.) I think if people can just get past the first-impressions hurdle, they will be more inclined to stick around long enough to see how deep the gameplay goes. That's my $0.02. >_______________________________________________ >netrek-dev mailing list >netrek-dev at us.netrek.org >http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > From stephen.thorne at gmail.com Thu Jun 22 16:06:06 2006 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Fri, 23 Jun 2006 07:06:06 +1000 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B0329.3010103@comcast.net> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> Message-ID: <3e8ca5c80606221406j1b590c61r7d2b2bc99563a414@mail.gmail.com> On 6/23/06, Cliff Hudson wrote: > That's my $0.02. I really appreciate your donation, would you be okay with putting it on the wiki? http://wiki.us.netrek.org/netrek-dev/ClientIdeas http://wiki.us.netrek.org/netrek-dev/ServerIdeas -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From chronosws at comcast.net Thu Jun 22 16:51:05 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Thu, 22 Jun 2006 14:51:05 -0700 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <3e8ca5c80606221406j1b590c61r7d2b2bc99563a414@mail.gmail.com> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <3e8ca5c80606221406j1b590c61r7d2b2bc99563a414@mail.gmail.com> Message-ID: <449B10C9.7090406@comcast.net> Stephen Thorne wrote: >On 6/23/06, Cliff Hudson wrote: > > >>That's my $0.02. >> >> > >I really appreciate your donation, would you be okay with putting it >on the wiki? > >http://wiki.us.netrek.org/netrek-dev/ClientIdeas >http://wiki.us.netrek.org/netrek-dev/ServerIdeas > > > Done and done. From williamb at its.caltech.edu Thu Jun 22 18:39:50 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Thu, 22 Jun 2006 16:39:50 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B0329.3010103@comcast.net> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> Message-ID: > (NOTE: When speaking of the client, I am referring to the NetrekXP 2006 > client, V1.0) > Hey Cliff, I'm the author of Netrek XP 2006, thanks for the feedback, I'll try and hit some of the points you've covered. > - 10 updates/sec. Because the client does not interpolate between > server updates, gameplay appears 'choppy'. This is probably the area > where I would most be inclined to change the server, moving to an > event-based network protocol with sync rather than a updates/sec protocol. Nick Slager's java netrek client (jtrek) did this sort of interpolation. It was most noticeable on torp movements. I actually thought it made torp movement worse though, they kinda went all wobbly. If you want to take a look at his client you can get it at: http://ftp.netrek.org/pub/netrek/clients/jtrek/ It definitely has some neat stuff grahpics wise. Perhaps more ideas can come from looking at it ;). > - Graphics. In general the bitmapped graphics look dated. Now I have > the utmost respect for those who have come along and tried to give the > game a more updated look with new bitmaps (Pascal comes to mind > recently) but it's not just the bitmaps. Smothing out movements > (vis-a-vis smooth ship rotations) and better effects (explosions with > particle effects, maybe some lighting, trails off the torps or plasmas) > are the top things which come to hmind. Well with ship movements to 256 positions (for the new bitmap set at least), turning is smoother than ever. Lighting effects would be cool, maybe some particle effects too. Trails off torps would just be distracting though. > - Playfield. I've always felt the tactical should be much larger. > Obviously the galactic is very important and its ability to convey > information should not be diminished, but perhaps it could be made as an > overlay, or hidden under some circumstances, etc to give the player more > tactical screen real estate (even if no real additional information is > disphhlayed on the tactical.) I agree, one of the longer term goals for the client is to make tactical resizeable. > - Sound. Netrek has always been weak on this front. We all know that > it sounds like what it is - developers grabbed some wavs from their > favorite Star Trek-themed source and slapped a playSound() call in the > right places in the code. What needs to happen is someone who is good > at manipulating sound files needs to fix these up, balance their levels > and integrate them into an overall sound scheme for the game. A bit of > background noise (the hum of the ship) wouldn't hurt. To be fair, > recent clients have done a better job with some of the sounds (shields > sound good, for instance,) but others leave much to be desired (the > login WAV on NetrekXP 2006 for instance seems jarring, the cloaking > sound takes WAY too long compared to the cloak animation time, phaser > blast sound is slightly delayed compared to the graphics.) Engine hum might be ok, but I think it would get old after the first 100 hours :). As for the specific WAV files you mentioned. 1) Login wav was a bit shrill, I fixed this in version 1.1 2) The cloak/decloak event is very short (less than a second), I've always been used to the cloak sound being longer than the cloak event (has been that way in every client I've seen). I don't think it is too long personally. Plus all sounds overlap now so it's not like the length of the sound prevents you from hearing some other sound. 3) I've not noticed a delay on the phaser sound, are you getting delays on other sounds as well? I haven't had a chance to really test the sound on different systems, and since it's a whole new way of playing back sound with newSound: on (I'm assuming you are using newSound), I'm curious to see if there are some problems. > - Configuration. RC files died in the 90s, at least as a primary method > of users configuring applications. There needs to be a proper > configuration UI, including a modern keymapping system. Obviously keys > can be remapped using the help screen, but this fact is a bit opaque to > new players and provides no instruction. I do feel the keymap mapping is still the most difficult user configuration required, which is why I tried to include the best keymap possible as the default with the client. As for remapping keys by help, we let players know that in one of the hint of the day messages. The best I've come up with for changing options, is in game through the options menu. Most rc options can be changed there. All netrekrc options are listed in a file in the documentation folder called netrekrc_options. You can choose to save your current options through page 6 of the options menu, this creates a netrekrc.sav file in your netrek folder. I spent quite a bit of time improving this, so that is should basically create a duplicate of your netrekrc with whatever options you changed in game. I'm hesitant to actually save over your netrekrc though, so you still have to either rename the file or copy/paste into your netrekrc. > The ability to move windows in > the client is nice, but quite possibly misguided, especially since you > can do it while in combat. There are probably a limited number of > genuinely useful configurations, and it may be wise to make it so you > can't create dumb ones (for instance, where the galactic is partially > obscured by the tactical.) These will obviously seem like minor issues > to devs and hardcore players, but I believe new players will expect more > polish from a game which is ostensibly 20 years old in its present form. Again, I tried to include the best possible window placement in the default netrekrc. You can turn off window movement in game by adding the netrekrc option windowMove: off. This is the default setting. > - Window decoration. Now maybe this can be turned on and I simply > haven't looked for the switch, but by default the game should be using > the OS standard window decorations for the main window, so that it can > be resized, closed, minimized, etc. Having a game window without a > title bar (as appears on NetrekXP 2006) looks VERY strange. > The main window can be made resizeable, and it does come with a title bar. You will need mainResizeable: on (also the default setting). To bring up the title bar, hit alt-enter. The title bar cuts into the viewable space if your monitor resolution is set to the size of your netrek window. I could make the title bar on by default, but I think it's best the way it is. One of the tip of the day messages also explains how to use alt-enter to bring up the title bar. NetrekXP 2006 main window is minimizeable as well. As for the close button, it's greyed out. Not quite sure why. It's like that in COW and NetrekXP too. Any insight onto this one would be appreciated. Bill From chronosws at comcast.net Thu Jun 22 19:18:31 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Thu, 22 Jun 2006 17:18:31 -0700 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> Message-ID: <449B3357.1070207@comcast.net> William Balcerski wrote: >>- 10 updates/sec. Because the client does not interpolate between >>server updates, gameplay appears 'choppy'. This is probably the area >>where I would most be inclined to change the server, moving to an >>event-based network protocol with sync rather than a updates/sec protocol. >> >> > >Nick Slager's java netrek client (jtrek) did this sort of interpolation. >It was most noticeable on torp movements. I actually thought it made torp >movement worse though, they kinda went all wobbly. > > I think to do this right will require a server-side change because the client obviously cannot extrapolate torp movements properly since it doesn't know where the torp is going to go next. I'd change the server to send the torp position and a vector, which the client would use until the next vector change came along. Torp wobble is accomplished by having the server twiddle the vector each time torps get updated. Now I can already hear the calls "But now the client can use the torp vector to predict the future movement of the torp! Think of the borgs!" True, but if the torp is wobbling a bit every 10th of a second this foreknowledge will probably not be a big deal. >It definitely has some neat stuff grahpics wise. Perhaps more ideas can >come from looking at it ;). > > > >>- Graphics. In general the bitmapped graphics look dated. Now I have >>the utmost respect for those who have come along and tried to give the >>game a more updated look with new bitmaps (Pascal comes to mind >>recently) but it's not just the bitmaps. Smothing out movements >>(vis-a-vis smooth ship rotations) and better effects (explosions with >>particle effects, maybe some lighting, trails off the torps or plasmas) >>are the top things which come to hmind. >> >> > >Well with ship movements to 256 positions (for the new bitmap set at >least), turning is smoother than ever. Lighting effects would be cool, >maybe some particle effects too. Trails off torps would just be >distracting though. > > > Certainly we wouldn't want to go overboard on effects, and they should be able to be turned off for those who find them distracting. But generally I think it is instructive to look at comparable modern games (various RTSes for example) and note some of the graphical details being presented. It's not that any one feature suddenly makes the game look alive, but a collection of very small things. Incidentally, having 256 bitmaps is not especially necessary since the code for rotating a bitmap smoothly is well known. It might save the artists some time to implement bitmap rotations in the client code (make sure it does bi-linear interpolation for rotated pixels!) so they only have to draw the bitmap once and not 'tune up' each degree of the rotation (assuming they do that in the first place.) Although this may seem like a scary idea, a reworked client could use one of the commonly-available, portable graphics engines, such as Ogre. In particular Ogre provides access to the full range of transformations available in 3D. While the game itself is not played in 3D, there are effects which could be implemented using such an engine (lighting, parallax starfields, etc.) >>- Playfield. I've always felt the tactical should be much larger. >>Obviously the galactic is very important and its ability to convey >>information should not be diminished, but perhaps it could be made as an >>overlay, or hidden under some circumstances, etc to give the player more >>tactical screen real estate (even if no real additional information is >>disphhlayed on the tactical.) >> >> > >I agree, one of the longer term goals for the client is to make tactical >resizeable. > > > >>- Sound. Netrek has always been weak on this front. We all know that >>it sounds like what it is - developers grabbed some wavs from their >>favorite Star Trek-themed source and slapped a playSound() call in the >>right places in the code. What needs to happen is someone who is good >>at manipulating sound files needs to fix these up, balance their levels >>and integrate them into an overall sound scheme for the game. A bit of >>background noise (the hum of the ship) wouldn't hurt. To be fair, >>recent clients have done a better job with some of the sounds (shields >>sound good, for instance,) but others leave much to be desired (the >>login WAV on NetrekXP 2006 for instance seems jarring, the cloaking >>sound takes WAY too long compared to the cloak animation time, phaser >>blast sound is slightly delayed compared to the graphics.) >> >> > >3) I've not noticed a delay on the phaser sound, are you getting delays on >other sounds as well? I haven't had a chance to really test the sound on >different systems, and since it's a whole new way of playing back sound >with newSound: on (I'm assuming you are using newSound), I'm curious to >see if there are some problems. > > > The delay is inherent in the sound itself. The attack rate for the phaser sound is too low (i.e. the volume does not rise fast enough.) That is just my opinion though. >>- Configuration. RC files died in the 90s, at least as a primary method >>of users configuring applications. There needs to be a proper >>configuration UI, including a modern keymapping system. Obviously keys >>can be remapped using the help screen, but this fact is a bit opaque to >>new players and provides no instruction. >> >> > >I do feel the keymap mapping is still the most difficult user >configuration required, which is why I tried to include the best keymap >possible as the default with the client. As for remapping keys by help, >we let players know that in one of the hint of the day messages. >The best I've come up with for changing options, is in game through the >options menu. Most rc options can be changed there. All netrekrc options >are listed in a file in the documentation folder called netrekrc_options. >You can choose to save your current options through page 6 of the options >menu, this creates a netrekrc.sav file in your netrek folder. I spent >quite a bit of time improving this, so that is should basically create a >duplicate of your netrekrc with whatever options you changed in game. I'm >hesitant to actually save over your netrekrc though, so you still have to >either rename the file or copy/paste into your netrekrc. > > > This is one area where I think the UI can be greatly improved, taking us away from the minimalist UI of the late 80s and trying to make the application either a) use the common paradigm of the OS on which it runs or b) uses its own paradigm but doesn't look like a developer designed the UI. I generally prefer to use the idioms of the OS on which the application runs because users will be used to this and the game will be much more intuitive to interact with. For instance, having the options windows be real windows consistent with the design rules for that OS, using buttons, checkboxes, textboxes, etc. Alternatively, the existing UI elements would have to be wrapped up in custom graphics and behaviors to maintain the theme of the game (and the game would have to be given a theme other than developer rectangles with solid lines before this can occur.) The current 'rows of settings' with some being clickable, some being just informational does not fit any standard paradigm and looks clunky, even if it IS functional. >>The ability to move windows in >>the client is nice, but quite possibly misguided, especially since you >>can do it while in combat. There are probably a limited number of >>genuinely useful configurations, and it may be wise to make it so you >>can't create dumb ones (for instance, where the galactic is partially >>obscured by the tactical.) These will obviously seem like minor issues >>to devs and hardcore players, but I believe new players will expect more >>polish from a game which is ostensibly 20 years old in its present form. >> >> > >Again, I tried to include the best possible window placement in the >default netrekrc. You can turn off window movement in game by adding the >netrekrc option windowMove: off. This is the default setting. > > > Hmm, for some reason window dragging was on in my game. I don't actually have a problem with the default window placement personally, but I can imagine that there might be two or three 'popular' placements. The options UI could let the user select from these pre-canned profiles, rather than having to edit the RC file. >>- Window decoration. Now maybe this can be turned on and I simply >>haven't looked for the switch, but by default the game should be using >>the OS standard window decorations for the main window, so that it can >>be resized, closed, minimized, etc. Having a game window without a >>title bar (as appears on NetrekXP 2006) looks VERY strange. >> >> >> > >The main window can be made resizeable, and it does come with a title bar. >You will need mainResizeable: on (also the default setting). > Unfortunately, doing this does not scale any of the other windows, which is what the user would expect. >To bring up >the title bar, hit alt-enter. The title bar cuts into the viewable >space if your monitor resolution is set to the size of your netrek window. > > The client could do a check and if the screen resolution is less than the size needed to show the window with decorations, turn them off, but only in the case where there is not enough room. Alternately, the title bar could be left on by default, but a 'fullscreen' option presented which eliminates the decorations (and expands the window to the full screen size.) This is a more standard paradigm for removing window decorations, and may be less offensive to users. >I could make the title bar on by default, but I think it's best the way it >is. One of the tip of the day messages also explains how to use alt-enter >to bring up the title bar. > Tip of the day are great. Another thing to consider is creating a help file appropriate to the OS. Such a help file could include the newbie guide as well. Here I am specifically thinking of a windows help file or a web page which is launched in your default browser when you select 'help.' > NetrekXP 2006 main window is minimizeable as >well. As for the close button, it's greyed out. Not quite sure why. >It's like that in COW and NetrekXP too. Any insight onto this one would >be appreciated. > > > I don't know offhand, I'll have to go browse through the code - it's been a while since I made a CreateWindowEx() call as I've been doing embedded Linux programming for the past 5 years ;) BTW, please take all of these suggestions in the best light. I'm not disparaging your efforts or questioning your judgement. These are my honest opinions on the subject. >Bill > >_______________________________________________ >netrek-dev mailing list >netrek-dev at us.netrek.org >http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > From netrek at gmail.com Thu Jun 22 19:42:18 2006 From: netrek at gmail.com (Zach) Date: Thu, 22 Jun 2006 20:42:18 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B3357.1070207@comcast.net> References: <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> Message-ID: Hi Cliff, Wow great feedback. I'm curious what you think of making a full fledged 3D client using a toolkit like OpenGL? The sophistication could obviously get very high (ray tracing, more complex game physics, full animation) etc... and this would place a higher requirement for a good video card, CPU speed, RAM etc. Would a 3D client be too radical a departure or could we do a hybrid client with mainly 2D and some 3D effects throw in for fun? Zach From jimmyhua73 at yahoo.com Thu Jun 22 20:52:13 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 22 Jun 2006 18:52:13 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060622074122.GK11858@us.netrek.org> Message-ID: <20060623015213.80330.qmail@web35308.mail.mud.yahoo.com> --- James Cameron wrote: > In addition, clue tend to be older and more likely > to be using one of > the older clients. I'm not sure where you get this kind of information. The clue who I regularly play with also regularly download and try the new clients as they come out. I'm rusty beer myself, and thusly use an old client :-P Jimmy From jimmyhua73 at yahoo.com Thu Jun 22 20:56:54 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 22 Jun 2006 18:56:54 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: Message-ID: <20060623015654.43465.qmail@web35307.mail.mud.yahoo.com> --- Trent Piepho wrote: > It doesn't do anything. It's a leftover xtrek > artifact of when the client and > server were a single program. Only xsg uses it now. > It should just be > removed, except that would break xsg. It should be > the size of the bitmap > that xsg is using. Is it just me or am I the only person who still uses xsg? As far as xsg goes, i think it's a 20x20 bitmap for ATT ships. When it gets displayed the ship ends up being off center due to it being defined as 28x28??? Need to try out this 20x20 change and see if it fixes xsg. Jimmy From jimmyhua73 at yahoo.com Thu Jun 22 21:12:18 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 22 Jun 2006 19:12:18 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B0329.3010103@comcast.net> Message-ID: <20060623021218.64659.qmail@web35314.mail.mud.yahoo.com> --- Cliff Hudson wrote: > - 10 updates/sec. Because the client does not > interpolate between > server updates, gameplay appears 'choppy'. This is > probably the area > where I would most be inclined to change the server, > moving to an > event-based network protocol with sync rather than a > updates/sec protocol. I like this idea. I dunno anything about programming though. > - Graphics. In general the bitmapped graphics look > dated. Now I have > the utmost respect for those who have come along and > tried to give the > game a more updated look with new bitmaps (Pascal > comes to mind > recently) but it's not just the bitmaps. Smothing > out movements > (vis-a-vis smooth ship rotations) and better effects > (explosions with > particle effects, maybe some lighting, trails off > the torps or plasmas) > are the top things which come to hmind. I like this idea. > - Playfield. I've always felt the tactical should be > much larger. > Obviously the galactic is very important and its > ability to convey > information should not be diminished, but perhaps it > could be made as an > overlay, or hidden under some circumstances, etc to > give the player more > tactical screen real estate (even if no real > additional information is > disphhlayed on the tactical.) Well, we can make the tactical/galactic more user configurable. But as you get good at this game, you spend way more time looking at the galactic than the tactical. > - Sound. Netrek has always been weak on this front. > We all know that > it sounds like what it is - developers grabbed some > wavs from their > favorite Star Trek-themed source and slapped a > playSound() call in the > right places in the code. What needs to happen is > someone who is good > at manipulating sound files needs to fix these up, > balance their levels > and integrate them into an overall sound scheme for > the game. A bit of > background noise (the hum of the ship) wouldn't > hurt. To be fair, > recent clients have done a better job with some of > the sounds (shields > sound good, for instance,) but others leave much to > be desired (the > login WAV on NetrekXP 2006 for instance seems > jarring, the cloaking > sound takes WAY too long compared to the cloak > animation time, phaser > blast sound is slightly delayed compared to the > graphics.) I have personally turned off the sound in every version I tried with sound. So the sound definitely needs improving, by alot. > - Configuration. RC files died in the 90s, at least > as a primary method > of users configuring applications. There needs to > be a proper > configuration UI, including a modern keymapping > system. Obviously keys > can be remapped using the help screen, but this fact > is a bit opaque to > new players and provides no instruction. The > ability to move windows in > the client is nice, but quite possibly misguided, > especially since you > can do it while in combat. There are probably a > limited number of > genuinely useful configurations, and it may be wise > to make it so you > can't create dumb ones (for instance, where the > galactic is partially > obscured by the tactical.) These will obviously > seem like minor issues > to devs and hardcore players, but I believe new > players will expect more > polish from a game which is ostensibly 20 years old > in its present form. Oh yeah, this I would like to see too. > - Window decoration. Now maybe this can be turned > on and I simply > haven't looked for the switch, but by default the > game should be using > the OS standard window decorations for the main > window, so that it can > be resized, closed, minimized, etc. Having a game > window without a > title bar (as appears on NetrekXP 2006) looks VERY > strange. Too many people with too little screens. And netrek has too much to show if you want to play effectively. ALL SERIOUS GAMES take up the full screen. Any modern game I've played, takes up the whole screen. It's weird that netrek is in a window... I have the exact opposite opinion about this than you. > Overall, the client needs to be polished. It looks > and feels rough > because it was made by developers for hard core > gamers, and for those > two groups it large meets its presentation goals. > But if I put this in > front of a new person, the first thing they think is > that it looks > awfully old (and therefore must not be very > interesting.) I think if > people can just get past the first-impressions > hurdle, they will be more > inclined to stick around long enough to see how deep > the gameplay goes. Agreed. However, the reason it looks old is because it is old. Awfully old at that! You'd probably need to re-write the client to make it look signficantly better than it does now. I'd love to see client improvements, however, I don't really know how to program. Jimmy From jimmyhua73 at yahoo.com Thu Jun 22 21:17:35 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 22 Jun 2006 19:17:35 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B3357.1070207@comcast.net> Message-ID: <20060623021735.21625.qmail@web35304.mail.mud.yahoo.com> --- Cliff Hudson wrote: > I think to do this right will require a server-side > change because the > client obviously cannot extrapolate torp movements > properly since it > doesn't know where the torp is going to go next. > I'd change the server > to send the torp position and a vector, which the > client would use until > the next vector change came along. Torp wobble is > accomplished by > having the server twiddle the vector each time torps > get updated. Now I > can already hear the calls "But now the client can > use the torp vector > to predict the future movement of the torp! Think > of the borgs!" True, > but if the torp is wobbling a bit every 10th of a > second this > foreknowledge will probably not be a big deal. The robots in a newbie server need the torp vector in order to properly dodge torps. Trent recently made a change in the server source so torp vector info is being sent. Jimmy From jimmyhua73 at yahoo.com Thu Jun 22 21:22:22 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 22 Jun 2006 19:22:22 -0700 (PDT) Subject: [netrek-dev] darcs patch: xtkill ship change fixes In-Reply-To: <20060623015654.43465.qmail@web35307.mail.mud.yahoo.com> Message-ID: <20060623022222.92695.qmail@web35308.mail.mud.yahoo.com> > Need to try out this 20x20 change and see if it > fixes > xsg. XSG is fixed thanks to the size change from 28x28 to 20x20 in ATT ships. Thanks Bill! Jimmy From jimmyhua73 at yahoo.com Thu Jun 22 21:29:10 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 22 Jun 2006 19:29:10 -0700 (PDT) Subject: [netrek-dev] war declarations for newbie robots Message-ID: <20060623022910.56590.qmail@web35307.mail.mud.yahoo.com> Hello, Is it just me, or the code for war declarations for the newbie robots is a bit too convoluted? It seems it is trying to find the enemy team with the most number of players and declare war on it, and then declaring peace with everybody else. But it's buggy. I am thinking about simplifying it to: declare war on all players not on the robot's team. Here's a snippet from robotd/update_players.c declare_intents() /* war & peace. Done initially */ /* BUGS */ declare_intents() { register i; register struct player *j; int teams[16], maxt = 0; int newhostile, pl=0; extern char *team_to_string(); if(me_p->alive < 100 || !isAlive(me)) /* 10 seconds into game */ return; if(_state.player_type == PT_OGGER || _state.player_type == PT_DOGFIGHTER) return; newhostile = me->p_hostile; bzero(teams, sizeof(teams)); for(i=0, j=players; ip_status == PFREE) continue; if(j->p_flags & PFROBOT) continue; if(me->p_team == j->p_team || j->p_team == 0 || j->p_team == ALLTEAM) continue; teams[j->p_team]++; pl++; } if(pl){ for(i=1; i< 9; i *= 2) if(teams[i] > maxt) maxt = i; mprintf("max team = %s\n", team_to_string(maxt)); } /* else maxt = -1; */ /* peace */ for(i=1; i< 9; i *= 2){ if(i == maxt) continue; if((i & me->p_hostile) && !(i & me->p_swar)){ mprintf("declaring peace with %s\n", team_to_string(i)); newhostile ^= i; } } _state.warteam = maxt; /* war */ if(maxt != -1){ if(!((maxt & me->p_swar) || (maxt & me->p_hostile))){ mprintf("declare war with %s\n", team_to_string(maxt)); newhostile ^= maxt; } } if(newhostile != me->p_hostile) sendWarReq(newhostile); } From williamb at its.caltech.edu Thu Jun 22 21:45:10 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Thu, 22 Jun 2006 19:45:10 -0700 (PDT) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B3357.1070207@comcast.net> References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> Message-ID: > Incidentally, having 256 bitmaps is not especially necessary since the > code for rotating a bitmap smoothly is well known. It might save the > artists some time to implement bitmap rotations in the client code (make > sure it does bi-linear interpolation for rotated pixels!) so they only > have to draw the bitmap once and not 'tune up' each degree of the > rotation (assuming they do that in the first place.) > My client doesn't come with 256 bitmaps, it has one 80x80 ship bitmap it scales and rotates on the fly using native windows SetWorldTransform function. Planets also come in larger size too, they are just scaled (not rotated). Goal has been to make bitmaps 4x larger than needed so can support up to 2000x2000 tactical and galactic maps someday :). > Although this may seem like a scary idea, a reworked client could use > one of the commonly-available, portable graphics engines, such as Ogre. > In particular Ogre provides access to the full range of transformations > available in 3D. While the game itself is not played in 3D, there are > effects which could be implemented using such an engine (lighting, > parallax starfields, etc.) > Gregory Hermann (spelling?) is working on netrek GL which uses Ogre I believe, you can get it off the netrek sourceforge site. Not sure if it's in a working state at the moment. But the screenshot of the 3d klingon battlecruiser was quite nice. Of course, netrek is a 2d game so any 3d stuff is gonna be..limited at best. Or just plain distracting. > The delay is inherent in the sound itself. The attack rate for the > phaser sound is too low (i.e. the volume does not rise fast enough.) > That is just my opinion though. > Well phaser sound is 1 second long and the phaser sound begins .01 seconds into the sound file, reaching maximum volume at .15 seconds. Sound for other people's phasers is shorter, at .6 seconds, with sound starting .03 seconds into the file, reaching maximum volume at .09 seconds. Was it other's phasers that you think was too delayed? I can chop .02 seconds off the front. > occur.) The current 'rows of settings' with some being clickable, some > being just informational does not fit any standard paradigm and looks > clunky, even if it IS functional. > That would take a massive redesign, something I'm not really wanting to do. I find it easy to use anyways. May not be pretty but it works better now than it ever has in terms of options listed correctly, options actually working as they supposed to, and the ability to save options. > Hmm, for some reason window dragging was on in my game. I don't > actually have a problem with the default window placement personally, > but I can imagine that there might be two or three 'popular' > placements. The options UI could let the user select from these > pre-canned profiles, rather than having to edit the RC file. > Definitely would want to do this if tactical/galactic become resizeable, will want a set of default window placements for set sizes, ie 500x500 tactical, 750x750, 1000x1000. As for the current state, about the only big thing I've seen is some people prefer playerlist under tactical, and some prefer it under galactic. I prefer it under tactical so I made it the default (I think it's the other way around in netrek xp mod version off playnetrek.org). > The client could do a check and if the screen resolution is less than > the size needed to show the window with decorations, turn them off, but > only in the case where there is not enough room. Alternately, the title > bar could be left on by default, but a 'fullscreen' option presented > which eliminates the decorations (and expands the window to the full > screen size.) This is a more standard paradigm for removing window > decorations, and may be less offensive to users. > I agree with Jimmy, less window border clutter, the better. As mentioned earlier, resizing windows and having everything scale is quite a large task, but a goal nonetheless. > Tip of the day are great. Another thing to consider is creating a help > file appropriate to the OS. Such a help file could include the newbie > guide as well. Here I am specifically thinking of a windows help file > or a web page which is launched in your default browser when you select > 'help.' > Ok, I think we actually do a good job on help. Hitting F1 brings up a windows help file covering the client basics. The metaserver window links to newbie guide, rec.games.netrek, netrek homepage, dogfight manual and netrek faq. The netrek xp documentation in the docs folder is also up to date. I'm really not sure what else to add help wise. > I don't know offhand, I'll have to go browse through the code - it's > been a while since I made a CreateWindowEx() call as I've been doing > embedded Linux programming for the past 5 years ;) > Patches welcome! The source is hosted on sourceforge as well. It can be found at: http://netrek.cvs.sourceforge.net/netrek/client/netrekxp/ > BTW, please take all of these suggestions in the best light. I'm not > disparaging your efforts or questioning your judgement. These are my > honest opinions on the subject. > Well thought out opinions are always welcome. Bill From williamb at its.caltech.edu Thu Jun 22 23:05:06 2006 From: williamb at its.caltech.edu (williamb at its.caltech.edu) Date: Thu, 22 Jun 2006 23:05:06 -0500 Subject: [netrek-dev] darcs patch: Xtkill bug fixes Message-ID: <200606230405.k5N456wZ001781@omen.digital-genesis.com> Thu Jun 22 23:00:57 CDT 2006 williamb at its.caltech.edu * Xtkill bug fixes * xtkill.c (Usage): Added 2 missing options (u and H) to options list. (main): Removed call to getshipdefaults(), as this data was already in memory, and it had the unintended consequence of erasing any modifications to ship values that were set in the sysdef file, forcing a sysdef reload every time xtkill was used. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 33424 bytes Desc: A darcs patch for your repository! Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060622/0b200f87/attachment-0001.bin From chronosws at comcast.net Thu Jun 22 23:23:17 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Thu, 22 Jun 2006 21:23:17 -0700 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> Message-ID: <449B6CB5.5000803@comcast.net> Zach wrote: >Hi Cliff, > >Wow great feedback. I'm curious what you think of making a full >fledged 3D client using a toolkit like OpenGL? The sophistication >could obviously get very high (ray tracing, more complex game physics, >full animation) etc... and this would place a higher requirement for a >good video card, CPU speed, RAM etc. Would a 3D client be too radical >a departure or could we do a hybrid client with mainly 2D and some 3D >effects throw in for fun? > > > I'm working with a friend on a redesign of the client from the ground up using Ogre. The primary idea behind using a 3D engine is to get scaling and rotations for free, as well as pre-built mechanisms for a variety of effects. Remember, I simply want to upgrade the presentation here, not alter the gameplay. 3D for 3D's sake is definitely a distraction ans should be avoided. As for system requirements, the amount of processing needed for Netrek even in 3D would be very small compared to most 3D games out there. This should not be a concern except for people who are running on horridly (5+ years) outdated hardware. >Zach > >_______________________________________________ >netrek-dev mailing list >netrek-dev at us.netrek.org >http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > From chronosws at comcast.net Thu Jun 22 23:40:02 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Thu, 22 Jun 2006 21:40:02 -0700 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> Message-ID: <449B70A2.1040602@comcast.net> William Balcerski wrote: >>Although this may seem like a scary idea, a reworked client could use >>one of the commonly-available, portable graphics engines, such as Ogre. >>In particular Ogre provides access to the full range of transformations >>available in 3D. While the game itself is not played in 3D, there are >>effects which could be implemented using such an engine (lighting, >>parallax starfields, etc.) >> >> >> >Gregory Hermann (spelling?) is working on netrek GL which uses Ogre I >believe, you can get it off the netrek sourceforge site. Not sure if it's >in a working state at the moment. But the screenshot of the 3d klingon >battlecruiser was quite nice. Of course, netrek is a 2d game so any 3d >stuff is gonna be..limited at best. Or just plain distracting. > > > Yes, I'd only use 3D in places where it makes sense. Mostly, for Netrek, I consider the Ogre engine useful for being able to set up nice rotations, scaling and compositing. The engine has a variety of useful tools for effects as well. >>The delay is inherent in the sound itself. The attack rate for the >>phaser sound is too low (i.e. the volume does not rise fast enough.) >>That is just my opinion though. >> >> >> >Well phaser sound is 1 second long and the phaser sound begins .01 seconds >into the sound file, reaching maximum volume at .15 seconds. Sound for >other people's phasers is shorter, at .6 seconds, with sound starting .03 >seconds into the file, reaching maximum volume at .09 seconds. Was it >other's phasers that you think was too delayed? I can chop .02 seconds >off the front. > > > I guess I expected a shorter rise to full volume. The mind is pretty good at detecting visual/audio synchronization and for some reason that particular sound bothers me. Just my opinion, I could be particularly sensitive to it :) >>occur.) The current 'rows of settings' with some being clickable, some >>being just informational does not fit any standard paradigm and looks >>clunky, even if it IS functional. >> >> >> >That would take a massive redesign, something I'm not really wanting to >do. I find it easy to use anyways. May not be pretty but it works better >now than it ever has in terms of options listed correctly, options >actually working as they supposed to, and the ability to save options. > > > I know it's a lot of work. This would be done in the context of a general client redesign. I don't think it's worth attempting to fix it within the current client. >>The client could do a check and if the screen resolution is less than >>the size needed to show the window with decorations, turn them off, but >>only in the case where there is not enough room. Alternately, the title >>bar could be left on by default, but a 'fullscreen' option presented >>which eliminates the decorations (and expands the window to the full >>screen size.) This is a more standard paradigm for removing window >>decorations, and may be less offensive to users. >> >> >> >I agree with Jimmy, less window border clutter, the better. As mentioned >earlier, resizing windows and having everything scale is quite a large >task, but a goal nonetheless. > > > Well, my reason is that the objective is to make the game approachable and sensible for new users. Users expect one of two user interfaces: windowed, where the game is displayed inside an OS-standard window; and fullscreen, where there is no border of any sort and the game takes up the whole screen. What Netrek does now is bizarre except to the initiated :) >>Tip of the day are great. Another thing to consider is creating a help >>file appropriate to the OS. Such a help file could include the newbie >>guide as well. Here I am specifically thinking of a windows help file >>or a web page which is launched in your default browser when you select >>'help.' >> >> >> >Ok, I think we actually do a good job on help. Hitting F1 brings up a >windows help file covering the client basics. The metaserver window links >to newbie guide, rec.games.netrek, netrek homepage, dogfight manual and >netrek faq. The netrek xp documentation in the docs folder is also up to >date. I'm really not sure what else to add help wise. > > > Oh, I didn't know that help was available from in game like that. My bad :) >>I don't know offhand, I'll have to go browse through the code - it's >>been a while since I made a CreateWindowEx() call as I've been doing >>embedded Linux programming for the past 5 years ;) >> >> >> >Patches welcome! The source is hosted on sourceforge as well. It can be >found at: >http://netrek.cvs.sourceforge.net/netrek/client/netrekxp/ > > > >>BTW, please take all of these suggestions in the best light. I'm not >>disparaging your efforts or questioning your judgement. These are my >>honest opinions on the subject. >> >> >> >Well thought out opinions are always welcome. >Bill > >_______________________________________________ >netrek-dev mailing list >netrek-dev at us.netrek.org >http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > From quozl at us.netrek.org Fri Jun 23 02:14:43 2006 From: quozl at us.netrek.org (James Cameron) Date: Fri, 23 Jun 2006 17:14:43 +1000 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B6CB5.5000803@comcast.net> References: <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> <449B6CB5.5000803@comcast.net> Message-ID: <20060623071443.GA15873@us.netrek.org> Even isometric view like Age of Empires would be an acceptable 3D style view. It's mechanically 2D, but *looks* 3D. http://www.cs.cmu.edu/afs/cs.cmu.edu/usr/jch/netrek/humor The post by Andrew Markiel shows an alternate way to present the game that may have some public appeal. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From netrek at gmail.com Fri Jun 23 02:21:12 2006 From: netrek at gmail.com (Zach) Date: Fri, 23 Jun 2006 03:21:12 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <449B6CB5.5000803@comcast.net> References: <20060622074122.GK11858@us.netrek.org> <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> <449B6CB5.5000803@comcast.net> Message-ID: On 6/23/06, Cliff Hudson wrote: > > As for system requirements, the amount of processing needed for Netrek > even in 3D would be very small compared to most 3D games out there. > This should not be a concern except for people who are running on > horridly (5+ years) outdated hardware. Such as my Dell laptop circa 2000! ;-) You working with Gregory Hermann? Zach From netrek at gmail.com Fri Jun 23 02:25:10 2006 From: netrek at gmail.com (Zach) Date: Fri, 23 Jun 2006 03:25:10 -0400 Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: <20060623071443.GA15873@us.netrek.org> References: <449AC517.6030902@comcast.net> <449B0329.3010103@comcast.net> <449B3357.1070207@comcast.net> <449B6CB5.5000803@comcast.net> <20060623071443.GA15873@us.netrek.org> Message-ID: On 6/23/06, James Cameron wrote: > Even isometric view like Age of Empires would be an acceptable 3D style > view. It's mechanically 2D, but *looks* 3D. Never played the game. Is it the sort of game view that Starcraft, Warcraft 2, Command & Conquer uses? Zach From jimmyhua73 at yahoo.com Sun Jun 25 05:23:20 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 25 Jun 2006 03:23:20 -0700 (PDT) Subject: [netrek-dev] robotd-war-declarations-fix.dpatch Message-ID: <20060625102320.63770.qmail@web35302.mail.mud.yahoo.com> There's a bug as to how Hadley's robot in newbie figures out who to declare war against. This patch is an attempt to fix that bug. However, I don't think it is completely fixed. And, this bug is not easy to test for (it rarely rears its ugly head). If anybody can think of ways to test if this is an improvement, or deprovement... I submit it as after reading the code, it makes sense to make this change. And also, it compiles fine. Seems to run fine too, but gotta think of ways to better test the various scenarios. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: robotd-war-declarations-fix.dpatch Type: application/octet-stream Size: 7508 bytes Desc: 4186159752-robotd-war-declarations-fix.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060625/5e9fa197/attachment.obj From jimmyhua73 at yahoo.com Sun Jun 25 10:48:01 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 25 Jun 2006 08:48:01 -0700 (PDT) Subject: [netrek-dev] robotd-war-declarations-fix.dpatch Message-ID: <20060625154801.12809.qmail@web35311.mail.mud.yahoo.com> Well, after a bit of testing and debugging, this piece of code just refuses to work the way I expected it to. Ignore this patch. I guess I have to figure out what doesn't work on it. Jimmy --- Jimmy Huang wrote: > There's a bug as to how Hadley's robot in newbie > figures out who to declare war against. > > This patch is an attempt to fix that bug. > > However, I don't think it is completely fixed. And, > this bug is not easy to test for (it rarely rears > its > ugly head). If anybody can think of ways to test if > this is an improvement, or deprovement... > > I submit it as after reading the code, it makes > sense > to make this change. And also, it compiles fine. > Seems to run fine too, but gotta think of ways to > better test the various scenarios. > > Jimmy From xyzzy at speakeasy.org Sun Jun 25 18:39:25 2006 From: xyzzy at speakeasy.org (Trent Piepho) Date: Sun, 25 Jun 2006 16:39:25 -0700 (PDT) Subject: [netrek-dev] robotd-war-declarations-fix.dpatch In-Reply-To: <20060625102320.63770.qmail@web35302.mail.mud.yahoo.com> References: <20060625102320.63770.qmail@web35302.mail.mud.yahoo.com> Message-ID: On Sun, 25 Jun 2006, Jimmy Huang wrote: > I submit it as after reading the code, it makes sense > to make this change. And also, it compiles fine. > Seems to run fine too, but gotta think of ways to > better test the various scenarios. You sure declaring war against multiple teams is a good idea? It seems like the bot is designed to fight against one team. Will it try to refuel on 3rd space planets that are now hostile? Will it try to take 3rd space? From jimmyhua73 at yahoo.com Sun Jun 25 22:29:55 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Sun, 25 Jun 2006 20:29:55 -0700 (PDT) Subject: [netrek-dev] robotd-war-declarations-fix.dpatch In-Reply-To: Message-ID: <20060626032955.38708.qmail@web35301.mail.mud.yahoo.com> --- Trent Piepho wrote: > You sure declaring war against multiple teams is a > good idea? It seems like > the bot is designed to fight against one team. Will > it try to refuel on 3rd > space planets that are now hostile? Will it try to > take 3rd space? As far as what would the robots do. I dunno. I know there is code to prevent it from refueling on hostile planets in general. It will even try to declare peace if possible. I am more thinking in terms of what a human player should do in terms of war declarations in various scenarious. The scenario that the bots fail horribly on, is during timercide, or when they get forced to join a different team. They don't check their war declarations and declare war as necessary for some reason. They only do their war declarations when they first join in, and that's it! Also, they won't take back planets that were taken by a 3rd team scummer. Declaring war on this 3rd team would be a start. But you're right, that current patch wouldn't fix anything. Furthermore, there are logic bugs in that patch in the way it is coded. Still working on it. Jimmy From quozl at us.netrek.org Mon Jun 26 02:58:59 2006 From: quozl at us.netrek.org (James Cameron) Date: Mon, 26 Jun 2006 17:58:59 +1000 Subject: [netrek-dev] robotd-war-declarations-fix.dpatch In-Reply-To: <20060626032955.38708.qmail@web35301.mail.mud.yahoo.com> References: <20060626032955.38708.qmail@web35301.mail.mud.yahoo.com> Message-ID: <20060626075859.GA13977@us.netrek.org> On Sun, Jun 25, 2006 at 08:29:55PM -0700, Jimmy Huang wrote: > The scenario that the bots fail horribly on, is during > timercide, or when they get forced to join a different > team. Is it sufficient to just disable the timercide feature? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From niclas at acc.umu.se Mon Jun 26 04:54:03 2006 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Mon, 26 Jun 2006 11:54:03 +0200 (MEST) Subject: [netrek-dev] Features I'd like to be added to server (long) In-Reply-To: References: <20060606012903.GA17953@orion.netrek.org> <20060622051856.GH11858@us.netrek.org> Message-ID: On Wed, 21 Jun 2006, William Balcerski wrote: >> 2004-05 to 2006-05 on continuum ... for the small amount of time that >> RSA was actually enabled ... >> >> > > So out of roughly 225000 connections, 8000-9000 or so use clients without > 32 position bitmaps, hence my original statement of 95+% proved to be > quite accurate! Looks like you missed this line: 13380 Client: Client Of Win. Arch: Intel/Win32. Player --Niclas From jimmyhua73 at yahoo.com Wed Jun 28 02:52:19 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Wed, 28 Jun 2006 00:52:19 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch Message-ID: <20060628075219.74450.qmail@web35314.mail.mud.yahoo.com> Hi All, Well here's the patch I wanted to write the first time. The bug only appears when you run Hadley's bot off a standard queue, where you can have players on all sorts of different teams before t-mode starts. And when you get kicked off your own team to join someone else during a timercide. Heavily tested. Works okay. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: robotd-war-decs-bugfix.dpatch Type: application/octet-stream Size: 10612 bytes Desc: 3512504885-robotd-war-decs-bugfix.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060628/8e0f297b/attachment.obj From quozl at us.netrek.org Wed Jun 28 03:30:32 2006 From: quozl at us.netrek.org (James Cameron) Date: Wed, 28 Jun 2006 18:30:32 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060628075219.74450.qmail@web35314.mail.mud.yahoo.com> References: <20060628075219.74450.qmail@web35314.mail.mud.yahoo.com> Message-ID: <20060628083032.GA25199@us.netrek.org> Some of the changes where you've added code show a style that isn't consistent with the existing style. Are you sure about those changes? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From jimmyhua73 at yahoo.com Wed Jun 28 07:42:30 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Wed, 28 Jun 2006 05:42:30 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060628083032.GA25199@us.netrek.org> Message-ID: <20060628124230.95456.qmail@web35314.mail.mud.yahoo.com> You mean like: main.c line 437, where I use space-tab combo for the indent, and the rest of the surrounding code is spaces only? I personally like spaces only, but someone told me space-tab combo was better. When editing the code in emacs, I can't see the difference, unless I move my cursor around and around seeing it jump more than 1 space.. I never realized it was different until you pointed it out, and I started poking around. A cursory glance, and everything else seems to line up fine. I did a darcs get, and a apply my own patch. Then a quick test. Seems to work fine. If anybody has any ideas on how I can "see the tabs" so I can follow the code style in emacs. It'd be greatly appreciated. Jimmy --- James Cameron wrote: > Some of the changes where you've added code show a > style that isn't > consistent with the existing style. Are you sure > about those changes? > > -- > James Cameron mailto:quozl at us.netrek.org > http://quozl.netrek.org/ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From jimmyhua73 at yahoo.com Wed Jun 28 07:53:43 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Wed, 28 Jun 2006 05:53:43 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060628124230.95456.qmail@web35314.mail.mud.yahoo.com> Message-ID: <20060628125343.99977.qmail@web35314.mail.mud.yahoo.com> --- Jimmy Huang wrote: > If anybody has any ideas on how I can "see the tabs" > so I can follow the code style in emacs. It'd be > greatly appreciated. Or even suggest some *other* editor available on Debian Linux Sarge with gnome desktop. I use emacs as it's the only thing I know how to use, and it's pretty easy to use. Jimmy From chronosws at comcast.net Wed Jun 28 10:41:45 2006 From: chronosws at comcast.net (Cliff Hudson) Date: Wed, 28 Jun 2006 08:41:45 -0700 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060628125343.99977.qmail@web35314.mail.mud.yahoo.com> References: <20060628125343.99977.qmail@web35314.mail.mud.yahoo.com> Message-ID: <44A2A339.8080403@comcast.net> I don't know if this project follows the same coding standards as we do at work, but it is customary to maintain the coding style of the file in which you are adding your code unless you are rewriting the whole file (or reformatting it.) BTW, I don't recommend going around reformatting files without the owner's (or in this case group's) permission, unless you enjoy being yelled at :) Jimmy Huang wrote: >--- Jimmy Huang wrote: > > >>If anybody has any ideas on how I can "see the tabs" >>so I can follow the code style in emacs. It'd be >>greatly appreciated. >> >> > >Or even suggest some *other* editor available on >Debian Linux Sarge with gnome desktop. I use emacs as >it's the only thing I know how to use, and it's pretty >easy to use. > >Jimmy > > >_______________________________________________ >netrek-dev mailing list >netrek-dev at us.netrek.org >http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > > From quozl at us.netrek.org Thu Jun 29 00:18:25 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 29 Jun 2006 15:18:25 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060628124230.95456.qmail@web35314.mail.mud.yahoo.com> References: <20060628083032.GA25199@us.netrek.org> <20060628124230.95456.qmail@web35314.mail.mud.yahoo.com> Message-ID: <20060629051825.GA14880@us.netrek.org> On Wed, Jun 28, 2006 at 05:42:30AM -0700, Jimmy Huang wrote: > main.c line 437, where I use space-tab combo for the > indent, and the rest of the surrounding code is spaces > only? That's one of many examples. I shouldn't have to point them all out, because you should have examined the diff closely yourself. The patch acceptance policy that I follow is in the file STYLE. But since you asked, I will point them out ... I'll review your patch below ... which makes this a long mail. > I personally like spaces only, but someone told me space-tab combo > was better. Regardless of what is better, you must follow the style in the file you are editing. > When editing the code in emacs, I can't see the difference, unless I > move my cursor around and around seeing it jump more than 1 space.. That's easy to fix. Customise your emacs. For instance, have a look at these methods on the Emacs Wiki ... http://www.emacswiki.org/cgi-bin/wiki/ShowWhiteSpace Especially note the "Show Tabs Using a Face (Color)" section, which I've just tried on my emacs and it works great. If you try this, make sure you add a hook section for c-mode. > A cursory glance, and everything else seems to line up > fine. It doesn't line up, when the patch is displayed ... therefore I presume you didn't review the patch bands yourself. Be honest ... did you? Check every line of a patch you are proposing. It shouldn't be difficult, and it's a great way to spot problems. -- Reviewing your patch ... (while it is possible to review it in the darcs mail form, and some of the problems are obvious even there, here it is changed to unified diff format, by doing a "darcs get" of my repo, "darcs apply" of your patch, then "darcs diff -u --last=1" to generate the diff, then quoted into my mail buffer ...) You wrote: > Wed Jun 28 18:37:21 EST 2006 jimmyhua73 at yahoo.com > * robotd-war-decs-bugfix.dpatch Priority: high. Problem: the patch name doesn't meet the STYLE requirements, in that it is not in user-visible NEWS style. See "Darcs - Patch Name and Long Comment" in the STYLE file. Threat: makes it harder for us to generate the NEWS file, makes it harder for people to understand the purpose of the patch by reference to just the patch name. > * robotd/data.c fixed spelling on comments. Priority: low. Problem: the long comment doesn't follow ChangeLog standards, because the colon is missing, and function names are missing. See "Darcs - Patch Name and Long Comment" in the STYLE file. Threat: makes it harder for us to find a cause of a later problem. (otherwise the long comment is fantastic, well done). > diff -rN -u old-netrek-server/Vanilla/robotd/data.c new-netrek-server/Vanilla/robotd/data.c > --- old-netrek-server/Vanilla/robotd/data.c 2006-06-29 14:28:12.000000000 +1000 > +++ new-netrek-server/Vanilla/robotd/data.c 2006-06-29 14:28:12.000000000 +1000 > @@ -45,7 +45,7 @@ > int override = 0; > int doreserved = 0; > int lastm; > -int delay; /* delay for decaring war */ > +int delay; /* delay for declaring war */ > int rdelay; /* delay for refitting */ > int mapmode = 1; > int namemode = 1; Fine. > diff -rN -u old-netrek-server/Vanilla/robotd/decide.c new-netrek-server/Vanilla/robotd/decide.c > --- old-netrek-server/Vanilla/robotd/decide.c 2006-06-29 14:28:12.000000000 +1000 > +++ new-netrek-server/Vanilla/robotd/decide.c 2006-06-29 14:28:12.000000000 +1000 > @@ -34,6 +34,7 @@ > if(!inl){ > if((_state.warteam < 0 || _state.total_wenemies == 0) && > _state.total_enemies > 0){ > + /* beginning of game, no enemies */ > declare_intents(); > return; > } Fine. > @@ -41,6 +42,7 @@ > else if(status->tourn){ > if((_state.warteam < 0 || _state.total_wenemies == 0) && > _state.total_enemies > 0){ > + /* beginning of game, no enemies */ > declare_intents(); > return; > } Fine. > diff -rN -u old-netrek-server/Vanilla/robotd/main.c new-netrek-server/Vanilla/robotd/main.c > --- old-netrek-server/Vanilla/robotd/main.c 2006-06-29 14:28:12.000000000 +1000 > +++ new-netrek-server/Vanilla/robotd/main.c 2006-06-29 14:28:12.000000000 +1000 > @@ -49,6 +49,7 @@ > char *defaultsFile = NULL; > register i; > int rwatch=0; > + static int switchedteams=0; > char password[64]; > int timer2 = 0, tryudp=1; > char **_argv = argv; Priority: medium. Problem: change of indenting style from existing style in function. The lines above and below the added line use tabs for indenting. The new line does not. So when it is displayed in a patch it shows up as a change of style. Threat: makes it harder to review the patch. > @@ -400,6 +401,7 @@ > > mprintf("team ...\n"); > if(!teamRequest(team, s_type)){ > + switchedteams = 1; > mprintf("team or ship rejected.\n"); > > /* if base destroyed */ Fine. > @@ -412,8 +414,9 @@ > > showteams(); > do { > - if(teamRequest(team, s_type)) > + if(teamRequest(team, s_type)) { > break; > + } > if(read_stdin) > process_stdin(); > readFromServer(1); Fine. > @@ -431,6 +434,7 @@ > timer2 = 0; > _state.team = team; > if (!teamRequest(team, s_type)){ > + switchedteams=1; > mfprintf(stderr, "team or ship rejected.\n"); > showteams(); > } Fine. Although this also looks wrong during patch review, since "switchedteams" starts in a different column to the mfprintf call. This is because the mfprintf line uses spaces, and the switchedteams line uses tabs. The added line is consistent with surrounding code, but it looks like a change of style. It may have been more correct to fix the indenting of the mfprintf and showteams lines. > @@ -459,6 +463,11 @@ > sendUdpReq(COMM_UDP); > } > > + if (switchedteams) { > + switchedteams=0; > + declare_intents(); > + } > + > input(); > } > Fine. > diff -rN -u old-netrek-server/Vanilla/robotd/robot.c new-netrek-server/Vanilla/robotd/robot.c > --- old-netrek-server/Vanilla/robotd/robot.c 2006-06-29 14:28:12.000000000 +1000 > +++ new-netrek-server/Vanilla/robotd/robot.c 2006-06-29 14:28:12.000000000 +1000 > @@ -2002,6 +2002,9 @@ > strcpy(_state.ignore_e, ignore_e); > > bzero(&_timers, sizeof(_timers)); > + /* This declare_intents() only gets run when you are dead > + or when someone sends a reset command to the robot. > + If you are dead, declare_intents does nothing */ > declare_intents(); > req_cloak_off("reset"); > return 1; Priority: medium. Problem: new lines are using a different indentation style, specifically the first of the added lines uses spaces and the second two use tabs. > @@ -2065,9 +2068,7 @@ > > sendUpdatePacket((int)(_state.timer_delay_ms * 100000.)); > init_comm(); > - /* > - declare_intents(); > - */ > + > } > > ignore_edefault(s) Fine. Although you've added a blank line ... I would have only removed the lines, not added a blank one. If you hadn't reviewed your change you probably would not have noticed. (The point again being that you should review your change, and you should make the change as small as it can be, provided it remains consistent. When reviewers see this kind of change, they can't help but think you didn't review it.) > diff -rN -u old-netrek-server/Vanilla/robotd/update_players.c new-netrek-server/Vanilla/robotd/update_players.c > --- old-netrek-server/Vanilla/robotd/update_players.c 2006-06-29 14:28:12.000000000 +1000 > +++ new-netrek-server/Vanilla/robotd/update_players.c 2006-06-29 14:28:12.000000000 +1000 > @@ -1024,13 +1024,25 @@ > } > > /* war & peace. Done initially */ > -/* BUGS */ > > +/* Fixed so, when you first enter the game 10 seconds in, the robot > + will declare war on the top 2 teams with most players. > + If the robot is a 3rd team scummer, it works out quite nicely. > + > + Will also declare war correctly when forced to join a different team, > + say during timercide. During Timercide, winners keep their old > + war declarations (which is the right thing to do), as they don't > + get forced to join a different team. > + > + Doesn't work when you lose t-mode and people join back in > + on different teams, as the function to check for this condition doesn't > + exist, yet. */ > declare_intents() > { > register i; > register struct player *j; > - int teams[16], maxt = 0; > + int teams[16], maxt=0, maxcount=0; > + int maxt2=0, maxcount2=0; > int newhostile, pl=0; > extern char *team_to_string(); > Priority: medium. Problem: new line added changes indentation style (maxt2 and maxcount2). You've used spaces instead of tabs. Oh, make sure you use a monospaced font for reading this mail, otherwise you won't see it the way I do ... which is that the "t" of teams[16] lines up with the "=" of "maxt2=0". > @@ -1053,21 +1065,36 @@ > pl++; > } > > + if (!pl) return; > + > if(pl){ > - for(i=1; i< 9; i *= 2) > - if(teams[i] > maxt) > - maxt = i; > + for(i=1; i< 9; i *= 2) { > + if(teams[i] > maxcount) { > + maxt = i; > + maxcount = teams[i]; > + } > + } Priority: medium. Problem: new "if" inside the "for" isn't indented properly? Actually, it is, but only because tabs are used instead of spaces. The "for" uses spaces. Your new code uses tabs. So it looks wrong. So actually it's a change of indenting style again. > mprintf("max team = %s\n", team_to_string(maxt)); > + > + for(i=1; i< 9; i *= 2) { > + if( (teams[i] > maxcount2) && (i != maxt) ) { > + maxt2 = i; > + maxcount2 = teams[i]; > + } > + } And again. > + mprintf("max team2 = %s\n", team_to_string(maxt2)); > + > + And two blank lines? > } > - /* > - else > - maxt = -1; > - */ > > /* peace */ > for(i=1; i< 9; i *= 2){ > if(i == maxt) continue; > - if((i & me->p_hostile) && !(i & me->p_swar)){ > + > + if (i==maxt2) continue; > + > + /* Is hostile to AND not at war with */ > + if((i & me->p_hostile) && !(i & me->p_swar)) { > mprintf("declaring peace with %s\n", team_to_string(i)); > newhostile ^= i; > } And again. > @@ -1075,12 +1102,21 @@ > _state.warteam = maxt; > > /* war */ > - if(maxt != -1){ > - if(!((maxt & me->p_swar) || (maxt & me->p_hostile))){ > + if(maxt != 0 ) { > + if(!((maxt & me->p_swar) && !(maxt & me->p_hostile))) { > mprintf("declare war with %s\n", team_to_string(maxt)); > - newhostile ^= maxt; > + newhostile |= maxt; > } > } And again, the mprintf looks improperly indented. Oh, and an extra space after "maxt != 0" > + > + /* being hostile to more teams is better than less teams */ > + if(maxt2 != 0 ) { > + if(!((maxt2 & me->p_swar) && !(maxt2 & me->p_hostile))) { > + mprintf("declare war with %s\n", team_to_string(maxt2)); > + newhostile |= maxt2; > + } > + } > + > if(newhostile != me->p_hostile) > sendWarReq(newhostile); > } > This change is what really caused me to look harder at your patch in the first place ... only because there's an extra space after the conditional expression in the if. -- Finally something about technical review ... when I got your patch I had the choice of either fixing the problems you had with it, accepting it as is, or rejecting it. A review such as the above is meant to find the problems, but isn't meant to tell you how to fix them. The review is intended to be positive, so that you can do better next time. This is learned behaviour for me, from being part of a software engineering group that valued quality. We had ISO900x certification and some really cool procedures to increase quality of our code. A technical review would normally happen in a conference room with paper copies of the code, or nowadays with a shared editor with multiple laptops and a projector or two ... and again, we aren't allowed to fix the code, only to highlight the problems. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/dadb0a75/attachment.pgp From quozl at us.netrek.org Thu Jun 29 00:19:38 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 29 Jun 2006 15:19:38 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <44A2A339.8080403@comcast.net> References: <20060628125343.99977.qmail@web35314.mail.mud.yahoo.com> <44A2A339.8080403@comcast.net> Message-ID: <20060629051938.GB14880@us.netrek.org> On Wed, Jun 28, 2006 at 08:41:45AM -0700, Cliff Hudson wrote: > I don't know if this project follows the same coding standards as we do > at work, but it is customary to maintain the coding style of the file in > which you are adding your code unless you are rewriting the whole file > (or reformatting it.) Yes, that's basically what STYLE says. http://www.netrek.org/repos/netrek-server/Vanilla/STYLE -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From jimmyhua73 at yahoo.com Thu Jun 29 02:14:12 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 29 Jun 2006 00:14:12 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060629051825.GA14880@us.netrek.org> Message-ID: <20060629071412.64485.qmail@web35315.mail.mud.yahoo.com> Hey James, Thank you for being so thorough and detailed. I now understand now how it looks different, even though when I look at the actual source code file it looked consistent to me! I really appreciate the pointer on emacs! This will help me alot. Super constructive! So I guess darcs treats tabs/spaces different on purpose so it looks non-lined up when the "style" changes! Neat! And here, when I first saw this phenomena, I thought it was a bug!!!! I'll get right on fixing my patch, so it is more consistent, and also to fixing my emacs so I can see the style changes without having to depend on darcs. I'll also know when it looks different in darcs, it is referring to spaces/indent changes... About, the one space I added: I actually added that in on purpose. I like to add blank spaces around certain code. Sort of a pause. As I am a bit dislexic, I depend on the blank spaces way more than I do the indent. I've never written code for someone else to see before. So this is an experience in of in itself. I'll get on fixing the patch for better readability and consistency. Please don't apply patch, so that I can send another one that is more consistent. Thanks, Jimmy --- James Cameron wrote: > Regardless of what is better, you must follow the > style in the file you > are editing. > That's easy to fix. Customise your emacs. For > instance, have a look at > these methods on the Emacs Wiki ... > > http://www.emacswiki.org/cgi-bin/wiki/ShowWhiteSpace > > Especially note the "Show Tabs Using a Face (Color)" > section, which I've > just tried on my emacs and it works great. If you > try this, make sure > you add a hook section for c-mode. Again, thanks for this tip. I'm going to try it out. > It doesn't line up, when the patch is displayed ... > therefore I presume > you didn't review the patch bands yourself. Be > honest ... did you? I only looked at it when your e-mail popped out saying it wasn't consistent ;-P. > Check every line of a patch you are proposing. It > shouldn't be > difficult, and it's a great way to spot problems. I'll look at the patch file too, in addition to the original source code. > Priority: high. > > Problem: the patch name doesn't meet the STYLE > requirements, in that it > is not in user-visible NEWS style. See "Darcs - > Patch Name and Long > Comment" in the STYLE file. Okay, I'm not sure what this means. But I'll read the STYLE file and figure it out. I'll also keep to make sure the function names are mentioned in the files modifiles. Jimmy From quozl at us.netrek.org Thu Jun 29 06:35:55 2006 From: quozl at us.netrek.org (James Cameron) Date: Thu, 29 Jun 2006 21:35:55 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060629071412.64485.qmail@web35315.mail.mud.yahoo.com> References: <20060629051825.GA14880@us.netrek.org> <20060629071412.64485.qmail@web35315.mail.mud.yahoo.com> Message-ID: <20060629113555.GD23493@us.netrek.org> Perhaps someone has the time to inject this thread into the Wiki? ;-) On Thu, Jun 29, 2006 at 12:14:12AM -0700, Jimmy Huang wrote: > Thank you for being so thorough and detailed. Normally people tell me I think too much. ;-) > I really appreciate the pointer on emacs! This will > help me alot. There are plenty of other ways to do similar things in emacs, do a search for "tabs" in the Emacs Wiki. You may find other useful tricks. Another trick that I use is to use "darcs diff -u > darcs.diff" and then open darcs.diff in Emacs. This opens it in diff mode, and you can step through each change, visiting the exact line of each source file changed. You can also select "Apply diff with Ediff" (A) ... Ediff is fantastic, shows you more detail about a change than just the diff. It's worth learning how to use. > So I guess darcs treats tabs/spaces different on purpose so it looks > non-lined up when the "style" changes! No, not really. Or rather your explanation is insufficient. Darcs is merely observing changes to the bytes in the source file. A source file is a stream of bytes. It is our use of tabs in the file that creates the issue. If we did not use tabs, there would be no problem. But we have to use tabs because some of the files already use tabs. Also, you might not be understanding what causes things to look different ... so I shall try to explain. Imagine a line consisting of a tab followed by an asterisk. The following line below contains only that: * A file containing this can be created on UNIX systems by typing a command: $ echo -e "\t*" > file Using the od(1) command in Linux, you can see various ways in which this stream of bytes appears: 1. in hexadecimal bytes, the 09 is the tab, the 2a is the asterisk, and the 0a is the newline: $ od -t x1 file 0000000 09 2a 0a 2. in ASCII characters or backslash escapes, the \t is the tab, the * is the asterisk, and the \n is the newline: $ od -c file 0000000 \t * \n 3. in named characters, the ht is the tab, the * is the asterisk, and the nl is the newline: $ od -a file 0000000 ht * nl (See also man ascii, man od). Now, imagine that this line is the subject of a patch ... that is, some program like diff or darcs is generating a patch file to show how to change this line from one version of a file to another. Imagine that the person making the change adds a space and the word hello to the end of the line, so that it becomes tab, asterisk, space, hello ... like so: * hello (which od(1) would show as 09 2a 20 68 65 6c 6c 6f 0a) All very well and good, but as it is part of a diff generated patch, it will have a "-" (what was there) and "+" (what is to be there) section, and those have a trailing space. So the patch band generated by diff will look like this: --- file.orig 2006-06-29 21:26:33.000000000 +1000 +++ file 2006-06-29 21:26:40.000000000 +1000 @@ -1 +1 @@ - * + * hello (the last two lines are 2d 20 09 2a 0a 2b 20 09 2a 20 68 65 6c 6c 6f 0a) That second line is plus, space, tab, asterisk, space, hello. But because a tab lines up to the next 8-column multiple, the asterisk does not seem to move. Provided you are looking at this on a character cell display that properly indents tabs to the next 8-column multiple! xterm, konsole, mutt, and emacs all do this for me. Now imagine that in making the change, you changed the tab to eight spaces. Here is how it would look: --- file.orig 2006-06-29 21:26:33.000000000 +1000 +++ file 2006-06-29 21:28:38.000000000 +1000 @@ -1 +1 @@ - * + * hello You see? There is a clear misalignment. The first line is minus, space, tab, asterisk, but the second line is plus, space, eight spaces, asterisk, space, hello. The eight spaces don't have the same visual effect as the tab, *only* because this is part of a patch. The "+" and space added by the patch causes the difference to be more visible. > I'll also know when it looks different in darcs, it is > referring to spaces/indent changes... If you think it might be spaces or indent changes, one of the ways you can prove it is do a diff with --ignore-all-space (or -w) between a copy of the repo before your patch and the repo that has your patch. Darcs doesn't let me use -w on diff, but that doesn't stop me using diff myself. > I've never written code for someone else to see > before. So this is an experience in of in itself. Writing for others changes your code ... giving it a higher value. It's fantastic ... helping you to become better at it. > Please don't apply patch, so that I can send another one that is more > consistent. Agreed. > > Problem: the patch name doesn't meet the STYLE > > requirements, in that it > > is not in user-visible NEWS style. See "Darcs - > > Patch Name and Long > > Comment" in the STYLE file. > > Okay, I'm not sure what this means. But I'll read the > STYLE file and figure it out. I'll put it another way just in case. When you type "darcs record" you are prompted for the patch name. We want you to use a name that matches what you would type into the NEWS file if you were the maintainer of the NEWS file. We will be using the patch name later to build the NEWS file for the next release. This also makes it very clear to anyone reviewing your patch exactly what it does as far as the user (or player) is concerned. Read the STYLE file. If there is anything in there you don't understand, then that is a program source code fault ... in the English language ... so I'll be happy to fix it. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/e4db1fae/attachment-0001.pgp From jimmyhua73 at yahoo.com Thu Jun 29 10:53:45 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 29 Jun 2006 08:53:45 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060629113555.GD23493@us.netrek.org> Message-ID: <20060629155345.57222.qmail@web35306.mail.mud.yahoo.com> --- James Cameron wrote: > --- file.orig 2006-06-29 21:26:33.000000000 +1000 > +++ file 2006-06-29 21:28:38.000000000 +1000 > @@ -1 +1 @@ > - * > + * hello > > You see? There is a clear misalignment. The first > line is minus, > space, tab, asterisk, but the second line is plus, > space, eight spaces, > asterisk, space, hello. The eight spaces don't have > the same visual > effect as the tab, *only* because this is part of a > patch. Tabs are aligned to the nearest 8 space cell while 8 spaces are not aligned! Gotcha! This has been the best explanation of it yet. > Writing for others changes your code ... giving it a > higher value. It's > fantastic ... helping you to become better at it. Yeah, when I debugged the bots the first time on my own. I definitely didn't get as far as where we are today. I spent the last few hours trying to get emacs to "show me the tabs!" I finally went with the first solution from the webpage quozl referred me to with the lisp program. Took a while to get it to work. So if anybody wants me to detail it out. I'd be more than happy to. Also found out that emacs won't let me insert tabs in *other* locations! Pretty annoying. Had to use vi some of the time to tidy up the code. Say you have this: int counter=0; The first tab is fine, but emacs won't let you add in the 2nd or 3rd tab.... Emacs wants you to use spaces to align everything up afterwards.... Hmm... Jimmy From jimmyhua73 at yahoo.com Thu Jun 29 10:57:48 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 29 Jun 2006 08:57:48 -0700 (PDT) Subject: [netrek-dev] newbie-robots-now-declare-war-properly-in-pickup-games.dpatch Message-ID: <20060629155748.59844.qmail@web35303.mail.mud.yahoo.com> Hey James, Hopefully this will meet all the standards of netrek coding. I tested it for 2-3 hours the other day. And although there's some room for improvement, I am happy with the changes I made. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: newbie-robots-now-declare-war-properly-in-regular-pickup-games.dpatch Type: application/octet-stream Size: 11658 bytes Desc: 2101502542-newbie-robots-now-declare-war-properly-in-regular-pickup-games.dpatch Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/2849b1cf/attachment.obj From narcis at luky.nl Thu Jun 29 12:33:30 2006 From: narcis at luky.nl (Chris en Judith) Date: Thu, 29 Jun 2006 19:33:30 +0200 Subject: [netrek-dev] Graphics NetrekXP2006 In-Reply-To: References: Message-ID: Hi, i downloaded netrek XP 2006 and found the graphics quite nice! i think Patrick was credited for it. I would like to use the same graphics for the new Mac client, but preferably with permission of the author :-) can he be reached through this list? regards Chris From narcis at luky.nl Thu Jun 29 14:13:13 2006 From: narcis at luky.nl (Chris en Judith) Date: Thu, 29 Jun 2006 21:13:13 +0200 Subject: [netrek-dev] Graphics NetrekXP2006 In-Reply-To: References: Message-ID: <091D6584-FE92-4E23-A72F-2194DDA8C09A@luky.nl> Hi, i downloaded netrek XP 2006 and found the graphics quite nice! i think Patrick was credited for it. I would like to use the same graphics for the new Mac client, but preferably with permission of the author :-) can he be reached through this list? regards Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: chris.png Type: application/applefile Size: 70494 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/4f18ec2b/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: chris.png Type: image/png Size: 23932 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/4f18ec2b/attachment-0001.png -------------- next part -------------- Chris Lukassen chris at luky.nl From williamb at its.caltech.edu Thu Jun 29 17:04:42 2006 From: williamb at its.caltech.edu (William Balcerski) Date: Thu, 29 Jun 2006 15:04:42 -0700 (PDT) Subject: [netrek-dev] Graphics NetrekXP2006 In-Reply-To: References: Message-ID: Hi Chris, the graphics were made by Pascal Gagnon, he was on the list, not sure if he still is, he said a few weeks ago that he had to go offline for 6 months. I know he wouldn't mind if you used them, I think he released them with some license that allows open use (Jerub knows more on this). His email address *was* dopleganger75 AT gmail.com. Use @ instead of AT. You can take the bitmaps straight out of the xp 2006 client and resize them to your needs. I'm the author of that client, and I took his original 1000x1000 drawings and put them in 80x80 (ships) or 120x120 (planets) pixel size. In the case of planets, I created the different race colors through colorizing the bitmaps in my pixel editor. In the case of the one rotating planet (unknown planet), I used GIMP's create a rotating planet function. I don't have the original 1000x1000s if you wanted those, though. I hope he comes back some day, still need some more art for rotating planets (need square shaped planets to input into the GIMP function). Bill On Thu, 29 Jun 2006, Chris en Judith wrote: > Hi, > > i downloaded netrek XP 2006 and found the graphics quite nice! i > think Patrick was credited for it. I would like to use > the same graphics for the new Mac client, but preferably with > permission of the author :-) can he be reached through this list? > > regards > > Chris > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > From quozl at us.netrek.org Thu Jun 29 19:10:27 2006 From: quozl at us.netrek.org (James Cameron) Date: Fri, 30 Jun 2006 10:10:27 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060629155345.57222.qmail@web35306.mail.mud.yahoo.com> References: <20060629113555.GD23493@us.netrek.org> <20060629155345.57222.qmail@web35306.mail.mud.yahoo.com> Message-ID: <20060630001027.GB7745@us.netrek.org> On Thu, Jun 29, 2006 at 08:53:45AM -0700, Jimmy Huang wrote: > Tabs are aligned to the nearest 8 space cell ... No, not the nearest, the next. A tab will always cause movement, and the movement will range from one to eight spaces in length. The word nearest can mean the same location, or one to the left. > I spent the last few hours trying to get emacs to > "show me the tabs!" I finally went with the first > solution from the webpage quozl referred me to with > the lisp program. Took a while to get it to work. So > if anybody wants me to detail it out. I'd be more than > happy to. If there's something wrong with the Emacs Wiki page, you should add a neutral and factual observation to it. You should be able to edit the pages in that Wiki, though I'm not sure if you need to register first. By neutral and factual, I mean don't just say "didn't work", instead say "when I tried this method with emacs 21 on linux the result was that the tabs were not highlighted." The Emacs Wiki is probably a more appropriate forum than this mailing list for discussing the Emacs Wiki. > Also found out that emacs won't let me insert tabs in > *other* locations! Pretty annoying. Had to use vi some > of the time to tidy up the code. You should be able to add a tab manually, using Control/Q then tab. If you just try a tab by itself, then a special indentation function is run if emacs is in c-mode. That's a gross simplification for the purpose of illustration. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Thu Jun 29 20:29:01 2006 From: quozl at us.netrek.org (James Cameron) Date: Fri, 30 Jun 2006 11:29:01 +1000 Subject: [netrek-dev] newbie-robots-now-declare-war-properly-in-pickup-games.dpatch In-Reply-To: <20060629155748.59844.qmail@web35303.mail.mud.yahoo.com> References: <20060629155748.59844.qmail@web35303.mail.mud.yahoo.com> Message-ID: <20060630012901.GD7745@us.netrek.org> On Thu, Jun 29, 2006 at 08:57:48AM -0700, Jimmy Huang wrote: > Hopefully this will meet all the standards of netrek > coding. Attached please find my revision of your changes. I've pushed this through to my repository. If you get some spare time, compare your patch to mine to see what I did. > I tested it for 2-3 hours the other day. And although > there's some room for improvement, I am happy with the > changes I made. It helps to describe the testing you did in the long comment, as that would help others to review the change and verify your testing was appropriate. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- New patches: [Newbie robots now declare war properly in pickup games quozl at us.netrek.org**20060630011431 Derived from Jimmy Huang's patch of the same name. * robotd/data.c: fixed comment misspelling in int delay. delay for declaring war. * robotd/decide.c (decide): added some comments to help me follow the code better * robotd/main.c (main): fixed up indentation of variable declarations. Added switchedteams variable. Modified main() function so that when a team switch occurs, declare_intents() gets called after choosing a new ship. * robotd/robot.c (reset_r_info): added some commentary on the declare_intents() call, which only gets something done only if someone sends a reset command to the robot. * robotd/robot.c (send_initial): removed commented code of declare_intents(). This was a bug workaround, robot sends a dummy packet so it doesn't get ghostbusted. Doesn't seem needed anymore. * robotd/update_players.c (declare_intents): added commentary on how this function is supposed to work. Function will now properly declare war on the 2 teams with the most players that isn't the same team as yourself. And then declares peace with everyone else. ] < > { hunk ./Vanilla/robotd/data.c 48 int override = 0; int doreserved = 0; int lastm; -int delay; /* delay for decaring war */ +int delay; /* delay for declaring war */ int rdelay; /* delay for refitting */ int mapmode = 1; int namemode = 1; hunk ./Vanilla/robotd/decide.c 37 if(!inl){ if((_state.warteam < 0 || _state.total_wenemies == 0) && _state.total_enemies > 0){ + /* beginning of game, no enemies */ declare_intents(); return; } hunk ./Vanilla/robotd/decide.c 45 else if(status->tourn){ if((_state.warteam < 0 || _state.total_wenemies == 0) && _state.total_enemies > 0){ + /* beginning of game, no enemies */ declare_intents(); return; } hunk ./Vanilla/robotd/main.c 42 char **argv; { int intrupt(), noargs = 0; - int team = 1, s_type = CRUISER; + int team = 1, s_type = CRUISER; int usage = 0; int err = 0; char *name, *ptr, *cp, *rindex(); hunk ./Vanilla/robotd/main.c 47 int dcore(), resetRobot(); - void reaper(int), kill_rwatch(int), exitRobot(int); + void reaper(int), kill_rwatch(int), exitRobot(int); int passive = 0; char *defaultsFile = NULL; hunk ./Vanilla/robotd/main.c 50 - register i; - int rwatch=0; - char password[64]; - int timer2 = 0, tryudp=1; - char **_argv = argv; - int _argc = argc; + register i; + int rwatch=0; + static int switchedteams=0; + char password[64]; + int timer2 = 0, tryudp=1; + char **_argv = argv; + int _argc = argc; if(argc == 1) printUsage(argv[0]); hunk ./Vanilla/robotd/main.c 404 mprintf("team ...\n"); if(!teamRequest(team, s_type)){ + switchedteams = 1; mprintf("team or ship rejected.\n"); /* if base destroyed */ hunk ./Vanilla/robotd/main.c 436 timer2 = 0; _state.team = team; if (!teamRequest(team, s_type)){ - mfprintf(stderr, "team or ship rejected.\n"); - showteams(); + switchedteams = 1; + mfprintf(stderr, "team or ship rejected.\n"); + showteams(); } else break; hunk ./Vanilla/robotd/main.c 464 if((_state.try_udp || tryudp) && commMode != COMM_UDP){ sendUdpReq(COMM_UDP); } + + if (switchedteams) { + switchedteams = 0; + declare_intents(); + } input(); } hunk ./Vanilla/robotd/robot.c 2005 strcpy(_state.ignore_e, ignore_e); bzero(&_timers, sizeof(_timers)); + + /* only happens when robot is dead or when someone sends a reset + command to the robot. If robot is dead, declare_intents does + nothing. */ declare_intents(); req_cloak_off("reset"); return 1; hunk ./Vanilla/robotd/robot.c 2072 sendUpdatePacket((int)(_state.timer_delay_ms * 100000.)); init_comm(); - /* - declare_intents(); - */ } ignore_edefault(s) hunk ./Vanilla/robotd/update_players.c 1027 } /* war & peace. Done initially */ -/* BUGS */ hunk ./Vanilla/robotd/update_players.c 1028 +/* When you first enter the game 10 seconds in, the robot will declare + war on the top 2 teams with most players. If the robot is a 3rd + team scummer, it works out quite nicely. + + Will also declare war correctly when forced to join a different + team, say during timercide. Then winners keep their old war + declarations (which is the right thing to do), as they don't get + forced to join a different team. + + Doesn't work when you lose t-mode and people join back in on + different teams, as the function to check for this condition + doesn't exist, yet. */ declare_intents() { register i; hunk ./Vanilla/robotd/update_players.c 1044 register struct player *j; - int teams[16], maxt = 0; + int teams[16], maxt=0, maxcount=0; + int maxt2=0, maxcount2=0; int newhostile, pl=0; extern char *team_to_string(); hunk ./Vanilla/robotd/update_players.c 1068 pl++; } + if (!pl) return; + if(pl){ hunk ./Vanilla/robotd/update_players.c 1071 - for(i=1; i< 9; i *= 2) - if(teams[i] > maxt) + for(i=1; i< 9; i *= 2) { + if(teams[i] > maxcount) { maxt = i; hunk ./Vanilla/robotd/update_players.c 1074 + maxcount = teams[i]; + } + } mprintf("max team = %s\n", team_to_string(maxt)); hunk ./Vanilla/robotd/update_players.c 1078 + for(i=1; i< 9; i *= 2) { + if( (teams[i] > maxcount2) && (i != maxt) ) { + maxt2 = i; + maxcount2 = teams[i]; + } + } + mprintf("max team2 = %s\n", team_to_string(maxt2)); } hunk ./Vanilla/robotd/update_players.c 1086 - /* - else - maxt = -1; - */ /* peace */ for(i=1; i< 9; i *= 2){ hunk ./Vanilla/robotd/update_players.c 1089 - if(i == maxt) continue; + if(i == maxt || i == maxt2) continue; if((i & me->p_hostile) && !(i & me->p_swar)){ hunk ./Vanilla/robotd/update_players.c 1091 + /* is hostile to and not at war with */ mprintf("declaring peace with %s\n", team_to_string(i)); newhostile ^= i; } hunk ./Vanilla/robotd/update_players.c 1099 _state.warteam = maxt; /* war */ - if(maxt != -1){ - if(!((maxt & me->p_swar) || (maxt & me->p_hostile))){ + if(maxt != 0) { + if(!((maxt & me->p_swar) && !(maxt & me->p_hostile))) { mprintf("declare war with %s\n", team_to_string(maxt)); hunk ./Vanilla/robotd/update_players.c 1102 - newhostile ^= maxt; + newhostile |= maxt; } } hunk ./Vanilla/robotd/update_players.c 1105 + + /* Being hostile to more teams is better than less teams. */ + if(maxt2 != 0) { + if(!((maxt2 & me->p_swar) && !(maxt2 & me->p_hostile))) { + mprintf("declare war with %s\n", team_to_string(maxt2)); + newhostile |= maxt2; + } + } + if(newhostile != me->p_hostile) sendWarReq(newhostile); } } Context: [continuum ban vote tweaks 2006-06 quozl at us.netrek.org**20060622015354 Following review of continuum recording 2006-06-07-22-00: - require four votes to ban instead of two, to defeat ban scumming, - expire ban votes within two minutes instead of ten, - expire eject votes within five minutes instead of ten. ] [xtkill ship change fixes williamb at its.caltech.edu**20060620005009 * tools/xtkill.c: Adds the ability to set ship to galaxy class, removes unneccessary ship size change for ATT, and updates the list of valid ship types to include the super SC with 1 point torps (this was missing from list of valid ship types). M ./Vanilla/tools/xtkill.c -8 +5 ] [newbie-observer-ports.dpatch jimmyhua73 at yahoo.com**20060616103448 * docs/sample_ports added observer port definitions for newbie server. Added commentary to make it easier to configure the port configuration for a newbie server setup. ] [Chaos mode starbase enhancements williamb at its.caltech.edu**20060606200821 * orbit.c, transwarp.c: Allows starbases to transwarp to and dock with other bases if chaos mode is activated. ] [Twarp message fix williamb at its.caltech.edu**20060606200652 * transwarp.c: Fixes outdated reference to transwarp hours. ] [ATT and invalid ship fixes williamb at its.caltech.edu**20060603092650 * getentry.c, main.c: allow listing of ATT on features screen, and allow player to select ATT from entry window if ship is defined in sysdef as a valid ship. Also fixes incorrect error message in the case of invalid ship type. ] [null-terminate-mapchars-indentfix Stephen Thorne **20060614103104] [null-terminate-mapchars jimmyhua73 at yahoo.com**20060614105540 * robotd/struct.h modify mapchars to 3 characters to hold the NULL at the end * robotd/enter.c initialize final character to be NULL at the end when the robot first enters the game. ] [robotd-improved-army-tracking.dpatch jimmyhua73 at yahoo.com**20060613104425 * INSTALL.Newbie updated installation documentation to reflect changes in code. Also, CONFIRM=0 only works, CONFIRM=2 does not work. * INSTALL.Newbie added toggle robdc, assume robots don't carry. Also added lookahead=0 to emulate how robots were before Trent fixed the torp-dir bug. * robotd/data.c added extern int robdc (robots don't carry) * robotd/data.h extern int robdc defaults to not activated. * robotd/data.h added compiler define NO_PFORBIT, so robot doesn't depend on PFORBIT flag to determine if someone is picking armies or not. * robotd/dmessage.c added robdc in help. added robdc in messaging logic. * robotd/update_players.c commented out a continue; statement as the for loop gets exited too quickly sometimes. * robotd/update_players.c stale information of p->closest_pl is kept even when enemy becomes invisible. Will be used later. * robotd/update_players.c don't update last x or y if invisible. * robotd/update_players.c changes to check_orbit() function to make sure players is marked as orbiting a planet when cloaked near a planet, or invisible. * robotd/update_players.c changed some debug statements to make them more readable during a denemy debug session. * robotd/update_players.c army_check1() and army_check2() added logic so if robdc is activated, robot doesn't track fellow robot carriers. * robotd/update_players.c added some commentary so the army tracking code is more readble. Commented out a beam-down to friendly in favor of the more pessimistic possibility that the planet simply popped. ] [Cross-transwarp check williamb at its.caltech.edu**20060608223709 * transwarp.c: Prevent transwarping to a base that is already in transwarp. ] [post 2.11.1 release process notes quozl at us.netrek.org**20060601040643] [include config.guess in make dist quozl at us.netrek.org**20060601033548] [include config.sub in make dist quozl at us.netrek.org**20060601033011] [TAG 2.11.1 quozl at us.netrek.org**20060601025406] Patch bundle hash: 8ecdd6780183d9777e3ff655913f26b794f0416b -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060630/f2f85b94/attachment.pgp From jimmyhua73 at yahoo.com Thu Jun 29 20:42:42 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 29 Jun 2006 18:42:42 -0700 (PDT) Subject: [netrek-dev] newbie-robots-now-declare-war-properly-in-pickup-games.dpatch In-Reply-To: <20060630012901.GD7745@us.netrek.org> Message-ID: <20060630014242.18311.qmail@web35305.mail.mud.yahoo.com> > It helps to describe the testing you did in the long > comment, as that > would help others to review the change and verify > your testing was > appropriate. Dang, I didn't think about that. Anyways, the test is: 1. start Marvin in a newbie server. 2. time it just right (1 second after t-mode starts) and start another Marvin in the same server, in a 3rd scumming team. Use port 3592 so he can join any team. 3. watch the war declarations. 4. watch the fighting to make sure, they do the right thing. 5. make the 3rd space scummer leave after a while (like he would if he joined the regular port). 6. Make the first marvin's team lose via timercide. 7. Watch war declarations and make sure Marvin does the right thing as far as war goes. Did this 2 times, and seems to work good. Jimmy From jimmyhua73 at yahoo.com Thu Jun 29 20:48:04 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 29 Jun 2006 18:48:04 -0700 (PDT) Subject: [netrek-dev] newbie-robots-now-declare-war-properly-in-pickup-games.dpatch In-Reply-To: <20060630014242.18311.qmail@web35305.mail.mud.yahoo.com> Message-ID: <20060630014804.92923.qmail@web35309.mail.mud.yahoo.com> --- Jimmy Huang wrote: > Anyways, the test is: > > 1. start Marvin in a newbie server. > 2. time it just right (1 second after t-mode starts) > and start another Marvin in the same server, in a > 3rd > scumming team. Use port 3592 so he can join any > team. > 3. watch the war declarations. > 4. watch the fighting to make sure, they do the > right > thing. > 5. make the 3rd space scummer leave after a while > (like he would if he joined the regular port). > 6. Make the first marvin's team lose via timercide. Marvin will be forced onto a different team. > 7. Watch war declarations and make sure Marvin does > the right thing as far as war goes. After Genocide, Marvin will be forced onto yet another team. Make sure he does the right war decs again. From jimmyhua73 at yahoo.com Thu Jun 29 21:06:32 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Thu, 29 Jun 2006 19:06:32 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060630001027.GB7745@us.netrek.org> Message-ID: <20060630020632.48106.qmail@web35302.mail.mud.yahoo.com> --- James Cameron wrote: > If there's something wrong with the Emacs Wiki page, > you should add a > neutral and factual observation to it. You should > be able to edit the > pages in that Wiki, though I'm not sure if you need > to register first. Argh! Something new to learn. Dunno how to modify Wiki pages. The problem with the emacs Wiki page, is that it is written for someone for already knows how to use emacs. It's written in cookbook fashion (for someone who already knows how to cook), and not step-by-step fashion. This is great in general, I think. But it's bad for me. Here's an example. I put this code in my .emacs file: (defface extra-whitespace-face '((t (:background "pale green"))) "Used for tabs and such.") (defvar my-extra-keywords '(("\t" . 'extra-whitespace-face))) (add-hook 'emacs-lisp-mode-hook (lambda () (font-lock-add-keywords nil my-extra-keywords))) (add-hook 'c-mode-hook (lambda () (font-lock-add-keywords nil my-extra-keywords))) And, it didn't work. No error messages or anything, so I have no clue what is wrong. > You should be able to add a tab manually, using > Control/Q then tab. Woohoo! Another tip! This will save me at least 5 minutes! Thanks. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: .emacs Type: application/octet-stream Size: 817 bytes Desc: 2460494731-.emacs Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060629/1ea9d36c/attachment.obj From quozl at us.netrek.org Thu Jun 29 21:24:05 2006 From: quozl at us.netrek.org (James Cameron) Date: Fri, 30 Jun 2006 12:24:05 +1000 Subject: [netrek-dev] newbie-robots-now-declare-war-properly-in-pickup-games.dpatch In-Reply-To: <20060630014804.92923.qmail@web35309.mail.mud.yahoo.com> References: <20060630014242.18311.qmail@web35305.mail.mud.yahoo.com> <20060630014804.92923.qmail@web35309.mail.mud.yahoo.com> Message-ID: <20060630022405.GA23677@us.netrek.org> Thanks for that, I've added it to Vanilla/tests/newbie-robots-war-declarations in my repo. (By having tests defined in the repository, we're able to more simply detect regressions ... this test isn't as automated as the others there, but it's better than nothing.) -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Thu Jun 29 23:39:17 2006 From: quozl at us.netrek.org (James Cameron) Date: Fri, 30 Jun 2006 14:39:17 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060630020632.48106.qmail@web35302.mail.mud.yahoo.com> References: <20060630001027.GB7745@us.netrek.org> <20060630020632.48106.qmail@web35302.mail.mud.yahoo.com> Message-ID: <20060630043917.GA1852@us.netrek.org> On Thu, Jun 29, 2006 at 07:06:32PM -0700, Jimmy Huang wrote: > Argh! Something new to learn. Dunno how to modify Wiki pages. Really? Okay, as a general principle you open the page in a web browser, then click on an edit button, and you get the page content in a text box, you edit it, and press submit. It is all done in the web browser. Read http://en.wikipedia.org/wiki/Wiki for more details. Practice the concepts on the Netrek Development Wiki, which has a page just for testing ... http://wiki.us.netrek.org/netrek-dev/WikiSandBox Wikis change policy over time. The Emacs Wiki was editable by anybody when I last checked. Go to http://www.emacswiki.org/ and click on the HowTo link for more instructions. > The problem with the emacs Wiki page, is that it is written for > someone for already knows how to use emacs. It's written in cookbook > fashion (for someone who already knows how to cook), and not > step-by-step fashion. This is great in general, I think. But it's bad > for me. That's an example of factoring of information. For instance they don't tell you how to change your .emacs file, because if they did that in the page about tabs then the information would be in the wrong place. You could help by finding what Wiki pages talk about editing the .emacs file, and if there's some central one then edit the page in question to point to it. > Here's an example. I put this code in my .emacs file: > And, it didn't work. No error messages or anything, so > I have no clue what is wrong. Perhaps you didn't turn on font-lock mode. When editing a C source file, are all the keywords different colours? If not, try turning on font-lock mode. There's a menu option for it, a command, or edit your .emacs file. Mine is attached. It turns on font-lock mode by default. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- (setq term-setup-hook 'edt-emulation-on) (setq version-control t) (setq kept-new-versions 15) (setq kept-old-versions 15) (setq backup-by-copying-when-linked t) (setq backup-by-copying-when-mismatch t) (custom-set-variables '(compilation-read-command nil) '(add-log-mailing-address "quozl at us.netrek.org" t) '(compilation-scroll-output t) '(add-log-time-format (quote current-time-string)) '(compilation-ask-about-save nil t) '(zenirc-server-default "irc.openprojects.net" t) '(time-stamp-time-zone "UTC") '(global-font-lock-mode t nil (font-lock)) '(highlight-changes-global-initial-state (quote active))) (custom-set-faces '(font-lock-warning-face ((((class color) (background dark)) (:inverse-video nil :foreground "Pink")))) '(modeline ((t (:inverse-video t))))) (defface extra-whitespace-face '((t (:background "dark green"))) "Used for tabs and such.") (defvar my-extra-keywords '(("\t" . 'extra-whitespace-face))) (add-hook 'emacs-lisp-mode-hook (lambda () (font-lock-add-keywords nil my-extra-keywords))) (add-hook 'text-mode-hook (lambda () (font-lock-add-keywords nil my-extra-keywords))) (add-hook 'c-mode-hook (lambda () (font-lock-add-keywords nil my-extra-keywords))) (add-hook 'diff-mode-hook (lambda () (font-lock-add-keywords nil my-extra-keywords))) (server-start) From jimmyhua73 at yahoo.com Fri Jun 30 03:04:49 2006 From: jimmyhua73 at yahoo.com (Jimmy Huang) Date: Fri, 30 Jun 2006 01:04:49 -0700 (PDT) Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060630043917.GA1852@us.netrek.org> Message-ID: <20060630080449.73659.qmail@web35305.mail.mud.yahoo.com> --- James Cameron wrote: > Really? Okay, as a general principle you open the > page in a web > browser, then click on an edit button, and you get > the page content in a > text box, you edit it, and press submit. It is all > done in the web > browser. Okay. I edited the emacs Wiki. > Perhaps you didn't turn on font-lock mode. When > editing a C source > file, are all the keywords different colours? If > not, try turning on > font-lock mode. There's a menu option for it, a > command, or edit your > .emacs file. Mine is attached. It turns on > font-lock mode by default. Okay. That was my problem. Although I have no clue what is font-lock to begin with so had no idea I was supposed to turn it on? I edited the Wiki at the WAY end, saying you need to turn it on to see the changes. I even used your file below so I know how to turn it on using .emacs ;-P. > (custom-set-variables > '(global-font-lock-mode t nil (font-lock)) ) Jimmy From quozl at us.netrek.org Fri Jun 30 06:48:05 2006 From: quozl at us.netrek.org (James Cameron) Date: Fri, 30 Jun 2006 21:48:05 +1000 Subject: [netrek-dev] robotd-war-decs-bugfix.dpatch In-Reply-To: <20060630080449.73659.qmail@web35305.mail.mud.yahoo.com> References: <20060630043917.GA1852@us.netrek.org> <20060630080449.73659.qmail@web35305.mail.mud.yahoo.com> Message-ID: <20060630114805.GA5800@us.netrek.org> On Fri, Jun 30, 2006 at 01:04:49AM -0700, Jimmy Huang wrote: > Okay. That was my problem. Although I have no clue > what is font-lock to begin with so had no idea I was > supposed to turn it on? Are you using emacs in a terminal emulator or using a graphical window? When I run emacs, I'm given pull-down menus. The options menu has an item called "Syntax Highlighting (Global Font Lock mode)", and another item called "Save Options". Using one then the other results in the automatic change of the .emacs file to add global-font-lock-mode true. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/