From dopleganger_69 at hotmail.com  Thu Apr  6 12:13:06 2006
From: dopleganger_69 at hotmail.com (Pascal Gagnon)
Date: Thu, 06 Apr 2006 13:13:06 -0400
Subject: [netrek-dev] Hi im defcom
Message-ID: <BAY107-F3CD82DFF9B20813622E56F5C80@phx.gbl>

im new at netrek-dev im anartist im there to do drawing ,the thing i wanna 
draw was the planet of the game i asked quozl he he suggested me to 
subscribe and talk about this ,so im here i want to talk to the persone whos 
first talk about changing the graphics of the game so if you want to 
communicate with me you know how to. i can also make butiful webpage picture 
i could also do picture for all back screen of netrek game be indulgent 
cause my english suck caus im french hehe im happy to participate to netrek 
preject thanks you all.

_________________________________________________________________
Des m?canismes de contr?le parental puissants permettent ? votre enfant de 
d?couvrir tout ce qu?Internet a ? offrir. 
http://join.msn.com/?pgmarket=fr-ca&page=features/parental Commencez d?s 
maintenant ? profiter de tous les avantages de MSN Premium et obtenez les 
deux premiers mois GRATUITS*.



From quozl at us.netrek.org  Thu Apr  6 20:09:51 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 7 Apr 2006 11:09:51 +1000
Subject: [netrek-dev] Hi im defcom
In-Reply-To: <BAY107-F3CD82DFF9B20813622E56F5C80@phx.gbl>
References: <BAY107-F3CD82DFF9B20813622E56F5C80@phx.gbl>
Message-ID: <20060407010951.GB21260@us.netrek.org>

Welcome Pascal!

It is Gregory Hermann who has been working on a new client.  We last
heard from him on 18th January.  He was going to add refit and plasma
support that weekend.  Check out the mailing list archives to catch up
on the discussion.

Open source projects often need graphic artists and it is good to hear
from one.  That you also play Netrek is great.  ;-)

Other things we need art work for are:

- web page content, backgrounds and static structures, especially if
  they can be done in CSS, (I'm not very good at it),

- metaserver web page,

- startup screens for Netrek programs,

- an image to go with the metaserver window,

- an image to go with the wait queue window,

- an image as background for log in stage,

- an image to go with team selection window,

- game piece images, such as planets and ships, explosions and torps,

This last need has some severe technical constraints.  It is difficult
to show different planet attributes.  It is difficult to fit all this
information into a 32x32 pixmap, like in COW or NetrekXP.  Gregory's
client may have different needs.

Because we're an open source project, we need to be able to know that
what you are providing is truly yours, and not someone elses work.  So
avoid posting images on web sites that claim copyright.  Learn how to
post on your own web site.  We can help you with that in IRC.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From netrek at gmail.com  Thu Apr  6 22:48:02 2006
From: netrek at gmail.com (Zach)
Date: Thu, 6 Apr 2006 23:48:02 -0400
Subject: [netrek-dev] Hi im defcom
In-Reply-To: <20060407010951.GB21260@us.netrek.org>
References: <BAY107-F3CD82DFF9B20813622E56F5C80@phx.gbl>
	<20060407010951.GB21260@us.netrek.org>
Message-ID: <ecfa260c0604062048t5c8a9e7an8f4c3b42ab7ba04d@mail.gmail.com>

On 4/6/06, James Cameron <quozl at us.netrek.org> wrote:
>
> It is Gregory Hermann who has been working on a new client.  We last
> heard from him on 18th January.  He was going to add refit and plasma
> support that weekend.  Check out the mailing list archives to catch up
> on the discussion.

Is his client code online? Does he have a SF page setup?

Zach


From stephen.thorne at gmail.com  Thu Apr  6 23:07:47 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 7 Apr 2006 14:07:47 +1000
Subject: [netrek-dev] Hi im defcom
In-Reply-To: <ecfa260c0604062048t5c8a9e7an8f4c3b42ab7ba04d@mail.gmail.com>
References: <BAY107-F3CD82DFF9B20813622E56F5C80@phx.gbl>
	<20060407010951.GB21260@us.netrek.org>
	<ecfa260c0604062048t5c8a9e7an8f4c3b42ab7ba04d@mail.gmail.com>
Message-ID: <3e8ca5c80604062107j640ee1d5x3402e0afa91e9536@mail.gmail.com>

On 4/7/06, Zach <netrek at gmail.com> wrote:
> On 4/6/06, James Cameron <quozl at us.netrek.org> wrote:
> >
> > It is Gregory Hermann who has been working on a new client.  We last
> > heard from him on 18th January.  He was going to add refit and plasma
> > support that weekend.  Check out the mailing list archives to catch up
> > on the discussion.
>
> Is his client code online? Does he have a SF page setup?

I see in the archives that http://sourceforge.net/projects/netrekng/
is where the code is.

--
Stephen Thorne
Development Engineer


From netrek at gmail.com  Thu Apr  6 23:14:40 2006
From: netrek at gmail.com (Zach)
Date: Fri, 7 Apr 2006 00:14:40 -0400
Subject: [netrek-dev] Hi im defcom
In-Reply-To: <3e8ca5c80604062107j640ee1d5x3402e0afa91e9536@mail.gmail.com>
References: <BAY107-F3CD82DFF9B20813622E56F5C80@phx.gbl>
	<20060407010951.GB21260@us.netrek.org>
	<ecfa260c0604062048t5c8a9e7an8f4c3b42ab7ba04d@mail.gmail.com>
	<3e8ca5c80604062107j640ee1d5x3402e0afa91e9536@mail.gmail.com>
Message-ID: <ecfa260c0604062114x5da80a6aqca77807cea24a523@mail.gmail.com>

Cool. You working on it Stephen?

Zach

On 4/7/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
> I see in the archives that http://sourceforge.net/projects/netrekng/
> is where the code is.


From williamb at its.caltech.edu  Fri Apr  7 02:30:25 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 7 Apr 2006 00:30:25 -0700 (PDT)
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
Message-ID: <Pine.GSO.4.58.0604070021380.25922@sue>

Hi, I'm trying to set up the vanilla server on linux for the first time,
and I ran into some compile errors.  First, on make, the following
problem with players.c in the /tools directory:

gcc  -g -O2  -DRSA -I. -I. -I../include -I./../include   -c -o players.o
players.c
players.c: In function `comment':
players.c:191: parse error before `*'
players.c:192: `file' undeclared (first use in this function)
players.c:192: (Each undeclared identifier is reported only once
players.c:192: for each function it appears in.)
players.c:193: parse error before `static'
players.c:196: `res' undeclared (first use in this function)
players.c: In function `udp':
players.c:231: parse error before `char'
players.c:236: `packet' undeclared (first use in this function)
make: *** [players.o] Error 1

I have no idea what the problem is, the line of code in question is:
  FILE *file = fopen(name, "r");


The second error message, in the xsg directory:
gcc  -g -O2  -DRSA  -INONE -I. -I. -I../include -I./../include   -c -o
x11window.o x11window.c
x11window.c:11: X11/Xlib.h: No such file or directory
x11window.c:12: X11/Xutil.h: No such file or directory

In this case, the files in question are just missing, perhaps due to the
linux box not having X windows?

Any help appreciated.
Bill


From tanner at real-time.com  Fri Apr  7 10:20:38 2006
From: tanner at real-time.com (Bob Tanner)
Date: Fri, 7 Apr 2006 10:20:38 -0500
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
In-Reply-To: <Pine.GSO.4.58.0604070021380.25922@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
Message-ID: <200604071020.39345.tanner@real-time.com>

On Friday 07 April 2006 02:30, William Balcerski wrote:
> Hi, I'm trying to set up the vanilla server on linux for the first time,
> and I ran into some compile errors. ?First, on make, the following
> problem with players.c in the /tools directory:

What linux distribution?

What version of that distro?

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From williamb at its.caltech.edu  Fri Apr  7 13:21:43 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 7 Apr 2006 11:21:43 -0700 (PDT)
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
In-Reply-To: <Pine.GSO.4.58.0604070021380.25922@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
Message-ID: <Pine.GSO.4.58.0604071120310.16842@inky>

As it turns out, using a later version of gcc fixed the first error, and
the second error was because X11 is not installed on the system.
Bill

On Fri, 7 Apr 2006, William Balcerski wrote:

> Hi, I'm trying to set up the vanilla server on linux for the first time,
> and I ran into some compile errors.  First, on make, the following
> problem with players.c in the /tools directory:
> <snip>


From gregoryhermann at yahoo.com  Fri Apr  7 14:50:44 2006
From: gregoryhermann at yahoo.com (Gregory Hermann)
Date: Fri, 7 Apr 2006 12:50:44 -0700 (PDT)
Subject: [netrek-dev] Hi im defcom
In-Reply-To: <ecfa260c0604062114x5da80a6aqca77807cea24a523@mail.gmail.com>
Message-ID: <20060407195044.72989.qmail@web54409.mail.yahoo.com>

Yep. Got tied up working on Real Life and having to
rewrite the UI system as (oddly enough) most of my
performance losses were coming from that. Given that I
work on a UI system professionally, it's something
that I got easily distracted by. 

--- Zach <netrek at gmail.com> wrote:

> Cool. You working on it Stephen?
> 
> Zach
> 
> On 4/7/06, Stephen Thorne <stephen.thorne at gmail.com>
> wrote:
> > I see in the archives that
> http://sourceforge.net/projects/netrekng/
> > is where the code is.
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From quozl at us.netrek.org  Sun Apr  9 22:32:00 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 13:32:00 +1000
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
In-Reply-To: <Pine.GSO.4.58.0604070021380.25922@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
Message-ID: <20060410033200.GA1243@us.netrek.org>

On Fri, Apr 07, 2006 at 12:30:25AM -0700, William Balcerski wrote:
> players.c: In function `comment':
> players.c:191: parse error before `*'
> players.c:192: `file' undeclared (first use in this function)

GCC 2.6 isn't supported by this code.  Use a more recent compiler.  The
code as it stands relies on inline declarations, a feature I'm told of
ANSI C99.

I'll take patches to fix compilation errors on GCC 3 or GCC 4.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From netrek at gmail.com  Sun Apr  9 23:36:22 2006
From: netrek at gmail.com (Zach)
Date: Mon, 10 Apr 2006 00:36:22 -0400
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
In-Reply-To: <20060410033200.GA1243@us.netrek.org>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
Message-ID: <ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>

On 4/9/06, James Cameron <quozl at us.netrek.org> wrote:
>
> GCC 2.6 isn't supported by this code.  Use a more recent compiler.  The
> code as it stands relies on inline declarations, a feature I'm told of
> ANSI C99.

http://en.wikipedia.org/wiki/Inline_function

Zach


From quozl at us.netrek.org  Mon Apr 10 00:22:56 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 15:22:56 +1000
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
In-Reply-To: <ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
Message-ID: <20060410052256.GD1243@us.netrek.org>

On Mon, Apr 10, 2006 at 12:36:22AM -0400, Zach wrote:
> On 4/9/06, James Cameron <quozl at us.netrek.org> wrote:
> >
> > GCC 2.6 isn't supported by this code.  Use a more recent compiler.  The
> > code as it stands relies on inline declarations, a feature I'm told of
> > ANSI C99.
> 
> http://en.wikipedia.org/wiki/Inline_function

Erm, no, not inline functions, but inline declarations.  Perhaps I'm not
using a term with a shared semantic.

See http://en.wikipedia.org/wiki/Declaration_%28computer_science%29

Example inline declarations from tools/players.c function comment are
the variables file, text, and res:

static char *comment() {
  char name[MAXPATH];
  snprintf(name, MAXPATH, "%s/%s", SYSCONFDIR, "comment");
  FILE *file = fopen(name, "r");
  if (file == NULL) return "";
  static char text[80];
  char *res = fgets(text, 80, file);
  fclose(file);
  if (res == NULL) return "";
  res[strlen(res)-1] = '\0';
  return res;
}

To write this with declarations at the top of the function would remove
the use of inline declarations:

static char *comment() {
  char name[MAXPATH];
  FILE *file;
  static char text[80], *res;

  snprintf(name, MAXPATH, "%s/%s", SYSCONFDIR, "comment");
  file = fopen(name, "r");
  if (file == NULL) return "";
  res = fgets(text, 80, file);
  fclose(file);
  if (res == NULL) return "";
  res[strlen(res)-1] = '\0';
  return res;
}

Which is more correct is a matter of style and code comprehension.  I've
not had any comments on this yet.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From williamb at its.caltech.edu  Mon Apr 10 00:41:34 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Sun, 9 Apr 2006 22:41:34 -0700 (PDT)
Subject: [netrek-dev] Sb etemp fix.
In-Reply-To: <20060410052256.GD1243@us.netrek.org>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
Message-ID: <Pine.GSO.4.58.0604092239460.15344@sue>

Here is a fix for properly undocking both ejected and ghostbusted
players who may have been docked to a SB, which is one of the main
sources of the dreaded starbase etemp bug.
Bill

Index: ./ntserv/ntscmds.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/ntscmds.c,v
retrieving revision 1.3
diff -u -r1.3 ntscmds.c
--- ./ntserv/ntscmds.c  27 Sep 2005 12:26:37 -0000      1.3
+++ ./ntserv/ntscmds.c  10 Apr 2006 05:39:12 -0000
@@ -299,6 +299,13 @@
   j->p_explode=10;
   j->p_status=PEXPLODE;
   j->p_whodead=me->p_no;
+  /* At this point, docked ships become removed. */
+  if (j->p_flags & PFDOCK)
+  {
+    players[j->p_docked].p_docked--;
+    players[j->p_docked].p_port[j->p_port[0]] = VACANT;
+    j->p_flags &= ~PFDOCK;
+  }
 }
 #endif /* ALLOW_EJECT */

Index: ./ntserv/daemonII.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
retrieving revision 1.3
diff -u -r1.3 daemonII.c
--- ./ntserv/daemonII.c 27 Sep 2005 12:26:37 -0000      1.3
+++ ./ntserv/daemonII.c 10 Apr 2006 05:39:12 -0000
@@ -3798,6 +3798,13 @@
             }
         }
     }
+    /* At this point, docked ships become removed. */
+    if (victim->p_flags & PFDOCK)
+    {
+        players[victim->p_docked].p_docked--;
+        players[victim->p_docked].p_port[victim->p_port[0]] = VACANT;
+        victim->p_flags &= ~PFDOCK;
+    }
 }

 static void saveplayer(struct player *victim)



From quozl at us.netrek.org  Mon Apr 10 00:50:56 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 15:50:56 +1000
Subject: [netrek-dev] Repost, phadthai, metaserver robot count consistency &c
Message-ID: <20060410055056.GE1243@us.netrek.org>

The following message apparently hasn't made it to the mailing list, so
I'm reposting it on behalf of an IRC user phadthai.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

--

I have had a netrek server successfully running and advertizing to the
metaservers (solicit.c) for a few months.  This is primarily a practice
server, with robots maintaining T mode 24/7.

I had fixed my local copy of the server code to not send robot players
along in solicit packets, and this seemed to successfully work for some
time.  However, lately it appears that the nine robots always appeared
again in the metaserver's list.

Using tcpdump(8) I could see that the solicit UDP datagram that is sent
is correct and does not include the robots.  Here is one:

0x0000:  0048 5480 e911 00b0 d083 dcd5 0800 4500            .HT...........E.
0x0010:  0051 68d6 0000 4011 0000 c0a8 010a 41c1            .Qh... at .......A.
0x0020:  11f0 c44c 0dc1 003d f708 620a 6e65 7472            ...L...=..b.netr
0x0030:  656b 2e70 756c 7361 722d 7a6f 6e65 2e6e            ek.pulsar-zone.n
0x0040:  6574 0a42 0a32 3539 320a 3235 3933 0a30            et.B.2592.2593.0
0x0050:  0a31 360a 790a 790a 6e0a 6f70 656e 0a              .16.y.y.n.open.

So I expect that the metaserver connects to the servers and obtain their
players list themselves, rather than relying on the solicit datagram (I
however yet have to read the metaserver code).  Grepping the metaservers
code for strings like "robot" or "localhost" it doesn't seem to perform
any checking to ignore robot players, however.

Considering that the source of a UDP client packet is easily spoofable,
it might make sense.  If this is the main issue, then would anyone mind
if I came up with an update to the Vanilla server code as well as to the
metaservers so that these can be transfered using TCP, and the source IP
address verified to match with the server's hostname resolution address?

If this was implemented, would there remain any other reasons for the
metaserver to connect to the servers, other than to verify their working
status?  Or, could we simply obsolete the current solicit datagram to be
replaced with one which only has the server address, for the metaservers
to continue querying the user list as it currently does, and add some
filtering against robot or localhost strings to hide those users?

Since I noticed that the robots on my server were now being seen as
players again, and that I'm not yet able to fix this easily without
looking closely at the metaservers code, I disabled the robots at around
15h EST today to avoid getting in trouble with the metaservers
administrators for "spamming" robot players.  However, it appears that
from approximately 19h EST and up, both orion.netrek.org and
sage.real-time.com stopped connecting to my server, and the server also
now seems out of the metaservers list (netrek.pulsar-zone.net).

Was the server blacklisted?  And if so, was it because of the
aforementionned "bot" spamming?  Under which case, why was it
blacklisted even after those robots were deactivated?  Moreover, would a
technical solution by server and/or metaserver code change be accepted
by the community?  These changes would not break clients.

If my server was blacklisted, what action can possibly be taken to list
the server again?

Thanks,
Matthew Mondor


From netrek at gmail.com  Mon Apr 10 00:59:51 2006
From: netrek at gmail.com (Zach)
Date: Mon, 10 Apr 2006 01:59:51 -0400
Subject: [netrek-dev] Compile errors for vanilla-2.10.2
In-Reply-To: <20060410052256.GD1243@us.netrek.org>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
Message-ID: <ecfa260c0604092259l3ad16fb0ke511f1e08ef4f69a@mail.gmail.com>

On 4/10/06, James Cameron <quozl at us.netrek.org> wrote:
>
> Erm, no, not inline functions, but inline declarations.  Perhaps I'm not
> using a term with a shared semantic.

Thanks for clearing that up.

Zach


From williamb at its.caltech.edu  Mon Apr 10 01:13:44 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Sun, 9 Apr 2006 23:13:44 -0700 (PDT)
Subject: [netrek-dev] Voting structure fix
In-Reply-To: <Pine.GSO.4.58.0604092239460.15344@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
	<Pine.GSO.4.58.0604092239460.15344@sue>
Message-ID: <Pine.GSO.4.58.0604092311000.15344@sue>

Th increase in the numbers of players (MAXPLAYERS) made the index system
on the voting structure obsolete, I increased the number of voting slots and
indexed all the vote commands past where they would overlap with player
slots.

Bill

Index: ./include/defs.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/defs.h,v
retrieving revision 1.3
diff -u -r1.3 defs.h
--- ./include/defs.h    28 Sep 2005 12:14:05 -0000      1.3
+++ ./include/defs.h    10 Apr 2006 06:09:22 -0000
@@ -64,7 +64,7 @@
                                    the rest obs slots */

 #ifdef VOTING
-#define PV_TOTAL        MAXPLAYER   /* total number of votable slots */
+#define PV_TOTAL        2*MAXPLAYER   /* total number of votable slots */
 #endif

 #if defined(NEWBIESERVER) || defined(PRETSERVER)
Index: ./ntserv/ntscmds.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/ntscmds.c,v
retrieving revision 1.3
diff -u -r1.3 ntscmds.c
--- ./ntserv/ntscmds.c  27 Sep 2005 12:26:37 -0000      1.3
+++ ./ntserv/ntscmds.c  10 Apr 2006 06:09:22 -0000
@@ -196,45 +196,45 @@
         C_VC_ALL | C_GLOG | C_PR_INPICKUP,
         "Start triple planet mayhem by vote",
         do_triple_planet_mayhem,
-       2, 22, 0},
+       2, 32, 0},
     { "BALANCE",
         C_VC_ALL | C_GLOG | C_PR_INPICKUP,
         "Request team randomise & balance",
         do_balance,
-        4, 23, 0 },
+        4, 33, 0 },
 #endif
 #if defined(AUTO_INL)
   { "INL",
        C_VC_ALL | C_GLOG | C_PR_INPICKUP,
        "Start game under INL rules.",
        do_start_inl,
-       1, 20, 0 },
+       1, 34, 0 },
 #endif
 #if defined(AUTO_PRACTICE)
   { "PRACTICE",
        C_VC_ALL | C_PR_INPICKUP,
        "Start basepractice by majority vote.",
        do_start_basep,
-       1, 20, 0 },
+       1, 35, 0 },
 #endif
 #if defined(AUTO_HOCKEY)
   { "HOCKEY",
        C_VC_ALL | C_GLOG | C_PR_INPICKUP,
        "Start hockey by majority vote.",
        do_start_puck,
-       1, 20, 0 },
+       1, 36, 0 },
 #endif
 #if defined(AUTO_DOGFIGHT)
   { "DOGFIGHT",
        C_VC_ALL | C_GLOG | C_PR_INPICKUP,
        "Start dogfight tournament by majority vote.",
        do_start_mars,
-       1, 20, 0 },
+       1, 37, 0 },
 #endif
 #endif /* VOTING */

     { NULL }
-    };
+};

 int check_command(struct message *mess)
 {


From quozl at us.netrek.org  Mon Apr 10 05:57:26 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 20:57:26 +1000
Subject: [netrek-dev] Sb etemp fix.
In-Reply-To: <Pine.GSO.4.58.0604092239460.15344@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
	<Pine.GSO.4.58.0604092239460.15344@sue>
Message-ID: <20060410105726.GF1243@us.netrek.org>

On Sun, Apr 09, 2006 at 10:41:34PM -0700, William Balcerski wrote:
> Here is a fix for properly undocking both ejected and ghostbusted
> players who may have been docked to a SB, which is one of the main
> sources of the dreaded starbase etemp bug.

Thanks Bill.  Kinda taken.  Actually I looked further into it, and found
there were a number of unhandled conditions that you didn't spot where
the etemp bug would appear again, such as:

- system induced process death, e.g. due to out of memory conditions,
- server admin killing processes with SIGKILL,
- ntserv program fault exit.

So I've reworked the design a little bit, removing the counter and
adding a crosscheck between the docking ports and the ships.

My change also moves the terminology from docking "ports" to docking
"bays" at the same time, so that I could more easily catch places where
I had not yet fixed things.

In struct player, deleted p_docked and p_ports[4].

Added p_bays[4], p_dock_with, and p_dock_bay.  This removed the
overloading that was done originally for performance reasons.

p_bays[4] works in a similar manner to p_ports[4] used to, except that
it is only used for starbases.  Each element in the array is either
VACANT (-1) or the p_no of the docked ship.

For the docked ship, the p_dock_with is set to the p_no of the base, and
the p_dock_bay is set to the p_bays array index value.

I've added a consistency checker that runs at the time a ship is docking
at a base.  Toggling docking also resets the bays.

In the daemon, where etemp is incremented, I've changed the logic to
count the active bays and determine the etemp addition from that count,
rather than rely on the count p_docked as before.

Patch to follow.

-- 
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/20060410/0b482e13/attachment.pgp 

From quozl at us.netrek.org  Mon Apr 10 06:56:44 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 21:56:44 +1000
Subject: [netrek-dev] Voting structure fix
In-Reply-To: <Pine.GSO.4.58.0604092311000.15344@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
	<Pine.GSO.4.58.0604092239460.15344@sue>
	<Pine.GSO.4.58.0604092311000.15344@sue>
Message-ID: <20060410115644.GH1243@us.netrek.org>

On Sun, Apr 09, 2006 at 11:13:44PM -0700, William Balcerski wrote:
> Th increase in the numbers of players (MAXPLAYERS) made the index system
> on the voting structure obsolete, I increased the number of voting slots and
> indexed all the vote commands past where they would overlap with player
> slots.

Taken, kinda.  I've adopted most of your change but then used macros to
set the base of the array for non-eject votes.  As I understand it, the
non-eject votes cost us one array element in each player struct for each
vote type.  So the INL vote costs one time_t in each player struct.

Patch attached.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
Index: ChangeLog
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ChangeLog,v
retrieving revision 1.16
diff -u -r1.16 ChangeLog
--- ChangeLog	10 Apr 2006 10:56:30 -0000	1.16
+++ ChangeLog	10 Apr 2006 11:32:43 -0000
@@ -1,3 +1,8 @@
+Mon Apr 10 21:31:33 2006  James Cameron  <quozl at us.netrek.org>
+
+	* defs.h, ntscmds.c (nts_commands): reallocate voting array sizes.
+	Reported by: William Balcerski.
+
 Mon Apr 10 20:41:52 2006  James Cameron  <quozl at us.netrek.org>
 
 	* struct.h: deprecate p_docked and p_ports in favour of
Index: include/defs.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/defs.h,v
retrieving revision 1.4
diff -u -r1.4 defs.h
--- include/defs.h	10 Apr 2006 10:56:31 -0000	1.4
+++ include/defs.h	10 Apr 2006 11:32:45 -0000
@@ -64,7 +64,11 @@
                                    the rest obs slots */
 
 #ifdef VOTING
-#define PV_TOTAL        MAXPLAYER   /* total number of votable slots */
+#define PV_EXTRA 8			/* # of non-eject vote types      */
+#define PV_TOTAL MAXPLAYER+PV_EXTRA	/* total number of voting slots   */
+#define PV_EJECT 0			/* array base for eject votes     */
+#define PV_OTHER MAXPLAYER		/* array base for non-eject votes */
+/* see ntserv/ntscmds.c for array */
 #endif
 
 #if defined(NEWBIESERVER) || defined(PRETSERVER)
Index: ntserv/ntscmds.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/ntscmds.c,v
retrieving revision 1.5
diff -u -r1.5 ntscmds.c
--- ntserv/ntscmds.c	10 Apr 2006 10:56:32 -0000	1.5
+++ ntserv/ntscmds.c	10 Apr 2006 11:32:48 -0000
@@ -189,52 +189,55 @@
 	C_VC_TEAM | C_GLOG | C_PLAYER | C_PR_INPICKUP,
 	"Eject a player               e.g. 'EJECT 0 IDLE'", 
 	do_player_eject,				/* EJECT */
-	2, 0, 120, 600},
+	2, PV_EJECT, 120, 600},
 #endif
 #if defined(TRIPLE_PLANET_MAYHEM)
     { "TRIPLE",
         C_VC_ALL | C_GLOG | C_PR_INPICKUP,
         "Start triple planet mayhem by vote",
         do_triple_planet_mayhem,
-	2, 22, 0},
+	2, PV_OTHER, 0},
     { "BALANCE",
         C_VC_ALL | C_GLOG | C_PR_INPICKUP,
         "Request team randomise & balance",
         do_balance,
-        4, 23, 0 },
+        4, PV_OTHER+1, 0 },
 #endif
 #if defined(AUTO_INL)
   { "INL",
 	C_VC_ALL | C_GLOG | C_PR_INPICKUP,
 	"Start game under INL rules.",
 	do_start_inl,
-	1, 20, 0 },
+	1, PV_OTHER+2, 0 },
 #endif
 #if defined(AUTO_PRACTICE)
   { "PRACTICE",
 	C_VC_ALL | C_PR_INPICKUP,
 	"Start basepractice by majority vote.",
 	do_start_basep,
-	1, 20, 0 },
+	1, PV_OTHER+3, 0 },
 #endif
 #if defined(AUTO_HOCKEY)
   { "HOCKEY",
 	C_VC_ALL | C_GLOG | C_PR_INPICKUP,
 	"Start hockey by majority vote.",
 	do_start_puck,
-	1, 20, 0 },
+	1, PV_OTHER+4, 0 },
 #endif
 #if defined(AUTO_DOGFIGHT)
   { "DOGFIGHT",
 	C_VC_ALL | C_GLOG | C_PR_INPICKUP,
 	"Start dogfight tournament by majority vote.",
 	do_start_mars,
-	1, 20, 0 },
+	1, PV_OTHER+5, 0 },
 #endif
 #endif /* VOTING */
 
+    /* crosscheck, last voting array element used (PV_OTHER+n) must
+       not exceed PV_TOTAL, see include/defs.h */
+
     { NULL }
-    };
+};
 
 int check_command(struct message *mess)
 {
@@ -308,9 +311,9 @@
 void do_start_basep(void)
 {
   if (vfork() == 0) {
-      (void) SIGNAL(SIGALRM,SIG_DFL);
-      execl(Basep, "basep", 0);
-      perror(Basep);
+    (void) SIGNAL(SIGALRM,SIG_DFL);
+    execl(Basep, "basep", 0);
+    perror(Basep);
   }
 }
 #endif
-------------- 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/20060410/7813b8b8/attachment.pgp 

From quozl at us.netrek.org  Mon Apr 10 07:01:30 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 22:01:30 +1000
Subject: [netrek-dev] Sb etemp fix.
In-Reply-To: <20060410105726.GF1243@us.netrek.org>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
	<Pine.GSO.4.58.0604092239460.15344@sue>
	<20060410105726.GF1243@us.netrek.org>
Message-ID: <20060410120130.GI1243@us.netrek.org>

The patch was placed on hold by the mailing list software, and as I
don't have any control I can't release it.

In the meanwhile, it is at
http://quozl.linux.org.au/netrek/vanilla-bays.patch

and committed to CVS.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From tanner at real-time.com  Mon Apr 10 11:56:18 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 10 Apr 2006 11:56:18 -0500
Subject: [netrek-dev] gcc2 and netrek-client-cow?
In-Reply-To: <20060410033200.GA1243@us.netrek.org>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
Message-ID: <200604101156.18521.tanner@real-time.com>

On Sunday 09 April 2006 22:32, James Cameron wrote:
> GCC 2.6 isn't supported by this code. ?Use a more recent compiler. ?The
> code as it stands relies on inline declarations, a feature I'm told of
> ANSI C99.
>
> I'll take patches to fix compilation errors on GCC 3 or GCC 4.

Are we in a position to take this same stance with netrek-client-cow?

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From williamb at its.caltech.edu  Mon Apr 10 21:41:19 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Mon, 10 Apr 2006 19:41:19 -0700 (PDT)
Subject: [netrek-dev] Minor T-mode message change
Message-ID: <Pine.GSO.4.58.0604101939030.7069@sue>

Dan Quayle is way out of date, let's find a higher profile target :).

Index: ./ntserv/daemonII.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
retrieving revision 1.3
diff -u -r1.3 daemonII.c
--- ./ntserv/daemonII.c 27 Sep 2005 12:26:37 -0000      1.3
+++ ./ntserv/daemonII.c 11 Apr 2006 02:36:46 -0000
@@ -584,7 +584,7 @@
                 pmessage(0, MALL, "GOD->ALL","Diplomat insults foriegn emperor's mother and fighting breaks out!");
                 break;
             case 6:
-                pmessage(0, MALL, "GOD->ALL","Dan Quayle declares self as galactic emperor and chaos breaks out!");
+                pmessage(0, MALL, "GOD->ALL","George Bush declares self as galactic emperor and chaos breaks out!");
                 break;
             default:
                 pmessage(0, MALL, "GOD->ALL","Peace parties have been demobilized, and fighting ensues.");
@@ -618,7 +618,7 @@
                 pmessage(0, MALL, "GOD->ALL","Diplomat apologizes to foreign emperor's mother and invasion is stopped!");
                 break;
             case 6:
-                pmessage(0, MALL, "GOD->ALL","Dan Quayle is locked up and order returns to the galaxy!");
+                pmessage(0, MALL, "GOD->ALL","George Bush is locked up and order returns to the galaxy!");
                 break;
             default:
                 pmessage(0, MALL, "GOD->ALL","The peace party has reformed, and is rallying for peace");



From stephen.thorne at gmail.com  Mon Apr 10 23:37:31 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 11 Apr 2006 14:37:31 +1000
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <Pine.GSO.4.58.0604101939030.7069@sue>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
Message-ID: <3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>

I suggest this change be altered to have

#define WARMONGERING_NATIONAL_LEADER "George Bush"

and then to use that constant in the code.
--
Stephen Thorne
Development Engineer


From williamb at its.caltech.edu  Tue Apr 11 00:31:35 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Mon, 10 Apr 2006 22:31:35 -0700 (PDT)
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
Message-ID: <Pine.GSO.4.58.0604102230180.9945@sue>

As per suggestion:

Index: ./include/defs.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/defs.h,v
retrieving revision 1.3
diff -u -r1.3 defs.h
--- ./include/defs.h    28 Sep 2005 12:14:05 -0000      1.3
+++ ./include/defs.h    11 Apr 2006 05:24:31 -0000
@@ -216,6 +216,7 @@
 #define N_SCUM_FILE    "god.LOG"
 #define N_ERROR_FILE   "ERRORS"
 #define N_BYPASS_FILE  "bypass"
+#define N_WARMONGER    "George Bush"   /* For T-mode messages */
 #ifdef RSA
 #define N_RSA_KEY_FILE "reserved"
 #endif
Index: ./ntserv/daemonII.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
retrieving revision 1.3
diff -u -r1.3 daemonII.c
--- ./ntserv/daemonII.c 27 Sep 2005 12:26:37 -0000      1.3
+++ ./ntserv/daemonII.c 11 Apr 2006 05:24:31 -0000
@@ -584,7 +584,8 @@
                 pmessage(0, MALL, "GOD->ALL","Diplomat insults foriegn emperor's mother and fighting breaks out!");
                 break;
             case 6:
-                pmessage(0, MALL, "GOD->ALL","Dan Quayle declares self as galactic emperor and chaos breaks out!");
+                pmessage(0, MALL, "GOD->ALL","%s declares self as galactic emperor and chaos breaks out!",
+                N_WARMONGER );
                 break;
             default:
                 pmessage(0, MALL, "GOD->ALL","Peace parties have been demobilized, and fighting ensues.");
@@ -618,7 +619,8 @@
                 pmessage(0, MALL, "GOD->ALL","Diplomat apologizes to foreign emperor's mother and invasion is stopped!");
                 break;
             case 6:
-                pmessage(0, MALL, "GOD->ALL","Dan Quayle is locked up and order returns to the galaxy!");
+                pmessage(0, MALL, "GOD->ALL","%s is locked up and order returns to the galaxy!",
+                N_WARMONGER );
                 break;
             default:
                 pmessage(0, MALL, "GOD->ALL","The peace party has reformed, and is rallying for peace");



From quozl at us.netrek.org  Tue Apr 11 05:44:46 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 11 Apr 2006 20:44:46 +1000
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <Pine.GSO.4.58.0604102230180.9945@sue>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
Message-ID: <20060411104446.GA5714@us.netrek.org>

I'm inclined to take the first patch over the second for technical
reasons, but I'd like some political confirmation from list members in
the United States of America that this is a proper thing to do.

N_FOO are file names.  We don't appear to have a collection of constants
for such names.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From xyzzy at speakeasy.org  Tue Apr 11 06:24:37 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 11 Apr 2006 04:24:37 -0700 (PDT)
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <20060411104446.GA5714@us.netrek.org>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<20060411104446.GA5714@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0604110421460.32255@shell2.speakeasy.net>

On Tue, 11 Apr 2006, James Cameron wrote:
> I'm inclined to take the first patch over the second for technical
> reasons, but I'd like some political confirmation from list members in
> the United States of America that this is a proper thing to do.

It's a very polarizing issue.  Quayle was a long time ago and therefore
much safer.  It also shows some of the history of netrek.


From quozl at us.netrek.org  Mon Apr 10 05:57:44 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 10 Apr 2006 20:57:44 +1000
Subject: [netrek-dev] Sb etemp fix.
In-Reply-To: <Pine.GSO.4.58.0604092239460.15344@sue>
References: <Pine.GSO.4.58.0604070021380.25922@sue>
	<20060410033200.GA1243@us.netrek.org>
	<ecfa260c0604092136pda198dfg6aaccf4735b37bb5@mail.gmail.com>
	<20060410052256.GD1243@us.netrek.org>
	<Pine.GSO.4.58.0604092239460.15344@sue>
Message-ID: <20060410105744.GG1243@us.netrek.org>

Patch as advised.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
Index: ChangeLog
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ChangeLog,v
retrieving revision 1.15
diff -u -r1.15 ChangeLog
--- ChangeLog	10 Apr 2006 10:30:44 -0000	1.15
+++ ChangeLog	10 Apr 2006 10:43:09 -0000
@@ -1,3 +1,32 @@
+Mon Apr 10 20:41:52 2006  James Cameron  <quozl at us.netrek.org>
+
+	* struct.h: deprecate p_docked and p_ports in favour of
+	p_dock_with, p_dock_bay, and p_bays, removing overloaded use.
+	
+	* proto.h, bay.c: add functions for starbase bay
+	maintenance and crosscheck.
+
+	* daemon.c: adopt new starbase bay maintenance, calculate etemp
+	based on number of bays in use rather than using a separate
+	counter, change some army count checks to prevent abuse.
+
+	* enter.c, interface.c, orbit.c, redraw.c, socket.c: adopt new
+	starbase bay maintenance.
+
+	* ntscmds.c: release starbase bay on eject ... vicious eject
+	prevents the explosion from running through the daemon logic,
+	resulting in inconsistency.  Reported by: William Balcerski
+
+	* xtkill.c: release starbase bay on intervention.
+
+Mon Apr 10 20:40:32 2006  James Cameron  <quozl at us.netrek.org>
+
+	* util.c: remove unnecessary includes.
+
+Mon Apr 10 20:38:15 2006  James Cameron  <quozl at us.netrek.org>
+
+	* main.c: fix compilation error on initialisation of p_ip.
+	
 Mon Apr 10 20:12:19 2006  James Cameron  <quozl at us.netrek.org>
 
 	* robots/inl.c (checkmess): fix compilation warning by renaming
Index: include/defs.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/defs.h,v
retrieving revision 1.3
diff -u -r1.3 defs.h
--- include/defs.h	28 Sep 2005 12:14:05 -0000	1.3
+++ include/defs.h	10 Apr 2006 10:43:11 -0000
@@ -134,7 +134,7 @@
 #define DOCKDIST 600
 #define DOCKSPEED 2     /* If base is moving, there will be some
 			   finesse involved to dock */
-#define NUMPORTS 4
+#define NUMBAYS 4	/* number of docking bays a starbase has */
 #define SBFUELMIN 10000   /* If starbase's fuel is less than this, it will not
 			   refuel docked vessels */
 #define TRACTDIST   6000 /* maximum effective tractor beam range */
Index: include/proto.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/proto.h,v
retrieving revision 1.3
diff -u -r1.3 proto.h
--- include/proto.h	15 Jun 2005 22:55:25 -0000	1.3
+++ include/proto.h	10 Apr 2006 10:43:11 -0000
@@ -6,6 +6,15 @@
 #ifndef __INCLUDED_proto_h__
 #define __INCLUDED_proto_h__
 
+/* bay.c */
+void bay_consistency_check(struct player *base);
+struct player *bay_owner(struct player *me);
+void bay_claim(struct player *base, struct player *me, int bay_no);
+void bay_release(struct player *me);
+void bay_release_all(struct player *base);
+void bay_init(struct player *me);
+int bay_closest(struct player *base, LONG dx, LONG dy);
+
 /* cluecheck.c */
 void clue_check(void);
 
Index: include/struct.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/struct.h,v
retrieving revision 1.3
diff -u -r1.3 struct.h
--- include/struct.h	10 Apr 2006 04:24:51 -0000	1.3
+++ include/struct.h	10 Apr 2006 10:43:13 -0000
@@ -370,9 +370,14 @@
     short p_planets;		/* planets taken this game */
     short p_armsbomb;		/* armies bombed this game */
     int p_ghostbuster;
-    int p_docked;		/* If starbase, # docked to, else pno base host */
-    int p_port[4];		/* If starbase, pno of ship docked to that port,
-				   else p_port[0] = port # docked to on host.   */
+
+    /* for starbases, if PFDOCKOK set */
+    int p_bays[NUMBAYS];        /* p_no of each docked ship, or VACANT */
+
+    /* for ships other than starbases, if p_flags PFDOCK set */
+    int p_dock_with;	        /* p_no of starbase we are docked with */
+    int p_dock_bay;	        /* bay of starbase we are docked with */
+
     short p_tractor;		/* What player is in tractor lock */
     int p_pos;			/* My position in the player file */
     int w_queue;		/* Waitqueue of my team */
Index: ntserv/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/Makefile.in,v
retrieving revision 1.3
diff -u -r1.3 Makefile.in
--- ntserv/Makefile.in	28 Sep 2005 12:14:05 -0000	1.3
+++ ntserv/Makefile.in	10 Apr 2006 10:43:15 -0000
@@ -22,14 +22,14 @@
 	    startrobot.o  sysdefaults.o  timecheck.o  torp.o  util.o  \
 	    warning.o ping.o $(RANDOMO) getpath.o $(STRDUPO) features.o \
 	    distress.o transwarp.o gencmds.o ntscmds.o openmem.o feature.o \
-	    queue.o slotmaint.o rsa_key.o ltd_stats.o
+	    queue.o slotmaint.o rsa_key.o ltd_stats.o bay.o
 
 
 #	daemonII object files
 
 D_OBJS =    daemonII.o  sintab.o  sysdefaults.o  data.o  slotmaint.o \
 	    util.o  $(RANDOMO) getpath.o getship.o smessage.o  queue.o \
-	    wander2.o openmem.o solicit.o ltd_stats.o
+	    wander2.o openmem.o solicit.o ltd_stats.o bay.o
 
 #	Src files
 
@@ -48,7 +48,8 @@
             ${srcdir}/features.c ${srcdir}/distress.c ${srcdir}/transwarp.c \
             ${srcdir}/gencmds.c ${srcdir}/ntscmds.c ${srcdir}/openmem.c \
             ${srcdir}/feature.c ${srcdir}/queue.c ${srcdir}/slotmaint.c \
-            ${srcdir}/wander2.c ${srcdir}/sysdefaults.c ${srcdir}/rsa_key.c
+            ${srcdir}/wander2.c ${srcdir}/sysdefaults.c ${srcdir}/rsa_key.c \
+            ${srcdir}/bay.c
 
 SRC = 	    $(R_FILES)  data.h  defs.h planets.h  struct.h \
 	    packets.h  copyright.h
Index: ntserv/daemonII.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
retrieving revision 1.3
diff -u -r1.3 daemonII.c
--- ntserv/daemonII.c	27 Sep 2005 12:26:37 -0000	1.3
+++ ntserv/daemonII.c	10 Apr 2006 10:43:27 -0000
@@ -927,13 +927,9 @@
                     j->p_explode = 600/PLAYERFUSE; /* set ghost buster */
                 }
 
-                /* At this point, docked ships become removed. */
-                if (j->p_flags & PFDOCK) {
-                    players[j->p_docked].p_docked--;
-                    players[j->p_docked].p_port[j->p_port[0]] = VACANT;
-                    j->p_flags &= ~PFDOCK;
-                } 
+                bay_release(j);
                 if (j->p_ship.s_type == STARBASE) {
+                    bay_release_all(j);
                     if (((j->p_whydead == KSHIP) || 
                             (j->p_whydead == KTORP) ||
                             (j->p_whydead == KPHASER) || 
@@ -942,16 +938,9 @@
                             (j->p_whydead == KGENOCIDE)) && (status->tourn))
                     teams[j->p_team].s_turns=BUILD_SB_TIME; /* in defs.h */
                         /* 30 minute reconstruction period for new starbase */
-                    for (k=0; k<NUMPORTS; k++) 
-                        if(j->p_port[k] != VACANT) {
-                            players[j->p_port[k]].p_flags &= ~PFDOCK;
-                            j->p_port[k] = VACANT;
-                        }
-                    j->p_docked = 0;
                 }
                 /* And he is ejected from orbit. */
-                if (j->p_flags & PFORBIT)
-                  j->p_flags &= ~PFORBIT;
+                j->p_flags &= ~PFORBIT;
 
                 /* Fall through to alive so explosions move */
                         
@@ -1016,10 +1005,13 @@
 
                         /* Charge SB's for mass of docked vessels ... */
                         if (j->p_ship.s_type == STARBASE) {
-                            for (k=0; k<NUMPORTS; k++) 
-                                if(j->p_port[k] != VACANT) 
-                                    j->p_fuel -= players[j->p_port[k]].p_ship.s_warpcost * j->p_speed;
-                                    j->p_etemp += .7*(j->p_speed * j->p_docked);
+			    int bays = 0;
+                            for (k=0; k<NUMBAYS; k++)
+                                if(j->p_bays[k] != VACANT) {
+                                    j->p_fuel -= players[j->p_bays[k]].p_ship.s_warpcost * j->p_speed;
+				    bays++;
+                                }
+			    j->p_etemp += .7*(j->p_speed * bays);
                         }
                     }
 #ifdef SB_TRANSWARP
@@ -1328,11 +1320,11 @@
                   j->p_fuel += 6 * j->p_ship.s_recharge;
                 } else if ((j->p_flags & PFDOCK) && 
                            (j->p_fuel < j->p_ship.s_maxfuel) &&
-                           (players[j->p_docked].p_fuel > SBFUELMIN)) {
+                           (players[j->p_dock_with].p_fuel > SBFUELMIN)) {
                   int fc = MIN(10*j->p_ship.s_recharge,
                                j->p_ship.s_maxfuel - j->p_fuel);
                   j->p_fuel += fc;
-                  players[j->p_docked].p_fuel -= fc;
+                  players[j->p_dock_with].p_fuel -= fc;
                 }
 #else
                 /* Add fuel */
@@ -1341,9 +1333,9 @@
                     (!(planets[j->p_planet].pl_owner & j->p_war))) {
                   j->p_fuel += 8 * j->p_ship.s_recharge;
                 } else if ((j->p_flags & PFDOCK) && (j->p_fuel < j->p_ship.s_maxfuel)) {
-                  if (players[j->p_docked].p_fuel > SBFUELMIN) {
+                  if (players[j->p_dock_with].p_fuel > SBFUELMIN) {
                     j->p_fuel += 12*j->p_ship.s_recharge;
-                    players[j->p_docked].p_fuel -= 12*j->p_ship.s_recharge;
+                    players[j->p_dock_with].p_fuel -= 12*j->p_ship.s_recharge;
                   }
                 } else
                   j->p_fuel += 2 * j->p_ship.s_recharge;
@@ -1418,8 +1410,8 @@
 
                 /* Move Player in dock */
                 if (j->p_flags & PFDOCK) {
-                    j->p_x = players[j->p_docked].p_x + DOCKDIST*Cos[(j->p_port[0]*90+45)*255/360];
-                    j->p_y = players[j->p_docked].p_y + DOCKDIST*Sin[(j->p_port[0]*90+45)*255/360];
+                    j->p_x = players[j->p_dock_with].p_x + DOCKDIST*Cos[(j->p_dock_bay*90+45)*255/360];
+                    j->p_y = players[j->p_dock_with].p_y + DOCKDIST*Sin[(j->p_dock_bay*90+45)*255/360];
                 }
 
                 /* Set player's alert status */
@@ -2939,9 +2931,9 @@
                 if (l->pl_armies < 5)
                     continue;
             if (j->p_flags & PFDOCK)
-                if (players[j->p_docked].p_armies == 0)
+                if (players[j->p_dock_with].p_armies < 1)
                     continue;
-            if (j->p_armies == j->p_ship.s_maxarmies)
+            if (j->p_armies >= j->p_ship.s_maxarmies)
                 continue;
             /* XXX */
             if (j->p_ship.s_type == ASSAULT) {
@@ -2969,13 +2961,13 @@
                 }
 #endif
 	    } else if (j->p_flags & PFDOCK) {
-                players[j->p_docked].p_armies--;
-		army_track(AMT_TRANSUP, j, &players[j->p_docked], 1);
+                struct player *base = bay_owner(j);
+                base->p_armies--;
+		army_track(AMT_TRANSUP, j, base, 1);
 
 #ifdef LTD_STATS
-                /* j = player, j->pdocked = friendly SB */
                 if (status->tourn) {
-                    ltd_update_armies_carried(j, &players[j->p_docked]);
+                    ltd_update_armies_carried(j, base);
                 }
 #endif
  
@@ -3242,18 +3234,18 @@
 
                 }
             } else if (j->p_flags & PFDOCK) {
-                if (players[j->p_docked].p_team != j->p_team)
+                struct player *base = bay_owner(j);
+                if (base->p_team != j->p_team)
                     continue;
-		if (players[j->p_docked].p_armies
-		    == players[j->p_docked].p_ship.s_maxarmies) {
+		if (base->p_armies >= base->p_ship.s_maxarmies) {
                     continue;
                 } else {
-		    army_track(AMT_TRANSDOWN, j, &players[j->p_docked], 1);
+		    army_track(AMT_TRANSDOWN, j, base, 1);
                     j->p_armies--;
-                    players[j->p_docked].p_armies ++;
+                    base->p_armies ++;
 #ifdef LTD_STATS
                     if (status->tourn) {
-                        ltd_update_armies_ferried(j, &players[j->p_docked]);
+                        ltd_update_armies_ferried(j, base);
                     }
 #endif /* LTD_STATS */
                         
Index: ntserv/enter.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/enter.c,v
retrieving revision 1.2
diff -u -r1.2 enter.c
--- ntserv/enter.c	21 Mar 2005 10:17:17 -0000	1.2
+++ ntserv/enter.c	10 Apr 2006 10:43:29 -0000
@@ -176,12 +176,10 @@
     me->p_lastseenby = VACANT;
     me->p_kills = 0.0;
     me->p_armies = 0;
-    me->p_docked = 0;
-    me->p_port[0] = VACANT;
-    me->p_port[1] = VACANT;
-    me->p_port[2] = VACANT;
-    me->p_port[3] = VACANT;
-/*    if (!keeppeace) me->p_hostile = (FED|ROM|KLI|ORI);*/
+    bay_init(me);
+    me->p_dock_with = 0;
+    me->p_dock_bay = 0;
+/*  if (!keeppeace) me->p_hostile = (FED|ROM|KLI|ORI); */
     if( !(me->p_flags & PFROBOT) && (me->p_team == NOBODY) ) {
       me->p_hostile = NOBODY;
       me->p_war = NOBODY;
Index: ntserv/interface.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/interface.c,v
retrieving revision 1.3
diff -u -r1.3 interface.c
--- ntserv/interface.c	22 Feb 2006 09:18:30 -0000	1.3
+++ ntserv/interface.c	10 Apr 2006 10:43:30 -0000
@@ -29,21 +29,15 @@
 	speed=0;
     }
     me->p_desspeed = speed;
-    if (me->p_flags & PFDOCK) {
-	players[me->p_docked].p_docked--;
-	players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-    }
-    me->p_flags &= ~(PFREPAIR | PFBOMB | PFORBIT | PFDOCK | PFBEAMUP | PFBEAMDOWN);
+    bay_release(me);
+    me->p_flags &= ~(PFREPAIR | PFBOMB | PFORBIT | PFBEAMUP | PFBEAMDOWN);
 }
 
 void set_course(u_char dir)
 {
     me->p_desdir = dir;
-    if (me->p_flags & PFDOCK) {
-	players[me->p_docked].p_docked--;
-	players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-    }
-    me->p_flags &= ~(PFBOMB | PFORBIT | PFDOCK | PFBEAMUP | PFBEAMDOWN);
+    bay_release(me);
+    me->p_flags &= ~(PFBOMB | PFORBIT | PFBEAMUP | PFBEAMDOWN);
 }
 
 void shield_up(void)
@@ -156,7 +150,7 @@
 	    return;
 	}
     } else if (me->p_flags & PFDOCK) {
-	if (me->p_team != players[me->p_docked].p_team) {
+	if (me->p_team != players[me->p_dock_with].p_team) {
             new_warning(46,"Comm Officer: We're not authorized to beam foriegn troops on board!");
 	    return;
 	}
@@ -185,7 +179,7 @@
 #endif
 
     if (me->p_flags & PFDOCK) {
-        if (me->p_team != players[me->p_docked].p_team) {
+        if (me->p_team != players[me->p_dock_with].p_team) {
             new_warning(48,"Comm Officer: Starbase refuses permission to beam our troops over.");
 	    return;
         }
@@ -312,16 +306,10 @@
     if (hypot((double) me->p_x-victim->p_x,
 	    (double) me->p_y-victim->p_y) < 
 	    ((double) TRACTDIST) * me->p_ship.s_tractrng) {
-	if (victim->p_flags & PFDOCK) {
-	    players[victim->p_docked].p_port[victim->p_port[0]] = VACANT;
-	    players[victim->p_docked].p_docked--;
-	}
-	if (me->p_flags & PFDOCK) {
-	    players[me->p_docked].p_docked--;
-	    players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-	}
-	victim->p_flags &= ~(PFORBIT | PFDOCK);
-	me->p_flags &= ~(PFORBIT | PFDOCK);
+	bay_release(victim);
+	bay_release(me);
+	victim->p_flags &= ~PFORBIT;
+	me->p_flags &= ~PFORBIT;
 	me->p_tractor = player;
 	me->p_flags |= PFTRACT;
     } else {			/* out of range */
@@ -357,14 +345,8 @@
     if (hypot((double) me->p_x-victim->p_x,
 	      (double) me->p_y-victim->p_y) < 
 	((double) TRACTDIST) * me->p_ship.s_tractrng) {
-	if (victim->p_flags & PFDOCK) {
-	    players[victim->p_docked].p_port[victim->p_port[0]] = VACANT;
-	    players[victim->p_docked].p_docked--;
-	}
-	if (me->p_flags & PFDOCK) {
-	    players[me->p_docked].p_docked--;
-	    players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-	}
+	bay_release(victim);
+	bay_release(me);
 	victim->p_flags &= ~(PFORBIT | PFDOCK);
 	me->p_flags &= ~(PFORBIT | PFDOCK);
 	me->p_tractor = target;
@@ -408,21 +390,18 @@
 	sendwarn("Orions", mask & ORI, ORI);
     }
     if (me->p_flags & PFDOCK) {
-	if (players[me->p_docked].p_team & mask) {
-	    players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-	    players[me->p_docked].p_docked--;
-	    me->p_flags &= ~PFDOCK;
+	if (players[me->p_dock_with].p_team & mask) {
+	    /* release ship from starbase that is now hostile */
+	    bay_release(me);
 	}
-    } else if (me->p_ship.s_type == STARBASE) {
-	if (me->p_docked > 0) {
-	    for(i=0; i<NUMPORTS; i++) {
-		if (me->p_port[i] == VACANT)   /* isae -- Ted's fix */
-                  continue;
-		if (mask & players[me->p_port[i]].p_team) {
-		    players[me->p_port[i]].p_flags &= ~PFDOCK;
-		    me->p_docked--;
-		    me->p_port[i] = VACANT;
-		}
+    }
+    if (me->p_ship.s_type == STARBASE) {
+        for(i=0; i<NUMBAYS; i++) {
+	    if (me->p_bays[i] == VACANT)
+                continue;
+	    if (mask & players[me->p_bays[i]].p_team) {
+	        /* release docked ships that are now hostile */
+	        bay_release(&players[me->p_bays[i]]);
 	    }
 	}
     }
@@ -486,7 +465,7 @@
             new_warning(52,"Can only refit to starbase on your home planet.");
 	    return;
 	}
-	if (players[me->p_docked].p_team != me->p_team) {
+	if (players[me->p_dock_with].p_team != me->p_team) {
             new_warning(53,"You must dock YOUR starbase to apply for command reassignment!");
 	    return;
 	}
@@ -573,12 +552,7 @@
 	/* Reset kills to 0.0 */
 	me->p_kills=0;
 	/* bump all docked ships */
-	for (i=0; i<NUMPORTS; i++) 
-	   if (me->p_port[i] != VACANT) {
-		players[me->p_port[i]].p_flags &= ~PFDOCK;
-		me->p_docked--;
-		me->p_port[i] = VACANT;	
-	   }
+	bay_release_all(me);
 	me->p_flags |= PFDOCKOK;
     }	
 
@@ -622,8 +596,7 @@
     me->p_etime = 0;
     me->p_ship.s_type = type;
     if (type == STARBASE) {
-	me->p_docked = 0;
-	for (i=0; i<4; i++) me->p_port[i] = VACANT;
+	bay_init(me);
 	me->p_flags |= PFDOCKOK;
     }
 
Index: ntserv/ntscmds.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/ntscmds.c,v
retrieving revision 1.4
diff -u -r1.4 ntscmds.c
--- ntserv/ntscmds.c	10 Apr 2006 04:24:51 -0000	1.4
+++ ntserv/ntscmds.c	10 Apr 2006 10:43:33 -0000
@@ -297,8 +297,10 @@
   j->p_ship.s_type = STARBASE;
   j->p_whydead=KQUIT;
   j->p_explode=10;
+  /* note VICIOUS_EJECT prevents animation of ship explosion */
   j->p_status=PEXPLODE;
   j->p_whodead=me->p_no;
+  bay_release(j);
 }
 #endif /* ALLOW_EJECT */
 
Index: ntserv/orbit.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/orbit.c,v
retrieving revision 1.2
diff -u -r1.2 orbit.c
--- ntserv/orbit.c	21 Mar 2005 10:17:17 -0000	1.2
+++ ntserv/orbit.c	10 Apr 2006 10:43:34 -0000
@@ -29,27 +29,10 @@
 #define TRUE 1
 #endif
 
-/*
- * If there are bugs in this docking code and/or possibly other places
- * in the code, then conceivably a base my have p_docked < 4 while
- * all ports are non-VACANT.  That is inconsistent, and this code
- * will check for that eventuality on the fly.
- */
-#if 1
-#define RETURN_IF_VACANT(base, port)
-#else
-#define RETURN_IF_VACANT(base, port) \
-        if (base->p_port[port] != VACANT) { \
-	  ERROR(1, ("Starbase %d has no ports vacant but p_docked==%d\n", \
-		    base->p_id, base->p_docked)); \
-	  return FALSE; \
-	}
-#endif
-
 void de_lock(struct player *me)
 {
   me->p_flags   &= ~(PFPLOCK | PFPLLOCK | PFTRACT | PFPRESS);
- #ifdef SB_TRANSWARP
+#ifdef SB_TRANSWARP
   if (me->p_flags & PFTWARP){
     me->p_flags &= ~PFTWARP;
     me->p_flags |= PFREFITTING;
@@ -64,14 +47,14 @@
  * (If one or more of these is not true, various nasty things happen.)
  */ 
 
-#define DOCK_NO_BASE 0
-#define DOCK_FAILURE 1
-#define DOCK_SUCCESS 2
+#define DOCK_NO_BASE 0 /* no base is close enough */
+#define DOCK_FAILURE 1 /* dock failed due to some condition */
+#define DOCK_SUCCESS 2 /* dock was successful */
 
 static int dock(struct player *base)
 {
   LONG dx, dy;
-  int port_id;
+  int bay_no;
   u_char dir_from_base;
 
   /*
@@ -124,90 +107,28 @@
   }
   
   /*
-   * Make sure the base's docking ports are not already full: */
-  if (base->p_docked >= NUMPORTS) {
+   * Make sure the base's docking bays are not already full: */
+  bay_no = bay_closest(base, dx, dy);
+  if (bay_no == -1) {
     if (send_short)
       swarning(SBDOCKDENIED_TEXT, base->p_no, 0);
     else
-      new_warning(UNDEF, "Starbase %s: Permission to dock denied, all ports currently occupied.", base->p_name);
+      new_warning(UNDEF, "Starbase %s: Permission to dock denied, all bays currently occupied.", base->p_name);
     de_lock(me);
     return DOCK_FAILURE;
   }
 
   /*
-   * Dock on closest port.
-   * A starbase's ports are     3    0
-   * numbered as in this          ()
-   * picture:                   2    1                       */
-  if (dx > 0) {
-    /* We are to the left of the base: */
-    if (dy > 0) {
-      /* Above and to left of base: */
-      if (base->p_port[3] == VACANT)
-	port_id = 3;
-      else if (base->p_port[2] == VACANT)
-	port_id = 2;
-      else if (base->p_port[0] == VACANT) 
-	port_id = 0;
-      else {
-	RETURN_IF_VACANT(base, 1);
-	port_id = 1;
-      }
-    } else {
-      /* Below and to left of base: */
-      if (base->p_port[2] == VACANT)
-	port_id = 2;
-      else if (base->p_port[3] == VACANT)
-	port_id = 3;
-      else if (base->p_port[1] == VACANT) 
-	port_id = 1;
-      else {
-	RETURN_IF_VACANT(base, 0);
-	port_id = 0;
-      }
-    }
-  } else {
-    /* We are to the right of the base: */
-    if (dy > 0) {
-      /* Above and to right of base: */
-      if (base->p_port[0] == VACANT)
-	port_id = 0;
-      else if (base->p_port[1] == VACANT)
-	port_id = 1;
-      else if (base->p_port[3] == VACANT) 
-	port_id = 3;
-      else {
-	RETURN_IF_VACANT(base, 2);
-	port_id = 2;
-      }
-    } else {
-      /* Below and to right of base: */
-      if (base->p_port[1] == VACANT)
-	port_id = 1;
-      else if (base->p_port[2] == VACANT)
-	port_id = 2;
-      else if (base->p_port[0] == VACANT) 
-	port_id = 0;
-      else {
-	RETURN_IF_VACANT(base, 3);
-	port_id = 3;
-      }
-    }
-  }
-
-  /*
    * Adjust player structures of myself and the base. */
-  dir_from_base = ((port_id * 90 + 45) * 256) / 360;
-  me->p_flags   &= ~(PFPLOCK | PFPLLOCK | PFTRACT | PFPRESS);
-  me->p_flags   |= PFDOCK;
-  me->p_dir      = 64 + dir_from_base;
-  me->p_desdir   = me->p_dir;
-  me->p_x        = base->p_x + DOCKDIST * Cos[dir_from_base];
-  me->p_y        = base->p_y + DOCKDIST * Sin[dir_from_base];
-  me->p_speed    = 0;
-  me->p_desspeed = 0;
-  me->p_docked   = base->p_no;
-  me->p_port[0]  = port_id;
+  dir_from_base   = ((bay_no * 90 + 45) * 256) / 360;
+  me->p_flags    &= ~(PFPLOCK | PFPLLOCK | PFTRACT | PFPRESS);
+  me->p_flags    |= PFDOCK;
+  me->p_dir       = 64 + dir_from_base;
+  me->p_desdir    = me->p_dir;
+  me->p_x         = base->p_x + DOCKDIST * Cos[dir_from_base];
+  me->p_y         = base->p_y + DOCKDIST * Sin[dir_from_base];
+  me->p_speed     = 0;
+  me->p_desspeed  = 0;
 #ifdef SB_TRANSWARP
   if (me->p_flags & PFTWARP){
     me->p_flags &= ~PFTWARP;
@@ -216,15 +137,14 @@
   }
 #endif
 
-  base->p_docked++;
-  base->p_port[port_id] = me->p_no;
+  bay_claim(base, me, bay_no);
 
   /*
    * Notify player of success. */
   if (send_short)
-    swarning(ONEARG_TEXT, 2, port_id);
+    swarning(ONEARG_TEXT, 2, bay_no);
   else
-    new_warning(UNDEF,"Helmsman:  Docking manuever completed Captain.  All moorings secured at port %d.", port_id);
+    new_warning(UNDEF,"Helmsman:  Docking manuever completed Captain.  All moorings secured at bay %d.", bay_no);
   return DOCK_SUCCESS;
 }
 
Index: ntserv/redraw.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/redraw.c,v
retrieving revision 1.1
diff -u -r1.1 redraw.c
--- ntserv/redraw.c	21 Mar 2005 05:23:44 -0000	1.1
+++ ntserv/redraw.c	10 Apr 2006 10:43:36 -0000
@@ -213,14 +213,12 @@
 #define NOOBSMASK	(PFSELFDEST|PFPLOCK|PFPLLOCK|PFOBSERV)
 	  me->p_flags = (pl->p_flags & ~NOOBSMASK) | (me->p_flags & NOOBSMASK);
 	  
-	  /* always cloaked, state of person watched will be obvious */
-	  /* me->p_flags |= PFCLOAK; */
 	  me->p_dir = pl->p_dir;
 	  me->p_tractor = pl->p_tractor;
-	  me->p_docked = pl->p_docked;
+	  me->p_dock_with = pl->p_dock_with;
+	  me->p_dock_bay = pl->p_dock_bay;
 	  me->p_planet = pl->p_planet;
 	  me->p_speed = pl->p_speed;
-	  /* me->p_kills = pl->p_kills;  Very bad: will confuse enemies */
 	}
 	return;
     }  /* end if I am locked onto a player */
@@ -439,10 +437,11 @@
 		      planets[me->p_planet].pl_armies);
 	    
 	} else if (me->p_flags & PFDOCK) {
-	    if (players[me->p_docked].p_armies == 0) {
+	    struct player *base = bay_owner(me);
+	    if (base->p_armies <= 0) {
 		txt = "Too few armies to beam up";
 		me->p_flags &= ~PFBEAMUP;
-	    } else if (me->p_armies == troop_capacity) {
+	    } else if (me->p_armies >= troop_capacity) {
 		txt = "No more room on board for armies";
 		me->p_flags &= ~PFBEAMUP;
 	    } else {
@@ -452,8 +451,8 @@
 			txt,
 			me->p_armies,
 			troop_capacity,
-			players[me->p_docked].p_name,
-			players[me->p_docked].p_armies);
+			base->p_name,
+			base->p_armies);
 	}
     }
 
@@ -475,13 +474,13 @@
 		      planets[me->p_planet].pl_armies);
 
 	} else if (me->p_flags & PFDOCK) {
-	    if (me->p_armies == 0) {
+	    struct player *base = bay_owner(me);
+	    if (me->p_armies <= 0) {
 		txt = "No more armies to beam down";
 		me->p_flags &= ~PFBEAMDOWN;
-	    } else if (players[me->p_docked].p_armies ==
-		players[me->p_docked].p_ship.s_maxarmies) {
-	      txt = "All troop bunkers are full";
-	      me->p_flags &= ~PFBEAMDOWN;
+	    } else if (base->p_armies >= base->p_ship.s_maxarmies) {
+	        txt = "All troop bunkers are full";
+	        me->p_flags &= ~PFBEAMDOWN;
 	    } else {
 	        txt = "Transfering ground units";
 	    }
@@ -489,8 +488,8 @@
 			txt,
 			me->p_armies,
 			troop_capacity,
-			players[me->p_docked].p_name,
-			players[me->p_docked].p_armies);
+			base->p_name,
+			base->p_armies);
 	}
     }
 
Index: ntserv/socket.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/socket.c,v
retrieving revision 1.4
diff -u -r1.4 socket.c
--- ntserv/socket.c	10 Apr 2006 04:24:51 -0000	1.4
+++ ntserv/socket.c	10 Apr 2006 10:43:45 -0000
@@ -1213,12 +1213,8 @@
     if (packet->state) {
 	orbit();
     } else {
+	bay_release(me);
 	me->p_flags &= ~PFORBIT;
-	if (me->p_flags & PFDOCK) {
-	    players[me->p_docked].p_docked--;
-	    players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-	    me->p_flags &= ~PFDOCK;
-	}
     }
 }
 
@@ -1402,21 +1398,15 @@
 	return;
     }
     if (target<0 || target>=MAXPLAYER || target==me->p_no) return;
-    player= &players[target];
+    player = &players[target];
     if (player->p_flags & PFCLOAK) return;
     if (hypot((double) me->p_x-player->p_x,
 	      (double) me->p_y-player->p_y) < 
 	((double) TRACTDIST) * me->p_ship.s_tractrng) {
-	if (player->p_flags & PFDOCK) {
-	    players[player->p_docked].p_port[player->p_port[0]] = VACANT;
-	    players[player->p_docked].p_docked--;
-	}
-	if (me->p_flags & PFDOCK) {
-	    players[me->p_docked].p_docked--;
-	    players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-	}
-	player->p_flags &= ~(PFORBIT | PFDOCK);
-	me->p_flags &= ~(PFORBIT | PFDOCK);
+	bay_release(player);
+	bay_release(me);
+	player->p_flags &= ~PFORBIT;
+	me->p_flags &= ~PFORBIT;
 	me->p_tractor = target;
 	me->p_flags |= PFTRACT;
     } else {
@@ -1448,16 +1438,10 @@
     if (hypot((double) me->p_x-player->p_x,
 	      (double) me->p_y-player->p_y) < 
 	((double) TRACTDIST) * me->p_ship.s_tractrng) {
-	if (player->p_flags & PFDOCK) {
-	    players[player->p_docked].p_port[player->p_port[0]] = VACANT;
-	    players[player->p_docked].p_docked--;
-	}
-	if (me->p_flags & PFDOCK) {
-	    players[me->p_docked].p_docked--;
-	    players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-	}
-	player->p_flags &= ~(PFORBIT | PFDOCK);
-	me->p_flags &= ~(PFORBIT | PFDOCK);
+	bay_release(player);
+	bay_release(me);
+	player->p_flags &= ~PFORBIT;
+	me->p_flags &= ~PFORBIT;
 	me->p_tractor = target;
 	me->p_flags |= (PFTRACT | PFPRESS);
     } else {
@@ -1736,16 +1720,12 @@
     int i;
 
     if (me->p_ship.s_type == STARBASE) {
-	me->p_docked = 0;
-	for (i=0; i<NUMPORTS; i++) {
-	    if (me->p_port[i] != VACANT)
-		players[me->p_port[i]].p_flags &= ~PFDOCK;
-	    me->p_port[i] = VACANT;  
-	}
-	if (packet->state) 
-	    me->p_flags |= PFDOCKOK;
-	else
-	    me->p_flags &= ~PFDOCKOK;
+        if (packet->state) {
+            me->p_flags |= PFDOCKOK;
+        } else {
+            me->p_flags &= ~PFDOCKOK;
+            bay_release_all(me);
+        }
     }
 }
 
Index: robotd/defs.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/robotd/defs.h,v
retrieving revision 1.2
diff -u -r1.2 defs.h
--- robotd/defs.h	28 Sep 2005 12:14:05 -0000	1.2
+++ robotd/defs.h	10 Apr 2006 10:43:45 -0000
@@ -40,7 +40,6 @@
 #define DOCKDIST 600
 #define DOCKSPEED 2     /* If base is moving, there will be some
 			   finesse involved to dock */
-#define NUMPORTS 4
 #define SBFUELMIN 10000   /* If starbase's fuel is less than this, it will not
 			   refuel docked vessels */
 #define TRACTDIST   6000 /* maximum effective tractor beam range */
Index: robotd/struct.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/robotd/struct.h,v
retrieving revision 1.1
diff -u -r1.1 struct.h
--- robotd/struct.h	21 Mar 2005 05:23:45 -0000	1.1
+++ robotd/struct.h	10 Apr 2006 10:43:46 -0000
@@ -199,9 +199,6 @@
     short p_planets;		/* planets taken this game */
     short p_armsbomb;		/* armies bombed this game */
     int p_ghostbuster;
-    int p_docked;		/* If starbase, # docked to, else pno base host */
-    int p_port[4];		/* If starbase, pno of ship docked to that port,
-				   else p_port[0] = port # docked to on host.   */
     short p_tractor;		/* What player is in tractor lock */
     int p_pos;			/* My position in the player file */
 };
Index: robots/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/robots/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- robots/Makefile.in	21 Mar 2005 10:17:18 -0000	1.2
+++ robots/Makefile.in	10 Apr 2006 10:43:46 -0000
@@ -30,7 +30,8 @@
 	../ntserv/orbit.o ../ntserv/phaser.o ../ntserv/sintab.o \
 	../ntserv/openmem.o  sysdefaults.o ../ntserv/torp.o  \
 	../ntserv/util.o $(RANDOMO) ../ntserv/getpath.o ../ntserv/smessage.o \
-	roboshar.o ../ntserv/slotmaint.o ../ntserv/distress.o ../ntserv/ltd_stats.o
+	roboshar.o ../ntserv/slotmaint.o ../ntserv/distress.o \
+	../ntserv/ltd_stats.o ../ntserv/bay.o 
 
 #	Puck Objects
 
Index: tools/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/tools/Makefile.in,v
retrieving revision 1.4
diff -u -r1.4 Makefile.in
--- tools/Makefile.in	22 Feb 2006 09:18:30 -0000	1.4
+++ tools/Makefile.in	10 Apr 2006 10:43:47 -0000
@@ -21,14 +21,10 @@
 
 TOOLDIR= $(LIBDIR)/tools
 
-GETPATH = ../ntserv/getpath.o ../ntserv/data.o
-
 LINTFLAGS = -habxc $(EXTRAINCS) $(FLAGS)
 
-#     Memory Objects
-
-M_OBJS = ../ntserv/data.o ../ntserv/openmem.o ../ntserv/ltd_stats.o
-
+OBJS_SHM = ../ntserv/data.o ../ntserv/openmem.o ../ntserv/ltd_stats.o
+OBJS_PATH = ../ntserv/getpath.o ../ntserv/data.o
 
 SRCS = ${srcdir}/blotpassword.c ${srcdir}/loadchecker.c ${srcdir}/mess.c \
 	${srcdir}/mergescores.c \
@@ -43,7 +39,7 @@
 	${srcdir}/conq_vert.c ${srcdir}/../ntserv/slotmaint.c $(RANDOMC) \
 	${srcdir}/sortdb.c ${srcdir}/../robots/roboshar.c \
 	${srcdir}/../ntserv/smessage.c ${srcdir}/ntpasswd.c \
-	${srcdir}/../ntserv/salt.c
+	${srcdir}/../ntserv/salt.c ${srcdir}/../ntserv/bay.c 
 
 EXECS =	blotpassword loadchecker mess message newscores planets players \
 	scores \
@@ -93,85 +89,80 @@
 # cb_sock.o: packets.h ../ntserv/socket.c
 #	$(CC) -o ./cb_sock.o -g $(CFLAGS) -DCAMBOT -c ../ntserv/socket.c
 
-cambot: cambot.o $(M_OBJS) $(GETPATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} cambot.o ../ntserv/genspkt.o ../ntserv/sysdefaults.o ../ntserv/getship.o ../ntserv/warning.o ../ntserv/smessage.o ../ntserv/distress.o ../ntserv/util.o $(M_OBJS) ../ntserv/getpath.o  $(RSA_LIB)
+cambot: cambot.o $(OBJS_SHM) $(OBJS_PATH)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} cambot.o ../ntserv/genspkt.o ../ntserv/sysdefaults.o ../ntserv/getship.o ../ntserv/warning.o ../ntserv/smessage.o ../ntserv/distress.o ../ntserv/util.o $(OBJS_SHM) ../ntserv/getpath.o  $(RSA_LIB)
 
 sortdb: sortdb.o
 	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} sortdb.o
 
-ntpasswd: ntpasswd.o $(GETPATH) ../ntserv/salt.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} ntpasswd.o $(GETPATH) ../ntserv/salt.o $(LIBCRYPT)
+ntpasswd: ntpasswd.o $(OBJS_PATH) ../ntserv/salt.o
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} ntpasswd.o $(OBJS_PATH) ../ntserv/salt.o $(LIBCRYPT)
 
-loadchecker: loadchecker.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} loadchecker.o $(M_OBJS) $(LIBS)
+loadchecker: loadchecker.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} loadchecker.o $(OBJS_SHM) $(LIBS)
 
-mess: mess.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mess.o $(M_OBJS) $(LIBS)
+mess: mess.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mess.o $(OBJS_SHM) $(LIBS)
 
-message: message.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} message.o $(M_OBJS) $(LIBS)
+message: message.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} message.o $(OBJS_SHM) $(LIBS)
 
-mergescores: mergescores.o $(GETPATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mergescores.o $(GETPATH) $(LIBS)
+mergescores: mergescores.o $(OBJS_PATH)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mergescores.o $(OBJS_PATH) $(LIBS)
 
-newscores: newscores.o $(GETPATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} newscores.o $(GETPATH) $(LIBS)
+newscores: newscores.o $(OBJS_PATH)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} newscores.o $(OBJS_PATH) $(LIBS)
 
-planets: planets.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} planets.o $(M_OBJS) $(LIBS)
+planets: planets.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} planets.o $(OBJS_SHM) $(LIBS)
 
-players: players.o $(M_OBJS) $(RANDOMO)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} players.o $(M_OBJS) $(RANDOMO) $(LIBS)
+players: players.o $(OBJS_SHM) $(RANDOMO)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} players.o $(OBJS_SHM) $(RANDOMO) $(LIBS)
 
-nuke: nuke.o $(M_OBJS) $(RANDOMO)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} nuke.o $(M_OBJS) $(RANDOMO) $(LIBS)
+nuke: nuke.o $(OBJS_SHM) $(RANDOMO)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} nuke.o $(OBJS_SHM) $(RANDOMO) $(LIBS)
 
-# some weird problem with the MIPS RISC compiler for DECstations...
-# gcc seems to compile working executables (TC)
-#
-scores: scores.o $(GETPATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} scores.o $(GETPATH) $(LIBS) ../ntserv/ltd_stats.o
-#	gcc -o $@ $(CFLAGS) -g scores.o -L/usr/users/terence/lib
-#	cp scores /usr/users/terence/bin/trekscores
+scores: scores.o $(OBJS_PATH)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} scores.o $(OBJS_PATH) $(LIBS) ../ntserv/ltd_stats.o
 
-setgalaxy: setgalaxy.o $(RANDOMO) $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} setgalaxy.o $(RANDOMO) $(M_OBJS) $(LIBS)
+setgalaxy: setgalaxy.o $(RANDOMO) $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} setgalaxy.o $(RANDOMO) $(OBJS_SHM) $(LIBS)
 
-showgalaxy: showgalaxy.o ../ntserv/distress.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} showgalaxy.o ../ntserv/distress.o $(M_OBJS) $(LIBS) $(LIBCURSES) $(LIBTERMCAP)
+showgalaxy: showgalaxy.o ../ntserv/distress.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} showgalaxy.o ../ntserv/distress.o $(OBJS_SHM) $(LIBS) $(LIBCURSES) $(LIBTERMCAP)
 
-stat: stat.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} stat.o $(M_OBJS) $(LIBS)
+stat: stat.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} stat.o $(OBJS_SHM) $(LIBS)
 
 blotpassword: blotpassword.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} blotpassword.o $(GETPATH) $(LIBS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} blotpassword.o $(OBJS_PATH) $(LIBS)
 
-trimscores: trimscores.o $(GETPATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} trimscores.o $(GETPATH) $(LIBS)
+trimscores: trimscores.o $(OBJS_PATH)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} trimscores.o $(OBJS_PATH) $(LIBS)
 
-watchmes: watchmes.o ../ntserv/distress.o $(M_OBJS)
-	$(CC) $(CFLAGS) ${LDFLAGS} watchmes.o ../ntserv/distress.o $(M_OBJS) $(LIBS) -o $@
+watchmes: watchmes.o ../ntserv/distress.o $(OBJS_SHM)
+	$(CC) $(CFLAGS) ${LDFLAGS} watchmes.o ../ntserv/distress.o $(OBJS_SHM) $(LIBS) -o $@
 
-xtkill: xtkill.o $(GETPATH) ../ntserv/getship.o ../ntserv/openmem.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} xtkill.o ../ntserv/getship.o ../ntserv/openmem.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o $(GETPATH) $(LIBS)
+xtkill: xtkill.o $(OBJS_SHM) $(OBJS_PATH) ../ntserv/getship.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o ../ntserv/bay.o
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} xtkill.o ../ntserv/getship.o ../ntserv/openmem.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o ../ntserv/bay.o $(OBJS_PATH) $(LIBS)
 
-keyman: keyman.o $(GETPATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} keyman.o $(GETPATH) $(LIBS)
+keyman: keyman.o $(OBJS_PATH)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} keyman.o $(OBJS_PATH) $(LIBS)
 
-fun: $(RANDOMO) fun.o $(M_OBJS)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} fun.o $(RANDOMO) $(M_OBJS) $(LIBS)
+fun: $(RANDOMO) fun.o $(OBJS_SHM)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} fun.o $(RANDOMO) $(OBJS_SHM) $(LIBS)
 
-convert: $(GETPATH) convert.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} convert.o $(GETPATH) $(LIBS)
+convert: $(OBJS_PATH) convert.o
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} convert.o $(OBJS_PATH) $(LIBS)
 
-updated: update.o $(GETPATH)
-	$(CC) $(CFLAGS) ${LDFLAGS} -o updated update.o ../ntserv/ltd_stats.o $(GETPATH) $(EXTRALIBS)
+updated: update.o $(OBJS_PATH)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o updated update.o ../ntserv/ltd_stats.o $(OBJS_PATH) $(EXTRALIBS)
 
 ltd_dump: ltd_dump.o
-	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_dump ltd_dump.o ../ntserv/ltd_stats.o $(GETPATH)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_dump ltd_dump.o ../ntserv/ltd_stats.o $(OBJS_PATH)
 
 ltd_convert: ltd_convert.o
-	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_convert ltd_convert.o ../ntserv/ltd_stats.o $(GETPATH)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_convert ltd_convert.o ../ntserv/ltd_stats.o $(OBJS_PATH)
 
 conq_vert: conq_vert.o
 	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} conq_vert.o
Index: tools/xtkill.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/tools/xtkill.c,v
retrieving revision 1.4
diff -u -r1.4 xtkill.c
--- tools/xtkill.c	10 Apr 2006 04:24:51 -0000	1.4
+++ tools/xtkill.c	10 Apr 2006 10:43:48 -0000
@@ -34,14 +34,8 @@
     me->p_desspeed = me->p_ship.s_maxspeed;
 
   /* bump all docked ships */
-  for (i=0; i<NUMPORTS; i++) 
-    if (me->p_port[i] != VACANT) {
-      players[me->p_port[i]].p_flags &= ~PFDOCK;
-      me->p_docked--;
-      me->p_port[i] = VACANT;	
-      me->p_flags |= PFDOCKOK;
-    }
-
+  bay_release_all(me);
+  me->p_flags |= PFDOCKOK;
 }
 
 int main(int argc, char **argv)
@@ -258,11 +252,8 @@
       me->p_flags &= ~PFCLOAK;
       /* set speed 0 */
       me->p_desspeed = 0;
-      if (me->p_flags & PFDOCK) {
-	players[me->p_docked].p_docked--;
-	players[me->p_docked].p_port[me->p_port[0]] = VACANT;
-      }
-      me->p_flags &= ~(PFREPAIR | PFBOMB | PFORBIT | PFDOCK | PFBEAMUP | PFBEAMDOWN);
+      bay_release(me);
+      me->p_flags &= ~(PFREPAIR | PFBOMB | PFORBIT | PFBEAMUP | PFBEAMDOWN);
       /* make unable to act */
       players[player].p_flags |= PFTWARP;
       /* show as puck */
-------------- 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/20060410/18b7f918/attachment-0001.pgp 

From williamb at its.caltech.edu  Wed Apr 12 06:40:44 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 12 Apr 2006 04:40:44 -0700 (PDT)
Subject: [netrek-dev] Documentation changes
Message-ID: <Pine.GSO.4.58.0604120439150.11109@clyde>

Removing bugs/projects that have been fixed/completed.

Index: BUGS
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/BUGS,v
retrieving revision 1.3
diff -u -r1.3 BUGS
--- BUGS        5 Apr 2006 04:42:40 -0000       1.3
+++ BUGS        12 Apr 2006 11:38:00 -0000
@@ -4,7 +4,8 @@
 List of things that are defects

        - Player "^%^" took a planet and it said "Planet taken by ^"
-         reported by zu22 (Zach Uram) on 2006-04-05
+         reported by zu22 (Zach Uram) on 2006-04-05.  This is also
+         a client issue.

        - god observer should see all teams messages.

@@ -61,8 +62,3 @@
        - change metaserver solicitation to process multiple IP addresses from
          each DNS host name given, just like new COW metaserver code.
          [coding in progress by cameron at stl.dec.com]
-
-       - starbase etemp bug, still shows up, engine cooling rate reduced,
-         warp 2 gives stable etemp, under those conditions it should drop
-         slowly at warp 2,
-
Index: PROJECTS
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/PROJECTS,v
retrieving revision 1.4
diff -u -r1.4 PROJECTS
--- PROJECTS    10 Apr 2006 04:24:50 -0000      1.4
+++ PROJECTS    12 Apr 2006 11:38:00 -0000
@@ -59,7 +59,7 @@
          galactic is recently reset.  Jerub expressed an interest in doing it.

        - If you are observing a friendly player who is t-warping, you
-         can lock on to other players/planets, but will not swap to
+         can lock on to other players, but you will not swap to
          their viewpoint.  Only when twarping is over, you can swap
          again [Shadow.Hunter at netrek.org]

@@ -177,9 +177,6 @@
          the current head of queue player.  May require client changes.
          [ref findslot() in cow, c/- carlos - quozl]

-       - observers do not see tractors and pressors ... fault of protocol,
-         according to Trent Piepho (xyzzy at u.washington.edu)
-
         - Observer system is screwed up.  Needs major re-write.  Items
           of note:




From williamb at its.caltech.edu  Thu Apr 13 08:01:56 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Thu, 13 Apr 2006 06:01:56 -0700 (PDT)
Subject: [netrek-dev] Weirdness in bombing kill credit
Message-ID: <Pine.GSO.4.58.0604130543120.3355@inky>

I was looking into a reported bug today regarding AS ships not showing the
proper "max armies you can carry" on the dashboard if the player's kills
is .33, 1.33, 2.33 etc.  To test this out, I used an AS ship and got
kills exclusively through bombing.  At .33 kills displayed, the server
lets the player carry 1 army, but the dashboard display max army capacity
of 0 (for both cow and netrekXP btw).

I went to the vanilla source, and looking at the code, each army bombed
should be worth .02 kills.  However, in practice, something else happens.  At
what seems a 50/50 chance, sometimes an army is worth .20000 kills and
sometimes it is worth .19999 kills (I only checked to 5 decimal places
by modifying the client dashboard to report extra decimal places, but
I assume the 9s go on forever).  The relevant code, in /ntserv/daemonII.c
is:
    j->p_kills += (0.02 * ab);

where j->pkills is defined as a float, and ab is a local integer.  Does
anyone have insight into what is happening here to cause this strange
oscillation?

Getting back to the original issue of the disparity between client and
server army capacity for an AS with .33 kills, the relevant server code,
from /ntserv/daemonII.c is:
            /* XXX */
            if (j->p_ship.s_type == ASSAULT) {
                if (j->p_armies == (int)(j->p_kills * 3.0))
                    continue;

So the function (int)(.33 * 3.0) is returning 1.  I checked this with 5
decimal places to make sure it was indeed .33000 kills, not .33999 kills
as can also happen due to the strangeness mentioned earlier.  In either
case the client would show .33 kills, but in the first case I don't see
why it is rounding up to 1 (.33 * 3.0 = .99 by my book, int should round
that down to 0).  Any thoughts?
Bill


From williamb at its.caltech.edu  Thu Apr 13 20:49:51 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Thu, 13 Apr 2006 18:49:51 -0700 (PDT)
Subject: [netrek-dev] Weirdness in bombing kill credit
In-Reply-To: <Pine.GSO.4.58.0604130543120.3355@inky>
References: <Pine.GSO.4.58.0604130543120.3355@inky>
Message-ID: <Pine.GSO.4.58.0604131840050.488@clyde>

I looked into this issue further, and found out some things regarding
floats and decimals that I should have known about before I posted.
Namely, that floats do not precisely store numbers like .1 or .2.  So I
don't see any way around the fact that bombing does not grant .2
kills per army bombed exactly everytime.

I also looked into how the client and server interact with regards to kill
updates.  Kills are multiplied by 100 by the server and sent to the
client.  The client then divides by 100 and inputs the value into the
player struct.  Effectively, any decimal places beyond the second are
lost.  Since the kills are stored as a float with many decimal places on
the server, but only to 2 decimal places on the client, this leads to a
case where the server and client calculate differently regarding how many
armies a ship can carry.

I propose then to modify the server code to truncate kills at the second
decimal place when it comes to troop capacity/beam up checking.  The code
change would be as follows (note there is also a similar function in
robot troop capacity logic but did not think this needed to be changed
as robot troop capacity stays server side).

Index: ntserv/daemonII.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
retrieving revision 1.5
diff -r1.5 daemonII.c
2947c2947,2948
<             /* XXX */
---
>             /* Truncate kills to the 2nd decimal place - same procedure used
>              for sending kill packets to clients */
2949c2950
<                 if (j->p_armies == (int)(j->p_kills * 3.0))
---
>                 if (j->p_armies == (int)((float)((int)(j->p_kills*100)/100.0) * 3.0))
2952c2953
<                 if (j->p_armies == (int)(j->p_kills * 2.0))
---
>                 if (j->p_armies == (int)((float)(int)(j->p_kills*100)/100.0) * 2.0))

Index: ntserv/redraw.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/redraw.c,v
retrieving revision 1.2
diff -r1.2 redraw.c
415c415,417
<     troop_capacity = pl->p_kills * (myship->s_type == ASSAULT?3:2);
---
>     /* Truncate kills to the 2nd decimal place - same procedure used
>        for sending kill packets to clients */
>     troop_capacity = (int)((float)((int)(pl->p_kills*100)/100.0) * (myship->s_type == ASSAULT?3:2));



From quozl at us.netrek.org  Fri Apr 14 05:49:09 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 14 Apr 2006 20:49:09 +1000
Subject: [netrek-dev] Weirdness in bombing kill credit
In-Reply-To: <Pine.GSO.4.58.0604131840050.488@clyde>
References: <Pine.GSO.4.58.0604130543120.3355@inky>
	<Pine.GSO.4.58.0604131840050.488@clyde>
Message-ID: <20060414104909.GB23058@us.netrek.org>

Bill and I discussed this on #netrek, and a commit has been made.
I've reviewed it and I'm happy with it.  Review by others still welcome.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Fri Apr 14 07:55:10 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 14 Apr 2006 22:55:10 +1000
Subject: [netrek-dev] proposed alternate t-mode scum check
Message-ID: <20060414125510.GA27001@us.netrek.org>

The following patch is for discussion.  It changes the t-mode scumming
check by preventing t-mode from beginning at all if there are players
present from the same IP address.  Once the duplication is resolved
t-mode begins.

It is implemented as a state machine.  The state variable is:

static enum ts {
	TS_PICKUP, 
	TS_SCUMMERS,
	TS_BEGIN,
	TS_TOURNAMENT,
	TS_END
} ts = TS_PICKUP;

Alternate ideas I've been playing with ...

- exclude the duplicate IP players from the total per team, such that
  with four clients on Federation from the same IP, they'd need another
  three ships before Federation would be considered to have quorum,

- make CHECKSCUM a maximum number of duplicates allowed, so that
  legitimate players from the same IP are permitted,

- if every slot is guest, don't care, allow t-mode.

(The intention is to hinder the social "problem" of players feeding
their character kills while waiting for other players to arrive.
Distortion of t-mode statistics.  It's not that I care about the
statistics, it's that people perceive the problem.)

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
Index: ntserv/daemonII.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
retrieving revision 1.6
diff -u -r1.6 daemonII.c
--- ntserv/daemonII.c	14 Apr 2006 10:19:17 -0000	1.6
+++ ntserv/daemonII.c	14 Apr 2006 12:44:22 -0000
@@ -67,7 +67,7 @@
 /* file scope prototypes */
 static void check_load(void);
 static int tournamentMode(void);
-static int check_scummers(void);
+static int check_scummers(int);
 static void move(int ignored);
 static void udplayersight(void);
 static void udplayers(void);
@@ -394,7 +394,7 @@
    Nick Trown   12/19/92
 */
 
-static int check_scummers(void)
+static int check_scummers(int verbose)
 {
     int i, j;
     int num;
@@ -443,7 +443,8 @@
             }
           }
         }
-        if (num>1){
+        if (num>0){
+            if (!verbose) return 1;
             pmessage(0,MALL,"GOD->ALL", "*****************************************");
             pmessage(0,MALL,"GOD->ALL","Possible t-mode scummers have been found.");
             pmessage(0,MALL,"GOD->ALL","They have been noted for god to review.");
@@ -553,6 +554,13 @@
     static int oldtourn=0;
     static int oldmessage;
     int old_robot;
+    static enum ts {
+	    TS_PICKUP, 
+	    TS_SCUMMERS,
+	    TS_BEGIN,
+	    TS_TOURNAMENT,
+	    TS_END
+    } ts = TS_PICKUP;
 
     /* Don't tell us it's time for another move in the middle of a move. */
     (void) SIGNAL(SIGALRM, SIG_IGN);
@@ -618,24 +626,49 @@
         pmessage(0, MALL, "GOD->ALL","Loading new server configuration.");
     }
 
-    if (tournamentMode()) {
-        if (!oldtourn) {
-            if (check_scum)     
-                check_scummers();               /* NBT */
-            oldmessage=(random() % 8);
+    switch (ts) {
+    case TS_PICKUP:
+	    status->tourn = 0;
+	    if (tournamentMode()) {
+		    ts = TS_BEGIN;
+		    if (check_scum && check_scummers(1))
+			    ts = TS_SCUMMERS;
+	    }
+	    break;
+
+    case TS_SCUMMERS:
+	    status->tourn = 0;
+	    if (!tournamentMode()) {
+		    ts = TS_PICKUP;
+	    } else {
+		    if (!check_scum) {
+			    ts = TS_BEGIN;
+			    break;
+		    }
+		    if (!check_scummers(0))
+			    ts = TS_BEGIN;
+	    }
+	    break;
+
+    case TS_BEGIN:
+	    oldmessage = (random() % 8);
 	    political_begin(oldmessage);
-        }
-        oldtourn=1;
-        status->tourn=1;
-        status->time++;
-        tourntimestamp = ticks;
-    } else {
-        if (oldtourn) {
+	    ts = TS_TOURNAMENT;
+            /* break; */
+
+    case TS_TOURNAMENT:
+            status->tourn = 1;
+            status->time++;
+            tourntimestamp = ticks;
+            if (tournamentMode()) break;
+            ts = TS_END;
+            /* break; */
+
+    case TS_END:
             tourntimestamp = ticks; /* record end of Tmode 8/2/91 TC */
-	    political_end(oldmessage);
-        }
-        oldtourn=0;
-        status->tourn=0;
+            political_end(oldmessage);
+            ts = TS_PICKUP;
+            break;
     }
 
 #ifdef PUCK_FIRST
-------------- 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/20060414/17ea926d/attachment.pgp 

From netrek at gmail.com  Sat Apr 15 03:06:33 2006
From: netrek at gmail.com (Zach)
Date: Sat, 15 Apr 2006 04:06:33 -0400
Subject: [netrek-dev] proposed alternate t-mode scum check
In-Reply-To: <20060414125510.GA27001@us.netrek.org>
References: <20060414125510.GA27001@us.netrek.org>
Message-ID: <ecfa260c0604150106n54649eb0uddee19140dae79b3@mail.gmail.com>

Or just reset all kills to 0 once t-mode starts.

Or restrict out-of-t same-ip t-mode to very late time period like 5 to
7am or something.

Zach

On 4/14/06, James Cameron <quozl at us.netrek.org> wrote:
> The following patch is for discussion.  It changes the t-mode scumming
> check by preventing t-mode from beginning at all if there are players
> present from the same IP address.  Once the duplication is resolved
> t-mode begins.
>
> It is implemented as a state machine.  The state variable is:
>
> static enum ts {
>         TS_PICKUP,
>         TS_SCUMMERS,
>         TS_BEGIN,
>         TS_TOURNAMENT,
>         TS_END
> } ts = TS_PICKUP;
>
> Alternate ideas I've been playing with ...
>
> - exclude the duplicate IP players from the total per team, such that
>   with four clients on Federation from the same IP, they'd need another
>   three ships before Federation would be considered to have quorum,
>
> - make CHECKSCUM a maximum number of duplicates allowed, so that
>   legitimate players from the same IP are permitted,
>
> - if every slot is guest, don't care, allow t-mode.
>
> (The intention is to hinder the social "problem" of players feeding
> their character kills while waiting for other players to arrive.
> Distortion of t-mode statistics.  It's not that I care about the
> statistics, it's that people perceive the problem.)
>
> --
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFEP5uubmRwv64kZsARAtFjAJ44fB7c376f5GmlTS6SBbS98t6T0wCdFcAO
> pq+LAyPNq39x4hkuUuK2l9o=
> =AVQL
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>
>
>


From williamb at its.caltech.edu  Sun Apr 16 03:28:26 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Sun, 16 Apr 2006 01:28:26 -0700 (PDT)
Subject: [netrek-dev] Need the help of a sound guru
Message-ID: <Pine.GSO.4.58.0604160111380.4996@clyde>

I'm looking to modify some of the sound files that come with NetrekXP.
Specifically, the nt_explosion, nt_explosion_other, and nt_torp hit.  The
reason is: these sounds are just too long.  Explosions are the highest
priority sound, and at 6 seconds long, the nt_explosion_other sound means
that every time someone blows up on your screen, you aren't hearing any
other sounds for 6 seconds.  Compare this to the sound package that comes
in COW - the explosion_other sound is just 2 seconds long.  Likewise,
nt_explosion is 9 seconds long, compared to 2 seconds in COW.  This one is
not as important, since this only fires when you are dead.  Still, I would
like it to be shorter, around 3 secs.  The same for nt_explosion_other.

The other problematic sound is nt_torp_hit, at 2 seconds long (vs. less
than 1 second in COW).  I would like this sound to be shorter as well.
There were several other sound files that had lots of dead space at the
end, most egregiously, the nt_phaser sound, which had a second of no sound
at the end.  I was able to tidy up these other sound files with Create
WaveStudio.  However, in the case of torp_hit and nt_explosions, a simple
truncating of the sound file will not be sufficient - the sound just is
too long.  And this task is beyond my skill.

Is there anyone who can submit new versions of these sounds, using the
current sounds as a base, but within the timeframes mentioned earlier (3
secs for explosion, 1 sec for torp hit)?  If so, I would use these to
replace the current files in the NetrekXP sound package.

Also, if anyone can confirm that the current NetrekXP sounds were made by
L Crawford, that would be good too.  I'm just guessing he made them, based
on a post 7 years ago on rec.games.netrek.

Bill


From netrek at gmail.com  Sun Apr 16 06:37:50 2006
From: netrek at gmail.com (Zach)
Date: Sun, 16 Apr 2006 07:37:50 -0400
Subject: [netrek-dev] COW page gone
Message-ID: <ecfa260c0604160437g24606a5dv397d0f0d1d59eee4@mail.gmail.com>

http://cow.netrek.org is defunct

Here is a copy from March 9th:
http://web.archive.org/web/20050309215938/www.netrek.org/cow/

Perhaps someone can restore this on netrek.org

Happy Easter!
<><

Zach


From netrek at gmail.com  Sun Apr 16 06:38:32 2006
From: netrek at gmail.com (Zach)
Date: Sun, 16 Apr 2006 07:38:32 -0400
Subject: [netrek-dev] latest COW sources
Message-ID: <ecfa260c0604160438h7ffd55f5v8d493f315ac0c34@mail.gmail.com>

Where can I find the latest COW sources?

Zach


From netrek at gmail.com  Sun Apr 16 06:40:42 2006
From: netrek at gmail.com (Zach)
Date: Sun, 16 Apr 2006 07:40:42 -0400
Subject: [netrek-dev] FTP service down
Message-ID: <ecfa260c0604160440m5bcf8699xd7dc0a6570780e9@mail.gmail.com>

FTP service is *not* running on ftp.netrek.org

ftp://ftp.netrek.org

Can someone look into this?

Zach


From quozl at us.netrek.org  Mon Apr 17 00:30:07 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 17 Apr 2006 15:30:07 +1000
Subject: [netrek-dev] Need the help of a sound guru
In-Reply-To: <Pine.GSO.4.58.0604160111380.4996@clyde>
References: <Pine.GSO.4.58.0604160111380.4996@clyde>
Message-ID: <20060417053007.GB11240@us.netrek.org>

G'day Bill,

You said you aren't hearing any other sounds while an explosion sound
plays out?  Are you sure about that?  With COW on Linux, sounds are
layered using SDL so that multiple events are mixed together over time.

If NetrekXP mixes sound, perhaps lowering the amplitude of the explosion
sound will make the mix sound better.

I've skill with sound editing ... but I'd need to know which way
NetrekXP works before I do anything to them.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Mon Apr 17 00:42:22 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 17 Apr 2006 15:42:22 +1000
Subject: [netrek-dev] COW page gone / latest COW sources / FTP service
	down
In-Reply-To: <ecfa260c0604160440m5bcf8699xd7dc0a6570780e9@mail.gmail.com>
	<ecfa260c0604160438h7ffd55f5v8d493f315ac0c34@mail.gmail.com>
	<ecfa260c0604160437g24606a5dv397d0f0d1d59eee4@mail.gmail.com>
References: <ecfa260c0604160440m5bcf8699xd7dc0a6570780e9@mail.gmail.com>
	<ecfa260c0604160438h7ffd55f5v8d493f315ac0c34@mail.gmail.com>
	<ecfa260c0604160437g24606a5dv397d0f0d1d59eee4@mail.gmail.com>
Message-ID: <20060417054222.GC11240@us.netrek.org>

On Sun, Apr 16, 2006 at 07:37:50AM -0400, Zach wrote:
> http://cow.netrek.org is defunct

It redirects to the content from http://netrek.org/ which is a
reasonable default, better than a 404.

> Here is a copy from March 9th:
> http://web.archive.org/web/20050309215938/www.netrek.org/cow/
> 
> Perhaps someone can restore this on netrek.org

Go ahead and do it, generate a darcs change set and let me know when
you've done it.  Put it in a directory called cow.  Most of the content
is from COW CVS.  The index page probably isn't, as I wasn't able to
find it in CVS.

On Sun, Apr 16, 2006 at 07:38:32AM -0400, Zach wrote:
> Where can I find the latest COW sources?

You must have missed my announcement of my release of COW 3.2.0, just
over a month ago.  You'll find it in the archives.  The .tar.gz source
is in http://quozl.linux.org.au/netrek/ and the CVS repository is the
module client/cow on the Netrek CVS repository on SourceForge.

On Sun, Apr 16, 2006 at 07:40:42AM -0400, Zach wrote:
> FTP service is *not* running on ftp.netrek.org
> ftp://ftp.netrek.org
> Can someone look into this?

Why?  FTP is so seventies.  Unless we have a clear need for it, I'm
inclined to deprecate it and fix all references.  Where did you see a
link to it?

http://ftp.netrek.org/ seems to work fine.  Feedback link to Dave.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From williamb at its.caltech.edu  Mon Apr 17 04:48:34 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Mon, 17 Apr 2006 02:48:34 -0700 (PDT)
Subject: [netrek-dev] Need the help of a sound guru
In-Reply-To: <20060417053007.GB11240@us.netrek.org>
References: <Pine.GSO.4.58.0604160111380.4996@clyde>
	<20060417053007.GB11240@us.netrek.org>
Message-ID: <Pine.GSO.4.58.0604170246130.29802@blinky>

Ah, it turns out NetrekXP does not use SDL, guess it branched off before
that was added.  Since sound mixing would be a really good thing, I'm
going to look into putting it into NetrekXP following what was done to the
COW client.  I looked over the Changelog for COW, it seemed SDL was one of
the larger changes.  Any other things that were added within the last 6
years that might be worth porting over to XP?
Bill



From stephen.thorne at gmail.com  Mon Apr 17 06:04:03 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Mon, 17 Apr 2006 21:04:03 +1000
Subject: [netrek-dev] COW build problems.
Message-ID: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>

I've been having problems with building cow. I've tried this with OSX
and ubuntu dapper, and have experienced the same problem, so it's
probably a bug in the build process.

$ ./configure > /dev/null ; grep -- -I system.mk
MPINC           = # -I.
INCS            =  -I


I have to change that 'INCS' line to read

INCS = -I.

for anything to compile properly, otherwise it consumes the next
compile flag as an include directory...

I'm using anon sourceforge cvs to compile from.
--
Stephen Thorne
Development Engineer


From mark at mark.mielke.cc  Thu Apr 13 21:36:30 2006
From: mark at mark.mielke.cc (mark at mark.mielke.cc)
Date: Thu, 13 Apr 2006 22:36:30 -0400
Subject: [netrek-dev] Weirdness in bombing kill credit
In-Reply-To: <Pine.GSO.4.58.0604131840050.488@clyde>
References: <Pine.GSO.4.58.0604130543120.3355@inky>
	<Pine.GSO.4.58.0604131840050.488@clyde>
Message-ID: <20060414023630.GA14602@mark.mielke.cc>

On Thu, Apr 13, 2006 at 06:49:51PM -0700, William Balcerski wrote:
> I looked into this issue further, and found out some things regarding
> floats and decimals that I should have known about before I posted.
> Namely, that floats do not precisely store numbers like .1 or .2.  So I
> don't see any way around the fact that bombing does not grant .2
> kills per army bombed exactly everytime.

No, but pretty darned close to .2. It sounds like all you have is a
rounding issue. 0.1999999 is 0.2, not 0.1.

> I also looked into how the client and server interact with regards to kill
> updates.  Kills are multiplied by 100 by the server and sent to the
> client.  The client then divides by 100 and inputs the value into the
> player struct.  Effectively, any decimal places beyond the second are
> lost.  Since the kills are stored as a float with many decimal places on
> the server, but only to 2 decimal places on the client, this leads to a
> case where the server and client calculate differently regarding how many
> armies a ship can carry.

Rounding fixes this.

> I propose then to modify the server code to truncate kills at the second
> decimal place when it comes to troop capacity/beam up checking.  The code
> change would be as follows (note there is also a similar function in
> robot troop capacity logic but did not think this needed to be changed
> as robot troop capacity stays server side).

Why truncate? Round.

Cheers,
mark

-- 
mark at mielke.cc / markm at ncf.ca / markm at nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/



From mark at mark.mielke.cc  Fri Apr 14 09:42:53 2006
From: mark at mark.mielke.cc (mark at mark.mielke.cc)
Date: Fri, 14 Apr 2006 10:42:53 -0400
Subject: [netrek-dev] proposed alternate t-mode scum check
In-Reply-To: <20060414125510.GA27001@us.netrek.org>
References: <20060414125510.GA27001@us.netrek.org>
Message-ID: <20060414144253.GA755@mark.mielke.cc>

I find myself wondering whether there is a more sophisticated way
of doing this sort of thing.

I've found myself in situations before, where I was attempting to
encourage people to learn Netrek, however, from behind my firewall at
home, SNAT presents all of us as the same IP address.

This is common now, and it's possible it may become more possible
as IPv6 is slowly rolled out, with IPv4 SNAT. It's a flaw in the
system. IP address != person.

Now, since then, I've managed to fake it out. I have 6 static Internet
accessible IP addresses on my home network. I can bind to 4 of them
on one machine, a 5th on a second, and a 6th on a third. But this
just exposes the problem. I can *still* cheat, if I really wanted to.

So, what is a person?

I'm thinking a 'person' should be measured more in terms of
interactivity. For example - if I'm truly good enough to run two
clients at once, from the same X display, why shouldn't it be
allowed? :-) What's the risk?

Well, maybe there is a risk that people set up clients on the
opposite team.

As an initial suggestion, I'm thinking that the same IP address can
be used as long as both clients are 'active'. Haven't thought too much
about measuring activity - but it shouldn't be too hard. The average
players sends dozens or hundreds of requests every minute. If less
than a dozen or two, the client is inactive.

Mostly: While Netrek is having trouble finding players, I'm not sure
that locking it down, preventing multiple players from the same
broadband Internet connection is such a great idea.

Cheers,
mark


On Fri, Apr 14, 2006 at 10:55:10PM +1000, James Cameron wrote:
> The following patch is for discussion.  It changes the t-mode scumming
> check by preventing t-mode from beginning at all if there are players
> present from the same IP address.  Once the duplication is resolved
> t-mode begins.
> 
> It is implemented as a state machine.  The state variable is:
> 
> static enum ts {
> 	TS_PICKUP, 
> 	TS_SCUMMERS,
> 	TS_BEGIN,
> 	TS_TOURNAMENT,
> 	TS_END
> } ts = TS_PICKUP;
> 
> Alternate ideas I've been playing with ...
> 
> - exclude the duplicate IP players from the total per team, such that
>   with four clients on Federation from the same IP, they'd need another
>   three ships before Federation would be considered to have quorum,
> 
> - make CHECKSCUM a maximum number of duplicates allowed, so that
>   legitimate players from the same IP are permitted,
> 
> - if every slot is guest, don't care, allow t-mode.
> 
> (The intention is to hinder the social "problem" of players feeding
> their character kills while waiting for other players to arrive.
> Distortion of t-mode statistics.  It's not that I care about the
> statistics, it's that people perceive the problem.)
> 
> -- 
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

> Index: ntserv/daemonII.c
> ===================================================================
> RCS file: /cvsroot/netrek/server/Vanilla/ntserv/daemonII.c,v
> retrieving revision 1.6
> diff -u -r1.6 daemonII.c
> --- ntserv/daemonII.c	14 Apr 2006 10:19:17 -0000	1.6
> +++ ntserv/daemonII.c	14 Apr 2006 12:44:22 -0000
> @@ -67,7 +67,7 @@
>  /* file scope prototypes */
>  static void check_load(void);
>  static int tournamentMode(void);
> -static int check_scummers(void);
> +static int check_scummers(int);
>  static void move(int ignored);
>  static void udplayersight(void);
>  static void udplayers(void);
> @@ -394,7 +394,7 @@
>     Nick Trown   12/19/92
>  */
>  
> -static int check_scummers(void)
> +static int check_scummers(int verbose)
>  {
>      int i, j;
>      int num;
> @@ -443,7 +443,8 @@
>              }
>            }
>          }
> -        if (num>1){
> +        if (num>0){
> +            if (!verbose) return 1;
>              pmessage(0,MALL,"GOD->ALL", "*****************************************");
>              pmessage(0,MALL,"GOD->ALL","Possible t-mode scummers have been found.");
>              pmessage(0,MALL,"GOD->ALL","They have been noted for god to review.");
> @@ -553,6 +554,13 @@
>      static int oldtourn=0;
>      static int oldmessage;
>      int old_robot;
> +    static enum ts {
> +	    TS_PICKUP, 
> +	    TS_SCUMMERS,
> +	    TS_BEGIN,
> +	    TS_TOURNAMENT,
> +	    TS_END
> +    } ts = TS_PICKUP;
>  
>      /* Don't tell us it's time for another move in the middle of a move. */
>      (void) SIGNAL(SIGALRM, SIG_IGN);
> @@ -618,24 +626,49 @@
>          pmessage(0, MALL, "GOD->ALL","Loading new server configuration.");
>      }
>  
> -    if (tournamentMode()) {
> -        if (!oldtourn) {
> -            if (check_scum)     
> -                check_scummers();               /* NBT */
> -            oldmessage=(random() % 8);
> +    switch (ts) {
> +    case TS_PICKUP:
> +	    status->tourn = 0;
> +	    if (tournamentMode()) {
> +		    ts = TS_BEGIN;
> +		    if (check_scum && check_scummers(1))
> +			    ts = TS_SCUMMERS;
> +	    }
> +	    break;
> +
> +    case TS_SCUMMERS:
> +	    status->tourn = 0;
> +	    if (!tournamentMode()) {
> +		    ts = TS_PICKUP;
> +	    } else {
> +		    if (!check_scum) {
> +			    ts = TS_BEGIN;
> +			    break;
> +		    }
> +		    if (!check_scummers(0))
> +			    ts = TS_BEGIN;
> +	    }
> +	    break;
> +
> +    case TS_BEGIN:
> +	    oldmessage = (random() % 8);
>  	    political_begin(oldmessage);
> -        }
> -        oldtourn=1;
> -        status->tourn=1;
> -        status->time++;
> -        tourntimestamp = ticks;
> -    } else {
> -        if (oldtourn) {
> +	    ts = TS_TOURNAMENT;
> +            /* break; */
> +
> +    case TS_TOURNAMENT:
> +            status->tourn = 1;
> +            status->time++;
> +            tourntimestamp = ticks;
> +            if (tournamentMode()) break;
> +            ts = TS_END;
> +            /* break; */
> +
> +    case TS_END:
>              tourntimestamp = ticks; /* record end of Tmode 8/2/91 TC */
> -	    political_end(oldmessage);
> -        }
> -        oldtourn=0;
> -        status->tourn=0;
> +            political_end(oldmessage);
> +            ts = TS_PICKUP;
> +            break;
>      }
>  
>  #ifdef PUCK_FIRST




> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev


-- 
mark at mielke.cc / markm at ncf.ca / markm at nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/



From tanner at real-time.com  Mon Apr 17 11:00:49 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 11:00:49 -0500
Subject: [netrek-dev] Need the help of a sound guru
In-Reply-To: <Pine.GSO.4.58.0604170246130.29802@blinky>
References: <Pine.GSO.4.58.0604160111380.4996@clyde>
	<20060417053007.GB11240@us.netrek.org>
	<Pine.GSO.4.58.0604170246130.29802@blinky>
Message-ID: <200604171100.49493.tanner@real-time.com>

On Monday 17 April 2006 04:48, William Balcerski wrote:
> Ah, it turns out NetrekXP does not use SDL, guess it branched off before
> that was added. ?Since sound mixing would be a really good thing, I'm
> going to look into putting it into NetrekXP following what was done to the
> COW client. ?I looked over the Changelog for COW, it seemed SDL was one of
> the larger changes. ?Any other things that were added within the last 6
> years that might be worth porting over to XP?

I think the SDL sound stuff I did was the last major addition to COW. 

Mostly did the work because it was during the transition from OSS to ALSA, 
ironic the Linux world is still transitioning....

I picked SDL to make a cross-platform sound system, let me know if my hack is 
to hard to read and I can help out.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From tanner at real-time.com  Mon Apr 17 11:04:33 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 11:04:33 -0500
Subject: [netrek-dev] latest COW sources
In-Reply-To: <ecfa260c0604160438h7ffd55f5v8d493f315ac0c34@mail.gmail.com>
References: <ecfa260c0604160438h7ffd55f5v8d493f315ac0c34@mail.gmail.com>
Message-ID: <200604171104.33737.tanner@real-time.com>

On Sunday 16 April 2006 06:38, Zach wrote:
> Where can I find the latest COW sources?

Pristine upstream source is here:
ftp://ftp.real-time.com/linux/real-time/pool/non-free/n/netrek-client-cow

But that is just a cvs checkout of HEAD.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From tanner at real-time.com  Mon Apr 17 11:40:52 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 11:40:52 -0500
Subject: [netrek-dev] COW build problems.
In-Reply-To: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
Message-ID: <200604171140.52581.tanner@real-time.com>

On Monday 17 April 2006 06:04, Stephen Thorne wrote:
> I've been having problems with building cow. I've tried this with OSX
> and ubuntu dapper, and have experienced the same problem, so it's
> probably a bug in the build process.

Have you looked at the debian/rules file in the package that available from 
here:

ftp://ftp.real-time.com/linux/real-time/pool/non-free/n/netrek-client-cow

Quick check using breezy shows it compiles fine.

# apt-get update
# apt-get upgrade          
# apt-get build-dep netrek-client-cow
# apt-get source netrek-client-cow 
# dpkg-buildpackage -b

dpkg-deb: building package `netrek-client-cow' in 
`../netrek-client-cow_3.2.0-2_i386.deb'.
 dpkg-genchanges -b
dpkg-genchanges: binary-only upload - not including any source code


Ditto for hoary.
# apt-get update
# apt-get upgrade          
# apt-get install debhelper cdbs libsdl1.2-dev libsdl-mixer1.2-dev libgmp3-dev 
libxt-dev   
(* horay too old so auto-deps don't work)
(* slight hacking on the control file to get versioning)
# apt-get source netrek-client-cow 
# dpkg-buildpackage -b

dpkg-deb: building package `netrek-client-cow' in 
`../netrek-client-cow_3.2.0-2_i386.deb'.
 dpkg-genchanges -b
dpkg-genchanges: binary-only upload - not including any source code

See http://wiki.us.netrek.org/netrek-dev/Building/Compiling_HOWTOs for more 
details.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From tanner at real-time.com  Mon Apr 17 12:04:06 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 12:04:06 -0500
Subject: [netrek-dev] COW build problems.
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
Message-ID: <e20hq7$kc5$1@sea.gmane.org>

Stephen Thorne wrote:

> I've been having problems with building cow. I've tried this with OSX
> and ubuntu dapper, and have experienced the same problem, so it's
> probably a bug in the build process.

For giggles, I created a pbuilder instance of dapper.

Quick check using breezy shows it compiles fine.

# apt-get update
# apt-get upgrade          
# apt-get build-dep netrek-client-cow
# apt-get source netrek-client-cow 
# dpkg-buildpackage -b

dpkg-deb: building package `netrek-client-cow' in 
`../netrek-client-cow_3.2.0-2_i386.deb'.
 dpkg-genchanges -b
dpkg-genchanges: binary-only upload - not including any source code


-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288



From tanner at real-time.com  Mon Apr 17 12:18:00 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 12:18:00 -0500
Subject: [netrek-dev] COW build problems.
In-Reply-To: <e20hq7$kc5$1@sea.gmane.org>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<e20hq7$kc5$1@sea.gmane.org>
Message-ID: <200604171218.01401.tanner@real-time.com>

On Monday 17 April 2006 12:04, Bob Tanner wrote:
> Quick check using breezy shows it compiles fine.

Bah, cut-n-paste error, it should read dapper.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From stephen.thorne at gmail.com  Mon Apr 17 16:09:45 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 18 Apr 2006 07:09:45 +1000
Subject: [netrek-dev] COW build problems.
In-Reply-To: <200604171140.52581.tanner@real-time.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<200604171140.52581.tanner@real-time.com>
Message-ID: <3e8ca5c80604171409p1153a276h4c1f3c90fbe14f27@mail.gmail.com>

On 4/18/06, Bob Tanner <tanner at real-time.com> wrote:
> On Monday 17 April 2006 06:04, Stephen Thorne wrote:
> > I've been having problems with building cow. I've tried this with OSX
> > and ubuntu dapper, and have experienced the same problem, so it's
> > probably a bug in the build process.
>
> Have you looked at the debian/rules file in the package that available from
> here:
>
> ftp://ftp.real-time.com/linux/real-time/pool/non-free/n/netrek-client-cow

No, I hadn't. I've been using CVS. Perhaps there's a regression?

When I compile it myself, (./configure;make) from CVS, it fails with
the error described, trying to use a bare -I.

When I compile from the debian package, it uses -I/usr/X11R6/include/,
but that does a configure like so:

CC="cc" CXX="g++" CFLAGS="-g -Wall -O2" CXXFLAGS="-g -Wall -O2"
CPPFLAGS="" /home/stephen/src/netrek-client-cow-3.2.0/./configure 
--build=i486-linux-gnu --prefix=/usr --includedir="\${prefix}/include"
--mandir="\${prefix}/share/man" --infodir="\${prefix}/share/info"
--sysconfdir=/etc --localstatedir=/var
--libexecdir="\${prefix}/lib/netrek-client-cow" --srcdir=.
--disable-maintainer-mode  --enable-unstable
--x-includes=/usr/X11R6/include

It seems that
./configure --x-includes=/usr/X11R6/include/
is the minimum requirement for getting it to build, however, there
seems to be a further problem.

'make' by itself causes the mkkey bit to fail with an error message,
this seems to be the minimum 'make' commandline that works:
make KEYDEF=sample_key.def netrek

So it seems there are regressions.
--
Stephen Thorne
Development Engineer


From tanner at real-time.com  Mon Apr 17 16:19:59 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 16:19:59 -0500
Subject: [netrek-dev] COW build problems.
In-Reply-To: <3e8ca5c80604171409p1153a276h4c1f3c90fbe14f27@mail.gmail.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<200604171140.52581.tanner@real-time.com>
	<3e8ca5c80604171409p1153a276h4c1f3c90fbe14f27@mail.gmail.com>
Message-ID: <200604171619.59858.tanner@real-time.com>

On Monday 17 April 2006 16:09, Stephen Thorne wrote:
> No, I hadn't. I've been using CVS. Perhaps there's a regression?
>
> When I compile it myself, (./configure;make) from CVS, it fails with
> the error described, trying to use a bare -I.
>
> When I compile from the debian package, it uses -I/usr/X11R6/include/,
> but that does a configure like so:

My debian build is in-sync with cvs.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From stephen.thorne at gmail.com  Mon Apr 17 17:12:44 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 18 Apr 2006 08:12:44 +1000
Subject: [netrek-dev] COW build problems.
In-Reply-To: <200604171619.59858.tanner@real-time.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<200604171140.52581.tanner@real-time.com>
	<3e8ca5c80604171409p1153a276h4c1f3c90fbe14f27@mail.gmail.com>
	<200604171619.59858.tanner@real-time.com>
Message-ID: <3e8ca5c80604171512i6adbc335y9d724ad695a42cfc@mail.gmail.com>

On 4/18/06, Bob Tanner <tanner at real-time.com> wrote:
> On Monday 17 April 2006 16:09, Stephen Thorne wrote:
> > No, I hadn't. I've been using CVS. Perhaps there's a regression?
> >
> > When I compile it myself, (./configure;make) from CVS, it fails with
> > the error described, trying to use a bare -I.
> >
> > When I compile from the debian package, it uses -I/usr/X11R6/include/,
> > but that does a configure like so:
>
> My debian build is in-sync with cvs.

When I said, "when I compile from the debian package", I meant
following the instructions, using "apt-get -b source
netrek-client-cow".

viz:

stephen at onyx:/tmp$ apt-get source netrek-client-cow
Reading package lists... Done
Building dependency tree... Done
Need to get 1496kB of source archives.
Get: 1 ftp://ftp.real-time.com sid/non-free netrek-client-cow 3.2.0-2
(dsc) [687B]
Get: 2 ftp://ftp.real-time.com sid/non-free netrek-client-cow 3.2.0-2
(tar) [1495kB]
Fetched 1496kB in 6s (216kB/s)
dpkg-source: extracting netrek-client-cow in netrek-client-cow-3.2.0
dpkg-source: unpacking netrek-client-cow_3.2.0-2.tar.gz
stephen at onyx:/tmp$ cd netrek-client-cow-3.2.0/
stephen at onyx:/tmp/netrek-client-cow-3.2.0$ ./configure >/dev/null;make
sed: can't read ./key.mk.in: No such file or directory
make -f system.mk KEYDEF= netrek
make[1]: Entering directory `/tmp/netrek-client-cow-3.2.0'
gcc -O2    -DRSA  -I   -o mkkey mkkey.c  -lmp -lgmp -L/usr/X11R6/lib 
-lX11 -lnsl -lm
gcc: mkkey: No such file or directory
make[1]: *** [mkkey] Error 1
make[1]: Leaving directory `/tmp/netrek-client-cow-3.2.0'
make: *** [netrekI] Error 2





--
Stephen Thorne
Development Engineer


From tanner at real-time.com  Mon Apr 17 17:51:00 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 17:51:00 -0500
Subject: [netrek-dev] COW build problems.
In-Reply-To: <3e8ca5c80604171512i6adbc335y9d724ad695a42cfc@mail.gmail.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<200604171619.59858.tanner@real-time.com>
	<3e8ca5c80604171512i6adbc335y9d724ad695a42cfc@mail.gmail.com>
Message-ID: <200604171751.00778.tanner@real-time.com>

On Monday 17 April 2006 17:12, Stephen Thorne wrote:
> stephen at onyx:/tmp$ cd netrek-client-cow-3.2.0/
> stephen at onyx:/tmp/netrek-client-cow-3.2.0$ ./configure >/dev/null;make
> sed: can't read ./key.mk.in: No such file or directory
> make -f system.mk KEYDEF= netrek
> make[1]: Entering directory `/tmp/netrek-client-cow-3.2.0'
> gcc -O2 ? ?-DRSA ?-I ? -o mkkey mkkey.c ?-lmp -lgmp -L/usr/X11R6/lib
> -lX11 -lnsl -lm
> gcc: mkkey: No such file or directory
> make[1]: *** [mkkey] Error 1
> make[1]: Leaving directory `/tmp/netrek-client-cow-3.2.0'
> make: *** [netrekI] Error 2

You aren't building the package correctly

Look at my previous posting:

# apt-get build-dep netrek-client-cow
# apt-get source netrek-client-cow 
% cd netrek-client-cow-3.2.0/
% dpkg-buildpackage -b -rfakeroot

Use the dpkg tools, not the configure.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From stephen.thorne at gmail.com  Mon Apr 17 17:57:57 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 18 Apr 2006 08:57:57 +1000
Subject: [netrek-dev] COW build problems.
In-Reply-To: <200604171751.00778.tanner@real-time.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<200604171619.59858.tanner@real-time.com>
	<3e8ca5c80604171512i6adbc335y9d724ad695a42cfc@mail.gmail.com>
	<200604171751.00778.tanner@real-time.com>
Message-ID: <3e8ca5c80604171557x10ebe160tc832442b5100d4f1@mail.gmail.com>

On 4/18/06, Bob Tanner <tanner at real-time.com> wrote:
> You aren't building the package correctly

Oh, sure, I understand that when I don't use the debian package tools
it doesn't build correctly.

That's the thing, when you don't use the debian package tools, it
doesn't build correctly.
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Mon Apr 17 18:13:15 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 18 Apr 2006 09:13:15 +1000
Subject: [netrek-dev] COW build problems.
In-Reply-To: <3e8ca5c80604171557x10ebe160tc832442b5100d4f1@mail.gmail.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<200604171619.59858.tanner@real-time.com>
	<3e8ca5c80604171512i6adbc335y9d724ad695a42cfc@mail.gmail.com>
	<200604171751.00778.tanner@real-time.com>
	<3e8ca5c80604171557x10ebe160tc832442b5100d4f1@mail.gmail.com>
Message-ID: <20060417231315.GA14467@us.netrek.org>

On Tue, Apr 18, 2006 at 08:57:57AM +1000, Stephen Thorne wrote:
> That's the thing, when you don't use the debian package tools, it
> doesn't build correctly.

Okay, that's a regression.  Patches welcome.  If the Debian packaging
has do to something special, perhaps that something special should be
moved into upstream.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From tanner at real-time.com  Mon Apr 17 18:55:39 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 17 Apr 2006 18:55:39 -0500
Subject: [netrek-dev] COW build problems.
In-Reply-To: <20060417231315.GA14467@us.netrek.org>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<3e8ca5c80604171557x10ebe160tc832442b5100d4f1@mail.gmail.com>
	<20060417231315.GA14467@us.netrek.org>
Message-ID: <200604171855.40371.tanner@real-time.com>

On Monday 17 April 2006 18:13, James Cameron wrote:
> On Tue, Apr 18, 2006 at 08:57:57AM +1000, Stephen Thorne wrote:
> > That's the thing, when you don't use the debian package tools, it
> > doesn't build correctly.
>
> Okay, that's a regression.  Patches welcome.  If the Debian packaging
> has do to something special, perhaps that something special should be
> moved into upstream.

Not really regression, I was stating that the debian build tool works and a 
manual compile can work too -IF- a KEYDEF is defined.

My point was, use the debian tools (since you mentioned dapper) and see how it 
builds the code by defining a KEYDEF make variable.


I spoked to Quozl on IRC about it, we can improve the pristine build 
environment, but the "error" you receive is legit, you need to have a KEYDEF 
defined in order to compile things.

I wrote a quick hack, Quozl patched it, to look for our personal keys (Looks 
like Dave Ahn's too) and to default the sample_key.def if it cannot find any 
of those keys.

AFAIK, KEYDEF has always been required to build COW, if the docs don't say as 
much they should be updated.

I believe you are Jerub on IRC?

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From stephen.thorne at gmail.com  Mon Apr 17 21:36:05 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 18 Apr 2006 12:36:05 +1000
Subject: [netrek-dev] COW build problems.
In-Reply-To: <200604171855.40371.tanner@real-time.com>
References: <3e8ca5c80604170404j3c13920dl18959c15611530d8@mail.gmail.com>
	<3e8ca5c80604171557x10ebe160tc832442b5100d4f1@mail.gmail.com>
	<20060417231315.GA14467@us.netrek.org>
	<200604171855.40371.tanner@real-time.com>
Message-ID: <3e8ca5c80604171936k4edf17c7qd8ec6b4c7afbe38c@mail.gmail.com>

On 4/18/06, Bob Tanner <tanner at real-time.com> wrote:
> On Monday 17 April 2006 18:13, James Cameron wrote:
> > On Tue, Apr 18, 2006 at 08:57:57AM +1000, Stephen Thorne wrote:
> > > That's the thing, when you don't use the debian package tools, it
> > > doesn't build correctly.
> >
> > Okay, that's a regression.  Patches welcome.  If the Debian packaging
> > has do to something special, perhaps that something special should be
> > moved into upstream.
>
> Not really regression, I was stating that the debian build tool works and a
> manual compile can work too -IF- a KEYDEF is defined.
>
> My point was, use the debian tools (since you mentioned dapper) and see how it
> builds the code by defining a KEYDEF make variable.

Also only if --x-includes is defined. even making it '.' works. If
it's not defined then a bare -I gets into the cflags and that just
causes problems.

> I believe you are Jerub on IRC?

Yep.

I'm going to look at this again tonight.
--
Stephen Thorne
Development Engineer


From netrek at gmail.com  Mon Apr 17 22:09:00 2006
From: netrek at gmail.com (Zach)
Date: Mon, 17 Apr 2006 23:09:00 -0400
Subject: [netrek-dev] proposed alternate t-mode scum check
In-Reply-To: <20060414144253.GA755@mark.mielke.cc>
References: <20060414125510.GA27001@us.netrek.org>
	<20060414144253.GA755@mark.mielke.cc>
Message-ID: <ecfa260c0604172009v4511e282qdca8325cff6aafe8@mail.gmail.com>

Good point Mark.

Zach

On 4/14/06, mark at mark.mielke.cc <mark at mark.mielke.cc> wrote:
> I find myself wondering whether there is a more sophisticated way
> of doing this sort of thing.
>
> I've found myself in situations before, where I was attempting to
> encourage people to learn Netrek, however, from behind my firewall at
> home, SNAT presents all of us as the same IP address.
>
> This is common now, and it's possible it may become more possible
> as IPv6 is slowly rolled out, with IPv4 SNAT. It's a flaw in the
> system. IP address != person.


From netrek at gmail.com  Mon Apr 17 22:14:19 2006
From: netrek at gmail.com (Zach)
Date: Mon, 17 Apr 2006 23:14:19 -0400
Subject: [netrek-dev] Need the help of a sound guru
In-Reply-To: <200604171100.49493.tanner@real-time.com>
References: <Pine.GSO.4.58.0604160111380.4996@clyde>
	<20060417053007.GB11240@us.netrek.org>
	<Pine.GSO.4.58.0604170246130.29802@blinky>
	<200604171100.49493.tanner@real-time.com>
Message-ID: <ecfa260c0604172014s2e7b7d0ckd42aa4f00377c6a0@mail.gmail.com>

On 4/17/06, Bob Tanner <tanner at real-time.com> wrote:
>
> Mostly did the work because it was during the transition from OSS to ALSA,
> ironic the Linux world is still transitioning....

So what is being used for sound in Linux these days? Is ALSA dominant?

Zach


From ahn at orion.netrek.org  Fri Apr 21 02:00:04 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Fri, 21 Apr 2006 03:00:04 -0400
Subject: [netrek-dev] COW page gone
In-Reply-To: <ecfa260c0604160437g24606a5dv397d0f0d1d59eee4@mail.gmail.com>
References: <ecfa260c0604160437g24606a5dv397d0f0d1d59eee4@mail.gmail.com>
Message-ID: <20060421070004.GA19650@orion.netrek.org>

On Sun, Apr 16, 2006 at 07:37:50AM -0400, Zach wrote:
> http://cow.netrek.org is defunct

It's temporarily at http://genocide.netrek.org/cow/


From ahn at orion.netrek.org  Fri Apr 21 02:03:25 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Fri, 21 Apr 2006 03:03:25 -0400
Subject: [netrek-dev] FTP service down
In-Reply-To: <ecfa260c0604160440m5bcf8699xd7dc0a6570780e9@mail.gmail.com>
References: <ecfa260c0604160440m5bcf8699xd7dc0a6570780e9@mail.gmail.com>
Message-ID: <20060421070325.GB19650@orion.netrek.org>

On Sun, Apr 16, 2006 at 07:40:42AM -0400, Zach wrote:
> FTP service is *not* running on ftp.netrek.org
> 
> ftp://ftp.netrek.org
> 
> Can someone look into this?

After discussing with James, I am considering removing the FTP service
and only offering HTTP access to the Netrek Software Archive.  Does
anyone have any objections to this?

Alternatively, Bob, what do you think of restarting the old
ftp.netrek.org / ftp.us.netrek.org rsync that we had going years ago?

Dave


From tanner at real-time.com  Fri Apr 21 13:53:59 2006
From: tanner at real-time.com (Bob Tanner)
Date: Fri, 21 Apr 2006 13:53:59 -0500
Subject: [netrek-dev] FTP service down
In-Reply-To: <20060421070325.GB19650@orion.netrek.org>
References: <ecfa260c0604160440m5bcf8699xd7dc0a6570780e9@mail.gmail.com>
	<20060421070325.GB19650@orion.netrek.org>
Message-ID: <20060421185359.GA1726@real-time.com>

Quoting Dave Ahn (ahn at orion.netrek.org):
> Alternatively, Bob, what do you think of restarting the old
> ftp.netrek.org / ftp.us.netrek.org rsync that we had going years ago?

Nice both boxes are in racks next to each other is it necessary? ;-)

I major event will take out both systems. :-(

Be happy to sync'em though.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288


From quozl at us.netrek.org  Sat Apr 22 16:51:52 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 23 Apr 2006 07:51:52 +1000
Subject: [netrek-dev] [repost] libnetrek.a
Message-ID: <20060422215152.GA27031@us.netrek.org>

The rework mentioned below has been committed.  The 42K patch was
rejected by the mailing list.

--

A rework of the Vanilla build process was about to be committed, but
SourceForge CVS is down again.  Patch is attached.

The goal of the change is to reduce the cost of adding functions, and to
ease understanding of the code.

I've chosen for the moment not to use a shared library, since doing so
complicates the build process and involves the use of an additional
build dependency (libtool), although it might drop run-time virtual
memory consumption slightly.

- most common code used in ntserv/ is placed in an ar(1) archive
  libnetrek.a,

- binaries are linked against libnetrek.a,

- some binaries that need special compilation (e.g. of
  ntserv/commands.c) still do this.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From netrek at gmail.com  Sat Apr 22 19:55:04 2006
From: netrek at gmail.com (Zach)
Date: Sat, 22 Apr 2006 20:55:04 -0400
Subject: [netrek-dev] [repost] libnetrek.a
In-Reply-To: <20060422215152.GA27031@us.netrek.org>
References: <20060422215152.GA27031@us.netrek.org>
Message-ID: <ecfa260c0604221755p54e4c006r5536140a8e8e5746@mail.gmail.com>

G'day James,

Is there a command to show which functions are encapsulated in the
library file libnetrek.a? Is the "./configure ; make" process affected
by this change? Ntserv is the main server process?
How does this ease understanding of the code since the source files
for ntserv have not changed as I understand it?

Zach

On 4/22/06, James Cameron <quozl at us.netrek.org> wrote:
> The rework mentioned below has been committed.  The 42K patch was
> rejected by the mailing list.
>
> --
>
> A rework of the Vanilla build process was about to be committed, but
> SourceForge CVS is down again.  Patch is attached.
>
> The goal of the change is to reduce the cost of adding functions, and to
> ease understanding of the code.
>
> I've chosen for the moment not to use a shared library, since doing so
> complicates the build process and involves the use of an additional
> build dependency (libtool), although it might drop run-time virtual
> memory consumption slightly.
>
> - most common code used in ntserv/ is placed in an ar(1) archive
>   libnetrek.a,
>
> - binaries are linked against libnetrek.a,
>
> - some binaries that need special compilation (e.g. of
>   ntserv/commands.c) still do this.
>
> --
> 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/listinfo/netrek-dev
>


From quozl at us.netrek.org  Sat Apr 22 23:02:28 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 23 Apr 2006 14:02:28 +1000
Subject: [netrek-dev] [repost] libnetrek.a
In-Reply-To: <ecfa260c0604221755p54e4c006r5536140a8e8e5746@mail.gmail.com>
References: <20060422215152.GA27031@us.netrek.org>
	<ecfa260c0604221755p54e4c006r5536140a8e8e5746@mail.gmail.com>
Message-ID: <20060423040227.GD27011@us.netrek.org>

G'day Zach,

Thanks for your questions.  Software developers know that
modularisation, encapsulation and simplification are good things to do
to source trees.  Since I've not seen any significant patches from you,
I guess you wouldn't appreciate the benefits as much as people who do
send in patches.

To answer your exact questions ...

1.  yes, there is a command to list the contents of an object library,
it is called nm(1).  However it is more likely that developers will look
for the function they need, find what source file it is in, and whether
that source file is in the Makefile target that builds the library.

2.  yes, the configure and make is affected by this change, because it
happens quicker and generates less on-screen output.  The directions to
build are not changed, of course.

3.  ntserv is the process forked for each player, and also the name of
the directory that contains the source for ntserv and for the universe
simulation daemon.

4.  it isn't necessary for an ntserv C source file to change for there
to have been an ease in understanding the code, because the process of
understanding does not use only C source files.  By simplifying the
build Makefiles for each directory, it is more clear to a newcomer how
the source files relate.

Now back to coding.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Sat Apr 22 04:17:30 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 22 Apr 2006 19:17:30 +1000
Subject: [netrek-dev] libnetrek.a
Message-ID: <20060422091730.GA21062@us.netrek.org>

A rework of the Vanilla build process was about to be committed, but
SourceForge CVS is down again.  Patch is attached.

The goal of the change is to reduce the cost of adding functions, and to
ease understanding of the code.

I've chosen for the moment not to use a shared library, since doing so
complicates the build process and involves the use of an additional
build dependency (libtool), although it might drop run-time virtual
memory consumption slightly.

- most common code used in ntserv/ is placed in an ar(1) archive
  libnetrek.a,

- binaries are linked against libnetrek.a,

- some binaries that need special compilation (e.g. of
  ntserv/commands.c) still do this.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
? FAQ
? cow.log
? cvs.diff
? libnetrek
? netrek-server-vanilla-2.10.1.tar.gz
? netrek-server-vanilla-2.10.1.tar.gz.md5sum
? netrek-server-vanilla-2.10.2.tar.gz
? netrek-server-vanilla-2.10.2.tar.gz.asc
? netrek-server-vanilla-2.10.2.tar.gz.md5sum
? netrek-server-vanilla-2.10.3.tar.gz
? ntserv.log
? tmp
? tmp.1
? vanilla.netrek.org
? docs/sample_geno_timer_crontab
? docs/sample_sysdef
? gum/.deps
? gum/Makefile
? gum/autom4te.cache
? gum/config.log
? gum/config.status
? newstartd/cow.log
? ntserv/.depend
? ntserv/Makefile
? ntserv/daemonII
? ntserv/glog.c
? ntserv/ntserv
? pledit/.depend
? pledit/Makefile
? pledit/pledit
? res-rsa/.depend
? res-rsa/Makefile
? res-rsa/config.h
? res-rsa/config.log
? res-rsa/config.status
? robotd/Makefile
? robotd/robot
? robotd/robot.log
? robots/.depend
? robots/Makefile
? robots/Makefile.in.libnetrek
? robots/basep
? robots/cvs.diff
? robots/inl
? robots/mars
? robots/newbie
? robots/pret
? robots/puck
? robots/robotII
? robots/tmp
? sequencer/.depend
? sequencer/Makefile
? sequencer/sequencer
? tools/.depend
? tools/Makefile
? tools/ate
? tools/blotpassword
? tools/cambot
? tools/conq_vert
? tools/convert
? tools/fun
? tools/keyman
? tools/loadchecker
? tools/ltd_convert
? tools/ltd_dump
? tools/mergescores
? tools/mess
? tools/message
? tools/metaget
? tools/metalog-plot
? tools/newscores
? tools/ntpasswd
? tools/nuke
? tools/planets
? tools/players
? tools/scores
? tools/setgalaxy
? tools/showgalaxy
? tools/sortdb
? tools/stat
? tools/trekon
? tools/trimscores
? tools/updated
? tools/watchmes
? tools/xtkill
? xsg/.depend
? xsg/Makefile
? xsg/xsg
Index: ChangeLog
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ChangeLog,v
retrieving revision 1.24
diff -u -r1.24 ChangeLog
--- ChangeLog	22 Apr 2006 02:16:42 -0000	1.24
+++ ChangeLog	22 Apr 2006 08:53:24 -0000
@@ -1,3 +1,14 @@
+Sat Apr 22 13:46:49 2006  James Cameron  <quozl at us.netrek.org>
+
+	* glog.c, socket.c, commands.c, gencmds.c: factorise god log
+	access, due to valgrind detected file descriptor left open after
+	exit.
+
+Sat Apr 22 13:01:10 2006  James Cameron  <quozl at us.netrek.org>
+
+	* ntserv/socket.c (clientVersion): remove superfluous NULL
+	termination of string returned by strdup().
+
 Sat Apr 22 12:07:50 2006  James Cameron  <quozl at us.netrek.org>
 
 	* Makefile.in (dist): avoid certain CVS files.
Index: Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/Makefile.in,v
retrieving revision 1.9
diff -u -r1.9 Makefile.in
--- Makefile.in	22 Apr 2006 02:16:44 -0000	1.9
+++ Makefile.in	22 Apr 2006 08:53:24 -0000
@@ -14,9 +14,17 @@
 
 include $(CONFIG)
 
-.PHONY: rmdependencies clean reallyclean install installbin server utils startup rsa_utils do_xsg do_pledit do_robots do_gum
-
-all: null $(PMAKE) server utils startup rsa_utils do_xsg do_pledit do_robots do_robotd @GUM@
+.PHONY: rmdependencies clean reallyclean install installbin \
+	do_library do_server do_listener do_robots do_robotd \
+	do_utilities do_rsa_utilities do_xsg do_pledit do_gum
+
+all: null $(PMAKE) \
+	do_library do_server do_listener do_robots do_robotd \
+	do_utilities do_rsa_utilities do_xsg do_pledit @GUM@
+
+minimal: null $(PMAKE) \
+	do_library do_server do_listener do_robots do_robotd \
+	do_utilities do_rsa_utilities 
 
 depend: system.mk
 	cd ntserv;    $(MAKE) depend
@@ -46,38 +54,40 @@
 config.h: system.mk
 	touch config.h
 
-# make the server binaries and such
-server: null rsalib
+do_library: null
+	cd ntserv; $(MAKE) libnetrek.a
+
+do_server: null do_rsa_library
 	cd ntserv; $(MAKE)
 
-do_robots:
+do_robots: do_library
 	cd robots; $(MAKE)
 
 do_robotd: 
 	cd robotd; $(MAKE)
 
-do_gum: 
+do_gum: do_library
 	cd gum; $(MAKE)
 
-do_xsg:
+do_xsg: do_library
 	cd xsg; $(MAKE);
 
-do_pledit:
+do_pledit: do_library
 	cd pledit; $(MAKE) 
 
-rsalib:	
+do_rsa_library:	
 	- at if [ -f res-rsa/Makefile ]; then \
 		(cd res-rsa; $(MAKE) librsa.a) \
 	fi
 
-utils: rsalib
+do_utilities: do_rsa_library do_library
 	cd tools; $(MAKE) 
 	cd sequencer; $(MAKE)
 
-rsa_utils: 
+do_rsa_utilities: do_library
 	cd keycomp; $(MAKE)
 
-startup: 
+do_listener: do_library
 	cd newstartd; $(MAKE)
 
 cflags.h: Makefile $(CONFIG)
Index: gum/Makefile.am
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/gum/Makefile.am,v
retrieving revision 1.3
diff -u -r1.3 Makefile.am
--- gum/Makefile.am	10 Apr 2006 04:24:50 -0000	1.3
+++ gum/Makefile.am	22 Apr 2006 08:53:25 -0000
@@ -13,7 +13,7 @@
 	signals.c signals.h \
 	id.c xmalloc.c
 
-gum_LDADD = @GTK_LIBS@ ../ntserv/data.o 
+gum_LDADD = @GTK_LIBS@ ../ntserv/libnetrek.a
 
 AM_CFLAGS = @AM_CFLAGS@ -DPACKAGE_DATA_DIR=\"@prefix@\"
 
Index: gum/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/gum/Makefile.in,v
retrieving revision 1.3
diff -u -r1.3 Makefile.in
--- gum/Makefile.in	10 Apr 2006 04:24:50 -0000	1.3
+++ gum/Makefile.in	22 Apr 2006 08:53:26 -0000
@@ -1,4 +1,4 @@
-# Makefile.in generated by automake 1.9.5 from Makefile.am.
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
 # @configure_input@
 
 # Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
@@ -14,8 +14,6 @@
 
 @SET_MAKE@
 
-SOURCES = $(gum_SOURCES)
-
 srcdir = @srcdir@
 top_srcdir = @top_srcdir@
 VPATH = @srcdir@
@@ -56,7 +54,7 @@
 am_gum_OBJECTS = support.$(OBJEXT) main.$(OBJEXT) signals.$(OBJEXT) \
 	id.$(OBJEXT) xmalloc.$(OBJEXT)
 gum_OBJECTS = $(am_gum_OBJECTS)
-gum_DEPENDENCIES = ../ntserv/data.o
+gum_DEPENDENCIES = ../ntserv/libnetrek.a
 DEFAULT_INCLUDES = -I. -I$(srcdir)
 depcomp = $(SHELL) $(top_srcdir)/depcomp
 am__depfiles_maybe = depfiles
@@ -168,7 +166,7 @@
 	signals.c signals.h \
 	id.c xmalloc.c
 
-gum_LDADD = @GTK_LIBS@ ../ntserv/data.o 
+gum_LDADD = @GTK_LIBS@ ../ntserv/libnetrek.a
 AM_CFLAGS = @AM_CFLAGS@ -DPACKAGE_DATA_DIR=\"@prefix@\"
 all: all-recursive
 
Index: gum/aclocal.m4
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/gum/aclocal.m4,v
retrieving revision 1.2
diff -u -r1.2 aclocal.m4
--- gum/aclocal.m4	10 Apr 2006 04:24:50 -0000	1.2
+++ gum/aclocal.m4	22 Apr 2006 08:53:29 -0000
@@ -1,4 +1,4 @@
-# generated automatically by aclocal 1.9.5 -*- Autoconf -*-
+# generated automatically by aclocal 1.9.6 -*- Autoconf -*-
 
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
 # 2005  Free Software Foundation, Inc.
@@ -17,7 +17,7 @@
 dnl AM_PATH_GTK([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, MODULES]]]])
 dnl Test for GTK, and define GTK_CFLAGS and GTK_LIBS
 dnl
-AC_DEFUN(AM_PATH_GTK,
+AC_DEFUN([AM_PATH_GTK],
 [dnl 
 dnl Get the cflags and libraries from the gtk-config script
 dnl
@@ -223,7 +223,7 @@
 # Call AM_AUTOMAKE_VERSION so it can be traced.
 # This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
 AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-	 [AM_AUTOMAKE_VERSION([1.9.5])])
+	 [AM_AUTOMAKE_VERSION([1.9.6])])
 
 # AM_AUX_DIR_EXPAND                                         -*- Autoconf -*-
 
Index: include/proto.h
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/include/proto.h,v
retrieving revision 1.4
diff -u -r1.4 proto.h
--- include/proto.h	10 Apr 2006 10:56:31 -0000	1.4
+++ include/proto.h	22 Apr 2006 08:53:40 -0000
@@ -93,6 +93,12 @@
 void getshipdefaults(void);
 void getship(struct ship *shipp, int s_type);
 
+/* glog.c */
+void glog_close(void);
+int glog_open();
+void glog_printf(const char *fmt, ...);
+void glog_flush();
+
 /* input.c */
 void input(void);
 
Index: keycomp/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/keycomp/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- keycomp/Makefile.in	21 Mar 2005 10:17:16 -0000	1.2
+++ keycomp/Makefile.in	22 Apr 2006 08:53:40 -0000
@@ -14,10 +14,10 @@
 INSTALLPROG = @INSTALL_PROGRAM@
 INSTALLDATA = @INSTALL_DATA@
 
-SRCS = ${srcdir}/rsa_keycomp.c ${srcdir}/../ntserv/getpath.c ${srcdir}/../ntserv/data.c ${srcdir}/rsa_key2cap.c $(RANDOMC)
-OBJS = rsa_keycomp.o ../ntserv/getpath.o ../ntserv/data.o $(STRDUPO) $(RANDOMO)
+SRCS = ${srcdir}/rsa_keycomp.c ${srcdir}/rsa_key2cap.c $(RANDOMC)
+OBJS = rsa_keycomp.o $(STRDUPO) $(RANDOMO) ../ntserv/libnetrek.a
 
-CFLAGS = $(MOREDEFS) $(FLAGS) -I../include -I${srcdir}/../include -I. -I${srcdir}
+CFLAGS = $(MOREDEFS) $(FLAGS) -I../include
 
 LINTFLAGS = -habxc $(MOREDEFS) $(FLAGS)
 
Index: newstartd/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/newstartd/Makefile.in,v
retrieving revision 1.3
diff -u -r1.3 Makefile.in
--- newstartd/Makefile.in	28 Sep 2005 12:14:05 -0000	1.3
+++ newstartd/Makefile.in	22 Apr 2006 08:53:40 -0000
@@ -13,19 +13,16 @@
 INSTALLDATA = @INSTALL_DATA@
 
 N_SRC = ${srcdir}/newstartd.c ${srcdir}/newaccess.c ${srcdir}/subnet.c
-N_OBJS = newstartd.o newaccess.o subnet.o
+N_OBJS = newstartd.o newaccess.o subnet.o ../ntserv/libnetrek.a
 
 LIBS = $(EXTRALIBS)
 
-GETPATH_SRC = ${srcdir}/../ntserv/getpath.c ${srcdir}/../ntserv/data.c
-GETPATH = ../ntserv/getpath.o ../ntserv/data.o
-
-CFLAGS = $(FLAGS) $(EXTRAFLAGS) $(PORT) -I. -I${srcdir} -I../include -I${srcdir}/../include
+CFLAGS = $(FLAGS) $(EXTRAFLAGS) $(PORT) -I../include
 
 all: newstartd
 
-newstartd: $(N_OBJS) $(GETPATH)
-	$(CC) $(CFLAGS) ${LDFLAGS} -o $@ $(N_OBJS) $(GETPATH) $(LIBS)
+newstartd: $(N_OBJS)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o $@ $(N_OBJS) $(LIBS)
 
 clean: rmdependencies
 	/bin/rm -f *.o make.out core
@@ -43,7 +40,7 @@
 	ln -sf $(LIBDIR)/newstartd $(DESTDIR)$(BINDIR)/netrekd
 
 depend: 
-	${CC} -M  $(CFLAGS) $(N_SRC) $(GETPATH_SRC) > .depend
+	${CC} -M  $(CFLAGS) $(N_SRC) > .depend
 
 rmdependencies:
 	rm -f .depend
Index: ntserv/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/Makefile.in,v
retrieving revision 1.4
diff -u -r1.4 Makefile.in
--- ntserv/Makefile.in	10 Apr 2006 10:56:31 -0000	1.4
+++ ntserv/Makefile.in	22 Apr 2006 08:53:40 -0000
@@ -1,5 +1,3 @@
-#	Change CONFIG to your .mk file
-
 VPATH = @srcdir@
 srcdir = @srcdir@
 
@@ -11,25 +9,41 @@
 INSTALLPROG = @INSTALL_PROGRAM@
 INSTALLDATA = @INSTALL_DATA@
 
-#	Do not edit below here. Everything should be setup in config
+#	libnetrek object files
+
+L_OBJS = bay.o \
+	coup.o \
+	data.o db.o detonate.o distress.o \
+	enter.o \
+	feature.o features.o \
+	gencmds.o genspkt.o getpath.o getship.o glog.o \
+	interface.o \
+	ltd_stats.o \
+	openmem.o orbit.o \
+	phaser.o ping.o plasma.o \
+	rsa_key.o reserved.o \
+	salt.o slotmaint.o sintab.o smessage.o socket.o startrobot.o sysdefaults.o \
+	torp.o transwarp.o \
+	util.o \
+	warning.o
 
 #	ntserv object files
 
-R_OBJS =    cluecheck.o coup.o data.o db.o death.o detonate.o enter.o \
-	    findslot.o  getentry.o  getname.o  salt.o getship.o  input.o \
+R_OBJS =    cluecheck.o coup.o db.o death.o detonate.o enter.o \
+	    findslot.o  getentry.o  getname.o  getship.o  input.o \
 	    interface.o  main.o  orbit.o  phaser.o  plasma.o  redraw.o \
 	    reserved.o  sintab.o  socket.o  genspkt.o  smessage.o  \
 	    startrobot.o  sysdefaults.o  timecheck.o  torp.o  util.o  \
-	    warning.o ping.o $(RANDOMO) getpath.o $(STRDUPO) features.o \
+	    warning.o ping.o $(RANDOMO) $(STRDUPO) features.o \
 	    distress.o transwarp.o gencmds.o ntscmds.o openmem.o feature.o \
-	    queue.o slotmaint.o rsa_key.o ltd_stats.o bay.o
+	    queue.o slotmaint.o rsa_key.o ltd_stats.o libnetrek.a
 
 
 #	daemonII object files
 
-D_OBJS =    daemonII.o  sintab.o  sysdefaults.o  data.o  slotmaint.o \
-	    util.o  $(RANDOMO) getpath.o getship.o smessage.o  queue.o \
-	    wander2.o openmem.o solicit.o ltd_stats.o bay.o
+D_OBJS =    daemonII.o  sintab.o  sysdefaults.o  slotmaint.o \
+	    util.o  $(RANDOMO) getship.o smessage.o  queue.o \
+	    wander2.o openmem.o solicit.o ltd_stats.o libnetrek.a
 
 #	Src files
 
@@ -48,15 +62,14 @@
             ${srcdir}/features.c ${srcdir}/distress.c ${srcdir}/transwarp.c \
             ${srcdir}/gencmds.c ${srcdir}/ntscmds.c ${srcdir}/openmem.c \
             ${srcdir}/feature.c ${srcdir}/queue.c ${srcdir}/slotmaint.c \
-            ${srcdir}/wander2.c ${srcdir}/sysdefaults.c ${srcdir}/rsa_key.c \
-            ${srcdir}/bay.c
+            ${srcdir}/wander2.c ${srcdir}/sysdefaults.c ${srcdir}/rsa_key.c
 
 SRC = 	    $(R_FILES)  data.h  defs.h planets.h  struct.h \
 	    packets.h  copyright.h
 
 LIBS = $(RSA_LIB) $(EXTRALIBS)
 
-INCS = $(RSA_INCS) $(EXTRAINCS) -I. -I${srcdir} -I../include -I${srcdir}/../include
+INCS = $(RSA_INCS) $(EXTRAINCS) -I../include
 
 CFLAGS = $(FLAGS) $(INCS)
 
@@ -71,6 +84,13 @@
 daemonII: $(PMAKE) $(D_OBJS)
 	$(CC) $(CFLAGS) ${LDFLAGS} -o daemonII $(D_OBJS) $(EXTRALIBS)
 
+libnetrek.a: $(L_OBJS)
+	ar cru $@ $(L_OBJS)
+	ranlib $@
+
+libnetrek.so: $(L_OBJS)
+	gcc -shared -Wl,-soname,$@ -o $@ $(L_OBJS) -lc
+
 commands.o: $(PMAKE) ${srcdir}/commands.c
 	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/commands.c
 
@@ -88,12 +108,11 @@
 	ling $(LINTFLAGS) $(SRC)
 
 clean: rmdependencies
-	/bin/rm -f *.o *.ln make.out core
+	/bin/rm -f *.a *.o *.ln make.out core
 
 reallyclean:  clean
 	rm -f ntserv daemonII .motd *~ #*#
 
-
 uninstall:
 	-cd $(XTREKDIR); rm -f daemonII .motd .sysdef; rm -rf slots
 	-cd $(LIBDIR); rm -f ntserv ; rm -rf slots
Index: ntserv/commands.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/commands.c,v
retrieving revision 1.2
diff -u -r1.2 commands.c
--- ntserv/commands.c	22 Apr 2006 02:16:46 -0000	1.2
+++ ntserv/commands.c	22 Apr 2006 08:53:44 -0000
@@ -1080,7 +1080,6 @@
     char *current;
     int pcount=0;  /* Total players in game */
     int vcount=0;  /* Number who've voted recently */
-    FILE *glog;
     int mflag = 0;
     int sendto = 0;
 
@@ -1094,22 +1093,19 @@
 #endif
 
     if ( votes[num].tag & VC_GLOG ){
-      if (!(glog = fopen(GodLog,"a")) )       /* Log votes for God to see */
-        perror(GodLog);
-      else {
+      if (glog_open() == 0) {	/* Log votes for God to see */
         time_t    t = time(NULL);
         char      tbuf[40];
         struct tm *tmv = localtime(&t);
       
 #ifdef STRFTIME
-      sprintf(tbuf, "%02d/%02d %d/%d", tmv->tm_hour,tmv->tm_min,
-              tmv->tm_mday,tmv->tm_mon);
+	sprintf(tbuf, "%02d/%02d %d/%d", tmv->tm_hour,tmv->tm_min,
+		tmv->tm_mday,tmv->tm_mon);
 #else
 	strftime(tbuf, 39, "%R %D", tmv);
 #endif
-        fprintf(glog, "VOTE: %s %s@%s \"%s\"\n", tbuf, players[who].p_login, 
-		players[who].p_monitor, comm);
- 	fclose(glog);
+        glog_printf("VOTE: %s %s@%s \"%s\"\n", tbuf, players[who].p_login, 
+		    players[who].p_ip, comm);
       }
     }
 
@@ -1184,11 +1180,8 @@
       pmessage(sendto, mflag, addr_mess(sendto,mflag), 
              "The motion %s passes", current);
       if ( votes[num].tag & VC_GLOG ){
-        if (!(glog = fopen(GodLog,"a")) )       /* Log pass for God to see */
-          perror(GodLog);
-        else {
- 	  fprintf(glog, "VOTE: The motion %s passes\n", current);
-	  fclose(glog);
+        if (glog_open() == 0) {	/* Log pass for God to see */
+ 	  glog_printf("VOTE: The motion %s passes\n", current);
 	}
       }
       
Index: ntserv/data.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/data.c,v
retrieving revision 1.3
diff -u -r1.3 data.c
--- ntserv/data.c	27 Sep 2005 12:26:37 -0000	1.3
+++ ntserv/data.c	22 Apr 2006 08:53:45 -0000
@@ -26,11 +26,7 @@
 
 int	oldalert = PFGREEN;	/* Avoid changing more than we have to */
 
-#ifdef XSG
-int     remap[16] = { 0, 1, 2, 0, 3, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0 };
-#else
 int 	remap[9] = { 0, 1, 2, -1, 3, -1, -1, -1, 4 };
-#endif
 int	reality = 10;		/* reality updates per second */
 int	minskip = 10;		/* maximum client updates per second */
 int	defskip = 5;		/* default client updates per second */
@@ -409,3 +405,4 @@
 int remoteaddr = -1;		/* inet address in net format */
 int whitelisted = 0;
 int blacklisted = 0;
+int ignored[MAXPLAYER];
Index: ntserv/gencmds.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/gencmds.c,v
retrieving revision 1.1
diff -u -r1.1 gencmds.c
--- ntserv/gencmds.c	21 Mar 2005 05:23:43 -0000	1.1
+++ ntserv/gencmds.c	22 Apr 2006 08:53:45 -0000
@@ -49,7 +49,6 @@
 {
   int i, len;
   char *comm;
-  FILE *glog;
 
   if (!(mess->m_flags & MINDIV)) return 0;	/* double-check */
 
@@ -89,10 +88,7 @@
       /* Record vote in GodLog if C_GLOG is set */
       if (cmds[i].tag & C_GLOG )
       {
-	if (!(glog = fopen(GodLog,"a")) )       /* Log votes for God to see */
-	  perror(GodLog);
-	else
-	{
+	if (glog_open() == 0) {	/* Log votes for God to see */
 	  time_t    t = time(NULL);
 	  char      tbuf[40];
 	  struct tm *tmv = localtime(&t);
@@ -103,10 +99,9 @@
 #else
 	  strftime(tbuf, 39, "%R %D", tmv);
 #endif
-	  fprintf(glog, "VOTE: %s %s@%s \"%s\"\n", tbuf,
+	  glog_printf("VOTE: %s %s@%s \"%s\"\n", tbuf,
 		  players[mess->m_from].p_login, 
 		  players[mess->m_from].p_monitor, comm);
-	  fclose(glog);
 	}
       } /* !C_GLOG */
 
@@ -117,12 +112,8 @@
 	{
 	  if ( cmds[i].tag & C_GLOG ) {
 
-	    if (!(glog = fopen(GodLog,"a")) )       /* Log pass for God to see */
-	      perror(GodLog);
-	    else
-	    {
-	      fprintf(glog, "VOTE: The motion %s passes\n", comm);
-	      fclose(glog);
+	    if (glog_open() == 0) {	/* Log pass for God to see */
+	      glog_printf("VOTE: The motion %s passes\n", comm);
 	    }
           }
 	}
Index: ntserv/main.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/main.c,v
retrieving revision 1.5
diff -u -r1.5 main.c
--- ntserv/main.c	10 Apr 2006 10:38:22 -0000	1.5
+++ ntserv/main.c	22 Apr 2006 08:53:48 -0000
@@ -44,9 +44,7 @@
 static void printStats(void);
 static int checkbanned(char *login, char *host);
 
-
-int ignored[MAXPLAYER];	/* change 7/24/91 TC */
-
+extern int ignored[MAXPLAYER];
 int indie = 0;			/* always be indie 8/28/91 TC */
 int living = 1;			/* our ship is living, reset by death */
 
@@ -232,6 +230,7 @@
     else
 	STRNCPY(login, "Bozo", NAME_LEN);
     login[NAME_LEN - 1] = '\0';
+    endpwent();
 
     strcpy(pseudo, "Guest");
 
Index: ntserv/socket.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/ntserv/socket.c,v
retrieving revision 1.6
diff -u -r1.6 socket.c
--- ntserv/socket.c	22 Apr 2006 02:16:46 -0000	1.6
+++ ntserv/socket.c	22 Apr 2006 08:53:54 -0000
@@ -300,7 +300,7 @@
 #define MAX_NONFAT	10		/* if we have this much left, stop */
 
 #ifdef CHECKMESG
-static FILE	*mlog, *glog;
+static FILE	*mlog;
 #endif
 
 /*int           send_short        = 0;*/ /* is now in data.c , because of robotII.c */
@@ -507,10 +507,7 @@
 	if (!mlog) mlog = fopen(MesgLog, "a");
 	if (!mlog) perror(MesgLog);
     }
-    if (loggod) {
-	if (!glog) glog = fopen(GodLog,"a");
-	if (!glog) perror(GodLog);
-    }
+    if (loggod) glog_open();
 #endif
 
     clientDead=0;
@@ -627,10 +624,7 @@
 	if(!mlog) mlog = fopen(MesgLog, "a");
 	if(!mlog) perror(MesgLog);
     }
-    if(loggod){
-	if(!glog) glog = fopen(GodLog, "a");
-	if(!glog) perror(GodLog);
-    }
+    if (loggod) glog_open();
 #endif
 
     if(commMode == COMM_UDP) addSequenceFlags(udpbuf);
@@ -1844,8 +1838,8 @@
     if (packet->mesg[0] != '@')
 	return FALSE;
 
+    /* FIXME: never freed */
     version = (char *)strdup(INDEX(packet->mesg,'@')+1);
-    version[strlen(version)] = '\0';
     return TRUE;
 }
 
@@ -2841,12 +2835,9 @@
 		      (packet->group & MGOD))){
 	    static int counter = 0;
 
-	    if(!glog) {
-		ERROR(1,( "ntserv: ERROR, null glog file descriptor\n"));
-		return 0;
-	    }
-	    fprintf(glog, "%s\n", buf);
-	    fflush(glog);
+	    if(glog_open() != 0) return;
+	    glog_printf("%s\n", buf);
+	    glog_flush();
 	    counter++;
 
 	    /* response */
Index: pledit/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/pledit/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- pledit/Makefile.in	21 Mar 2005 10:17:17 -0000	1.2
+++ pledit/Makefile.in	22 Apr 2006 08:53:54 -0000
@@ -12,18 +12,13 @@
 INSTALLPROG = @INSTALL_PROGRAM@
 INSTALLDATA = @INSTALL_DATA@
 
-SRCS	= ${srcdir}/main.c ${srcdir}/edit.c ${srcdir}/input.c \
-	${srcdir}/../ntserv/getpath.c ${srcdir}/../ntserv/data.c \
-	${srcdir}/../ntserv/salt.c
-OBJS	= main.o edit.o input.o ../ntserv/getpath.o ../ntserv/data.o \
-	  ../ntserv/salt.o
+SRCS	= ${srcdir}/main.c ${srcdir}/edit.c ${srcdir}/input.c
+OBJS	= main.o edit.o input.o ../ntserv/libnetrek.a
 HDRS	= ${srcdir}/pledit.h
-# LIBCURSES = -lcurses
 LIBS	= $(LIBCURSES) $(LIBTERMCAP) $(LIBCRYPT) $(EXTRALIBS)
 PROGRAM	= pledit
 
-# NBR server cflags
-CFLAGS = $(FLAGS) $(EXTRAFLAGS) -I. -I${srcdir} -I../include -I${srcdir}/../include
+CFLAGS = $(FLAGS) $(EXTRAFLAGS) -I. -I../include
 
 all:	$(PROGRAM)
 
@@ -34,7 +29,7 @@
 	rm -f pledit #* *~
 
 clean: rmdependencies
-	-rm -f $(OBJS)
+	-rm -f *.o
 
 clobber: clean
 	-rm -f $(PROGRAM)
Index: robots/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/robots/Makefile.in,v
retrieving revision 1.3
diff -u -r1.3 Makefile.in
--- robots/Makefile.in	10 Apr 2006 10:56:33 -0000	1.3
+++ robots/Makefile.in	22 Apr 2006 08:53:55 -0000
@@ -1,103 +1,61 @@
-# Change CONFIG to the .mk file that matches your system
-
 CONFIG = system.mk
 VPATH = @srcdir@
 srcdir = @srcdir@
 
-# Do Not Change anything below this line. It should be setup in config
-
 include ../$(CONFIG)
 
 INSTALL = @INSTALL@
 INSTALLPROG = @INSTALL_PROGRAM@
 INSTALLDATA = @INSTALL_DATA@
 
-# this is for revised ntserv/struct.h
-
-CFLAGS = $(EXTRAINCS) $(FLAGS) -DROBOT -I. -I${srcdir} -I../include -I${srcdir}/../include
+CFLAGS = $(EXTRAINCS) $(FLAGS) -DROBOT -I. -I../include
 
 LIBS = $(EXTRALIBS)
 
 TOOLDIR= $(LIBDIR)/tools
 
-GETPATH = getpath.o ../ntserv/data.o
-
 LINTFLAGS = -habxc $(EXTRAINCS) $(FLAGS)
 
-#	Common Objects
-
-C_OBJS = ../ntserv/data.o detonate.o  enter.o ../ntserv/getship.o interface.o \
-	../ntserv/orbit.o ../ntserv/phaser.o ../ntserv/sintab.o \
-	../ntserv/openmem.o  sysdefaults.o ../ntserv/torp.o  \
-	../ntserv/util.o $(RANDOMO) ../ntserv/getpath.o ../ntserv/smessage.o \
-	roboshar.o ../ntserv/slotmaint.o ../ntserv/distress.o \
-	../ntserv/ltd_stats.o ../ntserv/bay.o 
-
-#	Puck Objects
-
-PUCK_OBJS = puck.o  puckmove.o commands_puck.o $(C_OBJS)
-
-#	Mars (dogfighter) Objects
-
-M_OBJS = mars.o marsmove.o commands_mars.o $(C_OBJS)
-
-#	Robot Objects
-
-R_OBJS = robotII.o rmove.o commands.o $(C_OBJS)
-
-#       basepractice object files
+C_OBJS = $(RANDOMO) roboshar.o ../ntserv/libnetrek.a
 
-B_OBJS = basep.o commands_basep.o $(C_OBJS)  
-
-#       newbie server object files
-
-N_OBJS = newbie.o commands_newbie.o $(C_OBJS)
-
-#       pre-T server object files
-
-P_OBJS = pret.o commands_pret.o $(C_OBJS)
-
-#	INL Objects
-
-I_OBJS = inl.o inlcomm.o inlcmds.o gencmds.o $(C_OBJS)
-
-
-SRCS = ${srcdir}/puck.c ${srcdir}/puckmove.c ${srcdir}/mars.c \
-	${srcdir}/marsmove.c ${srcdir}/robotII.c ${srcdir}/rmove.c \
-	${srcdir}/../ntserv/getpath.c ${srcdir}/../ntserv/data.c \
-	${srcdir}/detonate.c  ${srcdir}/../ntserv/enter.c \
-	${srcdir}/../ntserv/getship.c  ${srcdir}/../ntserv/interface.c \
-	${srcdir}/../ntserv/orbit.c  ${srcdir}/../ntserv/phaser.c \
-	${srcdir}/../ntserv/sintab.c ${srcdir}/../ntserv/openmem.c \
-	${srcdir}/../ntserv/sysdefaults.c ${srcdir}/../ntserv/torp.c \
-	${srcdir}/../ntserv/util.c $(RANDOMC) ${srcdir}/../ntserv/commands.c \
-	${srcdir}/../ntserv/smessage.c ${srcdir}/basep.c  ${srcdir}/../ntserv/wander2.c \
-	${srcdir}/newbie.c ${srcdir}/inl.c ${srcdir}/inlcomm.c \
-	${srcdir}/../ntserv/slotmaint.c ${srcdir}/inlcmds.c \
-	${srcdir}/../ntserv/gencmds.c ${srcdir}/pret.c
+SRCS = ${srcdir}/puck.c ${srcdir}/puckmove.c \
+	${srcdir}/mars.c ${srcdir}/marsmove.c \
+	${srcdir}/robotII.c ${srcdir}/rmove.c \
+	$(RANDOMC) ${srcdir}/../ntserv/commands.c \
+	${srcdir}/basep.c \
+	${srcdir}/newbie.c \
+	${srcdir}/inl.c ${srcdir}/inlcomm.c ${srcdir}/inlcmds.c \
+	${srcdir}/pret.c
 
 EXECS =	puck mars robotII basep newbie inl pret
 
 all: $(PMAKE) $(EXECS)
 
+PUCK_OBJS = puck.o puckmove.o commands_puck.o $(C_OBJS)
 puck: $(PMAKE) $(PUCK_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o puck $(PUCK_OBJS) $(EXTRALIBS)
 
+M_OBJS = mars.o marsmove.o commands_mars.o $(C_OBJS)
 mars: $(PMAKE) $(M_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o mars $(M_OBJS) $(EXTRALIBS)
 
+R_OBJS = robotII.o rmove.o commands.o $(C_OBJS)
 robotII: $(PMAKE) $(R_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o robotII  $(R_OBJS) $(EXTRALIBS)
 
+B_OBJS = basep.o commands_basep.o $(C_OBJS)  
 basep: $(PMAKE) $(B_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o basep $(B_OBJS) $(EXTRALIBS)
 
+N_OBJS = newbie.o commands_newbie.o $(C_OBJS)
 newbie: $(PMAKE) $(N_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o newbie $(N_OBJS) $(EXTRALIBS)
 
+P_OBJS = pret.o commands_pret.o $(C_OBJS)
 pret: $(PMAKE) $(P_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o pret $(P_OBJS) $(EXTRALIBS)
 
+I_OBJS = inl.o inlcomm.o inlcmds.o $(C_OBJS)
 inl: $(PMAKE) $(I_OBJS)
 	$(CC) $(CFLAGS)  ${LDFLAGS} -o inl $(I_OBJS) $(EXTRALIBS)
 
@@ -107,18 +65,6 @@
 commands_puck.o: $(PMAKE) ${srcdir}/../ntserv/commands.c
 	$(CC) $(CFLAGS) $(DEP) -DPUCK -c ${srcdir}/../ntserv/commands.c -o commands_puck.o
 
-gencmds.o: $(PMAKE) ${srcdir}/../ntserv/gencmds.c
-	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/../ntserv/gencmds.c
-
-sysdefaults.o: $(PMAKE) ${srcdir}/../ntserv/sysdefaults.c
-	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/../ntserv/sysdefaults.c
-
-interface.o: $(PMAKE) ${srcdir}/../ntserv/interface.c
-	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/../ntserv/interface.c
-
-enter.o: $(PMAKE) ${srcdir}/../ntserv/enter.c
-	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/../ntserv/enter.c
-
 commands.o: $(PMAKE) ${srcdir}/../ntserv/commands.c
 	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/../ntserv/commands.c -o commands.o
 
@@ -149,9 +95,6 @@
 	$(INSTALLPROG) $(INSTALLOPTS) ${srcdir}/end_tourney.pl $(DESTDIR)$(LIBDIR)/end_tourney.pl
 	$(INSTALLPROG) $(INSTALLOPTS) ${srcdir}/auto-archive.pl $(DESTDIR)$(LIBDIR)/auto-archive.pl
 
-updated: update.o ../ntserv/data.o getpath.o
-	$(CC) $(CFLAGS) -o updated  update.o data.o getpath.o $(EXTRALIBS)
-
 lint: $(SRCS)
 	lint $(LINTFLAGS) -u $?
 	touch lint
Index: robots/detonate.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/robots/detonate.c,v
retrieving revision 1.1
diff -u -r1.1 detonate.c
--- robots/detonate.c	21 Mar 2005 05:23:46 -0000	1.1
+++ robots/detonate.c	22 Apr 2006 08:53:55 -0000
@@ -1,3 +1,5 @@
+/* apparently obsolete, use ntserv/detonate.c */
+
 /*
  * detonate.c
  */
@@ -5,7 +7,6 @@
 
 #include <stdio.h>
 #include <sys/types.h>
-#include <sys/ipc.h>
 #include "defs.h"
 #include "struct.h"
 #include "data.h"
@@ -15,8 +16,7 @@
             (((a)->p_team == (b)->p_team) && !((a)->p_flags & PFPRACTR))
 
 
-void
-detothers ()
+void detothers ()
 {
   int dx, dy;
   struct player *j;
Index: robots/roboshar.c
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/robots/roboshar.c,v
retrieving revision 1.1
diff -u -r1.1 roboshar.c
--- robots/roboshar.c	21 Mar 2005 05:23:46 -0000	1.1
+++ robots/roboshar.c	22 Apr 2006 08:53:55 -0000
@@ -157,3 +157,13 @@
     return((u_char) nint((atan2((double) (x2 - x1),
         (double) (y1 - y2)) / M_PI * 128.)));
 }
+
+/*
+ * Null client packet sending function for ntserv specific code in
+ * enter.c and interface.c so that we can avoid compiling it in the
+ * robots directory, and use libnetrek instead.
+ */
+void sendClientPacket(void *ignored)
+{
+  return;
+}
Index: sequencer/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/sequencer/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- sequencer/Makefile.in	21 Mar 2005 10:17:18 -0000	1.2
+++ sequencer/Makefile.in	22 Apr 2006 08:53:55 -0000
@@ -14,33 +14,30 @@
 
 # this is for revised ntserv/struct.h
 
-CFLAGS = $(EXTRAINCS) $(FLAGS) -I. -I${srcdir} -I../include -I${srcdir}/../include
+CFLAGS = $(EXTRAINCS) $(FLAGS) -I../include
 
 LIBS = $(EXTRALIBS)
 
-TOOLDIR= $(LIBDIR)/tools
+TOOLDIR = $(LIBDIR)/tools
 
 LINTFLAGS = -habxc $(EXTRAINCS) $(FLAGS)
 
 #	Common Objects
 
-C_OBJS = ../ntserv/data.o  ../ntserv/openmem.o  ../ntserv/smessage.o \
-        roboshar.o ../ntserv/slotmaint.o 
+C_OBJS = roboshar.o ../ntserv/libnetrek.a
 
 #	Sequencer Objects
 
-S_OBJS = sequencer.o  commands_sequencer.o $(C_OBJS) ../ntserv/ltd_stats.o
+S_OBJS = sequencer.o commands_sequencer.o $(C_OBJS) ../ntserv/libnetrek.a
 
-SRCS = ${srcdir}/roboshar.c ${srcdir}/sequencer.c ${srcdir}/../ntserv/commands.c \
-	${srcdir}/../ntserv/data.c ${srcdir}/../ntserv/openmem.c \
-	${srcdir}/../ntserv/smessage.c ${srcdir}/../ntserv/slotmaint.c
+SRCS = ${srcdir}/roboshar.c ${srcdir}/sequencer.c
 
 EXECS =	sequencer 
 
 all: $(PMAKE) $(EXECS)
 
 sequencer: $(PMAKE) $(S_OBJS)
-	$(CC) $(CFLAGS)  ${LDFLAGS} -o sequencer $(S_OBJS) $(EXTRALIBS)
+	$(CC) $(CFLAGS)  ${LDFLAGS} -o sequencer $(S_OBJS) $(LIBS)
 
 commands_sequencer.o: $(PMAKE) ${srcdir}/../ntserv/commands.c
 	$(CC) $(CFLAGS) $(DEP) -DSEQUENCER -c ${srcdir}/../ntserv/commands.c -o commands_sequencer.o
Index: tools/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/tools/Makefile.in,v
retrieving revision 1.5
diff -u -r1.5 Makefile.in
--- tools/Makefile.in	10 Apr 2006 10:56:33 -0000	1.5
+++ tools/Makefile.in	22 Apr 2006 08:53:56 -0000
@@ -12,19 +12,15 @@
 INSTALLPROG = @INSTALL_PROGRAM@
 INSTALLDATA = @INSTALL_DATA@
 
-# this is for revised ntserv/struct.h
+CFLAGS = $(EXTRAINCS) $(FLAGS) -I../include
 
-CFLAGS = $(EXTRAINCS) $(FLAGS) -I. -I${srcdir} -I../include -I${srcdir}/../include
-
-#LIBCURSES = -lcurses
 LIBS = $(EXTRALIBS)
 
 TOOLDIR= $(LIBDIR)/tools
 
 LINTFLAGS = -habxc $(EXTRAINCS) $(FLAGS)
 
-OBJS_SHM = ../ntserv/data.o ../ntserv/openmem.o ../ntserv/ltd_stats.o
-OBJS_PATH = ../ntserv/getpath.o ../ntserv/data.o
+OBJS = ../ntserv/libnetrek.a
 
 SRCS = ${srcdir}/blotpassword.c ${srcdir}/loadchecker.c ${srcdir}/mess.c \
 	${srcdir}/mergescores.c \
@@ -33,13 +29,10 @@
 	${srcdir}/stat.c ${srcdir}/trimscores.c ${srcdir}/watchmes.c \
 	${srcdir}/fun.c ${srcdir}/xtkill.c ${srcdir}/keyman.c \
 	${srcdir}/nuke.c ${srcdir}/metaget.c \
-	${srcdir}/../ntserv/getpath.c ${srcdir}/../ntserv/data.c \
-	${srcdir}/../ntserv/distress.c ${srcdir}/../ntserv/getship.c \
-	${srcdir}/update.c ${srcdir}/../ntserv/openmem.c ${srcdir}/convert.c \
-	${srcdir}/conq_vert.c ${srcdir}/../ntserv/slotmaint.c $(RANDOMC) \
-	${srcdir}/sortdb.c ${srcdir}/../robots/roboshar.c \
-	${srcdir}/../ntserv/smessage.c ${srcdir}/ntpasswd.c \
-	${srcdir}/../ntserv/salt.c ${srcdir}/../ntserv/bay.c 
+	${srcdir}/update.c ${srcdir}/convert.c \
+	${srcdir}/conq_vert.c $(RANDOMC) \
+	${srcdir}/sortdb.c \
+	${srcdir}/ntpasswd.c
 
 EXECS =	blotpassword loadchecker mess message newscores planets players \
 	scores \
@@ -86,83 +79,80 @@
 	$(INSTALLPROG) $(INSTALLOPTS) cambot $(DESTDIR)$(LIBDIR)/cambot
 	$(INSTALLPROG) $(INSTALLOPTS) metaget $(DESTDIR)$(LIBDIR)/tools/metaget
 
-# cb_sock.o: packets.h ../ntserv/socket.c
-#	$(CC) -o ./cb_sock.o -g $(CFLAGS) -DCAMBOT -c ../ntserv/socket.c
-
-cambot: cambot.o $(OBJS_SHM) $(OBJS_PATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} cambot.o ../ntserv/genspkt.o ../ntserv/sysdefaults.o ../ntserv/getship.o ../ntserv/warning.o ../ntserv/smessage.o ../ntserv/distress.o ../ntserv/util.o $(OBJS_SHM) ../ntserv/getpath.o  $(RSA_LIB)
+cambot: cambot.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} cambot.o $(OBJS) $(RSA_LIB)
 
 sortdb: sortdb.o
 	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} sortdb.o
 
-ntpasswd: ntpasswd.o $(OBJS_PATH) ../ntserv/salt.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} ntpasswd.o $(OBJS_PATH) ../ntserv/salt.o $(LIBCRYPT)
+ntpasswd: ntpasswd.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} ntpasswd.o $(OBJS) $(LIBCRYPT)
 
-loadchecker: loadchecker.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} loadchecker.o $(OBJS_SHM) $(LIBS)
+loadchecker: loadchecker.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} loadchecker.o $(OBJS) $(LIBS)
 
-mess: mess.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mess.o $(OBJS_SHM) $(LIBS)
+mess: mess.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mess.o $(OBJS) $(LIBS)
 
-message: message.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} message.o $(OBJS_SHM) $(LIBS)
+message: message.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} message.o $(OBJS) $(LIBS)
 
-mergescores: mergescores.o $(OBJS_PATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mergescores.o $(OBJS_PATH) $(LIBS)
+mergescores: mergescores.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} mergescores.o $(OBJS) $(LIBS)
 
-newscores: newscores.o $(OBJS_PATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} newscores.o $(OBJS_PATH) $(LIBS)
+newscores: newscores.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} newscores.o $(OBJS) $(LIBS)
 
-planets: planets.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} planets.o $(OBJS_SHM) $(LIBS)
+planets: planets.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} planets.o $(OBJS) $(LIBS)
 
-players: players.o $(OBJS_SHM) $(RANDOMO)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} players.o $(OBJS_SHM) $(RANDOMO) $(LIBS)
+players: players.o $(OBJS) $(RANDOMO)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} players.o $(OBJS) $(RANDOMO) $(LIBS)
 
-nuke: nuke.o $(OBJS_SHM) $(RANDOMO)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} nuke.o $(OBJS_SHM) $(RANDOMO) $(LIBS)
+nuke: nuke.o $(OBJS) $(RANDOMO)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} nuke.o $(OBJS) $(RANDOMO) $(LIBS)
 
-scores: scores.o $(OBJS_PATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} scores.o $(OBJS_PATH) $(LIBS) ../ntserv/ltd_stats.o
+scores: scores.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} scores.o $(OBJS) $(LIBS)
 
-setgalaxy: setgalaxy.o $(RANDOMO) $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} setgalaxy.o $(RANDOMO) $(OBJS_SHM) $(LIBS)
+setgalaxy: setgalaxy.o $(RANDOMO) $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} setgalaxy.o $(RANDOMO) $(OBJS) $(LIBS)
 
-showgalaxy: showgalaxy.o ../ntserv/distress.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} showgalaxy.o ../ntserv/distress.o $(OBJS_SHM) $(LIBS) $(LIBCURSES) $(LIBTERMCAP)
+showgalaxy: showgalaxy.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} showgalaxy.o $(OBJS) $(LIBS) $(LIBCURSES) $(LIBTERMCAP)
 
-stat: stat.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} stat.o $(OBJS_SHM) $(LIBS)
+stat: stat.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} stat.o $(OBJS) $(LIBS)
 
 blotpassword: blotpassword.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} blotpassword.o $(OBJS_PATH) $(LIBS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} blotpassword.o $(OBJS) $(LIBS)
 
-trimscores: trimscores.o $(OBJS_PATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} trimscores.o $(OBJS_PATH) $(LIBS)
+trimscores: trimscores.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} trimscores.o $(OBJS) $(LIBS)
 
-watchmes: watchmes.o ../ntserv/distress.o $(OBJS_SHM)
-	$(CC) $(CFLAGS) ${LDFLAGS} watchmes.o ../ntserv/distress.o $(OBJS_SHM) $(LIBS) -o $@
+watchmes: watchmes.o $(OBJS)
+	$(CC) $(CFLAGS) ${LDFLAGS} watchmes.o $(OBJS) $(LIBS) -o $@
 
-xtkill: xtkill.o $(OBJS_SHM) $(OBJS_PATH) ../ntserv/getship.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o ../ntserv/bay.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} xtkill.o ../ntserv/getship.o ../ntserv/openmem.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o ../ntserv/bay.o $(OBJS_PATH) $(LIBS)
+xtkill: xtkill.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} xtkill.o $(OBJS) $(LIBS)
 
-keyman: keyman.o $(OBJS_PATH)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} keyman.o $(OBJS_PATH) $(LIBS)
+keyman: keyman.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} keyman.o $(OBJS) $(LIBS)
 
-fun: $(RANDOMO) fun.o $(OBJS_SHM)
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} fun.o $(RANDOMO) $(OBJS_SHM) $(LIBS)
+fun: $(RANDOMO) fun.o $(OBJS)
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} fun.o $(RANDOMO) $(OBJS) $(LIBS)
 
-convert: $(OBJS_PATH) convert.o
-	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} convert.o $(OBJS_PATH) $(LIBS)
+convert: $(OBJS) convert.o
+	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} convert.o $(OBJS) $(LIBS)
 
-updated: update.o $(OBJS_PATH)
-	$(CC) $(CFLAGS) ${LDFLAGS} -o updated update.o ../ntserv/ltd_stats.o $(OBJS_PATH) $(EXTRALIBS)
+updated: update.o $(OBJS)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o updated update.o $(OBJS) $(EXTRALIBS)
 
 ltd_dump: ltd_dump.o
-	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_dump ltd_dump.o ../ntserv/ltd_stats.o $(OBJS_PATH)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_dump ltd_dump.o $(OBJS)
 
 ltd_convert: ltd_convert.o
-	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_convert ltd_convert.o ../ntserv/ltd_stats.o $(OBJS_PATH)
+	$(CC) $(CFLAGS) ${LDFLAGS} -o ltd_convert ltd_convert.o $(OBJS)
 
 conq_vert: conq_vert.o
 	$(CC) -o $@ $(CFLAGS) ${LDFLAGS} conq_vert.o
Index: xsg/Makefile.in
===================================================================
RCS file: /cvsroot/netrek/server/Vanilla/xsg/Makefile.in,v
retrieving revision 1.2
diff -u -r1.2 Makefile.in
--- xsg/Makefile.in	21 Mar 2005 10:17:19 -0000	1.2
+++ xsg/Makefile.in	22 Apr 2006 08:53:56 -0000
@@ -18,42 +18,37 @@
 			defs.h oldbitmaps.h patchlevel.h struct.h version.h \
 			localdata.h
 
-SRCS =	${srcdir}/colors.c ${srcdir}/../ntserv/data.c ${srcdir}/defaults.c \
-	${srcdir}/dmessage.c ${srcdir}/../ntserv/getship.c \
+SRCS =	${srcdir}/colors.c ${srcdir}/defaults.c \
+	${srcdir}/dmessage.c \
 	${srcdir}/inform.c ${srcdir}/input.c ${srcdir}/main.c \
 	${srcdir}/modify.c ${srcdir}/newwin.c ${srcdir}/option.c \
 	${srcdir}/planetlist.c ${srcdir}/planets.c ${srcdir}/playerlist.c \
 	${srcdir}/redraw.c ${srcdir}/robotwin.c ${srcdir}/shmem.c \
 	${srcdir}/sintab.c ${srcdir}/smessage.c ${srcdir}/stats.c \
 	${srcdir}/util.c ${srcdir}/war.c ${srcdir}/warning.c \
-	${srcdir}/x11window.c ${srcdir}/localdata.c \
-	${srcdir}/../ntserv/getpath.c ${srcdir}/../ntserv/distress.c \
-	${srcdir}/../ntserv/slotmaint.c ${srcdir}/../ntserv/ltd_stats.c
-
-OBJS =	colors.o data.o defaults.o dmessage.o ../ntserv/getship.o inform.o \
-	input.o main.o modify.o newwin.o option.o planetlist.o planets.o \
-	playerlist.o redraw.o robotwin.o shmem.o sintab.o smessage.o stats.o \
-	util.o war.o warning.o x11window.o localdata.o ../ntserv/getpath.o \
-	../ntserv/distress.o ../ntserv/slotmaint.o ../ntserv/ltd_stats.o
+	${srcdir}/x11window.c ${srcdir}/localdata.c
+
+OBJS = colors.o defaults.o dmessage.o inform.o input.o localdata.o \
+	main.o modify.o newwin.o option.o planetlist.o planets.o playerlist.o \
+	redraw.o robotwin.o shmem.o sintab.o smessage.o stats.o util.o war.o \
+	warning.o x11window.o ../ntserv/libnetrek.a
 
 LIBS = $(X11LIB) $(EXTRALIBS)
-INCS = $(EXTRAINCS) $(X11INCLUDE)
+INCS = $(EXTRAINCS)
 
-CFLAGS = $(EXTRACFLAGS) $(FLAGS) ${INCS} -I. -I${srcdir} -I../include -I${srcdir}/../include
+CFLAGS = $(EXTRACFLAGS) $(FLAGS) ${INCS} -I../include
 
 all: xsg
 
 xsg: $(OBJS)
 	$(CC) $(CFLAGS) ${LDFLAGS} -o $@ $(OBJS) $(LIBS)
 
-# data.c has an ifdef XSG in it, it must be recompiled here.
-
-data.o:	${srcdir}/../ntserv/data.c
-	$(CC) $(CFLAGS) -c ${srcdir}/../ntserv/data.c
+x11window.o: x11window.c
+	$(CC) $(CFLAGS) $(X11INCLUDE) -c -o $@ $<
 
 clean:
 	/bin/rm -f *.o make.out core
-        
+
 reallyclean:  clean 
 	/bin/rm -f xsg #* *~
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060422/f6630408/attachment-0001.pgp 

From quozl at us.netrek.org  Mon Apr 24 05:10:37 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 24 Apr 2006 20:10:37 +1000
Subject: [netrek-dev] Conquest Parade Screenshots
Message-ID: <20060424101037.GC23845@us.netrek.org>

A few of you have asked me for screen shots of the new conquest parade
code in action.  Zach captured a few while running a client against a
test server.

http://quozl.linux.org.au/netrek/2006-04-24/

The sequence is:

- conquest message appears as GOD->ALL

- freeze for one second, then all ships decloak, made visible to all,
  and plasma in flight cancelled

- during the next five seconds:
	- all ships are moved slowly into a ring formation
	- a ring of plasma rotates out from the planet

- during the next three seconds:
	- the ring of plasma continues to enlarge approaching the ships

- in the last second:
	- GOD->ALL  Goodbye
	- ring of plasma and ships explode
	- reset galactic

- if there is no queue, allow return to new game

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From netrek at gmail.com  Mon Apr 24 05:34:52 2006
From: netrek at gmail.com (Zach)
Date: Mon, 24 Apr 2006 06:34:52 -0400
Subject: [netrek-dev] Conquest Parade Screenshots
In-Reply-To: <20060424101037.GC23845@us.netrek.org>
References: <20060424101037.GC23845@us.netrek.org>
Message-ID: <ecfa260c0604240334w6ab431fambf594c0a90cf6ed2@mail.gmail.com>

I hereby nominate that as coolest Vanilla mod of 2006 :-)

Zach


From mm_lists at pulsar-zone.net  Mon Apr 24 23:28:03 2006
From: mm_lists at pulsar-zone.net (Matthew Mondor)
Date: Tue, 25 Apr 2006 00:28:03 -0400
Subject: [netrek-dev] Repost, phadthai,
 metaserver robot count consistency &c
In-Reply-To: <20060410055056.GE1243@us.netrek.org>
References: <20060410055056.GE1243@us.netrek.org>
Message-ID: <20060425002803.578ee307@sat.xisop>

On Mon, 10 Apr 2006 15:50:56 +1000
James Cameron <quozl at us.netrek.org> wrote:

> The following message apparently hasn't made it to the mailing list, so
> I'm reposting it on behalf of an IRC user phadthai.

[...]

With the kind help of James, this was fixed.  The Vanilla solicit.c code
I used did not take into account multiple addresses of a DNS pool, which
is used for metaserver.netrek.org.  Probably that the only metaserver
updated used to be James', when lately only the orion.netrek.org one was
because of a change of the order of the DNS pool addresses.  This
currently was fixed by using two distinct lines in the metaservers
configuration file for now.  Everything works well again.

Thanks,
Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.


From stephen.thorne at gmail.com  Tue Apr 25 01:33:29 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 25 Apr 2006 16:33:29 +1000
Subject: [netrek-dev] Alternate source repositories
Message-ID: <3e8ca5c80604242333x5f1f957avd23f69f391baf5d1@mail.gmail.com>

Hi!

I've been fiddling with alternate source repositories, specifically
I've created an alternate 'darcs' source repository that mirrors the
changes in developer-access CVS. Current policy and thinking is that
darcs patches should be posted to this list, and post review they can
be integrated into 'upstream' SF CVS.

At this point, the 'cow' darcs repo is broken, and the vanilla repo is
missing some changes.

At this point, while I'd love people to use the darcs repo because I
love darcs, and I think it's a real nice way forward in the freedom of
software, I can't advocate using the darcs repo instead of CVS. It's
really quite experimental right now, and I would class it as
completely broken.

The current darcs repo which is http://www.netrek.org/ and manages the
website is working well, and patches are accepted for that website, I
refer speicfically to the repos named 'netrek-server',
'netrek-client-cow' and 'netrek-client-xp'.

Considering how important the consistancy of source repositories is to
development, I found it necessery to report the status of what's going
on here.
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Tue Apr 25 05:29:46 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 25 Apr 2006 20:29:46 +1000
Subject: [netrek-dev] Alternate source repositories
In-Reply-To: <3e8ca5c80604242333x5f1f957avd23f69f391baf5d1@mail.gmail.com>
References: <3e8ca5c80604242333x5f1f957avd23f69f391baf5d1@mail.gmail.com>
Message-ID: <20060425102946.GA7374@us.netrek.org>

To augment what Stephen has said, I'm finding darcs to be terribly
useful and I'm eager to use it more.  I've a repository for the server
on http://james.tooraweenah.com/darcs/netrek-server/ which I'm using to
track Continuum.

With personal repositories, other developers should be aware that there
may be patches that won't make it into a release.  For example, my
repository contains a Continuum config.h.in patch which shouldn't be in
the default release.  Developers who pull from this repository should
consider whether they need that patch.

-- 
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: 191 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060425/d699c6c6/attachment.pgp 

From williamb at its.caltech.edu  Tue Apr 25 09:04:37 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Tue, 25 Apr 2006 07:04:37 -0700 (PDT)
Subject: [netrek-dev] Addition of player ban power to Vanilla
Message-ID: <Pine.GSO.4.58.0604250656001.22580@sue>

I'd like to hear what other people think of the latest change to Vanilla.

From tanner at real-time.com  Tue Apr 25 11:18:14 2006
From: tanner at real-time.com (Bob Tanner)
Date: Tue, 25 Apr 2006 11:18:14 -0500
Subject: [netrek-dev] Alternate source repositories
In-Reply-To: <20060425102946.GA7374@us.netrek.org>
References: <3e8ca5c80604242333x5f1f957avd23f69f391baf5d1@mail.gmail.com>
	<20060425102946.GA7374@us.netrek.org>
Message-ID: <200604251118.14585.tanner@real-time.com>

On Tuesday 25 April 2006 05:29, James Cameron wrote:
> I've a repository for the server
> on http://james.tooraweenah.com/darcs/netrek-server/

darcs totally distributed like bitkeeper/bzr-ng?

Meaning no central repository and no central control?

Can you cherry pick changeset from darcs?

Does it support a super-repository (repo or repo, ie master list that other 
developers can submit their repo too)?

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288
-------------- 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/20060425/cf1557a2/attachment.pgp 

From niclas at acc.umu.se  Tue Apr 25 13:41:50 2006
From: niclas at acc.umu.se (Niclas Fredriksson)
Date: Tue, 25 Apr 2006 20:41:50 +0200 (MET_DST)
Subject: [netrek-dev] Addition of player ban power to Vanilla
In-Reply-To: <Pine.GSO.4.58.0604250656001.22580@sue>
References: <Pine.GSO.4.58.0604250656001.22580@sue>
Message-ID: <Pine.A41.4.64.0604252036290.49598@stalin.acc.umu.se>

On Tue, 25 Apr 2006, William Balcerski wrote:

> I'd like to hear what other people think of the latest change to Vanilla.
>> From the Changelog:
>
> +	* ntserv/ntscmds.c: add a vote to temporarily ban, which requires
> +	100 non-banned logins before the temporary ban expires.  If the
> +	banned IP address tries in the meanwhile, the countdown is
> +	manipulated upwards

I don't like this feature.

The good thing it would bring is that whenever someone is, for instance, 
dead duding the base and it's not a full game the team can have the player 
ejected for a long period of time.

The bad things it would bring is that first off, as Bill says, most likely 
it will be abused. Second, I also agree with Bill that it's very harsh 
with the 100 unique logins and that you're punished for checking if the 
ban has been lifted.

Normally when someone is acting like an asshole he gets ejected and can't 
log back in because there's a full game. If there isn't a full game it's 
not that easy to be a huge asshole worthy of a ban because there's 
normally not that much going on (and if there is a lot going on the game 
will be full pretty soon). So I really don't see that big a need for a 
temporary ban vote.

Maybe the people that think the ban is a good idea can speak up so that we 
get to hear why 1) it won't be abused 2) it's not too harsh and 3) 
ejecting someone isn't enough.

--Niclas


From stephen.thorne at gmail.com  Tue Apr 25 16:03:43 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 26 Apr 2006 07:03:43 +1000
Subject: [netrek-dev] Alternate source repositories
In-Reply-To: <200604251118.14585.tanner@real-time.com>
References: <3e8ca5c80604242333x5f1f957avd23f69f391baf5d1@mail.gmail.com>
	<20060425102946.GA7374@us.netrek.org>
	<200604251118.14585.tanner@real-time.com>
Message-ID: <3e8ca5c80604251403n267d71ffv1a79523bb6f7eb1f@mail.gmail.com>

On 4/26/06, Bob Tanner <tanner at real-time.com> wrote:
> On Tuesday 25 April 2006 05:29, James Cameron wrote:
> > I've a repository for the server
> > on http://james.tooraweenah.com/darcs/netrek-server/
>
> darcs totally distributed like bitkeeper/bzr-ng?
>
> Meaning no central repository and no central control?

Yes.

> Can you cherry pick changeset from darcs?

Yes.

> Does it support a super-repository (repo or repo, ie master list that other
> developers can submit their repo too)?

No, this is handled at a social level.
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Wed Apr 26 04:50:36 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Wed, 26 Apr 2006 19:50:36 +1000
Subject: [netrek-dev] darcs patch: move voting to site policy
Message-ID: <E1FYgfM-0007G8-8M@spice.lan>

Wed Apr 26 19:46:39 EST 2006  quozl at us.netrek.org
  * move voting to site policy
  This patch moves voting from config.h.in compile-time configuration to 
  run-time configuration file etc/sysdef.  It also places eject and ban 
  policy within the control of the server administrator rather than the 
  source project.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 15367 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060426/c4d20913/attachment.bin 

From netrek at gmail.com  Wed Apr 26 06:00:02 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 07:00:02 -0400
Subject: [netrek-dev] darcs patch: move voting to site policy
In-Reply-To: <E1FYgfM-0007G8-8M@spice.lan>
References: <E1FYgfM-0007G8-8M@spice.lan>
Message-ID: <ecfa260c0604260400n5c0a5745oaba2b5bdcf27e611@mail.gmail.com>

".sysdef"

On 4/26/06, quozl at us.netrek.org <quozl at us.netrek.org> wrote:
> Wed Apr 26 19:46:39 EST 2006  quozl at us.netrek.org
>   * move voting to site policy
>   This patch moves voting from config.h.in compile-time configuration to
>   run-time configuration file etc/sysdef.  It also places eject and ban
>   policy within the control of the server administrator rather than the
>   source project.
>
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>
>
>


From netrek at gmail.com  Wed Apr 26 06:26:00 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 07:26:00 -0400
Subject: [netrek-dev] list archive references problem
Message-ID: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>

I noticed, when googling various netrek topics, that Googe has lots of
references for list archives at addresses such as this message:

http://archives.real-time.com/pipermail/vanilla-devel/2001-April/000200.html

However this is now reference defunct.

Here is the cached copy:
http://72.14.203.104/search?q=cache:0mN69EShjgAJ:archives.real-time.com/pipermail/vanilla-devel/2001-April/000200.html+vanilla+netrek+sysdef&hl=en&gl=us&ct=clnk&cd=2&client=firefox-a

By browsing by Date I was able to find the message here:
http://archives.us.netrek.org/pipermail/netrek-dev/2001-April/000936.html

Just curious if there is a way we can get this consistent in terms of
Google taking you to the right place. I don't know how long it will
remain in Google's cache until the new location supercedes it. Perhaps
a script on the the site could automatically fix the URL and redirect
visitors?

Zach


From netrek at gmail.com  Wed Apr 26 06:32:45 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 07:32:45 -0400
Subject: [netrek-dev] ftp.netrek.org & Vanilla releases
Message-ID: <ecfa260c0604260432g2bc12926lefb66d1d468d5d71@mail.gmail.com>

Seems http://ftp.netrek.org doesn't have the latest Vanilla release.
Looks like only the SourceForge site is being updated with releases
for the past 3 years. Here is the latest one that's up there:

/pub/netrek/servers/vanilla/Vanilla-2.9pl8.tar.gz          
05-Dec-2002 21:32   952k

If you stick the latest release, Vanilla-2.10.2, up on ftp.netrek.org
perhaps you can update the Vanilla page to show a link to it (it
already lists several methods for getting the client):
http://vanilla.netrek.org/

Zach


From netrek at gmail.com  Wed Apr 26 06:51:01 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 07:51:01 -0400
Subject: [netrek-dev] online repository browsing
Message-ID: <ecfa260c0604260451i40c18502y8b6419bd427c383b@mail.gmail.com>

Just came across program for browsing cvs or svn repositories -
ViewVC. It looks really nice.
Maybe you can set it up for Vanilla and COW?

http://www.viewvc.org/

Zach


From quozl at us.netrek.org  Wed Apr 26 08:08:39 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Wed, 26 Apr 2006 23:08:39 +1000
Subject: [netrek-dev] darcs patch: move voting to site policy (and 1 more)
Message-ID: <E1FYjl1-0007da-Fm@spice.lan>

Wed Apr 26 19:46:39 EST 2006  quozl at us.netrek.org
  * move voting to site policy
  This patch moves voting from config.h.in compile-time configuration to 
  run-time configuration file etc/sysdef.  It also places eject and ban 
  policy within the control of the server administrator rather than the 
  source project.

Wed Apr 26 23:01:58 EST 2006  quozl at us.netrek.org
  * sndFlags was called without initialised pointer
  Fix regression introduced in 2003-01-08, with the addition of visible
  tractors for observers.  The sndFlags function was being called with
  a pointer that was not valid.  The results were unpredictable; on i386
  the server state was corrupted, causing mass confusion of the clients,
  and on sparc (from memory) cambot simply segfaulted.  Thanks to KeyOS
  and the guys in IRC for ideas to debug.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 16667 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060426/3f257c0c/attachment-0001.bin 

From quozl at us.netrek.org  Wed Apr 26 08:12:25 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 26 Apr 2006 23:12:25 +1000
Subject: [netrek-dev] list archive references problem
In-Reply-To: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>
References: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>
Message-ID: <20060426131225.GA29562@us.netrek.org>

On Wed, Apr 26, 2006 at 07:26:00AM -0400, Zach wrote:
> http://archives.real-time.com/pipermail/vanilla-devel/2001-April/000200.html

Bob is responsible for those URLs.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Wed Apr 26 08:15:57 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 26 Apr 2006 23:15:57 +1000
Subject: [netrek-dev] online repository browsing
In-Reply-To: <ecfa260c0604260451i40c18502y8b6419bd427c383b@mail.gmail.com>
References: <ecfa260c0604260451i40c18502y8b6419bd427c383b@mail.gmail.com>
Message-ID: <20060426131557.GC29562@us.netrek.org>

On Wed, Apr 26, 2006 at 07:51:01AM -0400, Zach wrote:
> Just came across program for browsing cvs or svn repositories -
> ViewVC. It looks really nice.
> Maybe you can set it up for Vanilla and COW?

SoruceForge already has a web viewing service for CVS repositories, in
what way does ViewVC help?

Does it work with darcs?

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Wed Apr 26 08:15:04 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 26 Apr 2006 23:15:04 +1000
Subject: [netrek-dev] ftp.netrek.org & Vanilla releases
In-Reply-To: <ecfa260c0604260432g2bc12926lefb66d1d468d5d71@mail.gmail.com>
References: <ecfa260c0604260432g2bc12926lefb66d1d468d5d71@mail.gmail.com>
Message-ID: <20060426131504.GB29562@us.netrek.org>

ftp.netrek.org is not currently maintained.

As you say, you will find releases on SourceForge.

You will also find them on my web site, as the Vanilla page says.
Perhaps you missed that.

It says:

Version 2.10.2 of the Netrek Vanilla Server was released on 22nd
February 2006 and may be downloaded from:

    * http://quozl.linux.org.au/netrek/

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Wed Apr 26 08:17:48 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 26 Apr 2006 23:17:48 +1000
Subject: [netrek-dev] darcs patch: move voting to site policy
In-Reply-To: <ecfa260c0604260400n5c0a5745oaba2b5bdcf27e611@mail.gmail.com>
References: <E1FYgfM-0007G8-8M@spice.lan>
	<ecfa260c0604260400n5c0a5745oaba2b5bdcf27e611@mail.gmail.com>
Message-ID: <20060426131748.GD29562@us.netrek.org>

On Wed, Apr 26, 2006 at 07:00:02AM -0400, Zach wrote:
> ".sysdef"

Wrong.  etc/sysdef.  Please catch up with the current source code.  This
was changed in 2.10.0 in September 2005, and is how it works in the
current source repositories.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From netrek at gmail.com  Wed Apr 26 08:25:46 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 09:25:46 -0400
Subject: [netrek-dev] online repository browsing
In-Reply-To: <20060426131557.GC29562@us.netrek.org>
References: <ecfa260c0604260451i40c18502y8b6419bd427c383b@mail.gmail.com>
	<20060426131557.GC29562@us.netrek.org>
Message-ID: <ecfa260c0604260625j1015ca0ax182b6de5f0fd960@mail.gmail.com>

On 4/26/06, James Cameron <quozl at us.netrek.org> wrote:
>
> SoruceForge already has a web viewing service for CVS repositories, in
> what way does ViewVC help?
>
> Does it work with darcs?

Nope just CVS and SVN, but I looked at the darcs author's website and
there is a CGI script, darcs.cgi, that will allow us to view
repositories from the web. Here is the script in action on his
website: http://abridgegame.org/cgi-bin/darcs.cgi/darcs/

Zach


From tanner at real-time.com  Wed Apr 26 08:24:50 2006
From: tanner at real-time.com (Bob Tanner)
Date: Wed, 26 Apr 2006 08:24:50 -0500
Subject: [netrek-dev] list archive references problem
In-Reply-To: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>
References: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>
Message-ID: <200604260824.55099.tanner@real-time.com>

On Wednesday 26 April 2006 06:26, Zach wrote:
> I noticed, when googling various netrek topics, that Googe has lots of
> references for list archives at addresses such as this message:
>
> http://archives.real-time.com/pipermail/vanilla-devel/2001-April/000200.htm

Fall out of the upgrade of the mailing list server. For awhile all MLs 
answered in duality (both archives.real-time.com and 
archives.virtual.domain.com).

It was unfortunate that google picked the .real-time.com temp domain during 
the upgrade period.

I see if mod_rewrite can help.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288
-------------- 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/20060426/6eefe0f9/attachment.pgp 

From williamb at its.caltech.edu  Wed Apr 26 10:34:20 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 26 Apr 2006 08:34:20 -0700 (PDT)
Subject: [netrek-dev] Trying to track down warp 0 cloak/shield bug
Message-ID: <Pine.GSO.4.58.0604260822590.26577@inky>

Been trying to find the cause of the following bug:
If you are warp 0 and raise/lower shields or cloak/decloak, there are
certain situations where this information is not passed on to other
players on your tactical.  The following conditions must be met:
1) The other player must also be at warp 0.
2) There must be no one else who can see your ships on the galactic who is
doing anything.  For example, if there is a fed ship in galactic visual
range, and you are testing the bug with 2 ori ships, if the fed takes any
action at all (move, fire, change direction, etc), then the bug does not
occur.  However if the fed is out of galactic visual range, then no matter
what he does, the bug will still occur.

I noticed that a "fix" to this bug is to comment out the following in the
function sndFlags in /ntserv/genspkt.c

    /* With short packets 2 flag sampling, these don't need to be sent */
    if (send_short>1 && pl->p_no<32)
    	mask &= ~(PFSHIELD|PFCLOAK);

Basically, shield/cloak info is not sent by the small update (indeed,
requesting a small update does not refresh cloak/shield info, the
bug still occurs).  I don't believe this is the proper fix, but it at
least does narrow down what is going wrong.  However, I cannot figure out
the packet sequence, namely, what the threshhold is for triggering the
server to send more than the basic small update info to players.  I find
the whole packet code some tortuous and confusing, especially the whole
F19/short packet 2 flag sampling deal.  Any help in finding the cause and
a proper fix would be appreciated.
Bill


From xyzzy at speakeasy.org  Wed Apr 26 16:04:54 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 26 Apr 2006 14:04:54 -0700 (PDT)
Subject: [netrek-dev] Trying to track down warp 0 cloak/shield bug
In-Reply-To: <Pine.GSO.4.58.0604260822590.26577@inky>
References: <Pine.GSO.4.58.0604260822590.26577@inky>
Message-ID: <Pine.LNX.4.58.0604261351380.5286@shell3.speakeasy.net>

On Wed, 26 Apr 2006, William Balcerski wrote:
> Been trying to find the cause of the following bug:
> If you are warp 0 and raise/lower shields or cloak/decloak, there are

Player cloak/shield status is sent along with player positions in the VPlayer
packet.  If no one at all moves, you don't get a new position packet and so the
flags aren't sent.  Normally this just doesn't matter as no visible ships moving
never happens.  What you would need to do is keep track of if a VPlayer packet
is sent or not, and only consider the flags sent if it is.  Doesn't seem worth
the trouble for a display glitch that only appears under controlled conditions.

> Basically, shield/cloak info is not sent by the small update (indeed,
> requesting a small update does not refresh cloak/shield info, the
> bug still occurs).  I don't believe this is the proper fix, but it at

James added a kludge years ago so that no flags at all aren't sent on updates,
to avoid a buffer overflow on old clients.  Maybe that's still the problem, I
don't know if that code is still there.


From dopleganger_69 at hotmail.com  Wed Apr 26 17:27:56 2006
From: dopleganger_69 at hotmail.com (Pascal Gagnon)
Date: Wed, 26 Apr 2006 18:27:56 -0400
Subject: [netrek-dev] Defcom tactical sample
Message-ID: <BAY107-F3527A681ACC2D2811EEF3BF5BC0@phx.gbl>

people was worried about scaling up netrek game so i have made a sample of 
tactical screen p?tting a ship i have made a planet and torp just twice the 
scaling of original netrek bmp i could do better like third time the normal 
scaling to show more details

_________________________________________________________________
Des m?canismes de contr?le parental puissants permettent ? votre enfant de 
d?couvrir tout ce qu?Internet a ? offrir. 
http://join.msn.com/?pgmarket=fr-ca&page=features/parental&ST=1&xAPID=1983&DI=2043 
Commencez d?s maintenant ? profiter de tous les avantages de MSN Premium et 
obtenez les deux premiers mois GRATUITS*.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tactical sample at 1000x1000 ship at 40x40 planet at 60x60 copy.jpg
Type: image/pjpeg
Size: 29428 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060426/97214530/attachment-0001.bin 

From quozl at us.netrek.org  Wed Apr 26 19:17:49 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Thu, 27 Apr 2006 10:17:49 +1000
Subject: [netrek-dev] darcs patch: fix compilation warnings in cambot.c when
	using -Wall
Message-ID: <E1FYuCb-0000eK-Sm@spice.lan>

Thu Apr 27 09:45:05 EST 2006  quozl at us.netrek.org
  * fix compilation warnings in cambot.c when using -Wall
  Yesterday's patch trimmed back includes to the minimum required for
  compilation without warnings, but I was testing without -Wall.  This patch
  reverses some of these changes and also adds prototypes for genspkt.c functions
  that cambot uses.
  
  A future patch may add -Wall to system.mk.in after a few other problems are
  solved.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 8991 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060427/ccdfc93c/attachment.bin 

From quozl at us.netrek.org  Wed Apr 26 20:06:20 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 27 Apr 2006 11:06:20 +1000
Subject: [netrek-dev] Trying to track down warp 0 cloak/shield bug
In-Reply-To: <Pine.LNX.4.58.0604261351380.5286@shell3.speakeasy.net>
References: <Pine.GSO.4.58.0604260822590.26577@inky>
	<Pine.LNX.4.58.0604261351380.5286@shell3.speakeasy.net>
Message-ID: <20060427010619.GA2179@us.netrek.org>

On Wed, Apr 26, 2006 at 02:04:54PM -0700, Trent Piepho wrote:
> James added a kludge years ago so that no flags at all aren't sent on
> updates, to avoid a buffer overflow on old clients.  Maybe that's
> still the problem, I don't know if that code is still there.

Good call, maybe it is still there.  I suspect that the buffer overflow
was merely the size of UDP packets sent, and I remember that I figured
out a simpler way to reduce that.

If anyone knows where to look, let me know.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Wed Apr 26 20:17:01 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 27 Apr 2006 11:17:01 +1000
Subject: [netrek-dev] Defcom tactical sample
In-Reply-To: <BAY107-F3527A681ACC2D2811EEF3BF5BC0@phx.gbl>
References: <BAY107-F3527A681ACC2D2811EEF3BF5BC0@phx.gbl>
Message-ID: <20060427011700.GB2179@us.netrek.org>

That looks fantastic.  Any chance of another mock-up based on a real
tactical display, with several planets, ships, and weapons?  Add a
background of stars?

Things to worry about when scaling up ...

- reach of mouse ... the galaxy coordinate offset traversed by the mouse
  in a 1000x1000 tactical will be half of the standard 500x500 client
  display, so it will have a very different feel unless people want some
  special mouse acceleration mode,

- smoothness of rotation ... the server keeps angle of rotation for
  ships as a number from 0 to 255, which is 1.4 degrees per bit ...
  clients have kept only certain rotations of the image, such as 16 of
  them, which is one every 22.5 degrees ... at higher resolution this
  rotation is more chunky, but then the update rate of ten per second
  and the orbital velocity may combine to change this yet again.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From xyzzy at speakeasy.org  Wed Apr 26 20:46:38 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 26 Apr 2006 18:46:38 -0700 (PDT)
Subject: [netrek-dev] Trying to track down warp 0 cloak/shield bug
In-Reply-To: <20060427010619.GA2179@us.netrek.org>
References: <Pine.GSO.4.58.0604260822590.26577@inky>
	<Pine.LNX.4.58.0604261351380.5286@shell3.speakeasy.net>
	<20060427010619.GA2179@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0604261843180.80@shell3.speakeasy.net>

On Thu, 27 Apr 2006, James Cameron wrote:
> On Wed, Apr 26, 2006 at 02:04:54PM -0700, Trent Piepho wrote:
> > James added a kludge years ago so that no flags at all aren't sent on
> > updates, to avoid a buffer overflow on old clients.  Maybe that's
> > still the problem, I don't know if that code is still there.
>
> Good call, maybe it is still there.  I suspect that the buffer overflow
> was merely the size of UDP packets sent, and I remember that I figured
> out a simpler way to reduce that.
>
> If anyone knows where to look, let me know.

That information would be in the missing CVS history....

The buffer overflow was caused the size of the UDP packet.  If the archive of
this list is still around, you can find where I found the cause of the 'full
update crashes client' bug and described it in some detail.


From darius at dons.net.au  Wed Apr 26 21:08:06 2006
From: darius at dons.net.au (Daniel O'Connor)
Date: Thu, 27 Apr 2006 11:38:06 +0930
Subject: [netrek-dev] darcs patch: fix compilation warnings in cambot.c
	when using -Wall
In-Reply-To: <E1FYuCb-0000eK-Sm@spice.lan>
References: <E1FYuCb-0000eK-Sm@spice.lan>
Message-ID: <200604271138.16525.darius@dons.net.au>

On Thursday 27 April 2006 09:47, quozl at us.netrek.org wrote:
>   A future patch may add -Wall to system.mk.in after a few other problems
> are solved.

I suggest turning it on now.

Add -Werror after you fix the existing warnings - it will prevent (hopefully) 
people committing code which generates warnings.

If you're feeling really enthusiastic you could recompile it with..
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls

Although not much code survives that level of compiler paranoia :)

Other good tools are Electric Fence and Valgrind - they are run time tools 
though, but are *excellent* for finding buffer overruns and the like 
(especially Valgrind which also finds memory leaks)

-- 
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

-- 
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/20060427/c1cee2a4/attachment.pgp 

From netrek at gmail.com  Wed Apr 26 21:10:14 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 22:10:14 -0400
Subject: [netrek-dev] darcs patch: fix compilation warnings in cambot.c
	when using -Wall
In-Reply-To: <E1FYuCb-0000eK-Sm@spice.lan>
References: <E1FYuCb-0000eK-Sm@spice.lan>
Message-ID: <ecfa260c0604261910r1f7e7661pf7acb29d3500bce0@mail.gmail.com>

Will patches to darcs also be applied to the cvs repository?

Zach


From netrek at gmail.com  Wed Apr 26 21:26:21 2006
From: netrek at gmail.com (Zach)
Date: Wed, 26 Apr 2006 22:26:21 -0400
Subject: [netrek-dev] Trying to track down warp 0 cloak/shield bug
In-Reply-To: <Pine.LNX.4.58.0604261843180.80@shell3.speakeasy.net>
References: <Pine.GSO.4.58.0604260822590.26577@inky>
	<Pine.LNX.4.58.0604261351380.5286@shell3.speakeasy.net>
	<20060427010619.GA2179@us.netrek.org>
	<Pine.LNX.4.58.0604261843180.80@shell3.speakeasy.net>
Message-ID: <ecfa260c0604261926ta76921ek95c56e63f6b93b00@mail.gmail.com>

On 4/26/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
>
> That information would be in the missing CVS history....

Does Bob have this missing CVS on a non-public machine perhaps?

> The buffer overflow was caused the size of the UDP packet.  If the archive
>of  this list is still around, you can find where I found the cause
of the 'full
> update crashes client' bug and described it in some detail.

Is this it:


From quozl at us.netrek.org  Thu Apr 27 00:26:24 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 27 Apr 2006 15:26:24 +1000
Subject: [netrek-dev] darcs patch: fix compilation warnings in cambot.c
	when using -Wall
In-Reply-To: <200604271138.16525.darius@dons.net.au>
References: <E1FYuCb-0000eK-Sm@spice.lan>
	<200604271138.16525.darius@dons.net.au>
Message-ID: <20060427052624.GC2179@us.netrek.org>

On Thu, Apr 27, 2006 at 11:38:06AM +0930, Daniel O'Connor wrote:
> On Thursday 27 April 2006 09:47, quozl at us.netrek.org wrote:
> >   A future patch may add -Wall to system.mk.in after a few other problems
> > are solved.
> 
> I suggest turning it on now.

Taken.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From quozl at us.netrek.org  Thu Apr 27 01:06:09 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 27 Apr 2006 16:06:09 +1000
Subject: [netrek-dev] Source Control
Message-ID: <20060427060609.GA7314@us.netrek.org>

Following a discussion this morning in IRC about how darcs and CVS are
difficult to use at the same time, I'm leaning toward migrating to darcs
at a planned date in the future; 1st June 2006.

See the Wiki page http://wiki.us.netrek.org/netrek-dev/SourceControl for
a history of source control in the Netrek project, and the plans for the
future.

-- 
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: 191 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060427/1b3c602b/attachment.pgp 

From quozl at us.netrek.org  Thu Apr 27 08:36:35 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 27 Apr 2006 23:36:35 +1000
Subject: [netrek-dev] darcs patch: fix compilation warnings in cambot.c
	when using -Wall
In-Reply-To: <ecfa260c0604261910r1f7e7661pf7acb29d3500bce0@mail.gmail.com>
References: <E1FYuCb-0000eK-Sm@spice.lan>
	<ecfa260c0604261910r1f7e7661pf7acb29d3500bce0@mail.gmail.com>
Message-ID: <20060427133635.GA9098@us.netrek.org>

On Wed, Apr 26, 2006 at 10:10:14PM -0400, Zach wrote:
> Will patches to darcs also be applied to the cvs repository?

If they are to be included in a release, yes.  Otherwise no.

darcs repositories vary in policy.  After 1st June, the authoritative
repository for the server source will be a darcs repository hosted on
www.netrek.org.  But already we have developer scoped darcs
repositories, such as Stephen's, mine, and Continuum's.  There may be
others we don't know about.  If you do a darcs get on any of these
repositories, then you'll have your own repository too.

What brings up the question for you?  What are you afraid of?  Is it
that you worry that patches will be lost because they are distributed
in several repositories?  Worry not.  It is the responsibility of the
release engineer to pick and choose what patches to apply when forming
a new release.

I'm only release engineer by default and experience.  As with any open
source project, there's nothing stopping anyone else from trying to do
better and release a version of Netrek with whatever they like changed.

-- 
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: 191 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060427/ae18ba69/attachment.pgp 

From quozl at us.netrek.org  Thu Apr 27 08:49:42 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 27 Apr 2006 23:49:42 +1000
Subject: [netrek-dev] online repository browsing
In-Reply-To: <ecfa260c0604260625j1015ca0ax182b6de5f0fd960@mail.gmail.com>
References: <ecfa260c0604260451i40c18502y8b6419bd427c383b@mail.gmail.com>
	<20060426131557.GC29562@us.netrek.org>
	<ecfa260c0604260625j1015ca0ax182b6de5f0fd960@mail.gmail.com>
Message-ID: <20060427134942.GB9098@us.netrek.org>

On Wed, Apr 26, 2006 at 09:25:46AM -0400, Zach wrote:
> Nope just CVS and SVN, but I looked at the darcs author's website and
> there is a CGI script, darcs.cgi, that will allow us to view
> repositories from the web. Here is the script in action on his
> website: http://abridgegame.org/cgi-bin/darcs.cgi/darcs/

Well, if you need online repository browsing, set it up.  Let us know
when you've got it running.

I can't see the use myself.

Nothing else relies upon Netrek, it's not like it is essential
infrastructure that other projects use.  Using darcs or CVS or
wget to obtain the source is easy.  The source isn't exactly large,
so there's no significant benefit in allowing individual file download
in some special fashion.

The darcs repositories are directly browsable anyway; you can make
reference to the current version of a file simply by using the URL
for the repository as a base.  For example, the NEWS file in the
Vanilla source tree ...

http://www.netrek.org/repos/netrek-server/Vanilla/NEWS

... and the same file in my repository ...

http://james.tooraweenah.com/darcs/netrek-server/Vanilla/NEWS

For those on 56k modem, darcs is still the fastest method over any CGI
interface, since the patches are gzip compressed, and don't include
any HTML encapsulation.  Once downloaded and cached, there's no need
to go back to the web until another patch arrives.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/


From tanner at real-time.com  Thu Apr 27 10:38:19 2006
From: tanner at real-time.com (Bob Tanner)
Date: Thu, 27 Apr 2006 10:38:19 -0500
Subject: [netrek-dev] list archive references problem
In-Reply-To: <200604260824.55099.tanner@real-time.com>
References: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>
	<200604260824.55099.tanner@real-time.com>
Message-ID: <200604271038.20357.tanner@real-time.com>

:u?vw?u???
k?]???<??hm6??????^"?????v???+^q??zZ@??!z??v???+^v????azZS??k??^?+0y?%??lz???????%v???YZ?+-?)??w???%??l??(???y?ay???+???h?Kazf????z????^????V???ljwZ???n??v?^??kzIb??}???+??'!jx"?ay????^ ;0zYc??aj??????+?? ??h??m????)??M??z?Z?w?????)?r?????????;?Hm????+y?m?g??c"?w?????{??}?ox??t???~)?z?k?{
From doconnor at gsoft.com.au  Wed Apr 26 20:32:17 2006
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu, 27 Apr 2006 11:02:17 +0930
Subject: [netrek-dev] darcs patch: fix compilation warnings in cambot.c
	when using -Wall
In-Reply-To: <E1FYuCb-0000eK-Sm@spice.lan>
References: <E1FYuCb-0000eK-Sm@spice.lan>
Message-ID: <200604271102.36760.doconnor@gsoft.com.au>

On Thursday 27 April 2006 09:47, quozl at us.netrek.org wrote:
>   A future patch may add -Wall to system.mk.in after a few other problems
> are solved.

I suggest turning it on now.

Add -Werror after you fix the existing warnings - it will prevent (hopefully) 
people committing code which generates warnings.

If you're feeling really enthusiastic you could recompile it with..
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls

Although not much code survives that level of compiler paranoia :)

Other good tools are Electric Fence and Valgrind - they are run time tools 
though, but are *excellent* for finding buffer overruns and the like 
(especially Valgrind which also finds memory leaks)

-- 
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/20060427/381656bb/attachment-0001.pgp 

From netrek at gmail.com  Thu Apr 27 23:44:54 2006
From: netrek at gmail.com (Zach)
Date: Fri, 28 Apr 2006 00:44:54 -0400
Subject: [netrek-dev] list archive references problem
In-Reply-To: <200604271038.20357.tanner@real-time.com>
References: <ecfa260c0604260426q59c5248avf5ff6710e9f69c1a@mail.gmail.com>
	<200604260824.55099.tanner@real-time.com>
	<200604271038.20357.tanner@real-time.com>
Message-ID: <ecfa260c0604272144r4e9644acs9722f38efbc302ac@mail.gmail.com>

On 4/27/06, Bob Tanner <tanner at real-time.com> wrote:
>
> Apache's mod_rewrite  does not help.
>
> The problem is we collapses multiple old vanilla-* lists into netrek-* lists,
> to combined the archives, I took the mbox files for the vanilla-* lists and
> and rebuild the netrek-* lists. Effectively changing the article IDs, we'll
> just have to wait for google to get the new info.

Ok. Thanks for looking into it.

Zach


From doconnor at gsoft.com.au  Thu Apr 27 19:49:56 2006
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri, 28 Apr 2006 10:19:56 +0930
Subject: [netrek-dev] online repository browsing
In-Reply-To: <20060427134942.GB9098@us.netrek.org>
References: <ecfa260c0604260451i40c18502y8b6419bd427c383b@mail.gmail.com>
	<ecfa260c0604260625j1015ca0ax182b6de5f0fd960@mail.gmail.com>
	<20060427134942.GB9098@us.netrek.org>
Message-ID: <200604281020.16446.doconnor@gsoft.com.au>

On Thursday 27 April 2006 23:19, James Cameron wrote:
> Well, if you need online repository browsing, set it up.  Let us know
> when you've got it running.
>
> I can't see the use myself.

I find web access to repos handy for looking up the occassional diff _even if_ 
I have a CVS repo handy.

Also web access to the repo allows you to send out commit messages with links 
to diffs rather than the diffs themselves :)

-- 
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/20060428/ea647981/attachment.pgp