From quozl at us.netrek.org  Wed Mar  1 01:07:41 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 1 Mar 2006 18:07:41 +1100
Subject: [netrek-dev] netrek-client-cow-3.2.0 released
Message-ID: <20060301070741.GA27434@us.netrek.org>

netrek-client-cow 3.2.0 was released today, containing the new multicast
server solicitation feature for LAN parties.  This is the first release
since 3.01pl0 on 22nd June 2002.

http://quozl.linux.org.au/netrek/
31dccb5ac01f163bec310e339a984ad8  netrek-client-cow-3.2.0.tar.gz

Summary of user changes:
- desktop icon name change [Tanner]
- multicast server discovery [Cameron]

Summary of technical changes:
- change source package name from COW to netrek-client-cow [Cameron]
- packaging for Debian and Ubuntu style distributions [Tanner]
- version number format change [Cameron]
- remove win32/libgmp.a binary file [Cameron]
- default to --enable-unstable on configure [Cameron]
- packet logging improvements [Villalpando]

-- 
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/20060301/3c24ba10/attachment.pgp

From basic at us.netrek.org  Wed Mar  1 01:17:06 2006
From: basic at us.netrek.org (Bob Tanner)
Date: Wed, 1 Mar 2006 01:17:06 -0600
Subject: [netrek-dev] netrek-client-cow-3.2.0 released
In-Reply-To: <20060301070741.GA27434@us.netrek.org>
References: <20060301070741.GA27434@us.netrek.org>
Message-ID: <200603010117.06589.basic@us.netrek.org>

On Wednesday 01 March 2006 01:07, James Cameron wrote:
> netrek-client-cow 3.2.0 was released today, containing the new multicast
> server solicitation feature for LAN parties. ?This is the first release
> since 3.01pl0 on 22nd June 2002.

Blessed sid binaries where release on 02/27/2006, see 
http://archives.us.netrek.org/pipermail/netrek-dev/2006-February/002846.html 
dtails.

Blessed etch binaries

Format: 1.7
Date: Mon, 27 Feb 2006 23:51:48 -0600
Source: netrek-client-cow
Binary: netrek-client-cow
Architecture: i386
Version: 3.2.0-1etch1
Distribution: testing
Urgency: low
Maintainer: Robert J. Tanner <tanner at real-time.com>
Changed-By: Robert J. Tanner <tanner at real-time.com>
Description:
 netrek-client-cow - netrek Client
Changes:
 netrek-client-cow (3.2.0-1etch1) testing; urgency=low
 .
   * Fix regression caused by previous change, resulting in bad file
     descriptor errors from select in ReadMetasRecv(). (Quozl)
   * Change to Quozl's new release numbering scheme, he is the official
     librarian you know. :-)
Files:
 d8f9d5ed57c95457014682571a49e13 240860 non-free/x11 optional 
etrek-client-cow_3.2.0-1etch1_i386.deb

Blessed sarge binaries:

Format: 1.7
Date: Mon, 27 Feb 2006 23:51:48 -0600
Source: netrek-client-cow
Binary: netrek-client-cow
Architecture: i386
Version: 3.2.0-1sarge1
Distribution: stable
Urgency: low
Maintainer: Robert J. Tanner <tanner at real-time.com>
Changed-By: Robert J. Tanner <tanner at real-time.com>
Description:
 netrek-client-cow - netrek Client
Changes:
 netrek-client-cow (3.2.0-1sarge1) stable; urgency=low
 .
   * Fix regression caused by previous change, resulting in bad file
     descriptor errors from select in ReadMetasRecv(). (Quozl)
   * Change to Quozl's new release numbering scheme, he is the official
     librarian you know. :-)
Files:
 0c9d35a5b40473617211a02f1ccee707 238988 non-free/x11 optional 
etrek-client-cow_3.2.0-1sarge1_i386.deb


-- 
Bob Tanner <basic at us.netrek.org>          
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/20060301/ca26d612/attachment.pgp

From basic at us.netrek.org  Sat Mar  4 11:55:23 2006
From: basic at us.netrek.org (Bob Tanner)
Date: Sat, 4 Mar 2006 11:55:23 -0600
Subject: [netrek-dev] Netrek Development Wiki
Message-ID: <200603041155.24279.basic@us.netrek.org>

Don't mean to steal Dave's thunder, but I had the time and need for a wiki, 
since I'm getting a high level of "HOWTO's" on building debian|ubuntu|mephis 
packages of cow, so

	 http://wiki.us.netrek.org/netrek-dev

We can transfer any data collected to Dave's wiki once it gets installed.


-- 
Bob Tanner <basic at us.netrek.org>          
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/20060304/28900998/attachment.pgp

From quozl at us.netrek.org  Sat Mar  4 17:34:12 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 5 Mar 2006 10:34:12 +1100
Subject: [netrek-dev] Netrek Development Wiki
In-Reply-To: <200603041155.24279.basic@us.netrek.org>
References: <200603041155.24279.basic@us.netrek.org>
Message-ID: <20060304233412.GA22287@us.netrek.org>

Link added to http://vanilla.netrek.org/ and http://netrek.org/

While we wait for the genocide content to come back, I'll take
contributions to netrek.org via darcs.  Instructions are on the page.

-- 
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/20060305/2270fbfd/attachment.pgp

From netrek at gmail.com  Mon Mar  6 22:39:58 2006
From: netrek at gmail.com (Zach)
Date: Mon, 6 Mar 2006 23:39:58 -0500
Subject: [netrek-dev] http interface to metaserver stats?
Message-ID: <ecfa260c0603062039n4b1b73d8wfab675910c5d6e73@mail.gmail.com>

I guess this issues is a result of the machine crash. Are there plans
to put this functionality back in place?

http://metaserver.us.netrek.org
>times out

http://metaserver2.us.netrek.org
>redirects to www.netrek.org

http://metaserver.netrek.org
>redirects to www.netrek.org

http://metaserver.eu.netrek.org
>redirects to www.netrek.org

Zach


From quozl at us.netrek.org  Tue Mar  7 06:03:33 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 7 Mar 2006 23:03:33 +1100
Subject: [netrek-dev] http interface to metaserver stats?
In-Reply-To: <ecfa260c0603062039n4b1b73d8wfab675910c5d6e73@mail.gmail.com>
References: <ecfa260c0603062039n4b1b73d8wfab675910c5d6e73@mail.gmail.com>
Message-ID: <20060307120333.GB10784@us.netrek.org>

On Mon, Mar 06, 2006 at 11:39:58PM -0500, Zach wrote:
> I guess this issues is a result of the machine crash. 

Nope.  It is mainly at your end.

> Are there plans to put this functionality back in place?

It's already there, and works fine, though a little monochrome.

> http://metaserver.us.netrek.org
> >times out

Incorrect URL, use http://metaserver.us.netrek.org:1080/

> http://metaserver2.us.netrek.org
> >redirects to www.netrek.org

Incorrect URL, use http://metaserver2.us.netrek.org:1080/

> http://metaserver.netrek.org
> >redirects to www.netrek.org

This is an alias for both servers.
Incorrect URL, use http://metaserver.netrek.org:1080/

> http://metaserver.eu.netrek.org
> >redirects to www.netrek.org

The European metaserver is no longer available, so this address
translates to one of the US metaservers.  And, incorrect URL, add :1080/
to the end.

If you want to remember the 1080 somehow, it's a fox poison we use on
our farm here.  Sodium fluoroacetate.  
http://en.wikipedia.org/wiki/1080_%28poison%29

I've applied a patch to the metaserver in CVS to:

- better form the HTML by including a <body> tag set,
- remove the link to the European metaserver,
- change title to Netrek Metaserver.

I'll take patches to improve the style of the output, such as the use of
embedded CSS or a CSS from www.netrek.org.  The world wide web has
adopted colour since I wrote the disp_web.c module.

I'd also like to consider having the output in XML with a stylesheet, so
that the www.netrek.org site could syndicate it.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060307/1c1c31dc/attachment.pgp

From carlos at brain.jpl.nasa.gov  Tue Mar  7 02:18:10 2006
From: carlos at brain.jpl.nasa.gov (Carlos Y. Villalpando)
Date: Tue, 7 Mar 2006 00:18:10 -0800
Subject: [netrek-dev] http interface to metaserver stats?
In-Reply-To: <ecfa260c0603062039n4b1b73d8wfab675910c5d6e73@mail.gmail.com>
References: <ecfa260c0603062039n4b1b73d8wfab675910c5d6e73@mail.gmail.com>
Message-ID: <20060307081810.GA28376@brain.jpl.nasa.gov>


Try http://metaserver.netrek.org:1080

--Carlos V.


From quozl at us.netrek.org  Thu Mar 30 00:26:32 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 30 Mar 2006 17:26:32 +1100
Subject: [netrek-dev] Netrek on a LinkSys WRT54G and Asustek WL-HDD using
	OpenWrt
Message-ID: <20060330062632.GA12524@us.netrek.org>

G'day,

I've ported version 2.10.2 of the Netrek Vanilla Server to run on the
Broadcom platform used by LinkSys WRT54G and clones, using the OpenWrt
build tools.  My prototype is running on an Asustek WL-HDD2.5, which is
a 802.11g wireless 2.5" IDE drive box with a 125MHz processor and 16MB
RAM.  It runs from 5V at 800mA.

It's really neat to play Netrek against a server small enough to sit in
the palm of your hand, at a price point comparable to a restaurant
drinks bill.

All the files are on http://quozl.linux.org.au/netrek/

- netrek-server-vanilla-2.10.2-openwrt-1.0-rc5.tar.gz is the binary
  tarball, for unpacking in /mnt/netrek-server-vanilla, then bin/netrekd
  is run to start the server,

- netrek-server-vanilla-2.10.2-openwrt-1.0-rc5.patch are the changes
  necessary to get the code to cross-compile on the OpenWrt 1.0 RC5
  build root,

- netrek-server-vanilla-2.10.2-openwrt-1.0-rc5.src.tar.gz is my work in
  progress source tree within the build root, for building an ipkg file
  which is the OpenWrt distribution format.


A few notes ...

1.  to avoid the need for X and curses, the xsg, pledit, and showgalaxy
    programs were omitted,

2.  to avoid the need for GDBM or GLIB, the player database is not
    indexed, PLAYER_INDEX is undefined,

3.  to avoid the need for libgmp, the res-rsa support was removed,
    though clearly this could be added back in later with more effort,

4.  the build was done with the assumption of some meaningful
    filesystem, which could be either NFS, USB, or local disk, according
    to the OpenWrt device in use,

5.  the new multicast server discovery protocol worked fine,

6.  load testing isn't complete, but in my first try there was no
    difficulty handling three or four clients and a few robots ... no
    reason why it cannot handle 16 clients, but I'll give that a more
    thorough try later,

7.  most of the porting effort was learning the build system and editing
    down the configure script to remove test programs ... when cross
    compiling configure cannot run a test program.

Comments welcome.

-- 
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/20060330/a80162f0/attachment.pgp 

From netrek at gmail.com  Thu Mar 30 00:33:28 2006
From: netrek at gmail.com (Zach)
Date: Thu, 30 Mar 2006 01:33:28 -0500
Subject: [netrek-dev] Netrek on a LinkSys WRT54G and Asustek WL-HDD
	using OpenWrt
In-Reply-To: <20060330062632.GA12524@us.netrek.org>
References: <20060330062632.GA12524@us.netrek.org>
Message-ID: <ecfa260c0603292233v17857400v6218a2f429876f4b@mail.gmail.com>

Cool. How well would this scale? I am thinkin of 8x8 game with 8 observer ports.

Zach

On 3/30/06, James Cameron <quozl at us.netrek.org> wrote:
> G'day,
>
> I've ported version 2.10.2 of the Netrek Vanilla Server to run on the
> Broadcom platform used by LinkSys WRT54G and clones, using the OpenWrt
> build tools.  My prototype is running on an Asustek WL-HDD2.5, which is
> a 802.11g wireless 2.5" IDE drive box with a 125MHz processor and 16MB
> RAM.  It runs from 5V at 800mA.
>
> It's really neat to play Netrek against a server small enough to sit in
> the palm of your hand, at a price point comparable to a restaurant
> drinks bill.
>
> All the files are on http://quozl.linux.org.au/netrek/
>
> - netrek-server-vanilla-2.10.2-openwrt-1.0-rc5.tar.gz is the binary
>   tarball, for unpacking in /mnt/netrek-server-vanilla, then bin/netrekd
>   is run to start the server,
>
> - netrek-server-vanilla-2.10.2-openwrt-1.0-rc5.patch are the changes
>   necessary to get the code to cross-compile on the OpenWrt 1.0 RC5
>   build root,
>
> - netrek-server-vanilla-2.10.2-openwrt-1.0-rc5.src.tar.gz is my work in
>   progress source tree within the build root, for building an ipkg file
>   which is the OpenWrt distribution format.
>
>
> A few notes ...
>
> 1.  to avoid the need for X and curses, the xsg, pledit, and showgalaxy
>     programs were omitted,
>
> 2.  to avoid the need for GDBM or GLIB, the player database is not
>     indexed, PLAYER_INDEX is undefined,
>
> 3.  to avoid the need for libgmp, the res-rsa support was removed,
>     though clearly this could be added back in later with more effort,
>
> 4.  the build was done with the assumption of some meaningful
>     filesystem, which could be either NFS, USB, or local disk, according
>     to the OpenWrt device in use,
>
> 5.  the new multicast server discovery protocol worked fine,
>
> 6.  load testing isn't complete, but in my first try there was no
>     difficulty handling three or four clients and a few robots ... no
>     reason why it cannot handle 16 clients, but I'll give that a more
>     thorough try later,
>
> 7.  most of the porting effort was learning the build system and editing
>     down the configure script to remove test programs ... when cross
>     compiling configure cannot run a test program.
>
> Comments welcome.
>
> --
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFEK3oYbmRwv64kZsARAo2mAKCQiry9ErAiQCicj7M3WzmniTpOzQCeNSpn
> TKX2QFyesr4uIA1PBwsfZ0c=
> =lAQe
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>
>


From quozl at us.netrek.org  Thu Mar 30 06:35:25 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 30 Mar 2006 23:35:25 +1100
Subject: [netrek-dev] Netrek on a LinkSys WRT54G and Asustek WL-HDD
	using OpenWrt
In-Reply-To: <ecfa260c0603292233v17857400v6218a2f429876f4b@mail.gmail.com>
References: <20060330062632.GA12524@us.netrek.org>
	<ecfa260c0603292233v17857400v6218a2f429876f4b@mail.gmail.com>
Message-ID: <20060330123525.GA14561@us.netrek.org>

An 8x8 game at ten updates per second was close to the maximum
capability of the CPU.  The limiting factor appeared to be the delivery
of the packets through the wireless driver.  I'll give it another try
using the wired NIC.  There was no evidence of memory limitation, with
all 18 processes active there was still a reasonable amount of free
memory from the 16MB.

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


From bogus@does.not.exist.com  Tue Mar 28 10:56:58 2006
From: bogus@does.not.exist.com ()
Date: Tue, 28 Mar 2006 16:56:58 -0000
Subject: No subject
Message-ID: <mailman.224.1145974010.5488.netrek-dev@us.netrek.org>

+	* 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'm curious as to how the ban would effect players with static IPs vs.
those with dynamic IPs (like AOL users and other popular IPs like
rogers.com).  Would it allow an AOL user who gets banned to simply
reconnect to AOL, get their new random IP, and then reconnect to the
server?  Or would it ban all *AOL.com users?

Second, the legnth and determination of the ban.  I have a feeling 100
unique logins would take an awful long time, on the order of several days.
Is this an appropriate power to give the players, ban someone for several
days?  If anyone thinks this won't be abused like eject is currently
abused, they are kidding themselves.

Lastly, as to determination of ban length, the only way to check is to
login at a time you "guess" the ban has expired.  But if you guess wrong,
the ban is increased.  How is that fair to the player exactly?  The length
of ban should be static so they know when they can log in again without
meriting further automatic punishment from the server.

Bill