From msucka0xff at programmer.net  Mon May  1 15:54:31 2006
From: msucka0xff at programmer.net (. .)
Date: Mon, 01 May 2006 12:54:31 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>

Hey Joe,

Can you please explain what its purpose is, what this does in some more detail, why anyone would want to use it, and how it works? Documentation tends to be notoriously bad in Netrek -- almost like a sore thumb or a poke in the eye with a sharp stick.

Thanks,
-bd

>Source code is available at:
>
>http://www.playnetrek.org/netrek-config-source.html
>
>Written in VB and there is plenty of room for improvement if you have the
>time.  Also feel free to use the code to create a config utility for another
>OS.  The logic for the keymap config took some time to put together,
>shouldn't be too hard to transfer the code to a different compiler for use
>on a different OS.  Hopefully can save someone some time.
>
>Link to this page is only available from the links section of
>playnetrek.org.  I am told this code will also be placed in the CVS
>repository.
>
>-Joe 

-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From tanner at real-time.com  Mon May  1 16:06:35 2006
From: tanner at real-time.com (Bob Tanner)
Date: Mon, 1 May 2006 16:06:35 -0500
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>
References: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>
Message-ID: <200605011606.35872.tanner@real-time.com>

On Monday 01 May 2006 15:54, . . wrote:
> Can you please explain what its purpose is, what this does in some more
> detail, why anyone would want to use it, and how it works? Documentation
> tends to be notoriously bad in Netrek -- almost like a sore thumb or a poke
> in the eye with a sharp stick.

I don't mean this to be flame-bait, but it will sound that way....

The documentation is the code.  With that said, I agree the documentation is 
poor for Netrek, but if I had to pick, I'd rather have people writing code, 
then writing documentation.

A smaller FOSS projects like netrek do not (usually) get the luxury of having 
both.

My recommendation, see if you can get the author in irc and talk with him and 
write the documentation yourself. Why? Most devs, like myself, would write 
techno-babble documention which the end user wouldn't find all the useful 
anyways. :-)

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint -------------- 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/20060501/0f7317c5/attachment.pgp 

From msucka0xff at programmer.net  Mon May  1 17:11:21 2006
From: msucka0xff at programmer.net (. .)
Date: Mon, 01 May 2006 14:11:21 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060501221121.C36D016427A@ws1-4.us4.outblaze.com>

Hey Bob,

I didn't insult Joe's Mom, but I don't agree that code is documentation or vice versa. However, when I see either of you on continuum, I plan to insult your mother.

-bd


> ----- Original Message -----
> From: "Bob Tanner" <tanner at real-time.com>
> To: "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Mon, 1 May 2006 16:06:35 -0500
> 
> 
> On Monday 01 May 2006 15:54, . . wrote:
> > Can you please explain what its purpose is, what this does in some more
> > detail, why anyone would want to use it, and how it works? Documentation
> > tends to be notoriously bad in Netrek -- almost like a sore thumb or a poke
> > in the eye with a sharp stick.
> 
> I don't mean this to be flame-bait, but it will sound that way....
> 
> The documentation is the code.  With that said, I agree the documentation is
> poor for Netrek, but if I had to pick, I'd rather have people writing code,
> then writing documentation.
> 
> A smaller FOSS projects like netrek do not (usually) get the luxury of having
> both.
> 
> My recommendation, see if you can get the author in irc and talk with him and
> write the documentation yourself. Why? Most devs, like myself, would write
> techno-babble documention which the end user wouldn't find all the useful
> anyways. :-)
> 
> --
> 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
> << 1.2.dat >>
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev

>


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From msucka0xff at programmer.net  Mon May  1 18:29:00 2006
From: msucka0xff at programmer.net (. .)
Date: Mon, 01 May 2006 15:29:00 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060501232900.13224115811@ws1-7.us4.outblaze.com>

Folks,

I'm putting an edge to this, but not meaning anything personal. Accept my appologies if you felt offended.

-bd


> ----- Original Message -----
> From: ". ." <msucka0xff at programmer.net>
> To: tanner at real-time.com, "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Mon, 01 May 2006 14:11:21 -0800
> 
> 
> Hey Bob,
> 
> I didn't insult Joe's Mom, but I don't agree that code is 
> documentation or vice versa. However, when I see either of you on 
> continuum, I plan to insult your mother.
> 
> -bd
> 
> 
> > ----- Original Message -----
> > From: "Bob Tanner" <tanner at real-time.com>
> > To: "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> > Subject: Re: [netrek-dev] Netrek config utility source code
> > Date: Mon, 1 May 2006 16:06:35 -0500
> >
> >
> > On Monday 01 May 2006 15:54, . . wrote:
> > > Can you please explain what its purpose is, what this does in some more
> > > detail, why anyone would want to use it, and how it works? Documentation
> > > tends to be notoriously bad in Netrek -- almost like a sore thumb or a poke
> > > in the eye with a sharp stick.
> >
> > I don't mean this to be flame-bait, but it will sound that way....
> >
> > The documentation is the code.  With that said, I agree the documentation is
> > poor for Netrek, but if I had to pick, I'd rather have people writing code,
> > then writing documentation.
> >
> > A smaller FOSS projects like netrek do not (usually) get the luxury of having
> > both.
> >
> > My recommendation, see if you can get the author in irc and talk with him and
> > write the documentation yourself. Why? Most devs, like myself, would write
> > techno-babble documention which the end user wouldn't find all the useful
> > anyways. :-)
> >
> > --
> > 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
> > << 1.2.dat >>
> >
> > _______________________________________________
> > netrek-dev mailing list
> > netrek-dev at us.netrek.org
> > http://mailman.us.netrek.org/listinfo/netrek-dev
> 
> >
> 
> 
> --
> ___________________________________________________
> Play 100s of games for FREE! http://games.mail.com/
> 
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev

>


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From netrek at gmail.com  Mon May  1 18:35:17 2006
From: netrek at gmail.com (Zach)
Date: Mon, 1 May 2006 19:35:17 -0400
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060501232900.13224115811@ws1-7.us4.outblaze.com>
References: <20060501232900.13224115811@ws1-7.us4.outblaze.com>
Message-ID: <ecfa260c0605011635m1d65af53x3ca2c47293f971fe@mail.gmail.com>

Read this for a good laugh:
http://observer.guardian.co.uk/business/story/0,,1759298,00.html

Zach

On 5/1/06, . . <msucka0xff at programmer.net> wrote:
> Folks,
>
> I'm putting an edge to this, but not meaning anything personal. Accept my appologies if you felt offended.
>
> -bd


From mark at mark.mielke.cc  Mon May  1 18:19:16 2006
From: mark at mark.mielke.cc (mark at mark.mielke.cc)
Date: Mon, 1 May 2006 19:19:16 -0400
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060501221121.C36D016427A@ws1-4.us4.outblaze.com>
References: <20060501221121.C36D016427A@ws1-4.us4.outblaze.com>
Message-ID: <20060501231916.GA2350@mark.mielke.cc>

On Mon, May 01, 2006 at 02:11:21PM -0800, . . wrote:
> I didn't insult Joe's Mom, but I don't agree that code is
> documentation or vice versa. However, when I see either of you on
> continuum, I plan to insult your mother.

Good code is good documentation, for good code readers. Especially
code that will change, as people seem to have difficulty updating the
comments to reflect the code changes. It's no good at all to have a
barely accurate or useful comment, possibly mis-describing the very
accurate code. I find that unless the code is impossible to read
(yuck), I'll read the code first, and only if I have questions, will I
read the comments, to try to understand what in the heck the author
was thinking when he wrote it.

As to which of the three (more than one?) are lacking - I'll leave you
to decide. :-)

More seriously -

The netrek code of 10+ years ago - when I actually wrote additional
code for it client-side and server-side, was quite poor. Obviously
the work of a few University grads in their spare time. I found it
really hard to follow.

The last time I looked at it - porting some of my changes back up to a
more recent version, there was a great deal of improvement that I
immediately noticed. I think this included ANSI-C, a re-written
network/packet layer, and some nicer simplification in the daemon.
I'd say this switched it from poor to average or better quality.

I haven't looked recently to offer my condescending judgement for
2006... :-)

Cheers,
mark


> > ----- Original Message -----
> > From: "Bob Tanner" <tanner at real-time.com>
> > To: "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> > Subject: Re: [netrek-dev] Netrek config utility source code
> > Date: Mon, 1 May 2006 16:06:35 -0500
> > 
> > 
> > On Monday 01 May 2006 15:54, . . wrote:
> > > Can you please explain what its purpose is, what this does in some more
> > > detail, why anyone would want to use it, and how it works? Documentation
> > > tends to be notoriously bad in Netrek -- almost like a sore thumb or a poke
> > > in the eye with a sharp stick.
> > 
> > I don't mean this to be flame-bait, but it will sound that way....
> > 
> > The documentation is the code.  With that said, I agree the documentation is
> > poor for Netrek, but if I had to pick, I'd rather have people writing code,
> > then writing documentation.
> > 
> > A smaller FOSS projects like netrek do not (usually) get the luxury of having
> > both.
> > 
> > My recommendation, see if you can get the author in irc and talk with him and
> > write the documentation yourself. Why? Most devs, like myself, would write
> > techno-babble documention which the end user wouldn't find all the useful
> > anyways. :-)
> > 
> > --
> > 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
> > << 1.2.dat >>
> > 
> > _______________________________________________
> > netrek-dev mailing list
> > netrek-dev at us.netrek.org
> > http://mailman.us.netrek.org/listinfo/netrek-dev
> 
> >
> 
> 
> -- 
> ___________________________________________________
> Play 100s of games for FREE! http://games.mail.com/
> 
> 
> _______________________________________________
> 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 stephen.thorne at gmail.com  Mon May  1 21:20:36 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 2 May 2006 12:20:36 +1000
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060501231916.GA2350@mark.mielke.cc>
References: <20060501221121.C36D016427A@ws1-4.us4.outblaze.com>
	<20060501231916.GA2350@mark.mielke.cc>
Message-ID: <3e8ca5c80605011920v4b035033vcbdc9b1eea39a56a@mail.gmail.com>

On 5/2/06, mark at mark.mielke.cc <mark at mark.mielke.cc> wrote:
> I haven't looked recently to offer my condescending judgement for
> 2006... :-)

NetrekXP development has been going at a mile a minute, and Vanilla
has been granted new features lately, including automatic LAN server
discovery and new effects when one side wins.

When you have time to look and make comments, remember, patches accepted.
--
Stephen Thorne
Development Engineer


From netrek at gmail.com  Tue May  2 14:18:44 2006
From: netrek at gmail.com (Zach)
Date: Tue, 2 May 2006 15:18:44 -0400
Subject: [netrek-dev] email for Stas?
Message-ID: <ecfa260c0605021218l3ed9fd1eu40d23cee872ec5e0@mail.gmail.com>

I am trying to contact Stas but his email is failing:

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

    keyos at keyos.org

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 8): 550 5.7.1 Rejected: 64.233.182.185
listed at bl1.netvision.net.il


Zach


From tanner at real-time.com  Wed May  3 13:31:01 2006
From: tanner at real-time.com (Bob Tanner)
Date: Wed, 03 May 2006 13:31:01 -0500
Subject: [netrek-dev] Netrek config utility source code
References: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>
Message-ID: <e3ast5$v4a$1@sea.gmane.org>

>>Written in VB and there is plenty of room for improvement if you have the
>>time.  

I do wish it was developed in a language that at least has a shot of being
ported to a different operating system. :-(

Yes, we can follow the login in VB, but then we have to maintain 2
code-bases, 2 patches, 2 testsuites, 2 installations documents, 2 HOWTOs,
etc...


-- 
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 netrek at gmail.com  Wed May  3 15:06:20 2006
From: netrek at gmail.com (Zach)
Date: Wed, 3 May 2006 16:06:20 -0400
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <e3ast5$v4a$1@sea.gmane.org>
References: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>
	<e3ast5$v4a$1@sea.gmane.org>
Message-ID: <ecfa260c0605031306u2a537f68sf9c6ecf00c580aff@mail.gmail.com>

Java would be ideal language for such a task. You can run the utility
as a web app or standalone on the host machine. Will only have minimal
effort to run it on a wide variety of platforms.

Zach

On 5/3/06, Bob Tanner <tanner at real-time.com> wrote:
> >>Written in VB and there is plenty of room for improvement if you have the
> >>time.
>
> I do wish it was developed in a language that at least has a shot of being
> ported to a different operating system. :-(
>
> Yes, we can follow the login in VB, but then we have to maintain 2
> code-bases, 2 patches, 2 testsuites, 2 installations documents, 2 HOWTOs,
> etc...
>
>
> --
> 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
>
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>


From msucka0xff at programmer.net  Wed May  3 17:48:17 2006
From: msucka0xff at programmer.net (. .)
Date: Wed, 03 May 2006 14:48:17 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060503224817.6A776101DA@ws1-3.us4.outblaze.com>

having worked with java in the past, it is very unwieldly as a tool and a royal pain. i wouldn't recommend that as a development base for this app (or any for that matter). probably ANSI or clean C would be my recommendation -- along with adequate documentation ;-). at some point this code can be integrated directly into the client as a library and invoked via command line switch "--check-config" or something. apache httpd has a similar command line to validate the syntax of the config file.



> ----- Original Message -----
> From: Zach <netrek at gmail.com>
> To: tanner at real-time.com, "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Wed, 3 May 2006 16:06:20 -0400
> 
> 
> Java would be ideal language for such a task. You can run the utility
> as a web app or standalone on the host machine. Will only have minimal
> effort to run it on a wide variety of platforms.
> 
> Zach
> 
> On 5/3/06, Bob Tanner <tanner at real-time.com> wrote:
> > >>Written in VB and there is plenty of room for improvement if you have the
> > >>time.
> >
> > I do wish it was developed in a language that at least has a shot of being
> > ported to a different operating system. :-(
> >
> > Yes, we can follow the login in VB, but then we have to maintain 2
> > code-bases, 2 patches, 2 testsuites, 2 installations documents, 2 HOWTOs,
> > etc...
> >
> >
> > --
> > 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


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From stephen.thorne at gmail.com  Wed May  3 17:56:04 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 4 May 2006 08:56:04 +1000
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <ecfa260c0605031306u2a537f68sf9c6ecf00c580aff@mail.gmail.com>
References: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>
	<e3ast5$v4a$1@sea.gmane.org>
	<ecfa260c0605031306u2a537f68sf9c6ecf00c580aff@mail.gmail.com>
Message-ID: <3e8ca5c80605031556w28f667e1k6ebac427ba534904@mail.gmail.com>

On 5/4/06, Zach <netrek at gmail.com> wrote:
> Java would be ideal language for such a task. You can run the utility
> as a web app or standalone on the host machine. Will only have minimal
> effort to run it on a wide variety of platforms.

Java is far from ideal. It's a language that's not shipped with debian
OR redhat linux.
--
Stephen Thorne
Development Engineer


From darius at dons.net.au  Wed May  3 18:12:29 2006
From: darius at dons.net.au (Daniel O'Connor)
Date: Thu, 4 May 2006 08:42:29 +0930
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060503224817.6A776101DA@ws1-3.us4.outblaze.com>
References: <20060503224817.6A776101DA@ws1-3.us4.outblaze.com>
Message-ID: <200605040842.39448.darius@dons.net.au>

On Thursday 04 May 2006 08:18, . . wrote:
> having worked with java in the past, it is very unwieldly as a tool and a
> royal pain. i wouldn't recommend that as a development base for this app
> (or any for that matter). probably ANSI or clean C would be my
> recommendation -- along with adequate documentation ;-). at some point this
> code can be integrated directly into the client as a library and invoked
> via command line switch "--check-config" or something. apache httpd has a
> similar command line to validate the syntax of the config file.

Bleh, use something like Tcl/Tk, Python or Ruby.

All are cross platform and much more suited to such a task IMO.

> > ----- Original Message -----
> > From: Zach <netrek at gmail.com>
> > To: tanner at real-time.com, "Netrek Development Mailing List"
> > <netrek-dev at us.netrek.org> Subject: Re: [netrek-dev] Netrek config
> > utility source code
> > Date: Wed, 3 May 2006 16:06:20 -0400
> >
> >
> > Java would be ideal language for such a task. You can run the utility
> > as a web app or standalone on the host machine. Will only have minimal
> > effort to run it on a wide variety of platforms.
> >
> > Zach
> >
> > On 5/3/06, Bob Tanner <tanner at real-time.com> wrote:
> > > >>Written in VB and there is plenty of room for improvement if you have
> > > >> the time.
> > >
> > > I do wish it was developed in a language that at least has a shot of
> > > being ported to a different operating system. :-(
> > >
> > > Yes, we can follow the login in VB, but then we have to maintain 2
> > > code-bases, 2 patches, 2 testsuites, 2 installations documents, 2
> > > HOWTOs, etc...
> > >
> > >
> > > --
> > > Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
> > > http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
> > > Key fingerprint 
-- 
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/20060504/becdde02/attachment.pgp 

From msucka0xff at programmer.net  Wed May  3 18:21:52 2006
From: msucka0xff at programmer.net (. .)
Date: Wed, 03 May 2006 15:21:52 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060503232152.B65058402F@ws1-5.us4.outblaze.com>

I think that Microsoft Windows requires different code from Linux, and users tend not to have python, ruby, or perl interpreters installed on their OS. That's why I would not want it in these languages.


> ----- Original Message -----
> From: "Daniel O'Connor" <darius at dons.net.au>
> To: netrek-dev at us.netrek.org
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Thu, 4 May 2006 08:42:29 +0930
> 
> 
> On Thursday 04 May 2006 08:18, . . wrote:
> > having worked with java in the past, it is very unwieldly as a tool and a
> > royal pain. i wouldn't recommend that as a development base for this app
> > (or any for that matter). probably ANSI or clean C would be my
> > recommendation -- along with adequate documentation ;-). at some point this
> > code can be integrated directly into the client as a library and invoked
> > via command line switch "--check-config" or something. apache httpd has a
> > similar command line to validate the syntax of the config file.
> 
> Bleh, use something like Tcl/Tk, Python or Ruby.
> 
> All are cross platform and much more suited to such a task IMO.
> 
> > > ----- Original Message -----
> > > From: Zach <netrek at gmail.com>
> > > To: tanner at real-time.com, "Netrek Development Mailing List"
> > > <netrek-dev at us.netrek.org> Subject: Re: [netrek-dev] Netrek config
> > > utility source code
> > > Date: Wed, 3 May 2006 16:06:20 -0400
> > >
> > >
> > > Java would be ideal language for such a task. You can run the utility
> > > as a web app or standalone on the host machine. Will only have minimal
> > > effort to run it on a wide variety of platforms.
> > >
> > > Zach
> > >
> > > On 5/3/06, Bob Tanner <tanner at real-time.com> wrote:
> > > > >>Written in VB and there is plenty of room for improvement if you have
> > > > >> the time.
> > > >
> > > > I do wish it was developed in a language that at least has a shot of
> > > > being ported to a different operating system. :-(
> > > >
> > > > Yes, we can follow the login in VB, but then we have to maintain 2
> > > > code-bases, 2 patches, 2 testsuites, 2 installations documents, 2
> > > > HOWTOs, etc...
> > > >
> > > >
> > > > --
> > > > 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
> 
> --
> 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
> << 2.dat >>

>


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From ahn at orion.netrek.org  Wed May  3 20:07:09 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Wed, 3 May 2006 21:07:09 -0400
Subject: [netrek-dev] ftp.netrek.org & Vanilla releases
In-Reply-To: <20060426131504.GB29562@us.netrek.org>
References: <ecfa260c0604260432g2bc12926lefb66d1d468d5d71@mail.gmail.com>
	<20060426131504.GB29562@us.netrek.org>
Message-ID: <20060504010709.GB12548@orion.netrek.org>

On Wed, Apr 26, 2006 at 11:15:04PM +1000, James Cameron wrote:
> ftp.netrek.org is not currently maintained.

Actually, I am looking for a volunteer who will take over the
administration of the Netrek Software Archive.  This volunteer would
coordinate and/or place new releases of Netrek source and binaries in
the Netrek Software Archive.  Interested parties should contact me
directly at ahn AT romulus.netrek.org.  Thanks.

Dave


From darius at dons.net.au  Wed May  3 20:10:59 2006
From: darius at dons.net.au (Daniel O'Connor)
Date: Thu, 4 May 2006 10:40:59 +0930
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060503232152.B65058402F@ws1-5.us4.outblaze.com>
References: <20060503232152.B65058402F@ws1-5.us4.outblaze.com>
Message-ID: <200605041041.13405.darius@dons.net.au>

On Thursday 04 May 2006 08:51, . . wrote:
> I think that Microsoft Windows requires different code from Linux, and
> users tend not to have python, ruby, or perl interpreters installed on
> their OS. That's why I would not want it in these languages.

<shrugs>
All of those languages are trivial to install, they're all smaller installs 
than Java, although as you point out Java is most likely to be installed on 
an end user's PC.

In all cases the code is the same between Windows & Unix-like platforms 
(unless you try hard to make it not so)

Since I am not writing it I couldn't object too strongly, but Java is a bit on 
the heavy side IMO :)

> > ----- Original Message -----
> > From: "Daniel O'Connor" <darius at dons.net.au>
> > To: netrek-dev at us.netrek.org
> > Subject: Re: [netrek-dev] Netrek config utility source code
> > Date: Thu, 4 May 2006 08:42:29 +0930
> >
> > On Thursday 04 May 2006 08:18, . . wrote:
> > > having worked with java in the past, it is very unwieldly as a tool and
> > > a royal pain. i wouldn't recommend that as a development base for this
> > > app (or any for that matter). probably ANSI or clean C would be my
> > > recommendation -- along with adequate documentation ;-). at some point
> > > this code can be integrated directly into the client as a library and
> > > invoked via command line switch "--check-config" or something. apache
> > > httpd has a similar command line to validate the syntax of the config
> > > file.
> >
> > Bleh, use something like Tcl/Tk, Python or Ruby.
> >
> > All are cross platform and much more suited to such a task IMO.
> >
> > > > ----- Original Message -----
> > > > From: Zach <netrek at gmail.com>
> > > > To: tanner at real-time.com, "Netrek Development Mailing List"
> > > > <netrek-dev at us.netrek.org> Subject: Re: [netrek-dev] Netrek config
> > > > utility source code
> > > > Date: Wed, 3 May 2006 16:06:20 -0400
> > > >
> > > >
> > > > Java would be ideal language for such a task. You can run the utility
> > > > as a web app or standalone on the host machine. Will only have
> > > > minimal effort to run it on a wide variety of platforms.
> > > >
> > > > Zach
> > > >
> > > > On 5/3/06, Bob Tanner <tanner at real-time.com> wrote:
> > > > > >>Written in VB and there is plenty of room for improvement if you
> > > > > >> have the time.
> > > > >
> > > > > I do wish it was developed in a language that at least has a shot
> > > > > of being ported to a different operating system. :-(
> > > > >
> > > > > Yes, we can follow the login in VB, but then we have to maintain 2
> > > > > code-bases, 2 patches, 2 testsuites, 2 installations documents, 2
> > > > > HOWTOs, etc...
> > > > >
> > > > >
> > > > > --
> > > > > Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
> > > > > http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
> > > > > Key fingerprint > > > > > B288
> >
> > --
> > 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
> > << 2.dat >>

-- 
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/20060504/3c7de37f/attachment.pgp 

From msucka0xff at programmer.net  Wed May  3 20:18:05 2006
From: msucka0xff at programmer.net (. .)
Date: Wed, 03 May 2006 17:18:05 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060504011805.1DC43115812@ws1-7.us4.outblaze.com>

OK, I am ready to distribute the tally:

For Java:     1 
Against Java: 3

Total : 4

Lines of code written : 0.

Ah, good day's work, time to go home.
-bd


> ----- Original Message -----
> From: "Daniel O'Connor" <darius at dons.net.au>
> To: ". ." <msucka0xff at programmer.net>
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Thu, 4 May 2006 10:40:59 +0930
> 
> 
> On Thursday 04 May 2006 08:51, . . wrote:
> > I think that Microsoft Windows requires different code from Linux, and
> > users tend not to have python, ruby, or perl interpreters installed on
> > their OS. That's why I would not want it in these languages.
> 
> <shrugs>
> All of those languages are trivial to install, they're all smaller installs
> than Java, although as you point out Java is most likely to be installed on
> an end user's PC.
> 
> In all cases the code is the same between Windows & Unix-like platforms
> (unless you try hard to make it not so)
> 
> Since I am not writing it I couldn't object too strongly, but Java is a bit on
> the heavy side IMO :)
> 
> > > ----- Original Message -----
> > > From: "Daniel O'Connor" <darius at dons.net.au>
> > > To: netrek-dev at us.netrek.org
> > > Subject: Re: [netrek-dev] Netrek config utility source code
> > > Date: Thu, 4 May 2006 08:42:29 +0930
> > >
> > > On Thursday 04 May 2006 08:18, . . wrote:
> > > > having worked with java in the past, it is very unwieldly as a tool and
> > > > a royal pain. i wouldn't recommend that as a development base for this
> > > > app (or any for that matter). probably ANSI or clean C would be my
> > > > recommendation -- along with adequate documentation ;-). at some point
> > > > this code can be integrated directly into the client as a library and
> > > > invoked via command line switch "--check-config" or something. apache
> > > > httpd has a similar command line to validate the syntax of the config
> > > > file.
> > >
> > > Bleh, use something like Tcl/Tk, Python or Ruby.
> > >
> > > All are cross platform and much more suited to such a task IMO.
> > >
> > > > > ----- Original Message -----
> > > > > From: Zach <netrek at gmail.com>
> > > > > To: tanner at real-time.com, "Netrek Development Mailing List"
> > > > > <netrek-dev at us.netrek.org> Subject: Re: [netrek-dev] Netrek config
> > > > > utility source code
> > > > > Date: Wed, 3 May 2006 16:06:20 -0400
> > > > >
> > > > >
> > > > > Java would be ideal language for such a task. You can run the utility
> > > > > as a web app or standalone on the host machine. Will only have
> > > > > minimal effort to run it on a wide variety of platforms.
> > > > >
> > > > > Zach
> > > > >
> > > > > On 5/3/06, Bob Tanner <tanner at real-time.com> wrote:
> > > > > > >>Written in VB and there is plenty of room for improvement if you
> > > > > > >> have the time.
> > > > > >
> > > > > > I do wish it was developed in a language that at least has a shot
> > > > > > of being ported to a different operating system. :-(
> > > > > >
> > > > > > Yes, we can follow the login in VB, but then we have to maintain 2
> > > > > > code-bases, 2 patches, 2 testsuites, 2 installations documents, 2
> > > > > > HOWTOs, etc...
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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
> > >
> > > --
> > > 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
> > > << 2.dat >>
> 
> --
> 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
> << 2.dat >>

>


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From ahn at orion.netrek.org  Thu May  4 00:07:11 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 4 May 2006 01:07:11 -0400
Subject: [netrek-dev] www.netrek.org/stats/ back up
Message-ID: <20060504050711.GA13711@orion.netrek.org>

The Netrek Game Stats Archive should be back up now.  Please let me know
if there are any problems.  http://www.netrek.org/stats/

Dave


From mark at mark.mielke.cc  Wed May  3 18:02:03 2006
From: mark at mark.mielke.cc (mark at mark.mielke.cc)
Date: Wed, 3 May 2006 19:02:03 -0400
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <3e8ca5c80605031556w28f667e1k6ebac427ba534904@mail.gmail.com>
References: <20060501205433.942D51CE317@ws1-6.us4.outblaze.com>
	<e3ast5$v4a$1@sea.gmane.org>
	<ecfa260c0605031306u2a537f68sf9c6ecf00c580aff@mail.gmail.com>
	<3e8ca5c80605031556w28f667e1k6ebac427ba534904@mail.gmail.com>
Message-ID: <20060503230203.GA14069@mark.mielke.cc>

On Thu, May 04, 2006 at 08:56:04AM +1000, Stephen Thorne wrote:
> On 5/4/06, Zach <netrek at gmail.com> wrote:
> > Java would be ideal language for such a task. You can run the utility
> > as a web app or standalone on the host machine. Will only have minimal
> > effort to run it on a wide variety of platforms.
> Java is far from ideal. It's a language that's not shipped with debian
> OR redhat linux.

Perhaps you are not considering gcj? :-)

Eclipse works with gcj in Fedora Core 4 and 5.

Java is quite ideal, and preferable to VB. Although, with Mono, there is
a chance that VB code may run on Linux.

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  Wed May  3 18:04:15 2006
From: mark at mark.mielke.cc (mark at mark.mielke.cc)
Date: Wed, 3 May 2006 19:04:15 -0400
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060503224817.6A776101DA@ws1-3.us4.outblaze.com>
References: <20060503224817.6A776101DA@ws1-3.us4.outblaze.com>
Message-ID: <20060503230415.GB14069@mark.mielke.cc>

On Wed, May 03, 2006 at 02:48:17PM -0800, . . wrote:
> having worked with java in the past, it is very unwieldly as a tool
> and a royal pain. i wouldn't recommend that as a development base
> for this app (or any for that matter). probably ANSI or clean C
> would be my recommendation -- along with adequate documentation
> ;-). at some point this code can be integrated directly into the
> client as a library and invoked via command line switch
> "--check-config" or something. apache httpd has a similar command
> line to validate the syntax of the config file.

If you prefer C over Java for simple tasks such as a config utility,
that include a GUI...

Something is wrong. :-)

If anything, the main complaint against Java is that it is *too* easy,
and therefore limiting. People who claim C++ is better than Java, are
quick to point out that Java is a *subset* of C++. The GCC pretty
much proved this, with their C++/Java compiler that can call back and
forth between the two.

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 msucka0xff at programmer.net  Thu May  4 15:07:53 2006
From: msucka0xff at programmer.net (. .)
Date: Thu, 04 May 2006 12:07:53 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060504200753.547E483BFF@ws1-1.us4.outblaze.com>

I still don't know what this thing is. I refuse to look at the VB code. Joe will not say. 

> ----- Original Message -----
> From: mark at mark.mielke.cc
> To: "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Wed, 3 May 2006 19:04:15 -0400
> 
> 
> On Wed, May 03, 2006 at 02:48:17PM -0800, . . wrote:
> > having worked with java in the past, it is very unwieldly as a tool
> > and a royal pain. i wouldn't recommend that as a development base
> > for this app (or any for that matter). probably ANSI or clean C
> > would be my recommendation -- along with adequate documentation
> > ;-). at some point this code can be integrated directly into the
> > client as a library and invoked via command line switch
> > "--check-config" or something. apache httpd has a similar command
> > line to validate the syntax of the config file.
> 
> If you prefer C over Java for simple tasks such as a config utility,
> that include a GUI...
> 
> Something is wrong. :-)
> 
> If anything, the main complaint against Java is that it is *too* easy,
> and therefore limiting. People who claim C++ is better than Java, are
> quick to point out that Java is a *subset* of C++. The GCC pretty
> much proved this, with their C++/Java compiler that can call back and
> forth between the two.
> 
> 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/
> 
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev

>


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From tanner at real-time.com  Thu May  4 15:37:14 2006
From: tanner at real-time.com (Bob Tanner)
Date: Thu, 4 May 2006 15:37:14 -0500
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060504200753.547E483BFF@ws1-1.us4.outblaze.com>
References: <20060504200753.547E483BFF@ws1-1.us4.outblaze.com>
Message-ID: <200605041537.14701.tanner@real-time.com>

On Thursday 04 May 2006 15:07, . . wrote:
> I still don't know what this thing is. I refuse to look at the VB code. Joe
> will not say.

Refuse?

Joe has given you the freedom to look at his code and you won't look at it? 
Where would the open source movement be if we all acted like you?

No look, no complain.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint -------------- 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/20060504/b6441403/attachment.pgp 

From msucka0xff at programmer.net  Thu May  4 15:56:44 2006
From: msucka0xff at programmer.net (. .)
Date: Thu, 04 May 2006 12:56:44 -0800
Subject: [netrek-dev] Netrek config utility source code
Message-ID: <20060504205644.9080883BFF@ws1-1.us4.outblaze.com>

I don't have a computer with windows installed, so it won't make any sense.

> ----- Original Message -----
> From: "Bob Tanner" <tanner at real-time.com>
> To: "Netrek Development Mailing List" <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek config utility source code
> Date: Thu, 4 May 2006 15:37:14 -0500
> 
> 
> On Thursday 04 May 2006 15:07, . . wrote:
> > I still don't know what this thing is. I refuse to look at the VB code. Joe
> > will not say.
> 
> Refuse?
> 
> Joe has given you the freedom to look at his code and you won't look at it?
> Where would the open source movement be if we all acted like you?
> 
> No look, no complain.
> 
> --
> 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
> << 1.2.dat >>
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev

>


-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/



From tanner at real-time.com  Thu May  4 16:37:35 2006
From: tanner at real-time.com (Bob Tanner)
Date: Thu, 4 May 2006 16:37:35 -0500
Subject: [netrek-dev] Netrek config utility source code
In-Reply-To: <20060504205644.9080883BFF@ws1-1.us4.outblaze.com>
References: <20060504205644.9080883BFF@ws1-1.us4.outblaze.com>
Message-ID: <200605041637.36554.tanner@real-time.com>

On Thursday 04 May 2006 15:56, you wrote:
> I don't have a computer with windows installed, so it won't make any sense.

It's a text file and unless you run a PDP-11 and punch-cards you could be able 
to read it.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint -------------- 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/20060504/62895672/attachment.pgp 

From ahn at orion.netrek.org  Thu May  4 16:47:25 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 4 May 2006 17:47:25 -0400
Subject: [netrek-dev] SourceForge changes
Message-ID: <20060504214725.GA24794@orion.netrek.org>

I've updated the SourceForge project settings for Netrek to remove
features (Task Manager, etc) that aren't being used as well as some
other maintenace changes.  Please let me or any of the Netrek SF
administrators know if there are any problems.

Dave



From ahn at orion.netrek.org  Thu May  4 17:29:52 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 4 May 2006 18:29:52 -0400
Subject: [netrek-dev] Mailing lists consolidation
Message-ID: <20060504222952.GA24986@orion.netrek.org>

Hello folks,

Some updates regarding mailing lists.

Bob has graciously agreed to take over lists.netrek.org, the now-defunct
list server formerly hosted on orion.  We should be set with the current
{netrek,netrek-dev,netrek-cvs}@us.netrek.org lists, but any additions
will go there from now on.  The lists.netrek.org manager is the same as
us.netrek.org.

I have removed the numerous mailing lists on SourceForge after
discussion with James.  Most of these lists were empty or inactive save
one, netrek-vanilla-cvs at lists.sourceforge.net, and that was just a
subset of netrek-cvs at us.netrek.org.  Please use netrek-cvs at us.netrek.org
for CVS related mail going forward.

Please let me know if there are any problems.

Dave



From stephen.thorne at gmail.com  Thu May  4 18:39:35 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 5 May 2006 09:39:35 +1000
Subject: [netrek-dev] Vanilla repository
Message-ID: <3e8ca5c80605041639i5124448j118fca0bb87d8b5c@mail.gmail.com>

Hi again. This is an update on the current policy for patching the
Netrek Vanilla Server.

Until June 1st, if you have SourceForge CVS access, use CVS commits for Vanilla.

After June 1st, please use the darcs repository, and use 'darcs send'
to submit patches.

If you do not have SourceForge CVS access, please use darcs.

10 second darcs tutorial:

darcs get http://www.netrek.org/repos/netrek-server/
# make changes
darcs record -am "Some commit message"
darcs send -a
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Sat May  6 06:12:57 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 6 May 2006 21:12:57 +1000
Subject: [netrek-dev] *.tamu.edu block on netrekxp
In-Reply-To: <200605060540.k465enwr021553@enchanter.real-time.com>
References: <200605060540.k465enwr021553@enchanter.real-time.com>
Message-ID: <20060506111256.GA22387@us.netrek.org>

On Sat, May 06, 2006 at 05:40:02AM +0000, Bill Balcerski wrote:
> *.tamu.edu removed from metaserver listing, and direct connect via -h
> servername also removed.  This is due to the policy of blocking all
> players with the default login that comes with the client.

That's a good idea.  It will help to reduce the annoyance felt by
players who don't yet know of the server policy ... which is quite
likely if they are new-be-nice.

Please accept the attached patch.  It does the following:

- factorises the block to a single point in the code, so that adding new
  blocks will be easier, and removing the block in future will be
  easier,

- skip the block if the user has configured their login correctly,

- emit an explanatory message to console when "-h" is used,

I'm not able to test this, sorry.  Lacking in appropriate OS.

I wasn't able to find where "new-be-nice" is initially set.  It doesn't
appear in the source in CVS.  Where is it?  How can we get it in there?

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
--- include/parsemeta.h.~1~	2006-04-28 00:01:08.000000000 +1000
+++ include/parsemeta.h	2006-05-06 21:00:36.000000000 +1000
@@ -48,6 +48,8 @@
  *  select a server.
  */
 
+int metablock(char *host);
+/* block connections to known servers not willing to handle new-be-nice */
 
 #endif /* defined META */
 #endif /* defined meta_h_header */
--- src/main.c.~1~	2006-05-06 20:48:56.000000000 +1000
+++ src/main.c	2006-05-06 21:05:20.000000000 +1000
@@ -256,8 +256,10 @@
                 if (i < argc)
                 {
                     servertmp = argv[i + 1];
-                    if (strstr(servertmp,".tamu.edu") != NULL)
+                    if (metablock(servertmp) != NULL) {
+                        LineToConsole ("new-be-nice not welcome there\n");
                         exit (0);
+                    }
                     usemeta = 0;
                     i++;
                 }
--- src/parsemeta.c.~1~	2006-05-06 20:49:41.000000000 +1000
+++ src/parsemeta.c	2006-05-06 21:07:24.000000000 +1000
@@ -168,6 +168,14 @@
     return (sock);
 }
 
+int
+metablock (char *host)
+/* Block connections to known servers not willing to handle new-be-nice */
+{
+    if (strcmp(login, "new-be-nice")) return 0;
+    if (strstr(slist->address,".tamu.edu") == NULL) return 0;
+    return 1;
+}
 
 static void
 parseInput (char *in,
@@ -299,8 +307,8 @@
 			slist->pkt_rtt[i] = -1;
 #endif
 
-        /* Don't list Paradise Servers or *.tamu.edu */
-        if (slist->typeflag != 'P' && strstr(slist->address,".tamu.edu") == NULL)
+        /* Don't list servers we cannot use */
+        if (slist->typeflag != 'P' && !metablock(slist->address))
         {
 
 #ifdef DEBUG
@@ -583,8 +591,7 @@
 
     slist = serverlist + i;
     
-    // Don't list *.tamu.edu
-    if (strstr(slist->address,".tamu.edu") != NULL)
+    if (metablock(slist->address))
         return;
         
 #ifdef METAPING
-------------- 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/20060506/fc35f4d4/attachment.pgp 

From williamb at its.caltech.edu  Sat May  6 12:09:46 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Sat, 6 May 2006 10:09:46 -0700 (PDT)
Subject: [netrek-dev] *.tamu.edu block on netrekxp
In-Reply-To: <20060506111256.GA22387@us.netrek.org>
References: <200605060540.k465enwr021553@enchanter.real-time.com>
	<20060506111256.GA22387@us.netrek.org>
Message-ID: <Pine.GSO.4.58.0605060948360.4419@inky>

New-be-nice is the default login that comes with the netrekrc off
playnetrek.org, I noticed that stas's latest release off his website does
not use this, as his version does not come with an rc file, so instead
the program uses your Windows login as your login name.  I was planning on
including an rc file, but changing default login to "netrek-player".
However, I imagine this too would be banned by tamu's operator (Michael).
Seeing as how I cannot even connect to his server due to a 3 year+
siteban, plus he won't speak to me, I really have no desire for my client
to be used on his server.  If he were willing to work with me, I could
accept your patch as is, to just stop the default login.  Though in that
case I think the -h block wouldn't be needed, as if you are at the level
where you know how to connect manually to a server you aren't that
clueless a player.
Bill

On Sat, 6 May 2006, James Cameron wrote:

> On Sat, May 06, 2006 at 05:40:02AM +0000, Bill Balcerski wrote:
> > *.tamu.edu removed from metaserver listing, and direct connect via -h
> > servername also removed.  This is due to the policy of blocking all
> > players with the default login that comes with the client.
>
> That's a good idea.  It will help to reduce the annoyance felt by
> players who don't yet know of the server policy ... which is quite
> likely if they are new-be-nice.
>
> Please accept the attached patch.  It does the following:
>
> - factorises the block to a single point in the code, so that adding new
>   blocks will be easier, and removing the block in future will be
>   easier,
>
> - skip the block if the user has configured their login correctly,
>
> - emit an explanatory message to console when "-h" is used,
>
> I'm not able to test this, sorry.  Lacking in appropriate OS.
>
> I wasn't able to find where "new-be-nice" is initially set.  It doesn't
> appear in the source in CVS.  Where is it?  How can we get it in there?
>
> --
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
>


From netrek at gmail.com  Sat May  6 14:57:12 2006
From: netrek at gmail.com (Zach)
Date: Sat, 6 May 2006 15:57:12 -0400
Subject: [netrek-dev] darcs update?
Message-ID: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>

I see quite a few changes have been made in Vanilla. How do I update
my darcs repo to pull in these changes?

Zach


From keyos at keyos.org  Sat May  6 14:58:42 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Sat, 06 May 2006 22:58:42 +0300 (IDT)
Subject: [netrek-dev] *.tamu.edu block on netrekxp
In-Reply-To: <Pine.GSO.4.58.0605060948360.4419@inky>
References: <200605060540.k465enwr021553@enchanter.real-time.com>
	<20060506111256.GA22387@us.netrek.org>
	<Pine.GSO.4.58.0605060948360.4419@inky>
Message-ID: <Pine.GSO.4.63.0605062243450.1386@fcnep.argivfvba.arg.vy>

Hi Bill,

I personally don't see how you banning some server can
do good to netrek. I  am familiar with decision to ban
new-be-nice logins on hockey games. I can say that
there's reason behind that. I can explain why most of
hockey players agree with this decision.

I don't know why and for what reason caltech.edu was banned
by tamu, but I can assure you that this was done to ban you
and nobody else (because as far as I know nobody else plays
from caltech.edu for years now).

Now when you just do same and disable the client from being able
to connect to tamu you do bad job to client users, not to
tamu's admin.

I also don't see any reason to introduce blocks into client
side. Why would somebody want to play with your client if he
has to switch to cow when playing hockey ?

Now regarding rc file with new-be-nice login. I think Joe's idea
was to separate veterans from newbies at the beginning. However
from what I can see today everyone (veterans including) use
new-be-nice logins to either pretend to be newbie or just because
they are ones.

Today I would recommend to Joe (I hope he's in the list) to remove
this login name from rc file. This way there is much better chance of
seeing new logins (these days like 90% of login names are new-be-nice)
and getting familiar with people. Recognizing newbie is much easier
from watching him play.

My 2 sheqels on the issue :)

Stas.

On Sat, 6 May 2006, William Balcerski wrote:

> Date: Sat, 6 May 2006 10:09:46 -0700 (PDT)
> From: William Balcerski <williamb at its.caltech.edu>
> Reply-To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] *.tamu.edu block on netrekxp
> 
> New-be-nice is the default login that comes with the netrekrc off
> playnetrek.org, I noticed that stas's latest release off his website does
> not use this, as his version does not come with an rc file, so instead
> the program uses your Windows login as your login name.  I was planning on
> including an rc file, but changing default login to "netrek-player".
> However, I imagine this too would be banned by tamu's operator (Michael).
> Seeing as how I cannot even connect to his server due to a 3 year+
> siteban, plus he won't speak to me, I really have no desire for my client
> to be used on his server.  If he were willing to work with me, I could
> accept your patch as is, to just stop the default login.  Though in that
> case I think the -h block wouldn't be needed, as if you are at the level
> where you know how to connect manually to a server you aren't that
> clueless a player.
> Bill
> 
> On Sat, 6 May 2006, James Cameron wrote:
> 
> > On Sat, May 06, 2006 at 05:40:02AM +0000, Bill Balcerski wrote:
> > > *.tamu.edu removed from metaserver listing, and direct connect via -h
> > > servername also removed.  This is due to the policy of blocking all
> > > players with the default login that comes with the client.
> >
> > That's a good idea.  It will help to reduce the annoyance felt by
> > players who don't yet know of the server policy ... which is quite
> > likely if they are new-be-nice.
> >
> > Please accept the attached patch.  It does the following:
> >
> > - factorises the block to a single point in the code, so that adding new
> >   blocks will be easier, and removing the block in future will be
> >   easier,
> >
> > - skip the block if the user has configured their login correctly,
> >
> > - emit an explanatory message to console when "-h" is used,
> >
> > I'm not able to test this, sorry.  Lacking in appropriate OS.
> >
> > I wasn't able to find where "new-be-nice" is initially set.  It doesn't
> > appear in the source in CVS.  Where is it?  How can we get it in there?
> >
> > --
> > 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 netrek at gmail.com  Sat May  6 15:03:01 2006
From: netrek at gmail.com (Zach)
Date: Sat, 6 May 2006 16:03:01 -0400
Subject: [netrek-dev] darcs list?
Message-ID: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>

Since starting June Vanilla will only issue releases to CVS and use
darcs for between release changes does this mean a netrek-darcs list
will be setup and commits will be automatically posted there as
happens on the netrek-cvs list currently?

Zach


From netrek at gmail.com  Sat May  6 15:16:39 2006
From: netrek at gmail.com (Zach)
Date: Sat, 6 May 2006 16:16:39 -0400
Subject: [netrek-dev] *.tamu.edu block on netrekxp
In-Reply-To: <Pine.GSO.4.63.0605062243450.1386@fcnep.argivfvba.arg.vy>
References: <200605060540.k465enwr021553@enchanter.real-time.com>
	<20060506111256.GA22387@us.netrek.org>
	<Pine.GSO.4.58.0605060948360.4419@inky>
	<Pine.GSO.4.63.0605062243450.1386@fcnep.argivfvba.arg.vy>
Message-ID: <ecfa260c0605061316p652a436ft23ea4bdf12ea8526@mail.gmail.com>

On 5/6/06, Stas Pirogov <keyos at keyos.org> wrote:
>
> Today I would recommend to Joe (I hope he's in the list) to remove
> this login name from rc file. This way there is much better chance of
> seeing new logins (these days like 90% of login names are new-be-nice)
> and getting familiar with people. Recognizing newbie is much easier
> from watching him play.

Amen to that! Sadly the trend is for many experiences players to play
as anonymous or even to masquerade as someone else. It's really
childish and it's an interesting datum that there seems to be a high
correlation between the most abusive players and anonymity. Some
anonymous players are consistent in using the same Login and I can
respect that though I think it's a bit too paranoid. Perhaps we can
have a player setup utility that will ask them to choose a name and
login at least and at most will allow intuitive setup of their rc
file. When I started playing netrek 90% + of the player base played
from university accounts and had a verifiable user id. This also
allowed for quick identification and differentiation. Often you could
use finger or other utilities to find out exactly who that player was.
I really don't see it as a bad thing if players had to give their real
names to play.

Zach


From quozl at us.netrek.org  Sat May  6 19:28:13 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 7 May 2006 10:28:13 +1000
Subject: [netrek-dev] darcs update?
In-Reply-To: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>
References: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>
Message-ID: <20060507002813.GA4900@us.netrek.org>

On Sat, May 06, 2006 at 03:57:12PM -0400, Zach wrote:
> I see quite a few changes have been made in Vanilla. How do I update
> my darcs repo to pull in these changes?

darcs pull

This will pull in these changes from the repository you last did a get
or pull from.  Chances are this is the repository you want.

Remember there are multiple repositories, and they may not have the same
changes.  That's the whole idea of decentralised development.  The
netrek.org repository tracks CVS on SourceForge until 1st June 2006.  My
public repository has some changes that are not and never will be in
CVS.

The changes you saw on the Netrek CVS mailing list are the changes made
to CVS on SourceForge.  If these are the only changes you want in your
darcs repository, then you should pull from only the netrek.org
repository.

To make that explicit rather than having darcs default to the last used
repository, add the URL of the repository to the end of the pull
command, like so:

darcs pull http://www.netrek.org/repos/netrek-server/


Please read this section of the manual:

Switching from CVS
Darcs commands for CVS users
http://www.darcs.net/manual/node2.html#SECTION00220000000000000000

-- 
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/20060507/95992081/attachment.pgp 

From netrek at gmail.com  Sat May  6 19:34:02 2006
From: netrek at gmail.com (Zach)
Date: Sat, 6 May 2006 20:34:02 -0400
Subject: [netrek-dev] darcs update?
In-Reply-To: <20060507002813.GA4900@us.netrek.org>
References: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>
	<20060507002813.GA4900@us.netrek.org>
Message-ID: <ecfa260c0605061734u76be1ed5i5a69441042afadc@mail.gmail.com>

Thanks that's what I needed. I noticed the Linux kernel developers use
BitKeeper. Is this a tool we may use on Vanilla?

Zach

On 5/6/06, James Cameron <quozl at us.netrek.org> wrote:
>
> darcs pull
>
> This will pull in these changes from the repository you last did a get
> or pull from.  Chances are this is the repository you want.
[...]


From quozl at us.netrek.org  Sat May  6 19:37:29 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 7 May 2006 10:37:29 +1000
Subject: [netrek-dev] darcs list?
In-Reply-To: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>
References: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>
Message-ID: <20060507003729.GB4900@us.netrek.org>

On Sat, May 06, 2006 at 04:03:01PM -0400, Zach wrote:
> Since starting June Vanilla will only issue releases to CVS and use
> darcs for between release changes does this mean a netrek-darcs list
> will be setup and commits will be automatically posted there as
> happens on the netrek-cvs list currently?

No.  I don't see a need for this.  Change sets are easily seen with
darcs or a web browser.

Some "darcs send" generated changes may be seen on the netrek-dev
mailing list from developers whose darcs repository isn't merged-from
regularly by the Vanilla developers.  Downstream packagers, occasional
developers, or server owners may be the source of such changes.

Further, I'd like to propose that on 1st December 2006 that the Vanilla
developers abandon CVS altogether, hosting the .tar.gz releases only on
SourceForge.

-- 
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/20060507/7aecbf37/attachment.pgp 

From tanner at real-time.com  Sat May  6 20:23:14 2006
From: tanner at real-time.com (Bob Tanner)
Date: Sat, 6 May 2006 20:23:14 -0500
Subject: [netrek-dev] darcs update?
In-Reply-To: <ecfa260c0605061734u76be1ed5i5a69441042afadc@mail.gmail.com>
References: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>
	<20060507002813.GA4900@us.netrek.org>
	<ecfa260c0605061734u76be1ed5i5a69441042afadc@mail.gmail.com>
Message-ID: <200605062023.15193.tanner@real-time.com>

On Saturday 06 May 2006 19:34, Zach wrote:
> Thanks that's what I needed. I noticed the Linux kernel developers use
> BitKeeper. Is this a tool we may use on Vanilla?

No. 

The kernel uses git.

-- 
Bob Tanner <tanner at real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint -------------- 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/20060506/455ba9bc/attachment.pgp 

From tanner at real-time.com  Sat May  6 22:40:40 2006
From: tanner at real-time.com (Bob Tanner)
Date: Sat, 06 May 2006 22:40:40 -0500
Subject: [netrek-dev] darcs update?
References: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>
	<20060507002813.GA4900@us.netrek.org>
Message-ID: <e3jq7p$nlp$1@sea.gmane.org>

James Cameron wrote:

> Remember there are multiple repositories, and they may not have the same
> changes. ?That's the whole idea of decentralised development. ?The
> netrek.org repository tracks CVS on SourceForge until 1st June 2006. ?My
> public repository has some changes that are not and never will be in
> CVS.

Can we make a section on the wiki for people with repositories can list
them?

-- 
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  Sat May  6 22:41:32 2006
From: tanner at real-time.com (Bob Tanner)
Date: Sat, 06 May 2006 22:41:32 -0500
Subject: [netrek-dev] darcs list?
References: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>
	<20060507003729.GB4900@us.netrek.org>
Message-ID: <e3jq9c$nlp$2@sea.gmane.org>

James Cameron wrote:

> No. ?I don't see a need for this. ?Change sets are easily seen with
> darcs or a web browser.
> 

Can changesets be published as RSS, ATOM feeds?

-- 
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  Sat May  6 23:22:53 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Sun, 7 May 2006 14:22:53 +1000
Subject: [netrek-dev] darcs list?
In-Reply-To: <e3jq9c$nlp$2@sea.gmane.org>
References: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>
	<20060507003729.GB4900@us.netrek.org> <e3jq9c$nlp$2@sea.gmane.org>
Message-ID: <3e8ca5c80605062122y4f88c8do425f4b968ecce7b9@mail.gmail.com>

On 5/7/06, Bob Tanner <tanner at real-time.com> wrote:
> Can changesets be published as RSS, ATOM feeds?

That's a really interesting question. I will research this.

--
Stephen Thorne
Development Engineer


From netrek at gmail.com  Sun May  7 02:17:43 2006
From: netrek at gmail.com (Zach)
Date: Sun, 7 May 2006 03:17:43 -0400
Subject: [netrek-dev] darcs list?
In-Reply-To: <3e8ca5c80605062122y4f88c8do425f4b968ecce7b9@mail.gmail.com>
References: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>
	<20060507003729.GB4900@us.netrek.org> <e3jq9c$nlp$2@sea.gmane.org>
	<3e8ca5c80605062122y4f88c8do425f4b968ecce7b9@mail.gmail.com>
Message-ID: <ecfa260c0605070017m308cdf9n6534eaa75fc55c0d@mail.gmail.com>

On 5/7/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
> On 5/7/06, Bob Tanner <tanner at real-time.com> wrote:
> > Can changesets be published as RSS, ATOM feeds?
>
> That's a really interesting question. I will research this.

darcs2rss - Easy ChangeLog -> RSS convertor
http://www.darcs.net/DarcsWiki/RelatedSoftware

http://www.abridgegame.org/pipermail/darcs-users/2005-January/005145.html

Zach


From quozl at us.netrek.org  Sun May  7 07:09:53 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 7 May 2006 22:09:53 +1000
Subject: [netrek-dev] *.tamu.edu block on netrekxp
In-Reply-To: <ecfa260c0605061316p652a436ft23ea4bdf12ea8526@mail.gmail.com>
	<Pine.GSO.4.63.0605062243450.1386@fcnep.argivfvba.arg.vy>
	<Pine.GSO.4.58.0605060948360.4419@inky>
References: <Pine.GSO.4.58.0605060948360.4419@inky>
	<Pine.GSO.4.63.0605062243450.1386@fcnep.argivfvba.arg.vy>
	<ecfa260c0605061316p652a436ft23ea4bdf12ea8526@mail.gmail.com>
	<200605060540.k465enwr021553@enchanter.real-time.com>
	<20060506111256.GA22387@us.netrek.org>
	<Pine.GSO.4.58.0605060948360.4419@inky>
	<Pine.GSO.4.63.0605062243450.1386@fcnep.argivfvba.arg.vy>
	<200605060540.k465enwr021553@enchanter.real-time.com>
	<20060506111256.GA22387@us.netrek.org>
	<Pine.GSO.4.58.0605060948360.4419@inky>
Message-ID: <20060507120953.GA8148@us.netrek.org>

William Balcerski wrote:
> Seeing as how I cannot even connect to his server due to a 3 year+
> siteban, plus he won't speak to me, I really have no desire for my
> client to be used on his server.

Fascinating idea, that you believe the client is yours, yet you are
building on the work of many developers before you.  The concept is
alien to me; I can never think of the server code as mine.

> If he were willing to work with me, I could accept your patch as is,
> to just stop the default login.

The policy of some server owner is inconsequential to the technical
argument, that the client would be more useful with my patch than
without it.  If you've no technical grounds for refusal, then I need not
participate further on this issue.

Stas Pirogov wrote:
> Now when you just do same and disable the client from being able
> to connect to tamu you do bad job to client users, not to
> tamu's admin.

Agreed.  The ethics go beyond my limit ... to hurt a friend of an enemy
is the stuff of terrorism.  If he has an issue with a server owner, he
should talk to the server owner about it.  Source code is a blunt
weapon, which seldom strikes true.

Zach wrote:
> I really don't see it as a bad thing if players had to give their real
> names to play.

The player registration feature is not yet complete.  I'll take patches
to improve 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/20060507/6cb537e4/attachment.pgp 

From quozl at us.netrek.org  Sun May  7 07:57:28 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 7 May 2006 22:57:28 +1000
Subject: [netrek-dev] darcs update?
In-Reply-To: <e3jq7p$nlp$1@sea.gmane.org>
References: <ecfa260c0605061257x550cf1afj58b661c8bd99b4dd@mail.gmail.com>
	<20060507002813.GA4900@us.netrek.org> <e3jq7p$nlp$1@sea.gmane.org>
Message-ID: <20060507125728.GG4900@us.netrek.org>

On Sat, May 06, 2006 at 10:40:40PM -0500, Bob Tanner wrote:
> Can we make a section on the wiki for people with repositories can
> list them?

Sure.  Edit the SourceControl page.  I've added the accessible
repositories that I know of.

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


From jimmyhua73 at yahoo.com  Sun May  7 23:53:57 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 7 May 2006 21:53:57 -0700 (PDT)
Subject: [netrek-dev] updated newbie code
Message-ID: <20060508045357.12949.qmail@web35314.mail.mud.yahoo.com>

Hi, 
  
  Dunno how many active developers of netrek code is there. 
  
  but I updated the newbie.c code to startup with different teams other than fed vs. rom. 
  
  It does them all now, randomly. 
  
  I did this many many years back, but the code never got integrated into  the vanilla source code. So I am doing it again, as the netrek server  code has changed quite a bit. 
  
  I hope you can incorporate the changes into the standard distribution. 
  
  Code has been tested. Works pretty good, I'm sure there's more bugs. But I'll clean them up as soon as I find them. 
  
  Jimmy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060507/06629925/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie.c
Type: application/octet-stream
Size: 17264 bytes
Desc: 2969360621-newbie.c
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060507/06629925/attachment.obj 

From stephen.thorne at gmail.com  Mon May  8 01:09:51 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Mon, 8 May 2006 16:09:51 +1000
Subject: [netrek-dev] updated newbie code
In-Reply-To: <20060508045357.12949.qmail@web35314.mail.mud.yahoo.com>
References: <20060508045357.12949.qmail@web35314.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605072309t1c6b8fb5i8ff08aefe7e6d4d2@mail.gmail.com>

On 5/8/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>  Code has been tested. Works pretty good, I'm sure there's more bugs. But
> I'll clean them up as soon as I find them.

I've taken your newbie.c file and turned it into patches against the
latest development version.

Attached are:
random-newbie.patch
A darcs patch that will apply using 'darcs apply'.

random-newbie-plain.patch
A plain diff -u against the main sourcetree. will apply with 'patch -p1'

Welcome to the netrek development team. If you need to make notes
about your work, there is a wiki located here:
http://wiki.us.netrek.org/netrek-dev/
--
Stephen Thorne
Development Engineer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: random-newbie.patch
Type: application/octet-stream
Size: 15099 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060508/b595bc80/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: random-newbie-plain.patch
Type: application/octet-stream
Size: 10285 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060508/b595bc80/attachment-0003.obj 

From netrek at gmail.com  Mon May  8 07:21:07 2006
From: netrek at gmail.com (Zach)
Date: Mon, 8 May 2006 08:21:07 -0400
Subject: [netrek-dev] Netrek Cinema?
Message-ID: <ecfa260c0605080521s4d2b06f4k1bcd46040283e26a@mail.gmail.com>

The homepage and files seem to be missing. Is this content on a backup
somewhere and if so can it be restored?

http://web.archive.org/web/20050325023822/http://www.netrek.org/cinema2/

Zach


From quozl at us.netrek.org  Mon May  8 08:19:56 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 8 May 2006 23:19:56 +1000
Subject: [netrek-dev] Netrek Cinema?
In-Reply-To: <ecfa260c0605080521s4d2b06f4k1bcd46040283e26a@mail.gmail.com>
References: <ecfa260c0605080521s4d2b06f4k1bcd46040283e26a@mail.gmail.com>
Message-ID: <20060508131956.GA16715@us.netrek.org>

On Mon, May 08, 2006 at 08:21:07AM -0400, Zach wrote:
> The homepage and files seem to be missing. Is this content on a backup
> somewhere and if so can it be restored?

The former content from netrek.org is exactly where Dave and I said it
was before, nothing has changed.

It was on 27th January that I said http://genocide.netrek.org/ contains
the old content:

http://shadowknight.real-time.com/pipermail/netrek-dev/2006-January/002797.html

It was on 21st April that Dave reminded you, when he referred to
http://genocide.netrek.org/cow/

http://shadowknight.real-time.com/pipermail/netrek-dev/2006-April/002919.html

Please check the mailing list for previous answers.

All the cinema2 content is available, less the directory listings.

For example:
http://genocide.netrek.org/cinema2/jpg/tom1.jpg
http://genocide.netrek.org/cinema2/jpg/tom2.jpg

It seems that we might need PHP enabled before some of the content works
properly.  Feel free to work toward that, we could do with some help.
We probably don't want to run PHP at all.  I've not yet talked to Dave
about it.

Dave: can I enable directory listings in that tree?

-- 
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/20060508/c7df5570/attachment.pgp 

From keyos at keyos.org  Mon May  8 14:09:37 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Mon, 08 May 2006 22:09:37 +0300 (IDT)
Subject: [netrek-dev] Netrek Cinema?
In-Reply-To: <20060508131956.GA16715@us.netrek.org>
References: <ecfa260c0605080521s4d2b06f4k1bcd46040283e26a@mail.gmail.com>
	<20060508131956.GA16715@us.netrek.org>
Message-ID: <Pine.GSO.4.63.0605082203080.9604@fcnep.argivfvba.arg.vy>

On Mon, 8 May 2006, James Cameron wrote:
> 
> The former content from netrek.org is exactly where Dave and I said it
> was before, nothing has changed.
> 
> It was on 27th January that I said http://genocide.netrek.org/ contains
> the old content:
> 
> http://shadowknight.real-time.com/pipermail/netrek-dev/2006-January/002797.=
> html
> 

Not sure if I'm the only one who has problems, but have you tried actually 
browsing this site ?

> It was on 21st April that Dave reminded you, when he referred to
> http://genocide.netrek.org/cow/
> 
> http://shadowknight.real-time.com/pipermail/netrek-dev/2006-April/002919.ht=
> ml
> 

And this one ?

For both I either get 403 Forbidden errors, or it simply closes connection 
and I get "Unable to open ..."

Correct me if I'm wrong, but this doesn't look like former content to me.

Stas.


From ahn at orion.netrek.org  Mon May  8 14:17:53 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Mon, 8 May 2006 15:17:53 -0400
Subject: [netrek-dev] Netrek Cinema?
In-Reply-To: <Pine.GSO.4.63.0605082203080.9604@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605080521s4d2b06f4k1bcd46040283e26a@mail.gmail.com>
	<20060508131956.GA16715@us.netrek.org>
	<Pine.GSO.4.63.0605082203080.9604@fcnep.argivfvba.arg.vy>
Message-ID: <20060508191753.GA2151@orion.netrek.org>

On Mon, May 08, 2006 at 10:09:37PM +0300, Stas Pirogov wrote:
> 
[...]
>
> Not sure if I'm the only one who has problems, but have you tried actually 
> browsing this site ?

[...]

> And this one ?
> 
> For both I either get 403 Forbidden errors, or it simply closes connection 
> and I get "Unable to open ..."
> 
> Correct me if I'm wrong, but this doesn't look like former content to me.
> 
> Stas.

The old content is partially broken.  As you may have noticed this past
week I am in the process of restoring these broken services.  I
apologize that it is taking far too long.  Hopefully a move to a
wiki-based content publication system will increase the maintainability
of the web site.  I will try to get to it as soon as I can.



From netrek at gmail.com  Mon May  8 15:36:35 2006
From: netrek at gmail.com (Zach)
Date: Mon, 8 May 2006 16:36:35 -0400
Subject: [netrek-dev] Netrek Cinema?
In-Reply-To: <20060508131956.GA16715@us.netrek.org>
References: <ecfa260c0605080521s4d2b06f4k1bcd46040283e26a@mail.gmail.com>
	<20060508131956.GA16715@us.netrek.org>
Message-ID: <ecfa260c0605081336y39cdea5h437e0b36af4b8b29@mail.gmail.com>

On 5/8/06, James Cameron <quozl at us.netrek.org> wrote:
>
> It seems that we might need PHP enabled before some of the content works
> properly.  Feel free to work toward that, we could do with some help.
> We probably don't want to run PHP at all.  I've not yet talked to Dave
> about it.

Do you have security concerns about running PHP? I'd be glad to help out.

Zach


From williamb at its.caltech.edu  Mon May  8 19:39:50 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Mon, 8 May 2006 19:39:50 -0500
Subject: [netrek-dev] darcs patch: Fix to Observer lock onto Iggy and can't
	do anything o...
Message-ID: <200605090039.k490douB010989@omen.digital-genesis.com>

Mon May  8 19:39:25 CDT 2006  williamb at its.caltech.edu
  * Fix to Observer lock onto Iggy and can't do anything or even quit the game bug.  Also removes delay for observers locked onto someone who is refitting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 8040 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060508/63469bb6/attachment.bin 

From stephen.thorne at gmail.com  Mon May  8 20:31:32 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 9 May 2006 11:31:32 +1000
Subject: [netrek-dev] darcs patch: Fix to Observer lock onto Iggy and
	can't do anything o...
In-Reply-To: <200605090039.k490douB010989@omen.digital-genesis.com>
References: <200605090039.k490douB010989@omen.digital-genesis.com>
Message-ID: <3e8ca5c80605081831t484f3c71xd15465868181734@mail.gmail.com>

On 5/9/06, williamb at its.caltech.edu <williamb at its.caltech.edu> wrote:
> Mon May  8 19:39:25 CDT 2006  williamb at its.caltech.edu
>   * Fix to Observer lock onto Iggy and can't do anything or even quit the game bug.  Also removes delay for observers locked onto someone who is refitting.

This patch is now on the shiny respository.
http://shiny.thorne.id.au/~stephen/netrek-server/
I'm going to sync up www.netrek.org after I'm satisfied with this
change and some others.
--
Stephen Thorne
Development Engineer


From williamb at its.caltech.edu  Mon May  8 20:59:37 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Mon, 8 May 2006 20:59:37 -0500
Subject: [netrek-dev] darcs patch: My local server config (and 1 more)
Message-ID: <200605090159.k491xb94023814@omen.digital-genesis.com>

Mon May  8 20:14:19 CDT 2006  williamb at its.caltech.edu
  * My local server config

Mon May  8 20:59:25 CDT 2006  williamb at its.caltech.edu
  * Newbie server updated install instructions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 8767 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060508/e8caac2b/attachment-0001.bin 

From stephen.thorne at gmail.com  Mon May  8 21:09:41 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 9 May 2006 12:09:41 +1000
Subject: [netrek-dev] darcs patch: My local server config (and 1 more)
In-Reply-To: <200605090159.k491xb94023814@omen.digital-genesis.com>
References: <200605090159.k491xb94023814@omen.digital-genesis.com>
Message-ID: <3e8ca5c80605081909g6678142dm513b418fe890ba41@mail.gmail.com>

On 5/9/06, williamb at its.caltech.edu <williamb at its.caltech.edu> wrote:
> Mon May  8 20:14:19 CDT 2006  williamb at its.caltech.edu
>   * My local server config

Rejected.

> Mon May  8 20:59:25 CDT 2006  williamb at its.caltech.edu
>   * Newbie server updated install instructions

Accepted.

--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Mon May  8 21:31:14 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 9 May 2006 12:31:14 +1000
Subject: [netrek-dev] CVS down, again
Message-ID: <20060509023114.GA10543@us.netrek.org>

SourceForge CVS appears to be down again.  Several developers are
receiving a password prompt despite having a public key held by
SourceForge.

While it is down, my changes are going to my darcs repository, and I'll
commit them to CVS later.

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


From jrd at gerdesas.com  Mon May  8 21:44:19 2006
From: jrd at gerdesas.com (John R. Dennison)
Date: Mon, 8 May 2006 21:44:19 -0500
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509023114.GA10543@us.netrek.org>
References: <20060509023114.GA10543@us.netrek.org>
Message-ID: <20060509024419.GH10251@gerdesas.gerdesas.com>

On Tue, May 09, 2006 at 12:31:14PM +1000, James Cameron wrote:
> SourceForge CVS appears to be down again.  Several developers are
> receiving a password prompt despite having a public key held by
> SourceForge.

	And I ask myself yet again /why/ people continue to use
	SF?  Their downtime is, and has been for quite some time,
	higher then it has any right to be.




							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt


From stephen.thorne at gmail.com  Mon May  8 22:03:07 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 9 May 2006 13:03:07 +1000
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509024419.GH10251@gerdesas.gerdesas.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
Message-ID: <3e8ca5c80605082003x15db6c2bg947a48ddff7ed934@mail.gmail.com>

On 5/9/06, John R. Dennison <jrd at gerdesas.com> wrote:
>         And I ask myself yet again /why/ people continue to use
>         SF?  Their downtime is, and has been for quite some time,
>         higher then it has any right to be.

Soon, this will be a non-issue. June 1st is our cutover date for not
using SF CVS for vanilla development, and using darcs instead. If that
goes smoothly, I expect to see the other sourcetrees following suit.

If the SF repos don't come back up within a few days, I will summarily
announce that server development is darcs only.
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Mon May  8 22:05:52 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 9 May 2006 13:05:52 +1000
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509024419.GH10251@gerdesas.gerdesas.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
Message-ID: <20060509030552.GB10543@us.netrek.org>

On Mon, May 08, 2006 at 09:44:19PM -0500, John R. Dennison wrote:
> 	And I ask myself yet again /why/ people continue to use
> 	SF?  Their downtime is, and has been for quite some time,
> 	higher then it has any right to be.

Only because we used to.  We're moving away slowly.  Once upon a time it
was great.

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


From darius at dons.net.au  Mon May  8 22:09:43 2006
From: darius at dons.net.au (Daniel O'Connor)
Date: Tue, 9 May 2006 12:39:43 +0930
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509024419.GH10251@gerdesas.gerdesas.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
Message-ID: <200605091240.05876.darius@dons.net.au>

On Tuesday 09 May 2006 12:14, John R. Dennison wrote:
> 	And I ask myself yet again /why/ people continue to use
> 	SF?  Their downtime is, and has been for quite some time,
> 	higher then it has any right to be.

It _is_ free.. it has a right to suck as much as it wants.

Still, why people continue to use it when it does suck is mainly due to 
inertia I suspect :)

-- 
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/20060509/977b2f91/attachment.pgp 

From jrd at gerdesas.com  Mon May  8 22:36:13 2006
From: jrd at gerdesas.com (John R. Dennison)
Date: Mon, 8 May 2006 22:36:13 -0500
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509030552.GB10543@us.netrek.org>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
	<20060509030552.GB10543@us.netrek.org>
Message-ID: <20060509033613.GI10251@gerdesas.gerdesas.com>

On Tue, May 09, 2006 at 01:05:52PM +1000, James Cameron wrote:
> 
> Only because we used to.  We're moving away slowly.  Once upon a time it
> was great.

	No.  Once upon a time it was new.  And the only game in town.

	There have /always/ been issues with various parts of the
	SF infrastructure; since day one.  It is built of kludge upon
	kludge.

	It has never been 'great' except in the sense that it has had
	much to do with the momentum of the Open Source movement.  I
	will give them credit where due; I will not however consider
	them reliable.  And not being able to update a project code
	repository on a service that exists almost solely for that
	express purpose is just not cool.

	I am extremely happy to see Vanilla and eventually the other
	projects moved to darcs.  And I appreciate the time that the
	various developers have put into this effort.  You time will
	have paid off quite quickly, I expect, in the near future.





							John


-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt


From quozl at us.netrek.org  Mon May  8 23:02:03 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 9 May 2006 14:02:03 +1000
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509033613.GI10251@gerdesas.gerdesas.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
	<20060509030552.GB10543@us.netrek.org>
	<20060509033613.GI10251@gerdesas.gerdesas.com>
Message-ID: <20060509040203.GC10543@us.netrek.org>

On Mon, May 08, 2006 at 10:36:13PM -0500, John R. Dennison wrote:
> 	I am extremely happy to see Vanilla and eventually the other
> 	projects moved to darcs.  And I appreciate the time that the
> 	various developers have put into this effort.  You time will
> 	have paid off quite quickly, I expect, in the near future.

It has already paid off in my opinion.  ;-}

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


From netrek at gmail.com  Mon May  8 23:01:54 2006
From: netrek at gmail.com (Zach)
Date: Tue, 9 May 2006 00:01:54 -0400
Subject: [netrek-dev] CVS down, again
In-Reply-To: <20060509033613.GI10251@gerdesas.gerdesas.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
	<20060509030552.GB10543@us.netrek.org>
	<20060509033613.GI10251@gerdesas.gerdesas.com>
Message-ID: <ecfa260c0605082101l784b43d4x6aee0de1898ba917@mail.gmail.com>

On 5/8/06, John R. Dennison <jrd at gerdesas.com> wrote:
>
>         No.  Once upon a time it was new.  And the only game in town.
>
>         There have /always/ been issues with various parts of the
>         SF infrastructure; since day one.  It is built of kludge upon
>         kludge.

Any other major sites that host FOSS projects for free?

Zach


From stephen.thorne at gmail.com  Mon May  8 23:12:15 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 9 May 2006 14:12:15 +1000
Subject: [netrek-dev] CVS down, again
In-Reply-To: <ecfa260c0605082101l784b43d4x6aee0de1898ba917@mail.gmail.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
	<20060509030552.GB10543@us.netrek.org>
	<20060509033613.GI10251@gerdesas.gerdesas.com>
	<ecfa260c0605082101l784b43d4x6aee0de1898ba917@mail.gmail.com>
Message-ID: <3e8ca5c80605082112u62713690l9d9b83e2ccf5342f@mail.gmail.com>

On 5/9/06, Zach <netrek at gmail.com> wrote:
> Any other major sites that host FOSS projects for free?
Many.
--
Stephen Thorne
Development Engineer


From netrek at gmail.com  Tue May  9 00:26:40 2006
From: netrek at gmail.com (Zach)
Date: Tue, 9 May 2006 01:26:40 -0400
Subject: [netrek-dev] CVS down, again
In-Reply-To: <3e8ca5c80605082112u62713690l9d9b83e2ccf5342f@mail.gmail.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
	<20060509030552.GB10543@us.netrek.org>
	<20060509033613.GI10251@gerdesas.gerdesas.com>
	<ecfa260c0605082101l784b43d4x6aee0de1898ba917@mail.gmail.com>
	<3e8ca5c80605082112u62713690l9d9b83e2ccf5342f@mail.gmail.com>
Message-ID: <ecfa260c0605082226s403c2af1sadf725262faf2b3c@mail.gmail.com>

On 5/9/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
> On 5/9/06, Zach <netrek at gmail.com> wrote:
> > Any other major sites that host FOSS projects for free?
> Many.

Can you name a few? Freshmeat just lists external links and project
contact info; it doesn't seem to actually host the source for a
project.

Zach


From quozl at us.netrek.org  Tue May  9 00:32:18 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 9 May 2006 15:32:18 +1000
Subject: [netrek-dev] CVS down, again
In-Reply-To: <ecfa260c0605082101l784b43d4x6aee0de1898ba917@mail.gmail.com>
References: <20060509023114.GA10543@us.netrek.org>
	<20060509024419.GH10251@gerdesas.gerdesas.com>
	<20060509030552.GB10543@us.netrek.org>
	<20060509033613.GI10251@gerdesas.gerdesas.com>
	<ecfa260c0605082101l784b43d4x6aee0de1898ba917@mail.gmail.com>
Message-ID: <20060509053218.GD10543@us.netrek.org>

On Tue, May 09, 2006 at 12:01:54AM -0400, Zach wrote:
> Any other major sites that host FOSS projects for free?

netrek.org ;-) 
Provided it has something to do with Netrek.

See also:

http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities
http://en.wikipedia.org/wiki/BerliOS
http://en.wikipedia.org/wiki/SourceForge
http://en.wikipedia.org/wiki/GNU_Savannah

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


From jimmyhua73 at yahoo.com  Tue May  9 01:26:55 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 8 May 2006 23:26:55 -0700 (PDT)
Subject: [netrek-dev] Making changes to robotd directory
Message-ID: <20060509062655.92047.qmail@web35308.mail.mud.yahoo.com>

Hello, 
  
  If no one minds, I will be making a bunch of changes to the robotd directory. 
  
  Mostly to make the newbie robots play a better game of netrek and to  clean up compiler warning messages. I'll be sure to make sure that it  doesn't affect SB practise mode, and it shouldn't affect the PRET mode.  
  
  I dunno how to use darcs (or CVS for that matter), but as I understand  it with my short web reading. It looks like I can just change the code  in the netrek-server-vanilla_2.10.2-0.tar.gz, and e-mail it to someone  here who can "darcs" it out....
  
  Jimmy
  
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060508/54ec697c/attachment.htm 

From quozl at us.netrek.org  Tue May  9 01:47:00 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 9 May 2006 16:47:00 +1000
Subject: [netrek-dev] Making changes to robotd directory
In-Reply-To: <20060509062655.92047.qmail@web35308.mail.mud.yahoo.com>
References: <20060509062655.92047.qmail@web35308.mail.mud.yahoo.com>
Message-ID: <20060509064700.GF10543@us.netrek.org>

G'day Jimmy,

Go ahead with your changes.  But to make it easier to merge them, please
learn a bit of minimal darcs.  Or if not, I can send you a tarball of my
repository.  There have been many changes since 2.10.2.

Quick darcs intro ...

1.  install darcs (there are binaries for most everything),

2.  darcs get http://james.tooraweenah.com/darcs/netrek-server/

3.  make your changes, one set at a time, (e.g. one feature),

4.  darcs record

5.  darcs send

6.  goto 3

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


From quozl at us.netrek.org  Tue May  9 01:56:49 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 9 May 2006 16:56:49 +1000
Subject: [netrek-dev] darcs list?
In-Reply-To: <e3jq9c$nlp$2@sea.gmane.org>
References: <ecfa260c0605061303g515b58a3o9bdb6318d28302ee@mail.gmail.com>
	<20060507003729.GB4900@us.netrek.org> <e3jq9c$nlp$2@sea.gmane.org>
Message-ID: <20060509065649.GA21491@us.netrek.org>

On Sat, May 06, 2006 at 10:41:32PM -0500, Bob Tanner wrote:
> Can changesets be published as RSS, ATOM feeds?

darcs2rss generates a feed fine, but it's a little bare.
http://james.tooraweenah.com/darcs/netrek-server/administrivia/changelog.xml

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


From jimmyhua73 at yahoo.com  Tue May  9 10:37:03 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 9 May 2006 08:37:03 -0700 (PDT)
Subject: [netrek-dev] Making changes to robotd directory
In-Reply-To: <20060509064700.GF10543@us.netrek.org>
Message-ID: <20060509153703.82002.qmail@web35315.mail.mud.yahoo.com>

Thanks for the quick darcs intro. 

Some quick mentions. This has probably have to do with
darcs more than netrek but:

I had to:

chmod u+x configure
chmod u+x tools/mktrekon

to get the configure to work, and subsequently the
make install to work. 

Quick question:
I imagine darcs record, then darcs send. 

Sends the whole tree. 

Is there a way to do this only to a single directory
like the robotd directory or a single file? 



--- James Cameron <quozl at us.netrek.org> wrote:

> G'day Jimmy,
> 
> Go ahead with your changes.  But to make it easier
> to merge them, please
> learn a bit of minimal darcs.  Or if not, I can send
> you a tarball of my
> repository.  There have been many changes since
> 2.10.2.
> 
> Quick darcs intro ...
> 
> 1.  install darcs (there are binaries for most
> everything),
> 
> 2.  darcs get
> http://james.tooraweenah.com/darcs/netrek-server/
> 
> 3.  make your changes, one set at a time, (e.g. one
> feature),
> 
> 4.  darcs record
> 
> 5.  darcs send
> 
> 6.  goto 3
> 
> -- 
> 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 stephen.thorne at gmail.com  Tue May  9 16:45:21 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 10 May 2006 07:45:21 +1000
Subject: [netrek-dev] Making changes to robotd directory
In-Reply-To: <20060509153703.82002.qmail@web35315.mail.mud.yahoo.com>
References: <20060509064700.GF10543@us.netrek.org>
	<20060509153703.82002.qmail@web35315.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605091445q290e020ap634ce30129371ddc@mail.gmail.com>

On 5/10/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Thanks for the quick darcs intro.
>
> Some quick mentions. This has probably have to do with
> darcs more than netrek but:
>
> I had to:
>
> chmod u+x configure
> chmod u+x tools/mktrekon

Yes, this is unfortunate. This is now mentioned in the new file
Vanilla/README.darcs, which doubles as a shell script which will
correct the problem.

> to get the configure to work, and subsequently the
> make install to work.
>
> Quick question:
> I imagine darcs record, then darcs send.
>
> Sends the whole tree.
>
> Is there a way to do this only to a single directory
> like the robotd directory or a single file?

Darcs record makes a patch file, and records it in _darcs/patches/.

Darcs send will send only the unsent patches.

There have been two patches sent to the list in the last 24 hours,
look for attachments named
something-with-a-lengthy-and-hyphenated-name.dpatch. You'll see that
the patches are quite short, and are actually shorter than preparing
unified diffs.
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Tue May  9 18:08:44 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 10 May 2006 09:08:44 +1000
Subject: [netrek-dev] Making changes to robotd directory
In-Reply-To: <20060509153703.82002.qmail@web35315.mail.mud.yahoo.com>
References: <20060509064700.GF10543@us.netrek.org>
	<20060509153703.82002.qmail@web35315.mail.mud.yahoo.com>
Message-ID: <20060509230844.GB5849@us.netrek.org>

In addition to what Stephen said ... here's my comments.

On Tue, May 09, 2006 at 08:37:03AM -0700, Jimmy Huang wrote:
> Quick question:
> I imagine darcs record, then darcs send. 
> Sends the whole tree. 

Yeah, I thought that for about a minute, until I tested a darcs "get"
and found that darcs maintained a pristine copy.  So the "record" and
"send" are diffs against this pristine copy kept locally.  In a manner
of speaking.

One trick to really learn this stuff quickly is to do a darcs "get" then
recursive copy the tree *twice* to some other place (/tmp), and then do
darcs operations between the two temporary copies, imagining that one is
yours and one is someone else's.

Things to remember are:

- that a "push" can operate over SSH or local filesystem, and that a
  "send" is a "push" over e-mail.

- that a "get" is the initial "pull", and includes the effects of
  "init",

- that a "pull" can operate over SSH, local filesystem, and HTTP,

- that an "apply" is the e-mail transport equivalent of "pull".

> Is there a way to do this only to a single directory
> like the robotd directory or a single file? 

Yes.  Had to do this myself last night, when my repository contained
unrecorded changes to several files but I wanted the changes to go as
separate patches.  Just add the file names to the "record".

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


From jimmyhua73 at yahoo.com  Tue May  9 20:34:32 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 9 May 2006 18:34:32 -0700 (PDT)
Subject: [netrek-dev] Making changes to robotd directory
In-Reply-To: <20060509230844.GB5849@us.netrek.org>
Message-ID: <20060510013432.18150.qmail@web35308.mail.mud.yahoo.com>

Hmm, 
  
  I just realized, I don't have e-mail setup on my linux box. hmmm. 
  
  I just did a 
  
  darcs send
  
  followed the instructions, and it seemed to go through okay. 
  
  Anyone see it? It's named "cloakbombing"
  
  If not, I just edited my bounced e-mail and attached it as above. 
  
  Jimmy

James Cameron <quozl at us.netrek.org> wrote:  In addition to what Stephen said ... here's my comments.

On Tue, May 09, 2006 at 08:37:03AM -0700, Jimmy Huang wrote:
> Quick question:
> I imagine darcs record, then darcs send. 
> Sends the whole tree. 

Yeah, I thought that for about a minute, until I tested a darcs "get"
and found that darcs maintained a pristine copy.  So the "record" and
"send" are diffs against this pristine copy kept locally.  In a manner
of speaking.

One trick to really learn this stuff quickly is to do a darcs "get" then
recursive copy the tree *twice* to some other place (/tmp), and then do
darcs operations between the two temporary copies, imagining that one is
yours and one is someone else's.

Things to remember are:

- that a "push" can operate over SSH or local filesystem, and that a
  "send" is a "push" over e-mail.

- that a "get" is the initial "pull", and includes the effects of
  "init",

- that a "pull" can operate over SSH, local filesystem, and HTTP,

- that an "apply" is the e-mail transport equivalent of "pull".

> Is there a way to do this only to a single directory
> like the robotd directory or a single file? 

Yes.  Had to do this myself last night, when my repository contained
unrecorded changes to several files but I wanted the changes to go as
separate patches.  Just add the file names to the "record".

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060509/0c3c3af8/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cloakbombing
Type: application/octet-stream
Size: 11099 bytes
Desc: 537049707-cloakbombing
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060509/0c3c3af8/attachment.obj 

From jimmyhua73 at yahoo.com  Tue May  9 20:39:27 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 9 May 2006 18:39:27 -0700 (PDT)
Subject: [netrek-dev] Making changes to robotd directory
Message-ID: <20060510013927.35132.qmail@web35303.mail.mud.yahoo.com>

Okay, 
  
  I'm sure that won't work either. I guess i need to get e-mail working on my linux box....
  
  instead, let me attach assault.c which should go into the "robotd" directory. 
  
  Makes bots cloak while bombing enemy home world even when no enemy is around. This makes for more successful bombing. 
  
  Jimmy
  

Jimmy Huang <jimmyhua73 at yahoo.com> wrote:  Hmm, 
  
  I just realized, I don't have e-mail setup on my linux box. hmmm. 
  
  I just did a 
  
  darcs send
  
  followed the instructions, and it seemed to go through okay. 
  
  Anyone see it? It's named "cloakbombing"
  
  If not, I just edited my bounced e-mail and attached it as above. 
  
  Jimmy

James Cameron <quozl at us.netrek.org> wrote:  In addition to what Stephen said ... here's my comments.

On Tue, May 09, 2006 at 08:37:03AM -0700, Jimmy Huang wrote:
> Quick question:
> I imagine darcs record, then darcs send. 
> Sends the whole tree. 

Yeah, I thought that for about a minute, until I tested a darcs "get"
and found that darcs maintained a pristine copy.  So the "record" and
"send" are diffs against this pristine copy kept locally.  In a   manner
of speaking.

One trick to really learn this stuff quickly is to do a darcs "get" then
recursive copy the tree *twice* to some other place (/tmp), and then do
darcs operations between the two temporary copies, imagining that one is
yours and one is someone else's.

Things to remember are:

- that a "push" can operate over SSH or local filesystem, and that a
  "send" is a "push" over e-mail.

- that a "get" is the initial "pull", and includes the effects of
  "init",

- that a "pull" can operate over SSH, local filesystem, and HTTP,

- that an "apply" is the e-mail transport equivalent of "pull".

> Is there a way to do this only to a single directory
> like the robotd directory or a single file? 

Yes.  Had to do this myself last night, when my repository contained
unrecorded changes to several files but I wanted the changes to go as
separate patches.  Just add the file names to the   "record".

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060509/239c6dec/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assault.c
Type: application/octet-stream
Size: 11820 bytes
Desc: 2878784584-assault.c
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060509/239c6dec/attachment-0001.obj 

From stephen.thorne at gmail.com  Tue May  9 20:41:56 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 10 May 2006 11:41:56 +1000
Subject: [netrek-dev] Making changes to robotd directory
In-Reply-To: <20060510013432.18150.qmail@web35308.mail.mud.yahoo.com>
References: <20060509230844.GB5849@us.netrek.org>
	<20060510013432.18150.qmail@web35308.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605091841m3fe0ff06ra8841b3ea4b26a62@mail.gmail.com>

On 5/10/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>  Anyone see it? It's named "cloakbombing"
>
>  If not, I just edited my bounced e-mail and attached it as above.

Ahh, I've had this exact problem on a locked down host at my workplace.

The two things you can do in this situation are:

Publish the entire repository on a webserver. This is quite easy.

darcs put username at hostname:public_html/netrek-server

or!

darcs send -o cloakbombing.dpatch

and attach cloackbombing.dpatch to an email.

The patch you sent through had mime headers around it, so it broke.
And it seems to have been linewrapped by an email client, I can't get
it to apply.
--
Stephen Thorne
Development Engineer


From jimmyhua73 at yahoo.com  Tue May  9 22:31:51 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 9 May 2006 20:31:51 -0700 (PDT)
Subject: [netrek-dev] first patch to robotd
In-Reply-To: <3e8ca5c80605091841m3fe0ff06ra8841b3ea4b26a62@mail.gmail.com>
Message-ID: <20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>

Okay!

First darcs patch! Thanks Stephen for your advice. 

The ->

darcs send -o cloakbombing.dpatch 

worked. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cloakbombing.dpatch
Type: application/octet-stream
Size: 9806 bytes
Desc: 375927154-cloakbombing.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060509/3e31417d/attachment.obj 

From stephen.thorne at gmail.com  Tue May  9 22:55:29 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 10 May 2006 13:55:29 +1000
Subject: [netrek-dev] first patch to robotd
In-Reply-To: <20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>
References: <3e8ca5c80605091841m3fe0ff06ra8841b3ea4b26a62@mail.gmail.com>
	<20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605092055q86a912dsd5330508268008f9@mail.gmail.com>

On 5/10/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> First darcs patch! Thanks Stephen for your advice.

Great. This patch has been accepted and is available from
www.netrek.org/repos/netrek-server :)
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Tue May  9 23:10:38 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 10 May 2006 14:10:38 +1000
Subject: [netrek-dev] first patch to robotd
In-Reply-To: <20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>
References: <3e8ca5c80605091841m3fe0ff06ra8841b3ea4b26a62@mail.gmail.com>
	<20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>
Message-ID: <20060510041038.GI5849@us.netrek.org>

That's great.

But it doesn't take into account the possibility of home planets being
moved, such as using the PLANETS setting in etc/sysdef, or positioning
as part of a scenario.

Unless anyone else volunteers, I might change it to check for proximity
to any of the known home planets.

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


From netrek at gmail.com  Tue May  9 23:15:20 2006
From: netrek at gmail.com (Zach)
Date: Wed, 10 May 2006 00:15:20 -0400
Subject: [netrek-dev] first patch to robotd
In-Reply-To: <3e8ca5c80605092055q86a912dsd5330508268008f9@mail.gmail.com>
References: <3e8ca5c80605091841m3fe0ff06ra8841b3ea4b26a62@mail.gmail.com>
	<20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>
	<3e8ca5c80605092055q86a912dsd5330508268008f9@mail.gmail.com>
Message-ID: <ecfa260c0605092115q635b98d5xe9c6876963820efe@mail.gmail.com>

On 5/9/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
> Great. This patch has been accepted and is available from
> www.netrek.org/repos/netrek-server :)


From bogus@does.not.exist.com  Thu May  4 10:41:37 2006
From: bogus@does.not.exist.com ()
Date: Thu, 04 May 2006 15:41:37 -0000
Subject: No subject
Message-ID: <mailman.58.1147234540.21895.netrek-dev@us.netrek.org>

Zach


From quozl at us.netrek.org  Wed May 10 07:29:26 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 10 May 2006 22:29:26 +1000
Subject: [netrek-dev] first patch to robotd
In-Reply-To: <20060510041038.GI5849@us.netrek.org>
References: <3e8ca5c80605091841m3fe0ff06ra8841b3ea4b26a62@mail.gmail.com>
	<20060510033151.83411.qmail@web35311.mail.mud.yahoo.com>
	<20060510041038.GI5849@us.netrek.org>
Message-ID: <20060510122926.GB21118@us.netrek.org>

The following patch (from my repository) builds on Jimmy's work and
takes into account home planets that may have been moved as part of a
scenario, or where new home planets are nominated by the PLANETS setting
in etc/sysdef.

I've tested this to my satisfaction, by running a game with the robots
and using xsg to move things around.

One thing I did notice, which I'm calling for help on from anyone who
knows the code better ... is that the robots would stop concentrating on
the enemy planets in favour of the third space planets, if those third
space planets were within range of them.

Move a few Orion planets to the front between Romulan and Federation,
and the robots just orbit them with shields down, presumably trying to
bomb, and dying.

I think I've seen this in situations with unmodified planet positions.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
Wed May 10 17:31:41 EST 2006  quozl at us.netrek.org
  * robots to cloak near any home planet
  Factorised the decision of what makes a res death risk, and included a
  check for proximity to any home planet.  Used ntserv/enter.c and max
  phaser distance to determine a rectangular area of risk.
diff -rN -u old-netrek-server/Vanilla/NEWS new-netrek-server/Vanilla/NEWS
--- old-netrek-server/Vanilla/NEWS	2006-05-10 22:16:31.000000000 +1000
+++ new-netrek-server/Vanilla/NEWS	2006-05-10 22:16:31.000000000 +1000
@@ -1,3 +1,4 @@
+- fix practice robots to cloak when bombing near home planet [Huang]
 - fix INL confine to knock ships out of orbit [Cameron]
 - describe a local unnamed server as "server on this computer" [Cameron]
 - fix cambot regression [Cameron]
diff -rN -u old-netrek-server/Vanilla/robotd/assault.c new-netrek-server/Vanilla/robotd/assault.c
--- old-netrek-server/Vanilla/robotd/assault.c	2006-05-10 22:16:31.000000000 +1000
+++ new-netrek-server/Vanilla/robotd/assault.c	2006-05-10 22:16:31.000000000 +1000
@@ -43,6 +43,30 @@
    }
 }
 
+/* determine if there is risk of death due to res of opponent */
+static int risk_res_death(struct planet *pl)
+{
+  if (pl == NULL) return 0;
+  /* One of the home planets identified by server etc/sysdef PLANETS */
+  if (pl->pl_flags & PLHOME) return 1;
+  /* Altair in standard position */
+  if (pl->pl_no == 7 && pl->pl_x == 11000 && pl->pl_y == 75000) return 1;
+  /* Draconis in standard position */
+  if (pl->pl_no == 16 && pl->pl_x == 28000 && pl->pl_y == 23000) return 1;
+  /* Scorpii in standard position */
+  if (pl->pl_no == 26 && pl->pl_x == 70720 && pl->pl_y == 26320) return 1;
+  /* Within rectangular phaser distance of any home planet res point */
+  int i;
+  for (i=0,pl=planets;i<MAXPLANETS;i++,pl++) {
+    if (pl->pl_flags & PLHOME) {
+      if(ABS(pl->pl_x - me->p_x) < 12000 && ABS(pl->pl_y - me->p_y) < 12000) {
+	return 1;
+      }
+    }
+  }
+  return 0;
+}
+
 goto_assault_planet()
 {
    Player		*e = _state.closest_e;
@@ -79,17 +103,7 @@
    /* cloak bomb near enemy core, so you don't get res-killed */
 
    if (pdist < 7000) {
-     if (pl && pl->pl_flags&PLHOME)
-       cloak=1;
-
-     if (pl && pl->pl_no == 7) /* Altair */
-       cloak=1;
-
-     if (pl && pl->pl_no == 16) /* Draconis */
-       cloak=1;
-
-     if (pl && pl->pl_no == 26) /* Scorpii */
-       cloak=1;
+     if (risk_res_death(pl)) cloak = 1;
    }
 
    if(pdist < 10000 && edist < 18000)
@@ -174,17 +188,7 @@
    }
 
    /* cloak bomb near enemy core, so you don't get res-killed */
-   if (pl && pl->pl_flags&PLHOME)
-     cloak=1;
-
-   if (pl && pl->pl_no == 7) /* Altair */
-     cloak=1;
-
-   if (pl && pl->pl_no == 16) /* Draconis */
-     cloak=1;
-
-   if (pl && pl->pl_no == 26) /* Scorpii */
-     cloak=1;
+   if (risk_res_death(pl)) cloak = 1;
 
    if(cloak)
       req_cloak_on();

-------------- 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/20060510/2d3932f9/attachment-0001.pgp 

From keyos at keyos.org  Wed May 10 11:46:44 2006
From: keyos at keyos.org (keyos at keyos.org)
Date: Wed, 10 May 2006 19:46:44 +0300 (IDT)
Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4 more)
Message-ID: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>

Wed May 10 19:37:23 IDT 2006  keyos at keyos.org
  * configure-scripts-fix-for-gmp
  Fixed couple of inconsistensies in configure.in templates to detect GMP versions correct

Wed May 10 19:40:29 IDT 2006  keyos at keyos.org
  * libresolv-for-solaris
  solaris applications using gethostbyname functions require libresolv

Wed May 10 19:41:49 IDT 2006  keyos at keyos.org
  * new-autoconf-fix
  newer versions of autoconf do not have AC_OUTPUT_SUBDIRS

Wed May 10 19:43:53 IDT 2006  keyos at keyos.org
  * socket-header-missing

Wed May 10 19:44:15 IDT 2006  keyos at keyos.org
  * metaget-extralibs-fix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 11851 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060510/02dce337/attachment.bin 

From keyos at keyos.org  Wed May 10 11:56:05 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Wed, 10 May 2006 19:56:05 +0300 (IDT)
Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4
 more)
In-Reply-To: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>
References: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>
Message-ID: <Pine.GSO.4.63.0605101953320.19542@fcnep.argivfvba.arg.vy>

I have no idea why this came as one file, but anyway.

The only thing I didn't do was running autoconf to create configure 
scripts for both root and res-rsa directories. I ran them on my comp
and tested that everything works fine. Just don't want to create patch
of configure scripts (Hope Quozl will do that :)

Please, test it on linuxes before adding to repo.

Stas.

On Wed, 10 May 2006, keyos at keyos.org wrote:

> Date: Wed, 10 May 2006 19:46:44 +0300 (IDT)
> From: keyos at keyos.org
> Reply-To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4 more)
> 
> Wed May 10 19:37:23 IDT 2006  keyos at keyos.org
>   * configure-scripts-fix-for-gmp
>   Fixed couple of inconsistensies in configure.in templates to detect GMP versions correct
> 
> Wed May 10 19:40:29 IDT 2006  keyos at keyos.org
>   * libresolv-for-solaris
>   solaris applications using gethostbyname functions require libresolv
> 
> Wed May 10 19:41:49 IDT 2006  keyos at keyos.org
>   * new-autoconf-fix
>   newer versions of autoconf do not have AC_OUTPUT_SUBDIRS
> 
> Wed May 10 19:43:53 IDT 2006  keyos at keyos.org
>   * socket-header-missing
> 
> Wed May 10 19:44:15 IDT 2006  keyos at keyos.org
>   * metaget-extralibs-fix
> 


From stephen.thorne at gmail.com  Wed May 10 16:43:40 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 11 May 2006 07:43:40 +1000
Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4
	more)
In-Reply-To: <Pine.GSO.4.63.0605101953320.19542@fcnep.argivfvba.arg.vy>
References: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>
	<Pine.GSO.4.63.0605101953320.19542@fcnep.argivfvba.arg.vy>
Message-ID: <3e8ca5c80605101443p3717a9acx8cc5d73d2ef29a1c@mail.gmail.com>

On 5/11/06, Stas Pirogov <keyos at keyos.org> wrote:
> I have no idea why this came as one file, but anyway.
>
> The only thing I didn't do was running autoconf to create configure
> scripts for both root and res-rsa directories. I ran them on my comp
> and tested that everything works fine. Just don't want to create patch
> of configure scripts (Hope Quozl will do that :)
>
> Please, test it on linuxes before adding to repo.

Can I get some other people to test this? I've tested it on OSX, and
it causes my build to fail horribly.

Procedure for test is:

# create a branch using local copy
darcs get /path/to/local/netrek-server netrek-server-test-autoconf
# enter the branch
cd netrek-server-test-autoconf
# pull changes to test
darcs pull -a http://shiny.thorne.id.au/~stephen/netrek-server/
cd Vanilla
# create new ./configure file
autoconf
# run the configure, be sure the append the correct flags.
./configure
# make the project
make

--
Stephen Thorne
Development Engineer


From keyos at keyos.org  Wed May 10 17:05:10 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Thu, 11 May 2006 01:05:10 +0300 (IDT)
Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4
 more)
In-Reply-To: <3e8ca5c80605101443p3717a9acx8cc5d73d2ef29a1c@mail.gmail.com>
References: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>
	<Pine.GSO.4.63.0605101953320.19542@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605101443p3717a9acx8cc5d73d2ef29a1c@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.0605110104480.19542@fcnep.argivfvba.arg.vy>

You should also run autoconf under res-rsa folder.

Stas.

On Thu, 11 May 2006, Stephen Thorne wrote:

> Date: Thu, 11 May 2006 07:43:40 +1000
> From: Stephen Thorne <stephen.thorne at gmail.com>
> Reply-To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4
>     more)
> 
> On 5/11/06, Stas Pirogov <keyos at keyos.org> wrote:
> > I have no idea why this came as one file, but anyway.
> >
> > The only thing I didn't do was running autoconf to create configure
> > scripts for both root and res-rsa directories. I ran them on my comp
> > and tested that everything works fine. Just don't want to create patch
> > of configure scripts (Hope Quozl will do that :)
> >
> > Please, test it on linuxes before adding to repo.
> 
> Can I get some other people to test this? I've tested it on OSX, and
> it causes my build to fail horribly.
> 
> Procedure for test is:
> 
> # create a branch using local copy
> darcs get /path/to/local/netrek-server netrek-server-test-autoconf
> # enter the branch
> cd netrek-server-test-autoconf
> # pull changes to test
> darcs pull -a http://shiny.thorne.id.au/~stephen/netrek-server/
> cd Vanilla
> # create new ./configure file
> autoconf
> # run the configure, be sure the append the correct flags.
> ./configure
> # make the project
> make
> 
> --
> Stephen Thorne
> Development Engineer
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 


From quozl at us.netrek.org  Wed May 10 18:05:48 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 11 May 2006 09:05:48 +1000
Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4
	more)
In-Reply-To: <Pine.GSO.4.63.0605110104480.19542@fcnep.argivfvba.arg.vy>
References: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>
	<Pine.GSO.4.63.0605101953320.19542@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605101443p3717a9acx8cc5d73d2ef29a1c@mail.gmail.com>
	<Pine.GSO.4.63.0605110104480.19542@fcnep.argivfvba.arg.vy>
Message-ID: <20060510230548.GA6142@us.netrek.org>

Tests out fine, re-ran autoconf in main and res-rsa.  Log attached.

Had to run README.darcs half way through.  Shows we could do with a
build test.  That's next post.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netrek-server-test-autoconf.log.bz2
Type: application/octet-stream
Size: 13900 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060511/3938aa43/attachment-0001.obj 
-------------- 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/20060511/3938aa43/attachment-0001.pgp 

From stephen.thorne at gmail.com  Wed May 10 18:08:10 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 11 May 2006 09:08:10 +1000
Subject: [netrek-dev] DARCS Discipline
Message-ID: <3e8ca5c80605101608j108f1c7djfdbe9f64c3b6e046@mail.gmail.com>

Hi!

After some experiences with darcs in the last few days, I'm
instituting a few rules about how we handle patches. I want to make
very clear before I detail the rules that the reason I am detailing
these rules is so that I myself don't make the same mistakes again,
and we all have somewhere to refer to for best practice.

Firstly, if code is your own work. Please distribute it via a darcs
patch, either using 'darcs send', 'darcs send
--output=somefile.dpatch' or by publishing it on a respository
accessable via http.

Secondly, if you receieve code via the mailing list that is in a
'unified diff' format, please branch your repository to test the
patch. If you feel the need to use darcs record please do not publish
the dpatch. Wait until a dpatch is sent to the list before applying it
to your main working repository.

Thirdly, if you are unable to use darcs, and want your code to appear
in the upstream darcs repositories, send the unified diff privately to
another person who can use darcs. Don't send it to the list. That
person can create the patch (using --author "youremail at example.com")
in your name, and publish it.

This will (hopefully) resolve problems where two patches have the same
information, and result in a conflict.
--
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Wed May 10 18:08:03 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Thu, 11 May 2006 09:08:03 +1000
Subject: [netrek-dev] darcs patch: tests build
Message-ID: <E1Fdxml-0004xv-Ps@dors.lan>

Thu May 11 09:06:23 EST 2006  quozl at us.netrek.org
  * tests build
  Add script to test the build, creates a copy of the repository, runs
  autoconf, fixes file protection, runs configure, runs make, reports
  success.  Fails as soon as anything goes wrong.  Reports progress.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10490 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060511/ab359e7e/attachment.bin 

From stephen.thorne at gmail.com  Wed May 10 18:40:03 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 11 May 2006 09:40:03 +1000
Subject: [netrek-dev] darcs patch: tests build
In-Reply-To: <E1Fdxml-0004xv-Ps@dors.lan>
References: <E1Fdxml-0004xv-Ps@dors.lan>
Message-ID: <3e8ca5c80605101640u144cbd4bj37218b9e72e21109@mail.gmail.com>

On 5/11/06, quozl at us.netrek.org <quozl at us.netrek.org> wrote:
> Thu May 11 09:06:23 EST 2006  quozl at us.netrek.org
>   * tests build
>   Add script to test the build, creates a copy of the repository, runs
>   autoconf, fixes file protection, runs configure, runs make, reports
>   success.  Fails as soon as anything goes wrong.  Reports progress.

I can't apply this patch,

  * merge quozl 2006-05-10
  This is a merge of Quozl's repository to Jerub's repository, involving
  compilation fixes and miscellaneous other changes.

conflicts with

Thu May 11 07:26:01 EST 2006  quozl at us.netrek.org
  * make robots afraid of res-death, taking into account customised
home planets and such

(both patches contain the same data)

Your patch (tests-build.dpatch) depends on the latter. I've done the
scutwork required, but don't understand *exactly* what effect this
will have.

Try doing a:

darcs pull http://shiny.thorne.id.au/~stephen/netrek-server/

and tell me if anything bad happens.

--
Stephen Thorne
Development Engineer


From jimmyhua73 at yahoo.com  Wed May 10 21:02:19 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 10 May 2006 19:02:19 -0700 (PDT)
Subject: [netrek-dev] first patch to robotd
In-Reply-To: <20060510122926.GB21118@us.netrek.org>
Message-ID: <20060511020219.80826.qmail@web35311.mail.mud.yahoo.com>

Hi James, 
  
  I've seen this problem too.  It's an AI problem and not a coding  problem per se.  So as long as people don't move them planets  around during a pickup game, I think we are okay. 
  
  Many years ago, I used to run 
  
  gdb robot -h localhost
  
  And wait for a segmentation fault. Found quite a few "bugs" (about 5)  that got plugged up. Since this code is really different from what I  worked with. Not sure if I should do that again. 
  
  I'm going to take the Microsoft approach, and add all the features into  the robotd directory in first before I go into de-bugging...
  
  Jimmy
  

James Cameron <quozl at us.netrek.org> wrote:  The following patch (from my repository) builds on Jimmy's work and
takes into account home planets that may have been moved as part of a
scenario, or where new home planets are nominated by the PLANETS setting
in etc/sysdef.

I've tested this to my satisfaction, by running a game with the robots
and using xsg to move things around.

One thing I did notice, which I'm calling for help on from anyone who
knows the code better ... is that the robots would stop concentrating on
the enemy planets in favour of the third space planets, if those third
space planets were within range of them.

Move a few Orion planets to the front between Romulan and Federation,
and the robots just orbit them with shields down, presumably trying to
bomb, and dying.

I think I've seen this in situations with unmodified planet positions.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
Wed May 10 17:31:41 EST 2006  quozl at us.netrek.org
  * robots to cloak near any home planet
  Factorised the decision of what makes a res death risk, and included a
  check for proximity to any home planet.  Used ntserv/enter.c and max
  phaser distance to determine a rectangular area of risk.
diff -rN -u old-netrek-server/Vanilla/NEWS new-netrek-server/Vanilla/NEWS
--- old-netrek-server/Vanilla/NEWS 2006-05-10 22:16:31.000000000 +1000
+++ new-netrek-server/Vanilla/NEWS 2006-05-10 22:16:31.000000000 +1000
@@ -1,3 +1,4 @@
+- fix practice robots to cloak when bombing near home planet [Huang]
 - fix INL confine to knock ships out of orbit [Cameron]
 - describe a local unnamed server as "server on this computer" [Cameron]
 - fix cambot regression [Cameron]
diff -rN -u old-netrek-server/Vanilla/robotd/assault.c new-netrek-server/Vanilla/robotd/assault.c
--- old-netrek-server/Vanilla/robotd/assault.c 2006-05-10 22:16:31.000000000 +1000
+++ new-netrek-server/Vanilla/robotd/assault.c 2006-05-10 22:16:31.000000000 +1000
@@ -43,6 +43,30 @@
    }
 }
 
+/* determine if there is risk of death due to res of opponent */
+static int risk_res_death(struct planet *pl)
+{
+  if (pl = NULL) return 0;
+  /* One of the home planets identified by server etc/sysdef PLANETS */
+  if (pl->pl_flags & PLHOME) return 1;
+  /* Altair in standard position */
+  if (pl->pl_no = 7 && pl->pl_x = 11000 && pl->pl_y = 75000) return 1;
+  /* Draconis in standard position */
+  if (pl->pl_no = 16 && pl->pl_x = 28000 && pl->pl_y = 23000) return 1;
+  /* Scorpii in standard position */
+  if (pl->pl_no = 26 && pl->pl_x = 70720 && pl->pl_y = 26320) return 1;
+  /* Within rectangular phaser distance of any home planet res point */
+  int i;
+  for (i=0,pl=planets;i
+    if (pl->pl_flags & PLHOME) {
+      if(ABS(pl->pl_x - me->p_x) < 12000 && ABS(pl->pl_y - me->p_y) < 12000) {
+ return 1;
+      }
+    }
+  }
+  return 0;
+}
+
 goto_assault_planet()
 {
    Player  *e @@ -79,17 +103,7 @@
    /* cloak bomb near enemy core, so you don't get res-killed */
 
    if (pdist < 7000) {
-     if (pl && pl->pl_flags&PLHOME)
-       cloak=1;
-
-     if (pl && pl->pl_no = 7) /* Altair */
-       cloak=1;
-
-     if (pl && pl->pl_no = 16) /* Draconis */
-       cloak=1;
-
-     if (pl && pl->pl_no = 26) /* Scorpii */
-       cloak=1;
+     if (risk_res_death(pl)) cloak     }
 
    if(pdist < 10000 && edist < 18000)
@@ -174,17 +188,7 @@
    }
 
    /* cloak bomb near enemy core, so you don't get res-killed */
-   if (pl && pl->pl_flags&PLHOME)
-     cloak=1;
-
-   if (pl && pl->pl_no = 7) /* Altair */
-     cloak=1;
-
-   if (pl && pl->pl_no = 16) /* Draconis */
-     cloak=1;
-
-   if (pl && pl->pl_no = 26) /* Scorpii */
-     cloak=1;
+   if (risk_res_death(pl)) cloak  
    if(cloak)
       req_cloak_on();

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060510/9f197d4f/attachment-0001.htm 

From netrek at gmail.com  Wed May 10 22:47:37 2006
From: netrek at gmail.com (Zach)
Date: Wed, 10 May 2006 23:47:37 -0400
Subject: [netrek-dev] darcs patch: configure-scripts-fix-for-gmp (and 4
	more)
In-Reply-To: <3e8ca5c80605101443p3717a9acx8cc5d73d2ef29a1c@mail.gmail.com>
References: <200605101646.k4AGkiHi019756@sparc.netvision.net.il>
	<Pine.GSO.4.63.0605101953320.19542@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605101443p3717a9acx8cc5d73d2ef29a1c@mail.gmail.com>
Message-ID: <ecfa260c0605102047m4eb02454h444196841cea22f0@mail.gmail.com>

On 5/10/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
>
> Procedure for test is:
>
> # create a branch using local copy
> darcs get /path/to/local/netrek-server netrek-server-test-autoconf

netrek-server-test-autoconf is where we have cp'd over our local repo right?

zach


From netrek at gmail.com  Wed May 10 22:51:49 2006
From: netrek at gmail.com (Zach)
Date: Wed, 10 May 2006 23:51:49 -0400
Subject: [netrek-dev] darcs patch: tests build
In-Reply-To: <ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>
References: <E1Fdxml-0004xv-Ps@dors.lan>
	<3e8ca5c80605101640u144cbd4bj37218b9e72e21109@mail.gmail.com>
	<ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>
Message-ID: <ecfa260c0605102051i5eccc884t9b1dc6c12272ad58@mail.gmail.com>

On 5/10/06, Zach <netrek at gmail.com> wrote:
> Can we have one main darcs repo where regular developers pull from?
> I don't know where to pull from Quozl's or Jerub's or the netrek.org one!

s/"know where"/"know whether"

Zach


From netrek at gmail.com  Wed May 10 22:51:09 2006
From: netrek at gmail.com (Zach)
Date: Wed, 10 May 2006 23:51:09 -0400
Subject: [netrek-dev] darcs patch: tests build
In-Reply-To: <3e8ca5c80605101640u144cbd4bj37218b9e72e21109@mail.gmail.com>
References: <E1Fdxml-0004xv-Ps@dors.lan>
	<3e8ca5c80605101640u144cbd4bj37218b9e72e21109@mail.gmail.com>
Message-ID: <ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>

Can we have one main darcs repo where regular developers pull from?
I don't know where to pull from Quozl's or Jerub's or the netrek.org one!

Zach


From stephen.thorne at gmail.com  Wed May 10 23:06:14 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 11 May 2006 14:06:14 +1000
Subject: [netrek-dev] darcs patch: tests build
In-Reply-To: <ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>
References: <E1Fdxml-0004xv-Ps@dors.lan>
	<3e8ca5c80605101640u144cbd4bj37218b9e72e21109@mail.gmail.com>
	<ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>
Message-ID: <3e8ca5c80605102106t1ea8db2btd7986da8c422c270@mail.gmail.com>

On 5/11/06, Zach <netrek at gmail.com> wrote:
> Can we have one main darcs repo where regular developers pull from?
> I don't know where to pull from Quozl's or Jerub's or the netrek.org one!

yes

-- 
Stephen Thorne
Development Engineer


From ahn at orion.netrek.org  Wed May 10 23:06:06 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 11 May 2006 00:06:06 -0400
Subject: [netrek-dev] Legacy netrek home page back up
Message-ID: <20060511040606.GA7773@orion.netrek.org>

The old Netrek Home Page content is now available again at
http://genocide.netrek.org/.  Please let me know if there are any
problems.


From quozl at us.netrek.org  Wed May 10 23:53:21 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 11 May 2006 14:53:21 +1000
Subject: [netrek-dev] darcs patch: tests build
In-Reply-To: <ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>
References: <E1Fdxml-0004xv-Ps@dors.lan>
	<3e8ca5c80605101640u144cbd4bj37218b9e72e21109@mail.gmail.com>
	<ecfa260c0605102051l58764970xf369e159586876af@mail.gmail.com>
Message-ID: <20060511045321.GB6142@us.netrek.org>

On Wed, May 10, 2006 at 11:51:09PM -0400, Zach wrote:
> Can we have one main darcs repo where regular developers pull from?

Yes.

> I don't know where to pull from Quozl's or Jerub's or the netrek.org
> one!

See the SourceControl page in the Wiki.

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


From keyos at keyos.org  Thu May 11 05:19:31 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Thu, 11 May 2006 13:19:31 +0300 (IDT)
Subject: [netrek-dev] Legacy netrek home page back up
In-Reply-To: <20060511040606.GA7773@orion.netrek.org>
References: <20060511040606.GA7773@orion.netrek.org>
Message-ID: <Pine.GSO.4.63.0605111318030.21831@fcnep.argivfvba.arg.vy>

This 'old' content is so much better than current one that
I can't even describe it in words.
This is how netrek site should look.

Stas.

On Thu, 11 May 2006, Dave Ahn wrote:

> Date: Thu, 11 May 2006 00:06:06 -0400
> From: Dave Ahn <ahn at orion.netrek.org>
> Reply-To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> To: netrek-dev at us.netrek.org
> Subject: [netrek-dev] Legacy netrek home page back up
> 
> The old Netrek Home Page content is now available again at
> http://genocide.netrek.org/.  Please let me know if there are any
> problems.
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 


From jimmyhua73 at yahoo.com  Thu May 11 09:52:29 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 11 May 2006 07:52:29 -0700 (PDT)
Subject: [netrek-dev] 2nd patch to robotd update_players.c modified
Message-ID: <20060511145229.36182.qmail@web35301.mail.mud.yahoo.com>

Okay, 

This time, 2 files were modified, robot.h and
update_players.c 

Also, upon request, all my e-mails are sent out in
plain text without the html markup.  (I changed a
setting in yahoo, hopefully this works). 


Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_players.dpatch
Type: application/octet-stream
Size: 11971 bytes
Desc: 5019372-update_players.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060511/3fc59abf/attachment-0001.obj 

From jimmyhua73 at yahoo.com  Thu May 11 10:15:29 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 11 May 2006 08:15:29 -0700 (PDT)
Subject: [netrek-dev] 3rd patch to robotd decide_ogg patch
Message-ID: <20060511151529.63006.qmail@web35302.mail.mud.yahoo.com>

Added about 3 lines to decide.c

But Oh! What a world of difference!

This doesn't work well, without the help of the
previous update_players patch though. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decide_ogg.dpatch
Type: application/octet-stream
Size: 11081 bytes
Desc: 2589925698-decide_ogg.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060511/fb422c13/attachment.obj 

From xyzzy at speakeasy.org  Thu May 11 15:36:44 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 11 May 2006 13:36:44 -0700 (PDT)
Subject: [netrek-dev] 2nd patch to robotd update_players.c modified
In-Reply-To: <20060511145229.36182.qmail@web35301.mail.mud.yahoo.com>
References: <20060511145229.36182.qmail@web35301.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605111335460.9109@shell2.speakeasy.net>

If you change your login to be Robot! you won't get ogged bot the bots.
Use the robot flag instead.


From stephen.thorne at gmail.com  Thu May 11 15:51:55 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 12 May 2006 06:51:55 +1000
Subject: [netrek-dev] 3rd patch to robotd decide_ogg patch
In-Reply-To: <20060511151529.63006.qmail@web35302.mail.mud.yahoo.com>
References: <20060511151529.63006.qmail@web35302.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605111351m105e07e9gb9c29d3a3b34f84@mail.gmail.com>

On 5/12/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Added about 3 lines to decide.c
>
> But Oh! What a world of difference!
>
> This doesn't work well, without the help of the
> previous update_players patch though.

Patch taken.

-- 
Stephen Thorne
Development Engineer


From stephen.thorne at gmail.com  Thu May 11 15:53:47 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 12 May 2006 06:53:47 +1000
Subject: [netrek-dev] 2nd patch to robotd update_players.c modified
In-Reply-To: <20060511145229.36182.qmail@web35301.mail.mud.yahoo.com>
References: <20060511145229.36182.qmail@web35301.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605111353k53367354j8d92e88fba4430ff@mail.gmail.com>

On 5/12/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Okay,
>
> This time, 2 files were modified, robot.h and
> update_players.c
>
> Also, upon request, all my e-mails are sent out in
> plain text without the html markup.  (I changed a
> setting in yahoo, hopefully this works).

Can you make the changes that Trent suggests, and record a second patch please?

(don't unrecord or amend-record, record a new one)
-- 
Stephen Thorne
Development Engineer


From quozl at us.netrek.org  Thu May 11 17:40:09 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 12 May 2006 08:40:09 +1000
Subject: [netrek-dev] Legacy netrek home page back up
In-Reply-To: <Pine.GSO.4.63.0605111318030.21831@fcnep.argivfvba.arg.vy>
References: <20060511040606.GA7773@orion.netrek.org>
	<Pine.GSO.4.63.0605111318030.21831@fcnep.argivfvba.arg.vy>
Message-ID: <20060511224009.GB6151@us.netrek.org>

On Thu, May 11, 2006 at 01:19:31PM +0300, Stas Pirogov wrote:
> This 'old' content is so much better than current one that
> I can't even describe it in words.
> This is how netrek site should look.

But some of it is out of date.  Code talks.  Are you volunteering?
Until the Wiki is available, the current content is maintained with
darcs.  I'll take patches to add back features of the old content, now
that we have it available.

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


From stephen.thorne at gmail.com  Thu May 11 17:56:12 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 12 May 2006 08:56:12 +1000
Subject: [netrek-dev] New ship artwork!
Message-ID: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>

This is a demo of the new ship artwork, with all the ships from all
the teams (rom, fed, ori, kli, iggy) on parade.

The artwork is by Pascal, and is licensed under a creative commons
attribution license.

http://shiny.thorne.id.au/~stephen/ships.jpg


-- 
Stephen Thorne
Development Engineer


From jimmyhua73 at yahoo.com  Thu May 11 18:11:01 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 11 May 2006 16:11:01 -0700 (PDT)
Subject: [netrek-dev] 2nd patch to robotd update_players.c modified
In-Reply-To: <3e8ca5c80605111353k53367354j8d92e88fba4430ff@mail.gmail.com>
Message-ID: <20060511231101.33995.qmail@web35304.mail.mud.yahoo.com>

sure, 

I'll do a darcs record, darcs send. 

I'll call this a rbotd security patch...

Jimmy

--- Stephen Thorne <stephen.thorne at gmail.com> wrote:

> On 5/12/06, Jimmy Huang <jimmyhua73 at yahoo.com>
> wrote:
> > Okay,
> >
> > This time, 2 files were modified, robot.h and
> > update_players.c
> >
> > Also, upon request, all my e-mails are sent out in
> > plain text without the html markup.  (I changed a
> > setting in yahoo, hopefully this works).
> 
> Can you make the changes that Trent suggests, and
> record a second patch please?
> 
> (don't unrecord or amend-record, record a new one)
> -- 
> Stephen Thorne
> Development Engineer
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From jrd at gerdesas.com  Thu May 11 18:15:34 2006
From: jrd at gerdesas.com (John R. Dennison)
Date: Thu, 11 May 2006 18:15:34 -0500
Subject: [netrek-dev] New ship artwork!
In-Reply-To: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>
References: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>
Message-ID: <20060511231534.GA10251@gerdesas.gerdesas.com>

On Fri, May 12, 2006 at 08:56:12AM +1000, Stephen Thorne wrote:
> This is a demo of the new ship artwork, with all the ships from all
> the teams (rom, fed, ori, kli, iggy) on parade.
> 
> The artwork is by Pascal, and is licensed under a creative commons
> attribution license.
> 
> http://shiny.thorne.id.au/~stephen/ships.jpg

	Wow.  That's about all I can say.  Simply, wow.

	Very nice job, Pascal.

	Am I correct in assuming that the last set are iggy's




						John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt


From stephen.thorne at gmail.com  Thu May 11 18:22:04 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 12 May 2006 09:22:04 +1000
Subject: [netrek-dev] New ship artwork!
In-Reply-To: <20060511231534.GA10251@gerdesas.gerdesas.com>
References: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>
	<20060511231534.GA10251@gerdesas.gerdesas.com>
Message-ID: <3e8ca5c80605111622x696e8ce5h8ed12d009197027f@mail.gmail.com>

On 5/12/06, John R. Dennison <jrd at gerdesas.com> wrote:
>         Am I correct in assuming that the last set are iggy's

Yes, the last set are iggys.

I'm thinking about introducing a game mode where you get attacked by
wave after wave of iggys. Now that I've seen the artwork, once we get
a client using that art, I want to do it so much more desperately. :))

-- 
Stephen Thorne
Development Engineer


From niclas at acc.umu.se  Thu May 11 18:25:34 2006
From: niclas at acc.umu.se (Niclas Fredriksson)
Date: Fri, 12 May 2006 01:25:34 +0200 (MEST)
Subject: [netrek-dev] New ship artwork!
In-Reply-To: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>
References: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0605120124230.24523@shaka.acc.umu.se>

On Fri, 12 May 2006, Stephen Thorne wrote:

> This is a demo of the new ship artwork, with all the ships from all
> the teams (rom, fed, ori, kli, iggy) on parade.
>
> The artwork is by Pascal, and is licensed under a creative commons
> attribution license.
>
> http://shiny.thorne.id.au/~stephen/ships.jpg

What's the order of the ships?

--Niclas


From ahn at orion.netrek.org  Thu May 11 18:34:17 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 11 May 2006 19:34:17 -0400
Subject: [netrek-dev] Call for help on Netrek Wiki
In-Reply-To: <20060511224009.GB6151@us.netrek.org>
References: <20060511040606.GA7773@orion.netrek.org>
	<Pine.GSO.4.63.0605111318030.21831@fcnep.argivfvba.arg.vy>
	<20060511224009.GB6151@us.netrek.org>
Message-ID: <20060511233417.GA9693@orion.netrek.org>

On Fri, May 12, 2006 at 08:40:09AM +1000, James Cameron wrote:
> 
> Until the Wiki is available, the current content is maintained with
> darcs.  I'll take patches to add back features of the old content, now
> that we have it available.

Actually, the Netrek Wiki is almost ready to go.  I am placing a call
for volunteers who are interested in being Netrek Wiki Editors.  These
editors would be take the lead in maintaining some degree of order as we
add content to the wiki.  An editor may choose to limit his role to a
subset of content (say, if you want to publish pages related only to a
Netrek software package you maintain).  Of course, you do not need to be
an editor to contribute or maintain content.  As with other wikis,
nearly all content will be editable by anyone.

This call for help will stay open for until about May 18 while I try to
coordinate the initial efforts.  Please contact me directly at
ahn AT romulus.netrek.org if you wish to help.  Thanks.

Dave



From ahn at orion.netrek.org  Thu May 11 18:37:34 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 11 May 2006 19:37:34 -0400
Subject: [netrek-dev] New ship artwork!
In-Reply-To: <Pine.GSO.4.64.0605120124230.24523@shaka.acc.umu.se>
References: <3e8ca5c80605111556j61d894c3obae44308fb7ae38b@mail.gmail.com>
	<Pine.GSO.4.64.0605120124230.24523@shaka.acc.umu.se>
Message-ID: <20060511233734.GA9739@orion.netrek.org>

> On Fri, 12 May 2006, Stephen Thorne wrote:
> 
> > The artwork is by Pascal, and is licensed under a creative commons
> > attribution license.
> >
> > http://shiny.thorne.id.au/~stephen/ships.jpg

This is quite nice.  Is Pascal a graphics artist?



From jimmyhua73 at yahoo.com  Thu May 11 19:33:32 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 11 May 2006 17:33:32 -0700 (PDT)
Subject: [netrek-dev] 2nd patch to robotd update_players.c modified
In-Reply-To: <Pine.LNX.4.58.0605111335460.9109@shell2.speakeasy.net>
Message-ID: <20060512003332.7887.qmail@web35301.mail.mud.yahoo.com>

Hello, 

I was looking at

if (j->p_flags & PFROBOT) 

However, none of the bots are marked as a robot except
for Merlin. 

I was thinking about getting the ntserv to mark the
robots as bots when they come in, as they use a
different port and wait queue to come in through.
But...

There's an interesting bug in the current code is that
if you are marked as a robot, you appear invisible
(xsg sees it, but to a regular client, all you see are
the torps and phasors). 

Also, scattered throughout the bot-code, the bots are
programmed to ignore server bots, which have the flag
PFROBOT. 

Bottom line, this isn't as easy as I thought it would
be. 

The only easy solution I can think of for now, is to
not allow people coming in with a "robot!" login. But
allow it, if it is coming from the right port 3592 and
IP address (the local computer), IP address and port
to be set by the ports file. 

This involves changing the ntserv code. I'll look into
it. 

Jimmy



--- Trent Piepho <xyzzy at speakeasy.org> wrote:

> If you change your login to be Robot! you won't get
> ogged by the bots.
> Use the robot flag instead.
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From jimmyhua73 at yahoo.com  Thu May 11 20:40:02 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 11 May 2006 18:40:02 -0700 (PDT)
Subject: [netrek-dev] 2nd patch to robotd update_players.c modified
In-Reply-To: <Pine.GSO.4.58.0605111808590.7902@clyde>
Message-ID: <20060512014002.79455.qmail@web35313.mail.mud.yahoo.com>

It turns out, even newbie.c (aka Merlin),
differentiates between robots and humans based on the
login name "robot!" 

If you are logged in with login name of "robot!" you
stand the risk of getting kicked out for a real
player. 

If you are the real player logged in, Merlin will kick
everyone out thinking there are only robots in the
game. 

PFPRACTR -> practise robot.  Only robot that gets
tagged with this is the robot that comes out when you
press '*' to send in a practise robot. 

PFBPROBOT -> base practise robot, newbie-server,
robot, etc. 

Hey! U R onto something here! 

I looked through all of the current vanilla code, and
there's only one mention of PFBPROBOT in
ntserv/socket.c .

So, it looks like someone did want to try to tag all
basepractise and newbie robots with a PFBPROBOT flag,
but most of the rest of the code isn't there yet. 

Jimmy

--- William Balcerski <williamb at its.caltech.edu>
wrote:

> There's 2 other robot flags, PFPRACTR and PFBPROBOT,
> maybe one of those
> could be used?
> Bill
> 



From jimmyhua73 at yahoo.com  Thu May 11 21:17:08 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 11 May 2006 19:17:08 -0700 (PDT)
Subject: [netrek-dev] robotd-newbie security patch.
Message-ID: <20060512021708.10527.qmail@web35304.mail.mud.yahoo.com>


This patch modifies ntserv/getentry.c to not allow
players with "robot!" loginname. 

It's a temporary fix, until we can write code in to ID
newbie and basepractise robots using the PFBPROBOT
flag. Also need to re-write newbie.c and various
robotd/* code to use this flag, once the flag is
implemented. 

Also modifies docs/sample_ports to only allow
127.0.0.1 connections into 3592 so only localhost
robots can join the newbie game. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: disallowfakebot.dpatch
Type: application/octet-stream
Size: 11435 bytes
Desc: 3606172645-disallowfakebot.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060511/8afae164/attachment.obj 

From quozl at us.netrek.org  Thu May 11 22:05:49 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 12 May 2006 13:05:49 +1000
Subject: [netrek-dev] robotd-newbie security patch.
In-Reply-To: <20060512021708.10527.qmail@web35304.mail.mud.yahoo.com>
References: <20060512021708.10527.qmail@web35304.mail.mud.yahoo.com>
Message-ID: <20060512030549.GD6151@us.netrek.org>

I'm at a loss as to how a server can discriminate between robotd
connections and clients ... unless we look at source IP address or the
process id's started by the control logic.

I don't think username checking is appropriate, but I agree it's a good
start.  Let us know how you go.

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


From quozl at us.netrek.org  Thu May 11 22:30:38 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 12 May 2006 13:30:38 +1000
Subject: [netrek-dev] SourceForge CVS Host Name Change
Message-ID: <20060512033038.GA13805@us.netrek.org>

SourceForge have announced a change to the host name for the Netrek
project; from cvs.sourceforge.net to netrek.cvs.sourceforge.net ...
which is incidentally a reversal of a change some years ago, if I recall
correctly.

To change your repository, consider the attached shell script.  It looks
through the CVS/Root files and changes the host name.  Do this on a copy
of your repository (cp -pr), then try a "cvs update".  If you omit the
-p on cp then CVS will try to check all the files (on the grounds that
the time ahs changed).

netrek.cvs.sourceforge.net is currently prompting me for my password,
and evidence suggests my home directory is not visible to it.  But it
updated fine.

Remember that server development is still moving to darcs at the end of
month release.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netrek-cvs-host-name-2006-10-12.sh
Type: application/x-sh
Size: 280 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060512/894ec701/attachment.sh 
-------------- 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/20060512/894ec701/attachment.pgp 

From xyzzy at speakeasy.org  Thu May 11 23:03:06 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 11 May 2006 21:03:06 -0700 (PDT)
Subject: [netrek-dev] robotd-newbie security patch.
In-Reply-To: <20060512030549.GD6151@us.netrek.org>
References: <20060512021708.10527.qmail@web35304.mail.mud.yahoo.com>
	<20060512030549.GD6151@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605112059180.20216@shell3.speakeasy.net>

On Fri, 12 May 2006, James Cameron wrote:
> I'm at a loss as to how a server can discriminate between robotd
> connections and clients ... unless we look at source IP address or the
> process id's started by the control logic.

There is a packet that robots can send, which sets the flag.  OGGV is the name
I think.  Just have the robots send this packet so they are marked.  Non-borg
clients won't be able to mark themselves this way.


From quozl at us.netrek.org  Thu May 11 23:36:38 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 12 May 2006 14:36:38 +1000
Subject: [netrek-dev] robotd-newbie security patch.
In-Reply-To: <Pine.LNX.4.58.0605112059180.20216@shell3.speakeasy.net>
References: <20060512021708.10527.qmail@web35304.mail.mud.yahoo.com>
	<20060512030549.GD6151@us.netrek.org>
	<Pine.LNX.4.58.0605112059180.20216@shell3.speakeasy.net>
Message-ID: <20060512043638.GE6151@us.netrek.org>

On Thu, May 11, 2006 at 09:03:06PM -0700, Trent Piepho wrote:
> There is a packet that robots can send, which sets the flag.  OGGV is
> the name I think.  Just have the robots send this packet so they are
> marked.  Non-borg clients won't be able to mark themselves this way.

The packet could easily be forged.  I don't think it's a major risk
though ... as in what possible use would people have for marking
themselves as a robot?

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


From quozl at us.netrek.org  Wed May 10 02:34:30 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Wed, 10 May 2006 17:34:30 +1000
Subject: [netrek-dev] darcs patch: move voting to site policy (and 8 more)
Message-ID: <E1FdjDK-0005uD-HL@dors.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.

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.

Fri Apr 28 20:30:14 EST 2006  quozl at us.netrek.org
  * fix INL confine for orbiting ships
  This patch fixes INL confine mode so that orbiting ships that are outside
  the confinement boundary are knocked out of orbit.  Without this patch,
  these ships continue to orbit a planet outside confinement, which is
  against the expectation of the captains.

Fri Apr 28 20:42:55 EST 2006  quozl at us.netrek.org
  * describe a local server as on this computer
  This is a refinement to the server multicast discovery that helps clients
  to discover Netrek servers on a local area network.  One such scenario is
  a server running on the same host as the client.  This server will now
  answer with a comment to tell the user that the server is on the same
  computer.

Fri May  5 19:57:34 EST 2006  quozl at us.netrek.org
  * minor progress update

Fri May  5 22:54:25 EST 2006  quozl at us.netrek.org
  * compilation fix to etc/comment switch

Sat May  6 22:43:56 EST 2006  quozl at us.netrek.org
  * synchronise to sourceforge cvs as at 2006-05-06

Wed May 10 17:31:41 EST 2006  quozl at us.netrek.org
  * robots to cloak near any home planet
  Factorised the decision of what makes a res death risk, and included a
  check for proximity to any home planet.  Used ntserv/enter.c and max
  phaser distance to determine a rectangular area of risk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 55861 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060510/5ede4f50/attachment-0001.bin 

From jimmyhua73 at yahoo.com  Sat May 13 02:13:03 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 13 May 2006 00:13:03 -0700 (PDT)
Subject: [netrek-dev] The first newbie patch again.
Message-ID: <20060513071303.97540.qmail@web35310.mail.mud.yahoo.com>

Although the first newbie patch was approved...

It never seemed to have made it into the repository in
www.netrek.org. 

I went ahead and re-downloaded the latest:

darcs get http://www.netrek.org/repos/netrek-server/

Then, manually applied my changes. 

Then did a:

darcs record

and 

darcs send -o newbiepatch.dpatch

Here is the attached file. 

Hopefully, it will make it in netrek.org and stay
there this time. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbiepatch.dpatch
Type: application/octet-stream
Size: 17107 bytes
Desc: 2572907943-newbiepatch.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060513/82c40799/attachment.obj 

From jimmyhua73 at yahoo.com  Sat May 13 02:21:52 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 13 May 2006 00:21:52 -0700 (PDT)
Subject: [netrek-dev] The first newbie patch again.
In-Reply-To: <20060513071303.97540.qmail@web35310.mail.mud.yahoo.com>
Message-ID: <20060513072152.9403.qmail@web35311.mail.mud.yahoo.com>

Use this patch instead. 

I found out what was wrong with the PFBPROBOT flag. 

You need to invoke the robot program with a -g option.
And it starts sending the OggV packet.

Jimmy

--- Jimmy Huang <jimmyhua73 at yahoo.com> wrote:

> Although the first newbie patch was approved...
> 
> It never seemed to have made it into the repository
> in
> www.netrek.org. 
> 
> I went ahead and re-downloaded the latest:
> 
> darcs get http://www.netrek.org/repos/netrek-server/
> 
> Then, manually applied my changes. 
> 
> Then did a:
> 
> darcs record
> 
> and 
> 
> darcs send -o newbiepatch.dpatch
> 
> Here is the attached file. 
> 
> Hopefully, it will make it in netrek.org and stay
> there this time. 
> 
> Jimmy
> > _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From williamb at its.caltech.edu  Sat May 13 02:28:45 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sat, 13 May 2006 02:28:45 -0500
Subject: [netrek-dev] darcs patch: Send planet core flag
Message-ID: <200605130728.k4D7SjOg014475@omen.digital-genesis.com>

Sat May 13 02:27:02 CDT 2006  williamb at its.caltech.edu
  * Send planet core flag
  The client could use the server to send whether a planet is flaged as core or not, so as to display different planet bitmaps depending on whether a planet is a core planet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 11243 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060513/4c80b37b/attachment-0001.bin 

From netrek at gmail.com  Sat May 13 03:52:49 2006
From: netrek at gmail.com (Zach)
Date: Sat, 13 May 2006 04:52:49 -0400
Subject: [netrek-dev] Open Source Development with CVS
Message-ID: <ecfa260c0605130152g55d8282au65a2fcea8480b8fe@mail.gmail.com>

The complete book is available for download free:
http://cvsbook.red-bean.com/

Zach


From jimmyhua73 at yahoo.com  Sat May 13 09:13:44 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 13 May 2006 07:13:44 -0700 (PDT)
Subject: [netrek-dev] update_players with PFBPROBOT flag.
Message-ID: <20060513141344.58525.qmail@web35311.mail.mud.yahoo.com>

Okay, 

instead of using the login name of "robot!" to ID
robots. This patch now uses the PFBPROBOT flag as
suggested by other people. 

As the previous update_players was not incorporated
into www.netrek.org's darcs repo.... All the changes
are here too (except the ones needed for newbie.c,
which is one line, add the -g option when forking a
new robot into the game). 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: updateplayers.dpatch
Type: application/octet-stream
Size: 13112 bytes
Desc: 3146271520-updateplayers.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060513/d1ef3638/attachment.obj 

From quozl at us.netrek.org  Mon May 15 04:48:20 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 15 May 2006 19:48:20 +1000
Subject: [netrek-dev] netrek-server-vanilla-2.11.0 released
Message-ID: <20060515094820.GA572@us.netrek.org>

netrek-server-vanilla 2.11.0 was released today, with some significant
changes since 2.10.2.  It is in production on continuum.us.netrek.org
and I'm looking forward to the bug reports.

http://quozl.linux.org.au/netrek/
e4b9f7a5193ec1e08cfc722af597c7c3  netrek-server-vanilla-2.11.0.tar.gz

Summary of changes: (from NEWS)
- fix practice robots to cloak when bombing near home planet [Huang]
- fix INL confine to knock ships out of orbit [Cameron]
- describe a local unnamed server as "server on this computer" [Cameron]
- fix cambot regression [Cameron]
- convert voting, ejecting and banning to site policy in sysdef [Cameron]
- add vote to temporarily ban a player [Cameron]
- change to conquest sequence to add a parade [Cameron]
- fix unrealistic robot boredom timer [Cameron]
- add galaxy configuration tool, setplanet [Cameron]
- move common code into a libnetrek [Cameron]
- lesser lights minimal compilation target [Cameron]
- factorise god log access functions [Cameron]
- fix valgrind detected heap leaks [Cameron]
- compilation fixes for GCC 4.0.3 [Cameron]
- remove some crud from tar.gz [Cameron]
- add coding STYLE file [Cameron]
- fix client/server error over army capacity of AS in certain cases [Balcerski]
- use IP addresses only for t-mode scum test [Cameron]
- compilation fix for FreeBSD [O'Conner]

I'll take patches to fix the NEWS and ChangeLog files for any missing
changes ... things got a bit hectic with the CVS and Darcs situation, so
some changes may have been applied *without* a meaningful summary in
NEWS.

-- 
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/20060515/f2ef75f5/attachment.pgp 

From quozl at us.netrek.org  Mon May 15 06:02:26 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 15 May 2006 21:02:26 +1000
Subject: [netrek-dev] post 2.11.0 patching
Message-ID: <20060515110226.GA2189@us.netrek.org>

If you've sent in a patch for netrek-server-vanilla but it didn't get in
to 2.11.0, and you want it considered, please send it again.

Use Darcs relative to either of the repositories:

http://www.netrek.org/repos/netrek-server/
http://james.tooraweenah.com/darcs/netrek-server/

That is, do a "darcs get" followed by one of the URLs above, make your
changes, then do a "darcs record" followed by a "darcs send".

If you've got your own repository published, do a "darcs push" to it and
let us know about it.

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


From williamb at its.caltech.edu  Mon May 15 21:05:05 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Mon, 15 May 2006 21:05:05 -0500
Subject: [netrek-dev] darcs patch: Compilation fix for gcc4.0
Message-ID: <200605160205.k4G255sn001726@omen.digital-genesis.com>

Mon May 15 20:59:45 CDT 2006  williamb at its.caltech.edu
  * Compilation fix for gcc4.0
  Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
  moved the int declare to top of the function.
  This patch contains the following changes:
  
  M ./Vanilla/robotd/assault.c -1 +1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 522 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060515/bcd8f6c5/attachment.bin 

From quozl at us.netrek.org  Mon May 15 23:07:19 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 14:07:19 +1000
Subject: [netrek-dev] darcs patch: Compilation fix for gcc4.0
In-Reply-To: <200605160205.k4G255sn001726@omen.digital-genesis.com>
References: <200605160205.k4G255sn001726@omen.digital-genesis.com>
Message-ID: <20060516040719.GE5416@us.netrek.org>

On Mon, May 15, 2006 at 09:05:05PM -0500, williamb at its.caltech.edu wrote:
> Mon May 15 20:59:45 CDT 2006  williamb at its.caltech.edu
>   * Compilation fix for gcc4.0
>   Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
>   moved the int declare to top of the function.

Taken.  Actually, it was my change, not Jimmy's, that created that
problem for you.

Please include ChangeLog updates next time.  I've pushed a patch for
ChangeLog this time.

Please check the compiler version ... I'm using GCC 4.0.3 and it wasn't
choking on this code at all.

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


From dopleganger75 at gmail.com  Mon May 15 23:24:36 2006
From: dopleganger75 at gmail.com (Pascal Gagnon)
Date: Tue, 16 May 2006 00:24:36 -0400
Subject: [netrek-dev] Defcom i need a job !!! hehe
Message-ID: <f05e094d0605152124x7d5186d8n55eac4d2d0f57ea9@mail.gmail.com>

i have made alot of picture this last month but now i need to know what is
left to do i could build new edge for the chat,Galactic'and tactical but i
need the bmp of this if you have suggestion send me an email thx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060516/43cb3026/attachment.htm 

From quozl at us.netrek.org  Mon May 15 23:40:25 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 14:40:25 +1000
Subject: [netrek-dev] Defcom i need a job !!! hehe
In-Reply-To: <f05e094d0605152124x7d5186d8n55eac4d2d0f57ea9@mail.gmail.com>
References: <f05e094d0605152124x7d5186d8n55eac4d2d0f57ea9@mail.gmail.com>
Message-ID: <20060516044025.GF5416@us.netrek.org>

G'day Pascal,

Thanks for your work.  Hope you like how we've used it so far ...

- www.netrek.org decoration,
- Netrek XP 2006 beta.

Unfortunately you're working so much faster than we're able to use what
you've done, so feel free to guess what is needed and draw a few extra
pictures.

I'm also hoping someone will put the artwork into a repository so that
it can be used more readily.

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


From jimmyhua73 at yahoo.com  Tue May 16 01:28:14 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 15 May 2006 23:28:14 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
Message-ID: <20060516062814.54655.qmail@web35311.mail.mud.yahoo.com>

Well,

Here it is again. 

Well, at least this time it is more well thought out. 

Hope it makes it into the repository without getting
lost. 


Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbiebetter.dpatch
Type: application/octet-stream
Size: 7024 bytes
Desc: 2785419844-newbiebetter.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060515/b7dd646f/attachment.obj 

From quozl at us.netrek.org  Tue May 16 01:54:47 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 16:54:47 +1000
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516062814.54655.qmail@web35311.mail.mud.yahoo.com>
References: <20060516062814.54655.qmail@web35311.mail.mud.yahoo.com>
Message-ID: <20060516065447.GA18734@us.netrek.org>

On Mon, May 15, 2006 at 11:28:14PM -0700, Jimmy Huang wrote:
> Here it is again. 

Taken, applied, pushed.

Next time please include changes for ChangeLog and NEWS.  I'll write up
these this time; please review what I write in case I misunderstand.

Should there be any changes for Newbie server installation documents?

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


From jimmyhua73 at yahoo.com  Tue May 16 02:00:31 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 00:00:31 -0700 (PDT)
Subject: [netrek-dev] updateplayers.dpatch
Message-ID: <20060516070031.83669.qmail@web35305.mail.mud.yahoo.com>

Again, the updateplayers dpatch. 

This time, using both "robot!" login and OggV packet
to differentiate between robots and real players. 

U need the newbiebetter.dpatch for this previous one
to work right...

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: updateplayers.dpatch
Type: application/octet-stream
Size: 1981 bytes
Desc: 3146271520-updateplayers.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060516/b60f0d2c/attachment-0001.obj 

From jimmyhua73 at yahoo.com  Tue May 16 02:02:08 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 00:02:08 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516065447.GA18734@us.netrek.org>
Message-ID: <20060516070208.28160.qmail@web35301.mail.mud.yahoo.com>

Hi James, 

Sorry about that, didn't know I was supposed to modify
ChangeLog and NEWS. 

There are NO changes in the way you setup newbie
server.

Jimmy

--- James Cameron <quozl at us.netrek.org> wrote:

> On Mon, May 15, 2006 at 11:28:14PM -0700, Jimmy
> Huang wrote:
> > Here it is again. 
> 
> Taken, applied, pushed.
> 
> Next time please include changes for ChangeLog and
> NEWS.  I'll write up
> these this time; please review what I write in case
> I misunderstand.
> 
> Should there be any changes for Newbie server
> installation documents?
> 
> -- 
> 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  Tue May 16 02:06:49 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Tue, 16 May 2006 17:06:49 +1000
Subject: [netrek-dev] darcs patch: newbie better 2 changelog fix
Message-ID: <E1Fftdp-0005qb-R3@dors.lan>

Tue May 16 17:02:48 EST 2006  quozl at us.netrek.org
  * newbie better 2 changelog fix
  Applying the principles of the Software Release Practice HOWTO
  http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 2859 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060516/d813e97e/attachment.bin 

From quozl at us.netrek.org  Tue May 16 02:12:22 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 17:12:22 +1000
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516070208.28160.qmail@web35301.mail.mud.yahoo.com>
References: <20060516065447.GA18734@us.netrek.org>
	<20060516070208.28160.qmail@web35301.mail.mud.yahoo.com>
Message-ID: <20060516071222.GB18734@us.netrek.org>

On Tue, May 16, 2006 at 12:02:08AM -0700, Jimmy Huang wrote:
> Sorry about that, didn't know I was supposed to modify
> ChangeLog and NEWS. 

That's okay, we probably didn't make it very clear.  You'd only know by
looking at the differences made by others, or by the changes from one
version to another.

Take a look at
http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
the Software Release Practice HOWTO.

Especially section two, "Good patching practice".
Sections 2.6 and 2.7 and 2.8 are cool.

Some of the patch is to gain acceptance, but some has to live forever in
the code until someone removes it.  Review the patch I've just made, and
you'll see what I thought of it.  ;-)

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


From quozl at us.netrek.org  Tue May 16 02:15:22 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 17:15:22 +1000
Subject: [netrek-dev] updateplayers.dpatch
In-Reply-To: <20060516070031.83669.qmail@web35305.mail.mud.yahoo.com>
References: <20060516070031.83669.qmail@web35305.mail.mud.yahoo.com>
Message-ID: <20060516071522.GC18734@us.netrek.org>

Taken, thanks.

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


From quozl at us.netrek.org  Tue May 16 04:50:57 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 19:50:57 +1000
Subject: [netrek-dev] COW Camera prototype
Message-ID: <20060516095057.GA3011@us.netrek.org>

The attached patch is work in progress, addition of image capture
support to COW on Linux.  Contributions welcome.

At the moment, all it does is take a snapshot of the whole screen and
write it to a PNG file.  It does this on a coup request.  ;-)

Possible future enhancements:

- take a snapshot of only the main window, (working on that),

- take a snapshot of only the tactical window,

- write to files named after frame number of recording or game,

- generate a frame for every frame of a game recording,

- generate multiple layers for animated playback,

- generate RSS XML for notable events like last few seconds of an LPS,
  with the feed containing the animated playback, for netrek.org,

- operate against a virtual frame buffer under automated control after
  being triggered by the INL robot for end of game condition.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
Index: input.c
===================================================================
RCS file: /cvsroot/netrek/client/cow/input.c,v
retrieving revision 1.12
diff -u -u -r1.12 input.c
--- input.c	16 May 2006 06:25:25 -0000	1.12
+++ input.c	16 May 2006 09:41:57 -0000
@@ -1981,6 +1981,7 @@
 Key67(void)
 {
   sendCoupReq();
+  camera_snap();
 }
 
 Key68(void)
Index: system.mk.in
===================================================================
RCS file: /cvsroot/netrek/client/cow/system.mk.in,v
retrieving revision 1.7
diff -u -u -r1.7 system.mk.in
--- system.mk.in	31 Jan 2006 18:34:06 -0000	1.7
+++ system.mk.in	16 May 2006 09:41:58 -0000
@@ -72,7 +72,7 @@
 	          netstat.o netstatopt.o spopt.o dashboard.o dashboard3.o \
 	          short.o distress.o senddist.o defwin.o tools.o sound.o\
 		  docwin.o cflags.o beeplite.o feature.o\
-		  string_util.o local.o censor.o cowmain.o
+		  string_util.o local.o censor.o cowmain.o camera.o
 
 RSRC 		= check.c colors.c data.c death.c defaults.c dmessage.c\
 	          enter.c findslot.c getname.c getship.c helpwin.c inform.c\
@@ -83,7 +83,7 @@
                   lagmeter.c netstat.c netstatopt.c spopt.c dashboard.c dashboard3.c \
 		  short.c distress.c senddist.c defwin.c tools.c sound.c\
 		  docwin.c cflags.c beeplite.c feature.c reserved.c\
-		  string_util.c local.c censor.c cowmain.c
+		  string_util.c local.c censor.c cowmain.c camera.c
 
 
 INCLUDES 	= struct.h packets.h defs.h copyright.h bitmaps.h data.h\
@@ -113,7 +113,7 @@
 
 netrek: $(RSAOBJ) $(PMAKE) null $(ROBJ) $(MAINOBJ) $(INPUTOBJ) $(X11OBJ) $(WIN32OBJ)  $(RANDOMOBJ) cflags.c randomize
 	$(CC) $(LFLAGS) -o netrek `./randomize $(ROBJ) $(RSAOBJ) $(INPUTOBJ) \
-	$(MAINOBJ) $(X11OBJ) $(WIN32OBJ) $(RANDOMOBJ)` $(LIBRARIES)
+	$(MAINOBJ) $(X11OBJ) $(WIN32OBJ) $(RANDOMOBJ)` $(LIBRARIES) -lgiblib
 
 netrek.shared: done.libcow $(MAINOBJ) $(COWAPI)
 	$(CC) $(LFLAGS) $(MAINOBJ) -L. -lcow $(LIBS) -o netrek.shared
Index: x11window.c
===================================================================
RCS file: /cvsroot/netrek/client/cow/x11window.c,v
retrieving revision 1.7
diff -u -u -r1.7 x11window.c
--- x11window.c	16 May 2006 06:25:25 -0000	1.7
+++ x11window.c	16 May 2006 09:42:06 -0000
@@ -456,6 +456,7 @@
   /* tmp */
   /* XSynchronize(W_Display, True); */
   /* XSetErrorHandler(_myerror); */
+  camera_set_display(W_Display);
 
   W_Root = DefaultRootWindow(W_Display);
 
@@ -1006,6 +1007,9 @@
 			    CWBorderPixel,
 			    &attrs),
 		      WIN_GRAPH);
+  if (strcmp(name, "netrek") == 0) {
+    camera_set_window(newwin, width, height);
+  }
   /* top window */
   sz_hints = XAllocSizeHints();
   if (strcmp(name, "netrek") == 0 || strcmp(name, "wait") == 0 ||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: camera.c
Type: text/x-csrc
Size: 1821 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060516/f68d2528/attachment.c 
-------------- 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/20060516/f68d2528/attachment.pgp 

From netrek at gmail.com  Tue May 16 04:54:57 2006
From: netrek at gmail.com (Zach)
Date: Tue, 16 May 2006 05:54:57 -0400
Subject: [netrek-dev] darcs patch: Compilation fix for gcc4.0
In-Reply-To: <20060516040719.GE5416@us.netrek.org>
References: <200605160205.k4G255sn001726@omen.digital-genesis.com>
	<20060516040719.GE5416@us.netrek.org>
Message-ID: <ecfa260c0605160254h6efc890agdf47d5932106b758@mail.gmail.com>

I thought ChangeLog was specific to CVS?

Zach

On 5/16/06, James Cameron <quozl at us.netrek.org> wrote:
> On Mon, May 15, 2006 at 09:05:05PM -0500, williamb at its.caltech.edu wrote:
> > Mon May 15 20:59:45 CDT 2006  williamb at its.caltech.edu
> >   * Compilation fix for gcc4.0
> >   Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
> >   moved the int declare to top of the function.
>
> Taken.  Actually, it was my change, not Jimmy's, that created that
> problem for you.
>
> Please include ChangeLog updates next time.  I've pushed a patch for
> ChangeLog this time.
>
> Please check the compiler version ... I'm using GCC 4.0.3 and it wasn't
> choking on this code at all.
>
> --
> 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 netrek at gmail.com  Tue May 16 05:20:00 2006
From: netrek at gmail.com (Zach)
Date: Tue, 16 May 2006 06:20:00 -0400
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <20060516095057.GA3011@us.netrek.org>
References: <20060516095057.GA3011@us.netrek.org>
Message-ID: <ecfa260c0605160320n1faacc46w954cbecde4642bcf@mail.gmail.com>

Wow that is cool. Is package giblib included with Vanilla now?

Zach

On 5/16/06, James Cameron <quozl at us.netrek.org> wrote:
> The attached patch is work in progress, addition of image capture
> support to COW on Linux.  Contributions welcome.
>
> At the moment, all it does is take a snapshot of the whole screen and
> write it to a PNG file.  It does this on a coup request.  ;-)
>
> Possible future enhancements:
>
> - take a snapshot of only the main window, (working on that),
>
> - take a snapshot of only the tactical window,
>
> - write to files named after frame number of recording or game,
>
> - generate a frame for every frame of a game recording,
>
> - generate multiple layers for animated playback,
>
> - generate RSS XML for notable events like last few seconds of an LPS,
>   with the feed containing the animated playback, for netrek.org,
>
> - operate against a virtual frame buffer under automated control after
>   being triggered by the INL robot for end of game condition.
>
> --
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFEaaCBbmRwv64kZsARAjt6AJ4lM2fwltW9C/QQY/JwowQpdfxy+gCgv0TG
> vTOwdxs0Ma+DESKG4yX/MME=
> =1hLy
> -----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  Tue May 16 05:33:35 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 20:33:35 +1000
Subject: [netrek-dev] darcs patch: Compilation fix for gcc4.0
In-Reply-To: <ecfa260c0605160254h6efc890agdf47d5932106b758@mail.gmail.com>
References: <200605160205.k4G255sn001726@omen.digital-genesis.com>
	<20060516040719.GE5416@us.netrek.org>
	<ecfa260c0605160254h6efc890agdf47d5932106b758@mail.gmail.com>
Message-ID: <20060516103335.GA3151@us.netrek.org>

On Tue, May 16, 2006 at 05:54:57AM -0400, Zach wrote:
> I thought ChangeLog was specific to CVS?

No.  ChangeLog goes into the .tar.gz, so no matter what we use, CVS,
Darcs, subversion, or git, the ChangeLog is valuable.  CVS has no
special handling for the file.  It's just a file.

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


From netrek at gmail.com  Tue May 16 05:40:04 2006
From: netrek at gmail.com (Zach)
Date: Tue, 16 May 2006 06:40:04 -0400
Subject: [netrek-dev] darcs patch: Compilation fix for gcc4.0
In-Reply-To: <20060516103335.GA3151@us.netrek.org>
References: <200605160205.k4G255sn001726@omen.digital-genesis.com>
	<20060516040719.GE5416@us.netrek.org>
	<ecfa260c0605160254h6efc890agdf47d5932106b758@mail.gmail.com>
	<20060516103335.GA3151@us.netrek.org>
Message-ID: <ecfa260c0605160340h133871ceq2a73061ddd428ffd@mail.gmail.com>

Ok so if I make a change directly (such as working from tar repo) I
should manually create my own ChangeLog?

Zach

On 5/16/06, James Cameron <quozl at us.netrek.org> wrote:
> On Tue, May 16, 2006 at 05:54:57AM -0400, Zach wrote:
> > I thought ChangeLog was specific to CVS?
>
> No.  ChangeLog goes into the .tar.gz, so no matter what we use, CVS,
> Darcs, subversion, or git, the ChangeLog is valuable.  CVS has no
> special handling for the file.  It's just a file.
>
> --
> 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  Tue May 16 05:59:23 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 16 May 2006 20:59:23 +1000
Subject: [netrek-dev] darcs patch: Compilation fix for gcc4.0
In-Reply-To: <ecfa260c0605160340h133871ceq2a73061ddd428ffd@mail.gmail.com>
References: <200605160205.k4G255sn001726@omen.digital-genesis.com>
	<20060516040719.GE5416@us.netrek.org>
	<ecfa260c0605160254h6efc890agdf47d5932106b758@mail.gmail.com>
	<20060516103335.GA3151@us.netrek.org>
	<ecfa260c0605160340h133871ceq2a73061ddd428ffd@mail.gmail.com>
Message-ID: <20060516105923.GC3151@us.netrek.org>

On Tue, May 16, 2006 at 06:40:04AM -0400, Zach wrote:
> Ok so if I make a change directly (such as working from tar repo) I
> should manually create my own ChangeLog?

No thanks, you're exceptional ... if you make a change, just send it in,
don't bother with diff, patch, ChangeLog, or anything!

Read the GNU standards.

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


From jimmyhua73 at yahoo.com  Tue May 16 05:59:46 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 03:59:46 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516071222.GB18734@us.netrek.org>
Message-ID: <20060516105946.6262.qmail@web35306.mail.mud.yahoo.com>

Hey Quozl, 

Thanks for the general pointers. I've generally hacked
up other people's code for my own personal use.
Participating in an Open Source environment is pretty
new to me. 

As I have a great idea for a "newbie" server... BUT I
have no access to a Linux Box or other unix box out on
the internet... So, this is my only recourse, is to
add it into the Vanilla source (and hope someone else
uses it for a newbie server). 

I really dunno if putting it into a "newbie" type
server is even appropriate. My aspiration is by the
time, I am done tweaking the AI of hadley's bots, even
experienced players will have a hard time.

The next patch will include commentary in the
ChangeLog and news. Following the current format of
the Changelog. 

To be honest, those changes are it! I can't think of
anything else that will make the bots tougher.  

I have been thinking about re-writing the dogfighting
code. Computers are faster these days :-P. The first
time I re-wrote the dogfighting code (6 years ago), it
took so much CPU cycles, the bots couldn't keep up...

Jimmy

--- James Cameron <quozl at us.netrek.org> wrote:

> On Tue, May 16, 2006 at 12:02:08AM -0700, Jimmy
> Huang wrote:
> > Sorry about that, didn't know I was supposed to
> modify
> > ChangeLog and NEWS. 
> 
> That's okay, we probably didn't make it very clear. 
> You'd only know by
> looking at the differences made by others, or by the
> changes from one
> version to another.
> 
> Take a look at
>
http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
> the Software Release Practice HOWTO.
> 
> Especially section two, "Good patching practice".
> Sections 2.6 and 2.7 and 2.8 are cool.
> 
> Some of the patch is to gain acceptance, but some
> has to live forever in
> the code until someone removes it.  Review the patch
> I've just made, and
> you'll see what I thought of it.  ;-)
> 
> -- 
> 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 jimmyhua73 at yahoo.com  Tue May 16 06:11:25 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 04:11:25 -0700 (PDT)
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <20060516095057.GA3011@us.netrek.org>
Message-ID: <20060516111125.1379.qmail@web35307.mail.mud.yahoo.com>


Any tips on how to compile the COW client for linux?

I tried compiling it before. It compiles fine, but as
soon as I try to run it, it core dumps. 

Jimmy



From netrek at gmail.com  Tue May 16 08:21:19 2006
From: netrek at gmail.com (Zach)
Date: Tue, 16 May 2006 09:21:19 -0400
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <20060516111125.1379.qmail@web35307.mail.mud.yahoo.com>
References: <20060516095057.GA3011@us.netrek.org>
	<20060516111125.1379.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605160621l13703196udad51d166ade9109@mail.gmail.com>

On 5/16/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>
> Any tips on how to compile the COW client for linux?
>
> I tried compiling it before. It compiles fine, but as
> soon as I try to run it, it core dumps.

Same here. Debian GNU/Linux, 2.4.18 kernel

Zach


From dopleganger75 at gmail.com  Tue May 16 10:42:12 2006
From: dopleganger75 at gmail.com (Pascal Gagnon)
Date: Tue, 16 May 2006 11:42:12 -0400
Subject: [netrek-dev] Defcom i need Bmp
Message-ID: <f05e094d0605160842x6bbd3bdauba0f5ffb6073b7d0@mail.gmail.com>

im sending this email to ask someone to send me the bitmaps that are not in
the client , i will check them and decide to rebuild or not rebuild them
thankyou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060516/42d77921/attachment.htm 

From dopleganger75 at gmail.com  Tue May 16 10:50:31 2006
From: dopleganger75 at gmail.com (Pascal Gagnon)
Date: Tue, 16 May 2006 11:50:31 -0400
Subject: [netrek-dev] Defcom suggest
Message-ID: <f05e094d0605160850t320ebe46ja3945a76090dce57@mail.gmail.com>

i have difficulty to see what picture we have to rebuild i have done so much
and there is surely somethings left, if i could receive some suggestion from
everybody it could help me to know what we have to do thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060516/cfb4f643/attachment.htm 

From xyzzy at speakeasy.org  Tue May 16 15:38:21 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 16 May 2006 13:38:21 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516062814.54655.qmail@web35311.mail.mud.yahoo.com>
References: <20060516062814.54655.qmail@web35311.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605161332550.178@shell2.speakeasy.net>

On Mon, 15 May 2006, Jimmy Huang wrote:

> Well,
>
> Here it is again.
>
> Well, at least this time it is more well thought out.

Are they any coding standards?  The quality of the client code is shit, but
the vanilla server isn't that bad.  This patch has random indention style that
changes from hunk to hunk and does not match the exiting code.  Is that going to
be considered acceptable?  I don't care anymore what you do with the netrek
code.


From netrek at gmail.com  Tue May 16 16:06:25 2006
From: netrek at gmail.com (Zach)
Date: Tue, 16 May 2006 17:06:25 -0400
Subject: [netrek-dev] Defcom suggest
In-Reply-To: <f05e094d0605160850t320ebe46ja3945a76090dce57@mail.gmail.com>
References: <f05e094d0605160850t320ebe46ja3945a76090dce57@mail.gmail.com>
Message-ID: <ecfa260c0605161406m39e40496g9f8c64ecf4b525a3@mail.gmail.com>

On 5/16/06, Pascal Gagnon <dopleganger75 at gmail.com> wrote:
> i have difficulty to see what picture we have to rebuild i have done so much
> and there is surely somethings left, if i could receive some suggestion from
> everybody it could help me to know what we have to do thank you

Salutt Pascal,

You've done really nice work so far Pascal. Merci beaucoup :-)

I have a few ideas for pixmaps:

* new phaser (especially it would be nice if starbase phasers are a
different color)
* new plasma
* new photon torpedo
* new transwarp images (the redshift/blueshift of light from
surrounding stars effect)

Bon huit,
Zach


From stephen.thorne at gmail.com  Tue May 16 16:26:32 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 07:26:32 +1000
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <20060516111125.1379.qmail@web35307.mail.mud.yahoo.com>
References: <20060516095057.GA3011@us.netrek.org>
	<20060516111125.1379.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605161426p576fb2c4n502275f983539b1a@mail.gmail.com>

On 5/16/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>
> Any tips on how to compile the COW client for linux?
>
> I tried compiling it before. It compiles fine, but as
> soon as I try to run it, it core dumps.

Before you ./configure, change this line in system.mk.in

OPT             = -O2
to be:
OPT             = -g -Wall

That change will make cow compile with debugging symbols on.

Then run cow under gdb

gdb ./netrek
> run
(segfault should occur)
> backtrace

And post the backtrace on the mailing list.

If you have the corefile (and it doesn't contain any passwords, make
sure to omit them from your netrekrc) you can email it to me
privately, provided you've turned debugging symbols on for the
corefile.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Tue May 16 18:26:44 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 16:26:44 -0700 (PDT)
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <3e8ca5c80605161426p576fb2c4n502275f983539b1a@mail.gmail.com>
Message-ID: <20060516232644.47226.qmail@web35301.mail.mud.yahoo.com>

Hi Stephen, 

Thanks for the tips. I deleted my source tree after
many tries. So I had to re-download it. 

I did a 

darcs get
http://www.netrek.org/repos/netrek-client-cow/

But this time, it seems that the configure script file
is missing. 

Jimmy


--- Stephen Thorne <stephen.thorne at gmail.com> wrote:

> On 5/16/06, Jimmy Huang <jimmyhua73 at yahoo.com>
> wrote:
> >
> > Any tips on how to compile the COW client for
> linux?
> >
> > I tried compiling it before. It compiles fine, but
> as
> > soon as I try to run it, it core dumps.
> 
> Before you ./configure, change this line in
> system.mk.in
> 
> OPT             = -O2
> to be:
> OPT             = -g -Wall
> 
> That change will make cow compile with debugging
> symbols on.
> 
> Then run cow under gdb
> 
> gdb ./netrek
> > run
> (segfault should occur)
> > backtrace
> 
> And post the backtrace on the mailing list.
> 
> If you have the corefile (and it doesn't contain any
> passwords, make
> sure to omit them from your netrekrc) you can email
> it to me
> privately, provided you've turned debugging symbols
> on for the
> corefile.
> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I
> will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From jimmyhua73 at yahoo.com  Tue May 16 18:39:56 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 16:39:56 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
In-Reply-To: <Pine.LNX.4.58.0605161332550.178@shell2.speakeasy.net>
Message-ID: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>

Hi Trent, 

I spent many hours writing that code up. Please do not
insult me. 

I have read the indentation standards as laid out in
the "manual" that James Cameron referred me to.  And
the indentation looks good. 

Maybe it is the text editor we use to view it? I use
emacs. Seriously. The code is very readable, more so
than the original robotd code. 

Where exactly did my indentation style change? Again,
I use emacs, For blocks of code, I let emacs do my
indentation for me, and it looks good to me.  When I
change only a single line, I follow the identation of
what is already there. 

Again, I am very new to this. But I have some ideas I
want to implement. And since you guys have the keys. I
will bend over backwards and do whatever it takes to
get my changes into the Vanilla source code. 

What do you want me to change to get this accepted?

Jimmy

--- Trent Piepho <xyzzy at speakeasy.org> wrote:

> On Mon, 15 May 2006, Jimmy Huang wrote:
> 
> > Well,
> >
> > Here it is again.
> >
> > Well, at least this time it is more well thought
> out.
> 
> Are they any coding standards?  The quality of the
> client code is shit, but
> the vanilla server isn't that bad.  This patch has
> random indention style that
> changes from hunk to hunk and does not match the
> exiting code.  Is that going to
> be considered acceptable?  I don't care anymore what
> you do with the netrek
> code.
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From stephen.thorne at gmail.com  Tue May 16 19:13:46 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 10:13:46 +1000
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <20060516232644.47226.qmail@web35301.mail.mud.yahoo.com>
References: <3e8ca5c80605161426p576fb2c4n502275f983539b1a@mail.gmail.com>
	<20060516232644.47226.qmail@web35301.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605161713p1ffa7714of7f40e13147f64e8@mail.gmail.com>

On 5/17/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Hi Stephen,
>
> Thanks for the tips. I deleted my source tree after
> many tries. So I had to re-download it.
>
> I did a
>
> darcs get
> http://www.netrek.org/repos/netrek-client-cow/
>
> But this time, it seems that the configure script file
> is missing.

Oh, that's because I (summarily) decided it shouldn't be there.
configure is automatically generated from configure.in, using
autoconf.

Either revert the patch that removes it (darcs unpull -p patchname;
find the patchname by looking at 'darcs changes') or run autoconf.

SDL is required for autoconf to be run.

I think 'aclocal' or 'automake' might be required, but I've got no
idea. autoconf is black magic to me. Try them if autoconf doesn't
work. :)
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Tue May 16 19:18:38 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 10:18:38 +1000
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516105946.6262.qmail@web35306.mail.mud.yahoo.com>
References: <20060516071222.GB18734@us.netrek.org>
	<20060516105946.6262.qmail@web35306.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605161718l51f4b347ue6abe9bbabdbf298@mail.gmail.com>

On 5/16/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Thanks for the general pointers. I've generally hacked
> up other people's code for my own personal use.
> Participating in an Open Source environment is pretty
> new to me.
>
> As I have a great idea for a "newbie" server... BUT I
> have no access to a Linux Box or other unix box out on
> the internet... So, this is my only recourse, is to
> add it into the Vanilla source (and hope someone else
> uses it for a newbie server).

If you don't have access to a linux machine, then this is probably a good idea:

1) Get vmware server from http://vmware.com/
2) Get a linux image from http://www.thoughtpolice.co.uk/vmware/ I
recommend debian-31r0a-i386-netinst-kernel2.6.zip, 115M
3) apt-get install a bunch of things (I don't remember what, probably
things like libgdbm-dev)
4) Install Vanilla.
5) Playtest your changes.
6) Share the image with others.

:)
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Tue May 16 19:48:02 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 16 May 2006 17:48:02 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
In-Reply-To: <3e8ca5c80605161718l51f4b347ue6abe9bbabdbf298@mail.gmail.com>
Message-ID: <20060517004802.66607.qmail@web35307.mail.mud.yahoo.com>

Hi Stephen, 

You misunderstood me.  I have a linux box sitting
right here next to me running Debian Sarge 31r1. 

The code works and have been extensively play tested. 

I DON'T have a linuxbox with a static IP address
directly on the internet where I can host a newbie
server for *everyone* to play on 24x7. 

Jimmy

--- Stephen Thorne <stephen.thorne at gmail.com> wrote:

> On 5/16/06, Jimmy Huang <jimmyhua73 at yahoo.com>
> wrote:
> > Thanks for the general pointers. I've generally
> hacked
> > up other people's code for my own personal use.
> > Participating in an Open Source environment is
> pretty
> > new to me.
> >
> > As I have a great idea for a "newbie" server...
> BUT I
> > have no access to a Linux Box or other unix box
> out on
> > the internet... So, this is my only recourse, is
> to
> > add it into the Vanilla source (and hope someone
> else
> > uses it for a newbie server).
> 
> If you don't have access to a linux machine, then
> this is probably a good idea:
> 
> 1) Get vmware server from http://vmware.com/
> 2) Get a linux image from
> http://www.thoughtpolice.co.uk/vmware/ I
> recommend debian-31r0a-i386-netinst-kernel2.6.zip,
> 115M
> 3) apt-get install a bunch of things (I don't
> remember what, probably
> things like libgdbm-dev)
> 4) Install Vanilla.
> 5) Playtest your changes.
> 6) Share the image with others.
> 
> :)
> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I
> will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From stephen.thorne at gmail.com  Tue May 16 20:16:34 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 11:16:34 +1000
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060517004802.66607.qmail@web35307.mail.mud.yahoo.com>
References: <3e8ca5c80605161718l51f4b347ue6abe9bbabdbf298@mail.gmail.com>
	<20060517004802.66607.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605161816q480e8a2bw6ce96e918edd4f82@mail.gmail.com>

On 5/17/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Hi Stephen,
>
> You misunderstood me.  I have a linux box sitting
> right here next to me running Debian Sarge 31r1.
>
> The code works and have been extensively play tested.
>
> I DON'T have a linuxbox with a static IP address
> directly on the internet where I can host a newbie
> server for *everyone* to play on 24x7.

Damn, I was hoping someone else would handle steps 1->5 for me so I
could publish step 6 on www.netrek.org. You got my hopes up :(.

I'll talk to Q about more netrekd servers tomorrow. Maybe we can run
multiple ones on continuum or something.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Tue May 16 20:26:47 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 16 May 2006 18:26:47 -0700 (PDT)
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>
References: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605161805160.16977@shell2.speakeasy.net>

On Tue, 16 May 2006, Jimmy Huang wrote:
> Hi Trent,
>
> I spent many hours writing that code up. Please do not
> insult me.

Try posting code like that to the mplayer list, then you will see insults.

> Where exactly did my indentation style change? Again,

hunk ./Vanilla/robots/newbie.c 120
-    class = STARBASE;
+    class = ATT;

You change the newbie bot from a starbase to an att, that's not in
your patch description.

hunk ./Vanilla/robots/newbie.c 140
-    me->p_x = 75000;                 /* displace to on overlooking position */
-    me->p_y = 100;                  /* maybe we should just make it fight? */
+    me->p_x = 55000;                 /* displace to on overlooking position */
+    me->p_y = 50000;                  /* maybe we should just make it fight? */

You move merlin to a new position, that's not in your patch description
either.

-            if (next_team == FED)
-                start_a_robot("-Tf");
-            else
-                start_a_robot("-Tr");
+          if (next_team == FED)
+            start_a_robot("-Tf");

Original code is four space indents, you changed to two space indents.

+        if (j[i].p_team & pp_team) {
+          keep = i;
+          kill = 1;
+        }

Here you use K&R style with the brace on the same line as the if

+    if (tc == 0) /* no teams yet, join anybody */
+      {
+        rt = random() % 4;

Here you use the disgusting GNU style with stair-step braces on their
own line.

For projects I have administered or currently contribute to, this would be
completely unacceptable.  Maybe James thinks it is fine for netrek.  The
netrek codebase has never been high quality code, the server is ok, the
clients are very bad.  It reflects the code's history, random hacking by many
college students with little to no experience of a period of twenty plus
years.  Zach might say, "When twenty years old your code reaches, look as good
your code will not."

If James thinks mixed GNU and K&R style indention at sometimes 2 and sometimes
4 spaces is ok, then fine.  I'm not interested in getting into any kind of
policy discussion.


From netrek at gmail.com  Tue May 16 20:38:06 2006
From: netrek at gmail.com (Zach)
Date: Tue, 16 May 2006 21:38:06 -0400
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <3e8ca5c80605161713p1ffa7714of7f40e13147f64e8@mail.gmail.com>
References: <3e8ca5c80605161426p576fb2c4n502275f983539b1a@mail.gmail.com>
	<20060516232644.47226.qmail@web35301.mail.mud.yahoo.com>
	<3e8ca5c80605161713p1ffa7714of7f40e13147f64e8@mail.gmail.com>
Message-ID: <ecfa260c0605161838m2a0b1c04vaddd6ec549b1f732@mail.gmail.com>

On 5/16/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
>
> Oh, that's because I (summarily) decided it shouldn't be there.
> configure is automatically generated from configure.in, using
> autoconf.
>
> Either revert the patch that removes it (darcs unpull -p patchname;
> find the patchname by looking at 'darcs changes') or run autoconf.
>
> SDL is required for autoconf to be run.

SDL is an outside library, I think a good workaround would preserve
the existing way we've been config'ing the client (people are used to
it and it's straghtforward and adds a degree of transparency) rather
than throw it all out just because we want to support SDL.

Zach


From stephen.thorne at gmail.com  Tue May 16 22:09:44 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 13:09:44 +1000
Subject: [netrek-dev] newbie patch again
In-Reply-To: <Pine.LNX.4.58.0605161805160.16977@shell2.speakeasy.net>
References: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605161805160.16977@shell2.speakeasy.net>
Message-ID: <3e8ca5c80605162009n56f7237dhd42ff40117975129@mail.gmail.com>

On 5/17/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> Stuff

Thanks for the code review Trent. Most of the important stuff was
fixed by Quozl's subsequent patch, but I've gone through and changed
the indentation for some of the newbie.c file, and updated my repo on
shiny (see source control). As you seemed to think it was quite
important.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Tue May 16 22:48:15 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 13:48:15 +1000
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <ecfa260c0605161838m2a0b1c04vaddd6ec549b1f732@mail.gmail.com>
References: <3e8ca5c80605161426p576fb2c4n502275f983539b1a@mail.gmail.com>
	<20060516232644.47226.qmail@web35301.mail.mud.yahoo.com>
	<3e8ca5c80605161713p1ffa7714of7f40e13147f64e8@mail.gmail.com>
	<ecfa260c0605161838m2a0b1c04vaddd6ec549b1f732@mail.gmail.com>
Message-ID: <3e8ca5c80605162048w218ac2d1t3c258b363e8ee07c@mail.gmail.com>

On 5/17/06, Zach <netrek at gmail.com> wrote:
> On 5/16/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
> >
> > Oh, that's because I (summarily) decided it shouldn't be there.
> > configure is automatically generated from configure.in, using
> > autoconf.
> >
> > Either revert the patch that removes it (darcs unpull -p patchname;
> > find the patchname by looking at 'darcs changes') or run autoconf.
> >
> > SDL is required for autoconf to be run.
>
> SDL is an outside library.

Developers are expected to have all the libraries.

Non-developers can use the released source, in tarball form, with the
configure generated by someone with autoconf and all the libraries.

This is standard practice.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Wed May 17 00:15:59 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 15:15:59 +1000
Subject: [netrek-dev] Vanilla Bug Report, gcc-4.0.1
Message-ID: <3e8ca5c80605162215u24fce17fk8a7bce637ed9d794@mail.gmail.com>

Hi.

I'm faced with a problem with the netrek build on OSX using gcc-4.0.1,
I'll try to outline it briefly, show error output, and show a minimal
example that reproduces the error.

Brief Outline:
Symbols defined in a .o file inserted into a .a file fail to be seen
by the linker at link time.

To Reproduced under OSX:
CFLAGS=-I/opt/local/include ./configure
make

End of error output looks like:
gcc -o message  -I/opt/local/include -Wall  -DRSA -I../include
message.o ../ntserv/libnetrek.a   -lresolv -lm
gcc  -I/opt/local/include -Wall  -DRSA -I../include   -c -o
newscores.o newscores.c
gcc -o newscores  -I/opt/local/include -Wall  -DRSA -I../include
newscores.o ../ntserv/libnetrek.a   -lresolv -lm
/usr/bin/ld: Undefined symbols:
_Global
_PlayerFile
_status
_Access_File
_Banned_File
_Basep
_Bypass_File
_Cambot
_Cambot_out
_Clue_Bypass
_ConqFile
_Daemon
_Error_File
_Feature_File
_GodLog
_Inl
_LogFile
_LogFileName
_Mars
_MesgLog
_Motd_Path
_Newbie
_NoCount_File
_PlFile
_PlayerIndexFile
_PreT
_Prog
_Puck
_RSA_Key_File
_Robodir
_Robot
_Scores
_Scum_File
_SysDef_File
_Time_File
collect2: ld returned 1 exit status
make[1]: *** [newscores] Error 1
make: *** [do_utilities] Error 2

Minimal Test Case:
Copy attached makefile to an empty directory, and run 'make'

Expected output:
$ make
echo 'extern void bar(); int main (int argc, char**argv) { bar();
return 0; }' > three.c
gcc -c -o three.o three.c
echo "char foo[256];" > one.c
gcc -c -o one.o one.c
echo 'extern char foo[]; void bar() { strcpy(foo, "test"); }' > two.c
gcc -c -o two.o two.c
ar cru libfoo.a one.o two.o
gcc -o completed three.o libfoo.a
$ ./completed ; echo $?
0

Output found when using gcc-4.0.1 on OSX:
$ make
echo 'extern void bar(); int main (int argc, char**argv) { bar();
return 0; }' > three.c
gcc -c -o three.o three.c
echo "char foo[256];" > one.c
gcc -c -o one.o one.c
echo 'extern char foo[]; void bar() { strcpy(foo, "test"); }' > two.c
gcc -c -o two.o two.c
two.c: In function 'bar':
two.c:1: warning: incompatible implicit declaration of built-in
function 'strcpy'
ar cru libfoo.a one.o two.o
gcc -o completed three.o libfoo.a
/usr/bin/ld: Undefined symbols:
_foo
collect2: ld returned 1 exit status
make: *** [completed] Error 1

Ignoring the warning brought on by doing a strcpy without the relevent
header file, you see clearly the undefined symbol. Also note this is
the output of 'nm' in the error case:

$ nm libfoo.a

libfoo.a(one.o):
00000100 C _foo

libfoo.a(two.o):
00000000 T _bar
         U _foo


-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 543 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060517/ccab5ae9/attachment.obj 

From jimmyhua73 at yahoo.com  Wed May 17 02:26:08 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 17 May 2006 00:26:08 -0700 (PDT)
Subject: [netrek-dev] interesting newbie bug
Message-ID: <20060517072608.16900.qmail@web35307.mail.mud.yahoo.com>

I found an interesting bug when Vanilla server is run
in newbie mode. 

To test, I use a bot "Marvin" to play on one of the
teams to keep the game going. 

One team gets timercided (usually, after a couple of
hours). 

Bugs,

1. Losing team gets to join back into the timercided
team. 

2. Winning team is too clueless to finish the game and
take that last neuted planet. 

3. global stats get ruined and bots spend time
dogfighting.

Anyways, I was wondering how you want this fixed. 

We can:

1. Make the bots smart enough to finish the game. 
2. Have Merlin (newbie.c) robot reset the galaxy upon
timercide. 
3. Have the daemon (daemonII.c) reset the galaxy upon
timercide when in the newbie mode. 
4. force loser bots over to a 3rd team. 

In the past, bots and humans joined in the same queue.
And when the bots and humans got forced onto a
different team on timercide, the winning bots would
cause a geno when they went on to take a third space
planet (after reprogramming their computers). This
doesn't happen anymore, but it was fun to watch.

Of course 2 or 3 is the easiest to code. I haven't
thought about how to do 1 yet. 

Votes?

Jimmy



From xyzzy at speakeasy.org  Wed May 17 02:59:44 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 17 May 2006 00:59:44 -0700 (PDT)
Subject: [netrek-dev] Vanilla Bug Report, gcc-4.0.1
In-Reply-To: <3e8ca5c80605162215u24fce17fk8a7bce637ed9d794@mail.gmail.com>
References: <3e8ca5c80605162215u24fce17fk8a7bce637ed9d794@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0605170058330.499@shell3.speakeasy.net>

On Wed, 17 May 2006, Stephen Thorne wrote:
> gcc -o newscores  -I/opt/local/include -Wall  -DRSA -I../include
> newscores.o ../ntserv/libnetrek.a   -lresolv -lm

This should work.  It works on Linux.  Have you tried changing
../ntserv/libnetrek.a to -L../ntserv -lnetrek


From stephen.thorne at gmail.com  Wed May 17 04:49:31 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 19:49:31 +1000
Subject: [netrek-dev] Vanilla Bug Report, gcc-4.0.1
In-Reply-To: <Pine.LNX.4.58.0605170058330.499@shell3.speakeasy.net>
References: <3e8ca5c80605162215u24fce17fk8a7bce637ed9d794@mail.gmail.com>
	<Pine.LNX.4.58.0605170058330.499@shell3.speakeasy.net>
Message-ID: <3e8ca5c80605170249r33ae79b4n8f4fa18bd4721b34@mail.gmail.com>

On 5/17/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> On Wed, 17 May 2006, Stephen Thorne wrote:
> > gcc -o newscores  -I/opt/local/include -Wall  -DRSA -I../include
> > newscores.o ../ntserv/libnetrek.a   -lresolv -lm
>
> This should work.  It works on Linux.  Have you tried changing
> ../ntserv/libnetrek.a to -L../ntserv -lnetrek

Yes, it should work, and I've verified that it doesn't work using gcc3
or gcc4 under OSX, and does work using gcc3 and gcc4 under linux. This
is why I'm so confused. I've asked for help from a few sources, and
come up with "it should work" from some very experienced folks.

Datapoint, using your suggestion of -L$path -l$name, including the
relevent nm output to make sense of the ld errors.

shiny:/tmp stephen$ nm three.o
         U _bar
00000000 T _main
         U dyld_stub_binding_helper
shiny:/tmp stephen$ nm libfoo.a

libfoo.a(one.o):
00000100 C _foo

libfoo.a(two.o):
00000000 T _bar
         U _foo
shiny:/tmp stephen$ gcc three.o libfoo.a
/usr/bin/ld: Undefined symbols:
_foo
collect2: ld returned 1 exit status
shiny:/tmp stephen$ gcc -L. -lfoo three.o
/usr/bin/ld: Undefined symbols:
_bar
collect2: ld returned 1 exit status

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Wed May 17 06:24:44 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 17 May 2006 21:24:44 +1000
Subject: [netrek-dev] Vanilla Bug Report, gcc-4.0.1
In-Reply-To: <3e8ca5c80605170249r33ae79b4n8f4fa18bd4721b34@mail.gmail.com>
References: <3e8ca5c80605162215u24fce17fk8a7bce637ed9d794@mail.gmail.com>
	<Pine.LNX.4.58.0605170058330.499@shell3.speakeasy.net>
	<3e8ca5c80605170249r33ae79b4n8f4fa18bd4721b34@mail.gmail.com>
Message-ID: <3e8ca5c80605170424h75ec5f78p5907469a2e52984f@mail.gmail.com>

Turns out the bug was apple's version of ranlib. They are quite different.

Apple:

apple$ ranlib -V
Apple Computer, Inc. version cctools-590.18
ranlib: no archives specified
Usage: ranlib [-sactfqLT] [-] archive [...]

Debian:

debian$ ranlib --version
GNU ranlib 2.16.91 20051117 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.


From bogus@does.not.exist.com  Thu May  4 10:41:37 2006
From: bogus@does.not.exist.com ()
Date: Thu, 04 May 2006 15:41:37 -0000
Subject: No subject
Message-ID: <mailman.129.1147865113.21895.netrek-dev@us.netrek.org>

       -c     Include  common symbols as definitions with respect to the ta=
ble
              of contents.  This is seldom the intended behavior  for  link=
ing
              from  a  library,  as  it forces the linking of a library mem=
ber
              just because it uses an uninitialized global that  is  undefi=
ned
              at  that  point  in  the  linking.  This option is included o=
nly
              because this was the original behavior of ranlib.   This  opt=
ion
              is not the default.

So I have modified the build process to detect the broken ranlib (in a
bit of a nasty way, someone please fix this when you have a better
idea), and added the -c flag if the OSX version is found.

Here's expected behaviour on the two major operating systems we care
about. Patches accepted for solaris and bsd especially.

apple$ ranlib -c 2>/dev/null ; echo $?
1
debian$ ranlib -c 2>/dev/null ; echo $?
0

Attached here, and in the shiny repo.

--=20
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange

------=_Part_10348_7869479.1147865084723
Content-Type: application/octet-stream; name=ranlib-patch.dpatch
Content-Transfer-Encoding: 7bit
X-Attachment-Id: f_enbl4dp8
Content-Disposition: attachment; filename="ranlib-patch.dpatch"


New patches:

[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] {
hunk ./Vanilla/ChangeLog 1
+
+Wed May 17 11:12:04 2006  Stephen Thorne  <stephen at thorne.id.au>
+
+    * ntserv/Makefile.in (libnetrek.a): Pass @RANLIB_FLAGS@ to the ranlib
+    command.
+
+    * configure.in: Check for if ranlib exits with a non-zero exit when run
+    with a bare '-c' option. On debian, ranlib will exit with a 0 exit code
+    if passed a filename that doesen't exist. On OSX, '-c' is a valid flag, 
+    and if passed alone, will exit with an exit code of 1. A better way of
+    detecting this would be nice. If using the OSX version, then we pass -c
+    to all ranlib calls. Fixes build bug on OSX.
+
hunk ./Vanilla/configure.in 481
+
+AC_MSG_CHECKING(for OSX ranlib)
+RANLIB_FLAGS=
+if ranlib -c 2>/dev/null; then
+    AC_MSG_RESULT(good - no)
+else
+    RANLIB_FLAGS='-c'
+    AC_MSG_RESULT(drat - yes)
+fi
+
+AC_SUBST(RANLIB_FLAGS)
hunk ./Vanilla/ntserv/Makefile.in 90
-	ranlib $@
+	ranlib @RANLIB_FLAGS@ $@
}

Context:

[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
ed8efe77ed3768fff103c179279580bd3948d38f



------=_Part_10348_7869479.1147865084723--


From netrek at gmail.com  Wed May 17 10:14:33 2006
From: netrek at gmail.com (Zach)
Date: Wed, 17 May 2006 11:14:33 -0400
Subject: [netrek-dev] continuum bug
Message-ID: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>

when i joined kli slot Kf was stale

we ejected the slot:

"The motion to EJECT f passes"

however even after t-mode later began the slot is still there and wasn't cleared

sending @ or ! to the slot produces nothing

the slot does count towards t-mode though since we have only 3 players
and there's t now

Kf is Flt. Capt. HeadCheese (Login: critter)

it's been about 15 mins. and the stale slot is till there

zach


From jrd at gerdesas.com  Wed May 17 10:20:56 2006
From: jrd at gerdesas.com (John R. Dennison)
Date: Wed, 17 May 2006 10:20:56 -0500
Subject: [netrek-dev] continuum bug
In-Reply-To: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>
References: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>
Message-ID: <20060517152056.GK2259@gerdesas.gerdesas.com>

On Wed, May 17, 2006 at 11:14:33AM -0400, Zach wrote:
> 
> Kf is Flt. Capt. HeadCheese (Login: critter)
> 
> it's been about 15 mins. and the stale slot is till there

	That slot has been there since at least 2200 CDT last night.




							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt


From niclas at acc.umu.se  Wed May 17 10:22:35 2006
From: niclas at acc.umu.se (Niclas Fredriksson)
Date: Wed, 17 May 2006 17:22:35 +0200 (MEST)
Subject: [netrek-dev] continuum bug
In-Reply-To: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>
References: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0605171721450.5817@shaka.acc.umu.se>

On Wed, 17 May 2006, Zach wrote:

> when i joined kli slot Kf was stale
>
> we ejected the slot:
>
> "The motion to EJECT f passes"

You can't eject busted slots.

There was a brief period of time when the eject command freed the slot, 
but that's not how it works now.

--Niclas


From netrek at gmail.com  Wed May 17 10:28:46 2006
From: netrek at gmail.com (Zach)
Date: Wed, 17 May 2006 11:28:46 -0400
Subject: [netrek-dev] feature request
Message-ID: <ecfa260c0605170828g73d7a55ex492e965877fa5fa8@mail.gmail.com>

it's 5v5 (well really 5+1 cause of dead slot f) so oris make it 6v5
then 6v4 then 7v4 then 8v4!
disgusting. server really shouldn't allow this. we need some type of
balance mechanism even if it's nothing more than a fprint("Please <x>
<foo> join <bar>")

or put something in the motd

zach


From stephen.thorne at gmail.com  Wed May 17 15:57:06 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 06:57:06 +1000
Subject: [netrek-dev] feature request
In-Reply-To: <ecfa260c0605170828g73d7a55ex492e965877fa5fa8@mail.gmail.com>
References: <ecfa260c0605170828g73d7a55ex492e965877fa5fa8@mail.gmail.com>
Message-ID: <3e8ca5c80605171357v16d746d1q6c35dbb012de5d0c@mail.gmail.com>

On 5/18/06, Zach <netrek at gmail.com> wrote:
> it's 5v5 (well really 5+1 cause of dead slot f) so oris make it 6v5
> then 6v4 then 7v4 then 8v4!
> disgusting. server really shouldn't allow this. we need some type of
> balance mechanism even if it's nothing more than a fprint("Please <x>
> <foo> join <bar>")

Please write up this suggestion in the wiki.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From quozl at us.netrek.org  Wed May 17 18:10:11 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 18 May 2006 09:10:11 +1000
Subject: [netrek-dev] slot hang diagnosis
Message-ID: <20060517231011.GB5742@us.netrek.org>

Now that vicious eject is disabled, we've valuable evidence showing what
causes slot hangs.  I'm working on diagnosing this, but in the meanwhile
here is what the core file says in gdb about the process state:

(gdb) bt
#0  0x401751fe in read () from /lib/tls/libc.so.6
#1  0x08055099 in doRead (asock=5) at socket.c:1002
#2  0x08055925 in readFromClient () at socket.c:938
#3  0x0804dc48 in input () at input.c:152
#4  0x080503b5 in main (argc=Variable "argc" is not available.
) at main.c:437

And lsof shows the TCP connection down but the UDP connection still up:

COMMAND   PID  USER   FD   TYPE  DEVICE    SIZE       NODE NAME
ntserv  20876 quozl    0u  sock     0,4            4364912 can't identify protocol
ntserv  20876 quozl    1w   REG     8,1   35566     130991 /usr/games/continuum/var/ERRORS
ntserv  20876 quozl    2w   REG     8,1   35566     130991 /usr/games/continuum/var/ERRORS
ntserv  20876 quozl    3w   REG     8,1   35566     130991 /usr/games/continuum/var/ERRORS
ntserv  20876 quozl    4w   REG     8,1   16639     130994 /usr/games/continuum/var/god.LOG
ntserv  20876 quozl    5u  IPv4 4364929                UDP 208.20.202.42:39737->70.172.223.17:12415 

And strace shows continuous calls to read the UDP socket being
interrupted by SIGALRM (the daemon synchronisation signal):

read(5, 0xbfffb8c0, 16384)              = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [CHLD])
read(5, 0xbfffb8c0, 16384)              = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [CHLD])

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


From jimmyhua73 at yahoo.com  Wed May 17 20:41:21 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 17 May 2006 18:41:21 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
Message-ID: <20060518014121.80653.qmail@web35313.mail.mud.yahoo.com>

Well, the robots in robotd have stopped crashing after
these "few" changes. 

plan to test some more. But there were alot of
changes, so putting them in a patch. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clearingcrashes1.dpatch
Type: application/octet-stream
Size: 9511 bytes
Desc: 3379738479-clearingcrashes1.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060517/3989151c/attachment.obj 

From quozl at us.netrek.org  Wed May 17 22:01:17 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Thu, 18 May 2006 13:01:17 +1000
Subject: [netrek-dev] darcs patch: move wdt reset from SIGALRM handler to
	input handler
Message-ID: <E1FgYlJ-0004CN-3y@dors.lan>

Thu May 18 12:44:16 EST 2006  quozl at us.netrek.org
  * move wdt reset from SIGALRM handler to input handler
  Slots may jam in POUTFIT after KWINNER if the user terminates
  the client ungracefully ... such that the TCP connection is gone but
  the ntserv lives on.
  
  During this time, daemon synchronisation still sends SIGALRM to the
  ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
  timer.
  
  Prototype solution is to move p_ghostbust watchdog timer reset from
  within the SIGALRM handler to the section of main loop that is
  executed when input arrives from the client.
  
  Monitoring the p_ghostbust timer with gdb shows it is now reset for a
  dormant client on receipt of ping responses.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 3991 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060518/2c3d4132/attachment-0001.bin 

From stephen.thorne at gmail.com  Wed May 17 22:01:41 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 13:01:41 +1000
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <20060518014121.80653.qmail@web35313.mail.mud.yahoo.com>
References: <20060518014121.80653.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605172001n4c9c8b2fx8a89d1cd3da11274@mail.gmail.com>

On 5/18/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Well, the robots in robotd have stopped crashing after
> these "few" changes.
>
> plan to test some more. But there were alot of
> changes, so putting them in a patch.

I get a patch bundle checksum failure...

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From ahn at orion.netrek.org  Wed May 17 22:23:07 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Wed, 17 May 2006 23:23:07 -0400
Subject: [netrek-dev] newbie patch again
In-Reply-To: <3e8ca5c80605162009n56f7237dhd42ff40117975129@mail.gmail.com>
References: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605161805160.16977@shell2.speakeasy.net>
	<3e8ca5c80605162009n56f7237dhd42ff40117975129@mail.gmail.com>
Message-ID: <20060518032307.GA26994@orion.netrek.org>

On Wed, May 17, 2006 at 01:09:44PM +1000, Stephen Thorne wrote:
> 
> [...] I've gone through and changed
> the indentation for some of the newbie.c file, and updated my repo on
> shiny (see source control).

There are several code formatters like astyle that can be used to
enforce a certain style.  It may not be a bad idea to run it on the
code, verify the changes for correctness, then commit these changes to
revision control.  I've seen this work quite successfully with several
commercial and open source projects with minor effort required to
maintain cleanly formatted code.



From stephen.thorne at gmail.com  Wed May 17 22:40:08 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 13:40:08 +1000
Subject: [netrek-dev] newbie patch again
In-Reply-To: <20060518032307.GA26994@orion.netrek.org>
References: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605161805160.16977@shell2.speakeasy.net>
	<3e8ca5c80605162009n56f7237dhd42ff40117975129@mail.gmail.com>
	<20060518032307.GA26994@orion.netrek.org>
Message-ID: <3e8ca5c80605172040l5a07de1fk2e6123d4dbc883b1@mail.gmail.com>

On 5/18/06, Dave Ahn <ahn at orion.netrek.org> wrote:
> On Wed, May 17, 2006 at 01:09:44PM +1000, Stephen Thorne wrote:
> >
> > [...] I've gone through and changed
> > the indentation for some of the newbie.c file, and updated my repo on
> > shiny (see source control).
>
> There are several code formatters like astyle that can be used to
> enforce a certain style.  It may not be a bad idea to run it on the
> code, verify the changes for correctness, then commit these changes to
> revision control.  I've seen this work quite successfully with several
> commercial and open source projects with minor effort required to
> maintain cleanly formatted code.

I hesitate to do this to the repo. It would make rolling
back/cherrypicking patches very difficult.

I think at this point, my policy is, only fix the indentation if
you're also modifying the surrounding code. I'm willing to even say
that fixing only half a function's indentation is ok.

It sucks, but it's not like it's life-or-death. :)

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Wed May 17 22:42:36 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 13:42:36 +1000
Subject: [netrek-dev] darcs patch: move wdt reset from SIGALRM handler
	to input handler
In-Reply-To: <E1FgYlJ-0004CN-3y@dors.lan>
References: <E1FgYlJ-0004CN-3y@dors.lan>
Message-ID: <3e8ca5c80605172042q5bb4266cue95950eb9be74326@mail.gmail.com>

On 5/18/06, quozl at us.netrek.org <quozl at us.netrek.org> wrote:
> Thu May 18 12:44:16 EST 2006  quozl at us.netrek.org
>   * move wdt reset from SIGALRM handler to input handler

Taken. This caused a conflict because of ChangeLog, I resolved that
and pushed a patch to shiny.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Wed May 17 22:57:59 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 17 May 2006 20:57:59 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <20060518014121.80653.qmail@web35313.mail.mud.yahoo.com>
References: <20060518014121.80653.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605172012000.9545@shell2.speakeasy.net>

 1. Anywhere where me_p is called, it is first initialized to something
 sane at the beginning of that function. Dunno if this is necessary, but
 it doesn't hurt.

This is not what you are doing.  You are defining a new local variable
called me_p that is overriding the global one.  Bad coding style.  If me_p
is getting called before it is initialized in socket.c, you should figure
out why and fix it.

 2. Anywhere where me_p->closest_pl or p->closest_pl is NULL'd out, I
 re-wrote the code so it leaves it alone. p->closest_pl = NULL.
 For some reason, once this is done, closest_pl stays NULL for the
 rest of the program until you kill the program and restart it.

It's clear that setting closest_pl to NULL means something, that the player
isn't near a planet.  Setting it to some random planet will just make the
bot make mistakes.  What would be the correct thing to do, would be to fix
the bug in closest_planet() that makes it fail, rather than just making
random changes with no clue what effect they will have.

BTW, the bug in closest_planet can fix be fixed thusly:
--- update_players.c.old        Wed May 17 20:52:41 2006
+++ update_players.c    Wed May 17 20:50:11 2006
@@ -1320,7 +1320,7 @@

 {
    register                    k;
-   register struct planet      *pl, *rp = NULL;
+   register struct planet      *pl, *rp = opl;
    register                    d, mdist = INT_MAX;

    if(opl && (mdist = ihypot((double)(j->p_x - opl->pl_x),

Sorry, I'm too lazy to install yet another revision control system.

 3. Replaced all instances of mfprintf with regular fprintf. mfprintf
 causes SIGSEVs, but I don't know why. Function looks fine to me, but it
 extensively uses parameter overlloading, it's tough to debug. So
 just don't use it!!!

It probably has to do with it using varargs instead of stdargs.  You
should convert it to stdargs.

 4. Added some code somewhere to check "pl" is good. Every once in a
 while, this turns into NULL for unknown reasons. The situation clears
 itself after a while.

Again, find out why it's set to NULL, and fix that.


From ahn at orion.netrek.org  Wed May 17 22:57:47 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Wed, 17 May 2006 23:57:47 -0400
Subject: [netrek-dev] newbie patch again
In-Reply-To: <3e8ca5c80605172040l5a07de1fk2e6123d4dbc883b1@mail.gmail.com>
References: <20060516233956.43657.qmail@web35306.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605161805160.16977@shell2.speakeasy.net>
	<3e8ca5c80605162009n56f7237dhd42ff40117975129@mail.gmail.com>
	<20060518032307.GA26994@orion.netrek.org>
	<3e8ca5c80605172040l5a07de1fk2e6123d4dbc883b1@mail.gmail.com>
Message-ID: <20060518035747.GA27040@orion.netrek.org>

On Thu, May 18, 2006 at 01:40:08PM +1000, Stephen Thorne wrote:
> 
> I hesitate to do this to the repo. It would make rolling
> back/cherrypicking patches very difficult.
> 
> I think at this point, my policy is, only fix the indentation if
> you're also modifying the surrounding code. I'm willing to even say
> that fixing only half a function's indentation is ok.
> 
> It sucks, but it's not like it's life-or-death. :)

Reformatting an existing base of code is certainly a hassle, but
the path of least resistence will result in the status quo.  It would
seem to me that with the recent renewed development efforts and the
upcoming move to a darcs repository, taking the initiative to baseline
the code style might make future efforts much less painful.  But then,
it's definitely not life-or-death...



From quozl at us.netrek.org  Wed May 17 23:16:52 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 18 May 2006 14:16:52 +1000
Subject: [netrek-dev] continuum bug
In-Reply-To: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>
References: <ecfa260c0605170814n704dc8d2h9398efdb768fde44@mail.gmail.com>
Message-ID: <20060518041652.GF5742@us.netrek.org>

Yes, Kf slot was hung, apparently after a geno or conquer.

Slot free mode of eject is off so that we can capture the cause of the
hung slot and fix it.  A cause has been identified and the code changed.

If you see it happen again, please report it.

If you talk to HeadCheese, I'm interested to know if she remembers what
she did when the game ended.  We'd like to learn how to cause this so we
can prove we've fixed it.  This is called a "test case".

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


From jimmyhua73 at yahoo.com  Wed May 17 23:27:35 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 17 May 2006 21:27:35 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <Pine.LNX.4.58.0605172012000.9545@shell2.speakeasy.net>
Message-ID: <20060518042735.55851.qmail@web35303.mail.mud.yahoo.com>


Hey Trent, 

Thanks for your wise words. 

--- Trent Piepho <xyzzy at speakeasy.org> wrote:

>  1. Anywhere where me_p is called, it is first
> initialized to something
>  sane at the beginning of that function. Dunno if
> this is necessary, but
>  it doesn't hurt.
> 
> This is not what you are doing.  You are defining a
> new local variable
> called me_p that is overriding the global one.  Bad
> coding style.  If me_p
> is getting called before it is initialized in
> socket.c, you should figure
> out why and fix it.

Thanks for clearing this up. I wish I knew
programming. But I really don't. I'll try removing
these local variables and see if it starts crashing
again. I have a  feeling, it won't.

>  2. Anywhere where me_p->closest_pl or p->closest_pl
> is NULL'd out, I
>  re-wrote the code so it leaves it alone.
> p->closest_pl = NULL.
>  For some reason, once this is done, closest_pl
> stays NULL for the
>  rest of the program until you kill the program and
> restart it.
> 
> It's clear that setting closest_pl to NULL means
> something, that the player
> isn't near a planet.  Setting it to some random
> planet will just make the
> bot make mistakes.  What would be the correct thing
> to do, would be to fix
> the bug in closest_planet() that makes it fail,
> rather than just making
> random changes with no clue what effect they will
> have.

Been reading through that code. There's no reason why
closest_pl should ever get set to NULL. There's ALWAYS
a closest planet.

The reason closest_pl gets set to NULL is because the
enemy player cloaks, and so the client has no
information. It sets it to NULL instead of some
possibly dubious planet. I think leaving stale
information such as this should actually be to the
bots advantage. The code change, makes it so it just
leaves it alone instead of setting it to NULL. 

> 
> BTW, the bug in closest_planet can fix be fixed
> thusly:
> --- update_players.c.old        Wed May 17 20:52:41
> 2006
> +++ update_players.c    Wed May 17 20:50:11 2006
> @@ -1320,7 +1320,7 @@
> 
>  {
>     register                    k;
> -   register struct planet      *pl, *rp = NULL;
> +   register struct planet      *pl, *rp = opl;
>     register                    d, mdist = INT_MAX;
> 
>     if(opl && (mdist = ihypot((double)(j->p_x -
> opl->pl_x),
> 

Hey! I think that would work! I should add that in
too! 

> Sorry, I'm too lazy to install yet another revision
> control system.

no problem. 

>  3. Replaced all instances of mfprintf with regular
> fprintf. mfprintf
>  causes SIGSEVs, but I don't know why. Function
> looks fine to me, but it
>  extensively uses parameter overlloading, it's tough
> to debug. So
>  just don't use it!!!
> 
> It probably has to do with it using varargs instead
> of stdargs.  You
> should convert it to stdargs.

Heh. I wish I knew what you are talking about. I don't
know enough about c to know how to fix this.

>  4. Added some code somewhere to check "pl" is good.
> Every once in a
>  while, this turns into NULL for unknown reasons.
> The situation clears
>  itself after a while.
> 
> Again, find out why it's set to NULL, and fix that.

I plan to do that, as I am sure there are some
consequences (even though they don't crash anymore). 
I originally did the same thing to 
test for NULL'ness for me_p->closest_pl. And just
avoid the SIGSEV. This resulted in bots that started
to not report where they wanted to take their armies
to. 


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



From jimmyhua73 at yahoo.com  Wed May 17 23:30:40 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 17 May 2006 21:30:40 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <3e8ca5c80605172001n4c9c8b2fx8a89d1cd3da11274@mail.gmail.com>
Message-ID: <20060518043040.20475.qmail@web35315.mail.mud.yahoo.com>

Hi Stephen, 

I read Trent's comments on my code. And am planning to
make improvements. 

If you haven't applied the patch already. Don't. I
plan to darcs unrecord my changes here and make more
improvements based on Trent's comments. 

Jimmy


--- Stephen Thorne <stephen.thorne at gmail.com> wrote:

> On 5/18/06, Jimmy Huang <jimmyhua73 at yahoo.com>
> wrote:
> > Well, the robots in robotd have stopped crashing
> after
> > these "few" changes.
> >
> > plan to test some more. But there were alot of
> > changes, so putting them in a patch.
> 
> I get a patch bundle checksum failure...
> 
> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I
> will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> 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 May 18 01:10:17 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 18 May 2006 16:10:17 +1000
Subject: [netrek-dev] interesting newbie bug
In-Reply-To: <20060517072608.16900.qmail@web35307.mail.mud.yahoo.com>
References: <20060517072608.16900.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <20060518061017.GH5742@us.netrek.org>

On Wed, May 17, 2006 at 12:26:08AM -0700, Jimmy Huang wrote:
> 1. Make the bots smart enough to finish the game. 

That's certainly how I think it should happen.

A scriptable robot spawned by the server as soon as the timer expires
might be the way to do it.  "Get kills, pick up, take that planet."

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


From quozl at us.netrek.org  Thu May 18 01:41:43 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Thu, 18 May 2006 16:41:43 +1000
Subject: [netrek-dev] darcs patch: add setteam utility (and 1 more)
Message-ID: <E1FgcCd-0005eV-DN@dors.lan>

Thu May 18 15:59:20 EST 2006  quozl at us.netrek.org
  * add setteam utility
  Add a utility for viewing and changing the starbase reconstruction timer
  and surrender timer, both of which are in struct teams.  Although these
  timers can be manipulated by other means, setteam makes it easier to 
  script.
  
  Some common code now exists in setplanet.c and setteam.c that deserves
  factorisation.

Thu May 18 16:12:57 EST 2006  quozl at us.netrek.org
  * add setteam utility source
  The actual source now, so that builds complete.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 9331 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060518/194dd3c3/attachment.bin 

From jimmyhua73 at yahoo.com  Thu May 18 01:52:59 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 17 May 2006 23:52:59 -0700 (PDT)
Subject: [netrek-dev] interesting newbie bug
In-Reply-To: <20060518061017.GH5742@us.netrek.org>
Message-ID: <20060518065259.2617.qmail@web35304.mail.mud.yahoo.com>

Hi James, 

I've been digging through the robotd code fixing
something else. 

And, thanks to Trent's insistence I find out why pl is
NULL sometimes. I figured out the logic in the
check_take function in decide.c was basically flawed. 

It also explains why the bots don't like to take
neutral planets, unless certain oddball conditions are
met. 

I have summarily wiped out those oddball conditions
(the independent planet had to be Non-Agri OR the bot
had to have more than 4 armies???). Hopefully, this
will fix it. (I think human players will hate this
fix, as they can't run around behind the bots
finishing their takes now.)  And fix the funny
stalemate condition. 

Also, don't apply the patch I sent out today. Trent
pointed out some major problems with it -- mostly due
to my ignorance in c programming. I did a darcs
unrecord on my side already. 

Anyways, on with the code testing with gdb robot, and
I'll see if this works. 

Jimmy

--- James Cameron <quozl at us.netrek.org> wrote:

> On Wed, May 17, 2006 at 12:26:08AM -0700, Jimmy
> Huang wrote:
> > 1. Make the bots smart enough to finish the game. 
> 
> That's certainly how I think it should happen.
> 
> A scriptable robot spawned by the server as soon as
> the timer expires
> might be the way to do it.  "Get kills, pick up,
> take that planet."
> 
> -- 
> 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 jimmyhua73 at yahoo.com  Thu May 18 02:44:59 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 00:44:59 -0700 (PDT)
Subject: [netrek-dev] interesting newbie bug
In-Reply-To: <20060518065259.2617.qmail@web35304.mail.mud.yahoo.com>
Message-ID: <20060518074459.13568.qmail@web35305.mail.mud.yahoo.com>

Code testing worked!

Bots take neutral planets no problems, including the
ones after a timercide.  This of course, causes the
genocide!

Jimmy

--- Jimmy Huang <jimmyhua73 at yahoo.com> wrote:

> Hi James, 
> 
> I've been digging through the robotd code fixing
> something else. 
> 
> And, thanks to Trent's insistence I find out why pl
> is
> NULL sometimes. I figured out the logic in the
> check_take function in decide.c was basically
> flawed. 
> 
> It also explains why the bots don't like to take
> neutral planets, unless certain oddball conditions
> are
> met. 
> 
> I have summarily wiped out those oddball conditions
> (the independent planet had to be Non-Agri OR the
> bot
> had to have more than 4 armies???). Hopefully, this
> will fix it. (I think human players will hate this
> fix, as they can't run around behind the bots
> finishing their takes now.)  And fix the funny
> stalemate condition. 
> 
> Also, don't apply the patch I sent out today. Trent
> pointed out some major problems with it -- mostly
> due
> to my ignorance in c programming. I did a darcs
> unrecord on my side already. 
> 
> Anyways, on with the code testing with gdb robot,
> and
> I'll see if this works. 
> 
> Jimmy
> 
> --- James Cameron <quozl at us.netrek.org> wrote:
> 
> > On Wed, May 17, 2006 at 12:26:08AM -0700, Jimmy
> > Huang wrote:
> > > 1. Make the bots smart enough to finish the
> game. 
> > 
> > That's certainly how I think it should happen.
> > 
> > A scriptable robot spawned by the server as soon
> as
> > the timer expires
> > might be the way to do it.  "Get kills, pick up,
> > take that planet."
> > 
> > -- 
> > 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
> > 
> 
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From xyzzy at speakeasy.org  Thu May 18 03:01:03 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 18 May 2006 01:01:03 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <20060518042735.55851.qmail@web35303.mail.mud.yahoo.com>
References: <20060518042735.55851.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605180034380.14574@shell3.speakeasy.net>

On Wed, 17 May 2006, Jimmy Huang wrote:
> > It's clear that setting closest_pl to NULL means
> > something, that the player
> > isn't near a planet.  Setting it to some random
> > planet will just make the
> > bot make mistakes.  What would be the correct thing
> > to do, would be to fix
> > the bug in closest_planet() that makes it fail,
> > rather than just making
> > random changes with no clue what effect they will
> > have.
>
> Been reading through that code. There's no reason why
> closest_pl should ever get set to NULL. There's ALWAYS
> a closest planet.
>
> The reason closest_pl gets set to NULL is because the
> enemy player cloaks, and so the client has no
> information. It sets it to NULL instead of some

Doesn't need to cloak, just be far enough away that it's not visisble to
the bot.

I think if keeping the stale information around was a good idea, Hadley
would have done that.  He clearly detects invisible players, and sets the
closest planet to NULL, then checks for this everytime closest_pl is
examined.

Also, have you considered what happens when the bots first joins, and has
never seen where some player is?  What will closest_pl be, some random
uninitialized data?  NULL anyway?

> Hey! I think that would work! I should add that in
> too!

That is a fix for the real bug.  The closest planet would get set to NULL
every other update.  Once that is fixed, me_p->closest_pl should never be
NULL.  p->closest_pl may be NULL for an invisible player, but every use of
that is always checked for NULL first.

> I plan to do that, as I am sure there are some
> consequences (even though they don't crash anymore).
> I originally did the same thing to
> test for NULL'ness for me_p->closest_pl. And just
> avoid the SIGSEV. This resulted in bots that started
> to not report where they wanted to take their armies
> to.

There is a bug in the function that generates RCDs.  I fixed it months ago,
but since CVS was down I never committed it.  The bot will crash if it
tries to bomb or take and can't see any friendly or any enemy players.

If you want to fix mfprintf, man stdarg



From williamb at its.caltech.edu  Thu May 18 03:17:35 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Thu, 18 May 2006 03:17:35 -0500
Subject: [netrek-dev] darcs patch: ATT fixes
Message-ID: <200605180817.k4I8HZvZ003884@omen.digital-genesis.com>

Thu May 18 03:16:58 CDT 2006  williamb at its.caltech.edu
  * ATT fixes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 875 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060518/0581d53b/attachment.bin 

From xyzzy at speakeasy.org  Thu May 18 04:11:22 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 18 May 2006 02:11:22 -0700 (PDT)
Subject: [netrek-dev] interesting newbie bug
In-Reply-To: <20060518065259.2617.qmail@web35304.mail.mud.yahoo.com>
References: <20060518065259.2617.qmail@web35304.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605180106160.14574@shell3.speakeasy.net>

On Wed, 17 May 2006, Jimmy Huang wrote:
> And, thanks to Trent's insistence I find out why pl is
> NULL sometimes. I figured out the logic in the
> check_take function in decide.c was basically flawed.

It seems like you're not totally clear on the difference between local
variables and global variables.  The variable named pl in check_take() has
nothing to do with other variables of the same name in different functions.
If you have a C programming tutorial, you might want to read the bit about
local variables.

> It also explains why the bots don't like to take
> neutral planets, unless certain oddball conditions are
> met.
>
> I have summarily wiped out those oddball conditions
> (the independent planet had to be Non-Agri OR the bot
> had to have more than 4 armies???). Hopefully, this

You're wrong about that.  That code in check_take() is not checking an
independant planet, it is checking the last enemy planet it looked at in
the preceeding for loop.  (The one that looks for the closest enemy planet)

The check (!(pl->pl_flags & PLAGRI) || me->p_armies >= 5) actually makes
plenty of sense.  It is the common netrek wisdom, "don't drop armies on an
agri unless you have enough to take it."

The reason for a crash here is that when Hadley wrote the bot, there were
always enemy planets.  If you took all the enemy planets, the game was
over.  The bot would never try take a planet with only neut planets left in
the game.  Thus the case when the loop for(k=0; k< pls->num_warteamsp; k++)
never executed at all never came up, and pl was never left unset.  The bot
never had to cope with just neut planets left to take.

You are right that there is a bug in the check that surrounds the search
for neut planets.  First, it checks the last planet in the list of enemy
planets.  This list isn't in any order, so it's checking if some random
enemy planet is no agri.  Doesn't make sense.  What Hadley probably meant
to check was tpl, the target enemy planet, rather than pl.

Still, the check doesn't make sense.  What it's doing is only looking for
ind planets if the bot CAN take the closest enemy planet.  The logic is
like this:

Closest enemy planet is non-agri -> look for neut planets, take them first
Closest enemy planet is agri, but I have 5 armies -> look for neut planets,
take them first
Closest enemy planet is agri, and I don't have 5 armies -> don't try to
take neut planets

That makes no sense.  The bot would rather drop 2 on an agri than take a
neut planet.  This is the correct fix:

-   if(!(pl->pl_flags & PLAGRI) || me->p_armies >= 5){
+   if(!tpl || !(tpl->pl_flags & PLAGRI) || me->p_armies < 5){

Now the logic is:

There are no acceptable enemy planets -> look for ind ones (*)
The closest enemy planet is agri and I have five or more armies -> skip
looking for neut planets, the agri take is better
All other cases, look for nuet planets and take them before enemy planets

I think this logic is probably what Hadley intended to write, he just got
the logic backwards for the army check.


From jimmyhua73 at yahoo.com  Thu May 18 04:32:40 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 02:32:40 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <Pine.LNX.4.58.0605180034380.14574@shell3.speakeasy.net>
Message-ID: <20060518093240.23447.qmail@web35309.mail.mud.yahoo.com>


--- Trent Piepho <xyzzy at speakeasy.org> wrote:
> I think if keeping the stale information around was
> a good idea, Hadley
> would have done that.  He clearly detects invisible
> players, and sets the
> closest planet to NULL, then checks for this
> everytime closest_pl is
> examined.

This is true. I spoke to Hadley many eons ago. And he
doesn't like to keep stale information while I do. I
made a mod to his code a LONG time ago, where it kept
the x & y coordinates of enemy carriers even though
they were way off the screen and/or cloaked. It seemed
to help... back then. I have no idea if that code ever
got propagated back into here though. 

Anyways, baby steps and lots of testing. I'll keep the
if invisible -> set to NULL. And run it through the
debugger for a couple hours and see if it still
crashes at that point, as I am only interested in
making the code run stable for now. 

> Also, have you considered what happens when the bots
> first joins, and has
> never seen where some player is?  What will
> closest_pl be, some random
> uninitialized data?  NULL anyway?

Yeah yeah. I see your point. 

> > I plan to do that, as I am sure there are some
> > consequences (even though they don't crash
> anymore).
> > I originally did the same thing to
> > test for NULL'ness for me_p->closest_pl. And just
> > avoid the SIGSEV. This resulted in bots that
> started
> > to not report where they wanted to take their
> armies
> > to.

You probably already read this in a previous e-mail.
But, the call for pl in check_take seems to be not
well thought out. I took the whole if statement block
out, and kept what was inside the block, and the code
runs much better. 

was:

if(!(pl->pl_flags & PLAGRI) || me->p_armies >= 5){
   min_dist = GWIDTH;	/* ind overrides non-ind */
   for(k=0; k< pls->num_indsp; k++){
       pl = pls->ind_planets[k];
       if(pl->pl_mydist < min_dist){
	   tpl = pl;
	   min_dist = pl->pl_mydist;
       }
   }

}

now:

   min_dist = GWIDTH;	/* ind overrides non-ind */
   for(k=0; k< pls->num_indsp; k++){
       pl = pls->ind_planets[k];
        if(pl->pl_mydist < min_dist){
	   tpl = pl;
	   min_dist = pl->pl_mydist;
       }
   }

The pl->pl_flags is referring to a previous for-loop.
The last planet of warteams_planets... Non-sensical...
Why a if statement referring to the last warteams
planet? 

> There is a bug in the function that generates RCDs. 
> I fixed it months ago,
> but since CVS was down I never committed it.  The
> bot will crash if it
> tries to bomb or take and can't see any friendly or
> any enemy players.

Cool. e-mail me the related files, and I can manually
patch. 

> If you want to fix mfprintf, man stdarg

I was thinking about simply getting rid of it.  Have
any idea why use mfprintf instead of regular fprintf?

Anyways, I'll give reading "man stdargs" a try and
hope I can make some sense out of it. 

Jimmy


From jimmyhua73 at yahoo.com  Thu May 18 04:47:00 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 02:47:00 -0700 (PDT)
Subject: [netrek-dev] interesting newbie bug
In-Reply-To: <Pine.LNX.4.58.0605180106160.14574@shell3.speakeasy.net>
Message-ID: <20060518094700.64250.qmail@web35313.mail.mud.yahoo.com>

> This is the correct fix:
> 
> -   if(!(pl->pl_flags & PLAGRI) || me->p_armies >=
> 5){
> +   if(!tpl || !(tpl->pl_flags & PLAGRI) ||
> me->p_armies < 5){
> 
> Now the logic is:
> 
> There are no acceptable enemy planets -> look for
> ind ones (*)
> The closest enemy planet is agri and I have five or
> more armies -> skip
> looking for neut planets, the agri take is better
> All other cases, look for nuet planets and take them
> before enemy planets
> 
> I think this logic is probably what Hadley intended
> to write, he just got
> the logic backwards for the army check.

Hey Trent, U R much better at figuring out what a
person intended to write than I am!

That looks right! It's definitely better than me just
getting rid of the errant code. 

I'll need to stick your name into the patches I
submit.

Jimmy


From stephen.thorne at gmail.com  Thu May 18 04:46:20 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 19:46:20 +1000
Subject: [netrek-dev] darcs patch: ATT fixes
In-Reply-To: <200605180817.k4I8HZvZ003884@omen.digital-genesis.com>
References: <200605180817.k4I8HZvZ003884@omen.digital-genesis.com>
Message-ID: <3e8ca5c80605180246l60a9a285odc17b709421bad62@mail.gmail.com>

On 5/18/06, williamb at its.caltech.edu <williamb at its.caltech.edu> wrote:
> Thu May 18 03:16:58 CDT 2006  williamb at its.caltech.edu
>   * ATT fixes

Simple enough, taken.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Thu May 18 05:18:41 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 20:18:41 +1000
Subject: [netrek-dev] ChangeLog and revision control
Message-ID: <3e8ca5c80605180318v7afe4dbat3361a2a590ca0fdf@mail.gmail.com>

I've been having a bit of trouble integrating patches in the last few
days, the problem occurs when

a) ChangeLog entries are used
b) Two developers submit patches concurrently.

It results in me (the person who applies the patch) having to apply
the patch and resolve the 'conflict' (lines added to ChangeLog).

I'm not sure how to solve this. Not using ChangeLog anymore would
suck, but having weird patch dependancies and conflicts because every
patch hits the ChangeLog is annoying.

Two solutions come to mind.

1) Rely on commit messages instead, exclusively, and leave ChangeLog as a relic.

2) Mandate that ChangeLog formatted messages must be put into the
darcs 'long comment', and the person integrataing the patch into the
upstream repo copies those messages out of the commit messages into
the ChangeLog, and records that as a new patch.

I can see a lot of reistance to (1).

(2) is a lot of work, but at the moment that's zero sum - I'm already
doing a record for every conflict.

Can anyone else see other solutions?
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Thu May 18 06:03:32 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 18 May 2006 04:03:32 -0700 (PDT)
Subject: [netrek-dev] ChangeLog and revision control
In-Reply-To: <3e8ca5c80605180318v7afe4dbat3361a2a590ca0fdf@mail.gmail.com>
References: <3e8ca5c80605180318v7afe4dbat3361a2a590ca0fdf@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0605180343160.21521@shell3.speakeasy.net>

On Thu, 18 May 2006, Stephen Thorne wrote:
> 2) Mandate that ChangeLog formatted messages must be put into the
> darcs 'long comment', and the person integrataing the patch into the
> upstream repo copies those messages out of the commit messages into
> the ChangeLog, and records that as a new patch.

Is there some sort of commit hook that can do this automatically?

I have used CVS where a commit script would automatically create entries in a
changelog file.

None of the projects I work on now have a change log file that developers need
to update.  As you've found, it doesn't work for concurrent development, and
besides, that's what the versioning system is for.  Of course Vanilla has a
history of thowing away the version history every so often, so all those darcs
comments are just going to get lost.


From stephen.thorne at gmail.com  Thu May 18 06:14:47 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 18 May 2006 21:14:47 +1000
Subject: [netrek-dev] ChangeLog and revision control
In-Reply-To: <Pine.LNX.4.58.0605180343160.21521@shell3.speakeasy.net>
References: <3e8ca5c80605180318v7afe4dbat3361a2a590ca0fdf@mail.gmail.com>
	<Pine.LNX.4.58.0605180343160.21521@shell3.speakeasy.net>
Message-ID: <3e8ca5c80605180414s3181536br6a25ecb124d1b41a@mail.gmail.com>

On 5/18/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> On Thu, 18 May 2006, Stephen Thorne wrote:
> > 2) Mandate that ChangeLog formatted messages must be put into the
> > darcs 'long comment', and the person integrataing the patch into the
> > upstream repo copies those messages out of the commit messages into
> > the ChangeLog, and records that as a new patch.
>
> Is there some sort of commit hook that can do this automatically?
>
> I have used CVS where a commit script would automatically create entries in a
> changelog file.
>
> None of the projects I work on now have a change log file that developers need
> to update.  As you've found, it doesn't work for concurrent development, and
> besides, that's what the versioning system is for.  Of course Vanilla has a
> history of thowing away the version history every so often, so all those darcs
> comments are just going to get lost.

That's my fundamental fear.

I think maybe generating the ChangeLog at releasetime would be the best plan...

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Thu May 18 07:30:27 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 05:30:27 -0700 (PDT)
Subject: [netrek-dev] robotd-fixes! Thanks Trent!
In-Reply-To: <20060518094700.64250.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <20060518123027.25401.qmail@web35307.mail.mud.yahoo.com>

Thanks to Trent. Here is the improved patch for
robotd.

> > This is the correct fix:
> > 
> > -   if(!(pl->pl_flags & PLAGRI) || me->p_armies >> > 5){
> > +   if(!tpl || !(tpl->pl_flags & PLAGRI) ||
> > me->p_armies < 5){

Hi. Although logically that is correct. It is real
tough to figure out what that if statement means! 

I split it apart and re-wrote it in the attached
patch. Hopefully you like it. 

> There are no acceptable enemy planets -> look for
> ind ones (*)
> The closest enemy planet is agri and I have five
> or more armies -> skip
> looking for neut planets, the agri take is better
> All other cases, look for nuet planets and take
> them before enemy planets

Only a person who has played netrek heavily for many
years would know that logic is correct. If it were me,
I'd go for neut planets first over agris. And this is
why I couldn't figure out what Hadley was getting at.

Didn't get a chance to play test it. But it compiles
fine. 

I'll send an e-mail out tommorrow if I find something
wrong with the play testing. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-fixes.dpatch
Type: application/octet-stream
Size: 8120 bytes
Desc: 2572339651-robotd-fixes.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060518/36f60054/attachment.obj 

From xyzzy at speakeasy.org  Thu May 18 13:08:53 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 18 May 2006 11:08:53 -0700 (PDT)
Subject: [netrek-dev] robotd-fixes! Thanks Trent!
In-Reply-To: <20060518123027.25401.qmail@web35307.mail.mud.yahoo.com>
References: <20060518123027.25401.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605181042460.19907@shell2.speakeasy.net>

On Thu, 18 May 2006, Jimmy Huang wrote:
> > > This is the correct fix:
> > >
> > > -   if(!(pl->pl_flags & PLAGRI) || me->p_armies >=
> > > 5){
> > > +   if(!tpl || !(tpl->pl_flags & PLAGRI) ||
> > > me->p_armies < 5){
>
> Hi. Although logically that is correct. It is real
> tough to figure out what that if statement means!
>
> I split it apart and re-wrote it in the attached
> patch. Hopefully you like it.

It would be better if you just added a comment to what the if statement means,
rather than add in more code and extra variables.  Something like:

/* Skip check for neut planets if we found an enemy agri to take and have
   enough armies. */

You can also change the logic to:

if(!tpl || !( tpl->pl_flags&PLAGRI && me->p_armies >= 5 ) ) {


     * robotd/update_players.c changed closest_planet() function to return
       the old closest_planet if it cannot find a closest planet.

This is not what my fix to the bug in closest_planet is about at all.
Hadley's fuction had a bug where it would usually not find a closest planet
every other update.

     * robotd/update_players.c:  The function closest_planet() would
       usually return NULL every other time it was called.  It checks
       the distance to opl, the previous closest planet, and if the
       player is very close it doesn't bother searching.  If the
       player isn't very close, it would search for a planet _closer_
       than opl.  If opl was still the closest, it won't find a closer
       planet, but instead of returning opl, it would return NULL.


From xyzzy at speakeasy.org  Thu May 18 16:00:12 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 18 May 2006 14:00:12 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <20060518093240.23447.qmail@web35309.mail.mud.yahoo.com>
References: <20060518093240.23447.qmail@web35309.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605181348080.18789@shell3.speakeasy.net>

On Thu, 18 May 2006, Jimmy Huang wrote:
> > If you want to fix mfprintf, man stdarg
>
> I was thinking about simply getting rid of it.  Have
> any idea why use mfprintf instead of regular fprintf?

It looks like it check if stdin is connected, and if not doesn't print
anything.  It's probably so the bot doesn't spew debugging stuff when it's run
by the daemon and no one is there to look at it.

It also flushes stdout, to avoid buffering.  That can be a problem if a
program writes to both stdout and stderr, sometimes the output isn't in proper
order do with stream buffering.

It is very strange that mfprintf would crash and not mprintf.  Do you have a
gdb backtrace of when it crashes?


From jimmyhua73 at yahoo.com  Thu May 18 18:43:02 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 16:43:02 -0700 (PDT)
Subject: [netrek-dev] robotd-fixes! Thanks Trent!
In-Reply-To: <Pine.LNX.4.58.0605181042460.19907@shell2.speakeasy.net>
Message-ID: <20060518234303.30837.qmail@web35305.mail.mud.yahoo.com>

> It would be better if you just added a comment to
> what the if statement means,
> rather than add in more code and extra variables. 
> Something like:
> 
> /* Skip check for neut planets if we found an enemy
> agri to take and have
>    enough armies. */
> 
> You can also change the logic to:
> 
> if(!tpl || 
>     !( tpl->pl_flags&PLAGRI && 
>         me->p_armies >= 5 ) ) {

Yeah, I can make sense out of that one. I see how this
would generate more efficient machine code. 

>      * robotd/update_players.c changed
> closest_planet() function to return
>        the old closest_planet if it cannot find a
> closest planet.

> This is not what my fix to the bug in closest_planet
> is about at all.
> Hadley's fuction had a bug where it would usually
> not find a closest planet
> every other update.
> 
>      * robotd/update_players.c:  The function
> closest_planet() would
>        usually return NULL every other time it was
> called.  It checks
>        the distance to opl, the previous closest
> planet, and if the
>        player is very close it doesn't bother
> searching.  If the
>        player isn't very close, it would search for
> a planet _closer_
>        than opl.  If opl was still the closest, it
> won't find a closer
>        planet, but instead of returning opl, it
> would return NULL.

Uh, I think it's just symantecs. I meant to say

>      * robotd/update_players.c changed
> closest_planet() function to return
>        the old closest_planet if it cannot find a
> closer planet.

-- instead of returning NULL. Get it?

Anyways, patch doesn't introduce new bugs or bad
programming into the repo. 

Play testing shows that robotd works better! Much
better. 

So hopefully James or Stephen can apply the patch! It
looks okay. 

Messaging still gets screwed up 5 hours into a newbie
game. Not sure why though, no outright crash occurs.
No SIGSEV.  robots announce they carry, but do not
follow-up with where they want to carry to. Robots
continue to fight and take as normal though which is
good. 

Jimmy


From jimmyhua73 at yahoo.com  Thu May 18 18:46:02 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 16:46:02 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <Pine.LNX.4.58.0605181348080.18789@shell3.speakeasy.net>
Message-ID: <20060518234602.25522.qmail@web35303.mail.mud.yahoo.com>


> It is very strange that mfprintf would crash and not
> mprintf.  Do you have a
> gdb backtrace of when it crashes?
> 

fprintf doesn't crash, not mprintf. I haven't tried
mprintf. 

Sorry, I didn't store the backtrace into a file. I
should start doing this. 

Jimmy



From xyzzy at speakeasy.org  Thu May 18 19:35:19 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 18 May 2006 17:35:19 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <20060518234602.25522.qmail@web35303.mail.mud.yahoo.com>
References: <20060518234602.25522.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605181734240.30221@shell2.speakeasy.net>

On Thu, 18 May 2006, Jimmy Huang wrote:
>
> > It is very strange that mfprintf would crash and not
> > mprintf.  Do you have a
> > gdb backtrace of when it crashes?
> >
>
> fprintf doesn't crash, not mprintf. I haven't tried
> mprintf.

There is a function called mprintf() that the robot uses that
is almost the same as mfprintf().  Why would mfprintf() crash
and not mprintf()?


From jimmyhua73 at yahoo.com  Thu May 18 20:13:14 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 18 May 2006 18:13:14 -0700 (PDT)
Subject: [netrek-dev] clearingcrashes in robotd
In-Reply-To: <Pine.LNX.4.58.0605181734240.30221@shell2.speakeasy.net>
Message-ID: <20060519011314.66884.qmail@web35313.mail.mud.yahoo.com>

This is going to sound really obvious. 

But the way mprintf gets called and mfprintf gets
called are different. 

Your typical mprintf call looks like:

mprintf("declaring peace with %s\n",
         team_to_string(i));

while a typical mfprintf call look like:

mfprintf(stderr, 
         "shmem_cloakd: player not cloaked\n");

So, I think it has to do what you say about how, you
have to be careful when sending stuff to things other
than stdout??? A total guess on my part. 

I should have saved the backtrace. It takes a while
before a crash occurs. 

Jimmy

P.S. I'm working on fun things, like making the bots
take advantage of "ATT" ships (but not abusing them)
when you give them one via xsg. 

Also found an interesting bombing bug. Actually it's
not a bug per se, as the robot gets through it
(figures it out... eventually). But, if a bot takes a
planet and keeps dropping till the planet has >4
armies... It will then proceed to try to bomb those
armies!!!


--- Trent Piepho <xyzzy at speakeasy.org> wrote:

> On Thu, 18 May 2006, Jimmy Huang wrote:
> >
> > > It is very strange that mfprintf would crash and
> not
> > > mprintf.  Do you have a
> > > gdb backtrace of when it crashes?
> > >
> >
> > fprintf doesn't crash, not mprintf. I haven't
> tried
> > mprintf.
> 
> There is a function called mprintf() that the robot
> uses that
> is almost the same as mfprintf().  Why would
> mfprintf() crash
> and not mprintf()?
> 
> _______________________________________________
> 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 May 18 20:55:40 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 19 May 2006 11:55:40 +1000
Subject: [netrek-dev] ChangeLog and revision control
In-Reply-To: <3e8ca5c80605180414s3181536br6a25ecb124d1b41a@mail.gmail.com>
References: <3e8ca5c80605180318v7afe4dbat3361a2a590ca0fdf@mail.gmail.com>
	<Pine.LNX.4.58.0605180343160.21521@shell3.speakeasy.net>
	<3e8ca5c80605180414s3181536br6a25ecb124d1b41a@mail.gmail.com>
Message-ID: <20060519015539.GB8099@us.netrek.org>

On Thu, May 18, 2006 at 09:14:47PM +1000, Stephen Thorne wrote:
> I think maybe generating the ChangeLog at releasetime would be the
> best plan...

Agreed.  I've checked the GNU Coding Standards that I've been following,
and they allow for the concept of automatic ChangeLog generation at
release time.

Reference:
http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html

So after netrek-server-vanilla 2.11.1 the policy will be:

1.  contributed patches are not to change ChangeLog and NEWS,

2.  ChangeLog and NEWS will be updated during release (as a
darcs patch) based on the long comment and patch names of the
contributed patches.

In other words, we won't reject patches for lack of ChangeLog and NEWS,
but instead reject them for lack of suitable ChangeLog or NEWS type
material in the long comment and patch name respectively.

Until 2.11.1, we'll continue to require ChangeLog and NEWS changes.

Stephen agreed on IRC to find a way to generate a ChangeLog formatted
text stream for all patches since a tag version.  We should maintain
this in the repository.

Functional specification of this:

1.  input, the darcs repository, and a tag version of the previous
version,

2.  output, a stream to be edited into the top of ChangeLog, in the form
date, double space, name, double space, e-mail address, blank line, long
comment, blank line.

3.  output, a stream to be edited into the top of NEWS, in the form
hyphen, space, patch name, space, [Author], newline.

I'm happy for this to be two separate commands to issue.

-- 
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/20060519/2f709ee4/attachment.pgp 

From quozl at us.netrek.org  Thu May 18 20:56:05 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Fri, 19 May 2006 11:56:05 +1000
Subject: [netrek-dev] darcs patch: patch acceptance policy regarding patch
	name and comment
Message-ID: <E1FguDl-0004C2-Cp@dors.lan>

Fri May 19 11:52:08 EST 2006  quozl at us.netrek.org
  * patch acceptance policy regarding patch name and comment
  Define a new policy of not changing ChangeLog and NEWS until release.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 5446 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/ac97c091/attachment-0001.bin 

From williamb at its.caltech.edu  Thu May 18 21:32:18 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Thu, 18 May 2006 21:32:18 -0500
Subject: [netrek-dev] darcs patch: ATT fixes (and 1 more)
Message-ID: <200605190232.k4J2WIqF026870@omen.digital-genesis.com>

Thu May 18 03:16:58 CDT 2006  williamb at its.caltech.edu
  * ATT fixes

Thu May 18 21:18:44 CDT 2006  williamb at its.caltech.edu
  * Transwarp war errormsg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 1895 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060518/49c28e13/attachment.bin 

From quozl at us.netrek.org  Thu May 18 21:39:48 2006
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 19 May 2006 12:39:48 +1000
Subject: [netrek-dev] COW Camera prototype
In-Reply-To: <ecfa260c0605161838m2a0b1c04vaddd6ec549b1f732@mail.gmail.com>
References: <3e8ca5c80605161426p576fb2c4n502275f983539b1a@mail.gmail.com>
	<20060516232644.47226.qmail@web35301.mail.mud.yahoo.com>
	<3e8ca5c80605161713p1ffa7714of7f40e13147f64e8@mail.gmail.com>
	<ecfa260c0605161838m2a0b1c04vaddd6ec549b1f732@mail.gmail.com>
Message-ID: <20060519023947.GC8099@us.netrek.org>

On Tue, May 16, 2006 at 09:38:06PM -0400, Zach wrote:
> SDL is an outside library, I think a good workaround would preserve
> the existing way we've been config'ing the client (people are used to
> it and it's straghtforward and adds a degree of transparency) rather
> than throw it all out just because we want to support SDL.

SDL provides the sound effects playback.  We want to keep that.  COW is
not a minimalist client.

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


From quozl at us.netrek.org  Fri May 19 01:57:30 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Fri, 19 May 2006 16:57:30 +1000
Subject: [netrek-dev] darcs patch: mute banned observers (and 3 more)
Message-ID: <E1FgyvS-0008Bh-CI@dors.lan>

Fri May 19 14:27:23 EST 2006  quozl at us.netrek.org
  * mute banned observers
  Banned observers are allowed in and can speak, which was a surprise, but the
  code has always allowed this since observers were added.  Change to prevent
  banned observers from talking.  Simplify ban logic further.

Fri May 19 14:28:33 EST 2006  quozl at us.netrek.org
  * mute banned observers changelog

Fri May 19 16:06:23 EST 2006  quozl at us.netrek.org
  * add install-ntserv target for live updates
  Addition of a target install-ntserv to the ntserv Makefile so that a
  server operator can do a live update of ntserv during a running game.
  
  The target moves the existing in-use ntserv binary into an archive
  tree before installing the new ntserv binary.  This makes it possible
  to manually back out of an installation if the new binary breaks
  badly.
  
  Other methods to test a new ntserv binary include running it manually
  for connection back to the client.  See ntserv command line options.

Fri May 19 16:11:57 EST 2006  quozl at us.netrek.org
  * add install-ntserv target for live updates changelog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10051 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/ffd1a53f/attachment.bin 

From williamb at its.caltech.edu  Fri May 19 01:58:28 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Fri, 19 May 2006 01:58:28 -0500
Subject: [netrek-dev] darcs patch: declare_war fix
Message-ID: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>

Fri May 19 01:57:53 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 1976 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/7c86c757/attachment.bin 

From williamb at its.caltech.edu  Fri May 19 02:12:49 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Fri, 19 May 2006 02:12:49 -0500
Subject: [netrek-dev] darcs patch: declare_war fix
Message-ID: <200605190712.k4J7CnYF014869@omen.digital-genesis.com>

Fri May 19 02:11:44 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
  Use this patch instead of previous one, had to change a variable name.
  This patch contains the following changes:
  
  M ./Vanilla/ChangeLog +8
  M ./Vanilla/include/proto.h -1 +1
  M ./Vanilla/include/warnings.h -1 +1
  M ./Vanilla/ntserv/enter.c -1 +1
  M ./Vanilla/ntserv/interface.c -2 +2
  M ./Vanilla/ntserv/socket.c -1 +1
  M ./Vanilla/robots/rmove.c -2 +2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 2355 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/daf1bb7b/attachment-0001.bin 

From quozl at us.netrek.org  Fri May 19 03:15:42 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Fri, 19 May 2006 18:15:42 +1000
Subject: [netrek-dev] darcs patch: add max duplicate ip count for pickup play
Message-ID: <E1Fh098-0001aU-Ez@dors.lan>

Fri May 19 17:53:51 EST 2006  quozl at us.netrek.org
  * add max duplicate ip count for pickup play
  Adds a new etc/sysdef option DUPLICATES which is the maximum number of
  pickup player slots allowed from the same IP address before the next
  connection is given the Q32 response.
  
  This is a denial of service filtering feature.
  
  The default is 3.  Set this above 16 to make it ineffective.
  
  Set this to less than half of the number of players per side, otherwise
  abusers may not be ejected or banned by majority vote because a majority
  would be impossible.
  
  Does not affect robots, unless they join via the pickup queue ... which
  would be a misconfiguration.  Robots normally join via a special queue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 7434 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/c2f81d78/attachment.bin 

From williamb at its.caltech.edu  Fri May 19 03:19:00 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Fri, 19 May 2006 03:19:00 -0500
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
Message-ID: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>

Fri May 19 02:11:44 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
  Use this patch instead of previous one, had to change a variable name.
  This patch contains the following changes:
  
  M ./Vanilla/ChangeLog +8
  M ./Vanilla/include/proto.h -1 +1
  M ./Vanilla/include/warnings.h -1 +1
  M ./Vanilla/ntserv/enter.c -1 +1
  M ./Vanilla/ntserv/interface.c -2 +2
  M ./Vanilla/ntserv/socket.c -1 +1
  M ./Vanilla/robots/rmove.c -2 +2

Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
  * Phaser_Hit information equalization
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 3736 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/ddce6821/attachment.bin 

From xyzzy at speakeasy.org  Fri May 19 12:52:27 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 10:52:27 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix
In-Reply-To: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
References: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
Message-ID: <Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>

There is no declare war delay when switching teams, the code in enter.c
sets the delay to 0.  You still get a declare war message delay message.

Not sure what you're talking about with the bots.  They will freeze up
when they try to declare war?  I've never seen that happen.

On Fri, 19 May 2006 williamb at its.caltech.edu wrote:

> Fri May 19 01:57:53 CDT 2006  williamb at its.caltech.edu
>   * declare_war fix
>


From xyzzy at speakeasy.org  Fri May 19 13:06:45 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 11:06:45 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
Message-ID: <Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>

On Fri, 19 May 2006 williamb at its.caltech.edu wrote:
>
> Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
>   * Phaser_Hit information equalization
>

This will mess up some clients.  In order to get information for phaser stats,
they attempt to parse the phaser hit warning messages.  The phaser hit
message has been exactly the same for decades, in all servers, Vanilla, INL,
Paradise, Calvin, Sturgeon, etc.

I know that the Paradise client, Ted Turner, and Paradise-2000 all do this.

The message has the player name, that should be enough.  The client can
always try to figure out the player letter from the position and name.


From williamb at its.caltech.edu  Fri May 19 13:18:19 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 11:18:19 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix
In-Reply-To: <Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>
References: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191111160.16640@blinky>

Right, the delay is set to 0, but not before the server would send a
newwarning message to client that your battle computers are being
reprogrammed.  This prevents that message from being sent (I came across
this while adding a timer client-side to keep track of declare war delay.
If the server is not going to give us a delay, the delay message should
not be sent, period.)

As for bots, the whole problem with observers locking onto iggies and then
not being able to do anything (lock onto someone else, quit, etc) was due
to bots being in a permanent state of delay (their war timer is never
decremented like a player's timer).  This was partially fixed by a
previous patch of mine by not masking the PFWAR flag to observers.  This
second patch gets at the root of the problem - bots should not be flagged
PFWAR.  Of course, bots don't freeze cause they don't have to input
anything.

 On Fri, 19 May 2006, Trent Piepho wrote:

> There is no declare war delay when switching teams, the code in enter.c
> sets the delay to 0.  You still get a declare war message delay message.
>
> Not sure what you're talking about with the bots.  They will freeze up
> when they try to declare war?  I've never seen that happen.
>
> On Fri, 19 May 2006 williamb at its.caltech.edu wrote:
>
> > Fri May 19 01:57:53 CDT 2006  williamb at its.caltech.edu
> >   * declare_war fix
> >
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>


From williamb at its.caltech.edu  Fri May 19 13:23:43 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 11:23:43 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191121450.16640@blinky>

Show me the code where it will mess up.  Parsing is only done in short
packet message - this change only effects the long packet message.  At
least in COW and all COW-derivatives which I have code access to.  I'd
have checked Paradise for conflict but it's closed source.

BTW someone was trying to figure out how to refit to ATT in Paradise,
what's the key?

Bill

On Fri, 19 May 2006, Trent Piepho wrote:

> On Fri, 19 May 2006 williamb at its.caltech.edu wrote:
> >
> > Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
> >   * Phaser_Hit information equalization
> >
>
> This will mess up some clients.  In order to get information for phaser stats,
> they attempt to parse the phaser hit warning messages.  The phaser hit
> message has been exactly the same for decades, in all servers, Vanilla, INL,
> Paradise, Calvin, Sturgeon, etc.
>
> I know that the Paradise client, Ted Turner, and Paradise-2000 all do this.
>
> The message has the player name, that should be enough.  The client can
> always try to figure out the player letter from the position and name.
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>


From williamb at its.caltech.edu  Fri May 19 13:30:22 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 11:30:22 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191128160.16640@blinky>

Could you also explain how client could get player position from the
phaser hit message when all it passes is player name.  If you have
multiple "guest" logins, I don't see how you can tell which player
it is strictly from passing player name.
Bill

On Fri, 19 May 2006, Trent Piepho wrote:

> On Fri, 19 May 2006 williamb at its.caltech.edu wrote:
> >
> > Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
> >   * Phaser_Hit information equalization
> >
>
> This will mess up some clients.  In order to get information for phaser stats,
> they attempt to parse the phaser hit warning messages.  The phaser hit
> message has been exactly the same for decades, in all servers, Vanilla, INL,
> Paradise, Calvin, Sturgeon, etc.
>
> I know that the Paradise client, Ted Turner, and Paradise-2000 all do this.
>
> The message has the player name, that should be enough.  The client can
> always try to figure out the player letter from the position and name.
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>


From xyzzy at speakeasy.org  Fri May 19 14:09:56 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 12:09:56 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix
In-Reply-To: <Pine.GSO.4.58.0605191111160.16640@blinky>
References: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191111160.16640@blinky>
Message-ID: <Pine.LNX.4.58.0605191150280.20296@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> Right, the delay is set to 0, but not before the server would send a
> newwarning message to client that your battle computers are being
> reprogrammed.  This prevents that message from being sent (I came across

True, but that is not what your message said.  It's not the delay that
is being removed, but the incorrect warning message.

> this while adding a timer client-side to keep track of declare war delay.
> If the server is not going to give us a delay, the delay message should
> not be sent, period.)

Trying to copy my ideas from Paradise-2000 I see.  You can make a working
client side timer without changing the server by turning the timer off if the
PFWAR flag goes away.

> As for bots, the whole problem with observers locking onto iggies and then
> not being able to do anything (lock onto someone else, quit, etc) was due
> to bots being in a permanent state of delay (their war timer is never
> decremented like a player's timer).  This was partially fixed by a

The timer isn't exactly decremented.  Rather, it is the absolute time the
delay should turn off.  The player's p_updates counter is incremented every
update and the delay turns off when it p_updates reaches the delay or rdelay
value.  I think the problem is that the code to check for this is in the alarm
sig handler that server robots don't use.

> previous patch of mine by not masking the PFWAR flag to observers.  This
> second patch gets at the root of the problem - bots should not be flagged
> PFWAR.  Of course, bots don't freeze cause they don't have to input
> anything.

Ok, that make sense.  Does this mean masking the WAR flag for observers can be
removed?  That way you could still see if the observee had declared war.

I wonder, does a similar issue exist for refit?  I don't think the bots will
ever get their PFREFITTING flag set, but once they do, it won't go away
either.


From xyzzy at speakeasy.org  Fri May 19 14:18:14 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 12:18:14 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605191121450.16640@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191121450.16640@blinky>
Message-ID: <Pine.LNX.4.58.0605191210230.20296@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> Show me the code where it will mess up.  Parsing is only done in short
> packet message - this change only effects the long packet message.  At
> least in COW and all COW-derivatives which I have code access to.  I'd
> have checked Paradise for conflict but it's closed source.

The older Paradise client and Ted Turner are open source.  The code is in
warning.c.  I'd post it here but it's rather long.  I'm sure you can find it.

> BTW someone was trying to figure out how to refit to ATT in Paradise,
> what's the key?

It's set in the server source:

./ntserv/enter.c:      ShipFoo.s_letter = "sdcbaog*"[myship->s_type];
./ntserv/interface.c:   ShipFoo.s_letter = "sdcbaog*"[me->p_ship.s_type];


From xyzzy at speakeasy.org  Fri May 19 14:22:50 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 12:22:50 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605191128160.16640@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
Message-ID: <Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> Could you also explain how client could get player position from the
> phaser hit message when all it passes is player name.  If you have
> multiple "guest" logins, I don't see how you can tell which player
> it is strictly from passing player name.

I do it in paradise-2000, so it's obviously possible.  I'm not going copy
my features for you, you'll have to write them yourself.

The only people who would want to use non-short packets are borg
authors looking for more information and people with old clients.  The same
clients that don't like message text getting changed.


From williamb at its.caltech.edu  Fri May 19 14:38:10 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 12:38:10 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix
In-Reply-To: <Pine.LNX.4.58.0605191150280.20296@shell3.speakeasy.net>
References: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191111160.16640@blinky>
	<Pine.LNX.4.58.0605191150280.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191220300.18376@blinky>

> True, but that is not what your message said.  It's not the delay that
> is being removed, but the incorrect warning message.

You are right, the ChangeLog entry should say "unwanted war delay message"
instead of "unwanted war delay".

> Trying to copy my ideas from Paradise-2000 I see.  You can make a working
> client side timer without changing the server by turning the timer off if the
> PFWAR flag goes away.
>
Yes I could do this, but the server shouldn't be sending that message
regardless.

> The timer isn't exactly decremented.  Rather, it is the absolute time the
> delay should turn off.  The player's p_updates counter is incremented every
> update and the delay turns off when it p_updates reaches the delay or rdelay
> value.  I think the problem is that the code to check for this is in the alarm
> sig handler that server robots don't use.
>
Yup.  From design standpoint, I guess one could ask: should robots get
"freeze" when declaring war?  If so, they are going to have to pass
through whatever function keeps track of updates.  This patch would still
be compatable with that scenario - just change robot call to declare_war
to add delay (int 0 to 1)

> Ok, that make sense.  Does this mean masking the WAR flag for observers can be
> removed?  That way you could still see if the observee had declared war.
>
> I wonder, does a similar issue exist for refit?  I don't think the bots will
> ever get their PFREFITTING flag set, but once they do, it won't go away
> either.
>
No, the WAR flag for obs still can't be masked - the one place where the
delay in declare_war is needed (in socket handler) is the same place where
both player and observer would send declare war request.

A similar issue existed with observing obs'ing someone who was refitting -
it froze up observer with same delay timer.  Previous patch fixed this
issue as well.  Bots don't ever get PREFIT set, and but yes it wouldn't go
away either.

Bill


From williamb at its.caltech.edu  Fri May 19 14:41:15 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 12:41:15 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605191210230.20296@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191121450.16640@blinky>
	<Pine.LNX.4.58.0605191210230.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191239260.18376@blinky>

> The older Paradise client and Ted Turner are open source.  The code is in
> warning.c.  I'd post it here but it's rather long.  I'm sure you can find it.

I checked Ted Turner, I still don't see how this would mess anything up.
Ted Turner only pulls the damage off the end of the long packet message
(same as Cow, NetrekXP).  It doesn't try and parse the player name.  All
this patch does is add 5 chars at end of player name, in a region that no
client I have seen tries to parse.

> It's set in the server source:
>
> ./ntserv/enter.c:      ShipFoo.s_letter = "sdcbaog*"[myship->s_type];
> ./ntserv/interface.c:   ShipFoo.s_letter = "sdcbaog*"[me->p_ship.s_type];
>
Well I told the player to try * to refit but it wasn't working, he has to
change to NetrekXP.
Bill


From williamb at its.caltech.edu  Fri May 19 15:01:57 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 13:01:57 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191243190.18376@blinky>

> I do it in paradise-2000, so it's obviously possible.  I'm not going copy
> my features for you, you'll have to write them yourself.
>
Alright I'm going to call you on this one.  If you have 2 cloaked ships
both named guest in nearly the exact same place (trying to bomb homeworld
is a likely scenario), how are you going to tell which ship is which based
on player name?  Client doesn't get exact position for cloakers.

> The only people who would want to use non-short packets are borg
> authors looking for more information and people with old clients.  The same
> clients that don't like message text getting changed.
>
Short packets give less information.  Most noticeably, ship heading.  Actually
I made a list, I've come across lots of short packet problems during my coding:

1) cloaking/shields at warp 0 doesn't update someone else's tactical on
what you did
2) observer sound messes up when someone flips shields at warp 0
3) Locking onto robot cause the observer sound to mess up for shields
up/down
4) Observers don't get any geno message at all (head to default which is
error message)
5) The new smooth turning only working on self, not obs or others - short
packets only send headings of 16 positions.

If you have any decent internet connection, there is no reason to use
short packets.  Unless you like playing with *less* information.

You packed a lot of ideas into those 2 sentences, going to have to disect:

Statement 1:
Borg authors would want to use non-short packets for more information

Statement 2:
People with old clients would want to use non-short packets for more
information

Statment 3:
Old clients don't like message text getting changed

I'd agree with statement 1.  Statement 2 I don't.  How is it an
advantage to use short packets on an old client?  At any level of client,
from 10 year old COW to today's active clients, short packets gives an
informational disadvantage.  Except for this one case I have pointed out,
phaser hit messages.  From the noobest player to the most skilled,
everyone who wants to be the best player they can be, wants the most
information they can get.  I'm not asking for borgish information to be
sent to client.  For example, if short packets sent ship heading to 255
heading but long packets only sent them to 16, that would be contrary to
the purpose of short packets no?  This case seems (to me) contrary to the
purpose of short packets - it punishes player for using long packets.

As for statement 3, I still have not found an example where this patch would
break an old client.. they all use strlen(text) to get length of the warning
message, and none have parsed the player name.


From williamb at its.caltech.edu  Fri May 19 15:10:37 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Fri, 19 May 2006 15:10:37 -0500
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
Message-ID: <200605192010.k4JKAbjo014317@omen.digital-genesis.com>

Fri May 19 02:11:44 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
  Use this patch instead of previous one, had to change a variable name.
  This patch contains the following changes:
  
  M ./Vanilla/ChangeLog +8
  M ./Vanilla/include/proto.h -1 +1
  M ./Vanilla/include/warnings.h -1 +1
  M ./Vanilla/ntserv/enter.c -1 +1
  M ./Vanilla/ntserv/interface.c -2 +2
  M ./Vanilla/ntserv/socket.c -1 +1
  M ./Vanilla/robots/rmove.c -2 +2

Fri May 19 15:09:58 CDT 2006  williamb at its.caltech.edu
  * Declarewar ChangeLog fix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 2853 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/35e93bf7/attachment.bin 

From xyzzy at speakeasy.org  Fri May 19 15:32:08 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 13:32:08 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605191243190.18376@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
Message-ID: <Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> > I do it in paradise-2000, so it's obviously possible.  I'm not going copy
> > my features for you, you'll have to write them yourself.
> >
> Alright I'm going to call you on this one.  If you have 2 cloaked ships
> both named guest in nearly the exact same place (trying to bomb homeworld
> is a likely scenario), how are you going to tell which ship is which based
> on player name?  Client doesn't get exact position for cloakers.

It does when you plock them!

> > The only people who would want to use non-short packets are borg
> > authors looking for more information and people with old clients.  The same
> > clients that don't like message text getting changed.
> >
> Short packets give less information.  Most noticeably, ship heading.  Actually
> I made a list, I've come across lots of short packet problems during my coding:
>
> 1) cloaking/shields at warp 0 doesn't update someone else's tactical on
> what you did

Only if no ship in the game is moving at all.

> 2) observer sound messes up when someone flips shields at warp 0
> 3) Locking onto robot cause the observer sound to mess up for shields
> up/down

What are you talking about, observer sound?

> 4) Observers don't get any geno message at all (head to default which is
> error message)

Haven't heard about that one.

> 5) The new smooth turning only working on self, not obs or others - short
> packets only send headings of 16 positions.

Short packets should be extended for more ship positions.

> If you have any decent internet connection, there is no reason to use
> short packets.  Unless you like playing with *less* information.

Short packets handle packetloss much better than old packets.  They provide
messages and warnings in a form which the client can do more with.  You can
get custom kill messages, phaser messages, planet take, and so on.  Short
packets reduce the network bandwidth to the server.  Short packets should be
considered the standard.  Old packets are just for backward compatibility.
Old packets should not change.  If protocol enhancements are desired, they
should be incorporated into short packets.

> You packed a lot of ideas into those 2 sentences, going to have to disect:
>
> Statement 1:
> Borg authors would want to use non-short packets for more information
>
> Statement 2:
> People with old clients would want to use non-short packets for more
> information

People with old clients would want to use non-short packets because their
client dooesn't support short packets or doesn't support them correctly.


From williamb at its.caltech.edu  Fri May 19 17:30:45 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 15:30:45 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605191336290.18376@blinky>

> It does when you plock them!
>
I'll have to check and get back to you on this one.

>
> What are you talking about, observer sound?
>
I added in more sound support for observers (they can now hear shields
up/down for the ship they are observing).  This is where the shield sound
problem shows up with short packets on.  Oh and I forgot to mention one
other pretty important thing.  All robots (iggies, practice robots) always
show their shields being down when short packets = on, even if the robot has
shields up.

> Short packets should be extended for more ship positions.
>
Agreed but how to make it compatable with older clients?

> Short packets handle packetloss much better than old packets.  They provide
> messages and warnings in a form which the client can do more with.  You can
> get custom kill messages, phaser messages, planet take, and so on.  Short
> packets reduce the network bandwidth to the server.  Short packets should be
> considered the standard.  Old packets are just for backward compatibility.
> Old packets should not change.  If protocol enhancements are desired, they
> should be incorporated into short packets.
>
I'm all for making enhancements to short packets, but the impression I got
was that it was a by design tradeoff - less information for less
bandwidth, and that increasing the information in short packets (i.e.
enhancing them by adding more ship position detail) is not going to be
approved.  Not to mention the issue of making it compatable with older
clients.

> People with old clients would want to use non-short packets because their
> client dooesn't support short packets or doesn't support them correctly.
>
And so sending them an extra 5 chars in the middle of the phaser message
gives them unwanted information or breaks their client how?

Bill


From quozl at us.netrek.org  Fri May 19 18:00:47 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 20 May 2006 09:00:47 +1000
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605191243190.18376@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
Message-ID: <20060519230047.GA7330@us.netrek.org>

On Fri, May 19, 2006 at 01:01:57PM -0700, William Balcerski wrote:
> As for statement 3, I still have not found an example where this patch
> would break an old client.. they all use strlen(text) to get length of
> the warning message, and none have parsed the player name.

I'm happy to take a patch that shows this research more clearly; list
the client source code repositories you checked, and when you checked
them.

Closed source clients will go the way of all closed source; they'll
either be fixed by an active maintainer or be discarded by the player
base.

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


From williamb at its.caltech.edu  Fri May 19 20:06:40 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 18:06:40 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <20060519230047.GA7330@us.netrek.org>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<20060519230047.GA7330@us.netrek.org>
Message-ID: <Pine.GSO.4.58.0605191804250.27180@blinky>

Well rather than put 100s of lines of code in ChangeLog to justify,
the phaser message change, I'll just post my results here:


All checked on 5/19/06 vs. latest versions at ftp.netrek.org
Latest COW/NetrekXP/NetrekXP Mod

  doPhaser = showPhaser && (strncmp(text, "Phaser burst", 12) == 0);

  warncount = strlen(text);

#ifdef PHASER_STATS
  if (doPhaser && phaserShowStats)
    {
      sprintf(newtext, "%s [%2d%%]", text,
	      phaserStatTry ? (phaserStatHit * 100) / phaserStatTry : 0);
      warncount += 6;
      W_WriteText(warnw, 5, 5, textColor, newtext, warncount,
W_RegularFont);
    }
  else
#endif

    W_WriteText(warnw, 5, 5, textColor, text, warncount, W_RegularFont);



COW 2.02
Tested with client, works ok (didn't look at 10 year old source though,
just latest COW)



Ted Turner 1.3.1
    if(!W_IsMapped(warnw)) return;
    if (*count > 0) {
	/* XFIX */
	W_ClearWindow(warnw);
        /*W_ClearArea(warnw, W_XOFF, W_YOFF, W_Textwidth * *count,
W_Textheight);*/
	if(hudwarning)
          W_DirectMaskText(w, center - (*count / 2) * W_Textwidth, y,
	                   backColor, save_buffer, *count, font);
    }
    *count = strlen(text);
    W_WriteText(warnw, W_XOFF, W_YOFF, textColor, text, *count,
                font);
    if(hudwarning) {
      strcpy(save_buffer, text);
      W_DirectMaskText(w, center - (*count / 2) * W_Textwidth, y,
                       color, save_buffer, *count, font); #ifdef BUFFERING
      /* flush the buffer if there is one and we're not playing.
Flushing is
         too slow to do when playing - wait for the next update [BDyess]
*/
      if(me)
      if((me->p_status == PFREE ||
          me->p_status == POUTFIT) &&
	 W_IsBuffered(w))
        W_DisplayBuffer(w); #endif /*BUFFERING [BDyess]*/
    }
    if (strncmp(text, "Phaser", 6) == 0) {
	if (strncmp(text + 7, "missed", 6) == 0) {
	    phasFired++;
	    if (!logPhaserMissed)
		return;
	    thisHit = 0;
	} else if (strncmp(text + 7, "burst", 5) != 0 &&
		   strncmp(text + 7, "shot", 4) != 0)
	    return;
	else { /* a hit! */
	    phasFired++;
	    phasHits++;
	    thisHit = 1;
	}
	if (phaserStats) {
	    if (thisHit) {
		d = &text[strlen(text)];
		while (!isdigit(*d) && d > text) /* find the last number
							   in the string,
should
							   be damage */
		    d--;
		while (d > text && isdigit(*d))
		    d--;
		if (d > text) {
		    dmg = atoi(d);
		    totalDmg += dmg;
		    avgDmg = (float) totalDmg / (float) phasHits;
		    phasRatio = (100 * phasHits) / (float) phasFired;
		    sprintf(newtext, "Av:%5.2f, Hit:%5.2f%%: ", avgDmg,
phasRatio);
		}
	    } else { /* a miss */
		sprintf(newtext, "Hit: %d, Miss: %d, Dmg: %d: ", phasHits,
phasFired - phasHits, totalDmg);
	    }
	} else { /* not keeping phaser stats right now */
	    phasFired--;
	    if (thisHit)
		phasHits--;
	    newtext[0] = '\0';
	}
	strncat(newtext, text, 80);
	len = strlen(newtext);
	newtext[len++] = ' ';
	strcpy(newtext + len, timeString(time(NULL)));
	dmessage(newtext, 0, 254, 0);



Gltrek:
Couldn't find source



BRMH 2.4.0
   warncount = strlen(text);
   if(!recv_short && strncmp(text, "Phaser burst", 12)==0){
      if(phaserWindow){
	 W_WriteText(phaserwin, 0, 0, textColor, text, strlen(text),
W_MesgFont);
	 W_FlushScrollingWindow(phaserwin);
	 return;
      }
      if (phas_msgi){
	 W_WriteText(messwi, 0, 0, textColor, text, strlen(text),
W_MesgFont);
	 return;
      }


From williamb at its.caltech.edu  Fri May 19 23:01:32 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Fri, 19 May 2006 23:01:32 -0500
Subject: [netrek-dev] darcs patch: declare_war fix (and 3 more)
Message-ID: <200605200401.k4K41W0N014601@omen.digital-genesis.com>

Fri May 19 02:11:44 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
  Use this patch instead of previous one, had to change a variable name.
  This patch contains the following changes:
  
  M ./Vanilla/ChangeLog +8
  M ./Vanilla/include/proto.h -1 +1
  M ./Vanilla/include/warnings.h -1 +1
  M ./Vanilla/ntserv/enter.c -1 +1
  M ./Vanilla/ntserv/interface.c -2 +2
  M ./Vanilla/ntserv/socket.c -1 +1
  M ./Vanilla/robots/rmove.c -2 +2

Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
  * Phaser_Hit information equalization

Fri May 19 15:09:58 CDT 2006  williamb at its.caltech.edu
  * Declarewar ChangeLog fix

Fri May 19 23:00:56 CDT 2006  williamb at its.caltech.edu
  * Phasermsg Changelog Update
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 4973 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060519/557b4f72/attachment.bin 

From xyzzy at speakeasy.org  Fri May 19 23:21:22 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 21:21:22 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605191336290.18376@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191336290.18376@blinky>
Message-ID: <Pine.LNX.4.58.0605192053370.12122@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> > What are you talking about, observer sound?
> >
> I added in more sound support for observers (they can now hear shields
> up/down for the ship they are observing).  This is where the shield sound
> problem shows up with short packets on.  Oh and I forgot to mention one

This works fine in Paradise-2000, it must be a bug in your code.

> other pretty important thing.  All robots (iggies, practice robots) always
> show their shields being down when short packets = on, even if the robot has
> shields up.

I see the problem.  The short packets 2 flag sampling is turned off for robots
and for observers.  I see why observers is turned off, there is no reason to
tell other clients what observers are getting.  I'm not sure why it is turned
off for robots.  Can't think of any good reason.  Can anyone else think of
one?

> > Short packets should be extended for more ship positions.
> >
> Agreed but how to make it compatable with older clients?

One way is to find some spare space in a packet and stuff it in there.  That
was done for a number of things, extra self flags and visible tractors are two
I can think of off the top of my head.

Another is to add a feature packet that turns it on.  Like I did for 19_flags.
Then you could modify a packet, VPlayer is the obvious example, to add more
bits of ship rotation.

There is also the short packets version, you could create short packets
version 3.  That is more work than a feature packet.

> > Short packets handle packetloss much better than old packets.  They provide
> > messages and warnings in a form which the client can do more with.  You can
> > get custom kill messages, phaser messages, planet take, and so on.  Short
> > packets reduce the network bandwidth to the server.  Short packets should be
> > considered the standard.  Old packets are just for backward compatibility.
> > Old packets should not change.  If protocol enhancements are desired, they
> > should be incorporated into short packets.
> >
> I'm all for making enhancements to short packets, but the impression I got
> was that it was a by design tradeoff - less information for less
> bandwidth, and that increasing the information in short packets (i.e.

Not at all.  Originally the client and server were both the ntserv program.
It was split into two programs, without changing the code any more than
necessary.  All the data structures between the client and server were the
same.  Then the most obvious, simplest protocol was used to send these
data structures from the server to the client.  No thought to bandwidth
or packetloss was given at all.

Then short packets was made as a real protocol.  It is supposed to send ALL
information a non-borg client can use.  It was never a design trade off to
send less information; it actually sends MORE information.

The original client only had 16 ship positions, so only an aim-borg would need
more.  Now clients have 32.  When I first added 32 ship positions to Paradise
2000, Niclas said it was borg.  Extra rotations!  Unfair advantage!  It only
shut him up when I told him Steve Sheldon had added it to his client much
earlier.

I think adding a new feature to send 32 positions via short packets would be a
good idea.  I had been planning to do just that, when the netrek CVS went
down.


From xyzzy at speakeasy.org  Fri May 19 23:30:35 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Fri, 19 May 2006 21:30:35 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <20060519230047.GA7330@us.netrek.org>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<20060519230047.GA7330@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605192121340.12122@shell3.speakeasy.net>

On Sat, 20 May 2006, James Cameron wrote:
> On Fri, May 19, 2006 at 01:01:57PM -0700, William Balcerski wrote:
> > As for statement 3, I still have not found an example where this patch
> > would break an old client.. they all use strlen(text) to get length of
> > the warning message, and none have parsed the player name.
>
> I'm happy to take a patch that shows this research more clearly; list
> the client source code repositories you checked, and when you checked
> them.

I'd prefer to think of the old protocol as just a piece of legacy code, for
stuff like Hadley's bot.  If any protocol changes are to be made, it should
be done to the real protocol, short packets.  It should be done in a
backward compatible manner.  If there is a problem with the network code,
it should be fixed.  Regressing back to 15 year old network code because of
an easily fixable bug in short packet is not the answer!

Changing the old protocol makes it hard for clients to support old servers.
How to tell what version of the old protocol this client is getting?  The
one that's been the same for 20 years, or whatever it has been changed to?


From williamb at its.caltech.edu  Fri May 19 23:31:22 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Fri, 19 May 2006 21:31:22 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605192053370.12122@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191336290.18376@blinky>
	<Pine.LNX.4.58.0605192053370.12122@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605192129480.29708@blinky>

> I think adding a new feature to send 32 positions via short packets would be a
> good idea.  I had been planning to do just that, when the netrek CVS went
> down.
>
Suppose I should mention Netrek XP 2006 draws the new ship bitmaps to
255 positions :P  I'd prefer the actual p_dir be sent if possible, it's
the most important piece of information (imo)  lacking in short packets.
Bill


From xyzzy at speakeasy.org  Sat May 20 03:27:20 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Sat, 20 May 2006 01:27:20 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605192129480.29708@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191336290.18376@blinky>
	<Pine.LNX.4.58.0605192053370.12122@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605192129480.29708@blinky>
Message-ID: <Pine.LNX.4.58.0605200101060.12122@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> > I think adding a new feature to send 32 positions via short packets would be a
> > good idea.  I had been planning to do just that, when the netrek CVS went
> > down.
> >
> Suppose I should mention Netrek XP 2006 draws the new ship bitmaps to
> 255 positions :P  I'd prefer the actual p_dir be sent if possible, it's

Borg!  It's part of the game to figure out ship direction from ship motion.
Clued players will turn to the edge of the bitmap rotation so that they can
change direction faster than their enemies expect.  Why not just make a torp
aim borg?  blah blah  10 updates/sec is unfair!  blah blah color clients blah

Seriously, why only 255?  That means I can still one up you with 256 in the
next version of Paradise 2000.

> the most important piece of information (imo)  lacking in short packets.

What else is lacking, that a non-borg client can use?  I had a patch to add
armies dooshed by planets, but that's not in the old style protocol either.
Torp and plasma direction isn't sent, but a client can't use that.  I guess
there is speeds over 15.  Not something you have to worry about in a normal
game.

I think the easiest way to add more ship positions would be to append the data
to the end of the VPlayers packet.  Add the lower four bits for each player in
the vplayer packet, in order, to the end.  Just four bits per player extra
bandwidth.


From xyzzy at speakeasy.org  Sat May 20 03:40:30 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Sat, 20 May 2006 01:40:30 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix
In-Reply-To: <Pine.GSO.4.58.0605191220300.18376@blinky>
References: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191111160.16640@blinky>
	<Pine.LNX.4.58.0605191150280.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191220300.18376@blinky>
Message-ID: <Pine.LNX.4.58.0605200135020.12122@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> > Ok, that make sense.  Does this mean masking the WAR flag for observers can be
> > removed?  That way you could still see if the observee had declared war.
> >
> > I wonder, does a similar issue exist for refit?  I don't think the bots will
> > ever get their PFREFITTING flag set, but once they do, it won't go away
> > either.
> >
> No, the WAR flag for obs still can't be masked - the one place where the
> delay in declare_war is needed (in socket handler) is the same place where
> both player and observer would send declare war request.

What I would do, is change the code in socket.c that checks for the 'lockout'
flags that disable client input.  Make it so that observers don't get locked
out.  Then the observer flag mask can be restored to it's old value, so that
observers can see refit, war declare, and transwarp.


From xyzzy at speakeasy.org  Sat May 20 04:23:02 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Sat, 20 May 2006 02:23:02 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.GSO.4.58.0605191239260.18376@blinky>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191121450.16640@blinky>
	<Pine.LNX.4.58.0605191210230.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191239260.18376@blinky>
Message-ID: <Pine.LNX.4.58.0605200150460.12122@shell3.speakeasy.net>

On Fri, 19 May 2006, William Balcerski wrote:
> > ./ntserv/enter.c:      ShipFoo.s_letter = "sdcbaog*"[myship->s_type];
> > ./ntserv/interface.c:   ShipFoo.s_letter = "sdcbaog*"[me->p_ship.s_type];
> >
> Well I told the player to try * to refit but it wasn't working, he has to
> change to NetrekXP.

Some old vanilla server programmer is pissing me off.  The ATT was a
Paradise invention.  It was added as ship type 6.  Sometime later the
Bronco server code got galaxy ships (was it calvin?), and they used ship
type 6 for that.  Then a bronco server programmer copied the ATT from
Paradise, but added it as ship type 7.  It was a real pain in the ass for
me to make this work on both Bronco and Paradise servers!

When they copied the ATT, they decided instead of using the key 'X' to
select it, they would use '*'.  Just HAD to be different!

So in Paradise-2000 the key to pick ATT is initially 'X'.  Then the server
sends a shipcap packet, which re-programms the ATT's values to use the key
'*'.  So after you refit to an ATT, the key will change.  This annoys me,
but I have fixed it, so the key is always '*' on Bronco and 'X' on
Paradise.

I guess, since it wasn't possible to refit to an ATT, I never noticed this.


From williamb at its.caltech.edu  Sat May 20 11:38:39 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Sat, 20 May 2006 09:38:39 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 1 more)
In-Reply-To: <Pine.LNX.4.58.0605192053370.12122@shell3.speakeasy.net>
References: <200605190819.k4J8J0p6007774@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191057120.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191128160.16640@blinky>
	<Pine.LNX.4.58.0605191218240.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191243190.18376@blinky>
	<Pine.LNX.4.58.0605191313000.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191336290.18376@blinky>
	<Pine.LNX.4.58.0605192053370.12122@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605200929400.13979@inky>

> > > What are you talking about, observer sound?
> > >
> > I added in more sound support for observers (they can now hear shields
> > up/down for the ship they are observing).  This is where the shield sound
> > problem shows up with short packets on.  Oh and I forgot to mention one
>
> This works fine in Paradise-2000, it must be a bug in your code.
>
Well it happens most noticeably when locking onto iggies, client plays
shield up sound, then shield down, then shield up in rapid fashion.  Only
when short packets on (so iggy appears to have shields down when shields
are up).  If iggy actually goes into repair mode (drops shields), the
problem stops.  Is client getting conflicting information about iggy
shield state - only thing I can think of.

> What I would do, is change the code in socket.c that checks for the 'lockout'
> flags that disable client input.  Make it so that observers don't get locked
> out.  Then the observer flag mask can be restored to it's old value, so that
> observers can see refit, war declare, and transwarp

Sounds good, will make it so we can let observers change players if they
are observing a twarper (currently they can't change until the twarp state
is over).

> Seriously, why only 255?  That means I can still one up you with 256 in
> the next version of Paradise 2000.

Well I convert the p_dir to radians and rotate based on that, oops I guess
I meant 256.

> What else is lacking, that a non-borg client can use?

I would like torp/plasma fuse info sent for torps/plasmas fired on your
screen.  You'd already know how long they are going to last, so why not
send fuse info.  I would use this info to determine which torp was most
recently fired for purposes of where spatially to play the 3d sound event
for torp fire (I converted all sound to SDL, can have multiple sound
events with stereo effect).

Bill


From quozl at us.netrek.org  Sat May 20 20:50:59 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 21 May 2006 11:50:59 +1000
Subject: [netrek-dev] darcs patch: declare_war fix
In-Reply-To: <Pine.LNX.4.58.0605200135020.12122@shell3.speakeasy.net>
References: <200605190658.k4J6wSSP013995@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605191048540.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191111160.16640@blinky>
	<Pine.LNX.4.58.0605191150280.20296@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605191220300.18376@blinky>
	<Pine.LNX.4.58.0605200135020.12122@shell3.speakeasy.net>
Message-ID: <20060521015059.GA8007@us.netrek.org>

On Sat, May 20, 2006 at 01:40:30AM -0700, Trent Piepho wrote:
> What I would do, is change the code in socket.c that checks for the
> 'lockout' flags that disable client input.  Make it so that observers
> don't get locked out.  Then the observer flag mask can be restored to
> it's old value, so that observers can see refit, war declare, and
> transwarp.

I prefer that solution.  Good call.

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


From quozl at us.netrek.org  Sat May 20 22:09:32 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 21 May 2006 13:09:32 +1000
Subject: [netrek-dev] robotd testing and REALITY=n
Message-ID: <20060521030932.GA8949@us.netrek.org>

One of the useful methods to test robots on a fast machine is to change
etc/sysdef REALITY from 10 (the default) to 100.  This lets the robots
fight it out in a universe that runs at ten times the normal speed.

Beware, don't play in a universe with a REALITY other than 10, or your
reaction times are retrained for that universe, and you become less
useful in the standard universe.

Setting REALITY to 1 makes things ten times slower.  This can be useful
to test border cases.

Taking a cambot recording of the test lets you go back and verify that
things worked as you planned.

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


From williamb at its.caltech.edu  Sun May 21 03:55:46 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sun, 21 May 2006 03:55:46 -0500
Subject: [netrek-dev] darcs patch: declare_war fix (and 4 more)
Message-ID: <200605210855.k4L8tk2x021500@omen.digital-genesis.com>

Fri May 19 02:11:44 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
  Use this patch instead of previous one, had to change a variable name.
  This patch contains the following changes:
  
  M ./Vanilla/ChangeLog +8
  M ./Vanilla/include/proto.h -1 +1
  M ./Vanilla/include/warnings.h -1 +1
  M ./Vanilla/ntserv/enter.c -1 +1
  M ./Vanilla/ntserv/interface.c -2 +2
  M ./Vanilla/ntserv/socket.c -1 +1
  M ./Vanilla/robots/rmove.c -2 +2

Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
  * Phaser_Hit information equalization

Fri May 19 15:09:58 CDT 2006  williamb at its.caltech.edu
  * Declarewar ChangeLog fix

Fri May 19 23:00:56 CDT 2006  williamb at its.caltech.edu
  * Phasermsg Changelog Update

Sun May 21 03:55:03 CDT 2006  williamb at its.caltech.edu
  * Observer Mask and delay fix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 5819 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/3092dee1/attachment.bin 

From quozl at us.netrek.org  Sun May 21 05:46:22 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 21 May 2006 20:46:22 +1000
Subject: [netrek-dev] darcs patch: declare_war fix (and 4 more)
In-Reply-To: <200605210855.k4L8tk2x021500@omen.digital-genesis.com>
References: <200605210855.k4L8tk2x021500@omen.digital-genesis.com>
Message-ID: <20060521104622.GB5784@us.netrek.org>

Trent, are you okay with this one?  An acked-by or signed-off-by would
be appreciated.

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


From quozl at us.netrek.org  Sun May 21 06:54:08 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Sun, 21 May 2006 21:54:08 +1000
Subject: [netrek-dev] darcs patch: add game pause/resume/terminate tool,
	setgame
Message-ID: <E1FhmVc-0002Qq-LY@dors.lan>

Sun May 21 21:50:34 EST 2006  quozl at us.netrek.org
  * add game pause/resume/terminate tool, setgame
  
  	* tools/setgame.c: add script utility for pausing, resuming, and
  	terminating the game.
  
  	* tools/Makefile.in: add setgame target.
  
  	* ntserv/input.c (input): send bad version packet to terminate
  	client as soon as a GU_GAMEOK termination is requested.
  
  	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
  	possible if a GU_GAMEOK termination is requested.  Change nplayers
  	to nfree, to better explain what the variable is.
  
  	* include/struct.h (game_ok): remove unused macro.
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 8953 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/4825c791/attachment-0001.bin 

From quozl at us.netrek.org  Sun May 21 07:35:31 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Sun, 21 May 2006 22:35:31 +1000
Subject: [netrek-dev] darcs patch: fix two second delay on client connection
	if daemon no...
Message-ID: <E1Fhn9f-0002nV-OM@dors.lan>

Sun May 21 22:32:46 EST 2006  quozl at us.netrek.org
  * fix two second delay on client connection if daemon not running
  
  	Remove the two second delay experienced by clients that connect to
  	a server on which the daemon is not running.  Also fix a cause of
  	initial connection failing, which happens if the daemon does not
  	start up within the hoped-for interval.
  
  	Solution is implemented using the SIGUSR1 signal, but only during
  	the initialisation window between when ntserv forks the daemon and
  	the daemon completes initialisation.  The signal is not used at
  	other times.
  	
  	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
  	(ntserv) once initialisation of shared memory is completed and
  	regular SIGALRMs are about to commence.
  
  	* ntserv/openmem.c (openmem): remove two second delay that was
  	used to hope for daemon to initialise.
  	
  	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 6553 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/dca4dfc9/attachment.bin 

From jimmyhua73 at yahoo.com  Sun May 21 09:45:38 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 21 May 2006 07:45:38 -0700 (PDT)
Subject: [netrek-dev] robotd-fixes1.dpatch
Message-ID: <20060521144538.52501.qmail@web35307.mail.mud.yahoo.com>

Round 3. 

Made changes as suggested by Trent Piepho, also added
an additional bomb armies check. This is minor, so
hopefully it is okay to lump it in with this patch.

Please accept my patch. 

I've figured out the messaging problem where after a
few hours, the bots only send carrying messages but
not taking messages. 

Should I wait until this is accepted or send a
separate patch now for that too? 

Also found a "bug" in the genocide sequence with
newbie enabled. The genocide sequence moves Merlin to
the geno'd planet. But doesn't put him back. 

I created code in newbie.c to check for this, and
Merlin moves himself back after a while. Send patch or
wait? 


Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-fixes1.dpatch
Type: application/octet-stream
Size: 9952 bytes
Desc: 1826896968-robotd-fixes1.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/293df27e/attachment.obj 

From jimmyhua73 at yahoo.com  Sun May 21 09:51:25 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 21 May 2006 07:51:25 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
Message-ID: <20060521145125.10392.qmail@web35305.mail.mud.yahoo.com>

Hi Stephen, 

If it is okay with you, I am already implementing your
suggestions with regard to the changelog.

... Which is to input my relevant changes into the
darcs file instead of changing the changelog file. 

It is formatted the same way, so a simple cut and past
should do the trick. 

Jimmy

P.S. Anyone think it might be worthwhile to implement
shortpackets into hadley's robots? Once I'm done
debugging and improving the fight characteristics ... 

Personally, I think I want to keep it as is. The old
networking scheme seems to be rock solid, at least
when it's all on one computer :-P. 




From xyzzy at speakeasy.org  Sun May 21 13:05:21 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Sun, 21 May 2006 11:05:21 -0700 (PDT)
Subject: [netrek-dev] darcs patch: declare_war fix (and 4 more)
In-Reply-To: <200605210855.k4L8tk2x021500@omen.digital-genesis.com>
References: <200605210855.k4L8tk2x021500@omen.digital-genesis.com>
Message-ID: <Pine.LNX.4.58.0605211104230.30394@shell3.speakeasy.net>

+           if (((FD_ISSET(*bufptr, &inputMask)) &&
+                (me==NULL || (me->p_flags & PFOBSERV)

The proper way to check for observer in the server is to check p_status
against POBSERV, that is how it is done everywhere else.  You should also
protect it with #ifdef OBSERVERS like all the other observer code.


From williamb at its.caltech.edu  Sun May 21 19:16:35 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sun, 21 May 2006 19:16:35 -0500
Subject: [netrek-dev] darcs patch: declare_war fix (and 5 more)
Message-ID: <200605220016.k4M0GZPs014952@omen.digital-genesis.com>

Fri May 19 02:11:44 CDT 2006  williamb at its.caltech.edu
  * declare_war fix
  Use this patch instead of previous one, had to change a variable name.
  This patch contains the following changes:
  
  M ./Vanilla/ChangeLog +8
  M ./Vanilla/include/proto.h -1 +1
  M ./Vanilla/include/warnings.h -1 +1
  M ./Vanilla/ntserv/enter.c -1 +1
  M ./Vanilla/ntserv/interface.c -2 +2
  M ./Vanilla/ntserv/socket.c -1 +1
  M ./Vanilla/robots/rmove.c -2 +2

Fri May 19 03:17:50 CDT 2006  williamb at its.caltech.edu
  * Phaser_Hit information equalization

Fri May 19 15:09:58 CDT 2006  williamb at its.caltech.edu
  * Declarewar ChangeLog fix

Fri May 19 23:00:56 CDT 2006  williamb at its.caltech.edu
  * Phasermsg Changelog Update

Sun May 21 03:55:03 CDT 2006  williamb at its.caltech.edu
  * Observer Mask and delay fix

Sun May 21 19:16:03 CDT 2006  williamb at its.caltech.edu
  * Observ patch fix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 6133 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/f651fbde/attachment.bin 

From quozl at us.netrek.org  Sun May 21 19:40:06 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 22 May 2006 10:40:06 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060521145125.10392.qmail@web35305.mail.mud.yahoo.com>
References: <20060521145125.10392.qmail@web35305.mail.mud.yahoo.com>
Message-ID: <20060522004006.GA6615@us.netrek.org>

On Sun, May 21, 2006 at 07:51:25AM -0700, Jimmy Huang wrote:
> ... Which is to input my relevant changes into the
> darcs file instead of changing the changelog file. 

Until the 1st June release, I'm still requiring ChangeLog and NEWS
updates.  If you get someone else to do them, that's fine.  If it's in a
separate patch, that's also fine.  If I really like the patch and want
to make sure it gets in, I'll do the extra work myself.  If you want to
remove barriers to your patch being taken, you can help by making it
easier for me.

> P.S. Anyone think it might be worthwhile to implement
> shortpackets into hadley's robots? 

If the extra information given by short packets is useful to the 'bot,
that's a good enough justification.  Network traffic isn't a
justification, as the bots are normally run locally.

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


From williamb at its.caltech.edu  Sun May 21 20:38:20 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sun, 21 May 2006 20:38:20 -0500
Subject: [netrek-dev] darcs patch: Declare_war fix
Message-ID: <200605220138.k4M1cKwT022188@omen.digital-genesis.com>

Sun May 21 20:29:30 CDT 2006  williamb at its.caltech.edu
  * Declare_war fix
          * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
            added boolean to declare_war function to indicate whether to
            add delay and send delay message.  Fixes the case of unwanted 
            war delay message when switching teams, and also prevents robots
            from entering a state of permanent declare war delay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10998 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/f1cdd42b/attachment-0001.bin 

From williamb at its.caltech.edu  Sun May 21 20:41:56 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sun, 21 May 2006 20:41:56 -0500
Subject: [netrek-dev] darcs patch: Phaser hit information equalization
Message-ID: <200605220141.k4M1ful3022377@omen.digital-genesis.com>

Sun May 21 20:39:01 CDT 2006  williamb at its.caltech.edu
  * Phaser hit information equalization
          * phaser.c: Added player # and team letter to the non-short packet
            phaser hit message.  Logic as follows: short packet phaser hit
            message already sends player number.  A smart client can extract
            both player name and team letter from this piece of data.  Thus,
            short packet was sending more useful information than long
            packets.  This information is most relevant for phasering 
            cloakers.  This patch was checked to be compatable with the 
            latest version of all major open source clients: COW 3.01,
            Ted Turner 1.3.1, BRMH 2.4.0, Netrek XP, and Netrek XP Mod.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10690 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/d361154d/attachment.bin 

From williamb at its.caltech.edu  Sun May 21 20:43:32 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sun, 21 May 2006 20:43:32 -0500
Subject: [netrek-dev] darcs patch: Observ mask fix
Message-ID: <200605220143.k4M1hWMw022413@omen.digital-genesis.com>

Sun May 21 20:41:59 CDT 2006  williamb at its.caltech.edu
  * Observ mask fix
          * socket.c, redraw.c: removal of lockup for observers under
            declare war/transwarp/refit situations.  Reverses previous
            patch by restoring PFWAR and PFREFITTING mask to observers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10409 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/d63c2cec/attachment.bin 

From quozl at us.netrek.org  Sun May 21 21:25:07 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Mon, 22 May 2006 12:25:07 +1000
Subject: [netrek-dev] darcs patch: setteam usage fix
Message-ID: <E1Fi06V-0003jK-1z@dors.lan>

Mon May 22 12:23:27 EST 2006  quozl at us.netrek.org
  * setteam usage fix
  	* tools/setteam.c: fix error in usage propogated from setplanet,
  	and remove unnecessary include.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10005 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060522/1f3762ef/attachment-0001.bin 

From jimmyhua73 at yahoo.com  Mon May 22 00:18:39 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 21 May 2006 22:18:39 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522004006.GA6615@us.netrek.org>
Message-ID: <20060522051839.5820.qmail@web35309.mail.mud.yahoo.com>

> Until the 1st June release, I'm still requiring
> ChangeLog and NEWS
> updates.  

Okay. Attaching both dpatches here for your
convenience. 

> If you get someone else to do them, that's
> fine.  If it's in a
> separate patch, that's also fine.  If I really like
> the patch and want
> to make sure it gets in, I'll do the extra work
> myself.  If you want to
> remove barriers to your patch being taken, you can
> help by making it
> easier for me.

Dang James. U R a cool guy! Gotta meet some of you in
real life one of these days. 

Btw, although I mentioned that I fixed the "carrying"
then "taking" messages in the robotd.  It is only
partially fixed. There's another bug to do with the
_udcounter turning into a negative number which causes
the "taking" messages to disappear again. 

I'll have that patch (and others sent in), as soon as
I can verify this one has been accepted. (darcs get).
There's like 45 hunks to send out, and I'm getting
confused so I want to make sure it compiles and works,
before I send the others. 

Not sure how I can verify this myself.

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-fixes1-Changlog.dpatch
Type: application/octet-stream
Size: 7735 bytes
Desc: 1772805029-robotd-fixes1-Changlog.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/74be3ee0/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-fixes1.dpatch
Type: application/octet-stream
Size: 9952 bytes
Desc: 1826896968-robotd-fixes1.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060521/74be3ee0/attachment-0001.obj 

From quozl at us.netrek.org  Mon May 22 01:16:13 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Mon, 22 May 2006 16:16:13 +1000
Subject: [netrek-dev] darcs patch: revise build test after libtoolize
	adoption
Message-ID: <E1Fi3i9-0005Ou-9Y@dors.lan>

Mon May 22 16:10:37 EST 2006  quozl at us.netrek.org
  * revise build test after libtoolize adoption
  Stephen Thorne's addition of libtool to the configuration requires a
  change to the build test sequence, to run libtoolize and aclocal.
  Also it is no longer necessary to make configure executable, as autoconf
  does that for us.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10314 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060522/f94e31c1/attachment-0001.bin 

From quozl at us.netrek.org  Mon May 22 01:40:16 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 22 May 2006 16:40:16 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522051839.5820.qmail@web35309.mail.mud.yahoo.com>
References: <20060522004006.GA6615@us.netrek.org>
	<20060522051839.5820.qmail@web35309.mail.mud.yahoo.com>
Message-ID: <20060522064016.GK6615@us.netrek.org>

On Sun, May 21, 2006 at 10:18:39PM -0700, Jimmy Huang wrote:
> Okay. Attaching both dpatches here for your
> convenience. 

Stephen Thorne already supplied a ChangeLog patch for your patch.

> I'll have that patch (and others sent in), as soon as
> I can verify this one has been accepted. (darcs get).
> There's like 45 hunks to send out, and I'm getting
> confused so I want to make sure it compiles and works,
> before I send the others. 

Hrm, you should probably "darcs pull" from the netrek.org repository
now, to prove to yourself that the change was accepted.  Do it on a copy
of your repository first to test.

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


From quozl at us.netrek.org  Mon May 22 08:29:20 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 22 May 2006 23:29:20 +1000
Subject: [netrek-dev] bug: newbie robotd oscillation
Message-ID: <20060522132920.GA4157@us.netrek.org>

In the current code in the darcs repo, if Merlin chooses Kli and Ori as
the teams, but the first human player chooses Rom, then Merlin begins
spawning the remainder of the robots as Rom.  Each robot spawned is then
obliterated to make room for a human (according to the message to ALL).

Eventually the terminator arrives to take out the lone human, but Merlin
continues to insist on starting robots as Rom.

See the recordings:

http://quozl.linux.org.au/tmp/cambot-1.pkt.gz
http://quozl.linux.org.au/tmp/cambot-2.pkt.gz

These can be played by gunzip'ing them and then using "netrek -F
cambot-1.pkt"

Any ideas, Jimmy?  Does this relate to newbiebetter.dpatch?

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


From quozl at us.netrek.org  Mon May 22 08:22:34 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 22 May 2006 23:22:34 +1000
Subject: [netrek-dev] CVS COW on Linux Segfaults
Message-ID: <20060522132234.GA3015@us.netrek.org>

I've been seeing a curious problem with the current CVS of COW on Linux,
resulting in segfaults and corruption of display data.

Whenever it happens, I can "fix" it by changing the build slightly, e.g.
by adding another call or disabling a call, and it comes good again.

gdb backtraces show corruption of various data structures, especially
the "me" pointer, but also occasionally of other things.

At one stage I thought I'd reduced it to the addition of Imlib2, but
removing all calls to Imlib2 and leaving it as just the difference
between -lImlib2 or not during link ... and I still got the fault if
Imlib2 is included in the link.

But now having added -lXxf86vm for the video mode change feature, I find
that this does it in as well.

Things I've tried to do to exclude it:

1.  used valgrind to detect reads or writes outside permitted memory
areas ... doesn't tell me where the problem is caused, only tells me
when it manifests,

2.  worked through all the compilation warnings in x11window.c and fixed
them all ... no difference,

3.  added display synchronisation ... seems to make a statistical
difference, but then the problem can return after another program change
and turning off synchronisation fixes it, frustratingly.

4.  added or removed -g,

5.  added or removed -O2.

Any other ideas?  Test reports?

I'm yet to do a regression analysis to find which version builds and
doesn't cause the problem ... but I'm inclined to believe it will be
before the addition of extra libraries.

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


From xyzzy at speakeasy.org  Mon May 22 13:35:43 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Mon, 22 May 2006 11:35:43 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522051839.5820.qmail@web35309.mail.mud.yahoo.com>
References: <20060522051839.5820.qmail@web35309.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>

On Sun, 21 May 2006, Jimmy Huang wrote:
> > Until the 1st June release, I'm still requiring
> > ChangeLog and NEWS
> > updates.
>
> Okay. Attaching both dpatches here for your
> convenience.

I don't understand why you don't follow the style of the existing code.
Hadley is very consistent in his use of three spaces of indention.  Not my
faviorate number, but that is what the code uses.  This is very small patch,
it should take all of 30 seconds to go through and check that the indention is
correct.

I also think the change to remove mfprintf is not a good idea.  I checked the
function on my computer, it works fine.  No crashes.  I don't see anything
broken about it.  I suspect that maybe you are wrong about the problem with
mfprintf.  At any rate, that band-aid will never fix the bug.  It's like the
random changes you made for the closest planet bug, they had nothing to do
with the real problem and didn't fix it.


From xyzzy at speakeasy.org  Mon May 22 16:29:46 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Mon, 22 May 2006 14:29:46 -0700 (PDT)
Subject: [netrek-dev] glib in Makefile
Message-ID: <Pine.LNX.4.58.0605221428430.23374@shell2.speakeasy.net>

The Makefile includes calls to glib-config, which aren't necessary to
build the server, and fail if glib-config doesn't exist.  If someone
wants to enable the (disabled) database timing functionality that uses
glib, they can just add the options when they run configure.

-------------- next part --------------

New patches:

[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
<
> {
hunk ./Vanilla/ntserv/Makefile.in 85
 all: $(PMAKE) ntserv daemonII 
 
 ntserv: $(PMAKE) $(R_OBJS)
-	$(CC) $(CFLAGS) ${LDFLAGS} -o ntserv $(R_OBJS) $(LIBS) $(LIBCRYPT) `glib-config --libs` -lgdbm
+	$(CC) $(CFLAGS) ${LDFLAGS} -o ntserv $(R_OBJS) $(LIBS) $(LIBCRYPT) -lgdbm
 
 daemonII: $(PMAKE) $(D_OBJS)
 	$(CC) $(CFLAGS) ${LDFLAGS} -o daemonII $(D_OBJS) $(EXTRALIBS)
hunk ./Vanilla/ntserv/Makefile.in 101
 	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/commands.c
 
 db.o: $(PMAKE) db.c
-	$(CC) $(CFLAGS) $(DEP) `glib-config --cflags` -c db.c
+	$(CC) $(CFLAGS) $(DEP) -c db.c
 
 cflags:
 	echo "static char cflags[]=\"$(CFLAGS) $(LIBS)\";" >../cflags.h
}

Context:

[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
127bb6289e919cb87703d00ad26874cbe8f378be

From xyzzy at speakeasy.org  Mon May 22 16:22:04 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Mon, 22 May 2006 14:22:04 -0700 (PDT)
Subject: [netrek-dev] Problem with res-rsa configure and gmp
Message-ID: <Pine.LNX.4.58.0605221335250.4835@shell2.speakeasy.net>

The test for libgmp in the configure script for res-rsa doesn't work.  In
new versions of gmp, the gmp.h header files #defines functions to different
names, like mpz_init() to __gmpz_init().  It looks like the autoconf test
for libgmp doesn't include gmp.h and so continues to look for mpz_init in
libgmp.

I don't know autoconf, but I found a dated fix on the web:
http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html

I adapted this to res-rsa and it appears to work.  I'm attaching a darcs patch
to fix this in configure.in.  I'm not include the change to configure, since it
is a generated file.
-------------- next part --------------

New patches:

[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Mon May 22 14:03:38 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* res-rsa/configure.in  The check for gmp fails for gmp version 3,
+	fix it by adding a secondary check for the gmp3 symbol names.
+
 Mon May 22 10:53:03 2006  Jimmy Huang  <jimmyhua73 at yahoo.com>
 
 	* robotd/assault.c added extra check not to bomb your own armies. 
hunk ./Vanilla/res-rsa/configure.in 112
       LDOLD="$LDFLAGS"
       LDFLAGS="$GMP_LIB -lgmp"
       AC_CHECK_LIB(gmp, mpz_fdiv_q_ui, AC_DEFINE(HAVE_LIB_GMP2) GMP_VER=2)
+      if test $ac_cv_lib_gmp_mpz_fdiv_q_ui = no; then
+        dnl with gmp3 it's a #define, use real function name
+        AC_CHECK_LIB(gmp, __gmpz_fdiv_q_ui, AC_DEFINE(HAVE_LIB_GMP2) GMP_VER=2)
+      fi
       LDFLAGS="$LDOLD"
     fi
 
hunk ./Vanilla/res-rsa/configure.in 130
 
     if test $GMP_VER = 1; then
       AC_CHECK_LIB(gmp, mpz_init, AC_DEFINE(HAVE_LIB_GMP), GMP_VER=0)
+      if test $ac_cv_lib_gmp_mpz_init = no; then
+        dnl with gmp3 it's a #define, use real function name
+        AC_CHECK_LIB(gmp, __gmpz_init, AC_DEFINE(HAVE_LIB_GMP2) GMP_VER=2)
+      fi
     fi
 
     # Check for GMP2
hunk ./Vanilla/res-rsa/configure.in 139
     if test $GMP_VER = 1; then
       AC_CHECK_LIB(gmp, mpz_fdiv_q_ui, AC_DEFINE(HAVE_LIB_GMP2) GMP_VER=2)
+      if test $ac_cv_lib_gmp_mpz_fdiv_q_ui = no; then
+        dnl with gmp3 it's a #define, use real function name
+        AC_CHECK_LIB(gmp, __gmpz_fdiv_q_ui, AC_DEFINE(HAVE_LIB_GMP2) GMP_VER=2)
+      fi
     fi
 
   fi
}

Context:

[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
7b84a2950c1b3d2cb577473ecc19555f608007de

From jimmyhua73 at yahoo.com  Mon May 22 18:06:40 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 22 May 2006 16:06:40 -0700 (PDT)
Subject: [netrek-dev] bug: newbie robotd oscillation
In-Reply-To: <20060522132920.GA4157@us.netrek.org>
Message-ID: <20060522230640.56653.qmail@web35309.mail.mud.yahoo.com>

Hi James, 

Whoa! This is weird. 

Merlin chooses Kli vs. Ori. But human chooses Rom. 

In a 1 vs. 1 vs. 1. The bot will prefer Rom vs. Kli,
and start spawning Roms or Klis. 

Once there is a 4 vs. 4 game, it will start to wipe
out the 3rd team. 

This is what was supposed to happen.

I think what happened here is: 

There was already a Kli vs. Ori 3 vs. 3 or maybe even
a 4 vs. 4. Human joins Rom (somehow!), the server will
allow it if t-mode hasn't been set yet. 

Since Merlin still prefers a Rom vs. Kli game, it will
start to spawn Roms. Since, the server does not
restrict which teams the bots can join, Roms will come
in. 

But since, there is a 4 vs. 4 game Kli vs. Ori, Merlin
will subsequently wipe a Rom out.  Playing his own
little polish game. Starting a Rom, cuz Merlin prefers
a Rom vs. Kli game (doesn't check for t-mode when
starting players). And subsequently wiping that same
Rom out when it does it's 3rd team robot scummer
check. 

I knew this race condition was possible. But, you have
to have good timing in clicking Roms, to make this
happen! U R good!

newbiebetter.patch doesn't fix this.  You have to have
good timing to make this race condition happen
everytime. But, once it starts, it doesn't stop until
all human players quit. 

Let me see what I can do to fix this. 

Jimmy

--- James Cameron <quozl at us.netrek.org> wrote:

> In the current code in the darcs repo, if Merlin
> chooses Kli and Ori as
> the teams, but the first human player chooses Rom,
> then Merlin begins
> spawning the remainder of the robots as Rom.  Each
> robot spawned is then
> obliterated to make room for a human (according to
> the message to ALL).
> 
> Eventually the terminator arrives to take out the
> lone human, but Merlin
> continues to insist on starting robots as Rom.
> 
> See the recordings:
> 
> http://quozl.linux.org.au/tmp/cambot-1.pkt.gz
> http://quozl.linux.org.au/tmp/cambot-2.pkt.gz
> 
> These can be played by gunzip'ing them and then
> using "netrek -F
> cambot-1.pkt"
> 
> Any ideas, Jimmy?  Does this relate to
> newbiebetter.dpatch?
> 
> -- 
> 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  Mon May 22 18:26:00 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 09:26:00 +1000
Subject: [netrek-dev] bug: newbie robotd oscillation
In-Reply-To: <20060522230640.56653.qmail@web35309.mail.mud.yahoo.com>
References: <20060522132920.GA4157@us.netrek.org>
	<20060522230640.56653.qmail@web35309.mail.mud.yahoo.com>
Message-ID: <20060522232600.GA7001@us.netrek.org>

On Mon, May 22, 2006 at 04:06:40PM -0700, Jimmy Huang wrote:
> I knew this race condition was possible. But, you have
> to have good timing in clicking Roms, to make this
> happen! U R good!

Slowing REALITY has it's advantages.  But I did this at normal speed.

> Let me see what I can do to fix this. 

Great, thanks.

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


From jimmyhua73 at yahoo.com  Mon May 22 18:21:45 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 22 May 2006 16:21:45 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
Message-ID: <20060522232145.13570.qmail@web35313.mail.mud.yahoo.com>

> I also think the change to remove mfprintf is not a
> good idea.  I checked the
> function on my computer, it works fine.  No crashes.
>  I don't see anything
> broken about it.  I suspect that maybe you are wrong
> about the problem with
> mfprintf.  At any rate, that band-aid will never fix
> the bug.  It's like the
> random changes you made for the closest planet bug,
> they had nothing to do
> with the real problem and didn't fix it.

Okay, I remember the condition which causes mfprintf
to SIGSEV. 

Manually start a robot in the normal port 2592,
request it to join a team that is not allowed. 

It will try to join that team 3 times, then fail.
Instead of an graceful exit or joining a different
team, it executes the mfprintf, and SIGSEVs. 

The robot defaults to joining Roms. 

So what I did was:

gdb robot

run -h localhost

during a Fed vs. Ori game. 

I can try it again, and see if it coredumps or not. 

Jimmy


From quozl at us.netrek.org  Mon May 22 18:28:42 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 09:28:42 +1000
Subject: [netrek-dev] glib in Makefile
In-Reply-To: <Pine.LNX.4.58.0605221428430.23374@shell2.speakeasy.net>
References: <Pine.LNX.4.58.0605221428430.23374@shell2.speakeasy.net>
Message-ID: <20060522232842.GB7001@us.netrek.org>

On Mon, May 22, 2006 at 02:29:46PM -0700, Trent Piepho wrote:
> remove glib-config from Makefile.in

Taken, thanks.

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


From quozl at us.netrek.org  Mon May 22 18:31:01 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 09:31:01 +1000
Subject: [netrek-dev] Problem with res-rsa configure and gmp
In-Reply-To: <Pine.LNX.4.58.0605221335250.4835@shell2.speakeasy.net>
References: <Pine.LNX.4.58.0605221335250.4835@shell2.speakeasy.net>
Message-ID: <20060522233101.GC7001@us.netrek.org>

On Mon, May 22, 2006 at 02:22:04PM -0700, Trent Piepho wrote:
> resrsa-gmp-autoconf.darcs

Taken, thanks.

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


From jimmyhua73 at yahoo.com  Mon May 22 18:32:40 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 22 May 2006 16:32:40 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
Message-ID: <20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>


> I don't understand why you don't follow the style of
> the existing code.
> Hadley is very consistent in his use of three spaces
> of indention.  Not my
> faviorate number, but that is what the code uses. 
> This is very small patch,
> it should take all of 30 seconds to go through and
> check that the indention is
> correct.

Okay, I'll do that.

I misinterpreted the STYLE document to meaning you
change it to 4 space indent where-ever you change a
block of code. In actuality, you have to change the
whole function before you change the indent to 4
spaces. 

Jimmy



From quozl at us.netrek.org  Mon May 22 19:08:03 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 10:08:03 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522232145.13570.qmail@web35313.mail.mud.yahoo.com>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522232145.13570.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <20060523000803.GE7001@us.netrek.org>

On Mon, May 22, 2006 at 04:21:45PM -0700, Jimmy Huang wrote:
> Okay, I remember the condition which causes mfprintf
> to SIGSEV. 
> 
> Manually start a robot in the normal port 2592,
> request it to join a team that is not allowed. 
> 
> It will try to join that team 3 times, then fail.
> Instead of an graceful exit or joining a different
> team, it executes the mfprintf, and SIGSEVs. 

I think you need to look at the arguments given to mfprintf by the
calling function.  Use bt in gdb to see what called it, and check each
argument is correct using gdb.

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


From jimmyhua73 at yahoo.com  Mon May 22 19:38:30 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 22 May 2006 17:38:30 -0700 (PDT)
Subject: [netrek-dev] mfprintf in robotd
Message-ID: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>

Okay, 

I uncommented all references to mfprintf in the code,
and could not get the function to execute on it's own
anymore. 

So what I did was: 

1. start a bunch of robots until you could join in,
but not get the wait queue. U see 8 vs. 8, but cannot
join any teams. 

2. looked for the phrase "team or ship rejected" in
main.c. There are 2 instances of this phrase, one uses
mprintf and the other uses mfprintf. 

3. replaced the mprintf phrase to match that of the
mfprintf phrase:

mfprintf(stderr, "team or ship rejected.\n");

I assume you can run the above function from anywhere
in main.c and it should spit out a message. If your
team or ship gets rejected. 

gdb robot

run -h localhost
Starting program:
/home/jimmyhua/darcs/netrek-server/Vanilla/robotd/robot
-h localhost
Calling localhost.
Got connection.
non-udp client send.
initializing planets
login ...non-udp client send.
non-udp client send.

non-udp client send.
team ...

sent TeamReq team: 1, ship: 2
non-udp client send.
-> Server sending PING packets at 2 second intervals
-> I cannot allow that.  Pick another team
got pickOk = 0

Program received signal SIGSEGV, Segmentation fault.
0x400abf79 in vfprintf () from /lib/libc.so.6
(gdb) bt
#0  0x400abf79 in vfprintf () from /lib/libc.so.6
#1  0x08068d9d in mfprintf (format=0x65796200 "") at
util.c:455
#2  0x080605be in main (argc=3, argv=0x0) at
main.c:403

Any ideas? 

Jimmy


From jimmyhua73 at yahoo.com  Mon May 22 19:15:54 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 22 May 2006 17:15:54 -0700 (PDT)
Subject: [netrek-dev] robotd-indent-fix.dpatch
Message-ID: <20060523001554.32786.qmail@web35314.mail.mud.yahoo.com>

indent fixes for robotd. 3 spaces instead of 4 spaces
for the code I changed. 

Hoping I don't need a ChangeLog or NEWS for this, as
it's not here :-). 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-indent-fix.dpatch
Type: application/octet-stream
Size: 13420 bytes
Desc: 3123178939-robotd-indent-fix.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060522/20c8baa3/attachment-0001.obj 

From jimmyhua73 at yahoo.com  Mon May 22 20:13:14 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 22 May 2006 18:13:14 -0700 (PDT)
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <20060523011314.69549.qmail@web35301.mail.mud.yahoo.com>


I'm under the impression that mfprintf is used for
debugging. If this is the case, you should be able to
call

mfprintf(stderr, "foo.\n");

from anywhere in the program so as to get a printout
and know that that portion of code got executed. 

So, I don't think U need to do something as convoluted
as I did to test mfprintf. 

Stick it in the check_take function, when it decides
to announce that it carries... send an mfprintf.... It
really does crash horribly. Not sure why though. 

Looking at the backtrace, vfprintf isn't getting what
it wants. So va_start() or va_arg() isn't working
properly. va_start is used in mprintf which works
fine. 

So va_arg has a problem interpreting and sending the
right parameters to vfprintf. But, va_arg is a library
call. 

Did a "man va_arg", and went Huh? Didn't understand
how to use it.  As mprintf or fprintf works just as
good for debugging purposes..... :-P.  Yeah, I suck at
programming.

Jimmy



From quozl at us.netrek.org  Mon May 22 21:01:30 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 12:01:30 +1000
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060523012902.GG7001@us.netrek.org>
References: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>
	<20060523012902.GG7001@us.netrek.org>
Message-ID: <20060523020130.GH7001@us.netrek.org>

This regression in mfprintf was introduced in October 2003 by ReK, in a
patch to replace varargs with stdarg.

http://mailman.us.netrek.org/pipermail/netrek-dev/2003-October/001266.html

http://mailman.us.netrek.org/pipermail/netrek-dev/2003-October/001267.html

We lacked controls to detect the regression.
Successful controls may have been:

1.  prototypes for functions,

2.  test scripts validated against code coverage,

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


From stephen.thorne at gmail.com  Mon May 22 21:44:37 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 23 May 2006 12:44:37 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>

On 5/23/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>
> > I don't understand why you don't follow the style of
> > the existing code.
> > Hadley is very consistent in his use of three spaces
> > of indention.  Not my
> > faviorate number, but that is what the code uses.
> > This is very small patch,
> > it should take all of 30 seconds to go through and
> > check that the indention is
> > correct.
>
> Okay, I'll do that.
>
> I misinterpreted the STYLE document to meaning you
> change it to 4 space indent where-ever you change a
> block of code. In actuality, you have to change the
> whole function before you change the indent to 4
> spaces.

I'd much rather see 3 space indentation die horribly and get replaced
with a sane 4 space indent.

As such, I've been making plans for after a release of the various
codebases (cow, netrekxp, vanilla) all three codebases should go
through a 'cleanup'. Doing a cleanup will break all patches, so there
will have to be a post-release development freeze.

My desire:

June 1st: Release of cow, netrekxp and vanilla. Source tarballs
published, and repoistories tagged. All development frozen.
June 2-8: Volunteers go through codebases, file by file, and sanitise
the code. Would prefer one commit per file (easier to spot regressions
and back out changes).
June 9th+: All new patches required to apply cleanly against the new,
clean, source.

How do you folks feel about that?
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Mon May 22 23:04:45 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Mon, 22 May 2006 21:04:45 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522232145.13570.qmail@web35313.mail.mud.yahoo.com>
References: <20060522232145.13570.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605222101120.11796@shell2.speakeasy.net>

On Mon, 22 May 2006, Jimmy Huang wrote:
> > I also think the change to remove mfprintf is not a
> > good idea.  I checked the
> > function on my computer, it works fine.  No crashes.
> >  I don't see anything
> > broken about it.  I suspect that maybe you are wrong
> > about the problem with
> > mfprintf.  At any rate, that band-aid will never fix
> > the bug.  It's like the
> > random changes you made for the closest planet bug,
> > they had nothing to do
> > with the real problem and didn't fix it.
>
> Okay, I remember the condition which causes mfprintf
> to SIGSEV.

Don't worry about this anymore.  I finally installed darcs and got the latest
version.  Someone has converted it from varargs to stdarg, but they didn't do
mfprintf() correctly.  I'm surprised no one who should know better has said
anything, the bug is obvious.  I have already fixed it, and will send it
when I have a patch bundle ready.


From quozl at us.netrek.org  Mon May 22 23:39:19 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 14:39:19 +1000
Subject: [netrek-dev] darcs patch: Phaser hit information equalization
In-Reply-To: <200605220141.k4M1ful3022377@omen.digital-genesis.com>
References: <200605220141.k4M1ful3022377@omen.digital-genesis.com>
Message-ID: <20060523043919.GM7001@us.netrek.org>

On Sun, May 21, 2006 at 08:41:56PM -0500, williamb at its.caltech.edu wrote:
> Sun May 21 20:39:01 CDT 2006  williamb at its.caltech.edu
>   * Phaser hit information equalization

Rejected.  Breaks Paradise 2000, according to reports.  My better
understanding of the short packets changes (it's been a few years) are
that the information doesn't need equalisation.  My apologies for
previous simplistic explanations ... think of short packets as a
revision to the protocol that had the benefit of reducing bandwidth.

Is there any reason why you can't use short packets for this?

If so, can we add new packets to get what you need?  Parsing a text
message shouldn't be the way to design new features.  I prefer new
packet types and feature packets to negotiate them.

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


From xyzzy at speakeasy.org  Mon May 22 23:14:57 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Mon, 22 May 2006 21:14:57 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
References: <20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605222105110.11796@shell2.speakeasy.net>

On Mon, 22 May 2006, Jimmy Huang wrote:
> > I don't understand why you don't follow the style of
> > the existing code.
> > Hadley is very consistent in his use of three spaces
> > of indention.  Not my
> > faviorate number, but that is what the code uses.
> > This is very small patch,
> > it should take all of 30 seconds to go through and
> > check that the indention is
> > correct.
>
> Okay, I'll do that.

Don't worry about it, I will take care of all these fixes.

> I misinterpreted the STYLE document to meaning you
> change it to 4 space indent where-ever you change a
> block of code. In actuality, you have to change the
> whole function before you change the indent to 4
> spaces.

The only two reasonable courses of action I see for Hadley's code are:

1.  Stay consistent with the existing style.  The code is pretty good in
this regard, being consistent to itself.

2.  Convert the entire bot code to a different style, like a more common
indention level (I like 4).  Then always use that.

Changing bits and pieces of a code base that is very consistent to itself
to a different style is just a bad idea.


From quozl at us.netrek.org  Mon May 22 23:31:20 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 14:31:20 +1000
Subject: [netrek-dev] darcs patch: Declare_war fix
In-Reply-To: <200605220138.k4M1cKwT022188@omen.digital-genesis.com>
References: <200605220138.k4M1cKwT022188@omen.digital-genesis.com>
Message-ID: <20060523043120.GK7001@us.netrek.org>

On Sun, May 21, 2006 at 08:38:20PM -0500, williamb at its.caltech.edu wrote:
> Sun May 21 20:29:30 CDT 2006  williamb at its.caltech.edu
>   * Declare_war fix

Taken, thanks.

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


From quozl at us.netrek.org  Mon May 22 23:33:11 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 14:33:11 +1000
Subject: [netrek-dev] darcs patch: Observ mask fix
In-Reply-To: <200605220143.k4M1hWMw022413@omen.digital-genesis.com>
References: <200605220143.k4M1hWMw022413@omen.digital-genesis.com>
Message-ID: <20060523043311.GL7001@us.netrek.org>

On Sun, May 21, 2006 at 08:43:32PM -0500, williamb at its.caltech.edu wrote:
> Sun May 21 20:41:59 CDT 2006  williamb at its.caltech.edu
>   * Observ mask fix
>           * socket.c, redraw.c: removal of lockup for observers under
>             declare war/transwarp/refit situations.  Reverses previous
>             patch by restoring PFWAR and PFREFITTING mask to observers.

Taken, thanks.

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


From quozl at us.netrek.org  Mon May 22 23:17:29 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Tue, 23 May 2006 14:17:29 +1000
Subject: [netrek-dev] darcs patch: fix lack of shields shown on practice
	robots and iggies
Message-ID: <E1FiOKn-00077M-BV@dors.lan>

Tue May 23 14:04:21 EST 2006  quozl at us.netrek.org
  * fix lack of shields shown on practice robots and iggies
  	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
  	and hunter-killer, in conjunction with short packets version two,
  	shields were not being sent.  Changed to send shields in SP_FLAGS.
  	See also "S_P2 new flag sampling" in updateShips().  Reported by
  	William Balcerski.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10252 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060523/8df7525b/attachment.bin 

From quozl at us.netrek.org  Mon May 22 23:15:42 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 14:15:42 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
	<3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
Message-ID: <20060523041542.GI7001@us.netrek.org>

I was initially in favour of this, but now I'm not so sure ... mainly
because the recent development work has had me looking at older code
quite frequently!

I'm wondering what the benefit will be of standardised indenting.  I'm
worried that we're just creating work for ourselves.  The creation of
incompatibility with the previous versions of the code is a significant
cost, and as far as I can tell the only benefit of re-indentation is
enhanced understanding of the code when someone new looks at it.

What other reasons are there for reindenting?

If we don't do a mass indent, then we can stick to STYLE as it currently
stands.  That's my alternate proposal.

COW was indented after the fork that produced the current Netrek XP 2006
code base.  I was just going through defs.h for both clients today and
found COW had been tidied.  Some of that I'm tempted to restore to what
it was.  So if the tidy and indent done by COW years ago has had any
effect, it's to hinder a merge with Netrek XP.

Potential future merge for Vanilla is to the Paradise code.

I do see a need for adding prototypes.  I've successfully used cproto to
build per-file prototype headers.  But that's a different issue.

My 2c AUD.

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


From stephen.thorne at gmail.com  Tue May 23 03:18:59 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Tue, 23 May 2006 18:18:59 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060523041542.GI7001@us.netrek.org>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
	<3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
	<20060523041542.GI7001@us.netrek.org>
Message-ID: <3e8ca5c80605230118r24164383i3df92226539c26f1@mail.gmail.com>

On 5/23/06, James Cameron <quozl at us.netrek.org> wrote:
> What other reasons are there for reindenting?

The code is drifting between netrekxp and cow. I would really like
both codebases to converge again. With many style differences, it's
very hard to figure out what the actual changes are. By unifying style
we make those differences smaller.

> COW was indented after the fork that produced the current Netrek XP 2006
> code base.  I was just going through defs.h for both clients today and
> found COW had been tidied.  Some of that I'm tempted to restore to what
> it was.  So if the tidy and indent done by COW years ago has had any
> effect, it's to hinder a merge with Netrek XP.

NetrekXP has been tidied too.

> Potential future merge for Vanilla is to the Paradise code.

Mm, have these codebases diverged a large amount?

> I do see a need for adding prototypes.  I've successfully used cproto to
> build per-file prototype headers.  But that's a different issue.

Please commit these changes if they're workable.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From quozl at us.netrek.org  Tue May 23 04:08:48 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 19:08:48 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <3e8ca5c80605230118r24164383i3df92226539c26f1@mail.gmail.com>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
	<3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
	<20060523041542.GI7001@us.netrek.org>
	<3e8ca5c80605230118r24164383i3df92226539c26f1@mail.gmail.com>
Message-ID: <20060523090848.GA13484@us.netrek.org>

On Tue, May 23, 2006 at 06:18:59PM +1000, Stephen Thorne wrote:
> The code is drifting between netrekxp and cow. I would really like
> both codebases to converge again. With many style differences, it's
> very hard to figure out what the actual changes are. By unifying style
> we make those differences smaller.

Hrm, yes.  But then we make it more difficult for any other derived
client.  We shouldn't just think of the current projects.

> > Potential future merge for Vanilla is to the Paradise code.
> Mm, have these codebases diverged a large amount?

Don't know.  Perhaps Rado would know.

> > I do see a need for adding prototypes.  I've successfully used cproto to
> > build per-file prototype headers.  But that's a different issue.
> 
> Please commit these changes if they're workable.

These were committed to COW CVS yesterday.  They were only done to fix
compilation warnings in x11window.c.  Not a project-wide scope.

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


From xyzzy at speakeasy.org  Tue May 23 06:31:25 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 04:31:25 -0700 (PDT)
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <20060523090848.GA13484@us.netrek.org>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
	<3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
	<20060523041542.GI7001@us.netrek.org>
	<3e8ca5c80605230118r24164383i3df92226539c26f1@mail.gmail.com>
	<20060523090848.GA13484@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605230426540.24257@shell2.speakeasy.net>

On Tue, 23 May 2006, James Cameron wrote:
> > > Potential future merge for Vanilla is to the Paradise code.
> > Mm, have these codebases diverged a large amount?
>
> Don't know.  Perhaps Rado would know.

It is hugely different.  Vanilla has also copied lots of things from Paradise,
but done them differently.


From keyos at keyos.org  Tue May 23 06:46:44 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Tue, 23 May 2006 14:46:44 +0300 (IDT)
Subject: [netrek-dev] Patch + couple of things
Message-ID: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>

Hey,

Attached is patch to fix test for 'ranlib -c' that didn't
work on Solaris. Hopefully this one will work on any sh
interpreter.

Another thing that I would like to ask is about includes
that disappear from time to time from various .c files.

Today after getting fresh copy of repository and trying
to compile I found that tools/players.c is missing sys/socket.h
Not sure why this was removed (maybe it breaks something on
different systems).

As pretty fresh darcs user I also didn't find any good way
to find who created this regression. I had to zcat all files
under patches directory to actually find that Quozl is the man :)
Is there good way to get version diff (i.e. something like cvs diff -r 1.1 
filename) ?

Stas.
-------------- next part --------------

New patches:

[OSX ranlib test fix
keyos at keyos.org**20060523110427
 Test for ranlib was failing on Solaris. This is probably caused by different /bin/sh interpreters.
 Current fix should satisfy all of them
] {
hunk ./Vanilla/configure.in 485
-if $RANLIB -c 2>/dev/null; then
+(eval $RANLIB -c) 2>&5
+if test $? -ne 0; then
}

Context:

[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
78f75677ea0a3abecc4d03402da237a882217343

From xyzzy at speakeasy.org  Tue May 23 06:48:05 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 04:48:05 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
Message-ID: <Pine.LNX.4.58.0605230435460.24257@shell2.speakeasy.net>

Here is a pile of patches for the robot.  Most of have been discussed here
before, a few are new ones.  For some reason, darcs insisted that I include
the glib Makefile patch in this bundle.  Just ignore that one or kill the glib
patch I sent before and use this one instead.

The patches, from oldest to newest:

Rollback robotd-fixes1.dpatch, all these fixes will be re-done here, but differently

Mon May 22 15:40:42 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix mfprintf()
  When mfprintf() was changed from varargs to stdarg, it wasn't done
  correctly.  Fix this.

Tue May 23 00:45:25 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * adapt when assaulting
  The assault planet code didn't re-check the target planet after the
  assult started.  If the planet was taken by another player on a friendly
  team, or modified by god, the robot would still try to bomb/take it, even
  when that action was no longer possible.  The robot will now check for
  planets is can not drop on, and abort the assault if so.  It will not try
  to bomb planets it can not bomb.  It will also stop reinforcing planets
  when they get to 4 armies.

Tue May 23 00:49:46 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix neutral planet check
  Fix several bugs with check_take().  It didn't handle the case when no
  enemy planets were left.  It looked at the last enemy planet in the list,
  rather than the target enemy planet when deciding if it should take neut
  planets.  It would skip looking for neuts when it found an enemy agri and
  _didn't_ have enough armies to take it.

  Now it handles no enemy planets left.  It only skips looking for neut
  planets in preference of enemy planets if it has found an enemy agri and
  it _does_ have enough armies to take it.  In that case, the agri take
  will take precedence.

Tue May 23 00:55:48 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix closest_planet
  closest_planet() would usually return NULL every other time it was
  called.  For speed, it would check the previous closest planet first,
  then look for a _closer_ planet.  If it didn't find one, it returned
  NULL, rather than the previous (and current) closest planet (which
  it now returns).

Tue May 23 01:00:23 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix crash in RCD generation
  The code to generate the RCD message didn't handle the case when there
  were no visible friendly and/or enemy ships.  In this case,
  _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
  use me->p_no when no suitable other player is known.

Tue May 23 01:08:45 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix use of un-initialized variable
  Fix a warning about a un-initialized use of pldist in update_players().
  It didn't matter, but fix the warning anyway.

Tue May 23 01:54:09 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix calls to req_cloak_off()
  Some calls to req_cloak_off() were missing the function's argument
  (reason string).

Tue May 23 03:08:06 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix res danger
  The check for res danger would make the robot cloak when near _any_ home
  planet, so it would cloak even when bombing it's own core.  Unfortunately,
  it is not possible to tell from the planet flags whose home world a
  planet is.  Changed the code to only check the normal home planet
  indexes, skipping it's own HW, for proximity.  This makes the code much
  smaller and faster.  Realistically, the HWs are always at the standard
  indexes, even with non-standard planet layouts.  Included a bit of code,
  #if'ed out, that will find home worlds by name, the way the bot does when
  it wants to refit.

Tue May 23 04:09:21 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * torp dir for robot
  Hadley's bot expects to get torp direction from the server, but the
  server only sends it for your own torps.  Someone probably changed this
  years ago to combat borgs.  Changed back to send it for other
  torps too.  Without it, the bot thinks all torps are going straight up,
  making it a very bad dodger (unless you attack from below).

  This should be fixed to only turn this on for the robot, so as not to
  help borgs.  This will have to wait on a better way to detect robots.


From quozl at us.netrek.org  Tue May 23 00:12:39 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Tue, 23 May 2006 15:12:39 +1000
Subject: [netrek-dev] darcs patch: revised coding style and darcs discipline
Message-ID: <E1FiPCB-0007Pq-KX@dors.lan>

Tue May 23 15:09:27 EST 2006  quozl at us.netrek.org
  * revised coding style and darcs discipline
  Rewrite of the coding style and patch acceptance criteria based on 
  feedback on the mailing list from Stephen Thorne and Trent Piepho.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 14563 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060523/e7bef972/attachment-0001.bin 

From jimmyhua73 at yahoo.com  Tue May 23 08:05:30 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 06:05:30 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <Pine.LNX.4.58.0605230435460.24257@shell2.speakeasy.net>
Message-ID: <20060523130530.39525.qmail@web35308.mail.mud.yahoo.com>

Hi Trent, 

Glad you are finally on board darcs. 

I don't see the attachment here for the diffs or patch
file. Do you have a website or somesuch?

Jimmy

--- Trent Piepho <xyzzy at speakeasy.org> wrote:

> Here is a pile of patches for the robot.  Most of
> have been discussed here
> before, a few are new ones.  For some reason, darcs
> insisted that I include
> the glib Makefile patch in this bundle.  Just ignore
> that one or kill the glib
> patch I sent before and use this one instead.
> 
> The patches, from oldest to newest:
> 
> Rollback robotd-fixes1.dpatch, all these fixes will
> be re-done here, but differently
> 
> Mon May 22 15:40:42 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix mfprintf()
>   When mfprintf() was changed from varargs to
> stdarg, it wasn't done
>   correctly.  Fix this.
> 
> Tue May 23 00:45:25 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * adapt when assaulting
>   The assault planet code didn't re-check the target
> planet after the
>   assult started.  If the planet was taken by
> another player on a friendly
>   team, or modified by god, the robot would still
> try to bomb/take it, even
>   when that action was no longer possible.  The
> robot will now check for
>   planets is can not drop on, and abort the assault
> if so.  It will not try
>   to bomb planets it can not bomb.  It will also
> stop reinforcing planets
>   when they get to 4 armies.
> 
> Tue May 23 00:49:46 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix neutral planet check
>   Fix several bugs with check_take().  It didn't
> handle the case when no
>   enemy planets were left.  It looked at the last
> enemy planet in the list,
>   rather than the target enemy planet when deciding
> if it should take neut
>   planets.  It would skip looking for neuts when it
> found an enemy agri and
>   _didn't_ have enough armies to take it.
> 
>   Now it handles no enemy planets left.  It only
> skips looking for neut
>   planets in preference of enemy planets if it has
> found an enemy agri and
>   it _does_ have enough armies to take it.  In that
> case, the agri take
>   will take precedence.
> 
> Tue May 23 00:55:48 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix closest_planet
>   closest_planet() would usually return NULL every
> other time it was
>   called.  For speed, it would check the previous
> closest planet first,
>   then look for a _closer_ planet.  If it didn't
> find one, it returned
>   NULL, rather than the previous (and current)
> closest planet (which
>   it now returns).
> 
> Tue May 23 01:00:23 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix crash in RCD generation
>   The code to generate the RCD message didn't handle
> the case when there
>   were no visible friendly and/or enemy ships.  In
> this case,
>   _state.closest_{e,f} would be NULL.  Do what
> clients do in this case, and
>   use me->p_no when no suitable other player is
> known.
> 
> Tue May 23 01:08:45 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix use of un-initialized variable
>   Fix a warning about a un-initialized use of pldist
> in update_players().
>   It didn't matter, but fix the warning anyway.
> 
> Tue May 23 01:54:09 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix calls to req_cloak_off()
>   Some calls to req_cloak_off() were missing the
> function's argument
>   (reason string).
> 
> Tue May 23 03:08:06 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * fix res danger
>   The check for res danger would make the robot
> cloak when near _any_ home
>   planet, so it would cloak even when bombing it's
> own core.  Unfortunately,
>   it is not possible to tell from the planet flags
> whose home world a
>   planet is.  Changed the code to only check the
> normal home planet
>   indexes, skipping it's own HW, for proximity. 
> This makes the code much
>   smaller and faster.  Realistically, the HWs are
> always at the standard
>   indexes, even with non-standard planet layouts. 
> Included a bit of code,
>   #if'ed out, that will find home worlds by name,
> the way the bot does when
>   it wants to refit.
> 
> Tue May 23 04:09:21 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * torp dir for robot
>   Hadley's bot expects to get torp direction from
> the server, but the
>   server only sends it for your own torps.  Someone
> probably changed this
>   years ago to combat borgs.  Changed back to send
> it for other
>   torps too.  Without it, the bot thinks all torps
> are going straight up,
>   making it a very bad dodger (unless you attack
> from below).
> 
>   This should be fixed to only turn this on for the
> robot, so as not to
>   help borgs.  This will have to wait on a better
> way to detect robots.
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From jimmyhua73 at yahoo.com  Tue May 23 08:54:33 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 06:54:33 -0700 (PDT)
Subject: [netrek-dev] robotd _udcounter patch
Message-ID: <20060523135433.60147.qmail@web35314.mail.mud.yahoo.com>

Along the lines of debugging the robotd that Hadley
wrote. 

I found that on random occasions, the robots would
stop reporting where it wanted to take the armies it
was carrying. 

Usually, it stopped anywhere between 2 and 5 hours of
playing. 

I was thinking MEMORY HOLE. But then, one day, I ran
the bot for about 18 hours. Lo and behold! It started
to report where it wanted to take the armies to again!

Turns out the _udcounter was turning negative. It runs
on an 18 hour cycle. And depending on what time of day
you run the bot. You can count on it to work close to
18 hours, or only 1 hour!!! And then the cycle repeats
itself.

My initial fix was a bandaid that took into account
that _udcounter would flip over and count backwards...
-10 -9 -8 -7... At least for the carrying
announcement. 

Turns out that udcounter is used all over the place in
the robot code! The intent was udcounter is to start
from 0 and always count forwards based on 100ms of
time elapsed. 

I don't know if starting from 0 is a requirement...
But, I didn't take a chance on this one, and re-wrote
the function, so it does what it is supposed to do. 

tested code. And now udcounter has counted forwards
for close to 31 hours! 

Then robotd crashed! (SIGSEV on mprintf, not sure why,
but I did a backtrace and had I nice screen I was
going to send to everybody, but the power went out,
and I lost everything that was on my screen.). 


Jimmy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-udcounter.dpatch
Type: application/octet-stream
Size: 14908 bytes
Desc: 3714928906-robotd-udcounter.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060523/d26e8491/attachment-0001.obj 

From jimmyhua73 at yahoo.com  Tue May 23 09:44:37 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 07:44:37 -0700 (PDT)
Subject: [netrek-dev] newbie-fixes.dpatch
Message-ID: <20060523144437.76998.qmail@web35303.mail.mud.yahoo.com>

Okay, this is weird. 

darcs won't let me send the newbie fixes, unless I
also send the robotd-udcounter patch along with it. 

Probably because I changed the changelog twice!

Anyways, both patches are in here, even though it only
says newbie-fixes.dpatch. 

Also, only one file has changed, it's newbie.c 

I can also re-send without the changed changelog. 

Any guidance will be helpful. 

Jimmy

P.S. Hey James, here are the fixes you are waiting
for! 

Unfortunately, after fixing them I found another bug,
which is the t-mode setting for newbie.c is hardcoded
into 4 vs. 4.  

I think for now, I'll just change the INSTALL.newbie
file to make sure that the person running the newbie
server knows he needs a t-mode setting of 4 and not
anything else. 

Jimmy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie-fixes.dpatch
Type: application/octet-stream
Size: 20559 bytes
Desc: 781057739-newbie-fixes.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060523/e977eb5c/attachment-0001.obj 

From jimmyhua73 at yahoo.com  Tue May 23 10:05:29 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 08:05:29 -0700 (PDT)
Subject: [netrek-dev] updated INSTALL.Newbie
Message-ID: <20060523150529.95923.qmail@web35308.mail.mud.yahoo.com>

Here's the updated INSTALL.Newbie, as I just realized,
Merlin won't work properly unless TOURN=4. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie-install-docs-update.dpatch
Type: application/octet-stream
Size: 12814 bytes
Desc: 2967623636-newbie-install-docs-update.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060523/da03ff2b/attachment.obj 

From jimmyhua73 at yahoo.com  Tue May 23 10:20:37 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 08:20:37 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <Pine.LNX.4.58.0605230435460.24257@shell2.speakeasy.net>
Message-ID: <20060523152037.1659.qmail@web35314.mail.mud.yahoo.com>

> Tue May 23 04:09:21 PDT 2006  Trent Piepho
> <xyzzy at speakeasy.org>
>   * torp dir for robot
>   Hadley's bot expects to get torp direction from
> the server, but the
>   server only sends it for your own torps.  Someone
> probably changed this
>   years ago to combat borgs.  Changed back to send
> it for other
>   torps too.  Without it, the bot thinks all torps
> are going straight up,
>   making it a very bad dodger (unless you attack
> from below).

Whoa. I thought if Hadley's bot didn't get torp
direction information, it did try to deduce it. Did I
miss something in the code? 

Jimmy



From xyzzy at speakeasy.org  Tue May 23 06:25:32 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 04:25:32 -0700 (PDT)
Subject: [netrek-dev] darcs patch: fix lack of shields shown on practice
 robots and iggies
In-Reply-To: <E1FiOKn-00077M-BV@dors.lan>
References: <E1FiOKn-00077M-BV@dors.lan>
Message-ID: <Pine.LNX.4.58.0605230423150.24257@shell2.speakeasy.net>

On Tue, 23 May 2006 quozl at us.netrek.org wrote:
> Tue May 23 14:04:21 EST 2006  quozl at us.netrek.org
>   * fix lack of shields shown on practice robots and iggies
>   	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
>   	and hunter-killer, in conjunction with short packets version two,
>   	shields were not being sent.  Changed to send shields in SP_FLAGS.
>   	See also "S_P2 new flag sampling" in updateShips().  Reported by
>   	William Balcerski.

How about instead, change SP2 to send the flags of robots?  Wouldn't
that make more sense?  If you just wait a bit, I will send a patch that
fixes this.


From narcis at lukassen.homelinux.com  Sat May 20 15:50:24 2006
From: narcis at lukassen.homelinux.com (Chris en Judith)
Date: Sat, 20 May 2006 22:50:24 +0200
Subject: [netrek-dev] Connection to server protocol
In-Reply-To: <42902E01-94C8-47F8-9E14-F2E7E2C4A0A6@luky.nl>
References: <42902E01-94C8-47F8-9E14-F2E7E2C4A0A6@luky.nl>
Message-ID: <8BBF2E2C-CF40-404B-929E-F0FBD27E83F8@luky.nl>

Oh this may help too, salomo is running the client, and worrelsik is  
running the server

tcpdump: verbose output suppressed, use -v or -vv for full protocol  
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
22:48:33.755591 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: S  
3218268111:3218268111(0) win 65535 <mss 1460,nop,wscale  
0,nop,nop,timestamp 460745823 0>
         0x0000:  4500 003c bb89 4000 4006 fbd6 c0a8 0105   
E..<.. at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfcf 0000  
0000  .....;..........
         0x0020:  a002 ffff d4d8 0000 0204 05b4 0103  
0300  ................
         0x0030:  0101 080a 1b76 6c5f 0000 0000            .....vl_....
22:48:33.756549 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: S  
305951056:305951056(0) ack 3218268112 win 5792 <mss  
1460,nop,nop,timestamp 1164940136 460745823,nop,wscale 2>
         0x0000:  4500 003c 0000 4000 4006 b760 c0a8 0106   
E..<.. at .@..`....
         0x0010:  c0a8 0105 0a20 c13b 123c 7150 bfd2  
dfd0  .......;.<qP....
         0x0020:  a012 16a0 61c1 0000 0204 05b4 0101  
080a  ....a...........
         0x0030:  456f 9368 1b76 6c5f 0103 0302            Eo.h.vl_....
22:48:33.755775 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: .  
ack 1 win 65535 <nop,nop,timestamp 460745823 1164940136>
         0x0000:  4500 0034 bb8a 4000 4006 fbdd c0a8 0105  E.. 
4.. at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfd0 123c  
7151  .....;.......<qQ
         0x0020:  8010 ffff a427 0000 0101 080a 1b76  
6c5f  .....'.......vl_
         0x0030:  456f 9368                                Eo.h
active++: 1: pid 31844 port 2592
22:48:34.003112 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: P  
1:9(8) ack 1 win 65535 <nop,nop,timestamp 460745823 1164940136>
         0x0000:  4500 003c bb8d 4000 4006 fbd2 c0a8 0105   
E..<.. at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfd0 123c  
7151  .....;.......<qQ
         0x0020:  8018 ffff 0d52 0000 0101 080a 1b76  
6c5f  .....R.......vl_
         0x0030:  456f 9368 1b04 0a00 3728 3a99            Eo.h....7(:.
22:48:34.003163 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: .  
ack 9 win 1448 <nop,nop,timestamp 1164940198 460745823>
         0x0000:  4500 0034 e239 4000 4006 d52e c0a8 0106  E.. 
4.9 at .@.......
         0x0010:  c0a8 0105 0a20 c13b 123c 7151 bfd2  
dfd8  .......;.<qQ....
         0x0020:  8010 05a8 9e39 0000 0101 080a 456f 93a6  ..... 
9......Eo..
         0x0030:  1b76 6c5f                                .vl_
22:48:34.003810 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: P  
9:97(88) ack 1 win 65535 <nop,nop,timestamp 460745823 1164940198>
         0x0000:  4500 008c bb8e 4000 4006 fb81 c0a8 0105   
E..... at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfd8 123c  
7151  .....;.......<qQ
         0x0020:  8018 ffff 1901 0000 0101 080a 1b76  
6c5f  .............vl_
         0x0030:  456f 93a6 3c53 0000 0000 0001 4645 4154   
Eo..<S......FEAT
         0x0040:  5552 455f 5041 434b 4554 5300 0000 0000   
URE_PACKETS.....
         0x0050:  0000                                     ..
22:48:34.003858 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: .  
ack 97 win 1448 <nop,nop,timestamp 1164940198 460745823>
         0x0000:  4500 0034 e23b 4000 4006 d52c c0a8 0106  E.. 
4.;@. at ..,....
         0x0010:  c0a8 0105 0a20 c13b 123c 7151 bfd2  
e030  .......;.<qQ...0
         0x0020:  8010 05a8 9de1 0000 0101 080a 456f  
93a6  ............Eo..
         0x0030:  1b76 6c5f                                .vl_
22:48:34.004194 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: .  
1:1449(1448) ack 97 win 1448 <nop,nop,timestamp 1164940199 460745823>
         0x0000:  4500 05dc e23d 4000 4006 cf82 c0a8 0106   
E....=@. at .......
         0x0010:  c0a8 0105 0a20 c13b 123c 7151 bfd2  
e030  .......;.<qQ...0
         0x0020:  8010 05a8 4345 0000 0101 080a 456f  
93a7  ....CE......Eo..
         0x0030:  1b76 6c5f 0b00 0000 5765 6c63 6f6d  
6520  .vl_....Welcome.
         0x0040:  746f 2056 616e 696c 6c61 2073 6572 7665   
to.Vanilla.serve
         0x0050:  7220                                     r.
22:48:34.004213 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: .  
1449:2897(1448) ack 97 win 1448 <nop,nop,timestamp 1164940199 460745823>
         0x0000:  4500 05dc e23f 4000 4006 cf80 c0a8 0106  E....? 
@. at .......
         0x0010:  c0a8 0105 0a20 c13b 123c 76f9 bfd2  
e030  .......;.<v....0
         0x0020:  8010 05a8 a278 0000 0101 080a 456f  
93a7  .....x......Eo..
         0x0030:  1b76 6c5f 6f67 2020 2020 2020 2020  
2020  .vl_og..........
         0x0040:  2020 3a20 5965 7300 626c 6564 0000  
006f  ..:.Yes.bled...o
         0x0050:  0000                                     ..
22:48:34.004817 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: .  
ack 2897 win 65160 <nop,nop,timestamp 460745823 1164940199>
         0x0000:  4500 0034 bb8f 4000 4006 fbd8 c0a8 0105  E.. 
4.. at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 e030 123c 7ca1  .....;..... 
0.<|.
         0x0020:  8010 fe88 99af 0000 0101 080a 1b76  
6c5f  .............vl_
         0x0030:  456f 93a7                                Eo..
22:48:34.004853 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: .  
2897:4345(1448) ack 97 win 1448 <nop,nop,timestamp 1164940199 460745823>
         0x0000:  4500 05dc e241 4000 4006 cf7e c0a8 0106   
E....A at .@..~....
         0x0010:  c0a8 0105 0a20 c13b 123c 7ca1 bfd2  
e030  .......;.<|....0
         0x0020:  8010 05a8 de3e 0000 0101 080a 456f  
93a7  .....>......Eo..
         0x0030:  1b76 6c5f 0000 0000 180d 0000 0000  
0000  .vl_............
         0x0040:  0000 0000 0000 0000 0000 0000 0000  
0000  ................
         0x0050:  0000                                     ..
22:48:34.004865 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: P  
4345:5769(1424) ack 97 win 1448 <nop,nop,timestamp 1164940199 460745823>
         0x0000:  4500 05c4 e243 4000 4006 cf94 c0a8 0106   
E....C at .@.......
         0x0010:  c0a8 0105 0a20 c13b 123c 8249 bfd2  
e030  .......;.<.I...0
         0x0020:  8018 05a8 b0e1 0000 0101 080a 456f  
93a7  ............Eo..
         0x0030:  1b76 6c5f 0000 0000 141c 0000 121c  
0000  .vl_............
         0x0040:  0000 0000 041c 0000 0000 0000 0000  
0000  ................
         0x0050:  181d                                     ..
22:48:34.071085 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: F  
97:97(0) ack 5769 win 65535 <nop,nop,timestamp 460745823 1164940199>
         0x0000:  4500 0034 bb93 4000 4006 fbd4 c0a8 0105  E.. 
4.. at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 e030 123c 87d9  .....;..... 
0.<..
         0x0020:  8011 ffff 8cff 0000 0101 080a 1b76  
6c5f  .............vl_
         0x0030:  456f 93a7                                Eo..
22:48:34.071476 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: F  
5769:5769(0) ack 98 win 1448 <nop,nop,timestamp 1164940215 460745823>
         0x0000:  4500 0034 e245 4000 4006 d522 c0a8 0106  E.. 
4.E at .@.."....
         0x0010:  c0a8 0105 0a20 c13b 123c 87d9 bfd2  
e031  .......;.<.....1
         0x0020:  8011 05a8 8746 0000 0101 080a 456f  
93b7  .....F......Eo..
         0x0030:  1b76 6c5f                                .vl_
active--: 0: pid 31844 terminated
22:48:34.276188 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467: F  
5769:5769(0) ack 98 win 1448 <nop,nop,timestamp 1164940267 460745823>
         0x0000:  4500 0034 e247 4000 4006 d520 c0a8 0106  E.. 
4.G at .@.......
         0x0010:  c0a8 0105 0a20 c13b 123c 87d9 bfd2  
e031  .......;.<.....1
         0x0020:  8011 05a8 8712 0000 0101 080a 456f  
93eb  ............Eo..
         0x0030:  1b76 6c5f                                .vl_
22:48:34.276517 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek: .  
ack 5770 win 65535 <nop,nop,timestamp 460745824 1164940267>
         0x0000:  4500 0034 bb95 4000 4006 fbd2 c0a8 0105  E.. 
4.. at .@.......
         0x0010:  c0a8 0106 c13b 0a20 bfd2 e031 123c 87da  .....;..... 
1.<..
         0x0020:  8010 ffff 8cb9 0000 0101 080a 1b76  
6c60  .............vl`
         0x0030:  456f 93eb                                Eo..
        salomo.luky.nl                   Sat May 20 22:48:33 2006

On 20 May 2006, at 22:44, Chris en Judith wrote:

> Hi
>
> i'm developing a new client based on Objective-C/Cocoa but have  
> difficulties figuring out the protocol required to establish a  
> connection to the server. So far i can connect to the server and  
> exchange some data but after the MOTD i get lost. Here's a  
> transcript of what i am trying:
>
> 2006-05-20 22:33:24.370 MacTrek[4128] SetupWindowController  
> awakeFromNib
> 2006-05-20 22:33:24.748 MacTrek[4128] SetupWindowController  
> raiseSetupWindow
> (gdb) continue
> 2006-05-20 22:33:32.469 MacTrek[4128]  
> ClientController.startClientAt: netrek.luky.nl port 2592
> 2006-05-20 22:33:32.473 MacTrek[4128] Communication.callServer:  
> netrek.luky.nl at 2592
> 2006-05-20 22:33:32.474 MacTrek[4128] Communication.callServer: got  
> connection parameters
> Current language:  auto; currently objective-c
> Pending breakpoint 1 - ""ServerReader.m:166" resolved
> 2006-05-20 22:33:32.869 MacTrek[4128] ServerSenderTcp.sendBuffer  
> message: CP_SOCKET (27) size: 8
> 2006-05-20 22:33:32.870 MacTrek[4128]  
> LLNotificationCenter.postNotificationName COMM_PICK_SOCKET_SENT
> 2006-05-20 22:33:32.870 MacTrek[4128] ServerSenderTcp.sendBuffer  
> message: CP_FEATURE (60) size: 88
> (gdb) continue
> 2006-05-20 22:33:38.945 MacTrek[4128] ServerReader.readFromServer  
> received message: SP_MOTD (11), count: 1536
> 2006-05-20 22:33:38.994 MacTrek[4128] ServerReader.handlePacket:  
> SP_MOTD: Welcome to Vanilla server version 2.10, patchlevel 2
> 2006-05-20 22:33:39.020 MacTrek[4128]  
> LLNotificationCenter.postNotificationName SP_MOTD
> 2006-05-20 22:33:39.020 MacTrek[4128] ServerReader.readFromServer  
> received message: SP_MOTD_PIC (32), count: 1452
> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.handlePacket:  
> SP_MOTD_PIC not implemented
> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.readFromServer  
> received message: UNKNOWN (0), count: 1440
> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.readFromServer:  
> Unknown packet type. Flushing packet buffer & input stream.
> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.readFromServer:  
> Last packet type: 0
>
> roughly the server responds to my CP_SOCKET and CP_FEATURE message  
> with a SP_MOTD and a SP_MOTD_PIC the remainder of the buffer is  
> filled with a 0 and gets flushed. (i might accidently have read an  
> entire frame 1536 in stead of what was really in the buffer but  
> what the hack.
>
>  i was expecting a message SP_S_PLAYER to set which slot i'd been  
> allocated but i might be fully off here.
>
> What is going wrong and what should i have done ?
>
> regards
>
> Chris



From narcis at lukassen.homelinux.com  Sat May 20 16:00:12 2006
From: narcis at lukassen.homelinux.com (Chris en Judith)
Date: Sat, 20 May 2006 23:00:12 +0200
Subject: [netrek-dev] Connection to server protocol
In-Reply-To: <8BBF2E2C-CF40-404B-929E-F0FBD27E83F8@luky.nl>
References: <42902E01-94C8-47F8-9E14-F2E7E2C4A0A6@luky.nl>
	<8BBF2E2C-CF40-404B-929E-F0FBD27E83F8@luky.nl>
Message-ID: <F1CC6865-6F3B-4101-9455-6E92528872C2@luky.nl>


Pesky mail server :-( this should come through now (attempt 3)


On 20 May 2006, at 22:50, Chris en Judith wrote:

> Oh this may help too, salomo is running the client, and worrelsik  
> is running the server
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol  
> decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 22:48:33.755591 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek:  
> S 3218268111:3218268111(0) win 65535 <mss 1460,nop,wscale  
> 0,nop,nop,timestamp 460745823 0>
>         0x0000:  4500 003c bb89 4000 4006 fbd6 c0a8 0105   
> E..<.. at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfcf 0000  
> 0000  .....;..........
>         0x0020:  a002 ffff d4d8 0000 0204 05b4 0103  
> 0300  ................
>         0x0030:  0101 080a 1b76 6c5f 0000 0000            .....vl_....
> 22:48:33.756549 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467:  
> S 305951056:305951056(0) ack 3218268112 win 5792 <mss  
> 1460,nop,nop,timestamp 1164940136 460745823,nop,wscale 2>
>         0x0000:  4500 003c 0000 4000 4006 b760 c0a8 0106   
> E..<.. at .@..`....
>         0x0010:  c0a8 0105 0a20 c13b 123c 7150 bfd2  
> dfd0  .......;.<qP....
>         0x0020:  a012 16a0 61c1 0000 0204 05b4 0101  
> 080a  ....a...........
>         0x0030:  456f 9368 1b76 6c5f 0103 0302            Eo.h.vl_....
> 22:48:33.755775 IP salomo.luky.nl.49467 >  
> worrelsik.luky.nl.netrek: . ack 1 win 65535 <nop,nop,timestamp  
> 460745823 1164940136>
>         0x0000:  4500 0034 bb8a 4000 4006 fbdd c0a8 0105  E.. 
> 4.. at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfd0 123c  
> 7151  .....;.......<qQ
>         0x0020:  8010 ffff a427 0000 0101 080a 1b76  
> 6c5f  .....'.......vl_
>         0x0030:  456f 9368                                Eo.h
> active++: 1: pid 31844 port 2592
> 22:48:34.003112 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek:  
> P 1:9(8) ack 1 win 65535 <nop,nop,timestamp 460745823 1164940136>
>         0x0000:  4500 003c bb8d 4000 4006 fbd2 c0a8 0105   
> E..<.. at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfd0 123c  
> 7151  .....;.......<qQ
>         0x0020:  8018 ffff 0d52 0000 0101 080a 1b76  
> 6c5f  .....R.......vl_
>         0x0030:  456f 9368 1b04 0a00 3728 3a99            Eo.h....7(:.
> 22:48:34.003163 IP worrelsik.luky.nl.netrek > salomo.luky.nl. 
> 49467: . ack 9 win 1448 <nop,nop,timestamp 1164940198 460745823>
>         0x0000:  4500 0034 e239 4000 4006 d52e c0a8 0106  E.. 
> 4.9 at .@.......
>         0x0010:  c0a8 0105 0a20 c13b 123c 7151 bfd2  
> dfd8  .......;.<qQ....
>         0x0020:  8010 05a8 9e39 0000 0101 080a 456f 93a6  ..... 
> 9......Eo..
>         0x0030:  1b76 6c5f                                .vl_
> 22:48:34.003810 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek:  
> P 9:97(88) ack 1 win 65535 <nop,nop,timestamp 460745823 1164940198>
>         0x0000:  4500 008c bb8e 4000 4006 fb81 c0a8 0105   
> E..... at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 dfd8 123c  
> 7151  .....;.......<qQ
>         0x0020:  8018 ffff 1901 0000 0101 080a 1b76  
> 6c5f  .............vl_
>         0x0030:  456f 93a6 3c53 0000 0000 0001 4645 4154   
> Eo..<S......FEAT
>         0x0040:  5552 455f 5041 434b 4554 5300 0000 0000   
> URE_PACKETS.....
>         0x0050:  0000                                     ..
> 22:48:34.003858 IP worrelsik.luky.nl.netrek > salomo.luky.nl. 
> 49467: . ack 97 win 1448 <nop,nop,timestamp 1164940198 460745823>
>         0x0000:  4500 0034 e23b 4000 4006 d52c c0a8 0106  E.. 
> 4.;@. at ..,....
>         0x0010:  c0a8 0105 0a20 c13b 123c 7151 bfd2  
> e030  .......;.<qQ...0
>         0x0020:  8010 05a8 9de1 0000 0101 080a 456f  
> 93a6  ............Eo..
>         0x0030:  1b76 6c5f                                .vl_
> 22:48:34.004194 IP worrelsik.luky.nl.netrek > salomo.luky.nl. 
> 49467: . 1:1449(1448) ack 97 win 1448 <nop,nop,timestamp 1164940199  
> 460745823>
>         0x0000:  4500 05dc e23d 4000 4006 cf82 c0a8 0106   
> E....=@. at .......
>         0x0010:  c0a8 0105 0a20 c13b 123c 7151 bfd2  
> e030  .......;.<qQ...0
>         0x0020:  8010 05a8 4345 0000 0101 080a 456f  
> 93a7  ....CE......Eo..
>         0x0030:  1b76 6c5f 0b00 0000 5765 6c63 6f6d  
> 6520  .vl_....Welcome.
>         0x0040:  746f 2056 616e 696c 6c61 2073 6572 7665   
> to.Vanilla.serve
>         0x0050:  7220                                     r.
> 22:48:34.004213 IP worrelsik.luky.nl.netrek > salomo.luky.nl. 
> 49467: . 1449:2897(1448) ack 97 win 1448 <nop,nop,timestamp  
> 1164940199 460745823>
>         0x0000:  4500 05dc e23f 4000 4006 cf80 c0a8 0106  E....? 
> @. at .......
>         0x0010:  c0a8 0105 0a20 c13b 123c 76f9 bfd2  
> e030  .......;.<v....0
>         0x0020:  8010 05a8 a278 0000 0101 080a 456f  
> 93a7  .....x......Eo..
>         0x0030:  1b76 6c5f 6f67 2020 2020 2020 2020  
> 2020  .vl_og..........
>         0x0040:  2020 3a20 5965 7300 626c 6564 0000  
> 006f  ..:.Yes.bled...o
>         0x0050:  0000                                     ..
> 22:48:34.004817 IP salomo.luky.nl.49467 >  
> worrelsik.luky.nl.netrek: . ack 2897 win 65160 <nop,nop,timestamp  
> 460745823 1164940199>
>         0x0000:  4500 0034 bb8f 4000 4006 fbd8 c0a8 0105  E.. 
> 4.. at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 e030 123c  
> 7ca1  .....;.....0.<|.
>         0x0020:  8010 fe88 99af 0000 0101 080a 1b76  
> 6c5f  .............vl_
>         0x0030:  456f 93a7                                Eo..
> 22:48:34.004853 IP worrelsik.luky.nl.netrek > salomo.luky.nl. 
> 49467: . 2897:4345(1448) ack 97 win 1448 <nop,nop,timestamp  
> 1164940199 460745823>
>         0x0000:  4500 05dc e241 4000 4006 cf7e c0a8 0106   
> E....A at .@..~....
>         0x0010:  c0a8 0105 0a20 c13b 123c 7ca1 bfd2  
> e030  .......;.<|....0
>         0x0020:  8010 05a8 de3e 0000 0101 080a 456f  
> 93a7  .....>......Eo..
>         0x0030:  1b76 6c5f 0000 0000 180d 0000 0000  
> 0000  .vl_............
>         0x0040:  0000 0000 0000 0000 0000 0000 0000  
> 0000  ................
>         0x0050:  0000                                     ..
> 22:48:34.004865 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467:  
> P 4345:5769(1424) ack 97 win 1448 <nop,nop,timestamp 1164940199  
> 460745823>
>         0x0000:  4500 05c4 e243 4000 4006 cf94 c0a8 0106   
> E....C at .@.......
>         0x0010:  c0a8 0105 0a20 c13b 123c 8249 bfd2  
> e030  .......;.<.I...0
>         0x0020:  8018 05a8 b0e1 0000 0101 080a 456f  
> 93a7  ............Eo..
>         0x0030:  1b76 6c5f 0000 0000 141c 0000 121c  
> 0000  .vl_............
>         0x0040:  0000 0000 041c 0000 0000 0000 0000  
> 0000  ................
>         0x0050:  181d                                     ..
> 22:48:34.071085 IP salomo.luky.nl.49467 > worrelsik.luky.nl.netrek:  
> F 97:97(0) ack 5769 win 65535 <nop,nop,timestamp 460745823 1164940199>
>         0x0000:  4500 0034 bb93 4000 4006 fbd4 c0a8 0105  E.. 
> 4.. at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 e030 123c  
> 87d9  .....;.....0.<..
>         0x0020:  8011 ffff 8cff 0000 0101 080a 1b76  
> 6c5f  .............vl_
>         0x0030:  456f 93a7                                Eo..
> 22:48:34.071476 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467:  
> F 5769:5769(0) ack 98 win 1448 <nop,nop,timestamp 1164940215  
> 460745823>
>         0x0000:  4500 0034 e245 4000 4006 d522 c0a8 0106  E.. 
> 4.E at .@.."....
>         0x0010:  c0a8 0105 0a20 c13b 123c 87d9 bfd2  
> e031  .......;.<.....1
>         0x0020:  8011 05a8 8746 0000 0101 080a 456f  
> 93b7  .....F......Eo..
>         0x0030:  1b76 6c5f                                .vl_
> active--: 0: pid 31844 terminated
> 22:48:34.276188 IP worrelsik.luky.nl.netrek > salomo.luky.nl.49467:  
> F 5769:5769(0) ack 98 win 1448 <nop,nop,timestamp 1164940267  
> 460745823>
>         0x0000:  4500 0034 e247 4000 4006 d520 c0a8 0106  E.. 
> 4.G at .@.......
>         0x0010:  c0a8 0105 0a20 c13b 123c 87d9 bfd2  
> e031  .......;.<.....1
>         0x0020:  8011 05a8 8712 0000 0101 080a 456f  
> 93eb  ............Eo..
>         0x0030:  1b76 6c5f                                .vl_
> 22:48:34.276517 IP salomo.luky.nl.49467 >  
> worrelsik.luky.nl.netrek: . ack 5770 win 65535 <nop,nop,timestamp  
> 460745824 1164940267>
>         0x0000:  4500 0034 bb95 4000 4006 fbd2 c0a8 0105  E.. 
> 4.. at .@.......
>         0x0010:  c0a8 0106 c13b 0a20 bfd2 e031 123c  
> 87da  .....;.....1.<..
>         0x0020:  8010 ffff 8cb9 0000 0101 080a 1b76  
> 6c60  .............vl`
>         0x0030:  456f 93eb                                Eo..
>        salomo.luky.nl                   Sat May 20 22:48:33 2006
>
> On 20 May 2006, at 22:44, Chris en Judith wrote:
>
>> Hi
>>
>> i'm developing a new client based on Objective-C/Cocoa but have  
>> difficulties figuring out the protocol required to establish a  
>> connection to the server. So far i can connect to the server and  
>> exchange some data but after the MOTD i get lost. Here's a  
>> transcript of what i am trying:
>>
>> 2006-05-20 22:33:24.370 MacTrek[4128] SetupWindowController  
>> awakeFromNib
>> 2006-05-20 22:33:24.748 MacTrek[4128] SetupWindowController  
>> raiseSetupWindow
>> (gdb) continue
>> 2006-05-20 22:33:32.469 MacTrek[4128]  
>> ClientController.startClientAt: netrek.luky.nl port 2592
>> 2006-05-20 22:33:32.473 MacTrek[4128] Communication.callServer:  
>> netrek.luky.nl at 2592
>> 2006-05-20 22:33:32.474 MacTrek[4128] Communication.callServer:  
>> got connection parameters
>> Current language:  auto; currently objective-c
>> Pending breakpoint 1 - ""ServerReader.m:166" resolved
>> 2006-05-20 22:33:32.869 MacTrek[4128] ServerSenderTcp.sendBuffer  
>> message: CP_SOCKET (27) size: 8
>> 2006-05-20 22:33:32.870 MacTrek[4128]  
>> LLNotificationCenter.postNotificationName COMM_PICK_SOCKET_SENT
>> 2006-05-20 22:33:32.870 MacTrek[4128] ServerSenderTcp.sendBuffer  
>> message: CP_FEATURE (60) size: 88
>> (gdb) continue
>> 2006-05-20 22:33:38.945 MacTrek[4128] ServerReader.readFromServer  
>> received message: SP_MOTD (11), count: 1536
>> 2006-05-20 22:33:38.994 MacTrek[4128] ServerReader.handlePacket:  
>> SP_MOTD: Welcome to Vanilla server version 2.10, patchlevel 2
>> 2006-05-20 22:33:39.020 MacTrek[4128]  
>> LLNotificationCenter.postNotificationName SP_MOTD
>> 2006-05-20 22:33:39.020 MacTrek[4128] ServerReader.readFromServer  
>> received message: SP_MOTD_PIC (32), count: 1452
>> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.handlePacket:  
>> SP_MOTD_PIC not implemented
>> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.readFromServer  
>> received message: UNKNOWN (0), count: 1440
>> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.readFromServer:  
>> Unknown packet type. Flushing packet buffer & input stream.
>> 2006-05-20 22:33:39.021 MacTrek[4128] ServerReader.readFromServer:  
>> Last packet type: 0
>>
>> roughly the server responds to my CP_SOCKET and CP_FEATURE message  
>> with a SP_MOTD and a SP_MOTD_PIC the remainder of the buffer is  
>> filled with a 0 and gets flushed. (i might accidently have read an  
>> entire frame 1536 in stead of what was really in the buffer but  
>> what the hack.
>>
>>  i was expecting a message SP_S_PLAYER to set which slot i'd been  
>> allocated but i might be fully off here.
>>
>> What is going wrong and what should i have done ?
>>
>> regards
>>
>> Chris
>



From narcis at lukassen.homelinux.com  Tue May 23 06:44:50 2006
From: narcis at lukassen.homelinux.com (Chris en Judith)
Date: Tue, 23 May 2006 13:44:50 +0200
Subject: [netrek-dev] Number of players on Vanilla Server
Message-ID: <C4FF3523-4586-4033-998B-DA090189FBA3@luky.nl>

Hi,

i'm writing an ObjC client for netrek but notice that the server is  
sending more than 16 players, in fact i've seen player 31 come by!  
it's running out of my arrays but that is not the main problem,

Why is it sending so many? i would think 16 is enough

regards

Chris


From xyzzy at speakeasy.org  Tue May 23 07:06:53 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 05:06:53 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <Pine.LNX.4.58.0605230435460.24257@shell2.speakeasy.net>
References: <Pine.LNX.4.58.0605230435460.24257@shell2.speakeasy.net>
Message-ID: <Pine.LNX.4.58.0605230506030.24257@shell2.speakeasy.net>

On Tue, 23 May 2006, Trent Piepho wrote:
> Here is a pile of patches for the robot.  Most of have been discussed here

Ok, the actual patch this time.
-------------- next part --------------

New patches:

[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Mon May 22 14:31:58 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* Makefile.in  Remove calls to glib-config, they aren't needed
+	and fail if glib-config isn't present.
+
 Mon May 22 14:03:38 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* res-rsa/configure.in  The check for gmp fails for gmp version 3,
 	fix it by adding a secondary check for the gmp3 symbol names.
hunk ./Vanilla/ntserv/Makefile.in 85
 all: $(PMAKE) ntserv daemonII 
 
 ntserv: $(PMAKE) $(R_OBJS)
-	$(CC) $(CFLAGS) ${LDFLAGS} -o ntserv $(R_OBJS) $(LIBS) $(LIBCRYPT) `glib-config --libs` -lgdbm
+	$(CC) $(CFLAGS) ${LDFLAGS} -o ntserv $(R_OBJS) $(LIBS) $(LIBCRYPT) -lgdbm
 
 daemonII: $(PMAKE) $(D_OBJS)
 	$(CC) $(CFLAGS) ${LDFLAGS} -o daemonII $(D_OBJS) $(EXTRALIBS)
hunk ./Vanilla/ntserv/Makefile.in 101
 	$(CC) $(CFLAGS) $(DEP) -c ${srcdir}/commands.c
 
 db.o: $(PMAKE) db.c
-	$(CC) $(CFLAGS) $(DEP) `glib-config --cflags` -c db.c
+	$(CC) $(CFLAGS) $(DEP) -c db.c
 
 cflags:
 	echo "static char cflags[]=\"$(CFLAGS) $(LIBS)\";" >../cflags.h
}
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
<
> {
hunk ./Vanilla/robotd/util.c 445
 }
 #endif
 
-/* This function causes a SIGSEV, dunno why JKH */
-/* replacing it with a straight fprintf which */
-/* accomplishes the same thing */
+
 mfprintf(char *format, ...)
 {
    FILE	*fo;
hunk ./Vanilla/robotd/update_players.c 1356
 
 {
    register			k;
-   register struct planet	*pl, *rp = opl; /* zxxy */
+   register struct planet	*pl, *rp = NULL;
    register			d, mdist = INT_MAX;
 
    if(opl && (mdist = ihypot((double)(j->p_x - opl->pl_x), 
hunk ./Vanilla/robotd/update_players.c 1097
       return;
    }
    if(/* from < 0 ||*/ from >= MAXPLAYER){
-     /* mfprintf(stderr, "process_general_message: unknown player %d\n", from); */
-     fprintf(stderr, "process_general_message: unknown player %d\n", from); 
+      mfprintf(stderr, "process_general_message: unknown player %d\n", from);
       return;
    }
    p = &_state.players[from];
hunk ./Vanilla/robotd/update_players.c 282
       if(_state.player_type == PT_OGGER || _state.player_type == PT_DOGFIGHTER){
 	 timer ++;
 	 if(timer == 100){
-	   /* mfprintf(stderr, "nobody to fight\n"); */
-	    fprintf(stderr, "nobody to fight\n");
+	    mfprintf(stderr, "nobody to fight\n");
 	    exitRobot(0);
 	 }
       }
hunk ./Vanilla/robotd/update_players.c 145
 	 army_check1(p, j);
 	 army_check2(p, j);
       }
-
-      if(p->invisible) {
-	  p->closest_pl = NULL;
-      } else {
-	  p->closest_pl = closest_planet(j, &pldist, p->closest_pl);
-	  p->closest_pl_dist = pldist;
-      }
+      if(p->invisible)
+	 p->closest_pl = NULL;
+      else
+	 p->closest_pl = closest_planet(j, &pldist, p->closest_pl);
+      p->closest_pl_dist = pldist;
 
       if(j->p_flags & PFBOMB)
 	 p->bombing = _udcounter;
hunk ./Vanilla/robotd/socket.c 2412
     int attempts;
 
     if (udpSock >= 0) {
-      /* mfprintf(stderr, "netrek: tried to open udpSock twice\n"); */
-        fprintf(stderr, "netrek: tried to open udpSock twice\n");
+        mfprintf(stderr, "netrek: tried to open udpSock twice\n");
         return (0);     /* pretend we succeeded (this could be bad) */
     }
 
hunk ./Vanilla/robotd/socket.c 2395
         UDPDIAG(("Received UDP verification\n"));
         break;
     default:
-      /* mfprintf(stderr, "netrek: Got funny reply (%d) in UDP_REPLY packet\n",
-	 packet->reply); */
-        fprintf(stderr, "netrek: Got funny reply (%d) in UDP_REPLY packet\n",
+        mfprintf(stderr, "netrek: Got funny reply (%d) in UDP_REPLY packet\n",
                 packet->reply);
 
         break;
hunk ./Vanilla/robotd/socket.c 1921
         if (n < 0){
 #ifdef ATM
             if (fd == udpSock) {
-	        /* mfprintf(stderr, "Tried to write %d, 0x%x, %d (error %d)\n",
-		 fd, buf, bytes, errno); */
-                fprintf(stderr, "Tried to write %d, 0x%x, %d (error %d)\n",
+                mfprintf(stderr, "Tried to write %d, 0x%x, %d (error %d)\n",
                     fd, buf, bytes, errno);
 	        perror("write");
                 printUdpInfo();
hunk ./Vanilla/robotd/shmem.c 178
    int			tv = mtime(0), htv;
 
    if(!(j->p_flags & PFCLOAK)){
-      /* mfprintf(stderr, "shmem_cloakd: player not cloaked\n"); */
-      fprintf(stderr, "shmem_cloakd: player not cloaked\n");
+      mfprintf(stderr, "shmem_cloakd: player not cloaked\n");
       return 0;
    }
    /* assign my idea of location */
hunk ./Vanilla/robotd/main.c 433
 	 if(team != _state.team && team != -1){
 	    timer2 = 0;
 	    _state.team = team;
-	    if (!teamRequest(team, s_type)){
-              /* mfprintf(stderr, "team or ship rejected.\n"); */
-	      fprintf(stderr, "team or ship rejected.\n");
-	      showteams();
+	    if(!teamRequest(team, s_type)){
+	       mfprintf(stderr, "team or ship rejected.\n");
+	       showteams();
 	    }
 	    else 
 	       break;
hunk ./Vanilla/robotd/decide.c 713
 	     if(pl->pl_mydist < 20000 && pl_defended(pl,3)) continue;
 	   */
 
-	   if(pl->pl_mydist < min_dist){
-	       tpl = pl;
-	       min_dist = pl->pl_mydist;
-	   }
-       }
+	 if(pl->pl_mydist < min_dist){
+	    tpl = pl;
+	    min_dist = pl->pl_mydist;
+	 }
+      }
    }
    if(tpl){
       if(pls->total_textra_armies + me->p_armies < tpl->pl_armies)
hunk ./Vanilla/robotd/decide.c 702
       }
    }
 
-   /* take indep planet first over regular planets */
-   /* but take agris first if you have the armies */
-   if (!tpl || !(tpl->pl_flags&PLAGRI && me->p_armies >= 5) ) {
-       min_dist = GWIDTH;	/* ind overrides non-ind */
-       for(k=0; k< pls->num_indsp; k++){
-	   pl = pls->ind_planets[k];
-	   
-	   /*
-	     if(pl->pl_mydist < 20000 && pl_defended(pl,3)) continue;
-	   */
+	 /*
+	 if(pl->pl_mydist < 20000 && pl_defended(pl,3)) continue;
+	 */
 
 	 if(pl->pl_mydist < min_dist){
 	    tpl = pl;
hunk ./Vanilla/robotd/decide.c 701
 	 min_dist = pl->pl_mydist;
       }
    }
+   if(!(pl->pl_flags & PLAGRI) || me->p_armies >= 5){
+      min_dist = GWIDTH;	/* ind overrides non-ind */
+      for(k=0; k< pls->num_indsp; k++){
+	 pl = pls->ind_planets[k];
 
 	 /*
 	 if(pl->pl_mydist < 20000 && pl_defended(pl,3)) continue;
hunk ./Vanilla/robotd/decide.c 686
 
    if(pls->total_textra_armies == 0 && me->p_armies == 0) return 0;
 
-   /* find a planet to take */
    for(k=0; k< pls->num_warteamsp; k++){
       pl = pls->warteam_planets[k];
 
hunk ./Vanilla/robotd/decide.c 173
 
 decide_take()
 {
-   PlanetRec	 *pls = _state.planets;
+   PlanetRec		*pls = _state.planets;
    struct planet *tpl = _state.assault_planet;
    struct planet *cpl = me_p->closest_pl;
 
hunk ./Vanilla/robotd/assault.c 198
    else
       req_cloak_off("no cloak in assault_planet()");
 
-   /* Extra check not to bomb your own armies that you just */
-   /* dropped onto a planet you took */
-   /* Sometimes the bots will try to bomb friendly planets too */
-   /* will need to reset the warring if this happens */
-   /* that should happen elsewhere */
-   if( (armies > 4) && ( pl->pl_owner != me->p_team ) ){
+   if(armies > 4){
       req_bomb();
       return;
    }
}
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060522224042
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Mon May 22 15:39:35 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/util.c When mfprintf() was change from varargs to stdarg,
+	it wasn't done correctly.  Fix this.
+
 Mon May 22 14:31:58 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* Makefile.in  Remove calls to glib-config, they aren't needed
 	and fail if glib-config isn't present.
hunk ./Vanilla/robotd/util.c 446
 #endif
 
 
-mfprintf(char *format, ...)
+mfprintf(FILE *fo, char *format, ...)
 {
hunk ./Vanilla/robotd/util.c 448
-   FILE	*fo;
    va_list	ap;
 
    if(!read_stdin)
hunk ./Vanilla/robotd/util.c 454
       return;
    
    va_start(ap, format);
-   fo = va_arg(ap, FILE *);
    (void)vfprintf(fo, format, ap);
    fflush(stdout);
    va_end(ap);
}
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060523074525
 The assault planet code didn't re-check the target planet after the
 assult started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Mon May 22 16:31:58 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/assault.c Have robot check the planet status in
+	assault code, so that if a planet changes teams while it
+	being assaulted the robot will adapt.  It will not try to drop
+	on a planet it can not drop on, and not try to bomb a planet
+	it can not bomb.
+	Also, the robot will not reinforce a planet past 4 armies after
+	it takes it.
+
 Mon May 22 15:39:35 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/util.c When mfprintf() was change from varargs to stdarg,
 	it wasn't done correctly.  Fix this.
hunk ./Vanilla/robotd/assault.c 198
    else
       req_cloak_off("no cloak in assault_planet()");
 
-   if(armies > 4){
+   /* Planets that _can_ be dropped on:
+   1. Planets owned by your team
+   2. Planets that you are hostile to
+   3. Independent planets (owned by team 0)
+   Everything else can't be dropped on.  Planets in groups 1 and 3 _can't_
+   be bombed, only group 2 can be bombed, ie. bombable planets is a
+   proper subset of droppable planets. */
+
+   /* Turn off assault for non-droppable (thus non-bombable too) planets. */
+   if(!unknownpl(pl) && !( (pl->pl_owner == me->p_team) ||
+   	((me->p_swar|me->p_hostile) & pl->pl_owner) ||
+	(pl->pl_owner == 0) )){
+      req_shields_up();
+      unassault_c("planet not droppable");
+      return;
+   }
+
+   if(pl->pl_owner == me->p_team && pl->pl_armies >= 4){
+      req_shields_up();
+      unassault_c("planet fully reinforced");
+      return;
+   }
+
+   /* Only bomb bombable planets. */
+   if(armies > 4 && ((me->p_swar|me->p_hostile) & pl->pl_owner)){
       req_bomb();
       return;
    }
}
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060523074946
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
         
 Now it handles no enemy planets left.  It only skips looking for neut
 planets in preference of enemy planets if it has found an enemy agri and
 it _does_ have enough armies to take it.  In that case, the agri take
 will take precedence.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Mon May 22 16:53:42 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/decide.c Fix several bugs with check_take().
+	It didn't handle the case when no enemy planets were left.  It
+	looked at the last enemy planet in the list, rather than the
+	target enemy planet when deciding if it should take neut planets.
+	It would skip looking for neuts when it found an enemy agri and
+	*didn't* have enough armies to take it.
+
 Mon May 22 16:31:58 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/assault.c Have robot check the planet status in
 	assault code, so that if a planet changes teams while it
hunk ./Vanilla/robotd/decide.c 686
 
    if(pls->total_textra_armies == 0 && me->p_armies == 0) return 0;
 
+   /* Look for closest takeable enemy planet */
    for(k=0; k< pls->num_warteamsp; k++){
       pl = pls->warteam_planets[k];
 
hunk ./Vanilla/robotd/decide.c 701
 	 min_dist = pl->pl_mydist;
       }
    }
-   if(!(pl->pl_flags & PLAGRI) || me->p_armies >= 5){
+   /* Look for ind planets in preference to enemy, unless we found an
+   enemy agri and have the armies to take it.  In that case, the agri
+   take is better. */
+   if(!(tpl && (tpl->pl_flags & PLAGRI) && me->p_armies >= 5)){
       min_dist = GWIDTH;	/* ind overrides non-ind */
       for(k=0; k< pls->num_indsp; k++){
 	 pl = pls->ind_planets[k];
}
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060523075548
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Tue May 23 00:52:55 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/update_players.c The function closest_planet() would
+	usually return NULL every other time it was called.  For speed,
+	it would check the previous closest planet first, then look
+	for a _closer_ planet.  If it didn't find one, it returned
+	NULL, rather than the previous (and current) closest planet.
+
 Mon May 22 16:53:42 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/decide.c Fix several bugs with check_take().
 	It didn't handle the case when no enemy planets were left.  It
hunk ./Vanilla/robotd/update_players.c 1352
 
 {
    register			k;
-   register struct planet	*pl, *rp = NULL;
+   register struct planet	*pl, *rp = opl;
    register			d, mdist = INT_MAX;
 
    if(opl && (mdist = ihypot((double)(j->p_x - opl->pl_x), 
hunk ./Vanilla/robotd/update_players.c 1361
       return opl;
    }
 
-   *dist = INT_MAX;
-
    for(k=0, pl=planets; k < MAXPLANETS; k++, pl++){
 
       d = ihypot((double)(j->p_x - pl->pl_x), (double)(j->p_y - pl->pl_y));
}
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060523080023
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Tue May 23 00:57:29 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/dmessage.c The code to generate the RCD message didn't
+	handle the case when there were no visible friendly and/or enemy
+	ships.  In this case, _state.closest_{e,f} would be NULL.
+
 Tue May 23 00:52:55 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/update_players.c The function closest_planet() would
 	usually return NULL every other time it was called.  For speed,
hunk ./Vanilla/robotd/dmessage.c 1866
     dist.distype = i;
 
     dist.close_pl = me_p->closest_pl->pl_no;
-    dist.close_en = _state.closest_e->p->p_no;
-    dist.close_fr = _state.closest_f->p->p_no;
-    dist.close_j = (_state.closest_e->dist < _state.closest_f->dist) ?
-                    dist.close_en : dist.close_fr;
+    dist.close_en = _state.closest_e ? _state.closest_e->p->p_no : me->p_no;
+    dist.close_fr = _state.closest_f ? _state.closest_f->p->p_no : me->p_no;
+    if(!_state.closest_f) {
+       dist.close_j = dist.close_en;
+    } else if(!_state.closest_e) {
+       dist.close_j = dist.close_fr;
+    } else {
+       dist.close_j = (_state.closest_e->dist < _state.closest_f->dist) ?
+		       dist.close_en : dist.close_fr;
+    }
                     
     /* These are just guesses.... */
     dist.tclose_pl = 0;
}
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060523080845
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Tue May 23 01:07:02 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/update_players.c Fix a warning about a uninitialized use
+	of pldist in update_players().
+
 Tue May 23 00:57:29 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/dmessage.c The code to generate the RCD message didn't
 	handle the case when there were no visible friendly and/or enemy
hunk ./Vanilla/robotd/update_players.c 145
 	 army_check1(p, j);
 	 army_check2(p, j);
       }
-      if(p->invisible)
+      if(p->invisible){
 	 p->closest_pl = NULL;
hunk ./Vanilla/robotd/update_players.c 147
-      else
+      }
+      else {
 	 p->closest_pl = closest_planet(j, &pldist, p->closest_pl);
hunk ./Vanilla/robotd/update_players.c 150
-      p->closest_pl_dist = pldist;
+	 p->closest_pl_dist = pldist;
+      }
 
       if(j->p_flags & PFBOMB)
 	 p->bombing = _udcounter;
}
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060523085409
 Some calls to req_cloak_off() were missing the function's argument
 (reason string).
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Tue May 23 01:51:17 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/assault.c, robotd/escort.c, robotd/getarmies.c,
+	robotd/robot.c Some calls to req_cloak_off() were missing the
+	function's argument (reason string).
+
 Tue May 23 01:07:02 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/update_players.c Fix a warning about a uninitialized use
 	of pldist in update_players().
hunk ./Vanilla/robotd/assault.c 179
 
 #ifdef nodef
    if(!do_cloak(0))
-      req_cloak_off();
+      req_cloak_off("no do cloak");
 #endif
 
    cloak=0; /* start assuming you don't need to cloak */
hunk ./Vanilla/robotd/escort.c 52
    /* check internal state */
    switch(_state.escort){
       case 0:
-	 req_cloak_off();
+	 req_cloak_off("escort: 0");
 	 /* just got request, need to go to planet */
 	 if(DEBUG & DEBUG_ESCORT)
 	    printf("goto escort planet %s\n", escpl->pl_name);
hunk ./Vanilla/robotd/escort.c 61
 
       case 1:
 	 /* close enough to escort planet .. wait for escortee */
-	 req_cloak_off();
+	 req_cloak_off("escort: 1");
 	 if(DEBUG & DEBUG_ESCORT)
 	    printf("wait for escort %s\n", escp->p->p_mapchars);
 	 wait_for_escort(escp, escpl);
hunk ./Vanilla/robotd/escort.c 85
 	 break;
       
       case 5:
-	 req_cloak_off();
+	 req_cloak_off("escort: 5");
 	 /* do defenders */
 	 if(DEBUG & DEBUG_ESCORT)
 	    printf("no defenders\n");
hunk ./Vanilla/robotd/getarmies.c 176
    else{
       _state.lock = 0;
       req_shields_up();
-      req_cloak_off();
+      req_cloak_off("no armies to beam");
       _state.p_desspeed = me->p_speed;
       return;
    }
hunk ./Vanilla/robotd/robot.c 722
    }
    if((me->p_flags & PFCLOAK) &&
       me->p_ship.s_type != ASSAULT && (!pl || !(pl->pl_flags & PLFUEL))){
-      req_cloak_off();
+      req_cloak_off("recharge: no fuel planet");
    }
 
    if(_state.pl_danger){
}
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060523100806
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping it's own HW, for proximity.  This makes the code much
 smaller and faster.  Realistically, the HWs are always at the standard
 indexes, even with non-standard planet layouts.  Included a bit of code,
 #if'ed out, that will find home worlds by name, the way the bot does when
 it wants to refit.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Tue May 23 03:05:55 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* robotd/assault.c  The check for res danger would make the
+	robot cloak when near _any_ home planet, so it would
+	cloak even when bombing it's own core.  Fixed this, and made
+	it faster too.
+
 Tue May 23 01:51:17 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/assault.c, robotd/escort.c, robotd/getarmies.c,
 	robotd/robot.c Some calls to req_cloak_off() were missing the
hunk ./Vanilla/robotd/assault.c 49
 /* determine if there is risk of death due to res of opponent */
 static int risk_res_death(struct planet *pl)
 {
-  int i;
-  if (pl == NULL) return 0;
-  /* One of the home planets identified by server etc/sysdef PLANETS */
-  if (pl->pl_flags & PLHOME) return 1;
-  /* Altair in standard position */
-  if (pl->pl_no == 7 && pl->pl_x == 11000 && pl->pl_y == 75000) return 1;
-  /* Draconis in standard position */
-  if (pl->pl_no == 16 && pl->pl_x == 28000 && pl->pl_y == 23000) return 1;
-  /* Scorpii in standard position */
-  if (pl->pl_no == 26 && pl->pl_x == 70720 && pl->pl_y == 26320) return 1;
-  /* Within rectangular phaser distance of any home planet res point */
-  for (i=0,pl=planets;i<MAXPLANETS;i++,pl++) {
-    if (pl->pl_flags & PLHOME) {
-      if(ABS(pl->pl_x - me->p_x) < 12000 && ABS(pl->pl_y - me->p_y) < 12000) {
-	return 1;
+   /* Home planet locations.  This will not work if the HWs are not at
+   their normal indexes.  This should always be the case, even for
+   non-standard planet layouts. */
+   const static int hw[4] = {0, 10, 20, 30};
+   int i;
+
+#if 0
+   /* Code to find home planets by name, like the bot does to refit. */
+   static int found_hw = 0;
+   if(!found_hw) {
+      extern struct planet *team_planet(int);
+      hw[0] = (team_planet(FED)?:&planets[0])->pl_no;
+      hw[1] = (team_planet(ROM)?:&planets[0])->pl_no;
+      hw[2] = (team_planet(KLI)?:&planets[0])->pl_no;
+      hw[3] = (team_planet(ORI)?:&planets[0])->pl_no;
+      found_hw = 1;
+      mfprintf(stderr, "planets at %d %d %d %d\n", hw[0], hw[1], hw[2], hw[3]);
+   }
+#endif
+
+   if(pl == NULL) return 0;
+
+   for(i = 0; i < 4; i++){
+      if((1<<i) == me->p_team) continue; /* No danger at MY homeworld */
+
+      pl = &planets[hw[i]];
+      /* Inside rectangular phaser/tractor range of a ressing ship. */
+      if(ABS(pl->pl_x - me->p_x) < 12200 && ABS(pl->pl_y - me->p_y) < 12200){
+	 return 1;
       }
hunk ./Vanilla/robotd/assault.c 79
-    }
-  }
-  return 0;
+   }
+   return 0;
 }
 
 goto_assault_planet()
}
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060523110921
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 torps too.  Without it, the bot thinks all torps are going straight up,
 making it a very bad dodger (unless you attack from below).  
 
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
<
> {
hunk ./Vanilla/ChangeLog 1
+Tue May 23 04:06:08 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* ntserv/genspkt.c Hadley's bot expects to get torp direction
+	from the server, but the server only sends it for your own torps. 
+	Changed to send it for other torps too.  Without it, the bot
+	thinks all torps are going straight up, making it a very bad
+	dodger (unless you attack from below).  Should be fixed to only
+	turn this on for the robot, so as not to help borgs.
+
 Tue May 23 03:05:55 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* robotd/assault.c  The check for res danger would make the
 	robot cloak when near _any_ home planet, so it would
hunk ./Vanilla/ntserv/genspkt.c 564
 	tp->type = SP_TORP;
 	tp->x    = htonl(t->t_x);
 	tp->y    = htonl(t->t_y);
+	tp->dir  = t->t_dir; /* The robot needs this */
 	tp->tnum = htons(i);
 	sendClientPacket(tp);
 	if ( (t->t_status != tpi->status)
}

Context:

[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
7b5ddf2aa0cf2d038e3f1bb0472d96e99df60bf0

From jimmyhua73 at yahoo.com  Tue May 23 11:11:58 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 09:11:58 -0700 (PDT)
Subject: [netrek-dev] Number of players on Vanilla Server
In-Reply-To: <C4FF3523-4586-4033-998B-DA090189FBA3@luky.nl>
Message-ID: <20060523161158.74724.qmail@web35311.mail.mud.yahoo.com>

Hi, 

I think the max number of players in netrek are

all the letters in the alphabet and all the numbers.

So, 26+10, or 36. 

Your standard game is 8 vs. 8.  But in addition to
that. You can have up to 4 fighting robots that mix it
up, and they take slots too. Also, 1 robot that
controls the game. And a bunch of "observers", up to 8
(sometimes more, based on who sets up the server). 

People in the wait queue when the game is full, also
take up a slot. (Although U shouldn't get getting
information about these people).

Jimmy


--- Chris en Judith <narcis at lukassen.homelinux.com>
wrote:

> Hi,
> 
> i'm writing an ObjC client for netrek but notice
> that the server is  
> sending more than 16 players, in fact i've seen
> player 31 come by!  
> it's running out of my arrays but that is not the
> main problem,
> 
> Why is it sending so many? i would think 16 is
> enough
> 
> regards
> 
> Chris
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
> 



From ahn at orion.netrek.org  Tue May 23 12:21:14 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Tue, 23 May 2006 13:21:14 -0400
Subject: [netrek-dev] Problem with res-rsa configure and gmp
In-Reply-To: <20060522233101.GC7001@us.netrek.org>
References: <Pine.LNX.4.58.0605221335250.4835@shell2.speakeasy.net>
	<20060522233101.GC7001@us.netrek.org>
Message-ID: <20060523172114.GA6881@orion.netrek.org>

On Tue, May 23, 2006 at 09:31:01AM +1000, James Cameron wrote:
> On Mon, May 22, 2006 at 02:22:04PM -0700, Trent Piepho wrote:
> > resrsa-gmp-autoconf.darcs
> 
> Taken, thanks.

Sorry for being out of the loop, but have you guys been releasing
RES-RSA as part of the Vanilla Server package?  I just noticed that the
RES-RSA source code is in the darcs repository.  There are some US
export regulations that cover RES-RSA.



From jimmyhua73 at yahoo.com  Tue May 23 11:46:33 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 09:46:33 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <Pine.LNX.4.58.0605230506030.24257@shell2.speakeasy.net>
Message-ID: <20060523164634.46436.qmail@web35315.mail.mud.yahoo.com>

I got a "bad patch bundle" error message.

Did you by any chance do a 

darcs send -o patch.dpatch

and then manually edit the file? There's a hash check
at the end that will fail if you do this. 

Patch bundle hash:
7b5ddf2aa0cf2d038e3f1bb0472d96e99df60bf0

Instead, do a "darcs whatsnew." It will give you a
list of changes you made so you can type it into the
darcs file, and not have to go back and edit it. 

Or, if U are like me, and have tons of changes, but
only want to send a few at a time... 

darcs record
darcs send -o temp.file
darcs unrecord
darcs record (this time referring to the temp.file)
darcs send-o real.file

e-mail file with attachment.

Okay, the above sequence is a pain. But, I have yet
find a better way. 

Jimmy

--- Trent Piepho <xyzzy at speakeasy.org> wrote:

> On Tue, 23 May 2006, Trent Piepho wrote:
> > Here is a pile of patches for the robot.  Most of
> have been discussed here
> 
> Ok, the actual patch this time.> 
> New patches:





From netrek at gmail.com  Tue May 23 12:49:11 2006
From: netrek at gmail.com (Zach)
Date: Tue, 23 May 2006 17:49:11 +0000
Subject: [netrek-dev] Vanilla compile fatal error
Message-ID: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>

System arch: i686 (Pentium 3).
Linux kernel: 2.4.27-2-686
OS: Debian GNU/Linux (testing release)

I checked /netrek-server/Vanilla/debian/control and I have all those packages.

I am including the output of configure and make.

PS: When view my logfile (saved using 'script') in emacs I see these
weird control character codes such as lots of "^M" and some "^H" and
"^G" and "^[[7P". I ran in an xterm with $TERM set as xterm. Running
in X Windows with GNOME desktop. Anyone know how I can stop these
(ANSI?) characters from being inserted?

Zach

./configure

creating cache ./config.cache

checking for used sources... Vanilla SERVER

checking for a BSD compatible install... /usr/bin/install -c

checking for gcc... gcc

checking whether the C compiler (gcc  ) works... yes

checking whether the C compiler (gcc  ) is a cross-compiler... no

checking whether we are using GNU C... yes

checking whether gcc accepts -g... yes

checking how to run the C preprocessor... gcc -E

checking whether ln -s works... yes

checking whether make sets ${MAKE}... yes

checking for AIX... no

checking for inline... inline

checking if fd_set requires sys/select.h... no

checking for ANSI C header files... yes

checking for unistd.h... yes

checking for memory.h... yes

checking for math.h... yes

checking for stdlib.h... yes

checking for sys/timeb.h... yes

checking for sys/ptyio.h... no

checking for sys/fcntl.h... yes

checking for fcntl.h... yes

checking for ctype.h... yes

checking for machine/endian.h... no

checking for sys/resource.h... yes

checking for sys/wait.h... yes

checking for netinet/in.h... yes

checking for sys/filio.h... no

checking for gdbm.h... yes

checking for ncurses.h... yes

checking for gdbm_open in -lgdbm... yes

checking for wait3 that fills in rusage... yes

checking for pid_t... yes

checking for uid_t in sys/types.h... yes

checking for size_t... yes

checking for vfork.h... no

checking for working vfork... yes

checking whether struct tm is in sys/time.h or time.h... time.h

checking for itimer in time.h... no

checking size of long... 4

checking for u_int in sys/types.h... yes

checking for PATH_MAX in limits.h... yes

checking for main in -lgdi32... no

checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include

checking for mp.h... no

checking for gmp.h... yes

checking for main in -lmp... yes

checking for main in -lgmp... yes

checking res-rsa/configure... RSA utilities found

checking for main in -lXbsd... no

checking for main in -lsocket... no

checking for main in -linet... no

checking for main in -lnsl... yes

checking for main in -lseq... no

checking for main in -lsun... no

checking for main in -lipc... no

checking for main in -lshm... no

checking for main in -lstuff... no

checking for crypt in -lcrypt... yes

checking for main in -ltermcap... yes

checking for newwin in -lncurses... yes

checking return type of signal handlers... void

checking for restartable system calls... yes

checking for signals style... BSD

checking for usleep... yes

checking for random... yes

checking for setstate... yes

checking for strftime... yes

checking for ftime... yes

checking for strcmpi... no

checking for strncmpi... no

checking for main in -lm... yes

checking for nint... no

checking for nint in -lsunmath... no

checking for random... (cached) yes

checking for strdup... yes

checking for rint... yes

checking for netstat... yes

checking for uptime... yes

updating cache ./config.cache

creating ./config.status

creating system.mk

creating Makefile

creating ntserv/Makefile

creating tools/Makefile

creating sequencer/Makefile

creating newstartd/Makefile

creating robots/Makefile

creating keycomp/Makefile

creating xsg/Makefile

creating pledit/Makefile

creating robotd/Makefile

creating docs/Makefile

creating tools/no_geno_timer

creating tools/geno_timer

creating docs/sample_geno_timer_crontab

creating docs/sample_sysdef

creating include/config.h

configuring in res-rsa

running /bin/sh ./configure  --cache-file=.././config.cache --srcdir=.

loading cache .././config.cache

checking for gcc... (cached) gcc

checking whether the C compiler (gcc  ) works... yes

checking whether the C compiler (gcc  ) is a cross-compiler... no

checking whether we are using GNU C... (cached) yes

checking whether gcc accepts -g... (cached) yes

checking how to run the C preprocessor... (cached) gcc -E

checking for ranlib... ranlib

checking for inline... (cached) inline

checking for gmp.h... yes

checking for mpz_init in -lgmp... no

GMP not found, non-GMP version of librsa will be built.

updating cache .././config.cache

creating ./config.status

creating Makefile

creating config.h



Directories

    Binaries (external use) : /usr/local/games/netrek-server-vanilla/bin

    Binaries (internal use) : /usr/local/games/netrek-server-vanilla/lib

    Configuration files     : /usr/local/games/netrek-server-vanilla/etc

    Local state files       : /usr/local/games/netrek-server-vanilla/var



]0;zu22 at netrek:
/home/zu22/src/netrek-server/Vanillazu22 at netrek:~/src/netrek-server/Vanilla$
make

touch null

make depend

make[1]: Entering directory `/home/zu22/src/netrek-server/Vanilla'

cd ntserv;    make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/ntserv'

gcc -M -g -O2 -Wall  -DRSA   -I../include ./cluecheck.c ./coup.c
./data.c ./db.c ./death.c ./detonate.c  ./enter.c ./findslot.c
./getentry.c ./getname.c  ./salt.c ./getship.c  ./input.c
./interface.c  ./main.c  ./orbit.c ./phaser.c  ./plasma.c ./redraw.c
./reserved.c  ./sintab.c ./socket.c  ./genspkt.c  ./smessage.c
./startrobot.c  ./timecheck.c ./torp.c  ./util.c  ./warning.c
./ping.c ./getpath.c  ./features.c ./distress.c ./transwarp.c
./gencmds.c ./ntscmds.c ./openmem.c ./feature.c ./queue.c
./slotmaint.c ./wander2.c ./sysdefaults.c ./rsa_key.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/ntserv'

cd robots;    make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/robots'

touch .depend

gcc -M  -g -O2 -Wall  -DRSA -DROBOT -I. -I../include ./puck.c
./puckmove.c ./mars.c ./marsmove.c ./robotII.c ./rmove.c
./../ntserv/commands.c ./basep.c ./newbie.c ./inl.c ./inlcomm.c
./inlcmds.c ./pret.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/robots'

cd newstartd; make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/newstartd'

gcc -M  -g -O2 -Wall  -DRSA  -DPORT=2592 -I../include ./newstartd.c
./newaccess.c ./subnet.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/newstartd'

cd tools;     make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/tools'

touch .depend

gcc -M  -g -O2 -Wall  -DRSA -I../include ./blotpassword.c
./loadchecker.c ./mess.c ./mergescores.c ./newscores.c ./planets.c
./players.c ./scores.c ./setgalaxy.c ./showgalaxy.c ./stat.c
./trimscores.c ./watchmes.c ./fun.c ./xtkill.c ./keyman.c ./nuke.c
./metaget.c ./update.c ./convert.c ./conq_vert.c  ./sortdb.c
./ntpasswd.c ./setgame.c ./setplanet.c ./setteam.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/tools'

cd pledit;    make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/pledit'

gcc -M  -g -O2 -Wall  -DRSA  -I. -I../include ./main.c ./edit.c
./input.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/pledit'

cd keycomp;   make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/keycomp'

gcc -M   -g -O2 -Wall  -DRSA -I../include ./rsa_keycomp.c
./rsa_key2cap.c  > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/keycomp'

cd sequencer; make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/sequencer'

gcc -M  -g -O2 -Wall  -DRSA -I../include ./roboshar.c ./sequencer.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/sequencer'

cd xsg;       make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/xsg'

gcc -M  -g -O2 -Wall  -DRSA  -I../include ./colors.c ./defaults.c
./dmessage.c ./inform.c ./input.c ./main.c ./modify.c ./newwin.c
./option.c ./planetlist.c ./planets.c ./playerlist.c ./redraw.c
./robotwin.c ./shmem.c ./sintab.c ./smessage.c ./stats.c ./util.c
./war.c ./warning.c ./x11window.c ./localdata.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/xsg'

cd pledit;    make depend

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/pledit'

gcc -M  -g -O2 -Wall  -DRSA  -I. -I../include ./main.c ./edit.c
./input.c > .depend

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/pledit'

make[2]: Entering directory `/home/zu22/src/netrek-server/Vanilla/res-rsa'

/bin/touch .depend

makedepend: warning:  rsa_math.c (reading /usr/include/stdio.h, line
34): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  rsa_math.c (reading /usr/include/bits/types.h,
line 31): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  rsa_math.c (reading /usr/include/_G_config.h,
line 14): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  rsa_math.c (reading /usr/include/wchar.h, line
48): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  rsa_math.c (reading /usr/include/gconv.h, line
31): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  rsa_math.c (reading /usr/include/libio.h, line
53): cannot find include file "stdarg.h"

	not in /usr/local/lib/gcc-include/stdarg.h

	not in /usr/include/stdarg.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stdarg.h

makedepend: warning:  rsa_math.c (reading /usr/include/stdlib.h, line
33): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  rsa_gmp.c (reading /usr/include/gmp.h, line 54):
cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  mkkey.c (reading /usr/include/string.h, line
33): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  mkkey.c (reading /usr/include/limits.h, line
124): cannot find include file "limits.h"

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/limits.h

makedepend: warning:  mkkey.c (reading /usr/include/sys/types.h, line
147): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

makedepend: warning:  mkkey.c (reading /usr/include/unistd.h, line
195): cannot find include file "stddef.h"

	not in /usr/local/lib/gcc-include/stddef.h

	not in /usr/include/stddef.h

	not in /usr/lib/gcc/i486-linux-gnu/4.0.3/include/stddef.h

make[2]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/res-rsa'

make[1]: Leaving directory `/home/zu22/src/netrek-server/Vanilla'

cd ntserv; make libnetrek.a

make[1]: Entering directory `/home/zu22/src/netrek-server/Vanilla/ntserv'

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o balance.o balance.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o bay.o bay.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o coup.o coup.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o data.o data.c

gcc -g -O2 -Wall  -DRSA   -I../include  -c db.c

db.c: In function 'changepassword':

db.c:210: warning: implicit declaration of function 'crypt'

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o detonate.o detonate.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o distress.o distress.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o enter.o enter.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o feature.o feature.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o features.o features.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o gencmds.o gencmds.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o genspkt.o genspkt.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o getpath.o getpath.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o getship.o getship.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o glog.o glog.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o interface.o interface.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o ltd_stats.o ltd_stats.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o openmem.o openmem.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o orbit.o orbit.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o phaser.o phaser.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o ping.o ping.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o plasma.o plasma.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o rsa_key.o rsa_key.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o reserved.o reserved.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o salt.o salt.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o slotmaint.o slotmaint.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o sintab.o sintab.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o smessage.o smessage.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o socket.o socket.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o startrobot.o startrobot.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o sysdefaults.o sysdefaults.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o torp.o torp.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o transwarp.o transwarp.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o util.o util.c

gcc -g -O2 -Wall  -DRSA   -I../include   -c -o warning.o warning.c

ar cru libnetrek.a balance.o 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

make[1]: RANLIB@: Command not found

make[1]: *** [libnetrek.a] Error 127

make[1]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/ntserv'

make: *** [do_library] Error 2

]0;zu22 at netrek: /home/zu22/src/netrek-server/Vanillazu22 at netrek:

Zach


From ahn at orion.netrek.org  Tue May 23 12:13:13 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Tue, 23 May 2006 13:13:13 -0400
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
References: <Pine.LNX.4.58.0605221113430.12905@shell2.speakeasy.net>
	<20060522233240.55109.qmail@web35304.mail.mud.yahoo.com>
	<3e8ca5c80605221944h4d7e4b46md95ad8e7bf978ef7@mail.gmail.com>
Message-ID: <20060523171313.GA6823@orion.netrek.org>

On Tue, May 23, 2006 at 12:44:37PM +1000, Stephen Thorne wrote:
> 
> As such, I've been making plans for after a release of the various
> codebases (cow, netrekxp, vanilla) all three codebases should go
> through a 'cleanup'. Doing a cleanup will break all patches, so there
> will have to be a post-release development freeze.
> 
> My desire:
> 
> June 1st: Release of cow, netrekxp and vanilla. Source tarballs
> published, and repoistories tagged. All development frozen.
> June 2-8: Volunteers go through codebases, file by file, and sanitise
> the code. Would prefer one commit per file (easier to spot regressions
> and back out changes).
> June 9th+: All new patches required to apply cleanly against the new,
> clean, source.
> 
> How do you folks feel about that?

I would think that it would be easier for one person to use a code
formatter to reformat all the files initially.  You could then have
volunteers go through and review the reformatted code afterwards.  This
would seem much less error prone than having developers manually go
through each file and sanitize the code.

If you would like to reformat the code this way but aren't very
comfortable with using reformatters, I'd be happy to do the initial
legwork of creating the baseline.  It shouldn't take more than half an
hour.



From ahn at orion.netrek.org  Tue May 23 12:15:05 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Tue, 23 May 2006 13:15:05 -0400
Subject: [netrek-dev] patch postings to this list
Message-ID: <20060523171505.GA6855@orion.netrek.org>

Do you guys plan to continue posting darcs patches to netrek-dev
indefinitely?


From netrek at gmail.com  Tue May 23 13:07:18 2006
From: netrek at gmail.com (Zach)
Date: Tue, 23 May 2006 18:07:18 +0000
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
Message-ID: <ecfa260c0605231107p41075599g4d637ddb755a37a9@mail.gmail.com>

zu22 at netrek:~/src/netrek-server/Vanilla$ ranlib -v
GNU ranlib 2.16.91 20060413 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

zu22 at netrek:~/src/netrek-server/Vanilla$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)

zu22 at netrek:~/src/netrek-server/Vanilla$ ar --version
GNU ar 2.16.91 20060413 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.


From netrek at gmail.com  Tue May 23 12:54:27 2006
From: netrek at gmail.com (Zach)
Date: Tue, 23 May 2006 17:54:27 +0000
Subject: [netrek-dev] Connection to server protocol
In-Reply-To: <F1CC6865-6F3B-4101-9455-6E92528872C2@luky.nl>
References: <42902E01-94C8-47F8-9E14-F2E7E2C4A0A6@luky.nl>
	<8BBF2E2C-CF40-404B-929E-F0FBD27E83F8@luky.nl>
	<F1CC6865-6F3B-4101-9455-6E92528872C2@luky.nl>
Message-ID: <ecfa260c0605231054q55e7956dm978b62b0acaec6c6@mail.gmail.com>

I never saw the message it references show up on the list, namely:

On 20 May 2006, at 22:44, Chris en Judith wrote:

> Hi
>
> i'm developing a new client based on Objective-C/Cocoa but have
> difficulties figuring out the protocol required to establish a
> connection to the server. So far i can connect to the server and
> exchange some data but after the MOTD i get lost. Here's a
> transcript of what i am trying:

Zach


From williamb at its.caltech.edu  Tue May 23 13:47:10 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Tue, 23 May 2006 11:47:10 -0700 (PDT)
Subject: [netrek-dev] patch postings to this list
In-Reply-To: <20060523171505.GA6855@orion.netrek.org>
References: <20060523171505.GA6855@orion.netrek.org>
Message-ID: <Pine.GSO.4.58.0605231144300.121@clyde>

I would propose having all patches go to the same list for both CVS and
darcs, maybe rename netrek-CVS to netrek-patches.  Keep netrek-dev low
traffic, for design issues or approval of potentinally controversial
patches only.  And redefine the currently unused netrek mailing list as
for players, clue game announcements, etc.  Change mailman.us.netrek.org
to reflect that, and advertise on rgn and server MOTDs.
Bill

On Tue, 23 May 2006, Dave Ahn wrote:

> Do you guys plan to continue posting darcs patches to netrek-dev
> indefinitely?
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>
>


From williamb at its.caltech.edu  Tue May 23 13:42:44 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Tue, 23 May 2006 11:42:44 -0700 (PDT)
Subject: [netrek-dev] Number of players on Vanilla Server
In-Reply-To: <C4FF3523-4586-4033-998B-DA090189FBA3@luky.nl>
References: <C4FF3523-4586-4033-998B-DA090189FBA3@luky.nl>
Message-ID: <Pine.GSO.4.58.0605231138190.121@clyde>

As I understand it, old limit was 20 players (16 in game, 4 observer), it
was increased to 32 in Vanilla version 2.9pl4.  The reason being: so we
can have lots of observers, and it supports 4 way T mode in the future I
suppose.  A crowded game can have 10 plus observers, plus it was very
annoying in INL to only have a limited number of obs slots per team.
Bill

On Tue, 23 May 2006, Chris en Judith wrote:

> Hi,
>
> i'm writing an ObjC client for netrek but notice that the server is
> sending more than 16 players, in fact i've seen player 31 come by!
> it's running out of my arrays but that is not the main problem,
>
> Why is it sending so many? i would think 16 is enough
>
> regards
>
> Chris
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/listinfo/netrek-dev
>
>


From williamb at its.caltech.edu  Tue May 23 13:48:21 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Tue, 23 May 2006 11:48:21 -0700 (PDT)
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
Message-ID: <Pine.GSO.4.58.0605231147380.121@clyde>

Run aclocal and autoconf.
Bill

> make[1]: RANLIB@: Command not found
>
> make[1]: *** [libnetrek.a] Error 127
>
> make[1]: Leaving directory `/home/zu22/src/netrek-server/Vanilla/ntserv'
>
> make: *** [do_library] Error 2
>
> ]0;zu22 at netrek: /home/zu22/src/netrek-server/Vanillazu22 at netrek:
>
> Zach
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>
>


From xyzzy at speakeasy.org  Tue May 23 14:48:09 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 12:48:09 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <20060523152037.1659.qmail@web35314.mail.mud.yahoo.com>
References: <20060523152037.1659.qmail@web35314.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605231241180.22502@shell3.speakeasy.net>

On Tue, 23 May 2006, Jimmy Huang wrote:
> > Tue May 23 04:09:21 PDT 2006  Trent Piepho
> > <xyzzy at speakeasy.org>
> >   * torp dir for robot
> >   Hadley's bot expects to get torp direction from
> > the server, but the
> >   server only sends it for your own torps.  Someone
> > probably changed this
> >   years ago to combat borgs.  Changed back to send
> > it for other
> >   torps too.  Without it, the bot thinks all torps
> > are going straight up,
> >   making it a very bad dodger (unless you attack
> > from below).
>
> Whoa. I thought if Hadley's bot didn't get torp
> direction information, it did try to deduce it. Did I
> miss something in the code?

Nope.  I discovered this when I was trying to get the bot the play with
ping-pong plasma.  It would usually just let itself get smacked.  I finally
figured out that the dodge code thought all torps (& plasma) were going in
direction 0, straight up.

Haven't you noticed that the bot really sucks are dodging torps?  The iggy
bots are much simpler Hadley's bot, but they are far harder to hit.


From xyzzy at speakeasy.org  Tue May 23 15:35:59 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 13:35:59 -0700 (PDT)
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
Message-ID: <Pine.LNX.4.58.0605231305070.22502@shell3.speakeasy.net>

On Tue, 23 May 2006, Stas Pirogov wrote:
>
> As pretty fresh darcs user I also didn't find any good way
> to find who created this regression. I had to zcat all files
> under patches directory to actually find that Quozl is the man :)
> Is there good way to get version diff (i.e. something like cvs diff -r 1.1
> filename) ?

Put this in your ~/.darcs/defaults, or the _darcs/prefs/defaults file for
the repository:
ALL unified

Make the diffs much easier to read.

# Show a single patch
darcs diff -p name

# changes to working version since some patch
darcs diff --from-patch=name

# changes between two versions
darcs diff --from-patch=name --to-patch=name

The name is a regexp that will match against the patch name.  You can
also use the same commands but change 'patch' to 'match' and get a
version that let you specifiy a patch like this:

darcs diff --match="author Trent && name robot"
darcs diff --match="author jimmy && name robot"

There is no easy version number like in CVS or Mercurial.  The is a large
hash value for each patch, but I haven't found out how you get it.


From xyzzy at speakeasy.org  Tue May 23 14:58:15 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 12:58:15 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <20060523164634.46436.qmail@web35315.mail.mud.yahoo.com>
References: <20060523164634.46436.qmail@web35315.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605231252540.22502@shell3.speakeasy.net>

On Tue, 23 May 2006, Jimmy Huang wrote:
> I got a "bad patch bundle" error message.
>
> Did you by any chance do a
>
> darcs send -o patch.dpatch
>
> and then manually edit the file? There's a hash check
> at the end that will fail if you do this.

No, didn't do that.  I just re-made the patch, and it's exactly the same as the
file I sent before.  Maybe it was the size, I got a message from the list
software that my message was too big.

> Okay, the above sequence is a pain. But, I have yet
> find a better way.

I think the way each patch builds on the changelog is preventing
darcs from letting us select individual patches.  It seems like,
every patch depends on all previous patches.  This is clearly unsustainable.


From quozl at us.netrek.org  Tue May 23 17:15:54 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 08:15:54 +1000
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <Pine.GSO.4.58.0605231147380.121@clyde>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
	<Pine.GSO.4.58.0605231147380.121@clyde>
Message-ID: <20060523221554.GB4911@us.netrek.org>

On Tue, May 23, 2006 at 11:48:21AM -0700, William Balcerski wrote:
> Run aclocal and autoconf.

As I said Zach, look at tests/build.  That's what it does, so should you.

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


From quozl at us.netrek.org  Tue May 23 17:20:10 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 08:20:10 +1000
Subject: [netrek-dev] patch postings to this list
In-Reply-To: <20060523171505.GA6855@orion.netrek.org>
References: <20060523171505.GA6855@orion.netrek.org>
Message-ID: <20060523222010.GC4911@us.netrek.org>

On Tue, May 23, 2006 at 01:15:05PM -0400, Dave Ahn wrote:
> Do you guys plan to continue posting darcs patches to netrek-dev
> indefinitely?

I'd like to do so, yes.  It keeps developers in the loop.  I expect all
developers to review the patches.  I think we are getting code reviews
faster than if we'd posted to the netrek-cvs list, whose membership is
unknown to me.  I'd like a netrek-announce list for anyone who can't
afford the cost of seeing the patches on netrek-dev, but perhaps the
bare netrek list is sufficient.

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


From jimmyhua73 at yahoo.com  Tue May 23 17:14:56 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 23 May 2006 15:14:56 -0700 (PDT)
Subject: [netrek-dev] Lots of patches for the robot
In-Reply-To: <Pine.LNX.4.58.0605231241180.22502@shell3.speakeasy.net>
Message-ID: <20060523221456.95307.qmail@web35313.mail.mud.yahoo.com>

> > Whoa. I thought if Hadley's bot didn't get torp
> > direction information, it did try to deduce it.
> Did I
> > miss something in the code?
> 
> Nope.  I discovered this when I was trying to get
> the bot the play with
> ping-pong plasma.  It would usually just let itself
> get smacked.  I finally
> figured out that the dodge code thought all torps (&
> plasma) were going in
> direction 0, straight up.
> 
> Haven't you noticed that the bot really sucks are
> dodging torps?  The iggy
> bots are much simpler Hadley's bot, but they are far
> harder to hit.

Yeah, after you wrote your message,and I typed in
mine. I did notice that if you are Rom in a Rom vs.
Fed game. It is MUCH EASIER to kill a robot. 

Since I usually like playing Fed in Fed vs. Rom, I
never really noticed ;-P. 

I once munged the change course function completely,
and really didn't notice the bots fighting any
differently!!! It was then, I realized something.
(Don't fly in straight lines, it makes you a much less
easier target!). 

It's a good catch to notice that the dodge code isn't
working right. 


Jimmy



From quozl at us.netrek.org  Tue May 23 17:26:02 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 08:26:02 +1000
Subject: [netrek-dev] Number of players on Vanilla Server
In-Reply-To: <C4FF3523-4586-4033-998B-DA090189FBA3@luky.nl>
References: <C4FF3523-4586-4033-998B-DA090189FBA3@luky.nl>
Message-ID: <20060523222602.GD4911@us.netrek.org>

Chris, the specification of the protocol is in the source code for the
server, you should read and understand the relevant sections as soon as
yohu have a question about how the protocol works.

MAXPLAYER is set in include/config.h to 32.  That's player number zero
through to 31, as you observed.

How far are you from release?  We're synchronising here for a 1st June
release for several components.

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


From quozl at us.netrek.org  Tue May 23 17:34:36 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 08:34:36 +1000
Subject: [netrek-dev] Connection to server protocol
In-Reply-To: <8BBF2E2C-CF40-404B-929E-F0FBD27E83F8@luky.nl>
References: <42902E01-94C8-47F8-9E14-F2E7E2C4A0A6@luky.nl>
	<8BBF2E2C-CF40-404B-929E-F0FBD27E83F8@luky.nl>
Message-ID: <20060523223436.GE4911@us.netrek.org>

G'day Chris,

No, tcpdump doesn't really help me ... I use packet decoding logic in
the Linux client to figure out what is going on.  We don't have this in
the server yet, but it's something I'm pondering.

On Sat, May 20, 2006 at 10:50:24PM +0200, Chris en Judith wrote:
> roughly the server responds to my CP_SOCKET and CP_FEATURE message  
> with a SP_MOTD and a SP_MOTD_PIC the remainder of the buffer is  
> filled with a 0 and gets flushed. (i might accidently have read an  
> entire frame 1536 in stead of what was really in the buffer but  
> what the hack.

You'd better clarify this.  Packets are sent appended to each other, and
unless you get the sizes exactly right (their size is not in the data
stream usually) then you will lose alignment and crash.

> i was expecting a message SP_S_PLAYER to set which slot i'd been  
> allocated but i might be fully off here.

After SP_MOTD you get SP_YOU with your player number, then a batch of
(SP_PL_LOGIN, SP_HOSTILE, SP_PLAYER_INFO, SP_KILLS, SP_PSTATUS and
SP_PLAYER) for each of the 32 slots.  Then you get all the
SP_PLANET_LOCs for each planet, then all the SP_FEATURE packets, then an
SP_LOGIN prompt packet.  Your reply at this point should be CP_LOGIN.

See http://quozl.linux.org.au/netrek/login.log.gz for an example of a
connection and login sequence.

> What is going wrong and what should i have done ?

Read and understand the working protocol and crosscheck against your
code.

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


From quozl at us.netrek.org  Tue May 23 18:21:42 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 09:21:42 +1000
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <ecfa260c0605231107p41075599g4d637ddb755a37a9@mail.gmail.com>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
	<ecfa260c0605231107p41075599g4d637ddb755a37a9@mail.gmail.com>
Message-ID: <20060523232142.GH4911@us.netrek.org>

On Tue, May 23, 2006 at 06:07:18PM +0000, Zach wrote:
> GNU ranlib 2.16.91 20060413 Debian GNU/Linux
> gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> GNU ar 2.16.91 20060413 Debian GNU/Linux

Those versions all look fine.  Follow the steps in tests/build.

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


From ahn at orion.netrek.org  Tue May 23 18:07:27 2006
From: ahn at orion.netrek.org (Dave Ahn)
Date: Tue, 23 May 2006 19:07:27 -0400
Subject: [netrek-dev] patch postings to this list
In-Reply-To: <20060523222010.GC4911@us.netrek.org>
	<Pine.GSO.4.58.0605231144300.121@clyde>
References: <20060523171505.GA6855@orion.netrek.org>
	<20060523222010.GC4911@us.netrek.org>
	<20060523171505.GA6855@orion.netrek.org>
	<Pine.GSO.4.58.0605231144300.121@clyde>
Message-ID: <20060523230727.GA7596@orion.netrek.org>

On Tue, May 23, 2006 at 11:47:10AM -0700, William Balcerski wrote:
> I would propose having all patches go to the same list for both CVS and
> darcs, maybe rename netrek-CVS to netrek-patches.  Keep netrek-dev low
> traffic, for design issues or approval of potentinally controversial
> patches only.  And redefine the currently unused netrek mailing list as
> for players, clue game announcements, etc.  Change mailman.us.netrek.org
> to reflect that, and advertise on rgn and server MOTDs.

I think we set up netrek at us.netrek.org specifically to replace all the
various user/player lists.  It's just that most people don't seem to be
using that list.  I wouldn't mind seeing the darcs patches go to
netrek-cvs, but James has a good point about keeping developers in the
loop on netrek-dev.  There is always the digest subscription mode.

On Wed, May 24, 2006 at 08:20:10AM +1000, James Cameron wrote:
> 
> I'd like to do so, yes.  It keeps developers in the loop.  I expect all
> developers to review the patches.  I think we are getting code reviews
> faster than if we'd posted to the netrek-cvs list, whose membership is
> unknown to me.  I'd like a netrek-announce list for anyone who can't
> afford the cost of seeing the patches on netrek-dev, but perhaps the
> bare netrek list is sufficient.

I do think the base netrek@ list is sufficient and a netrek-announce is
unnecessary; the netrek-announce we had on SF never got used.



From xyzzy at speakeasy.org  Tue May 23 17:53:36 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 15:53:36 -0700 (PDT)
Subject: [netrek-dev] darcs patches too big
Message-ID: <Pine.LNX.4.58.0605231544490.28433@shell3.speakeasy.net>

I made a patch to resolve the conflicts that appear with my bundle of bot
fixes and other patches since applied to the repository.  But darcs won't let
me send it, unless I also send all my other patches.  This is too big for the
list attachment limit.

I'm still waiting for the epiphany when I figure out how darcs turns the pile
of patches into a repository revision tree.  So far, I am finding darcs
branching and merging to be incomprehensible.  I like Mercurial better.

The manual modification of the changelog for each patch is getting really
really annoying.


From xyzzy at speakeasy.org  Tue May 23 18:32:09 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 16:32:09 -0700 (PDT)
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <20060523232142.GH4911@us.netrek.org>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
	<ecfa260c0605231107p41075599g4d637ddb755a37a9@mail.gmail.com>
	<20060523232142.GH4911@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605231631260.28433@shell3.speakeasy.net>

On Wed, 24 May 2006, James Cameron wrote:

> On Tue, May 23, 2006 at 06:07:18PM +0000, Zach wrote:
> > GNU ranlib 2.16.91 20060413 Debian GNU/Linux
> > gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> > GNU ar 2.16.91 20060413 Debian GNU/Linux
>
> Those versions all look fine.  Follow the steps in tests/build.

Or just edit the makefile by hand, and replace @RANLIB@ with ranlib and
delete @RANLIBFLAGS@ on the next line.


From quozl at us.netrek.org  Tue May 23 19:17:31 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 10:17:31 +1000
Subject: [netrek-dev] darcs patches too big
In-Reply-To: <Pine.LNX.4.58.0605231544490.28433@shell3.speakeasy.net>
References: <Pine.LNX.4.58.0605231544490.28433@shell3.speakeasy.net>
Message-ID: <20060524001731.GJ4911@us.netrek.org>

On Tue, May 23, 2006 at 03:53:36PM -0700, Trent Piepho wrote:
> I made a patch to resolve the conflicts that appear with my bundle of bot
> fixes and other patches since applied to the repository.  But darcs won't let
> me send it, unless I also send all my other patches.  This is too big for the
> list attachment limit.

Hmm.  You can send it straight to me, or quozl at hwy dot com dot au if
my usual address bounces.

If you have an HTTP accessible hosting location, put your repository
there and just give us the pointer.  Then we can pull from it.

> The manual modification of the changelog for each patch is getting really
> really annoying.

Make separate "darcs record" for the ChangeLog and NEWS patches.  This
applies until end of the month.  After that, no more changing of those
files.

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


From quozl at us.netrek.org  Tue May 23 19:52:00 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Wed, 24 May 2006 10:52:00 +1000
Subject: [netrek-dev] darcs patch: robotd mfprintf regression fix
Message-ID: <E1FihbU-0002km-9m@dors.lan>

Wed May 24 10:47:52 EST 2006  quozl at us.netrek.org
  * robotd mfprintf regression fix
  
  	* robotd/util.c (mfprintf): fix a regression caused by conversion
  	  to stdargs done on Fri Oct 31 09:15:42 2003.
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 12758 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060524/79232585/attachment.bin 

From xyzzy at speakeasy.org  Tue May 23 19:58:52 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 17:58:52 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
Message-ID: <Pine.LNX.4.58.0605231749210.26256@shell3.speakeasy.net>

This should fix everything, the problem of bots not getting their shields
sent correctly and problems with shields while observing.  Includes a
change to not send the flags of observers to other players, except for
the PFOBSERV flag.  Should also fix difficult to notice problems with
bases' shields appearing to lower when they toggle docking or shields
getting lowered and players uncloaking after a full update.  Might also
fix a longstanding problem with cow-lite, not that anyone uses that
client anymore.

I'm including the patch, less changelog entry.  For the changelog, I'm
attaching a normal diff, since darcs wants to send every patch I've made
with that one.
-------------- next part --------------

New patches:

[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
<
> {
hunk ./Vanilla/ntserv/genspkt.c 154
 u_char clientVKills[MAXPLAYER*2+2 +4];
 int clientVKillsCount;
 struct stats_s_spacket singleStats;
-unsigned char n_flags[MAXPLAYER]; 
-int highest_active_player;
+static unsigned char n_flags[MAXPLAYER];
+static int highest_active_player;
 
 #if MAXPLAYER > 32
 static u_char	clientVXPlayers[33*4];
hunk ./Vanilla/ntserv/genspkt.c 303
 
 }
 
+/* This function is for sending the flags of OTHER players, the player's
+   own flags are handled elsewhere.  The cambot will set f_many_self,
+   and use this function to record the flags of all players.  */
 int sndFlags( struct flags_spacket *flags, struct player *pl, int howmuch)
 {
 /*#define FLAGMASK (PFSHIELD|PFBOMB|PFORBIT|PFCLOAK|PFROBOT|PFBEAMUP|PFBEAMDOWN|PFPRACTR|PFDOCK|PFTRACT|PFPRESS|PFDOCKOK) aieee, too much.  7/27/91 TC */ 
hunk ./Vanilla/ntserv/genspkt.c 320
     int tractor = ((F_show_all_tractors || f_many_self) && pl->p_flags&PFTRACT)?
                       (pl->p_tractor|0x40):0;
 
+#ifdef OBSERVERS
+    if (!f_many_self && pl->p_status == POBSERV) {
+    	mask = PFOBSERV;	/* All we need to know about observers. */
+	tractor = 0;
+    } else
+#endif
     if (howmuch == UPDT_ALL) {
 	mask = FLAGMASK;
 	if(F_show_all_tractors || f_many_self) mask |= PFTRACT|PFPRESS;
hunk ./Vanilla/ntserv/genspkt.c 331
     } else
 	mask = INVISOMASK;
-	
-    /* With short packets 2 flag sampling, these don't need to be sent */
-    if (!(pl->p_flags & PFROBOT)) {
-        if (send_short > 1 && pl->p_no < 32)
-            mask &= ~(PFSHIELD|PFCLOAK);
-    }
-
 
     if ((ntohl(flags->flags)&mask) == (pl->p_flags&mask) &&
         flags->tractor==tractor)
hunk ./Vanilla/ntserv/genspkt.c 1176
 	sndPlayerInfo(cpli, pl);
 	sndKills(kills, pl);
 
+	/* S_P2 new flag sampling */
+	if (send_short > 1) {
+	    u_int oldflags;
 #ifdef OBSERVERS
hunk ./Vanilla/ntserv/genspkt.c 1180
-	if(pl->p_status != POBSERV){
+	    /* Skip observers' flags, unless I am the observer. */
+	    if (pl->p_status != POBSERV || pl == me) {
 #endif
hunk ./Vanilla/ntserv/genspkt.c 1183
-	    /* S_P2 new flag sampling */
-	    if(!(pl->p_flags & PFROBOT)) { /* No robos please */
 		switch(pl->p_status){
 		case PALIVE: /* huh, we must work */
 		    highest_active_player = i;
hunk ./Vanilla/ntserv/genspkt.c 1188
 		    if(pl->p_flags & PFCLOAK){
 			n_flags[i] = 1;
-			break;
 		    }
 		    else if(pl->p_flags & PFSHIELD){
 			n_flags[i] = 2;
hunk ./Vanilla/ntserv/genspkt.c 1206
 		    /* Is it ok to send the old value ? */
 		    break;
 		}
-	    } /* robos out */ 
+		/* Mark shield and cloak as updated, so they won't be resent
+		   again with a flags packet. */
+		oldflags = ntohl(flags->flags);
+		oldflags &= ~(PFSHIELD|PFCLOAK);
+		oldflags |= pl->p_flags&(PFSHIELD|PFCLOAK);
+		flags->flags = htonl(oldflags);
 #ifdef OBSERVERS
hunk ./Vanilla/ntserv/genspkt.c 1213
-	}
+	    }
 #endif
hunk ./Vanilla/ntserv/genspkt.c 1215
+	}
 
 	if (sndPStatus(pstatus, pl)) {
 	    update=1;
}

Context:

[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
fd26f79b69cea82936a7735bb9e22e9452f6d8c7
-------------- next part --------------
Tue May 23 17:44:09 PDT 2006  Trent Piepho <xyzzy at speakeasy.org>
  * fix SP_2 flag sending for real changelog
--- old-netrek-server/Vanilla/ChangeLog	2006-05-23 17:45:36.000000000 -0700
+++ new-netrek-server/Vanilla/ChangeLog	2006-05-23 17:45:36.000000000 -0700
@@ -1,3 +1,13 @@
+Tue May 23 17:21:56 2006  Trent Piepho <xyzzy at speakeasy.org>
+	* ntserv/genspkt.c Fix SP_2 flags, for real.  The sndFlags
+	function will not send flags of observers (except for PFOBSERV of
+	course).  The SP_2 flag sampling code will sample the flags of
+	robots now.  It will not sample observers' flags, except for an
+	observer's own flags.  The SP_2 sampling code will update the
+	last sent flags data, so shield/cloak are not sent again via
+	sndFlags().  When sndFlags() does send flags, it will send the
+	correct shield/cloak and not zero.
+
 Tue May 23 04:06:08 2006  Trent Piepho <xyzzy at speakeasy.org>
 	* ntserv/genspkt.c Hadley's bot expects to get torp direction
 	from the server, but the server only sends it for your own torps.


From quozl at us.netrek.org  Mon May 22 20:29:02 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 11:29:02 +1000
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>
References: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <20060523012902.GG7001@us.netrek.org>

You were just plain calling it wrong.

The arguments in the function declaration were not matching the
arguments you were passing.  The lack of prototypes is a cause.

Try the attached patch against util.c, it changes mfprintf to adopt the
argument list format used by the references elsewhere.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
--- old-netrek-server/Vanilla/robotd/util.c	2006-05-23 11:27:12.000000000 +1000
+++ new-netrek-server/Vanilla/robotd/util.c	2006-05-23 11:27:12.000000000 +1000
@@ -442,21 +442,15 @@
 }
 #endif
 
-/* This function causes a SIGSEV, dunno why JKH */
-/* replacing it with a straight fprintf which */
-/* accomplishes the same thing */
-mfprintf(char *format, ...)
+mfprintf(FILE *fo, char *format, ...)
 {
-   FILE	*fo;
    va_list	ap;
    
    if(!read_stdin)
       return;
    
    va_start(ap, format);
-   fo = va_arg(ap, FILE *);
    (void)vfprintf(fo, format, ap);
-   fflush(stdout);
+   fflush(fo);
    va_end(ap);
 }
-


From quozl at us.netrek.org  Mon May 22 20:23:10 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 11:23:10 +1000
Subject: [netrek-dev] robotd-indent-fix.dpatch
In-Reply-To: <20060523001554.32786.qmail@web35314.mail.mud.yahoo.com>
References: <20060523001554.32786.qmail@web35314.mail.mud.yahoo.com>
Message-ID: <20060523012310.GF7001@us.netrek.org>

On Mon, May 22, 2006 at 05:15:54PM -0700, Jimmy Huang wrote:
> indent fixes for robotd. 3 spaces instead of 4 spaces
> for the code I changed. 

Taken.  Thanks.

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


From quozl at us.netrek.org  Tue May 23 19:55:49 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 10:55:49 +1000
Subject: [netrek-dev] updated INSTALL.Newbie
In-Reply-To: <20060523150529.95923.qmail@web35308.mail.mud.yahoo.com>
References: <20060523150529.95923.qmail@web35308.mail.mud.yahoo.com>
Message-ID: <20060524005549.GK4911@us.netrek.org>

On Tue, May 23, 2006 at 08:05:29AM -0700, Jimmy Huang wrote:
> Here's the updated INSTALL.Newbie, as I just realized,
> Merlin won't work properly unless TOURN=4. 

Taken, thanks.

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


From quozl at us.netrek.org  Mon May 22 23:18:19 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 May 2006 14:18:19 +1000
Subject: [netrek-dev] Changing the changelog
In-Reply-To: <Pine.LNX.4.58.0605222101120.11796@shell2.speakeasy.net>
References: <20060522232145.13570.qmail@web35313.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605222101120.11796@shell2.speakeasy.net>
Message-ID: <20060523041819.GJ7001@us.netrek.org>

On Mon, May 22, 2006 at 09:04:45PM -0700, Trent Piepho wrote:
> I'm surprised no one who should know better has said
> anything, the bug is obvious.

It's 'cause I didn't look at it until today.  ;-)

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


From quozl at us.netrek.org  Tue May 23 20:10:19 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 11:10:19 +1000
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060523012902.GG7001@us.netrek.org>
References: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>
	<20060523012902.GG7001@us.netrek.org>
Message-ID: <20060524011019.GM4911@us.netrek.org>

On Tue, May 23, 2006 at 11:29:02AM +1000, James Cameron wrote:
> Try the attached patch against util.c, it changes mfprintf to adopt the
> argument list format used by the references elsewhere.

I've placed this patch in my darcs repo.
I didn't see any feedback.

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


From quozl at us.netrek.org  Tue May 23 17:14:40 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 08:14:40 +1000
Subject: [netrek-dev] Problem with res-rsa configure and gmp
In-Reply-To: <20060523172114.GA6881@orion.netrek.org>
References: <Pine.LNX.4.58.0605221335250.4835@shell2.speakeasy.net>
	<20060522233101.GC7001@us.netrek.org>
	<20060523172114.GA6881@orion.netrek.org>
Message-ID: <20060523221440.GA4911@us.netrek.org>

On Tue, May 23, 2006 at 01:21:14PM -0400, Dave Ahn wrote:
> Sorry for being out of the loop, but have you guys been releasing
> RES-RSA as part of the Vanilla Server package?  I just noticed that
> the RES-RSA source code is in the darcs repository.  There are some US
> export regulations that cover RES-RSA.

In all cases the release is done in Australia first.  You said
previously that this was sufficient.  This is noted in the release
process.

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


From netrek at gmail.com  Tue May 23 20:58:40 2006
From: netrek at gmail.com (Zach)
Date: Wed, 24 May 2006 01:58:40 +0000
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <Pine.LNX.4.58.0605231631260.28433@shell3.speakeasy.net>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
	<ecfa260c0605231107p41075599g4d637ddb755a37a9@mail.gmail.com>
	<20060523232142.GH4911@us.netrek.org>
	<Pine.LNX.4.58.0605231631260.28433@shell3.speakeasy.net>
Message-ID: <ecfa260c0605231858m75e837adk73a5dd84fa3284fc@mail.gmail.com>

On 5/23/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
>
> Or just edit the makefile by hand, and replace @RANLIB@ with ranlib and
> delete @RANLIBFLAGS@ on the next line.

Ok thanks. It seems the build process has changed but this was not
documented. People who download the src will check INSTALL and expect
the directions there to be complete and valid.

Zach


From quozl at us.netrek.org  Tue May 23 21:43:49 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 12:43:49 +1000
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.LNX.4.58.0605231749210.26256@shell3.speakeasy.net>
References: <Pine.LNX.4.58.0605231749210.26256@shell3.speakeasy.net>
Message-ID: <20060524024349.GO4911@us.netrek.org>

Taken, pushed.  Thanks.

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


From xyzzy at speakeasy.org  Tue May 23 22:14:02 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 23 May 2006 20:14:02 -0700 (PDT)
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060524011019.GM4911@us.netrek.org>
References: <20060523003830.46313.qmail@web35313.mail.mud.yahoo.com>
	<20060523012902.GG7001@us.netrek.org>
	<20060524011019.GM4911@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605232007430.1385@shell2.speakeasy.net>

On Wed, 24 May 2006, James Cameron wrote:
> On Tue, May 23, 2006 at 11:29:02AM +1000, James Cameron wrote:
> > Try the attached patch against util.c, it changes mfprintf to adopt the
> > argument list format used by the references elsewhere.
>
> I've placed this patch in my darcs repo.
> I didn't see any feedback.

I had already fixed this when I got that message, in was in my bundle
of robot fixes.

Mon May 22 15:39:35 2006  Trent Piepho <xyzzy at speakeasy.org>
        * robotd/util.c When mfprintf() was change from varargs to stdarg,
        it wasn't done correctly.  Fix this.

Or did you send this message I while ago?  It feels like I'm getting the
mailling list out of order.


From quozl at us.netrek.org  Tue May 23 20:11:43 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 11:11:43 +1000
Subject: [netrek-dev] robotd _udcounter patch
In-Reply-To: <20060523135433.60147.qmail@web35314.mail.mud.yahoo.com>
References: <20060523135433.60147.qmail@web35314.mail.mud.yahoo.com>
Message-ID: <20060524011143.GN4911@us.netrek.org>

Taken, thanks.

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


From quozl at us.netrek.org  Tue May 23 20:06:45 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 11:06:45 +1000
Subject: [netrek-dev] newbie-fixes.dpatch
In-Reply-To: <20060523144437.76998.qmail@web35303.mail.mud.yahoo.com>
References: <20060523144437.76998.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <20060524010645.GL4911@us.netrek.org>

On Tue, May 23, 2006 at 07:44:37AM -0700, Jimmy Huang wrote:
> darcs won't let me send the newbie fixes, unless I
> also send the robotd-udcounter patch along with it. 
> Probably because I changed the changelog twice!

Yes.  As I said before, until the end of the month try to record your
ChangeLog and NEWS entries in a different patch.  This will help with
merging them.  After the end of the month, we don't want ChangeLog and
NEWS files changed by patches, unless you're the release engineer.

> P.S. Hey James, here are the fixes you are waiting
> for! 

Taken, thanks.

"newbie-fixes.dpatch changelog conflict resolution" pushed to 
http://james.tooraweenah.com/darcs/netrek-server/ suggest you pull.

> I think for now, I'll just change the INSTALL.newbie
> file to make sure that the person running the newbie
> server knows he needs a t-mode setting of 4 and not
> anything else. 

Saw that.  Perhaps it would be better to prepare the sysdef and other
files for a newbie server ahead of time, so that the installation
instructions need only say "use this file" or "use this make target".

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


From quozl at us.netrek.org  Tue May 23 22:49:34 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 13:49:34 +1000
Subject: [netrek-dev] Vanilla compile fatal error
In-Reply-To: <ecfa260c0605231858m75e837adk73a5dd84fa3284fc@mail.gmail.com>
References: <ecfa260c0605231049s2c09e2deoce6f2eb88a66ce62@mail.gmail.com>
	<ecfa260c0605231107p41075599g4d637ddb755a37a9@mail.gmail.com>
	<20060523232142.GH4911@us.netrek.org>
	<Pine.LNX.4.58.0605231631260.28433@shell3.speakeasy.net>
	<ecfa260c0605231858m75e837adk73a5dd84fa3284fc@mail.gmail.com>
Message-ID: <20060524034934.GP4911@us.netrek.org>

On Wed, May 24, 2006 at 01:58:40AM +0000, Zach wrote:
> Ok thanks. It seems the build process has changed but this was not
> documented. People who download the src will check INSTALL and expect
> the directions there to be complete and valid.

Wrong.  It was documented.  You didn't read it.

INSTALL pertains to source downloads using .tar.gz, or source that has
been autogen'd.

README.darcs points to autogen.sh if you've used darcs to obtain the
source.

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


From stephen.thorne at gmail.com  Wed May 24 01:04:00 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 24 May 2006 16:04:00 +1000
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
Message-ID: <3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>

On 5/23/06, Stas Pirogov <keyos at keyos.org> wrote:
> Attached is patch to fix test for 'ranlib -c' that didn't
> work on Solaris. Hopefully this one will work on any sh
> interpreter.

Thanks for the patch, but it fails to apply, Can you check the md5sum?
8da52ebce2725b4056a4e56a657b8a65 is what I get...

Can you check that ranlib on solaris has the same (broken) behaviour
as gnu ranlib? gnu ranlib will exit with an exit code of 0 if you pass
it -c. Can you check that solaris ranlib does so too?

> As pretty fresh darcs user I also didn't find any good way
> to find who created this regression. I had to zcat all files
> under patches directory to actually find that Quozl is the man :)
> Is there good way to get version diff (i.e. something like cvs diff -r 1.1
> filename) ?

darcs annotate has a really annoying output. but it shows you who
wrote every line.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Wed May 24 02:58:33 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 24 May 2006 00:58:33 -0700 (PDT)
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060524011019.GM4911@us.netrek.org>
Message-ID: <20060524075833.49861.qmail@web35310.mail.mud.yahoo.com>

Hi James, 

Although I don't understand how to use this
function...  I went ahead and replaced every instance
of mprintf with mfprintf(sterr,"foo\n");

Ran the program through a debugger, and robotd has
been running fine for about an hour now. Things print
out on the screen just fine. 

In other news, the workload at work has been getting
hectic and things are breaking left and right. So you
may suddenly not hear from me.  And it may mean I will
disappear for a couple of weeks (at least from
developing code). 

Jimmy


--- James Cameron <quozl at us.netrek.org> wrote:

> On Tue, May 23, 2006 at 11:29:02AM +1000, James
> Cameron wrote:
> > Try the attached patch against util.c, it changes
> mfprintf to adopt the
> > argument list format used by the references
> elsewhere.
> 
> I've placed this patch in my darcs repo.
> I didn't see any feedback.
> 
> -- 
> James Cameron    mailto:quozl at us.netrek.org    
> http://quozl.netrek.org/
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From quozl at us.netrek.org  Wed May 24 03:31:51 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 18:31:51 +1000
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060524075833.49861.qmail@web35310.mail.mud.yahoo.com>
References: <20060524011019.GM4911@us.netrek.org>
	<20060524075833.49861.qmail@web35310.mail.mud.yahoo.com>
Message-ID: <20060524083151.GU4911@us.netrek.org>

On Wed, May 24, 2006 at 12:58:33AM -0700, Jimmy Huang wrote:
> Although I don't understand how to use this
> function...  I went ahead and replaced every instance
> of mprintf with mfprintf(sterr,"foo\n");

But why?

mprintf is for reporting messages to stdout, which is buffered, and is
expected to contain diagnostic output if any.

mfprintf is for reporting messages to stderr, which is not buffered, and
is expected to contain errors or other failures.

The deliberate difference seems useful.  Making it all the same just
eliminates that useful difference.

> Ran the program through a debugger, and robotd has
> been running fine for about an hour now. Things print
> out on the screen just fine. 

Wouldn't this break any scripts that are watching stdout?  Why do it?

> In other news, the workload at work has been getting
> hectic and things are breaking left and right. So you
> may suddenly not hear from me.  And it may mean I will
> disappear for a couple of weeks (at least from
> developing code). 

No worries, I know how it goes.  I get the same thing happening.  It
*will* give us a chance to settle the code and do some testing.  ;-)

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


From williamb at its.caltech.edu  Wed May 24 03:11:12 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Wed, 24 May 2006 03:11:12 -0500
Subject: [netrek-dev] darcs patch: Player position sign fix
Message-ID: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>

Wed May 24 03:09:01 CDT 2006  williamb at its.caltech.edu
  * Player position sign fix
  * genspkt.c: With short packets on, positions in the negative (i.e. on player
  death) were being reported incorrectly. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 16330 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060524/c91585f6/attachment-0001.bin 

From stephen.thorne at gmail.com  Wed May 24 03:51:40 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 24 May 2006 18:51:40 +1000
Subject: [netrek-dev] darcs patch: Player position sign fix
In-Reply-To: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
References: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
Message-ID: <3e8ca5c80605240151y35067316nccc44a53b2ec9c47@mail.gmail.com>

On 5/24/06, williamb at its.caltech.edu <williamb at its.caltech.edu> wrote:
> Wed May 24 03:09:01 CDT 2006  williamb at its.caltech.edu
>   * Player position sign fix
>   * genspkt.c: With short packets on, positions in the negative (i.e. on player
>   death) were being reported incorrectly.

Taken.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From netrek at gmail.com  Wed May 24 04:14:53 2006
From: netrek at gmail.com (Zach)
Date: Wed, 24 May 2006 09:14:53 +0000
Subject: [netrek-dev] cow package won't display metaserver data
Message-ID: <ecfa260c0605240214p5634356aw541b11fe38377f62@mail.gmail.com>

I installed CoW from ftp.real-time.com's repository:
netrek-client-cow_3.2.0-1etch1_i386.deb

When it runs the metaserver window comes up but no hosts are listed it says:

Server (all rows blank), Status (all rows say "OPEN 0"), Type (all
rows say "Unknown"), Age (all rows say "0s")

When I click on Quit it says "CANNOT CONNECT" and I have to xkill the window.

However I'm able to connect directly to a host by using the '"-h" flag.

I have attached an strace log and below are some feable debugging attempts :)

zu22 at netrek:~$ ldd /usr/bin/netrek-client-cow
        libmp.so.3 => /usr/lib/libmp.so.3 (0x40021000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40037000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40068000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40134000)
        libm.so.6 => /lib/libm.so.6 (0x4014a000)
        libc.so.6 => /lib/libc.so.6 (0x40170000)
        libdl.so.2 => /lib/libdl.so.2 (0x40292000)
        /lib/ld-linux.so.2 (0x40000000)
zu22 at netrek:~$ locate libmp.so.3 libgmp.so.3 libX11.so.6 libnsl.so.1
libm.so.6 libc.so.6  libdl.so.2
/lib/libc.so.6
/lib/libdl.so.2
/lib/libm.so.6
/lib/libnsl.so.1
/lib/tls/libc.so.6
/lib/tls/libdl.so.2
/lib/tls/libm.so.6
/lib/tls/libnsl.so.1
/usr/lib/libgmp.so.3
/usr/lib/libgmp.so.3.3.3
/usr/lib/libmp.so.3
/usr/lib/libmp.so.3.1.7
/usr/X11R6/lib/libX11.so.6
/usr/X11R6/lib/libX11.so.6.2

I tried running GDB but the client was not built with debugging symbols it says:
zu22 at netrek:~$ gdb netrek-client-cow
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/netrek-client-cow
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Reading defaults file .xtrekrc
No server name was given.  Connecting to metaserver.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Attempting to connect to  on port 0...
Cannot connect to !

Program received signal SIGINT, Interrupt.
0x402290b2 in select () from /lib/libc.so.6
(gdb) bt
#0  0x402290b2 in select () from /lib/libc.so.6
#1  0x00000007 in ?? ()
#2  0xbffff090 in ?? ()
#3  0xbffff110 in ?? ()
#4  0x08085c60 in ?? ()
#5  0x00000400 in ?? ()
#6  0xbffff090 in ?? ()
#7  0x00000000 in ?? ()
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Zach
-------------- next part --------------
execve("/usr/bin/netrek-client-cow", ["netrek-client-cow"], [/* 22 vars */]) uname({sys="Linux", node="netrek", ...}) brk(0)                                  access("/etc/ld.so.nohwcap", F_OK)      mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) access("/etc/ld.so.preload", R_OK)      open("/etc/ld.so.cache", O_RDONLY)      fstat64(3, {st_mode=S_IFREG|0644, st_size4106, ...}) mmap2(NULL, 34106, PROT_READ, MAP_PRIVATE, 3, 0) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/usr/lib/libmp.so.3", O_RDONLY)   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\36\0\000"..., 512) fstat64(3, {st_mode=S_IFREG|0644, st_size?180, ...}) mmap2(NULL, 87200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x40036000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) mprotect(0xbfffc000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC) mprotect(0xbfffe000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) mprotect(0xbfffe000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/usr/lib/libgmp.so.3", O_RDONLY)  read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 at V\0\000"..., 512) fstat64(3, {st_mode=S_IFREG|0644, st_size5316, ...}) mmap2(NULL, 198304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x40067000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2f) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\24"..., 512) fstat64(3, {st_mode=S_IFREG|0644, st_size?6224, ...}) mmap2(NULL, 830360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x4012f000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc6) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/lib/libnsl.so.1", O_RDONLY)      read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3405\0"..., 512) fstat64(3, {st_mode=S_IFREG|0644, st_sizev792, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) mmap2(NULL, 88096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x40146000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) mmap2(0x40148000, 6176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/lib/libm.so.6", O_RDONLY)        read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P3\0\000"..., 512) fstat64(3, {st_mode=S_IFREG|0644, st_size9264, ...}) mmap2(NULL, 151712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x4016e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/lib/libc.so.6", O_RDONLY)        read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220T\1"..., 512) fstat64(3, {st_mode=S_IFREG|0755, st_size77116, ...}) mmap2(NULL, 1186964, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x40288000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x117) mmap2(0x40290000, 7316, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) close(3)                                access("/etc/ld.so.nohwcap", F_OK)      open("/lib/libdl.so.2", O_RDONLY)       read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0"..., 512) fstat64(3, {st_mode=S_IFREG|0644, st_size?92, ...}) mmap2(NULL, 12404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) mmap2(0x40294000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) close(3)                                mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) mprotect(0x40288000, 20480, PROT_READ)  munmap(0x40018000, 34106)               rt_sigaction(SIGFPE, {0x8063990, [FPE], SA_RESTORER|SA_RESTART, 0x401994c8}, {SIG_DFL}, 8) time(NULL)                              access(".netrekrc", R_OK)               access("/home/zu22/.netrekrc", R_OK)    access(".xtrekrc", R_OK)                brk(0)                                  brk(0x80e4e44)                          brk(0x80e5000)                          open(".xtrekrc", O_RDONLY)              fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) write(1, "Reading defaults file .xtrekrc\n", 31) fstat64(3, {st_mode=S_IFREG|0644, st_size?38, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(3, "#-------------------------------"..., 4096) read(3, "   _    ____   ___  _   _  ____ "..., 4096) read(3, " $tap@, CARRYING %?%a>0%{%a%!NO%"..., 4096) read(3, "", 4096)                       close(3)                                munmap(0x40019000, 4096)                getpid()                                time(NULL)                              write(1, "No server name was given.  Conne"..., 53) socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) bind(3, {sa_family?_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) sendto(3, "?", 1, 0, {sa_family?_INET, sin_port=htons(3521), sin_addr=inet_addr("224.0.0.1")}, 16) gettimeofday({1148447181, 332966}, NULL) getpid()                                open("/etc/resolv.conf", O_RDONLY)      fstat64(4, {st_mode=S_IFREG|0644, st_sizes, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(4, "# resolv.conf created by pppconf"..., 4096) read(4, "", 4096)                       close(4)                                munmap(0x40019000, 4096)                uname({sys="Linux", node="netrek", ...}) socket(PF_FILE, SOCK_STREAM, 0)         fcntl64(4, F_GETFL)                     fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  connect(4, {sa_family?_FILE, path="/var/run/nscd/socket"}, 110) poll([{fd=4, events=POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 5000) writev(4, [{"\2\0\0\0\r\0\0\0\6\0\0\0", 12}, {"hosts\0", 6}], 2) poll([{fd=4, events=POLLIN|POLLERR|POLLHUP, revents=POLLIN|POLLHUP}], 1, 5000) recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"hosts\0", 6}], msg_controllen, {cmsg_len, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {5}}, msg_flags=0}, MSG_NOSIGNAL) fstat64(5, {st_mode=S_IFREG|0600, st_size!7016, ...}) pread64(5, "\1\0\0\0h\0\0\0V\0\0\0\0\0\0\0\215\nsD\0\0\0\0\323\0\0"..., 104, 0) time(NULL)                              close(5)                                close(4)                                socket(PF_FILE, SOCK_STREAM, 0)         fcntl64(4, F_GETFL)                     fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  connect(4, {sa_family?_FILE, path="/var/run/nscd/socket"}, 110) poll([{fd=4, events=POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 5000) writev(4, [{"\2\0\0\0\4\0\0\0\31\0\0\0", 12}, {"metaserver.eu.netrek.org\0", 25}], 2) poll([{fd=4, events=POLLIN|POLLERR|POLLHUP, revents=POLLIN|POLLHUP}], 1, 5000) read(4, "\2\0\0\0\1\0\0\0\31\0\0\0\0\0\0\0\2\0\0\0\4\0\0\0\2\0\0"..., 32) readv(4, [{"metaserver.eu.netrek.org\0", 25}, {"A\301\21\360\320\24\312*", 8}], 2) read(4, NULL, 0)                        close(4)                                sendto(3, "?", 1, 0, {sa_family?_INET, sin_port=htons(3521), sin_addr=inet_addr("65.193.17.240")}, 16) sendto(3, "?", 1, 0, {sa_family?_INET, sin_port=htons(3521), sin_addr=inet_addr("208.20.202.42")}, 16) select(1024, [3], NULL, NULL, {4, 0})   recvfrom(3, "r,15\nkirk.hal-pc.org,2592,6,1204"..., 2048, 0, {sa_family?_INET, sin_port=htons(3521), sin_addr=inet_addr("65.193.17.240")}, [16]) time(NULL)                              uname({sys="Linux", node="netrek", ...}) socket(PF_FILE, SOCK_STREAM, 0)         getrlimit(RLIMIT_NOFILE, {rlim_cur24, rlim_max24}) uname({sys="Linux", node="netrek", ...}) uname({sys="Linux", node="netrek", ...}) connect(4, {sa_family?_FILE, path="/tmp/.X11-unix/X0"}, 19) uname({sys="Linux", node="netrek", ...}) fcntl64(4, F_SETFD, FD_CLOEXEC)         access("/home/zu22/.Xauthority", R_OK)  open("/home/zu22/.Xauthority", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0600, st_size91, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "\1\0\0\6netrek\0\0010\0\22MIT-MAGIC-COOKIE-"..., 4096) read(5, "", 4096)                       close(5)                                munmap(0x40019000, 4096)                gettimeofday({1148447181, 810164}, NULL) getpid()                                time([1148447181])                      writev(4, [{"l\0\v\0\0\0\23\0\30\0\0\0", 12}, {"XDM-AUTHORIZATION-1", 19}, {"\0", 1}, {"\267\315;+\212\"N\325\240\313\332\30\2702\356=\210p\4\306"..., 24}], 4) fcntl64(4, F_GETFL)                     fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  read(4, "\1\0\v\0\0\0L\0", 8)           read(4, "\341\355f\2\0\0\300\1\377\377\37\0\0\1\0\0\30\0\377\377"..., 304) write(4, "7\0\5\0\0\0\300\1:\0\0\0\10\0\0\0\377\377\377\0b\0\5\0"..., 64) read(4, "\1\0\2\0\0\0\0\0\1\202\0\0\0\0\0\0\0\0\0\0\24\0\0\0\350"..., 32) read(4, "\1\10\3\0#\0\0\0\37\0\0\0\0\0\0\0\212\0\0\0\0\0\0\0\0\0"..., 32) readv(4, [{"*customization:\t-color\nXLock*log"..., 138}, {"\377\0", 2}], 2) write(4, "\202\0\1\0", 4)               read(4, "\1\0\4\0\0\0\0\0\377\377\17\0\0\0\0\0\1\0\0\0\24\0\0\0"..., 32) writev(4, [{"b\0\5\0\t\0\300\1", 8}, {"XKEYBOARD", 9}, {"\0\0\0", 3}], 3) read(4, "\1\0\5\0\0\0\0\0\1\225n\257\0\0\0\0\1\0\0\0\24\0\0\0\350"..., 32) write(4, "\225\0\2\0\1\0\0\0", 8)       read(4, "\1\1\6\0\0\0\0\0\1\0\0\0\0\0\0\0\1\0\0\0\24\0\0\0\350p"..., 32) writev(4, [{"b\0\6\0\17\0\0\0", 8}, {"XFree86-Bigfont", 15}, {"\0", 1}], 3) read(4, "\1\0\7\0\0\0\0\0\1\231\0\0\0\0\0\0\1\0\0\0\24\0\0\0\350"..., 32) write(4, "\231\0\1\0", 4)               read(4, "\1\1\10\0\0\0\0\0\1\0\1\0\0\0\0\0\0\0\0\0\3\37o\326\350"..., 32) write(4, "-\0\4\0\1\0\300\1\4\0\0\0006x10\231\1\3\0\1\0\300\1\1\0"..., 28) read(4, "\1\0\n\0[\1\0\0\0\0\0\0\6\0\377\377\371\377\0\0\t\0\0\0"..., 32) read(4, "\2\0\0\0\0\0\t\0\0\0\377\0\0\0\26\0\0\0\0\0\10\0\2\0\0"..., 40) read(4, "\305\0\0\0\306\0\0\0\261\0\0\0\307\0\0\0@\0\0\0\310\0\0"..., 176) read(4, "\0\0\5\0\6\0\7\0\0\0\0\0\0\0\5\0\6\0\6\0\377\377\0\0\0"..., 1172) open("/usr/X11R6/lib/X11/locale/locale.alias", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0644, st_sizeu128, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "#\t$XdotOrg: xc/nls/locale.alias,"..., 4096) read(5, "14\t\t\t\tbr_FR.ISO8859-14\nbr_FR.ISO"..., 4096) read(5, "\nen.ISO-8859-1\t\t\t\t\ten_US.ISO8859"..., 4096) read(5, "9-1\t\t\t\tes_ES.ISO8859-1\nes_ES.iso"..., 4096) read(5, "r_CA.iso885915\t\t\t\tfr_CA.ISO8859-"..., 4096) read(5, "t_IT.88591.en\t\t\t\t\tit_IT.ISO8859-"..., 4096) read(5, "59-15\nnl_BE.ISO-8859-15 at euro\t\t\t\t"..., 4096) read(5, "ET.UTF-8\nsk\t\t\t\t\t\tsk_SK.ISO8859-2"..., 4096) read(5, "\t\t\t\twa_BE.ISO8859-1\nwa_BE\t\t\t\t\t\tw"..., 4096) read(5, "s locale names\nISO8859-1\t\t\t\t\ten_"..., 4096) read(5, "_BG.koi8r:\t\t\t\t\tbg_BG.KOI8-R\nbe_B"..., 4096) read(5, "TF-8\nGER_DE.8859:\t\t\t\t\tde_DE.ISO8"..., 4096) read(5, "ISO-8859-1:\t\t\t\tes_CR.ISO8859-1\ne"..., 4096) read(5, "F-8\nfr:\t\t\t\t\t\tfr_FR.ISO8859-1\nfr_"..., 4096) read(5, "u_HU.ISO-8859-2:\t\t\t\thu_HU.ISO885"..., 4096) read(5, "1\nmk_MK.MICROSOFT-CP1251:\t\t\t\tmk_"..., 4096) read(5, "\nro_RO.utf8:\t\t\t\t\tro_RO.UTF-8\nru:"..., 4096) read(5, "O8859-1\nts_ZA.utf8:\t\t\t\t\tts_ZA.UT"..., 4096) read(5, "SO8859-8\nhrvatski:\t\t\t\t\thr_HR.ISO"..., 4096) read(5, "", 4096)                       close(5)                                munmap(0x40019000, 4096)                open("/usr/X11R6/lib/X11/locale/locale.dir", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0644, st_size8037, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "#\t$XdotOrg: xc/nls/locale.dir,v "..., 4096) read(5, "LOCALE\t\t\tes_DO.ISO8859-1\niso8859"..., 4096) read(5, "ined for it, and the GNU C Libra"..., 4096) read(5, "ALE            byn_ER.UTF-8\nen_U"..., 4096) read(5, "in Malawi), not Nynorsk.\n# See <"..., 4096) close(5)                                munmap(0x40019000, 4096)                open("/usr/X11R6/lib/X11/locale/C/XI18N_OBJS", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0644, st_size33, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "# CATEGORY(XLC|XIM|OM)\tSHARED_LI"..., 4096) read(5, "", 4096)                       close(5)                                munmap(0x40019000, 4096)                open("/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2", O_RDONLY) read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\6\0"..., 512) fstat64(5, {st_mode=S_IFREG|0644, st_sizer48, ...}) mmap2(NULL, 10188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) mmap2(0x4001b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1) close(5)                                open("/usr/X11R6/lib/X11/locale/locale.alias", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0644, st_sizeu128, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "#\t$XdotOrg: xc/nls/locale.alias,"..., 4096) read(5, "14\t\t\t\tbr_FR.ISO8859-14\nbr_FR.ISO"..., 4096) read(5, "\nen.ISO-8859-1\t\t\t\t\ten_US.ISO8859"..., 4096) read(5, "9-1\t\t\t\tes_ES.ISO8859-1\nes_ES.iso"..., 4096) read(5, "r_CA.iso885915\t\t\t\tfr_CA.ISO8859-"..., 4096) read(5, "t_IT.88591.en\t\t\t\t\tit_IT.ISO8859-"..., 4096) read(5, "59-15\nnl_BE.ISO-8859-15 at euro\t\t\t\t"..., 4096) read(5, "ET.UTF-8\nsk\t\t\t\t\t\tsk_SK.ISO8859-2"..., 4096) read(5, "\t\t\t\twa_BE.ISO8859-1\nwa_BE\t\t\t\t\t\tw"..., 4096) read(5, "s locale names\nISO8859-1\t\t\t\t\ten_"..., 4096) read(5, "_BG.koi8r:\t\t\t\t\tbg_BG.KOI8-R\nbe_B"..., 4096) read(5, "TF-8\nGER_DE.8859:\t\t\t\t\tde_DE.ISO8"..., 4096) read(5, "ISO-8859-1:\t\t\t\tes_CR.ISO8859-1\ne"..., 4096) read(5, "F-8\nfr:\t\t\t\t\t\tfr_FR.ISO8859-1\nfr_"..., 4096) read(5, "u_HU.ISO-8859-2:\t\t\t\thu_HU.ISO885"..., 4096) read(5, "1\nmk_MK.MICROSOFT-CP1251:\t\t\t\tmk_"..., 4096) read(5, "\nro_RO.utf8:\t\t\t\t\tro_RO.UTF-8\nru:"..., 4096) read(5, "O8859-1\nts_ZA.utf8:\t\t\t\t\tts_ZA.UT"..., 4096) read(5, "SO8859-8\nhrvatski:\t\t\t\t\thr_HR.ISO"..., 4096) read(5, "", 4096)                       close(5)                                munmap(0x4001c000, 4096)                open("/usr/X11R6/lib/X11/locale/locale.dir", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0644, st_size8037, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "#\t$XdotOrg: xc/nls/locale.dir,v "..., 4096) read(5, "LOCALE\t\t\tes_DO.ISO8859-1\niso8859"..., 4096) read(5, "ined for it, and the GNU C Libra"..., 4096) read(5, "ALE            byn_ER.UTF-8\nen_U"..., 4096) read(5, "in Malawi), not Nynorsk.\n# See <"..., 4096) close(5)                                munmap(0x4001c000, 4096)                access("/usr/X11R6/lib/X11/locale/C/XLC_LOCALE", R_OK) open("/usr/X11R6/lib/X11/locale/C/XLC_LOCALE", O_RDONLY|O_LARGEFILE) fstat64(5, {st_mode=S_IFREG|0644, st_sizew2, ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "#  $Xorg: C,v 1.3 2000/08/17 19:"..., 4096) read(5, "", 4096)                       close(5)                                munmap(0x4001c000, 4096)                write(4, "-\0\16\0\2\0\300\1+\0\0\0-*-clean-bold-r-norm"..., 68) read(4, "\1\377\f\0\351\0\0\0\0\0\0\0\6\0\0\0\373\377\0\0\377\377"..., 32) read(4, "\2\0\0\0\377\377\23\0\0\0\177\0\0\0\25\0\0\0\0\1\10\0\2"..., 40) read(4, "\305\0\0\0\306\0\0\0\261\0\0\0\207\1\0\0@\0\0\0\210\1\0"..., 168) read(4, "\0\0\6\0\6\0\10\0\2\0\0\0\0\0\6\0\6\0\7\0\0\0\0\0\1\0\6"..., 724) write(4, "-\0\16\0\3\0\300\1+\0\0\0-*-clean-bold-r-norm"..., 68) read(4, "\1\377\16\0\351\0\0\0\0\0\0\0\6\0\0\0\373\377\0\0\377\377"..., 32) read(4, "\2\0\0\0\377\377\23\0\0\0\177\0\0\0\25\0\0\0\0\1\10\0\2"..., 40) read(4, "\305\0\0\0\306\0\0\0\261\0\0\0\207\1\0\0@\0\0\0\210\1\0"..., 168) read(4, "\0\0\6\0\6\0\10\0\2\0\0\0\0\0\6\0\6\0\7\0\0\0\0\0\1\0\6"..., 724) write(4, "-\0\16\0\4\0\300\1,\0\0\0-*-lucidatypewriter-"..., 68) read(4, "\1\0\20\0\343\1\0\0\371\377\1\0\30\0\377\377\346\377Z\2"..., 32) read(4, "\t\0Z\2\1\0\v\0\0\0\377\0\0\0\33\0\0\0\0\0%\0\10\0\0\1"..., 40) read(4, "\261\0\0\0\215\1\0\0@\0\0\0\216\1\0\0\262\0\0\0\217\1\0"..., 216) read(4, "\2\0\27\0\30\0\36\0\0\0Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1676) open("/etc/ld.so.cache", O_RDONLY)      fstat64(5, {st_mode=S_IFREG|0644, st_size4106, ...}) mmap2(NULL, 34106, PROT_READ, MAP_PRIVATE, 5, 0) close(5)                                access("/etc/ld.so.nohwcap", F_OK)      open("/usr/lib/libXcursor.so.1", O_RDONLY) read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 $\0\000"..., 512) fstat64(5, {st_mode=S_IFREG|0644, st_size3128, ...}) mmap2(NULL, 36204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) mmap2(0x402a8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x7) close(5)                                access("/etc/ld.so.nohwcap", F_OK)      open("/usr/lib/libXrender.so.1", O_RDONLY) read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\23"..., 512) fstat64(5, {st_mode=S_IFREG|0644, st_size1620, ...}) mmap2(NULL, 34568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) mmap2(0x402b1000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x7) close(5)                                munmap(0x40297000, 34106)               writev(4, [{"5\30\4\0\5\0\300\1:\0\0\0\20\0\20\0007c\5\0\6\0\300\1\5"..., 132}, {"RENDER", 6}, {"\0\0", 2}], 3) read(4, "\1\0\24\0\0\0\0\0\1\232\0\264\0\0\0\0\0\0\0\0\24\0\0\0"..., 32) write(4, "\232\0\3\0\0\0\0\0\n\0\0\0\232\1\1\0", 16) read(4, "\1>\25\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\1l\26\0\227\0\0\0\22\0\0\0\1\0\0\0\7\0\0\0\4\0\0\0\1\0"..., 32) read(4, "&\0\0\0\1\1\220\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0"..., 604) uname({sys="Linux", node="netrek", ...}) open("/home/zu22/.Xdefaults-netrek", O_RDONLY|O_LARGEFILE) write(4, "<\0\2\0\6\0\300\0017\0\5\0\7\0\300\1:\0\0\0\0@\0\0\4\0"..., 1772) read(4, "\1\0l\0\0\0\0\0g\0\0\0\0\0\0\0\0\0\0\0\24\0\0\0\350p\210"..., 32) write(4, "\20\1\t\0\31\0\300\1XDCCC_LINEAR_RGB_MATRICE"..., 36) read(4, "\1\0m\0\0\0\0\0h\0\0\0\0\0\0\0\1\0\0\0\24\0\0\0\350p\210"..., 32) write(4, "\24\0\6\0:\0\0\0h\0\0\0\23\0\0\0\0\0\0\0t\31\0\0", 24) read(4, "\1\0n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) stat64("/usr/X11R6/lib/X11/Xcms.txt", 0xbfffede4) write(4, "\\\0\5\0 \0\0\0\5\0\0\0white\0\0\0", 20) read(4, "\1>o\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"..., 32) write(4, "T\0\4\0 \0\0\0\377\377\377\377\377\377it", 16) read(4, "\1>p\0\0\0\0\0\377\377\377\377\377\377\0\0\377\377\377"..., 32) write(4, "5\30\4\0O\0\300\1:\0\0\0\20\0\20\0007\0\6\0P\0\300\1O\0"..., 156) read(4, "\1\33u\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) write(4, "T\30\4\0 \0\0\0\0\0\0\0\0\0\20\0", 16) read(4, "\1>v\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) write(4, "5\30\4\0Q\0\300\1:\0\0\0\20\0\20\0007\0\5\0R\0\300\1Q\0"..., 148) read(4, "\1\33{\0\0\0\0\0\377\377\300\300\313\313\377\377\300\300"..., 32) write(4, "T\30\4\0 \0\0\0\377\377\300\300\313\313\20\0", 16) read(4, "\1>|\0\0\0\0\0\377\377\300\300\313\313\0\0\313\300\377"..., 32) write(4, "5\30\4\0S\0\300\1:\0\0\0\20\0\20\0007\0\6\0T\0\300\1S\0"..., 156) read(4, "\1\33\201\0\0\0\0\0\0\0\377\377\0\0\0\0\377\377\0\0\0\0"..., 32) write(4, "T\30\4\0 \0\0\0\0\0\377\377\0\0\20\0", 16) read(4, "\1>\202\0\0\0\0\0\0\0\377\377\0\0\0\0\0\377\0\0\0\0\0\0"..., 32) write(4, "5\30\4\0U\0\300\1:\0\0\0\20\0\20\0007\0\6\0V\0\300\1U\0"..., 156) read(4, "\1\33\207\0\0\0\0\0\377\377\377\377\0\0\377\377\377\377"..., 32) write(4, "T\30\4\0 \0\0\0\377\377\377\377\0\0\20\0", 16) read(4, "\1>\210\0\0\0\0\0\377\377\377\377\0\0\0\0\0\377\377\0\0"..., 32) write(4, "5\30\4\0W\0\300\1:\0\0\0\20\0\20\0007\0\6\0X\0\300\1W\0"..., 152) read(4, "\1\33\215\0\0\0\0\0\0\0\377\377\377\377\0\0\377\377\377"..., 32) write(4, "T\30\4\0 \0\0\0\0\0\377\377\377\377\20\0", 16) read(4, "\1>\216\0\0\0\0\0\0\0\377\377\377\377\0\0\377\377\0\0\0"..., 32) write(4, "5\30\4\0Y\0\300\1:\0\0\0\20\0\20\0007\0\6\0Z\0\300\1Y\0"..., 160) read(4, "\1\33\223\0\0\0\0\0\323\323\323\323\323\323\323\323\323"..., 32) write(4, "T\30\4\0 \0\0\0\323\323\323\323\323\323\20\0", 16) read(4, "\1>\224\0\0\0\0\0\323\323\323\323\323\323\0\0\323\323\323"..., 32) write(4, "5\30\4\0[\0\300\1:\0\0\0\20\0\20\0007\0\6\0\\\0\300\1["..., 152) read(4, "\1\33\231\0\0\0\0\0\377\377\300\300\313\313\377\377\300"..., 32) write(4, "T\30\4\0 \0\0\0\377\377\300\300\313\313\20\0", 16) read(4, "\1>\232\0\0\0\0\0\377\377\300\300\313\313\0\0\313\300\377"..., 32) write(4, "5\30\4\0]\0\300\1:\0\0\0\20\0\20\0007\0\6\0^\0\300\1]\0"..., 156) read(4, "\1\33\237\0\0\0\0\0\0\0\377\377\0\0\0\0\377\377\0\0\0\0"..., 32) write(4, "T\30\4\0 \0\0\0\0\0\377\377\0\0\20\0", 16) read(4, "\1>\240\0\0\0\0\0\0\0\377\377\0\0\0\0\0\377\0\0\0\0\0\0"..., 32) write(4, "5\30\4\0_\0\300\1:\0\0\0\20\0\20\0007\0\6\0`\0\300\1_\0"..., 156) read(4, "\1\33\245\0\0\0\0\0\377\377\377\377\0\0\377\377\377\377"..., 32) write(4, "T\30\4\0 \0\0\0\377\377\377\377\0\0\20\0", 16) read(4, "\1>\246\0\0\0\0\0\377\377\377\377\0\0\0\0\0\377\377\0\0"..., 32) write(4, "5\30\4\0a\0\300\1:\0\0\0\20\0\20\0007\0\6\0b\0\300\1a\0"..., 152) read(4, "\1\33\253\0\0\0\0\0\0\0\377\377\377\377\0\0\377\377\377"..., 32) write(4, "T\30\4\0 \0\0\0\0\0\377\377\377\377\20\0", 16) read(4, "\1>\254\0\0\0\0\0\0\0\377\377\377\377\0\0\377\377\0\0\0"..., 32) write(4, "5\30\4\0c\0\300\1:\0\0\0\20\0\20\0007\0\6\0d\0\300\1c\0"..., 160) read(4, "\1\33\261\0\0\0\0\0\323\323\323\323\323\323\323\323\323"..., 32) write(4, "T\30\4\0 \0\0\0\323\323\323\323\323\323\20\0", 16) read(4, "\1>\262\0\0\0\0\0\323\323\323\323\323\323\0\0\323\323\323"..., 32) write(4, "5\30\4\0e\0\300\1:\0\0\0\20\0\20\0007\0\6\0f\0\300\1e\0"..., 352) read(4, "\1\0\275\0\224\1\0\0\0\0\0\0\t\0\377\377\366\377\0\0\30"..., 32) read(4, "\3\0\0\0\0\0Z\2\0\0\377\0\0\0\26\0\0\0\0\0\f\0\3\0\0\1"..., 40) read(4, "\305\0\0\0\306\0\0\0\261\0\0\0\307\0\0\0@\0\0\0\310\0\0"..., 176) read(4, "\0\0\10\0\t\0\v\0\0\0\0\0\0\0\t\0\t\0\t\0\0\0\0\0\0\0\t"..., 1400) write(4, "T\30\4\0 \0\0\0\0p\0p\0p\20\0", 16) read(4, "\1>\276\0\0\0\0\0pppppp\0\0ppp\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) write(4, "7\30\7\0k\0\300\1:\0\0\0\5@\0\0\7\0\0\0ppp\0j\0\300\1\1"..., 6972) read(4, "\23\0\'\1{\0\300\1{\0\300\1\0\326\f\10\350\274}\10X@\215"..., 32) read(4, "\23\0005\1}\0\300\1}\0\300\1\0\326\f\10\350\274}\10\320"..., 32) read(4, "\1\334]\1\2\0\0\0\1\0\377\277\360\236\v\10\210\307}\10"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\30\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>^\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "-\30\5\0\204\0\300\1\6\0\377\0cursor\0\0^p\10\0\205\0\300"..., 416) read(4, "\1\322j\1\2\0\0\0\1\0\377\277\360\236\v\10\0\r\214\10\0"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\30\3\0 \0\0\0\0\0\0\0", 12) read(4, "\1>k\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\30\10\0\207\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 3044) read(4, "\1\335\260\1\2\0\0\0\1\0\377\277\360\236\v\10\220\265\215"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\30\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>\261\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\30\10\0\222\0\300\1\204\0\300\1\204\0\300\1D\0E\0\0\0"..., 80) read(4, "\1\321\265\1\2\0\0\0\1\0\377\277\360\236\v\10\360\356\210"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\30\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>\266\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\30\10\0\223\0\300\1\204\0\300\1\204\0\300\1D\0E\0\0\0"..., 80) read(4, "\1\321\272\1\2\0\0\0\1\0\377\277\360\236\v\10\270\360\210"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\30\3\0 \0\0\0\0\0\0\0", 12) read(4, "\1>\273\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\30\10\0\224\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\277\1\2\0\0\0\1\0\377\277\360\236\v\10\270\225\211"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) write(4, "[\30\3\0 \0\0\0\0\0\0\0", 12) read(4, "\1>\300\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                open("/home/zu22/.icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/core/index.theme", O_RDONLY) open("/usr/share/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/core/index.theme", O_RDONLY) open("/usr/share/pixmaps/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/core/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/index.theme", O_RDONLY) write(4, "5\1\4\0\225\0\300\1n\0\300\1\v\0\v\0007\0\4\0\226\0\300"..., 296) read(4, "\1\322\314\1\2\0\0\0\1\0\377\277\360\236\v\10X\35\221\10"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\315\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                open("/home/zu22/.icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/core/index.theme", O_RDONLY) open("/usr/share/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/core/index.theme", O_RDONLY) open("/usr/share/pixmaps/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/core/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/index.theme", O_RDONLY) write(4, "5\1\4\0\232\0\300\1o\0\300\1\v\0\v\0007\0\4\0\233\0\300"..., 296) read(4, "\1\322\331\1\2\0\0\0\1\0\377\277\360\236\v\10\320\376\200"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\332\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\237\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\336\1\2\0\0\0\1\0\377\277\360\236\v\10\0\245\204"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\337\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/xterm", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/xterm", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/xterm", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/xterm", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\240\0\300\1\204\0\300\1\204\0\300\1\230\0\231"..., 80) read(4, "\1\321\343\1\2\0\0\0\1\0\377\277\360\236\v\10(\274}\10"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\344\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\241\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\350\1\2\0\0\0\1\0\377\277\360\236\v\10H!\211\10"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\351\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\242\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\355\1\2\0\0\0\1\0\377\277\360\236\v\10@>\215\10"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\356\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\243\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\362\1\2\0\0\0\1\0\377\277\360\236\v\10\250\336\223"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\1\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>\363\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\244\0\300\1\204\0\300\1\204\0\300\1D\0E\0\0\0"..., 80) read(4, "\1\321\367\1\2\0\0\0\1\0\377\277\360\236\v\10\270\340\223"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\370\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\245\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\374\1\2\0\0\0\1\0\377\277\360\236\v\10\320\277\177"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\375\1\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\246\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\1\2\2\0\0\0\1\0\377\277\360\236\v\10X@\215\10\0"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\2\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\247\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\6\2\2\0\0\0\1\0\377\277\360\236\v\10\320\275\177"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\7\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\250\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\v\2\2\0\0\0\1\0\377\277\360\236\v\10P\211\220\10"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\f\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\251\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\20\2\2\0\0\0\1\0\377\277\360\236\v\10h\207\220\10"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\21\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\252\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\25\2\2\0\0\0\1\0\377\277\360\236\v\10\370\236\203"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\26\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\253\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321\32\2\2\0\0\0\1\0\377\277\360\236\v\10\360\206\221"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>\33\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/xterm", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/xterm", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/xterm", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/xterm", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\254\0\300\1\204\0\300\1\204\0\300\1\230\0\231"..., 80) read(4, "\1\321\37\2\2\0\0\0\1\0\377\277\360\236\v\10\210\315\220"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1> \2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\255\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321$\2\2\0\0\0\1\0\377\277\360\236\v\10p\275w\10\0@"..., 32) read(4, "\377\377\300\300\313\313\0\0", 8) write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>%\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/pirate", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/pirate", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/pirate", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/pirate", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\256\0\300\1\204\0\300\1\204\0\300\1X\0Y\0\0\0"..., 80) read(4, "\1\321)\2\2\0\0\0\1\0\377\277\360\236\v\10(\235\203\10"..., 32) read(4, "\377\377\377\377\0\0\0\0", 8)  write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>*\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/trek", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/trek", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/trek", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/trek", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\257\0\300\1\204\0\300\1\204\0\300\1\216\0\217"..., 80) read(4, "\1\321.\2\2\0\0\0\1\0\377\277\360\236\v\10\220\265\215"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\1\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>/\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\260\0\300\1\204\0\300\1\204\0\300\1D\0E\0\0\0"..., 80) read(4, "\1\3213\2\2\0\0\0\1\0\377\277\360\236\v\10@\247\204\10"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\1\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>4\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                write(4, "^\1\10\0\261\0\300\1\204\0\300\1\204\0\300\1D\0E\0\0\0"..., 80) read(4, "\1\3218\2\2\0\0\0\1\0\377\277\360\236\v\10\350\305}\10"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>9\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                open("/home/zu22/.icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/core/index.theme", O_RDONLY) open("/usr/share/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/core/index.theme", O_RDONLY) open("/usr/share/pixmaps/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/core/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/index.theme", O_RDONLY) write(4, "5\1\4\0\262\0\300\1\213\0\300\1\21\0\22\0007\0\4\0\263"..., 352) read(4, "\1\322E\2\2\0\0\0\1\0\377\277\360\236\v\10\310\33\203\10"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>F\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                open("/home/zu22/.icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/core/index.theme", O_RDONLY) open("/usr/share/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/core/index.theme", O_RDONLY) open("/usr/share/pixmaps/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/core/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/index.theme", O_RDONLY) write(4, "5\1\4\0\267\0\300\1\214\0\300\1\21\0\r\0007\0\4\0\270\0"..., 312) read(4, "\1\322R\2\2\0\0\0\1\0\377\277\360\236\v\10\300\35\203\10"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>S\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                open("/home/zu22/.icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/core/index.theme", O_RDONLY) open("/usr/share/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/core/index.theme", O_RDONLY) open("/usr/share/pixmaps/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/core/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/index.theme", O_RDONLY) write(4, "5\1\4\0\274\0\300\1\215\0\300\1\21\0\22\0007\0\4\0\275"..., 352) read(4, "\1\322_\2\2\0\0\0\1\0\377\277\360\236\v\10\340\7\207\10"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) write(4, "[\1\3\0 \0\0\0\0\0\0\0", 12)  read(4, "\1>`\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          open("/home/zu22/.icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                open("/home/zu22/.icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/home/zu22/.icons/core/index.theme", O_RDONLY) open("/usr/share/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/icons/core/index.theme", O_RDONLY) open("/usr/share/pixmaps/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/share/pixmaps/core/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/cursors/00000000000000000000000000000000", O_RDONLY) open("/usr/X11R6/lib/X11/icons/core/index.theme", O_RDONLY) write(4, "5\1\4\0\301\0\300\1\216\0\300\1\21\0\22\0007\0\4\0\302"..., 536) read(4, "\1\323q\2\2\0\0\0\1\0\377\277\360\236\v\10\210\244\230"..., 32) read(4, "\0\0\0\0\0\0\0\0", 8)          write(4, "[\1\3\0 \0\0\0\377\377\377\0", 12) read(4, "\1>r\2\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) read(4, "\377\377\377\377\377\377\0\0", 8) open("/home/zu22/.icons/default/cursors/left_ptr", O_RDONLY) open("/home/zu22/.icons/default/index.theme", O_RDONLY) open("/usr/share/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/share/icons/default/index.theme", O_RDONLY) open("/usr/share/pixmaps/default/cursors/left_ptr", O_RDONLY) open("/usr/share/pixmaps/default/index.theme", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/cursors/left_ptr", O_RDONLY) open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) fstat64(5, {st_mode=S_IFREG|0644, st_size', ...}) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) read(5, "[Icon Theme]\nInherits=core\n", 4096) close(5)                                munmap(0x4001c000, 4096)                writev(4, [{"^\1\10\0\307\0\300\1\204\0\300\1\204\0\300\1D\0E\0\0\0"..., 16356}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\370\0\0\0\374\1\0\0\374\1\0"..., 80}], 2) write(4, "<\1\2\0\251\1\300\0015\1\4\0\252\1\300\1n\0\300\1\24\0"..., 16376) write(4, "7\1\4\0\215\2\300\1\214\2\300\1\0\0\0\0H\1\32\0\214\2\300"..., 16368) writev(4, [{"H\1\32\0n\3\300\1o\3\300\1\24\0\24\0\0\0\0\0\0\1\300\1"..., 16376}, {"\0\0\0\0\0\0\0\0\0\4\0\0\0\2\0\0\0\2\0\0\0\7\1\0\0\235"..., 80}], 2) writev(4, [{"<\1\2\0Q\4\300\0015\1\4\0R\4\300\1n\0\300\1\24\0\24\000"..., 16312}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\300\0\0\0x\0\0\0\16\0\0\200"..., 80}], 2) write(4, "<\1\2\0003\5\300\0015\1\4\0004\5\300\1n\0\300\1\24\0\24"..., 16376) write(4, "7\1\4\0\27\6\300\1\26\6\300\1\0\0\0\0H\1\32\0\26\6\300"..., 16368) writev(4, [{"H\1\32\0\370\6\300\1\371\6\300\1\24\0\24\0\0\0\0\0\0\1"..., 15948}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512}], 2) write(4, "<\1\2\0\273\7\300\0015\1\4\0\274\7\300\1n\0\300\1@\0@\000"..., 12848) select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [32])                read(4, "\f\347\342\20w\0\300\1\0\0\0\0\352\1F\1\0\0\223\10\30\326"..., 32) write(4, "8\1\6\0\7\0\300\1\f\0\1\0\377\377\377\0\0\0\0\0\0\0\0\0"..., 1524) ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   recvfrom(3, "r,12\nparadise.homeunix.org,2592,"..., 2048, 0, {sa_family?_INET, sin_port=htons(3521), sin_addr=inet_addr("208.20.202.42")}, [16]) time(NULL)                              select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [32])                read(4, "\4\1\376\20\25\274\335\4:\0\0\0w\0\300\1\0\0\0\0\232\0"..., 32) write(4, "F\1\5\0w\0\300\1\r\0\300\1\5\0008\1\340\1\n\0LM\30\0w\0"..., 116) write(1, "Attempting to connect to  on por"..., 39) socket(PF_FILE, SOCK_STREAM, 0)         fcntl64(5, F_GETFL)                     fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK)  connect(5, {sa_family?_FILE, path="/var/run/nscd/socket"}, 110) poll([{fd=5, events=POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 5000) writev(5, [{"\2\0\0\0\4\0\0\0\1\0\0\0", 12}, {"\0", 1}], 2) poll([{fd=5, events=POLLIN|POLLERR|POLLHUP, revents=POLLIN|POLLHUP}], 1, 5000) read(5, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377"..., 32) close(5)                                write(2, "Cannot connect to !\n", 20)   write(4, "F\1\5\0w\0\300\1\r\0\300\1\5\0008\1\340\1\n\0008M\6\0\24"..., 116) select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(1024, [3 4], NULL, NULL, NULL)   ioctl(4, FIONREAD, [0])                 select(5, [4], NULL, NULL, {0, 0})      ioctl(4, FIONREAD, [0])                 read(4, "", 32)                         write(2, "X connection to :0.0 broken (exp"..., 65) munmap(0x40018000, 4096)                exit_group(1)                           



From williamb at its.caltech.edu  Wed May 24 04:40:52 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Wed, 24 May 2006 04:40:52 -0500
Subject: [netrek-dev] darcs patch: PROJECTS update
Message-ID: <200605240940.k4O9eqsi031158@omen.digital-genesis.com>

Wed May 24 04:39:48 CDT 2006  williamb at its.caltech.edu
  * PROJECTS update
  Removed twarp observer bug from PROJECTS list, as this has been fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 16398 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060524/c70f1dcd/attachment.bin 

From quozl at us.netrek.org  Wed May 24 05:19:00 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 20:19:00 +1000
Subject: [netrek-dev] cow package won't display metaserver data
In-Reply-To: <ecfa260c0605240214p5634356aw541b11fe38377f62@mail.gmail.com>
References: <ecfa260c0605240214p5634356aw541b11fe38377f62@mail.gmail.com>
Message-ID: <20060524101900.GX4911@us.netrek.org>

Run it again with "-r /dev/null" and tell me if it does the same thing.

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


From quozl at us.netrek.org  Wed May 24 05:20:21 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 May 2006 20:20:21 +1000
Subject: [netrek-dev] darcs patch: PROJECTS update
In-Reply-To: <200605240940.k4O9eqsi031158@omen.digital-genesis.com>
References: <200605240940.k4O9eqsi031158@omen.digital-genesis.com>
Message-ID: <20060524102021.GY4911@us.netrek.org>

On Wed, May 24, 2006 at 04:40:52AM -0500, williamb at its.caltech.edu wrote:
> Wed May 24 04:39:48 CDT 2006  williamb at its.caltech.edu
>   * PROJECTS update
>   Removed twarp observer bug from PROJECTS list, as this has been fixed.

Taken, thanks.

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


From jimmyhua73 at yahoo.com  Wed May 24 06:43:10 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 24 May 2006 04:43:10 -0700 (PDT)
Subject: [netrek-dev] mfprintf in robotd
In-Reply-To: <20060524083151.GU4911@us.netrek.org>
Message-ID: <20060524114310.3783.qmail@web35313.mail.mud.yahoo.com>



--- James Cameron <quozl at us.netrek.org> wrote:

> On Wed, May 24, 2006 at 12:58:33AM -0700, Jimmy
> Huang wrote:
> > Although I don't understand how to use this
> > function...  I went ahead and replaced every
> instance
> > of mprintf with mfprintf(sterr,"foo\n");
> 
> But why?

Only for testing purposes. Since I don't understand
it. I blackbox it, and send it through a torture test.


No permanent changes to the robotd code. All changes
were already wiped out here locally. 

Jimmy

> mfprintf is for reporting messages to stderr, which
> is not buffered, and
> is expected to contain errors or other failures.
> 
> The deliberate difference seems useful.  Making it
> all the same just
> eliminates that useful difference.

I understand there's a usefulness to it (though don't
know how I personally can take advantage of it), and
don't plan to change it. 

> > Ran the program through a debugger, and robotd has
> > been running fine for about an hour now. Things
> print
> > out on the screen just fine. 
> 
> Wouldn't this break any scripts that are watching
> stdout?  Why do it?

Don't know of any scripts. 

> No worries, I know how it goes.  I get the same
> thing happening.  It
> *will* give us a chance to settle the code and do
> some testing.  ;-)

There's some changes that Trent put out that are
totally awesome. He improved the bombing/taking logic
even more than what I did. And also, fixed the dodge
code by changing something in the server. 

Gotta manual patch his patch and check it out. 

Jimmy



From xyzzy at speakeasy.org  Wed May 24 16:57:46 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 14:57:46 -0700 (PDT)
Subject: [netrek-dev] darcs patch: Player position sign fix
In-Reply-To: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
References: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
Message-ID: <Pine.LNX.4.58.0605241355030.22226@shell2.speakeasy.net>

On Wed, 24 May 2006 williamb at its.caltech.edu wrote:
> Wed May 24 03:09:01 CDT 2006  williamb at its.caltech.edu
>   * Player position sign fix
>   * genspkt.c: With short packets on, positions in the negative (i.e. on player
>   death) were being reported incorrectly.

It looks to me, like they are still not reported correctly.

For other players, this should have no effect.  The SP code to send their
positions maps anything off the map to galactic,501,501.  It doesn't matter if
it's a negative number or a very large positive number.

For the player's own position with SP1, this shouldn't effect anything (for
the C99 standard, prior to that, it's not defined).  It just turns the data
from unsigned long -> signed long -> unsigned long.  Remeber that ntohl() and
htonl() both use unsigned longs.

For the player's own position and SP2, the values changes, but the client code
I've looked at all treats the data in the packet as unsigned short.  Here is
the code from COW:

          struct player_s2_spacket *pa2 = (struct player_s2_spacket *) sbuf;

          x = SCALE * ntohs(pa2->x);
          y = SCALE * ntohs(pa2->y);

Notice that it doesn't treat the value as signed.  What happened before your
change:

dead player position = -100000
data sent in SP2 packet = 0x5ca2 = 23714
client interpertation of SP2 data = 948560 (way outside galaxy)

After change:
dead player position = -100000
data sent in SP2 packet = 0xf63d = 63037
client interpertation of SP2 data = 2521480 (way way outside galaxy)

If you also change the clients to treat the data in the SP2 struct as
signed instead of unsigned, then you get:

dead player position = -100000
data sent in SP2 packet = 0xf63d = -2499
client interpertation of SP2 data = -99960

Close, but still different.


From narcis at lukassen.homelinux.com  Wed May 24 17:09:43 2006
From: narcis at lukassen.homelinux.com (Chris en Judith)
Date: Thu, 25 May 2006 00:09:43 +0200
Subject: [netrek-dev] netrek-dev Digest, Vol 15, Issue 64
In-Reply-To: <mailman.182.1148427222.31331.netrek-dev@us.netrek.org>
References: <mailman.182.1148427222.31331.netrek-dev@us.netrek.org>
Message-ID: <BF935A1A-69E5-4548-B8BF-50B38C8DDBAD@luky.nl>


Hi everyone,

thanks for all the input

> Message: 4
> Date: Wed, 24 May 2006 08:26:02 +1000
> From: James Cameron <quozl at us.netrek.org>
> Subject: Re: [netrek-dev] Number of players on Vanilla Server
>
> Chris, the specification of the protocol is in the source code for the
> server,

Yeah that's what always tell my boss when i asks for documentation :-)

> you should read and understand the relevant sections as soon as
> yohu have a question about how the protocol works.

It's comming, but quite a bit to chew on from scratch.

> MAXPLAYER is set in include/config.h to 32.  That's player number zero
> through to 31, as you observed.

Yes there were some very helpfull remarks as to why. I've created a  
larger
array, but now also know why :-)

> How far are you from release?  We're synchronising here for a 1st June
> release for several components.

Very far, but i could help generate a server binary for OS X if you  
would like?

> -- 
> James Cameron    mailto:quozl at us.netrek.org     http:// 
> quozl.netrek.org/
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 24 May 2006 08:34:36 +1000
> From: James Cameron <quozl at us.netrek.org>
> Subject: Re: [netrek-dev] Connection to server protocol
>
> G'day Chris,
>
> No, tcpdump doesn't really help me ... I use packet decoding logic in
> the Linux client to figure out what is going on.  We don't have  
> this in
> the server yet, but it's something I'm pondering.

Ok, i created a something and hooked it quite ugly i gwrite, i will
post it later on, could be something to bolt on but it is not as  
descriptive as your log

> On Sat, May 20, 2006 at 10:50:24PM +0200, Chris en Judith wrote:
>> roughly the server responds to my CP_SOCKET and CP_FEATURE message
>> with a SP_MOTD and a SP_MOTD_PIC the remainder of the buffer is
>> filled with a 0 and gets flushed. (i might accidently have read an
>> entire frame 1536 in stead of what was really in the buffer but
>> what the hack.
>
> You'd better clarify this.  Packets are sent appended to each  
> other, and
> unless you get the sizes exactly right (their size is not in the data
> stream usually) then you will lose alignment and crash.

My mistake, i advanced a pointer a bit too far, and had not expected  
the server
to cache that many messages. They are flying by now.

>> i was expecting a message SP_S_PLAYER to set which slot i'd been
>> allocated but i might be fully off here.
>
> After SP_MOTD you get SP_YOU with your player number, then a batch of
> (SP_PL_LOGIN, SP_HOSTILE, SP_PLAYER_INFO, SP_KILLS, SP_PSTATUS and
> SP_PLAYER) for each of the 32 slots.  Then you get all the
> SP_PLANET_LOCs for each planet, then all the SP_FEATURE packets,  
> then an
> SP_LOGIN prompt packet.  Your reply at this point should be CP_LOGIN.

I'm at that stage now, what tricked my was the CP_SOCKET i had not  
anticipated the
need before the server even nows my name, then i saw the UDP version  
field...

> See http://quozl.linux.org.au/netrek/login.log.gz for an example of a
> connection and login sequence.

Got it, these SP_SEQUENCE had to do with compressed packets isn't it?

Thanks i'll keep you posted on the progress.

regards

Chris



From williamb at its.caltech.edu  Wed May 24 17:20:09 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 24 May 2006 15:20:09 -0700 (PDT)
Subject: [netrek-dev] darcs patch: Player position sign fix
In-Reply-To: <Pine.LNX.4.58.0605241355030.22226@shell2.speakeasy.net>
References: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605241355030.22226@shell2.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605241510410.9837@clyde>

>           struct player_s2_spacket *pa2 = (struct player_s2_spacket *) sbuf;
>
>           x = SCALE * ntohs(pa2->x);
>           y = SCALE * ntohs(pa2->y);
>
> If you also change the clients to treat the data in the SP2 struct as
> signed instead of unsigned, then you get:
>
> data sent in SP2 packet = 0xf63d = -2499
> client interpertation of SP2 data = -99960
>
> Close, but still different.
>
Yup I also changed client from ntohs to (short) ntohs.  -99960 is
good enough imo, would be better if it was -100000 but I don't see
how to do that.  Probably a rounding thing.  There are several
places in the client (COW, netrekxp at least) where it looks for negative
player position as determining factor whether to redraw screen or not.
Most noticeable for observers locked onto a player who dies - with short
packets on, the observer gets constant redraws due to xpos > 0, with long
packets, client stops redrawing due to xpos = -100000.  Yes it also
requires a client change to receive the signed position correctly, and
yes the client could be changed to check both x upper bound as well as
lower bound - but getting completely wrong position is still something
that should be fixed, imho.
For older clients without the corresponding client change, they will still
get the way wrong positive xpos as you said.  But for newer clients this
gives a chance to actually get negative pos values.
Bill


From quozl at us.netrek.org  Wed May 24 17:50:51 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 08:50:51 +1000
Subject: [netrek-dev] netrek-dev Digest, Vol 15, Issue 64
In-Reply-To: <BF935A1A-69E5-4548-B8BF-50B38C8DDBAD@luky.nl>
References: <mailman.182.1148427222.31331.netrek-dev@us.netrek.org>
	<BF935A1A-69E5-4548-B8BF-50B38C8DDBAD@luky.nl>
Message-ID: <20060524225051.GA5052@us.netrek.org>

On Thu, May 25, 2006 at 12:09:43AM +0200, Chris en Judith wrote:
> Very far, but i could help generate a server binary for OS X if you  
> would like?

Now that would be good.  Stephen Thorne is another OS X user on list, he
might be able to collaborate.

We'll be hosting stuff on http://www.netrek.org/ once the software tree
is back in place.

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


From xyzzy at speakeasy.org  Wed May 24 17:52:00 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 15:52:00 -0700 (PDT)
Subject: [netrek-dev] darcs patch: Player position sign fix
In-Reply-To: <Pine.GSO.4.58.0605241510410.9837@clyde>
References: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605241355030.22226@shell2.speakeasy.net>
	<Pine.GSO.4.58.0605241510410.9837@clyde>
Message-ID: <Pine.LNX.4.58.0605241541090.24783@shell3.speakeasy.net>

On Wed, 24 May 2006, William Balcerski wrote:
> Yup I also changed client from ntohs to (short) ntohs.  -99960 is
> good enough imo, would be better if it was -100000 but I don't see
> how to do that.  Probably a rounding thing.  There are several

Maybe it would be a better idea to do the same thing that is done for other
players' positions.  If a player is outside the galaxy, no matter if it's at
12345678 or -10000 or -100000, it gets mapped to the coordinates galactic,
x=501, y=501.  The clients detect this as "player not on map".  The same thing
could be done for SP2 own position, set it to 0xffff, 0xffff when the player
is outside the galaxy.  The client could interpret this anyway it wants.

> packets, client stops redrawing due to xpos = -100000.  Yes it also
> requires a client change to receive the signed position correctly, and

Changes in the protocol are very important.  This is not the kind of thing
that should be ignored in all comments so that it can be snuck in.


From keyos at keyos.org  Wed May 24 18:20:38 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Thu, 25 May 2006 02:20:38 +0300 (IDT)
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>

On Wed, 24 May 2006, Stephen Thorne wrote:

> Thanks for the patch, but it fails to apply, Can you check the md5sum?
> 8da52ebce2725b4056a4e56a657b8a65 is what I get...
> 
> Can you check that ranlib on solaris has the same (broken) behaviour
> as gnu ranlib? gnu ranlib will exit with an exit code of 0 if you pass
> it -c. Can you check that solaris ranlib does so too?
> 

Hmm, I'm kinda lost then. You're saying that the problem with gnu ranlib
is that it returns 0 when ran with -c. I have GNU ranlib and it exits
with 9 when ran with -c.

I know that there are versions of BSD like systems that replaced ranlib
with ar, so the ranlib is actually script that has 'exit 0' in it. I have
such ranlib on Solaris 8. Actually any SunOS 5.x has such ranlib.

I think you have such ranlib on your system as well. If this is the case
it means that ar will do all the job that ranlib was supposed to do as 
well. So in case of such system running ranlib -c or ranlib -qwe would 
have same effect on library - no effect at all.

I actually created the configure.in patch to fix the code that looks wrong
to me:

AC_MSG_CHECKING(for OSX ranlib)
if $RANLIB -c 2>/dev/null; then
    RANLIB_FLAGS=
    AC_MSG_RESULT(no)
else
    RANLIB_FLAGS='-c'
    AC_MSG_RESULT(drat - yes)
fi

I'm not sure what your shell interpreter returns on the first test, but 
mine always fails this test (no matter if I run ranlib -c or not).

The correct way with GNU lib would be:

AC_MSG_CHECKING(for OSX ranlib)
(eval $RANLIB -c) 2>&5
if test $? -ne 0; then
    RANLIB_FLAGS=                                                                                              
    AC_MSG_RESULT(no)                                                                                          
else                                                                                                           
    RANLIB_FLAGS='-c'                                                                                          
    AC_MSG_RESULT(drat - yes)                                                                                  
fi                                                                                                             

Hope this help understanding what's wrong with ranlib. I'd be glad if 
you'll add this patch to configure.in, because I'm kinda frustrated with
darcs already.

> darcs annotate has a really annoying output. but it shows you who
> wrote every line.

After Trent's message about Mercurial I've read lots of info on it and it
really looks much better to me in numerous ways (most important it has 
diff features similar to CVS and change sets (i.e. patches) are easily
searched and diffed).

I'd vote for moving to Mercurial from darcs. The main idea of 
decentralized repository would stay.

Please (everyone), take a look at Mercurial's home page and see if you 
would like working with it more than with darcs:

http://www.selenic.com/mercurial/wiki/index.cgi

Stas.

> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 


From quozl at us.netrek.org  Wed May 24 18:52:25 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 09:52:25 +1000
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
	<Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>
Message-ID: <20060524235225.GB5052@us.netrek.org>

On Thu, May 25, 2006 at 02:20:38AM +0300, Stas Pirogov wrote:
> Hope this help understanding what's wrong with ranlib. I'd be glad if 
> you'll add this patch to configure.in, because I'm kinda frustrated with
> darcs already.

Okay, I'll do that.

> I'd vote for moving to Mercurial from darcs. The main idea of 
> decentralized repository would stay.
> 
> Please (everyone), take a look at Mercurial's home page and see if you 
> would like working with it more than with darcs:

I've read the MajorFeatures page and the main page, and I agree, it
looks appealing.  I'll consider it after a few more months with darcs,
because at the moment the only significant problem I'm having with darcs
is the performance presumably due to ChangeLog.  In other ways, darcs
is doing fine for me.

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


From quozl at us.netrek.org  Wed May 24 20:03:38 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 11:03:38 +1000
Subject: [netrek-dev] Trent's robotd changes now in my repo
Message-ID: <20060525010338.GD5052@us.netrek.org>

I've completed the merge of Trent's changes.  Thanks to Trent for
helping me with the process.  Thanks to Stephen for testing my branch.

NEWS file:

- server sends torp direction, robots dodge better [Piepho]
- make robots cloak near enemy home planets due res danger [Piepho]
- make robots take neut planets once there are no enemy planets [Piepho]
- make robots recognise planet situational change while assaulting [Piepho]
- various robot fixes that triggered comprehensive work by others [Huang]

Pull from http://james.tooraweenah.com/darcs/netrek-server/

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


From williamb at its.caltech.edu  Wed May 24 20:16:47 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 24 May 2006 18:16:47 -0700 (PDT)
Subject: [netrek-dev] Sysdef option for stupid robots
Message-ID: <Pine.GSO.4.58.0605241813390.18098@sue>

I'm gonna sorta miss the robots that act all dumb, it was actually fun in
a way to play against them with such bad AI.  And it might even be
more useful for a newbie who is just as clueless to play against such
robots.  Could there be a way to tone down robot AI (not just dogfighting
skill) with a sysdef option?
Bill


From quozl at us.netrek.org  Wed May 24 20:22:03 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 11:22:03 +1000
Subject: [netrek-dev] darcs patch: Player position sign fix
In-Reply-To: <Pine.LNX.4.58.0605241541090.24783@shell3.speakeasy.net>
References: <200605240811.k4O8BCJU022215@omen.digital-genesis.com>
	<Pine.LNX.4.58.0605241355030.22226@shell2.speakeasy.net>
	<Pine.GSO.4.58.0605241510410.9837@clyde>
	<Pine.LNX.4.58.0605241541090.24783@shell3.speakeasy.net>
Message-ID: <20060525012203.GE5052@us.netrek.org>

On Wed, May 24, 2006 at 03:52:00PM -0700, Trent Piepho wrote:
> Changes in the protocol are very important.  This is not the kind of
> thing that should be ignored in all comments so that it can be snuck
> in.

I've rolled back this patch in my repo.  The protocol as it stands is
broken, but it is usably broken, the bit pattern can be recognised.

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


From quozl at us.netrek.org  Wed May 24 20:32:05 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 11:32:05 +1000
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <Pine.GSO.4.58.0605241813390.18098@sue>
References: <Pine.GSO.4.58.0605241813390.18098@sue>
Message-ID: <20060525013205.GF5052@us.netrek.org>

Perhaps an option that sets the rate at which robots are given updates,
so that instead of once every tenth of a second they get five or even
two updates per second?

Perhaps an anger option that degrades their performance if you make
assertions about their parentage?

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


From jimmyhua73 at yahoo.com  Wed May 24 20:33:58 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 24 May 2006 18:33:58 -0700 (PDT)
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <Pine.GSO.4.58.0605241813390.18098@sue>
Message-ID: <20060525013358.50305.qmail@web35302.mail.mud.yahoo.com>

No, 

But you can hard-code it in. 

There's a setting on the robots called "human factor"

They default to human factor 0. (Think Terminator,
Arnold Schwarzeneger)

With a human factor 10. They can't even shoot
straight. 

We can modify newbie.c to send the robots in with
whatever human factor you want. 

I'll eventually need to add this feature into newbie
to read the sysdef to make such a change convenient
and easy. 

So we can have a "truly newbie" server, and "not so
newbie" server ;-P. 

Jimmy


--- William Balcerski <williamb at its.caltech.edu>
wrote:

> I'm gonna sorta miss the robots that act all dumb,
> it was actually fun in
> a way to play against them with such bad AI.  And it
> might even be
> more useful for a newbie who is just as clueless to
> play against such
> robots.  Could there be a way to tone down robot AI
> (not just dogfighting
> skill) with a sysdef option?
> Bill
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From stephen.thorne at gmail.com  Wed May 24 21:34:48 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 25 May 2006 12:34:48 +1000
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <Pine.GSO.4.58.0605241813390.18098@sue>
References: <Pine.GSO.4.58.0605241813390.18098@sue>
Message-ID: <3e8ca5c80605241934h389f8944i3654a2656c239c5@mail.gmail.com>

On 5/25/06, William Balcerski <williamb at its.caltech.edu> wrote:
> I'm gonna sorta miss the robots that act all dumb, it was actually fun in
> a way to play against them with such bad AI.  And it might even be
> more useful for a newbie who is just as clueless to play against such
> robots.  Could there be a way to tone down robot AI (not just dogfighting
> skill) with a sysdef option?

I too find this frustrating.

Things that I've found that make the robots easier to play against,
but it's really just redefining your playing style, which is really
hard.

Cripping enemy ships instead of killing them, only ever running around
with 1 kill, commit suicide or run away if you get more than 4 kills
(by accident), do takes in multiple runs or by following your own
bots, stuff like that.

I'd really like an option, "don't send every single enemy bot to ogg
the player" :p

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Wed May 24 21:45:42 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 19:45:42 -0700 (PDT)
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <20060525013358.50305.qmail@web35302.mail.mud.yahoo.com>
References: <20060525013358.50305.qmail@web35302.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605241934570.28798@shell3.speakeasy.net>

On Wed, 24 May 2006, Jimmy Huang wrote:
> But you can hard-code it in.

The robot has the ability to read a command file on startup.  In this file,
you could put a command like "hm 10" or whatever to dumb them down.  Have the
newbie server start the bot with -C etcdir/newbie.commands, then stick your
human level and what not in the newbie.commands files.  You could also tell
the bot about bounce plasma, galaxy ships, and wrap around walls here.  The
bot actually has code to play with these things.

I think your new mad ogger robot code should have a command to toggle it.  I
can imagine, this makes the robots much harder to play against.


From xyzzy at speakeasy.org  Wed May 24 22:06:40 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 20:06:40 -0700 (PDT)
Subject: [netrek-dev] Robot improvement, and res-rsa configure script
Message-ID: <Pine.LNX.4.58.0605241952020.28798@shell3.speakeasy.net>

This patch helps the robot deal with ping-pong plasmas.  It has code to deal
them already, but it doesn't quite handle the style of ping-pongs on the
server now.

This includes a change to the server.  It doesn't change the protocol, but
sends the client slightly different information when ping-pong plasmas are
turned on.

The second patch remove the res-rsa configure script, like the Vanilla one has
been removed.

Here are the descriptions from the patches, which I'm gzipping because they
are too large:

  In Ping-Pong plasma mode, a plasma changes teams when it is bounced.
  There is no way to send this change to the client, so the client doesn't
  know.  For example, if a player at peace with us but who we are at war
  with bounces our (or a teammate's) plasma back at us, it appears to the
  client that the plasma is friendly.  But really, it's not, since we are
  at war with the plasma's new team.  Fix this by setting the plasma's war
  flag if the player is hostile to the plasma's team.

  In order to take advantage of this, clients will need to be sure to:
  1. Not assume that the player's own plasma is friendly.
  2. Not assume that plasma from the player's team is friendly.
  3. Make sure the check the plasma's war flags, and not the flags of the
  player who fired it.

  The robot has code to deal with Ping-Pong plasma, but it's an old
  version.  It doesn't work properly with the current ping pong plasmas,
  written by Trent Piepho in 1995 (so the old ones are really old!).
  Basically, the bots needs to allow for plasma fired by a friendly player
  becoming hostile to it.

  Also sets the pl_team member of the plasma struct, which makes getting
  the plasma's team easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robot-ping-pong.darcs.gz
Type: application/octet-stream
Size: 9063 bytes
Desc: 
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060524/ee601aea/attachment-0001.obj 

From xyzzy at speakeasy.org  Wed May 24 22:07:20 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 20:07:20 -0700 (PDT)
Subject: [netrek-dev] The resrsa configure removal patch
Message-ID: <Pine.LNX.4.58.0605242006430.28798@shell3.speakeasy.net>

Too big for last message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resrsa-configure.darcs.gz
Type: application/octet-stream
Size: 19937 bytes
Desc: 
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060524/107b2138/attachment.obj 

From stephen.thorne at gmail.com  Wed May 24 23:05:25 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 25 May 2006 14:05:25 +1000
Subject: [netrek-dev] netrek-dev Digest, Vol 15, Issue 64
In-Reply-To: <20060524225051.GA5052@us.netrek.org>
References: <mailman.182.1148427222.31331.netrek-dev@us.netrek.org>
	<BF935A1A-69E5-4548-B8BF-50B38C8DDBAD@luky.nl>
	<20060524225051.GA5052@us.netrek.org>
Message-ID: <3e8ca5c80605242105j75c49c41i90eba6ccdc72e4f@mail.gmail.com>

On 5/25/06, James Cameron <quozl at us.netrek.org> wrote:
> On Thu, May 25, 2006 at 12:09:43AM +0200, Chris en Judith wrote:
> > Very far, but i could help generate a server binary for OS X if you
> > would like?
>
> Now that would be good.  Stephen Thorne is another OS X user on list, he
> might be able to collaborate.
>
> We'll be hosting stuff on http://www.netrek.org/ once the software tree
> is back in place.

Would you like PPC binaries? I can generate them, built on Tiger.

Latest source from darcs is required, plus junk from darwinports. Talk
to me off list if you'd like a hand building Vanilla yourself.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Wed May 24 23:08:25 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 25 May 2006 14:08:25 +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: <3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>

> +#define N_WARMONGER    "George Bush"   /* For T-mode messages */

I'm intending to take this patch unless a better patch is presented.

(in-reply-to http://mailman.us.netrek.org/pipermail/netrek-dev/2006-April/002882.html
for those who don't have history back to april for this list)
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From quozl at us.netrek.org  Wed May 24 23:19:07 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Thu, 25 May 2006 14:19:07 +1000
Subject: [netrek-dev] darcs patch: deprecate dan quayle in t-mode messages
Message-ID: <E1Fj7JT-0000ZU-CR@dors.lan>

Thu May 25 14:13:44 EST 2006  quozl at us.netrek.org
  * deprecate dan quayle in t-mode messages
  
  	* include/defs.h (WARMONGER): add customisation setting for
  	configuration of local warmonger, so that we are not caught by
  	change again so easily.
  
  	* ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
  	favour of George Bush, subject to mailing list discussion.  Patch
  	by: William Balcerski with rework by James Cameron.
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 24135 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/b7cc8ce6/attachment-0001.bin 

From xyzzy at speakeasy.org  Wed May 24 23:57:36 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 21:57:36 -0700 (PDT)
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>

On Thu, 25 May 2006, Stephen Thorne wrote:
> > +#define N_WARMONGER    "George Bush"   /* For T-mode messages */
>
> I'm intending to take this patch unless a better patch is presented.

Not that I disagree, but this is still a very inflammatory issue.  Maybe
it would be a good idea to wait a decade or so.


From jrd at gerdesas.com  Thu May 25 00:05:31 2006
From: jrd at gerdesas.com (John R. Dennison)
Date: Thu, 25 May 2006 00:05:31 -0500
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
Message-ID: <20060525050531.GY2259@gerdesas.gerdesas.com>

On Wed, May 24, 2006 at 09:57:36PM -0700, Trent Piepho wrote:
> 
> Not that I disagree, but this is still a very inflammatory issue.  Maybe
> it would be a good idea to wait a decade or so.

	He's a very inflammatory president...  Seems very appropriate,
	to be honest.



							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt


From quozl at us.netrek.org  Thu May 25 00:06:01 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 15:06:01 +1000
Subject: [netrek-dev] Robot improvement, and res-rsa configure script
In-Reply-To: <Pine.LNX.4.58.0605241952020.28798@shell3.speakeasy.net>
References: <Pine.LNX.4.58.0605241952020.28798@shell3.speakeasy.net>
Message-ID: <20060525050601.GK5052@us.netrek.org>

Taken, along with the res-rsa configure removal patch.
Thanks.

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


From stephen.thorne at gmail.com  Thu May 25 00:05:52 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 25 May 2006 15:05:52 +1000
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
Message-ID: <3e8ca5c80605242205y387b0889i8af65b3a47e58849@mail.gmail.com>

On 5/25/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> On Thu, 25 May 2006, Stephen Thorne wrote:
> > > +#define N_WARMONGER    "George Bush"   /* For T-mode messages */
> >
> > I'm intending to take this patch unless a better patch is presented.
>
> Not that I disagree, but this is still a very inflammatory issue.  Maybe
> it would be a good idea to wait a decade or so.

It seems james integrated the patch in response to what I said:

Thu May 25 14:13:44 EST 2006  quozl at us.netrek.org
  * deprecate dan quayle in t-mode messages

        * include/defs.h (WARMONGER): add customisation setting for
        configuration of local warmonger, so that we are not caught by
        change again so easily.

        * ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
        favour of George Bush, subject to mailing list discussion.  Patch
        by: William Balcerski with rework by James Cameron.

A suggested enhancmenet I'd take a patch for is to add a ./configure
option for this.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Thu May 25 00:12:34 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 24 May 2006 22:12:34 -0700 (PDT)
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <Pine.LNX.4.58.0605241934570.28798@shell3.speakeasy.net>
Message-ID: <20060525051234.56510.qmail@web35313.mail.mud.yahoo.com>

[William wrote]
> I too find this frustrating.
> 
> Things that I've found that make the robots easier
> to play against,
> but it's really just redefining your playing style,
> which is really
> hard.
 
Heh. I had 2 goals when improving Hadley's AI. Both
really haven't been reached yet :-(. 

1. When an extremely clued player joins a game full of
robots, he couldn't make a difference. 

i.e. 8 Bot Roms vs. 1 human and 7 Bot Feds. Extreme
Clue doesn't cause Feds to win the game. 

2. In an 8 Bots vs. 8 Clued Humans game, Human's do
not, and cannot genocide the Bots. The bot's get cored
to 5 or 2 planets, but no geno. 

> I'd really like an option, "don't send every single
> enemy bot to ogg
> the player" :p

This is what happens in an INL game if they know
you've been carrying and are their only carrier :-). 

Anyways, point has been taken. 

--- Trent Piepho <xyzzy at speakeasy.org> wrote:
> On Wed, 24 May 2006, Jimmy Huang wrote:
> > But you can hard-code it in.
> 
> The robot has the ability to read a command file on
> startup.  In this file,
> you could put a command like "hm 10" or whatever to
> dumb them down.  Have the
> newbie server start the bot with -C
> etcdir/newbie.commands, then stick your
> human level and what not in the newbie.commands
> files.  You could also tell
> the bot about bounce plasma, galaxy ships, and wrap
> around walls here.  The
> bot actually has code to play with these things.
> 
> I think your new mad ogger robot code should have a
> command to toggle it.  I
> can imagine, this makes the robots much harder to
> play against.

You think I can just use the human factor level? Say
any human factor of 2,1,or 0 have the mad ogger. And
anything 3 or above (or some other cutoff), ignore?  

Or would you rather prefer a whole separate toggle?

Okay, looks like 2 coding requests. Make newbie.c
spawn robots that read a customizeable setup file.
Somehow make "mad ogger mode" a toggle switch, either
through human factor or whatever. 

It wasn't meant to be a mad ogger mode. The bots have
a single-mindedness about them. If they bomb, they do
nothing but bomb, while humans, are better at juggling
priorities. The code was to make them be able to
switch from bombing to ogging if a carrier was close
by (this is what alot of good clued players do). 

Also, I wanted to improve the ogging code. The ogging
code was originally designed to ogg starbases. If U
run away, they should uncloak and follow, instead of
staying cloaked, which they do now. 

I wanna add a "twink" mode. Have the bots act like a
regular twink. Someone who horks other people's kills
and then does anything to stay alive. It'd be funny as
hell!

Jimmy



From quozl at us.netrek.org  Thu May 25 00:20:11 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 May 2006 15:20:11 +1000
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
Message-ID: <20060525052011.GL5052@us.netrek.org>

On Wed, May 24, 2006 at 09:57:36PM -0700, Trent Piepho wrote:
> Not that I disagree, but this is still a very inflammatory issue.
> Maybe it would be a good idea to wait a decade or so.

Have you an alternate suggestion other than Dan Quayle?

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


From williamb at its.caltech.edu  Thu May 25 00:20:40 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 24 May 2006 22:20:40 -0700 (PDT)
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <20060525051234.56510.qmail@web35313.mail.mud.yahoo.com>
References: <20060525051234.56510.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <Pine.GSO.4.58.0605242220020.24547@clyde>

> I wanna add a "twink" mode. Have the bots act like a
> regular twink. Someone who horks other people's kills
> and then does anything to stay alive. It'd be funny as
> hell!
>
Now this might be the best bot suggestion I've heard yet.
Bill


From xyzzy at speakeasy.org  Thu May 25 00:45:27 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 24 May 2006 22:45:27 -0700 (PDT)
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <20060525052011.GL5052@us.netrek.org>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
	<20060525052011.GL5052@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605242231250.23787@shell3.speakeasy.net>

On Thu, 25 May 2006, James Cameron wrote:
> On Wed, May 24, 2006 at 09:57:36PM -0700, Trent Piepho wrote:
> > Not that I disagree, but this is still a very inflammatory issue.
> > Maybe it would be a good idea to wait a decade or so.
>
> Have you an alternate suggestion other than Dan Quayle?

Ghengis Khan?  Leonard George Casley?

I'd just leave it at Dan Quayle, and let those who setup servers change the
warmonger value to their favorite.  You could even allow it to be set with the
configure script.


From jrd at gerdesas.com  Thu May 25 01:10:46 2006
From: jrd at gerdesas.com (John R. Dennison)
Date: Thu, 25 May 2006 01:10:46 -0500
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <Pine.LNX.4.58.0605242231250.23787@shell3.speakeasy.net>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
	<20060525052011.GL5052@us.netrek.org>
	<Pine.LNX.4.58.0605242231250.23787@shell3.speakeasy.net>
Message-ID: <20060525061046.GA2259@gerdesas.gerdesas.com>

On Wed, May 24, 2006 at 10:45:27PM -0700, Trent Piepho wrote:
> 
> I'd just leave it at Dan Quayle, and let those who setup servers change the
> warmonger value to their favorite.  You could even allow it to be set with the
> configure script.

	This would force user's that use binary packages to have to
	recompile in order to change it.  Is there any chance of 
	getting this as a run-time configurable option in the sysdef
	config file?



						John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt


From stephen.thorne at gmail.com  Thu May 25 01:22:25 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 25 May 2006 16:22:25 +1000
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <20060525061046.GA2259@gerdesas.gerdesas.com>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
	<20060525052011.GL5052@us.netrek.org>
	<Pine.LNX.4.58.0605242231250.23787@shell3.speakeasy.net>
	<20060525061046.GA2259@gerdesas.gerdesas.com>
Message-ID: <3e8ca5c80605242322x1aa7a21al817e75a07084744a@mail.gmail.com>

On 5/25/06, John R. Dennison <jrd at gerdesas.com> wrote:
>         This would force user's that use binary packages to have to
>         recompile in order to change it.  Is there any chance of
>         getting this as a run-time configurable option in the sysdef
>         config file?

That sounds like an idea. I'd accept a patch that did that.
-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From netrek at gmail.com  Thu May 25 03:07:21 2006
From: netrek at gmail.com (Zach)
Date: Thu, 25 May 2006 08:07:21 +0000
Subject: [netrek-dev] Minor T-mode message change
In-Reply-To: <3e8ca5c80605242322x1aa7a21al817e75a07084744a@mail.gmail.com>
References: <Pine.GSO.4.58.0604101939030.7069@sue>
	<3e8ca5c80604102137l739e5663v3a6174a8aee804d4@mail.gmail.com>
	<Pine.GSO.4.58.0604102230180.9945@sue>
	<3e8ca5c80605242108n4fff646eq670b0cad13aa10b7@mail.gmail.com>
	<Pine.LNX.4.58.0605242155470.6338@shell3.speakeasy.net>
	<20060525052011.GL5052@us.netrek.org>
	<Pine.LNX.4.58.0605242231250.23787@shell3.speakeasy.net>
	<20060525061046.GA2259@gerdesas.gerdesas.com>
	<3e8ca5c80605242322x1aa7a21al817e75a07084744a@mail.gmail.com>
Message-ID: <ecfa260c0605250107j15da03cducf28ff9f5e1de280@mail.gmail.com>

A few candidates:

Lyndon B. Johnson
John F. Kennedy
Franklin D. Roosevelt

By just about any metric their warmongering eclipsed that of Bush.

Zach


From keyos at keyos.org  Thu May 25 04:42:44 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Thu, 25 May 2006 12:42:44 +0300 (IDT)
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <20060524235225.GB5052@us.netrek.org>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
	<Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>
	<20060524235225.GB5052@us.netrek.org>
Message-ID: <Pine.GSO.4.63.0605251230570.5911@fcnep.argivfvba.arg.vy>

On Thu, 25 May 2006, James Cameron wrote:

> I've read the MajorFeatures page and the main page, and I agree, it
> looks appealing.  I'll consider it after a few more months with darcs,
> because at the moment the only significant problem I'm having with darcs
> is the performance presumably due to ChangeLog.  In other ways, darcs
> is doing fine for me.
>

Well my major problem these days is that I can't normally diff versions
of the repositories. And I couldn't find any 'cvs log' alternative.

Dunno if this is only Solaris, but any darcs diff operation returns me 
following:

darcs: /tmp/new-netrek-server: setCurrentDirectory: does not exist (No such file or directory)

The repository is located under /home/darcs/netrek-server, so I don't 
understand where this /tmp... comes from.
 
So I can only darcs annotate (per file) which is annoying.

Moreover comparing Haskell (darcs) installation versus Python (mercurial) 
is very easy: Haskell -10 : Python +10
Python wins :)

BTW, I installed mercurial yesterday and have only positive experience
up to now. Created repository, edited, cloned, committed, diffed - 
everything works like a charm.

And it's robust, and ... wait, I begin feeling like salesman. Nevermind.

Think faster :) Couple more months with darcs and I'll have ulcer.

Stas.

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


From stephen.thorne at gmail.com  Thu May 25 05:12:25 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Thu, 25 May 2006 20:12:25 +1000
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.GSO.4.63.0605251230570.5911@fcnep.argivfvba.arg.vy>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
	<Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>
	<20060524235225.GB5052@us.netrek.org>
	<Pine.GSO.4.63.0605251230570.5911@fcnep.argivfvba.arg.vy>
Message-ID: <3e8ca5c80605250312h4a2b36aaw193d8d7d2af6a7b1@mail.gmail.com>

On 5/25/06, Stas Pirogov <keyos at keyos.org> wrote:
> Dunno if this is only Solaris, but any darcs diff operation returns me
> following:
>
> darcs: /tmp/new-netrek-server: setCurrentDirectory: does not exist (No such file or directory)
>
> The repository is located under /home/darcs/netrek-server, so I don't
> understand where this /tmp... comes from.
>

Astounding, file a bug. Please

> So I can only darcs annotate (per file) which is annoying.

darcs annotate sucks. I'm very close to having a replacement done.
(python wrapper)

> Moreover comparing Haskell (darcs) installation versus Python (mercurial)
> is very easy: Haskell -10 : Python +10
> Python wins :)

I agree.

> BTW, I installed mercurial yesterday and have only positive experience
> up to now. Created repository, edited, cloned, committed, diffed -
> everything works like a charm.
>
> And it's robust, and ... wait, I begin feeling like salesman. Nevermind.

This is a serious suggestion. Download tailor, and use tailor to sync
a merucial repo with a darcs repo. See how it goes. You can use tailor
2-way if you're brave.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Thu May 25 07:08:09 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 25 May 2006 05:08:09 -0700 (PDT)
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.GSO.4.63.0605251230570.5911@fcnep.argivfvba.arg.vy>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
	<Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>
	<20060524235225.GB5052@us.netrek.org>
	<Pine.GSO.4.63.0605251230570.5911@fcnep.argivfvba.arg.vy>
Message-ID: <Pine.LNX.4.58.0605250505000.18325@shell3.speakeasy.net>

On Thu, 25 May 2006, Stas Pirogov wrote:
> Well my major problem these days is that I can't normally diff versions
> of the repositories. And I couldn't find any 'cvs log' alternative.

darcs changes appears to be the way to do that.

> Dunno if this is only Solaris, but any darcs diff operation returns me
> following:
>
> darcs: /tmp/new-netrek-server: setCurrentDirectory: does not exist (No such file or directory)

It looks like darcs creates a new directory under /tmp when you do
a diff and puts a bunch of files in it, then diffs them.  Maybe you
should set TMPDIR to a directory you have write access to.



From xyzzy at speakeasy.org  Thu May 25 07:22:31 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 25 May 2006 05:22:31 -0700 (PDT)
Subject: [netrek-dev] Sysdef option for stupid robots
In-Reply-To: <20060525051234.56510.qmail@web35313.mail.mud.yahoo.com>
References: <20060525051234.56510.qmail@web35313.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605250519370.18325@shell3.speakeasy.net>

On Wed, 24 May 2006, Jimmy Huang wrote:
> You think I can just use the human factor level? Say
> any human factor of 2,1,or 0 have the mad ogger. And
> anything 3 or above (or some other cutoff), ignore?
>
> Or would you rather prefer a whole separate toggle?

I think a separate toggle would be better.  It's really
a pretty drastic change in their behaviour.


From xyzzy at speakeasy.org  Thu May 25 07:44:08 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 25 May 2006 05:44:08 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
Message-ID: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>

The patch adds armies carried by a player killed by a planet to the short
packets kill message.  It is put into the argument2 field in the KILLARGS2
short warning message, which was unused before.

The army count for player kills is transmitted differently, with four bits
in the DMKILL packet and one bit in KILLARGS.  Packing armies inside the
DMKILLP packet wouldn't work with existing clients and the KILLARGS packet
isn't sent for planet kills.  The second argument of KILLARGS2 isn't used
and that packet is already transmitted for planet kills, so it makes the
most sense to just use it.
-------------- next part --------------

New patches:

[planet doosh
Trent Piepho <xyzzy at speakeasy.org>**20060525122228
 Send information to clients to report the number of armies carried by a
 player killed by a planet.  The army count is transmitted in argument2 of
 the KILLARGS2 swarning packet, currently unused.
] 
<
> {
hunk ./Vanilla/ntserv/daemonII.c 2753
       arg[1] = j->p_no;
       arg[2] = l->pl_no;
       arg[3] = 0;
-      arg[4] = 0;
+      arg[4] = j->p_armies;
 #ifdef CHAIN_REACTION
       strcat(buf,"   [planet]");
       arg[5] = KPLANET;
hunk ./Vanilla/ntserv/genspkt.c 896
     case DMKILLP:
 #ifdef CHAIN_REACTION
 	if (why_dead) {
-	    swarning(KILLARGS2,(u_char)cur->args[5],0);
+	    swarning(KILLARGS2,(u_char)cur->args[5],(u_char)cur->args[4]);
 	}
 #endif
 	swarning(DMKILLP, (u_char)cur->args[1], (u_char)cur->args[2]);
}

Context:

[robotd omnibus 2 changelog
quozl at us.netrek.org**20060525003615
 Addition of ChangeLog and NEWS entries to cover Trent Piepho's rework 
 of Jimmy Huang's changes to robotd.
] 
[fix ranlib for solaris changelog
Stas Pirogov <keyos at keyos.org>**20060524235806] 
[fix ranlib for solaris
Stas Pirogov <keyos at keyos.org>**20060524235510
 
 	* configure.in: test for ranlib was failing on Solaris. This is
 	probably caused by different /bin/sh interpreters.  This fix should
 	satisfy all of them.
 
] 
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060524082754
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 players' torps too.  Without it, the bot thinks all torps are going
 straight up, making it a very bad dodger (unless you attack from below). 
   
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060524082708
 Some calls to req_cloak_off() were missing the function's argument,
 the reason string.
] 
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060524082437
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping the bots's own HW, for proximity.  This makes the code
 much smaller and faster.  Realistically, the HWs are always at the
 standard indexes, even with non-standard planet layouts.  Included a bit
 of code, #if'ed out, that will find home worlds by name, the way the bot
 does when it wants to refit.
] 
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060524082353
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060524082241
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060524082149
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060524082029
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
] 
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060524081723
 The assault planet code didn't re-check the target planet after the
 assault started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060524081613
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[robotd mfprintf regression fix
quozl at us.netrek.org*-20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com*-20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[PROJECTS update
williamb at its.caltech.edu**20060524093948
 Removed twarp observer bug from PROJECTS list, as this has been fixed.
] 
[Player position sign fix
williamb at its.caltech.edu**20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[conflict resolution 2006-08-24-a
quozl at us.netrek.org**20060524042919] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[fix SP_2 flag sending for real changelog
quozl at us.netrek.org**20060524024253] 
[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
[remove generated autotools files
quozl at us.netrek.org**20060524015023
 aclocal.m4 and configure are generated files, they are generated using
 autogen.sh from configure.in, and as such they do not deserve to be in the
 repository and are costing us time and energy as they change.
] 
[misc bugs update
quozl at us.netrek.org**20060524014925] 
[deprecate README.darcs execution in favour of autogen.sh changelog
quozl at us.netrek.org**20060524011944] 
[deprecate README.darcs execution in favour of autogen.sh
quozl at us.netrek.org**20060524011759
 
 	* autogen.sh: add GNU standard autotools configuration sequence,
 	deprecating execution of README.darcs.  Manual build process then
 	becomes "sh autogen.sh" followed by the usual configure, make, and
 	make install.
 
] 
[newbie-fixes.dpatch changelog conflict resolution
quozl at us.netrek.org**20060524005953] 
[newbie-fixes.dpatch
jimmyhua73 at yahoo.com**20060523153223
 
  Bug fixes:
 
   1. Merlin gets moved on genocide. Now Merlin moves himself back.
   2. You can get Merlin into a race condition by timing your join and
   joining something other than what Merlin chooses for the warring teams.
   This is fixed (I think). I was never able to time this right!!!
   James please check again!
 
  Known Bug:
 
  1. t-mode criteria is hardcoded into Merlin as 4 players a side.
 
  ChangeLog here:
 
      * robots/newbie.c changed some tabbing for better indent and bracing
      consistency.
 
      * robots/newbie.c added #defines POSITIONX and POSITIONY so there's
      only one place the change the desired x and y position of Merlin
 
      * robots/newbie.c added checkpos() function which checks for changes
      in Merlin's position. Replaces him back into POSITIONX and POSITIONY
      once it finds that Merlin has stopped moving for 15 seconds.
 
      * robots/newbie.c corrected misspellings of various comments
 
      * robots/newbie.c modified num_players() function to return
      the correct *next_team based on t-mode settings also
 
] 
[robotd_udcounter.dpatch
jimmyhua73 at yahoo.com**20060523143934
 
 I re-did the setflag() function, so it now will always report back
 a positive incrementing int at 100ms intervals. And it starts with 0
 on program start. 
 
 There are some other places that initialize _udcounter, I think this
 might need to be got rid of, but I didn't do that in this patch. 
 
 Read the longwinded diatribe in the Changelog. 
 
] 
[newbie-install-docs-update.dpatch
jimmyhua73 at yahoo.com**20060523155757
 
 Updated the installation document for newbie
 
] 
[robotd mfprintf regression fix changelog
quozl at us.netrek.org**20060524004957] 
[robotd mfprintf regression fix
quozl at us.netrek.org**20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[revised coding style and darcs discipline
quozl at us.netrek.org**20060523050927
 Rewrite of the coding style and patch acceptance criteria based on 
 feedback on the mailing list from Stephen Thorne and Trent Piepho.
] 
[Declare_war fix
williamb at its.caltech.edu**20060522012930
         * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
           added boolean to declare_war function to indicate whether to
           add delay and send delay message.  Fixes the case of unwanted 
           war delay message when switching teams, and also prevents robots
           from entering a state of permanent declare war delay.
] 
[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
29b5f3b3e36579a104668d9ac064a24716774eb9

From keyos at keyos.org  Thu May 25 08:20:49 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Thu, 25 May 2006 16:20:49 +0300 (IDT)
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.LNX.4.58.0605250505000.18325@shell3.speakeasy.net>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605232304v6d2959c1g8d3948114bbe1e55@mail.gmail.com>
	<Pine.GSO.4.63.0605250157580.3159@fcnep.argivfvba.arg.vy>
	<20060524235225.GB5052@us.netrek.org>
	<Pine.GSO.4.63.0605251230570.5911@fcnep.argivfvba.arg.vy>
	<Pine.LNX.4.58.0605250505000.18325@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.63.0605251619180.5911@fcnep.argivfvba.arg.vy>

On Thu, 25 May 2006, Trent Piepho wrote:

> darcs changes appears to be the way to do that.
>

Oh, that's a relief
 
> > Dunno if this is only Solaris, but any darcs diff operation returns me
> > following:
> >
> > darcs: /tmp/new-netrek-server: setCurrentDirectory: does not exist (No such file or directory)
> 
> It looks like darcs creates a new directory under /tmp when you do
> a diff and puts a bunch of files in it, then diffs them.  Maybe you
> should set TMPDIR to a directory you have write access to.
>

Apparently binary that comes from darcs.net was broken. Just compiled from
sources and everything works ok. (And sure I had permissions to /tmp :)


Thanks for help.

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


From williamb at its.caltech.edu  Thu May 25 14:13:17 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Thu, 25 May 2006 14:13:17 -0500
Subject: [netrek-dev] darcs patch: Alt planet doosh
Message-ID: <200605251913.k4PJDHrh019418@omen.digital-genesis.com>

Thu May 25 14:10:11 CDT 2006  williamb at its.caltech.edu
  * Alt planet doosh
      * daemonII.c: Changes planet doosh messages to same format as player doosh messages.
        Both short/long packets can receive the doosh information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 18107 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/3fd5ceca/attachment.bin 

From williamb at its.caltech.edu  Thu May 25 14:14:46 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Thu, 25 May 2006 12:14:46 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
References: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605251213450.18949@blinky>

I think it would be better to mirror how player dooshes are sent, so that
both short and long packets get the information, patch to follow.



From williamb at its.caltech.edu  Thu May 25 15:13:48 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Thu, 25 May 2006 15:13:48 -0500
Subject: [netrek-dev] darcs patch: Alt planet doosh
Message-ID: <200605252013.k4PKDmep021746@omen.digital-genesis.com>

Thu May 25 15:12:09 CDT 2006  williamb at its.caltech.edu
  * Alt planet doosh
       * daemonII.c: Changes planet doosh messages to same format as player doosh messages.
         Both short/long packets can receive the doosh information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 18129 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/0547ae44/attachment-0001.bin 

From keyos at keyos.org  Thu May 25 15:58:14 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Thu, 25 May 2006 23:58:14 +0300 (IDT)
Subject: [netrek-dev] Patch + couple of things
In-Reply-To: <Pine.LNX.4.58.0605231305070.22502@shell3.speakeasy.net>
References: <Pine.GSO.4.63.0605231419030.1040@fcnep.argivfvba.arg.vy>
	<Pine.LNX.4.58.0605231305070.22502@shell3.speakeasy.net>
Message-ID: <Pine.GSO.4.63.0605252352400.20071@fcnep.argivfvba.arg.vy>

On Tue, 23 May 2006, Trent Piepho wrote:

> There is no easy version number like in CVS or Mercurial.  The is a large
> hash value for each patch, but I haven't found out how you get it.
>

You can get it by using 'darcs changes --xml-output'. Most useful output
I've seen up to now.

So you can actually:

darcs diff --match="hash 20060426130158-e4f26-95127653ab70ab4e79a2be331ac863cbc5b1d9b5.gz"

Taken from: http://darcs.net/DarcsWiki/FrequentlyAskedQuestions

Stas.
 


From xyzzy at speakeasy.org  Thu May 25 19:43:31 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 25 May 2006 17:43:31 -0700 (PDT)
Subject: [netrek-dev] darcs patch: Alt planet doosh
In-Reply-To: <200605251913.k4PJDHrh019418@omen.digital-genesis.com>
References: <200605251913.k4PJDHrh019418@omen.digital-genesis.com>
Message-ID: <Pine.LNX.4.58.0605251742580.1926@shell2.speakeasy.net>

On Thu, 25 May 2006 williamb at its.caltech.edu wrote:

> Thu May 25 14:10:11 CDT 2006  williamb at its.caltech.edu
>   * Alt planet doosh
>       * daemonII.c: Changes planet doosh messages to same format as player doosh messages.
>         Both short/long packets can receive the doosh information.
>

Don't change the legacy packet format.


From xyzzy at speakeasy.org  Thu May 25 19:47:59 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 25 May 2006 17:47:59 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.GSO.4.58.0605251213450.18949@blinky>
References: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605251213450.18949@blinky>
Message-ID: <Pine.LNX.4.58.0605251744250.1926@shell2.speakeasy.net>

On Thu, 25 May 2006, William Balcerski wrote:

> I think it would be better to mirror how player dooshes are sent, so that
> both short and long packets get the information, patch to follow.

I don't think you understand what you're doing.  You are not sending the
information for short packets, only with the text sent for legacy clients.

You are also annoying re-indenting the code.  Why is this so hard for
people to get right?  Changing two lines of code without changing the
indention of the dozen lines you didn't touch shouldn't be hard.  darcs
even has its nice interactive patch selector.


From jimmyhua73 at yahoo.com  Thu May 25 19:58:10 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 25 May 2006 17:58:10 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.LNX.4.58.0605251744250.1926@shell2.speakeasy.net>
Message-ID: <20060526005810.67136.qmail@web35314.mail.mud.yahoo.com>

> You are also annoying re-indenting the code.  Why is
> this so hard for
> people to get right?  Changing two lines of code
> without changing the
> indention of the dozen lines you didn't touch
> shouldn't be hard.  darcs
> even has its nice interactive patch selector.

Hello alls, 

Here is my .emacs file to help with keeping the
indentation consistent. If you use emacs, this will
help alot.

As I work with mostly robotd code, I have the:

(setq c-default-style "bsd"
     c-basic-offset 3)

However, if working with netrek-server code, change
that to 4, and I think you should be good to go. 


Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .emacs
Type: application/octet-stream
Size: 446 bytes
Desc: 2460494731-.emacs
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/ef873fba/attachment.obj 

From netrek at gmail.com  Thu May 25 20:29:38 2006
From: netrek at gmail.com (Zach)
Date: Thu, 25 May 2006 21:29:38 -0400
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <20060526005810.67136.qmail@web35314.mail.mud.yahoo.com>
References: <Pine.LNX.4.58.0605251744250.1926@shell2.speakeasy.net>
	<20060526005810.67136.qmail@web35314.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605251829p7fb3e8f1j6601a697fe73dbc3@mail.gmail.com>

On 5/25/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>
> As I work with mostly robotd code, I have the:
>
> (setq c-default-style "bsd"
>      c-basic-offset 3)

Thanks for that info Jimmy. So in Emacs this will make the cursor move
4 spaces if you hit the TAB key right?

Zach


From williamb at its.caltech.edu  Thu May 25 20:31:03 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Thu, 25 May 2006 18:31:03 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.LNX.4.58.0605251744250.1926@shell2.speakeasy.net>
References: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
	<Pine.GSO.4.58.0605251213450.18949@blinky>
	<Pine.LNX.4.58.0605251744250.1926@shell2.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605251818220.11104@sue>

> I don't think you understand what you're doing.  You are not sending the
> information for short packets, only with the text sent for legacy clients.
>
Your solution for short packets is a good one.  I didn't include the
genspkt.c file, but I would not change anything there (this patch assumes
your patch has already been applied).  Both short and long packets are
successfully sent to client with the new army doosh info.  I have tested
it on the client I work with.

As for the "don't change legacy format" argument, if it doesn't break a
single client, and only makes old clients better (by giving them planet
doosh info), where is the harm?  If we continue to just change short
packets for all new info we send to clients, we force people to upgrade to
the newest clients to get the informational advantage that comes with
server changes.  Maybe we want to do that, force people to upgrade.  If
that's the consensus, I'd accept it (my personal opinion is we should not
force upgrade).  If I'm playing 10 year old COW, or some other really
old client without short packets, and I had the choice between the server
sending me info on planet doosh, vs not sending, why would I ever choose
to not get the doosh info?

> You are also annoying re-indenting the code.  Why is this so hard for
> people to get right?  Changing two lines of code without changing the
> indention of the dozen lines you didn't touch shouldn't be hard.  darcs
> even has its nice interactive patch selector.
>
Indentation looks fine to me.  Everything went in 4 spaces because of the
new if else loop to check if armies == 0 or not.  Similiar to how the code
looks in the player kill section.  Unless it's a problem with tabs vs
spaces?


From jimmyhua73 at yahoo.com  Thu May 25 20:58:03 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 25 May 2006 18:58:03 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <ecfa260c0605251829p7fb3e8f1j6601a697fe73dbc3@mail.gmail.com>
Message-ID: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>

> > (setq c-default-style "bsd"
> >      c-basic-offset 4)
> 
> Thanks for that info Jimmy. So in Emacs this will
> make the cursor move
> 4 spaces if you hit the TAB key right?

With the above, yeah that's right! 

You gotta change the .emacs file to whatever
indentation you are using. Put it in your home
directory. 

The .emacs file I sent, was at 3 spaces... 

There's a bunch more settings in the attached .emacs
file to convert everything to spaces. The reason
being, is that emacs will actually use a combination
of tabs and spaces. 

It looks good on emacs and with tabs and spaces, but
some programs like "more" will assume TAB means 4
spaces instead of 5, and then everything looks
whacked. 

But when you use, "less" everything looks okay again,
pretty bizzare. 

Took me a long while to get this .emacs file settings
to work right, cuz I kept trying to change my settings
in a file called .emacsrc which is wrong!!!


Jimmy



From jimmyhua73 at yahoo.com  Thu May 25 21:04:52 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 25 May 2006 19:04:52 -0700 (PDT)
Subject: [netrek-dev] dumbing down newbie with patches.
Message-ID: <20060526020452.72655.qmail@web35308.mail.mud.yahoo.com>

Okay, 

Here is the "fix" to make the robots dumber in newbie
mode. 

Modified newbie.c so that Merlin now sends in the
robots and makes the robots read a command file before
starting up. 

Modified INSTALL.Newbie with instructions on how to
make such a command file and test it out. There's no
limit on hm. You can put hm 100 and really watch the
robots turn into dumb zombies. (Pretty boring
actually)

2 patches here to keep my sanity. 1 for the changes in
code. And 1 for the Changelog. 

I'm not sure I want to put in a news item, as this
feature has been in the very first newbie server I
have seen back 3+ years ago. The code somehow got
lost. 

Jimmy

P.S., next to write is the "ogg_pesky_humans" toggle
in the robots, so people can turn it off ;-P. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie-configurable-robots-changelog.dpatch
Type: application/octet-stream
Size: 22750 bytes
Desc: 2044143249-newbie-configurable-robots-changelog.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/a1808a48/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie-configurable-robots.dpatch
Type: application/octet-stream
Size: 25200 bytes
Desc: 3341121968-newbie-configurable-robots.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/a1808a48/attachment-0003.obj 

From darius at dons.net.au  Thu May 25 21:36:21 2006
From: darius at dons.net.au (Daniel O'Connor)
Date: Fri, 26 May 2006 12:06:21 +0930
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
References: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
Message-ID: <200605261206.22924.darius@dons.net.au>

On Friday 26 May 2006 11:28, Jimmy Huang wrote:
> There's a bunch more settings in the attached .emacs
> file to convert everything to spaces. The reason
> being, is that emacs will actually use a combination
> of tabs and spaces.
>
> It looks good on emacs and with tabs and spaces, but
> some programs like "more" will assume TAB means 4
> spaces instead of 5, and then everything looks
> whacked.

Actually your TERMINAL thinks a tab is *8* character spaces. Telling your 
editor tabs are anything but 8 character spaces is counter productive - you 
can't change your terminal's interpretation of a tab character easily.

When you press tab in emacs when it's in c-mode it interprets it as "indent 
this line appropriately" - it looks at your code and checks the what indent 
level should be (in character spaces) and then turns that into the 
appropriate number of tabs and spaces.

Also, you can tell emacs to edit a specific file specially by adding this to 
the end..
/*
 * Local variables:
 * c-basic-offset: 4
 * End:
 */
(Although I wouldn't advocate modifying all the source files to do this)

-- 
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/20060526/0aee61de/attachment.pgp 

From jimmyhua73 at yahoo.com  Thu May 25 21:44:02 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 25 May 2006 19:44:02 -0700 (PDT)
Subject: [netrek-dev] dumbing down newbie with patches.
In-Reply-To: <20060526020452.72655.qmail@web35308.mail.mud.yahoo.com>
Message-ID: <20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>

ARRGH!

There's "bugs" in this patch. 

I took away the "INL" mode. But it turns out, this is
the mode that makes it so the bots don't listen to the
other players in the game. I thought the "blind" mode
did that. But apparently it does something else. 

Now you can type in commands and the bots listen to
you. 

James, your choice. Either don't apply the patch, and
I'll fix it completely and resend, or apply the patch
and I'll go back and fix it. 

Jimmy


--- Jimmy Huang <jimmyhua73 at yahoo.com> wrote:

> Okay, 
> 
> Here is the "fix" to make the robots dumber in
> newbie
> mode. 
> 
> Modified newbie.c so that Merlin now sends in the
> robots and makes the robots read a command file
> before
> starting up. 
> 
> Modified INSTALL.Newbie with instructions on how to
> make such a command file and test it out. There's no
> limit on hm. You can put hm 100 and really watch the
> robots turn into dumb zombies. (Pretty boring
> actually)
> 
> 2 patches here to keep my sanity. 1 for the changes
> in
> code. And 1 for the Changelog. 
> 
> I'm not sure I want to put in a news item, as this
> feature has been in the very first newbie server I
> have seen back 3+ years ago. The code somehow got
> lost. 
> 
> Jimmy
> 
> P.S., next to write is the "ogg_pesky_humans" toggle
> in the robots, so people can turn it off ;-P. 
> 
> 
> > _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From netrek at gmail.com  Thu May 25 22:50:17 2006
From: netrek at gmail.com (Zach)
Date: Thu, 25 May 2006 23:50:17 -0400
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
References: <ecfa260c0605251829p7fb3e8f1j6601a697fe73dbc3@mail.gmail.com>
	<20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605252050v3e38a8ffs7f277e4e4ef612a2@mail.gmail.com>

On 5/25/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>
> There's a bunch more settings in the attached .emacs
> file to convert everything to spaces. The reason
> being, is that emacs will actually use a combination
> of tabs and spaces.

Wow I wasn't aware of that. Thanks for the .emacs!

> But when you use, "less" everything looks okay again,
> pretty bizzare.

Hmm that does sound weird.

> Took me a long while to get this .emacs file settings
> to work right, cuz I kept trying to change my settings
> in a file called .emacsrc which is wrong!!!

Heh, I had same type of problem when I was setting up my BASH preferences.

Zach


From stephen.thorne at gmail.com  Thu May 25 23:19:07 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 26 May 2006 14:19:07 +1000
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <200605261206.22924.darius@dons.net.au>
References: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
	<200605261206.22924.darius@dons.net.au>
Message-ID: <3e8ca5c80605252119w4ffa58f1j2250a087de234569@mail.gmail.com>

On 5/26/06, Daniel O'Connor <darius at dons.net.au> wrote:
> Also, you can tell emacs to edit a specific file specially by adding this to
> the end..
> /*
>  * Local variables:
>  * c-basic-offset: 4
>  * End:
>  */
> (Although I wouldn't advocate modifying all the source files to do this)

I happen to think this is a good idea for the files where c-basic-offset is 3.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Thu May 25 23:20:58 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 26 May 2006 14:20:58 +1000
Subject: [netrek-dev] dumbing down newbie with patches.
In-Reply-To: <20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>
References: <20060526020452.72655.qmail@web35308.mail.mud.yahoo.com>
	<20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605252120s62757d93rd16aec02af5ae2ea@mail.gmail.com>

On 5/26/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> James, your choice. Either don't apply the patch, and
> I'll fix it completely and resend, or apply the patch
> and I'll go back and fix it.

I'm going to disregard this patch. Feel free to unrecord it and submit
a better one, or patch your patch and I'll apply both.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From xyzzy at speakeasy.org  Fri May 26 00:44:53 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Thu, 25 May 2006 22:44:53 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <3e8ca5c80605252119w4ffa58f1j2250a087de234569@mail.gmail.com>
References: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
	<200605261206.22924.darius@dons.net.au>
	<3e8ca5c80605252119w4ffa58f1j2250a087de234569@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0605252243050.13884@shell3.speakeasy.net>

On Fri, 26 May 2006, Stephen Thorne wrote:
> On 5/26/06, Daniel O'Connor <darius at dons.net.au> wrote:
> > Also, you can tell emacs to edit a specific file specially by adding this to
> > the end..
> > /*
> >  * Local variables:
> >  * c-basic-offset: 4
> >  * End:
> >  */
> > (Although I wouldn't advocate modifying all the source files to do this)
>
> I happen to think this is a good idea for the files where c-basic-offset is 3.

I don't use emacs, but I would be fine with this.  Most of the files in the
linux kernel have these emacs settings at the end.


From jimmyhua73 at yahoo.com  Fri May 26 00:52:53 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Thu, 25 May 2006 22:52:53 -0700 (PDT)
Subject: [netrek-dev] dumbing down newbie with patches.
In-Reply-To: <20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <20060526055253.92282.qmail@web35305.mail.mud.yahoo.com>

The fix was a one-liner change in code! 

INL mode was put back in. Changed a line in dmessage.c
so that it will listen to the guy in the local
terminal, but won't listen to any messages it gets
from other players or even God. This allowed the bots
to read the command file and use it. 

No sample command file, but there's an example in
INSTALL.Newbie

The nice thing about this patch, is it doesn't break
anything (Hadley's robots parse command options real
nicely). If the robots can't find a command file.. It
keeps going like you never asked it to read one. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie-configurable-robots.dpatch
Type: application/octet-stream
Size: 26003 bytes
Desc: 3341121968-newbie-configurable-robots.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/1fb890d3/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newbie-configurable-robots-changelog.dpatch
Type: application/octet-stream
Size: 23313 bytes
Desc: 2044143249-newbie-configurable-robots-changelog.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060525/1fb890d3/attachment-0003.obj 

From stephen.thorne at gmail.com  Fri May 26 02:57:06 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 26 May 2006 17:57:06 +1000
Subject: [netrek-dev] dumbing down newbie with patches.
In-Reply-To: <20060526055253.92282.qmail@web35305.mail.mud.yahoo.com>
References: <20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>
	<20060526055253.92282.qmail@web35305.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605260057g40a60b18ocafbe3f1e07638b3@mail.gmail.com>

Taken.

Please check the changelog. I think I have duplicate entries, but
don't have the tools to fix it up.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From stephen.thorne at gmail.com  Fri May 26 03:07:29 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Fri, 26 May 2006 18:07:29 +1000
Subject: [netrek-dev] dumbing down newbie with patches.
In-Reply-To: <3e8ca5c80605260057g40a60b18ocafbe3f1e07638b3@mail.gmail.com>
References: <20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>
	<20060526055253.92282.qmail@web35305.mail.mud.yahoo.com>
	<3e8ca5c80605260057g40a60b18ocafbe3f1e07638b3@mail.gmail.com>
Message-ID: <3e8ca5c80605260107r4f7abbb7i6887d5aa63dc98bf@mail.gmail.com>

On 5/26/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
> Please check the changelog. I think I have duplicate entries, but
> don't have the tools to fix it up.

Sorry, I integrated the patch in a stale branch. I've pushed one
that's a lot cleaner. Please don't worry about this.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From netrek at gmail.com  Fri May 26 03:49:06 2006
From: netrek at gmail.com (Zach)
Date: Fri, 26 May 2006 08:49:06 +0000
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.LNX.4.58.0605252243050.13884@shell3.speakeasy.net>
References: <20060526015803.56274.qmail@web35311.mail.mud.yahoo.com>
	<200605261206.22924.darius@dons.net.au>
	<3e8ca5c80605252119w4ffa58f1j2250a087de234569@mail.gmail.com>
	<Pine.LNX.4.58.0605252243050.13884@shell3.speakeasy.net>
Message-ID: <ecfa260c0605260149n24108d77ja2e6bbdef6496a85@mail.gmail.com>

Vi user?

Zach

On 5/26/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> On Fri, 26 May 2006, Stephen Thorne wrote:
> > On 5/26/06, Daniel O'Connor <darius at dons.net.au> wrote:
> > > Also, you can tell emacs to edit a specific file specially by adding this to
> > > the end..
> > > /*
> > >  * Local variables:
> > >  * c-basic-offset: 4
> > >  * End:
> > >  */
> > > (Although I wouldn't advocate modifying all the source files to do this)
> >
> > I happen to think this is a good idea for the files where c-basic-offset is 3.
>
> I don't use emacs, but I would be fine with this.  Most of the files in the
> linux kernel have these emacs settings at the end.
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>


From jimmyhua73 at yahoo.com  Fri May 26 21:03:13 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Fri, 26 May 2006 19:03:13 -0700 (PDT)
Subject: [netrek-dev] robotd new toggle switches.
Message-ID: <20060527020314.46025.qmail@web35308.mail.mud.yahoo.com>

Hi, 

Added some toggle switches to turn on/off some AI that
I added into Hadley's robots that are used in Newbie
servers. 

Both modes are off by default now, whereas before they
were hardcoded in and always on. 

hcr - toggle the assumption that humans carry
ogh - oggy happy mode. Changes to ogg mode while
bombing if a carrier is nearby. 

These use the global variables ogg_happy and hm_cr
found in data.h. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-toggle-newlogic-news.dpatch
Type: application/octet-stream
Size: 27374 bytes
Desc: 3705622924-robotd-toggle-newlogic-news.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060526/429a4c73/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-toggle-newlogic.dpatch
Type: application/octet-stream
Size: 33244 bytes
Desc: 3813668598-robotd-toggle-newlogic.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060526/429a4c73/attachment-0003.obj 

From quozl at us.netrek.org  Sat May 27 00:35:31 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 27 May 2006 15:35:31 +1000
Subject: [netrek-dev] dumbing down newbie with patches.
In-Reply-To: <20060526055253.92282.qmail@web35305.mail.mud.yahoo.com>
References: <20060526024402.5430.qmail@web35303.mail.mud.yahoo.com>
	<20060526055253.92282.qmail@web35305.mail.mud.yahoo.com>
Message-ID: <20060527053531.GA5456@us.netrek.org>

Agreed, taken.

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


From quozl at us.netrek.org  Sat May 27 00:39:42 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 27 May 2006 15:39:42 +1000
Subject: [netrek-dev] robotd new toggle switches.
In-Reply-To: <20060527020314.46025.qmail@web35308.mail.mud.yahoo.com>
References: <20060527020314.46025.qmail@web35308.mail.mud.yahoo.com>
Message-ID: <20060527053942.GB5456@us.netrek.org>

Taken.

Suggest that checking if a slot is a robot or human should be abstracted
into a separate function ... there was too much checking for "robot!" in
that patch for my liking.

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


From quozl at us.netrek.org  Sat May 27 00:49:50 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 27 May 2006 15:49:50 +1000
Subject: [netrek-dev] darcs patch: Alt planet doosh
In-Reply-To: <200605251913.k4PJDHrh019418@omen.digital-genesis.com>
References: <200605251913.k4PJDHrh019418@omen.digital-genesis.com>
Message-ID: <20060527054950.GF5456@us.netrek.org>

On Thu, May 25, 2006 at 02:13:17PM -0500, williamb at its.caltech.edu wrote:
> Thu May 25 14:10:11 CDT 2006  williamb at its.caltech.edu
>   * Alt planet doosh
>       * daemonII.c: Changes planet doosh messages to same format as
>       player doosh messages.  Both short/long packets can receive the
>       doosh information.

Rejected, because I don't want to change the old long packet
format.  Please place new features in either unused fields of the short
packets 2 protocol, or implement changes in a way that is flagged using
feature packets.  If there's something stopping you from using short
packets 2, let's find out why, and fix it using feature packets.

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


From quozl at us.netrek.org  Sat May 27 00:52:47 2006
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 27 May 2006 15:52:47 +1000
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
References: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
Message-ID: <20060527055247.GG5456@us.netrek.org>

On Thu, May 25, 2006 at 05:44:08AM -0700, Trent Piepho wrote:
> The patch adds armies carried by a player killed by a planet to the
> short packets kill message.  It is put into the argument2 field in the
> KILLARGS2 short warning message, which was unused before.

Technically acceptable, but I must be missing something ... what use is
this information to the client again?  What is the client going to do
with it?

Or is it just to enhance play by making it clear when a carrier dies to
a planet?

(The INL army tracking logic already handles this situation for INL
server mode.)

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


From williamb at its.caltech.edu  Sat May 27 01:23:04 2006
From: williamb at its.caltech.edu (williamb at its.caltech.edu)
Date: Sat, 27 May 2006 01:23:04 -0500
Subject: [netrek-dev] darcs patch: Chaos mode det fix
Message-ID: <200605270623.k4R6N4lK026260@omen.digital-genesis.com>

Sat May 27 01:20:43 CDT 2006  williamb at its.caltech.edu
  * Chaos mode det fix
      * detonate.c: The sysdef CHAOS option ignores weapontemp, except for on torp detonation.
        This patch fixes that inconsistency.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 16623 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060527/5607e8ac/attachment-0001.bin 

From jimmyhua73 at yahoo.com  Sat May 27 05:23:11 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 27 May 2006 03:23:11 -0700 (PDT)
Subject: [netrek-dev] robotd new toggle switches.
In-Reply-To: <20060527053942.GB5456@us.netrek.org>
Message-ID: <20060527102311.75438.qmail@web35314.mail.mud.yahoo.com>


Okay, I can do that.  Give me a few days. I'll send a
patch out. 

Btw, I noticed that it seems there is some mix up, and
although the changelogs and stuff are there, some of
the fixes to mfprintf and other stuff seems to be
missing...

Jimmy


--- James Cameron <quozl at us.netrek.org> wrote:

> Taken.
> 
> Suggest that checking if a slot is a robot or human
> should be abstracted
> into a separate function ... there was too much
> checking for "robot!" in
> that patch for my liking.
> 
> -- 
> James Cameron    mailto:quozl at us.netrek.org    
> http://quozl.netrek.org/
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From stephen.thorne at gmail.com  Sat May 27 18:04:30 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Sun, 28 May 2006 09:04:30 +1000
Subject: [netrek-dev] robotd new toggle switches.
In-Reply-To: <20060527102311.75438.qmail@web35314.mail.mud.yahoo.com>
References: <20060527053942.GB5456@us.netrek.org>
	<20060527102311.75438.qmail@web35314.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605271604u7be4907cl5bcf9a8449fedf68@mail.gmail.com>

On 5/27/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
>
> Okay, I can do that.  Give me a few days. I'll send a
> patch out.
>
> Btw, I noticed that it seems there is some mix up, and
> although the changelogs and stuff are there, some of
> the fixes to mfprintf and other stuff seems to be
> missing...

I'll have a look at this issue.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From netrek at gmail.com  Sat May 27 19:10:20 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 00:10:20 +0000
Subject: [netrek-dev] Vanilla build broken :(
Message-ID: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>

I had successfully built/installed the server a few days ago into /tmp
so I was going to build and install it for real this time so I did a
'darcs pull' from Quozl's repo and ran tests/build and now it dies!
argh. here is the output and fatal error is at the end:

zu22 at netrek:~/src/netrek-server/Vanilla$ ./tests/build

# test that current working directory matches darcs get expectation
if [ ! -f autogen.sh ]; then echo "build: run in wrong directory"; exit 1; fi

# where to build
#BUILDROOT=/tmp/netrek-server.$$
BUILDROOT=/home/zu22/bin/netrek-server.$$

# copy the repository there
darcs get .. $BUILDROOT
Copying patch 188 of 188... done!
Finished getting.

# go there
cd $BUILDROOT/Vanilla

# build configure
sh autogen.sh
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
autogen.sh completed ok

# configure
./configure --prefix=$BUILDROOT/out
checking for used sources... Vanilla SERVER
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... yes
checking whether make sets $(MAKE)... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for AIX... no
checking for inline... inline
checking if fd_set requires sys/select.h... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for unistd.h... (cached) yes
checking for memory.h... (cached) yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking for stdlib.h... (cached) yes
checking sys/timeb.h usability... yes
checking sys/timeb.h presence... yes
checking for sys/timeb.h... yes
checking sys/ptyio.h usability... no
checking sys/ptyio.h presence... no
checking for sys/ptyio.h... no
checking sys/fcntl.h usability... yes
checking sys/fcntl.h presence... yes
checking for sys/fcntl.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking machine/endian.h usability... no
checking machine/endian.h presence... no
checking for machine/endian.h... no
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking sys/filio.h usability... no
checking sys/filio.h presence... no
checking for sys/filio.h... no
checking gdbm.h usability... yes
checking gdbm.h presence... yes
checking for gdbm.h... yes
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking for gdbm_open in -lgdbm... yes
checking for wait3 that fills in rusage... yes
checking for pid_t... yes
checking for uid_t in sys/types.h... yes
checking for size_t... yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for itimer in time.h... no
checking for long... yes
checking size of long... 4
checking for u_int in sys/types.h... yes
checking for PATH_MAX in limits.h... yes
checking for main in -lgdi32... no
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for mp.h... ./configure: line 6781: syntax error near
unexpected token `}'
./configure: line 6781: `echo "${ECHO_T}no" >&6; }'

Zach


From netrek at gmail.com  Sat May 27 19:19:43 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 00:19:43 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
References: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
Message-ID: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>

Vanilla/configure script is also missing now. what is going on?

the old way worked for all these years why is someone drastically
altering the build/configure process??!

At least document in INSTALL how to build it now. I only found out
about tests/build script from  being in #netrek channel. If this was
replaced also by a new way to build why is it not documented in the
distribution? This really MUST be documented and put INSIDE the
Vanilla source tree PLEASE.

zach


From jimmyhua73 at yahoo.com  Sat May 27 19:37:19 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 27 May 2006 17:37:19 -0700 (PDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
Message-ID: <20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>

I agree it should have been documented. 

Before it used to be:

./configure --prefix==/tmp/netrek
make
make install

Now it is:

sh autogen.sh
./configure --prefix==/tmp/netrek
make
make
make install

You have to type make twice, as ranlib doesn't work
the way it should, but it clears up the 2nd time you
try. 

Also, you need a whole bunch of other software
packages that you didn't used to need. Figure out what
they are as when autogen crashes. I forgot what they
were (i should have written down what I did). 

Jimmy

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

> Vanilla/configure script is also missing now. what
> is going on?
> 
> the old way worked for all these years why is
> someone drastically
> altering the build/configure process??!
> 
> At least document in INSTALL how to build it now. I
> only found out
> about tests/build script from  being in #netrek
> channel. If this was
> replaced also by a new way to build why is it not
> documented in the
> distribution? This really MUST be documented and put
> INSIDE the
> Vanilla source tree PLEASE.
> 
> zach
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From jimmyhua73 at yahoo.com  Sat May 27 19:52:09 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 27 May 2006 17:52:09 -0700 (PDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
Message-ID: <20060528005209.39246.qmail@web35303.mail.mud.yahoo.com>

--- Zach <netrek at gmail.com> wrote:
> checking for u_int in sys/types.h... yes
> checking for PATH_MAX in limits.h... yes
> checking for main in -lgdi32... no
> checking for X... libraries /usr/X11R6/lib, headers
> /usr/X11R6/include
> checking for mp.h... ./configure: line 6781: syntax
> error near
> unexpected token `}'
> ./configure: line 6781: `echo "${ECHO_T}no" >&6; }'

Do you have mp.h libraries by any chance? I do not,
and I tried all the repos, and they build fine. 

The build process hasn't changed since you last used
it. 

modify the tests/build to the directory you want and
run the shell script. 

Jimmy



From xyzzy at speakeasy.org  Sat May 27 21:01:35 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Sat, 27 May 2006 19:01:35 -0700 (PDT)
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <20060527055247.GG5456@us.netrek.org>
References: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
	<20060527055247.GG5456@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605271847040.10604@shell3.speakeasy.net>

On Sat, 27 May 2006, James Cameron wrote:
> On Thu, May 25, 2006 at 05:44:08AM -0700, Trent Piepho wrote:
> > The patch adds armies carried by a player killed by a planet to the
> > short packets kill message.  It is put into the argument2 field in the
> > KILLARGS2 short warning message, which was unused before.
>
> Technically acceptable, but I must be missing something ... what use is
> this information to the client again?  What is the client going to do
> with it?

You get a kill message like this:

guest (F0+2 armies) [CA] killed by Capella (R)         [planet]

The server normally doesn't send the info at all, so there is no way for a
client to see this.  I guess the client could play a doosh sound or show some
kind of little man flying into space animation if the client had something
like that.

Really, it's no more or less useful than the armies killed info for normal
player kills.


From netrek at gmail.com  Sat May 27 21:22:00 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 02:22:00 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605271922g17be2467qe34897d31b103946@mail.gmail.com>

Hey Jimmy,

Ah ok. Well the error it died on was complaining about not finding the
GNU Multi-Precision Library include file mp.h (I went to the line in
the generated ./configure it referenced), but I clearly have this file
already installed:

netrek:~# dpkg -L libgmp3-dev
/.
/usr
/usr/lib
/usr/lib/libgmp.a
/usr/lib/libgmp.la
/usr/lib/libmp.a
/usr/lib/libmp.la
/usr/lib/libgmpxx.a
/usr/lib/libgmpxx.la
/usr/lib/gmp
/usr/lib/gmp/config.h
/usr/lib/gmp/gmp-impl.h
/usr/lib/gmp/gmp-mparam.h
/usr/lib/gmp/longlong.h
/usr/include
/usr/include/gmp.h
/usr/include/mp.h
/usr/include/gmpxx.h
/usr/share
/usr/share/doc
/usr/share/doc/libgmp3-dev
/usr/share/doc/libgmp3-dev/changelog.gz
/usr/share/doc/libgmp3-dev/copyright
/usr/share/doc/libgmp3-dev/changelog.Debian.gz
/usr/lib/libgmp.so
/usr/lib/libmp.so
/usr/lib/libgmpxx.so


Zach


From netrek at gmail.com  Sat May 27 21:27:12 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 02:27:12 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <20060528005209.39246.qmail@web35303.mail.mud.yahoo.com>
References: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
	<20060528005209.39246.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605271927u3c46fc83ga77f80a5845d859@mail.gmail.com>

On 5/28/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> > checking for mp.h... ./configure: line 6781: syntax
> > error near
> > unexpected token `}'
> > ./configure: line 6781: `echo "${ECHO_T}no" >&6; }'
>
> Do you have mp.h libraries by any chance? I do not,
> and I tried all the repos, and they build fine.

Yup. I have mp.h in
/usr/include/mp.h

I don't know enough about SH langauge to make sense of that error above.

> The build process hasn't changed since you last used
> it.
>
> modify the tests/build to the directory you want and
> run the shell script.

I did. I set it to /home/zu22/bin

Zach


From jimmyhua73 at yahoo.com  Sat May 27 22:34:57 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sat, 27 May 2006 20:34:57 -0700 (PDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <ecfa260c0605271927u3c46fc83ga77f80a5845d859@mail.gmail.com>
Message-ID: <20060528033457.49022.qmail@web35309.mail.mud.yahoo.com>

Did you add this in recently? I'm thinking the script
works fine if you don't have mp.h....

Jimmy

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

> On 5/28/06, Jimmy Huang <jimmyhua73 at yahoo.com>
> wrote:
> > > checking for mp.h... ./configure: line 6781:
> syntax
> > > error near
> > > unexpected token `}'
> > > ./configure: line 6781: `echo "${ECHO_T}no" >&6;
> }'
> >
> > Do you have mp.h libraries by any chance? I do
> not,
> > and I tried all the repos, and they build fine.
> 
> Yup. I have mp.h in
> /usr/include/mp.h
> 
> I don't know enough about SH langauge to make sense
> of that error above.
> 
> > The build process hasn't changed since you last
> used
> > it.
> >
> > modify the tests/build to the directory you want
> and
> > run the shell script.
> 
> I did. I set it to /home/zu22/bin
> 
> Zach
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From tanner at real-time.com  Sat May 27 22:48:57 2006
From: tanner at real-time.com (Bob Tanner)
Date: Sat, 27 May 2006 22:48:57 -0500
Subject: [netrek-dev] Vanilla build broken :(
References: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
Message-ID: <e5b6j9$dso$1@sea.gmane.org>

Zach wrote:

> At least document in INSTALL how to build it now.

Pulled from darcs, I'd say your lucky it does anything. If you want a for
sure built, that is what the tarball and tagged releases are about.

If you want to help find bugs -AND- document them, that is what the
development branch is about.

Since you now know how to build netrek, I expect we'll see a Zach.dev branch
with the INSTALL updated approriately?

-- 
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  Sun May 28 00:34:59 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Sun, 28 May 2006 15:34:59 +1000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
Message-ID: <3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>

On 5/28/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> You have to type make twice, as ranlib doesn't work
> the way it should, but it clears up the 2nd time you
> try.

This is frustrating, the recent changes to the ranlib stuff for
solaris also broke it on OSX. I'm going to have to figure out a better
way to do this.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Sun May 28 02:43:48 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 28 May 2006 00:43:48 -0700 (PDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
Message-ID: <20060528074348.15132.qmail@web35302.mail.mud.yahoo.com>

Hey Stephen, 

What I wrote is old news. 

I tried your latest greatest when all the repos were
re-synced together. 

And, everything works, no need to type make twice. 

However, there *might* still be a bug in the configure
script that is generated by autogen.sh IF you have
mp.h libraries installed. 

I don't, and so I can't really test this. 

Jimmy

--- Stephen Thorne <stephen.thorne at gmail.com> wrote:

> On 5/28/06, Jimmy Huang <jimmyhua73 at yahoo.com>
> wrote:
> > You have to type make twice, as ranlib doesn't
> work
> > the way it should, but it clears up the 2nd time
> you
> > try.
> 
> This is frustrating, the recent changes to the
> ranlib stuff for
> solaris also broke it on OSX. I'm going to have to
> figure out a better
> way to do this.
> 
> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I
> will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
>
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 



From keyos at keyos.org  Sun May 28 03:24:22 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Sun, 28 May 2006 11:24:22 +0300 (IDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.0605281117280.23152@fcnep.argivfvba.arg.vy>

On Sun, 28 May 2006, Stephen Thorne wrote:

> On 5/28/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> > You have to type make twice, as ranlib doesn't work
> > the way it should, but it clears up the 2nd time you
> > try.
> 
> This is frustrating, the recent changes to the ranlib stuff for
> solaris also broke it on OSX. I'm going to have to figure out a better
> way to do this.
>

Well, it looks like the problem began when you first added the 'ranlib -c'
fix to configure.in
I'd say we'll be fixing each other's fixes till the end of the world 
unless we understand what causes one's fix break other's configuration :)

Current configure script doesn't create any problems on my system.
What's wrong on yours ? Maybe we should debug it together ?

Stas.
 
> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 


From stephen.thorne at gmail.com  Sun May 28 04:51:57 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Sun, 28 May 2006 19:51:57 +1000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <Pine.GSO.4.63.0605281117280.23152@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
	<Pine.GSO.4.63.0605281117280.23152@fcnep.argivfvba.arg.vy>
Message-ID: <3e8ca5c80605280251t65eb5f06jaf6991b81999e096@mail.gmail.com>

On 5/28/06, Stas Pirogov <keyos at keyos.org> wrote:
> Current configure script doesn't create any problems on my system.
> What's wrong on yours ? Maybe we should debug it together ?

On a basic level, I need a way of detecting if ranlib is gnu ranlib or
apple ranlib. The detection method currently employed is insufficient
and fragile.

Perhaps using grep on ranlib -V would be better:

$ ranlib -V 2>/dev/null| grep Apple
Apple Computer, Inc. version cctools-590.18

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From netrek at gmail.com  Sun May 28 05:15:26 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 10:15:26 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <20060528033457.49022.qmail@web35309.mail.mud.yahoo.com>
References: <ecfa260c0605271927u3c46fc83ga77f80a5845d859@mail.gmail.com>
	<20060528033457.49022.qmail@web35309.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605280315o62d54760s56aa75efd693b61b@mail.gmail.com>

On 5/28/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Did you add this in recently? I'm thinking the script
> works fine if you don't have mp.h....

Nope. It has been installed for weeks now. It was definitely installed
when I ran the build script 5 days ago and it worked.

Zach


From keyos at keyos.org  Sun May 28 05:15:41 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Sun, 28 May 2006 13:15:41 +0300 (IDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <3e8ca5c80605280251t65eb5f06jaf6991b81999e096@mail.gmail.com>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
	<Pine.GSO.4.63.0605281117280.23152@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605280251t65eb5f06jaf6991b81999e096@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>

On Sun, 28 May 2006, Stephen Thorne wrote:

> On a basic level, I need a way of detecting if ranlib is gnu ranlib or
> apple ranlib. The detection method currently employed is insufficient
> and fragile.
> 
> Perhaps using grep on ranlib -V would be better:
> 
> $ ranlib -V 2>/dev/null| grep Apple
> Apple Computer, Inc. version cctools-590.18
>

Let's go one step back and understand why do we need to know ranlib 
version ? If this is a matter of having '-c' as a switch or not then
we should find a way to test for '-c' correct. Maybe the best way would
be to build actual archive and run ranlib on it ?

Let's test following on OSX:

create test.c:

int test_func (void)
{
    return 1;
}

compile with gcc -c test.c
archive with ar -cru test.a test.c
run OSX ranlib -c test.a and check the exit code

If the exit code is 0 then we're good and such test should satisfy both
OSX and others, because on every other system (except ones with ranlib
substituted with 'exit 0') it'll return non zero. On the systems with
'exit 0' ranlib this test won't matter because 'ar' will create the index
by default and ranlib will do nothing.
 
Testing for ranlib version using -V is not good way IMO.

Stas.

> -- 
> Stephen Thorne
> 
> "Give me enough bandwidth and a place to sit and I will move the world."
>   --Jonathan Lange
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 


From netrek at gmail.com  Sun May 28 05:25:32 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 10:25:32 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
Message-ID: <ecfa260c0605280325v30bd8790h426c32e6ef594148@mail.gmail.com>

On 5/28/06, Stephen Thorne <stephen.thorne at gmail.com> wrote:
>
> This is frustrating, the recent changes to the ranlib stuff for
> solaris also broke it on OSX. I'm going to have to figure out a better
> way to do this.

It seems a universal break cause my Linux system had ranlib problem.
So it affects OSX, Solaris and Linux.

Zach


From netrek at gmail.com  Sun May 28 05:31:12 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 10:31:12 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
	<Pine.GSO.4.63.0605281117280.23152@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605280251t65eb5f06jaf6991b81999e096@mail.gmail.com>
	<Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>
Message-ID: <ecfa260c0605280331v6c68d904y456a5b0d88597d2f@mail.gmail.com>

There has been talk of ranlib problem which we already knew about but
nobody besides Jimmy has offered ideas on why configure is complaining
about mp.h which is the original problem in this thread. Can someone
else look at the error I pasted please? I don't understand SH that
well. And can someone say what the most recent canonical method for
building server from darcs is please? I don't understand why the build
script worked fine 5 days ago and after I pulled latest changes it
fails. It built fine on May 23rd when I originally did 'darcs get'
from Quozl's repo to setup my repo and then yesterday i did a 'darcs
pull' from Quozl's repo and it installed lots of patches.

Zach


From netrek at gmail.com  Sun May 28 05:32:14 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 10:32:14 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <e5b6j9$dso$1@sea.gmane.org>
References: <ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<e5b6j9$dso$1@sea.gmane.org>
Message-ID: <ecfa260c0605280332i5d66a549j409356b2025f64dd@mail.gmail.com>

On 5/28/06, Bob Tanner <tanner at real-time.com> wrote:
>
> Since you now know how to build netrek, I expect we'll see a Zach.dev >branch with the INSTALL updated approriately?

Sure once I get it building again. When I built it originally on May
23rd it went smoothly but now it dies with that error regarding mp.h

Zach


From netrek at gmail.com  Sun May 28 09:35:16 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 14:35:16 +0000
Subject: [netrek-dev] build problem (mp.h)
Message-ID: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>

Talked with Jerub in #netrek and we seemed to agree on the problem
being "sh autogen.sh" incorrectly building ./configure. I did "darcs
revert -a" as Jerub suggested and ran build script again but got same
error, http://pastebin.com/742765,  in autogen.sh:

#
# build configure
#
sh autogen.sh
#
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
#
autogen.sh completed ok

and the same error in ./configure:
#
checking for mp.h... ./configure: line 6781: syntax error near
unexpected token `}'
#
./configure: line 6781: `echo "${ECHO_T}no" >&6; }'

So next I did "darcs unpull" and removed all 86 patches then ran build
again, this time there is no autogen.sh warning about aclocal but it
still gives same ./configure error:

checking for mp.h... ./configure: line 6578: syntax error near
unexpected token `}'
./configure: line 6578: `echo "${ECHO_T}no" >&6; }'

Here is the full log from last build run: http://pastebin.com/742848

Zach


From keyos at keyos.org  Sun May 28 11:12:31 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Sun, 28 May 2006 19:12:31 +0300 (IDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<3e8ca5c80605272234i314fc7abva47ded861e95d831@mail.gmail.com>
	<Pine.GSO.4.63.0605281117280.23152@fcnep.argivfvba.arg.vy>
	<3e8ca5c80605280251t65eb5f06jaf6991b81999e096@mail.gmail.com>
	<Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>
Message-ID: <Pine.GSO.4.63.0605281734310.23152@fcnep.argivfvba.arg.vy>

This one is for Stephen only to test on OSX. If this runs fine
then we'll test it on linuxes etc.

Stas.

On Sun, 28 May 2006, Stas Pirogov wrote:

> Date: Sun, 28 May 2006 13:15:41 +0300 (IDT)
> From: Stas Pirogov <keyos at keyos.org>
> Reply-To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> Subject: Re: [netrek-dev] Vanilla build broken :(
> 
> On Sun, 28 May 2006, Stephen Thorne wrote:
> 
> > On a basic level, I need a way of detecting if ranlib is gnu ranlib or
> > apple ranlib. The detection method currently employed is insufficient
> > and fragile.
> > 
> > Perhaps using grep on ranlib -V would be better:
> > 
> > $ ranlib -V 2>/dev/null| grep Apple
> > Apple Computer, Inc. version cctools-590.18
> >
> 
> Let's go one step back and understand why do we need to know ranlib 
> version ? If this is a matter of having '-c' as a switch or not then
> we should find a way to test for '-c' correct. Maybe the best way would
> be to build actual archive and run ranlib on it ?
> 
> Let's test following on OSX:
> 
> create test.c:
> 
> int test_func (void)
> {
>     return 1;
> }
> 
> compile with gcc -c test.c
> archive with ar -cru test.a test.c
> run OSX ranlib -c test.a and check the exit code
> 
> If the exit code is 0 then we're good and such test should satisfy both
> OSX and others, because on every other system (except ones with ranlib
> substituted with 'exit 0') it'll return non zero. On the systems with
> 'exit 0' ranlib this test won't matter because 'ar' will create the index
> by default and ranlib will do nothing.
>  
> Testing for ranlib version using -V is not good way IMO.
> 
> Stas.
> 
> > -- 
> > Stephen Thorne
> > 
> > "Give me enough bandwidth and a place to sit and I will move the world."
> >   --Jonathan Lange
> > 
> > _______________________________________________
> > netrek-dev mailing list
> > netrek-dev at us.netrek.org
> > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> > 
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 
-------------- next part --------------

New patches:

[OSX vs GNU ranlib differentiation
Stas Pirogov <keyos at keyos.org>**20060528160823
 Current patch will try to distinguish between OSX ranlib that requires -c switch
 to generate index and GNU ranlib that creates index by default. Current patch
 relies on AC_LANG_COMPILER_REQUIRE(C) directive that sets various compiler/linker
 variables and on AC_PROG_LIBTOOL macro that creates variables for ar and ranlib
 programs (and creates the libtool script afterwards)
] 
<
> {
hunk ./Vanilla/configure.in 7
 AC_INIT(name.c)
 AC_CONFIG_HEADER(include/config.h)
 AC_PREFIX_DEFAULT("/usr/local/games/netrek-server-vanilla")
+AC_LANG_COMPILER_REQUIRE(C)
 
 #----------------------------------------------------
 #	For which code are we checking? (server, cow)
hunk ./Vanilla/configure.in 485
 
 AC_PROG_LIBTOOL
 
-AC_MSG_CHECKING(for OSX ranlib)
-(eval $RANLIB -c) 2>&5
-if test $? -ne 0; then
-    RANLIB_FLAGS=
-    AC_MSG_RESULT(no)
+AC_MSG_CHECKING(for ranlib style)
+RANLIB_FLAGS=
+cat >>conftest.$ac_ext <<_ACEOF
+int test_func (void)
+{
+  return 1;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+(eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+(eval $ac_compile) 2>&5
+ac_status=$?
+echo "$as_me:$LINENO: \$? = $ac_status" >&5
+if test $ac_status -eq 0; then
+    (eval echo $AR $AR_FLAGS conftest.$libext conftest.$ac_objext) >&5
+    (eval $AR $AR_FLAGS conftest.$libext conftest.$ac_objext) 2>&5
+    ac_status=$?
+    echo "$as_me:$LINENO: \$? = $ac_status" >&5
+    if test $ac_status -eq 0; then
+        (eval echo $RANLIB -c conftest.a) >&5
+        (eval $RANLIB -c conftest.a) 2>&5
+        ac_status=$?
+        echo "$as_me:$LINENO: \$? = $ac_status" >&5
+        if test $ac_status -eq 0; then
+            RANLIB_FLAGS='-c'
+            AC_MSG_RESULT(OSX style)
+        else
+            RANLIB_FLAGS=
+            AC_MSG_RESULT(GNU style)
+        fi
+    else
+        echo "cannot archive"
+    fi
 else
hunk ./Vanilla/configure.in 519
-    RANLIB_FLAGS='-c'
-    AC_MSG_RESULT(drat - yes)
+    echo "cannot compile"
 fi
hunk ./Vanilla/configure.in 521
-
 AC_SUBST(RANLIB_FLAGS)
 
 if test "$code" = server; then
}

Context:

[experimental rework for wait queue dumping changelog
quozl at us.netrek.org**20060527090326] 
[experimental rework for wait queue dumping
quozl at us.netrek.org**20060527090226
 
 	* ntserv/openmem.c: experimental rework to support wait queue
 	dumping, and multiple server instances in separate shared memory
 	segments.  Provide interface so findslot will be able to detach
 	from an active game segment and create and attach to a new game
 	segment.  Accept NETREK_PKEY environment variable.
 
] 
[experiment slot number change command changelog
quozl at us.netrek.org**20060527071222] 
[experiment slot number change command
quozl at us.netrek.org**20060527071121
 
 	* ntserv/ntscmds.c (do_become): add experimental and not yet
 	functioning code to support change of slot number for a player.
 	Requires client-side support and further work.
 
] 
[robotd-toggle-newlogic-news.dpatch
jimmyhua73 at yahoo.com**20060527025530] 
[robotd-toggle-newlogic
jimmyhua73 at yahoo.com**20060527024334
 
 On request, the new logic that the robotd uses can be turned on and off
 via a commandfile or command sequence. Currently defaulted to off. 
 
 hcr -> assume humans carry
 ogh -> ogg carriers while I am bombing
 
 	* INSTALL.Newbie updated INSTALL.Newbie to document newer switches.
 	Need to include all possible robot switches in the future. 
 
 	* robotd/data.c added initialization of global variables hm_cr and 
 	ogg_happy
 
 	* robotd/data.h added global variables hm_cr and ogg_happy
 
 	* robotd/decide.c added check for ogg_happy mode before 
 	check_ogg while bombing
 
 	* robotd/dmessage.c added hcr and ogh message decoding. 
 
 	* robotd/update_players.c moved conservative assumptions that
 	humans carry into a new function called army_check3. 
 
 	* robotd/update_players.c added logic so army_check3 only 
 	executes if (hm_cr) global variable is active. 
 
 
 
] 
[resolve conflicts with newbie-configurable-robots-changelog.dpatch
Stephen Thorne <stephen at thorne.id.au>**20060526081423] 
[newbie-configurable-robots.dpatch
jimmyhua73 at yahoo.com**20060526063547
 
 	* INSTALL.Newbie updated documentation to show how to configure
 	the robots to be dumber
 
 	* robotd/data.c changed default updates=2.0 instead of 1.0, decreases
 	CPU load by 50% and fights about the same. 
 
 	* robotd/dmessage.c allow decoding of local messages and commandfile
 	messages even if robot is in INL mode. In INL mode, robots will 
 	ignore other players and GOD's commands. 
 
 	* robots/newbie.c checkpos() returns 1, to avoid compiler warning
 
 	* robots/newbie.c added a bunch of comments on what each option
 	does, when Merlin forks a robot. 
 
 	* robots/newbie.c modified the command so robots now read a command
 	file on startup. 
 
] 
[newbie-configurable-robots-changelog.dpatch
jimmyhua73 at yahoo.com**20060526064353] 
[ping pong plasma bot changelog
quozl at us.netrek.org**20060525050440] 
[remove res-rsa/configure
Trent Piepho <xyzzy at speakeasy.org>**20060525015328
 This is a generated file and shouldn't be kept in the repository.
] 
[help bot deal with ping-pong plasma
Trent Piepho <xyzzy at speakeasy.org>**20060525030034
 The robot has code to deal with Ping-Pong plasma, but it's an old
 version.  It doesn't work properly with the current ping pong plasmas,
 written by Trent Piepho in 1995 (so the old ones are really old!). 
 Basically, the bots needs to allow for plasma fired by a friendly player
 becoming hostile to it.
       
 Also sets the pl_team member of the plasma struct, which makes getting
 the plasma's team easier.
] 
[help client with plasma war in ping-pong mode
Trent Piepho <xyzzy at speakeasy.org>**20060525025806
 In Ping-Pong plasma mode, a plasma changes teams when it is bounced. 
 There is no way to send this change to the client, so the client doesn't
 know.  For example, if a player at peace with us but who we are at war
 with bounces our (or a teammate's) plasma back at us, it appears to the
 client that the plasma is friendly.  But really, it's not, since we are
 at war with the plasma's new team.  Fix this by setting the plasma's war
 flag if the player is hostile to the plasma's team.
  
 In order to take advantage of this, clients will need to be sure to:
 1. Not assume that the player's own plasma is friendly.
 2. Not assume that plasma from the player's team is friendly.
 3. Make sure the check the plasma's war flags, and not the flags of the
 player who fired it.
 
] 
[deprecate dan quayle in t-mode messages changelog
quozl at us.netrek.org**20060525041559] 
[deprecate dan quayle in t-mode messages
quozl at us.netrek.org**20060525041344
 
 	* include/defs.h (WARMONGER): add customisation setting for
 	configuration of local warmonger, so that we are not caught by
 	change again so easily.
 
 	* ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
 	favour of George Bush, subject to mailing list discussion.  Patch
 	by: William Balcerski with rework by James Cameron.
 
] 
[rewrite build test script changelog
quozl at us.netrek.org**20060525013820] 
[rewrite build test script
quozl at us.netrek.org**20060525013317
 
 	* autogen.sh: add res-rsa to autoconf re-run,
 
 	* tests/build: test for correct directory, use darcs get instead
 	of put, use autogen.sh instead of running autotools here, add the
 	install target.
 
 	"darcs put" is slow, the darcs manual recommends "darcs get" instead,
 	which is certainly faster.  But "darcs get" must have the exact path to
 	a repo, not like "darcs put".  So a test is added to check that we are
 	in the right directory first.
 
] 
[Player position sign fix
williamb at its.caltech.edu*-20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[robotd omnibus 2 changelog
quozl at us.netrek.org**20060525003615
 Addition of ChangeLog and NEWS entries to cover Trent Piepho's rework 
 of Jimmy Huang's changes to robotd.
] 
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060524082754
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 players' torps too.  Without it, the bot thinks all torps are going
 straight up, making it a very bad dodger (unless you attack from below). 
   
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060524082708
 Some calls to req_cloak_off() were missing the function's argument,
 the reason string.
] 
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060524082437
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping the bots's own HW, for proximity.  This makes the code
 much smaller and faster.  Realistically, the HWs are always at the
 standard indexes, even with non-standard planet layouts.  Included a bit
 of code, #if'ed out, that will find home worlds by name, the way the bot
 does when it wants to refit.
] 
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060524082353
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060524082241
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060524082149
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060524082029
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
] 
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060524081723
 The assault planet code didn't re-check the target planet after the
 assault started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060524081613
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[robotd mfprintf regression fix
quozl at us.netrek.org*-20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com*-20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[fix ranlib for solaris changelog
Stas Pirogov <keyos at keyos.org>**20060524235806] 
[fix ranlib for solaris
Stas Pirogov <keyos at keyos.org>**20060524235510
 
 	* configure.in: test for ranlib was failing on Solaris. This is
 	probably caused by different /bin/sh interpreters.  This fix should
 	satisfy all of them.
 
] 
[PROJECTS update
williamb at its.caltech.edu**20060524093948
 Removed twarp observer bug from PROJECTS list, as this has been fixed.
] 
[conflict resolution 2006-08-24-a
quozl at us.netrek.org**20060524042919] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[Player position sign fix
williamb at its.caltech.edu**20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[fix SP_2 flag sending for real changelog
quozl at us.netrek.org**20060524024253] 
[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
[remove generated autotools files
quozl at us.netrek.org**20060524015023
 aclocal.m4 and configure are generated files, they are generated using
 autogen.sh from configure.in, and as such they do not deserve to be in the
 repository and are costing us time and energy as they change.
] 
[misc bugs update
quozl at us.netrek.org**20060524014925] 
[deprecate README.darcs execution in favour of autogen.sh changelog
quozl at us.netrek.org**20060524011944] 
[deprecate README.darcs execution in favour of autogen.sh
quozl at us.netrek.org**20060524011759
 
 	* autogen.sh: add GNU standard autotools configuration sequence,
 	deprecating execution of README.darcs.  Manual build process then
 	becomes "sh autogen.sh" followed by the usual configure, make, and
 	make install.
 
] 
[newbie-fixes.dpatch changelog conflict resolution
quozl at us.netrek.org**20060524005953] 
[newbie-fixes.dpatch
jimmyhua73 at yahoo.com**20060523153223
 
  Bug fixes:
 
   1. Merlin gets moved on genocide. Now Merlin moves himself back.
   2. You can get Merlin into a race condition by timing your join and
   joining something other than what Merlin chooses for the warring teams.
   This is fixed (I think). I was never able to time this right!!!
   James please check again!
 
  Known Bug:
 
  1. t-mode criteria is hardcoded into Merlin as 4 players a side.
 
  ChangeLog here:
 
      * robots/newbie.c changed some tabbing for better indent and bracing
      consistency.
 
      * robots/newbie.c added #defines POSITIONX and POSITIONY so there's
      only one place the change the desired x and y position of Merlin
 
      * robots/newbie.c added checkpos() function which checks for changes
      in Merlin's position. Replaces him back into POSITIONX and POSITIONY
      once it finds that Merlin has stopped moving for 15 seconds.
 
      * robots/newbie.c corrected misspellings of various comments
 
      * robots/newbie.c modified num_players() function to return
      the correct *next_team based on t-mode settings also
 
] 
[robotd_udcounter.dpatch
jimmyhua73 at yahoo.com**20060523143934
 
 I re-did the setflag() function, so it now will always report back
 a positive incrementing int at 100ms intervals. And it starts with 0
 on program start. 
 
 There are some other places that initialize _udcounter, I think this
 might need to be got rid of, but I didn't do that in this patch. 
 
 Read the longwinded diatribe in the Changelog. 
 
] 
[newbie-install-docs-update.dpatch
jimmyhua73 at yahoo.com**20060523155757
 
 Updated the installation document for newbie
 
] 
[robotd mfprintf regression fix changelog
quozl at us.netrek.org**20060524004957] 
[robotd mfprintf regression fix
quozl at us.netrek.org**20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[revised coding style and darcs discipline
quozl at us.netrek.org**20060523050927
 Rewrite of the coding style and patch acceptance criteria based on 
 feedback on the mailing list from Stephen Thorne and Trent Piepho.
] 
[Declare_war fix
williamb at its.caltech.edu**20060522012930
         * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
           added boolean to declare_war function to indicate whether to
           add delay and send delay message.  Fixes the case of unwanted 
           war delay message when switching teams, and also prevents robots
           from entering a state of permanent declare war delay.
] 
[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
308564801976d99676394fe997839d57b093cb31

From keyos at keyos.org  Sun May 28 11:24:58 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Sun, 28 May 2006 19:24:58 +0300 (IDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>

I'd say open configure and search for "checking for mp.h"
Copy paste everything until "checking for gmp.h" to pastebin
and give us the link.

Make sure you run:

aclocal
libtoolize
autoconf

in this order (it is wrong in build tests) and test configure
again.

Stas.

On Sun, 28 May 2006, Zach wrote:

> Date: Sun, 28 May 2006 14:35:16 +0000
> From: Zach <netrek at gmail.com>
> Reply-To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> To: Netrek Development Mailing List <netrek-dev at us.netrek.org>
> Subject: [netrek-dev] build problem (mp.h)
> 
> Talked with Jerub in #netrek and we seemed to agree on the problem
> being "sh autogen.sh" incorrectly building ./configure. I did "darcs
> revert -a" as Jerub suggested and ran build script again but got same
> error, http://pastebin.com/742765,  in autogen.sh:
> 
> #
> # build configure
> #
> sh autogen.sh
> #
> You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
> #
> autogen.sh completed ok
> 
> and the same error in ./configure:
> #
> checking for mp.h... ./configure: line 6781: syntax error near
> unexpected token `}'
> #
> ./configure: line 6781: `echo "${ECHO_T}no" >&6; }'
> 
> So next I did "darcs unpull" and removed all 86 patches then ran build
> again, this time there is no autogen.sh warning about aclocal but it
> still gives same ./configure error:
> 
> checking for mp.h... ./configure: line 6578: syntax error near
> unexpected token `}'
> ./configure: line 6578: `echo "${ECHO_T}no" >&6; }'
> 
> Here is the full log from last build run: http://pastebin.com/742848
> 
> Zach
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 


From netrek at gmail.com  Sun May 28 12:23:19 2006
From: netrek at gmail.com (Zach)
Date: Sun, 28 May 2006 17:23:19 +0000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
Message-ID: <ecfa260c0605281023g156406aat8ce73bc02bfa0786@mail.gmail.com>

On 5/28/06, Stas Pirogov <keyos at keyos.org> wrote:
> I'd say open configure and search for "checking for mp.h"
> Copy paste everything until "checking for gmp.h" to pastebin
> and give us the link.
>
> Make sure you run:
>
> aclocal
> libtoolize
> autoconf
>
> in this order (it is wrong in build tests) and test configure
> again.

Shalom Stas,

Ok here is what I just did. Pastebin would only hold ~2,000 lines so I
had to split it up into 4 parts:

Part 1 of 4
http://pastebin.com/743148

Part 2 of 4
http://pastebin.com/743177

Part 3 of 4
http://pastebin.com/743182

Part 4 of 4
http://pastebin.com/743188

Zach


From keyos at keyos.org  Sun May 28 13:01:48 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Sun, 28 May 2006 21:01:48 +0300 (IDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <ecfa260c0605281023g156406aat8ce73bc02bfa0786@mail.gmail.com>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<ecfa260c0605281023g156406aat8ce73bc02bfa0786@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.0605282059180.27171@fcnep.argivfvba.arg.vy>

On Sun, 28 May 2006, Zach wrote:

> Shalom Stas,
> 
> Ok here is what I just did. Pastebin would only hold ~2,000 lines so I
> had to split it up into 4 parts:
> 
> Part 1 of 4
> http://pastebin.com/743148
> 
> Part 2 of 4
> http://pastebin.com/743177
> 
> Part 3 of 4
> http://pastebin.com/743182
> 
> Part 4 of 4
> http://pastebin.com/743188
>

Hmm, I expected for around 30 lines and got 8000. Either you didn't
read what I wrote or you did, but didn't do what I asked to :)

Now find the relevant part in these pastebins and paste it to new one.
I only need configure part that begins with line containing "checking for mp.h"
and ends with line containing "checking for gmp.h"

Stas.

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


From jimmyhua73 at yahoo.com  Sun May 28 23:26:42 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 28 May 2006 21:26:42 -0700 (PDT)
Subject: [netrek-dev] Code clean-up and re-indent robotd/update_players.c
Message-ID: <20060529042642.9459.qmail@web35309.mail.mud.yahoo.com>

Sorry I still miss proper indentation every once in a
while. 

Indentation is fixed.  Also, removed robo-human check
from army_check function and placed it in a NotRobot()
function per request from quozl. 



Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-notrobot-func-changelog.dpatch
Type: application/octet-stream
Size: 28667 bytes
Desc: 3503014875-robotd-notrobot-func-changelog.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060528/218c56d1/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: robotd-notrobot-func.dpatch
Type: application/octet-stream
Size: 31346 bytes
Desc: 829764901-robotd-notrobot-func.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060528/218c56d1/attachment-0003.obj 

From jimmyhua73 at yahoo.com  Sun May 28 23:45:39 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Sun, 28 May 2006 21:45:39 -0700 (PDT)
Subject: [netrek-dev] mfprintf fix
Message-ID: <20060529044539.79067.qmail@web35303.mail.mud.yahoo.com>

Hello all, 

This is the James Cameron fix of mfprintf function
that somehow got lost during manual patching.

There's a one line difference between Jame's fix and
Trent's fix.

Trent's    fflush(stdout);
Jame's     fflush(fo);

Anyways, I'm guessing that James's own is right, and
here's the patch. 

No changelog as the changelog was updated already. 

Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mfprintf-fix.dpatch
Type: application/octet-stream
Size: 28805 bytes
Desc: 455086449-mfprintf-fix.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060528/1f26b2b6/attachment-0001.obj 

From quozl at us.netrek.org  Mon May 29 00:56:00 2006
From: quozl at us.netrek.org (quozl at us.netrek.org)
Date: Mon, 29 May 2006 15:56:00 +1000
Subject: [netrek-dev] darcs patch: fix mp.h syntax error
Message-ID: <E1FkajQ-00044L-HE@dors.lan>

Mon May 29 15:52:34 EST 2006  quozl at us.netrek.org
  * fix mp.h syntax error
  Wasn't able to find what patch had caused this problem, darcs trackdown found
  no patch removal that would pass this test, so it seems likely that it was due
  to a change to autoconf in Debian Etch rather than in the Netrek Server Vanilla
  code base.  Expanding the check into separate lines solved the problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 29198 bytes
Desc: A darcs patch for your repository!
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060529/e21cb86e/attachment-0001.bin 

From quozl at us.netrek.org  Mon May 29 01:02:35 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 16:02:35 +1000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
Message-ID: <20060529060235.GC8047@us.netrek.org>

On Sun, May 28, 2006 at 07:24:58PM +0300, Stas Pirogov wrote:
> Make sure you run:
> aclocal ; libtoolize ; autoconf
> in this order (it is wrong in build tests) and test configure
> again.

tests/build hasn't got this any more, it's moved to autogen.sh, and I'm
happy to change it, but can you give me a reference for the order?  It
seems to work both ways for me.

A patch to autogen.sh is welcome.

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


From quozl at us.netrek.org  Mon May 29 01:03:14 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 16:03:14 +1000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
Message-ID: <20060529060314.GD8047@us.netrek.org>

Fixed, pull.

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


From quozl at us.netrek.org  Mon May 29 01:45:29 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 16:45:29 +1000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <ecfa260c0605271927u3c46fc83ga77f80a5845d859@mail.gmail.com>
	<20060528005209.39246.qmail@web35303.mail.mud.yahoo.com>
	<ecfa260c0605280332i5d66a549j409356b2025f64dd@mail.gmail.com>
	<e5b6j9$dso$1@sea.gmane.org>
	<ecfa260c0605280325v30bd8790h426c32e6ef594148@mail.gmail.com>
	<ecfa260c0605280331v6c68d904y456a5b0d88597d2f@mail.gmail.com>
	<ecfa260c0605271922g17be2467qe34897d31b103946@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
References: <Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>
	<ecfa260c0605280331v6c68d904y456a5b0d88597d2f@mail.gmail.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<ecfa260c0605271922g17be2467qe34897d31b103946@mail.gmail.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
Message-ID: <20060529064529.GE8047@us.netrek.org>

Summary: regression by Debian Etch autoconf.

On Sun, May 28, 2006 at 12:10:20AM +0000, Zach wrote:
> I had successfully built/installed the server a few days ago into /tmp
> so I was going to build and install it for real this time so I did a
> 'darcs pull' from Quozl's repo and ran tests/build and now it dies!

Yeah, I got that too.  Oh well, it's not important, as it's so easy to
fix.

Was autoconf recently upgraded on your system?  It was upgraded on my
system on 26th May, and that's when the problem began.  You can check
that by looking at the times on the files

	/var/lib/dpkg/info/autoconf*

On Sun, May 28, 2006 at 12:19:43AM +0000, Zach wrote:
> Vanilla/configure script is also missing now. what is going on?

This is intentional, and you were told.

> the old way worked for all these years why is someone drastically
> altering the build/configure process??!

Because it is better to change it than to leave it as it is.  If you are
challenging my decision on it, you better have a good reason other than
your unwillingness to review patches and documentation.

> At least document in INSTALL how to build it now.

Absolutely not.  INSTALL is instructions for end-user who downloads
tar.gz file.  It is only a subset of the instructions needed to build
from source obtained from Darcs.

> I only found out about tests/build script from being in #netrek
> channel. 

You are unwise to rely only on the #netrek channel for understanding
changes being made by the team to the repository.  Instead, use the
repository tools.  See the Darcs manual, which explains how to look at
changes made.

> If this was replaced also by a new way to build why is it not
> documented in the distribution?

Because the distribution (the .tar.gz) is not affected by this change.
A new .tar.gz file when it is produced will include INSTALL and
configure, it should not include autogen.sh.

Adding instructions to INSTALL that don't relate to the .tar.gz would be
pointless and harmful.

> This really MUST be documented and put INSIDE the Vanilla source tree
> PLEASE.

It is documented, see README.darcs.  Okay, maybe it is a little brief,
but you are expected to know GNU standards, and autogen.sh is a common
thing to find in other GNU style projects.

I'll take patches to README.darcs!

On Sat, May 27, 2006 at 05:37:19PM -0700, Jimmy Huang wrote:
> I agree it should have been documented. 
> sh autogen.sh
> ./configure --prefix==/tmp/netrek

Are you sure about that double equals sign, Jimmy?  I've not tried that.

> Also, you need a whole bunch of other software
> packages that you didn't used to need. Figure out what
> they are as when autogen crashes. I forgot what they
> were (i should have written down what I did). 

Rats.  If someone builds such a list (such as that found in
debian/control in the repository), please submit it.

On Sat, May 27, 2006 at 05:52:09PM -0700, Jimmy Huang wrote:
> Do you have mp.h libraries by any chance? I do not,
> and I tried all the repos, and they build fine. 

That's a very important point ... removing the mp.h would probably have
fixed the configure as well.

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


From quozl at us.netrek.org  Mon May 29 02:07:35 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 17:07:35 +1000
Subject: [netrek-dev] armies killed by planets support
In-Reply-To: <Pine.LNX.4.58.0605271847040.10604@shell3.speakeasy.net>
References: <Pine.LNX.4.58.0605250531130.18325@shell3.speakeasy.net>
	<20060527055247.GG5456@us.netrek.org>
	<Pine.LNX.4.58.0605271847040.10604@shell3.speakeasy.net>
Message-ID: <20060529070735.GH8047@us.netrek.org>

On Sat, May 27, 2006 at 07:01:35PM -0700, Trent Piepho wrote:
> The server normally doesn't send the info at all, so there is no way
> for a client to see this.  I guess the client could play a doosh sound
> or show some kind of little man flying into space animation if the
> client had something like that.

Thanks.  I accept that patch.  I can see the use now.

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


From keyos at keyos.org  Mon May 29 04:08:50 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Mon, 29 May 2006 12:08:50 +0300 (IDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <20060529060235.GC8047@us.netrek.org>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
Message-ID: <Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>

On Mon, 29 May 2006, James Cameron wrote:

> On Sun, May 28, 2006 at 07:24:58PM +0300, Stas Pirogov wrote:
> > Make sure you run:
> > aclocal ; libtoolize ; autoconf
> > in this order (it is wrong in build tests) and test configure
> > again.
> 
> tests/build hasn't got this any more, it's moved to autogen.sh, and I'm
> happy to change it, but can you give me a reference for the order?  It
> seems to work both ways for me.
>

Well, if you look at libtoolize code you'll see that it actually looks for
aclocal.m4 in the current directory. When I run it before aclocal I get
"add the contents of /usr/loca/share/aclocal/libtool.m4 to aclocal.m4"
When aclocal is ran first - no warnings.

I'd also suggest using 'libtoolize --copy' instead of regular one that 
creates links to config.guess and config.sub

> A patch to autogen.sh is welcome.
>

First you should accept the idea :) Then you'll probably add one by 
yourself.

Stas.
 
> -- 
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 


From quozl at us.netrek.org  Mon May 29 04:30:48 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 19:30:48 +1000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
Message-ID: <20060529093048.GA887@us.netrek.org>

On Mon, May 29, 2006 at 12:08:50PM +0300, Stas Pirogov wrote:
> Well, if you look at libtoolize code you'll see that it actually looks
> for aclocal.m4 in the current directory.

Well, yes, it does ... but I don't see why that means anything.

> When I run it before aclocal I get "add the contents of
> /usr/loca/share/aclocal/libtool.m4 to aclocal.m4" 

Yes, I get that too (with slight changes to file names), but exit status
is zero, success.

> When aclocal is ran first - no warnings.

Agreed, that warning goes.

> > A patch to autogen.sh is welcome.
> 
> First you should accept the idea :) Then you'll probably add one by 
> yourself.

I don't yet see the point of doing it.
I was hoping someone else did.
I didn't add libtoolize.

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


From keyos at keyos.org  Mon May 29 04:49:32 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Mon, 29 May 2006 12:49:32 +0300 (IDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <20060529093048.GA887@us.netrek.org>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
Message-ID: <Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>

On Mon, 29 May 2006, James Cameron wrote:

> I don't yet see the point of doing it.
> I was hoping someone else did.
> I didn't add libtoolize.
>

Well, the point is to remove warning. It doesn't do anything wrong
if that's your question, but if I'd have option to fix some warning
I'd do that. Simply because new developer will see that warning and
take time to check what's wrong there.

Stas.

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


From netrek at gmail.com  Mon May 29 05:25:40 2006
From: netrek at gmail.com (Zach)
Date: Mon, 29 May 2006 10:25:40 +0000
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <20060529064529.GE8047@us.netrek.org>
References: <Pine.GSO.4.63.0605281258530.23152@fcnep.argivfvba.arg.vy>
	<ecfa260c0605280332i5d66a549j409356b2025f64dd@mail.gmail.com>
	<e5b6j9$dso$1@sea.gmane.org>
	<ecfa260c0605280325v30bd8790h426c32e6ef594148@mail.gmail.com>
	<ecfa260c0605280331v6c68d904y456a5b0d88597d2f@mail.gmail.com>
	<ecfa260c0605271922g17be2467qe34897d31b103946@mail.gmail.com>
	<20060528003719.23877.qmail@web35307.mail.mud.yahoo.com>
	<ecfa260c0605271719n6abd2389wc19c2cecc1bb1515@mail.gmail.com>
	<ecfa260c0605271710n7e000ffemfb1641abd69819dd@mail.gmail.com>
	<20060529064529.GE8047@us.netrek.org>
Message-ID: <ecfa260c0605290325s52ee87f7n7b9536b902340f7@mail.gmail.com>

On 5/29/06, James Cameron <quozl at us.netrek.org> wrote:
> It was upgraded on my
> system on 26th May, and that's when the problem began.  You
> can check
> that by looking at the times on the files
>
>         /var/lib/dpkg/info/autoconf*

It built fine on May 24th early in the morning hours and failed on May
28/29th. Here are the file times:
-rw-r--r-- 1 root root   38 May 13 18:14 /var/lib/dpkg/info/autoconf.conffiles
-rw-r--r-- 1 root root 2649 May 24 20:57 /var/lib/dpkg/info/autoconf.list
-rw-r--r-- 1 root root 4238 May 13 18:14 /var/lib/dpkg/info/autoconf.md5sums
-rwxr-xr-x 1 root root  873 May 13 18:14 /var/lib/dpkg/info/autoconf.postinst
-rw-r--r-- 1 root root   47 Dec  6  2004 /var/lib/dpkg/info/autoconf2.13.list
-rwxr-xr-x 1 root root  382 Mar 28  2002 /var/lib/dpkg/info/autoconf2.13.postrm

Zach


From quozl at us.netrek.org  Mon May 29 06:03:23 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 21:03:23 +1000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
	<Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
Message-ID: <20060529110323.GD887@us.netrek.org>

On Mon, May 29, 2006 at 12:49:32PM +0300, Stas Pirogov wrote:
> Well, the point is to remove warning. It doesn't do anything wrong
> if that's your question, but if I'd have option to fix some warning
> I'd do that. Simply because new developer will see that warning and
> take time to check what's wrong there.

Excellent, the more eyes the better.  Hopefully said developer will know
enough to send in a patch.  ;-)

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


From williamb at its.caltech.edu  Mon May 29 06:17:16 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Mon, 29 May 2006 04:17:16 -0700 (PDT)
Subject: [netrek-dev] Features I'd like to be added to server (long)
Message-ID: <Pine.GSO.4.58.0605290327370.12165@sue>

Ok I'm going to attempt to list and analyze some features I'd like added
to Vanilla.  Let's start with the most pressing one:

1) Ship headings to 256 with SP2
Current ship headings are only sent to 16 positions with SP2.  All modern
clients use 32 position bitmap sets, and my client uses 256 position
bitmaps.  Ship headings are sent to 256 positions with long packets on -
this is the last major holdup for me to have my client use short packets
as default.  Please please Trent could you do this one, I'd do it myself
if I could make sense of short packet code.  You are the expert for sure.

Pros: support for modern bitmap sets, better looking ship turns, full
support for client bitmap rotation
Cons: are there any?  Can one argue more accurate ship headings gives an
unfair advantage in dogfighting?

2) Ability to bomb enemy 3rd space planets in your T-mode opponent's space
As often happens in T-mode games these days, there is some 3rd space
action, and often planets of the main 2 races get taken by a 3rd race.
These planets then become unbombable by Team B, if the planets are in Team
A's space, even though A and B are T-mode opponents.  In the worst case
scenario, team B can take all of team A's planets, but not be able to win
due to a 3rd space planet in team A's space that is full of armies and
unbombable.  Solution is to add some sort of variable that keeps track of
T-mode.

Pros: Minimizes impact of 3rd space activity in T mode game.
Cons: Can't think of any

3) Have server send info on torp and plasma fuses
If a player can see the torp/plasma fired, knowing the fuse times of the
various ships, and assuming no packet loss, he can pretty accurately
predict when a torp or plasma will run out.  Thus, I don't think it would
be too borgish to have server send this info (but only for torps fired on
screen, off screen torps from distance plinking should not have fuse info
sent).  The main reason I would like this is to determine the "newest"
torp for sound purposes - right now, if there are 20 torps on the screen,
I can't tell which one to play the torp sound for.  2 clients (NetrekXP
2006 and Paradise 2000) now have 3d sound - this would help make the sound
events more accurate.   It's the same for plasma, but it's a much bigger
deal for torps.

Pros: Accurate sound reporting for 3d sound clients
Cons: Possible borgish behavior to make torps visibly fuse out as they
reach end of life cycle, perhaps by blinking?  Of course, any clued player
will pretty much know when a torp is going to expire anyways.

4) Have SP2 send p_whydead to observers
Currently, when there is a genocide, observers get sent to team select
screen with an unknown p_whydead (it equals 0).  Once there, observers
then begin to get the right p_whydead info from server.  This causes 3
problems (at least for my client).  One, the observer gets wrong death
message on motd window.  Two, observer doesn't get the geno bitmap that
display on a geno.  Three, if observer rejoins game with new conquer code,
and then quits at some later time, he sees the geno bitmap (because his
p_whydead is still KWINNER).  Solution would be to add observer support to
sndSSelf packet (I think).

Pros: correct behavior for observer geno situations.  Also, added bonus of
maybe having an observer get info on how his observee died (perhaps having
a message flash across screen that describes the p_whydead state of his
observee).
Cons: extra bandwidth for observers in SP2 mode

5) Have server send estimated repair time to players in repair mode
It's currently possible for the client to calculate the estimated repair
rate by mimicing server code, and server defines (such as repair bonuses
for repair planets/bases, and ship defined repair rates).  However, there
are several issues.  One, observers don't get war/hostile info on planets,
so if their observee if at peace and orbitting a repair planet, the client
can't mimic server code calculating repair rate - it has to make an
educated guess as to whether that ship is at peace.
Of course, one could make a much more complex system to determine repair
rate, by tracking sequential packets to determine an average repair rate
empirically.  This system would need a lot of conditionals to work right.
Certain ships repair faster than others, and it may not be possible to get
an accurate repair rate for slow repairing ships, within the first second
or two of repair.  Secondly, damage taken to the ship while in repair mode
has to be taken into account from the repair rate averaging.  Thirdly, in
the case of constant damage (i.e repairing in range of an enemy planet
which slowly damages your ship) it may be quite hard to make sense of the
sequential changes in hull damage to get a repair rate.  My opinion is the
best way is to have the server send the information.

Pros: Eliminates a lot of client side copying of server code, guesswork
and/or laborious data tracking to get the repair rate
Cons: Client can sort of back calculate the repair rate already (with
limitations)

6) Have server send info on what planet you are orbitting
Currently, server will tell you that you are orbitting, but not what
planet you are orbitting.  I can envision several uses for this
information.  The client could perhaps have a little popup box that shows
a zoomed version of planet (on the galactic map) when you orbit.  Also, if
client is going to calculate repair times, it needs to know if you are
orbitting a repair planet or not.

Pros: Allows future client features
Cons: Client can sort of get this information already by finding closest
planet to your x,y loc.  Works in all situations except if planets move
and are almost on top of each other


Enough food for thought I hope.
Bill


From netrek at gmail.com  Mon May 29 06:28:48 2006
From: netrek at gmail.com (Zach)
Date: Mon, 29 May 2006 11:28:48 +0000
Subject: [netrek-dev] mypatch.dpatch darcs send -o yourfile.dpatch
Message-ID: <ecfa260c0605290428j32e424d4ld2c80707f57bd69c@mail.gmail.com>

can you see it? maybe quozl or jerub can apply this to their
development darcs repositories

zach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yourfile.dpatch
Type: application/octet-stream
Size: 30258 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060529/ba57fef0/attachment-0001.obj 

From quozl at us.netrek.org  Mon May 29 06:46:10 2006
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 29 May 2006 21:46:10 +1000
Subject: [netrek-dev] mypatch.dpatch darcs send -o yourfile.dpatch
In-Reply-To: <ecfa260c0605290428j32e424d4ld2c80707f57bd69c@mail.gmail.com>
References: <ecfa260c0605290428j32e424d4ld2c80707f57bd69c@mail.gmail.com>
Message-ID: <20060529114610.GE887@us.netrek.org>

Taken.

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


From keyos at keyos.org  Mon May 29 06:46:38 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Mon, 29 May 2006 14:46:38 +0300 (IDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <20060529110323.GD887@us.netrek.org>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
	<Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
	<20060529110323.GD887@us.netrek.org>
Message-ID: <Pine.GSO.4.63.0605291438251.8380@fcnep.argivfvba.arg.vy>

On Mon, 29 May 2006, James Cameron wrote:

> On Mon, May 29, 2006 at 12:49:32PM +0300, Stas Pirogov wrote:
> > Well, the point is to remove warning. It doesn't do anything wrong
> > if that's your question, but if I'd have option to fix some warning
> > I'd do that. Simply because new developer will see that warning and
> > take time to check what's wrong there.
> 
> Excellent, the more eyes the better.  Hopefully said developer will know
> enough to send in a patch.  ;-)
>

Haha.

Well, I'm attaching three patches actually to fix following:

* config.h.in comment in wrong place fix
 Comments are not allowed to present in same line as 'undef VARIABLE', otherwise the VARIABLE
 will never be set. This patch fixes two such mistakes by moving the comments one line above

* sys/socket addition to tools/players.c
 Apparently we're fighting for the right to have <sys/socket.h> included in numerous files.
 I hope I will win that.

* swap aclocal and libtoolize to remove warning
 aclocal should be run first to avoid libtoolize warning about missing aclocal.m4
 Also added --copy to libtoolize to make sure developer doesn't mess up system wide
 config.guess and config.sub

Hope you can drag them couple more days, so I won't have to patch CHANGES 
as well :)

Stas.
 
> -- 
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
> 
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
> 
-------------- next part --------------

New patches:

[config.h.in comment in wrong place fix
Stas Pirogov <keyos at keyos.org>**20060528203912
 Comments are not allowed to present in same line as 'undef VARIABLE', otherwise the VARIABLE
 will never be set. This patch fixes two such mistakes by moving the comments one line above
] 
<
> {
hunk ./Vanilla/include/config.h.in 475
 #define STDC_HEADERS 1 		/* 13/01/94 omit hosed index [007] */
 #undef HAVE_WAIT3 
 #undef NEED_SYS_SELECT_H 
-#undef NO_FD_SET		/* Guess we suck badly if that happens :( */
+				/* Guess we suck badly if that happens :( */
+#undef NO_FD_SET
 #undef HAVE_UNISTD_H 
 #undef HAVE_SYS_TIMEB_H
 #undef TM_IN_SYS_TIME 
hunk ./Vanilla/include/config.h.in 490
 #undef HAVE_SYS_RESOURCE_H
 #undef HAVE_SYS_WAIT_H
 #undef HAVE_NETINET_IN_H
-#undef HAVE_SYS_FILIO_H		/* Needed for Solaris 2.5.1 */
+				/* Needed for Solaris 2.x */
+#undef HAVE_SYS_FILIO_H
 #undef HAVE_GMP2_H
 #undef NO_U_INT 
 #undef SIZEOF_LONG
}

Context:

[experimental rework for wait queue dumping changelog
quozl at us.netrek.org**20060527090326] 
[experimental rework for wait queue dumping
quozl at us.netrek.org**20060527090226
 
 	* ntserv/openmem.c: experimental rework to support wait queue
 	dumping, and multiple server instances in separate shared memory
 	segments.  Provide interface so findslot will be able to detach
 	from an active game segment and create and attach to a new game
 	segment.  Accept NETREK_PKEY environment variable.
 
] 
[experiment slot number change command changelog
quozl at us.netrek.org**20060527071222] 
[experiment slot number change command
quozl at us.netrek.org**20060527071121
 
 	* ntserv/ntscmds.c (do_become): add experimental and not yet
 	functioning code to support change of slot number for a player.
 	Requires client-side support and further work.
 
] 
[robotd-toggle-newlogic-news.dpatch
jimmyhua73 at yahoo.com**20060527025530] 
[robotd-toggle-newlogic
jimmyhua73 at yahoo.com**20060527024334
 
 On request, the new logic that the robotd uses can be turned on and off
 via a commandfile or command sequence. Currently defaulted to off. 
 
 hcr -> assume humans carry
 ogh -> ogg carriers while I am bombing
 
 	* INSTALL.Newbie updated INSTALL.Newbie to document newer switches.
 	Need to include all possible robot switches in the future. 
 
 	* robotd/data.c added initialization of global variables hm_cr and 
 	ogg_happy
 
 	* robotd/data.h added global variables hm_cr and ogg_happy
 
 	* robotd/decide.c added check for ogg_happy mode before 
 	check_ogg while bombing
 
 	* robotd/dmessage.c added hcr and ogh message decoding. 
 
 	* robotd/update_players.c moved conservative assumptions that
 	humans carry into a new function called army_check3. 
 
 	* robotd/update_players.c added logic so army_check3 only 
 	executes if (hm_cr) global variable is active. 
 
 
 
] 
[resolve conflicts with newbie-configurable-robots-changelog.dpatch
Stephen Thorne <stephen at thorne.id.au>**20060526081423] 
[newbie-configurable-robots.dpatch
jimmyhua73 at yahoo.com**20060526063547
 
 	* INSTALL.Newbie updated documentation to show how to configure
 	the robots to be dumber
 
 	* robotd/data.c changed default updates=2.0 instead of 1.0, decreases
 	CPU load by 50% and fights about the same. 
 
 	* robotd/dmessage.c allow decoding of local messages and commandfile
 	messages even if robot is in INL mode. In INL mode, robots will 
 	ignore other players and GOD's commands. 
 
 	* robots/newbie.c checkpos() returns 1, to avoid compiler warning
 
 	* robots/newbie.c added a bunch of comments on what each option
 	does, when Merlin forks a robot. 
 
 	* robots/newbie.c modified the command so robots now read a command
 	file on startup. 
 
] 
[newbie-configurable-robots-changelog.dpatch
jimmyhua73 at yahoo.com**20060526064353] 
[ping pong plasma bot changelog
quozl at us.netrek.org**20060525050440] 
[remove res-rsa/configure
Trent Piepho <xyzzy at speakeasy.org>**20060525015328
 This is a generated file and shouldn't be kept in the repository.
] 
[help bot deal with ping-pong plasma
Trent Piepho <xyzzy at speakeasy.org>**20060525030034
 The robot has code to deal with Ping-Pong plasma, but it's an old
 version.  It doesn't work properly with the current ping pong plasmas,
 written by Trent Piepho in 1995 (so the old ones are really old!). 
 Basically, the bots needs to allow for plasma fired by a friendly player
 becoming hostile to it.
       
 Also sets the pl_team member of the plasma struct, which makes getting
 the plasma's team easier.
] 
[help client with plasma war in ping-pong mode
Trent Piepho <xyzzy at speakeasy.org>**20060525025806
 In Ping-Pong plasma mode, a plasma changes teams when it is bounced. 
 There is no way to send this change to the client, so the client doesn't
 know.  For example, if a player at peace with us but who we are at war
 with bounces our (or a teammate's) plasma back at us, it appears to the
 client that the plasma is friendly.  But really, it's not, since we are
 at war with the plasma's new team.  Fix this by setting the plasma's war
 flag if the player is hostile to the plasma's team.
  
 In order to take advantage of this, clients will need to be sure to:
 1. Not assume that the player's own plasma is friendly.
 2. Not assume that plasma from the player's team is friendly.
 3. Make sure the check the plasma's war flags, and not the flags of the
 player who fired it.
 
] 
[deprecate dan quayle in t-mode messages changelog
quozl at us.netrek.org**20060525041559] 
[deprecate dan quayle in t-mode messages
quozl at us.netrek.org**20060525041344
 
 	* include/defs.h (WARMONGER): add customisation setting for
 	configuration of local warmonger, so that we are not caught by
 	change again so easily.
 
 	* ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
 	favour of George Bush, subject to mailing list discussion.  Patch
 	by: William Balcerski with rework by James Cameron.
 
] 
[rewrite build test script changelog
quozl at us.netrek.org**20060525013820] 
[rewrite build test script
quozl at us.netrek.org**20060525013317
 
 	* autogen.sh: add res-rsa to autoconf re-run,
 
 	* tests/build: test for correct directory, use darcs get instead
 	of put, use autogen.sh instead of running autotools here, add the
 	install target.
 
 	"darcs put" is slow, the darcs manual recommends "darcs get" instead,
 	which is certainly faster.  But "darcs get" must have the exact path to
 	a repo, not like "darcs put".  So a test is added to check that we are
 	in the right directory first.
 
] 
[Player position sign fix
williamb at its.caltech.edu*-20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[robotd omnibus 2 changelog
quozl at us.netrek.org**20060525003615
 Addition of ChangeLog and NEWS entries to cover Trent Piepho's rework 
 of Jimmy Huang's changes to robotd.
] 
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060524082754
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 players' torps too.  Without it, the bot thinks all torps are going
 straight up, making it a very bad dodger (unless you attack from below). 
   
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060524082708
 Some calls to req_cloak_off() were missing the function's argument,
 the reason string.
] 
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060524082437
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping the bots's own HW, for proximity.  This makes the code
 much smaller and faster.  Realistically, the HWs are always at the
 standard indexes, even with non-standard planet layouts.  Included a bit
 of code, #if'ed out, that will find home worlds by name, the way the bot
 does when it wants to refit.
] 
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060524082353
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060524082241
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060524082149
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060524082029
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
] 
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060524081723
 The assault planet code didn't re-check the target planet after the
 assault started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060524081613
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[robotd mfprintf regression fix
quozl at us.netrek.org*-20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com*-20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[fix ranlib for solaris changelog
Stas Pirogov <keyos at keyos.org>**20060524235806] 
[fix ranlib for solaris
Stas Pirogov <keyos at keyos.org>**20060524235510
 
 	* configure.in: test for ranlib was failing on Solaris. This is
 	probably caused by different /bin/sh interpreters.  This fix should
 	satisfy all of them.
 
] 
[PROJECTS update
williamb at its.caltech.edu**20060524093948
 Removed twarp observer bug from PROJECTS list, as this has been fixed.
] 
[conflict resolution 2006-08-24-a
quozl at us.netrek.org**20060524042919] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[Player position sign fix
williamb at its.caltech.edu**20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[fix SP_2 flag sending for real changelog
quozl at us.netrek.org**20060524024253] 
[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
[remove generated autotools files
quozl at us.netrek.org**20060524015023
 aclocal.m4 and configure are generated files, they are generated using
 autogen.sh from configure.in, and as such they do not deserve to be in the
 repository and are costing us time and energy as they change.
] 
[misc bugs update
quozl at us.netrek.org**20060524014925] 
[deprecate README.darcs execution in favour of autogen.sh changelog
quozl at us.netrek.org**20060524011944] 
[deprecate README.darcs execution in favour of autogen.sh
quozl at us.netrek.org**20060524011759
 
 	* autogen.sh: add GNU standard autotools configuration sequence,
 	deprecating execution of README.darcs.  Manual build process then
 	becomes "sh autogen.sh" followed by the usual configure, make, and
 	make install.
 
] 
[newbie-fixes.dpatch changelog conflict resolution
quozl at us.netrek.org**20060524005953] 
[newbie-fixes.dpatch
jimmyhua73 at yahoo.com**20060523153223
 
  Bug fixes:
 
   1. Merlin gets moved on genocide. Now Merlin moves himself back.
   2. You can get Merlin into a race condition by timing your join and
   joining something other than what Merlin chooses for the warring teams.
   This is fixed (I think). I was never able to time this right!!!
   James please check again!
 
  Known Bug:
 
  1. t-mode criteria is hardcoded into Merlin as 4 players a side.
 
  ChangeLog here:
 
      * robots/newbie.c changed some tabbing for better indent and bracing
      consistency.
 
      * robots/newbie.c added #defines POSITIONX and POSITIONY so there's
      only one place the change the desired x and y position of Merlin
 
      * robots/newbie.c added checkpos() function which checks for changes
      in Merlin's position. Replaces him back into POSITIONX and POSITIONY
      once it finds that Merlin has stopped moving for 15 seconds.
 
      * robots/newbie.c corrected misspellings of various comments
 
      * robots/newbie.c modified num_players() function to return
      the correct *next_team based on t-mode settings also
 
] 
[robotd_udcounter.dpatch
jimmyhua73 at yahoo.com**20060523143934
 
 I re-did the setflag() function, so it now will always report back
 a positive incrementing int at 100ms intervals. And it starts with 0
 on program start. 
 
 There are some other places that initialize _udcounter, I think this
 might need to be got rid of, but I didn't do that in this patch. 
 
 Read the longwinded diatribe in the Changelog. 
 
] 
[newbie-install-docs-update.dpatch
jimmyhua73 at yahoo.com**20060523155757
 
 Updated the installation document for newbie
 
] 
[robotd mfprintf regression fix changelog
quozl at us.netrek.org**20060524004957] 
[robotd mfprintf regression fix
quozl at us.netrek.org**20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[revised coding style and darcs discipline
quozl at us.netrek.org**20060523050927
 Rewrite of the coding style and patch acceptance criteria based on 
 feedback on the mailing list from Stephen Thorne and Trent Piepho.
] 
[Declare_war fix
williamb at its.caltech.edu**20060522012930
         * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
           added boolean to declare_war function to indicate whether to
           add delay and send delay message.  Fixes the case of unwanted 
           war delay message when switching teams, and also prevents robots
           from entering a state of permanent declare war delay.
] 
[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
558cc33e9b08f4265190265ce31378731feff413
-------------- next part --------------

New patches:

[swap aclocal and libtoolize to remove warning
Stas Pirogov <keyos at keyos.org>**20060529113401
 aclocal should be run first to avoid libtoolize warning about missing aclocal.m4
 Also added --copy to libtoolize to make sure developer doesn't mess up system wide
 config.guess and config.sub
] 
<
> {
hunk ./Vanilla/autogen.sh 2
 #!/bin/sh
-libtoolize
 aclocal
hunk ./Vanilla/autogen.sh 3
+libtoolize --copy
 autoconf
 cd res-rsa && autoconf && cd ..
 chmod +x tools/mktrekon
}

Context:

[experimental rework for wait queue dumping changelog
quozl at us.netrek.org**20060527090326] 
[experimental rework for wait queue dumping
quozl at us.netrek.org**20060527090226
 
 	* ntserv/openmem.c: experimental rework to support wait queue
 	dumping, and multiple server instances in separate shared memory
 	segments.  Provide interface so findslot will be able to detach
 	from an active game segment and create and attach to a new game
 	segment.  Accept NETREK_PKEY environment variable.
 
] 
[experiment slot number change command changelog
quozl at us.netrek.org**20060527071222] 
[experiment slot number change command
quozl at us.netrek.org**20060527071121
 
 	* ntserv/ntscmds.c (do_become): add experimental and not yet
 	functioning code to support change of slot number for a player.
 	Requires client-side support and further work.
 
] 
[robotd-toggle-newlogic-news.dpatch
jimmyhua73 at yahoo.com**20060527025530] 
[robotd-toggle-newlogic
jimmyhua73 at yahoo.com**20060527024334
 
 On request, the new logic that the robotd uses can be turned on and off
 via a commandfile or command sequence. Currently defaulted to off. 
 
 hcr -> assume humans carry
 ogh -> ogg carriers while I am bombing
 
 	* INSTALL.Newbie updated INSTALL.Newbie to document newer switches.
 	Need to include all possible robot switches in the future. 
 
 	* robotd/data.c added initialization of global variables hm_cr and 
 	ogg_happy
 
 	* robotd/data.h added global variables hm_cr and ogg_happy
 
 	* robotd/decide.c added check for ogg_happy mode before 
 	check_ogg while bombing
 
 	* robotd/dmessage.c added hcr and ogh message decoding. 
 
 	* robotd/update_players.c moved conservative assumptions that
 	humans carry into a new function called army_check3. 
 
 	* robotd/update_players.c added logic so army_check3 only 
 	executes if (hm_cr) global variable is active. 
 
 
 
] 
[resolve conflicts with newbie-configurable-robots-changelog.dpatch
Stephen Thorne <stephen at thorne.id.au>**20060526081423] 
[newbie-configurable-robots.dpatch
jimmyhua73 at yahoo.com**20060526063547
 
 	* INSTALL.Newbie updated documentation to show how to configure
 	the robots to be dumber
 
 	* robotd/data.c changed default updates=2.0 instead of 1.0, decreases
 	CPU load by 50% and fights about the same. 
 
 	* robotd/dmessage.c allow decoding of local messages and commandfile
 	messages even if robot is in INL mode. In INL mode, robots will 
 	ignore other players and GOD's commands. 
 
 	* robots/newbie.c checkpos() returns 1, to avoid compiler warning
 
 	* robots/newbie.c added a bunch of comments on what each option
 	does, when Merlin forks a robot. 
 
 	* robots/newbie.c modified the command so robots now read a command
 	file on startup. 
 
] 
[newbie-configurable-robots-changelog.dpatch
jimmyhua73 at yahoo.com**20060526064353] 
[ping pong plasma bot changelog
quozl at us.netrek.org**20060525050440] 
[remove res-rsa/configure
Trent Piepho <xyzzy at speakeasy.org>**20060525015328
 This is a generated file and shouldn't be kept in the repository.
] 
[help bot deal with ping-pong plasma
Trent Piepho <xyzzy at speakeasy.org>**20060525030034
 The robot has code to deal with Ping-Pong plasma, but it's an old
 version.  It doesn't work properly with the current ping pong plasmas,
 written by Trent Piepho in 1995 (so the old ones are really old!). 
 Basically, the bots needs to allow for plasma fired by a friendly player
 becoming hostile to it.
       
 Also sets the pl_team member of the plasma struct, which makes getting
 the plasma's team easier.
] 
[help client with plasma war in ping-pong mode
Trent Piepho <xyzzy at speakeasy.org>**20060525025806
 In Ping-Pong plasma mode, a plasma changes teams when it is bounced. 
 There is no way to send this change to the client, so the client doesn't
 know.  For example, if a player at peace with us but who we are at war
 with bounces our (or a teammate's) plasma back at us, it appears to the
 client that the plasma is friendly.  But really, it's not, since we are
 at war with the plasma's new team.  Fix this by setting the plasma's war
 flag if the player is hostile to the plasma's team.
  
 In order to take advantage of this, clients will need to be sure to:
 1. Not assume that the player's own plasma is friendly.
 2. Not assume that plasma from the player's team is friendly.
 3. Make sure the check the plasma's war flags, and not the flags of the
 player who fired it.
 
] 
[deprecate dan quayle in t-mode messages changelog
quozl at us.netrek.org**20060525041559] 
[deprecate dan quayle in t-mode messages
quozl at us.netrek.org**20060525041344
 
 	* include/defs.h (WARMONGER): add customisation setting for
 	configuration of local warmonger, so that we are not caught by
 	change again so easily.
 
 	* ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
 	favour of George Bush, subject to mailing list discussion.  Patch
 	by: William Balcerski with rework by James Cameron.
 
] 
[rewrite build test script changelog
quozl at us.netrek.org**20060525013820] 
[rewrite build test script
quozl at us.netrek.org**20060525013317
 
 	* autogen.sh: add res-rsa to autoconf re-run,
 
 	* tests/build: test for correct directory, use darcs get instead
 	of put, use autogen.sh instead of running autotools here, add the
 	install target.
 
 	"darcs put" is slow, the darcs manual recommends "darcs get" instead,
 	which is certainly faster.  But "darcs get" must have the exact path to
 	a repo, not like "darcs put".  So a test is added to check that we are
 	in the right directory first.
 
] 
[Player position sign fix
williamb at its.caltech.edu*-20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[robotd omnibus 2 changelog
quozl at us.netrek.org**20060525003615
 Addition of ChangeLog and NEWS entries to cover Trent Piepho's rework 
 of Jimmy Huang's changes to robotd.
] 
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060524082754
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 players' torps too.  Without it, the bot thinks all torps are going
 straight up, making it a very bad dodger (unless you attack from below). 
   
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060524082708
 Some calls to req_cloak_off() were missing the function's argument,
 the reason string.
] 
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060524082437
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping the bots's own HW, for proximity.  This makes the code
 much smaller and faster.  Realistically, the HWs are always at the
 standard indexes, even with non-standard planet layouts.  Included a bit
 of code, #if'ed out, that will find home worlds by name, the way the bot
 does when it wants to refit.
] 
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060524082353
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060524082241
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060524082149
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060524082029
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
] 
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060524081723
 The assault planet code didn't re-check the target planet after the
 assault started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060524081613
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[robotd mfprintf regression fix
quozl at us.netrek.org*-20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com*-20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[fix ranlib for solaris changelog
Stas Pirogov <keyos at keyos.org>**20060524235806] 
[fix ranlib for solaris
Stas Pirogov <keyos at keyos.org>**20060524235510
 
 	* configure.in: test for ranlib was failing on Solaris. This is
 	probably caused by different /bin/sh interpreters.  This fix should
 	satisfy all of them.
 
] 
[PROJECTS update
williamb at its.caltech.edu**20060524093948
 Removed twarp observer bug from PROJECTS list, as this has been fixed.
] 
[conflict resolution 2006-08-24-a
quozl at us.netrek.org**20060524042919] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[Player position sign fix
williamb at its.caltech.edu**20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[fix SP_2 flag sending for real changelog
quozl at us.netrek.org**20060524024253] 
[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
[remove generated autotools files
quozl at us.netrek.org**20060524015023
 aclocal.m4 and configure are generated files, they are generated using
 autogen.sh from configure.in, and as such they do not deserve to be in the
 repository and are costing us time and energy as they change.
] 
[misc bugs update
quozl at us.netrek.org**20060524014925] 
[deprecate README.darcs execution in favour of autogen.sh changelog
quozl at us.netrek.org**20060524011944] 
[deprecate README.darcs execution in favour of autogen.sh
quozl at us.netrek.org**20060524011759
 
 	* autogen.sh: add GNU standard autotools configuration sequence,
 	deprecating execution of README.darcs.  Manual build process then
 	becomes "sh autogen.sh" followed by the usual configure, make, and
 	make install.
 
] 
[newbie-fixes.dpatch changelog conflict resolution
quozl at us.netrek.org**20060524005953] 
[newbie-fixes.dpatch
jimmyhua73 at yahoo.com**20060523153223
 
  Bug fixes:
 
   1. Merlin gets moved on genocide. Now Merlin moves himself back.
   2. You can get Merlin into a race condition by timing your join and
   joining something other than what Merlin chooses for the warring teams.
   This is fixed (I think). I was never able to time this right!!!
   James please check again!
 
  Known Bug:
 
  1. t-mode criteria is hardcoded into Merlin as 4 players a side.
 
  ChangeLog here:
 
      * robots/newbie.c changed some tabbing for better indent and bracing
      consistency.
 
      * robots/newbie.c added #defines POSITIONX and POSITIONY so there's
      only one place the change the desired x and y position of Merlin
 
      * robots/newbie.c added checkpos() function which checks for changes
      in Merlin's position. Replaces him back into POSITIONX and POSITIONY
      once it finds that Merlin has stopped moving for 15 seconds.
 
      * robots/newbie.c corrected misspellings of various comments
 
      * robots/newbie.c modified num_players() function to return
      the correct *next_team based on t-mode settings also
 
] 
[robotd_udcounter.dpatch
jimmyhua73 at yahoo.com**20060523143934
 
 I re-did the setflag() function, so it now will always report back
 a positive incrementing int at 100ms intervals. And it starts with 0
 on program start. 
 
 There are some other places that initialize _udcounter, I think this
 might need to be got rid of, but I didn't do that in this patch. 
 
 Read the longwinded diatribe in the Changelog. 
 
] 
[newbie-install-docs-update.dpatch
jimmyhua73 at yahoo.com**20060523155757
 
 Updated the installation document for newbie
 
] 
[robotd mfprintf regression fix changelog
quozl at us.netrek.org**20060524004957] 
[robotd mfprintf regression fix
quozl at us.netrek.org**20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[revised coding style and darcs discipline
quozl at us.netrek.org**20060523050927
 Rewrite of the coding style and patch acceptance criteria based on 
 feedback on the mailing list from Stephen Thorne and Trent Piepho.
] 
[Declare_war fix
williamb at its.caltech.edu**20060522012930
         * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
           added boolean to declare_war function to indicate whether to
           add delay and send delay message.  Fixes the case of unwanted 
           war delay message when switching teams, and also prevents robots
           from entering a state of permanent declare war delay.
] 
[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
b2de63a5b6207bf4fd32b7b7bc22c6a9eb7523d7
-------------- next part --------------

New patches:

[sys/socket addition to tools/players.c
Stas Pirogov <keyos at keyos.org>**20060529114049
 Apparently we're fighting for the right to have <sys/socket.h> included in numerous files.
 I hope I will win that.
] 
<
> {
hunk ./Vanilla/tools/players.c 7
 #include <unistd.h>
 #include <errno.h>
 #include <arpa/inet.h>
+#include <sys/socket.h>
 #include "defs.h"
 #include "struct.h"
 #include "data.h"
}

Context:

[experimental rework for wait queue dumping changelog
quozl at us.netrek.org**20060527090326] 
[experimental rework for wait queue dumping
quozl at us.netrek.org**20060527090226
 
 	* ntserv/openmem.c: experimental rework to support wait queue
 	dumping, and multiple server instances in separate shared memory
 	segments.  Provide interface so findslot will be able to detach
 	from an active game segment and create and attach to a new game
 	segment.  Accept NETREK_PKEY environment variable.
 
] 
[experiment slot number change command changelog
quozl at us.netrek.org**20060527071222] 
[experiment slot number change command
quozl at us.netrek.org**20060527071121
 
 	* ntserv/ntscmds.c (do_become): add experimental and not yet
 	functioning code to support change of slot number for a player.
 	Requires client-side support and further work.
 
] 
[robotd-toggle-newlogic-news.dpatch
jimmyhua73 at yahoo.com**20060527025530] 
[robotd-toggle-newlogic
jimmyhua73 at yahoo.com**20060527024334
 
 On request, the new logic that the robotd uses can be turned on and off
 via a commandfile or command sequence. Currently defaulted to off. 
 
 hcr -> assume humans carry
 ogh -> ogg carriers while I am bombing
 
 	* INSTALL.Newbie updated INSTALL.Newbie to document newer switches.
 	Need to include all possible robot switches in the future. 
 
 	* robotd/data.c added initialization of global variables hm_cr and 
 	ogg_happy
 
 	* robotd/data.h added global variables hm_cr and ogg_happy
 
 	* robotd/decide.c added check for ogg_happy mode before 
 	check_ogg while bombing
 
 	* robotd/dmessage.c added hcr and ogh message decoding. 
 
 	* robotd/update_players.c moved conservative assumptions that
 	humans carry into a new function called army_check3. 
 
 	* robotd/update_players.c added logic so army_check3 only 
 	executes if (hm_cr) global variable is active. 
 
 
 
] 
[resolve conflicts with newbie-configurable-robots-changelog.dpatch
Stephen Thorne <stephen at thorne.id.au>**20060526081423] 
[newbie-configurable-robots.dpatch
jimmyhua73 at yahoo.com**20060526063547
 
 	* INSTALL.Newbie updated documentation to show how to configure
 	the robots to be dumber
 
 	* robotd/data.c changed default updates=2.0 instead of 1.0, decreases
 	CPU load by 50% and fights about the same. 
 
 	* robotd/dmessage.c allow decoding of local messages and commandfile
 	messages even if robot is in INL mode. In INL mode, robots will 
 	ignore other players and GOD's commands. 
 
 	* robots/newbie.c checkpos() returns 1, to avoid compiler warning
 
 	* robots/newbie.c added a bunch of comments on what each option
 	does, when Merlin forks a robot. 
 
 	* robots/newbie.c modified the command so robots now read a command
 	file on startup. 
 
] 
[newbie-configurable-robots-changelog.dpatch
jimmyhua73 at yahoo.com**20060526064353] 
[ping pong plasma bot changelog
quozl at us.netrek.org**20060525050440] 
[remove res-rsa/configure
Trent Piepho <xyzzy at speakeasy.org>**20060525015328
 This is a generated file and shouldn't be kept in the repository.
] 
[help bot deal with ping-pong plasma
Trent Piepho <xyzzy at speakeasy.org>**20060525030034
 The robot has code to deal with Ping-Pong plasma, but it's an old
 version.  It doesn't work properly with the current ping pong plasmas,
 written by Trent Piepho in 1995 (so the old ones are really old!). 
 Basically, the bots needs to allow for plasma fired by a friendly player
 becoming hostile to it.
       
 Also sets the pl_team member of the plasma struct, which makes getting
 the plasma's team easier.
] 
[help client with plasma war in ping-pong mode
Trent Piepho <xyzzy at speakeasy.org>**20060525025806
 In Ping-Pong plasma mode, a plasma changes teams when it is bounced. 
 There is no way to send this change to the client, so the client doesn't
 know.  For example, if a player at peace with us but who we are at war
 with bounces our (or a teammate's) plasma back at us, it appears to the
 client that the plasma is friendly.  But really, it's not, since we are
 at war with the plasma's new team.  Fix this by setting the plasma's war
 flag if the player is hostile to the plasma's team.
  
 In order to take advantage of this, clients will need to be sure to:
 1. Not assume that the player's own plasma is friendly.
 2. Not assume that plasma from the player's team is friendly.
 3. Make sure the check the plasma's war flags, and not the flags of the
 player who fired it.
 
] 
[deprecate dan quayle in t-mode messages changelog
quozl at us.netrek.org**20060525041559] 
[deprecate dan quayle in t-mode messages
quozl at us.netrek.org**20060525041344
 
 	* include/defs.h (WARMONGER): add customisation setting for
 	configuration of local warmonger, so that we are not caught by
 	change again so easily.
 
 	* ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
 	favour of George Bush, subject to mailing list discussion.  Patch
 	by: William Balcerski with rework by James Cameron.
 
] 
[rewrite build test script changelog
quozl at us.netrek.org**20060525013820] 
[rewrite build test script
quozl at us.netrek.org**20060525013317
 
 	* autogen.sh: add res-rsa to autoconf re-run,
 
 	* tests/build: test for correct directory, use darcs get instead
 	of put, use autogen.sh instead of running autotools here, add the
 	install target.
 
 	"darcs put" is slow, the darcs manual recommends "darcs get" instead,
 	which is certainly faster.  But "darcs get" must have the exact path to
 	a repo, not like "darcs put".  So a test is added to check that we are
 	in the right directory first.
 
] 
[Player position sign fix
williamb at its.caltech.edu*-20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[robotd omnibus 2 changelog
quozl at us.netrek.org**20060525003615
 Addition of ChangeLog and NEWS entries to cover Trent Piepho's rework 
 of Jimmy Huang's changes to robotd.
] 
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060524082754
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 players' torps too.  Without it, the bot thinks all torps are going
 straight up, making it a very bad dodger (unless you attack from below). 
   
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060524082708
 Some calls to req_cloak_off() were missing the function's argument,
 the reason string.
] 
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060524082437
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping the bots's own HW, for proximity.  This makes the code
 much smaller and faster.  Realistically, the HWs are always at the
 standard indexes, even with non-standard planet layouts.  Included a bit
 of code, #if'ed out, that will find home worlds by name, the way the bot
 does when it wants to refit.
] 
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060524082353
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060524082241
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060524082149
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060524082029
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
] 
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060524081723
 The assault planet code didn't re-check the target planet after the
 assault started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060524081613
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[robotd mfprintf regression fix
quozl at us.netrek.org*-20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com*-20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[fix ranlib for solaris changelog
Stas Pirogov <keyos at keyos.org>**20060524235806] 
[fix ranlib for solaris
Stas Pirogov <keyos at keyos.org>**20060524235510
 
 	* configure.in: test for ranlib was failing on Solaris. This is
 	probably caused by different /bin/sh interpreters.  This fix should
 	satisfy all of them.
 
] 
[PROJECTS update
williamb at its.caltech.edu**20060524093948
 Removed twarp observer bug from PROJECTS list, as this has been fixed.
] 
[conflict resolution 2006-08-24-a
quozl at us.netrek.org**20060524042919] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[Player position sign fix
williamb at its.caltech.edu**20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[fix SP_2 flag sending for real changelog
quozl at us.netrek.org**20060524024253] 
[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
[remove generated autotools files
quozl at us.netrek.org**20060524015023
 aclocal.m4 and configure are generated files, they are generated using
 autogen.sh from configure.in, and as such they do not deserve to be in the
 repository and are costing us time and energy as they change.
] 
[misc bugs update
quozl at us.netrek.org**20060524014925] 
[deprecate README.darcs execution in favour of autogen.sh changelog
quozl at us.netrek.org**20060524011944] 
[deprecate README.darcs execution in favour of autogen.sh
quozl at us.netrek.org**20060524011759
 
 	* autogen.sh: add GNU standard autotools configuration sequence,
 	deprecating execution of README.darcs.  Manual build process then
 	becomes "sh autogen.sh" followed by the usual configure, make, and
 	make install.
 
] 
[newbie-fixes.dpatch changelog conflict resolution
quozl at us.netrek.org**20060524005953] 
[newbie-fixes.dpatch
jimmyhua73 at yahoo.com**20060523153223
 
  Bug fixes:
 
   1. Merlin gets moved on genocide. Now Merlin moves himself back.
   2. You can get Merlin into a race condition by timing your join and
   joining something other than what Merlin chooses for the warring teams.
   This is fixed (I think). I was never able to time this right!!!
   James please check again!
 
  Known Bug:
 
  1. t-mode criteria is hardcoded into Merlin as 4 players a side.
 
  ChangeLog here:
 
      * robots/newbie.c changed some tabbing for better indent and bracing
      consistency.
 
      * robots/newbie.c added #defines POSITIONX and POSITIONY so there's
      only one place the change the desired x and y position of Merlin
 
      * robots/newbie.c added checkpos() function which checks for changes
      in Merlin's position. Replaces him back into POSITIONX and POSITIONY
      once it finds that Merlin has stopped moving for 15 seconds.
 
      * robots/newbie.c corrected misspellings of various comments
 
      * robots/newbie.c modified num_players() function to return
      the correct *next_team based on t-mode settings also
 
] 
[robotd_udcounter.dpatch
jimmyhua73 at yahoo.com**20060523143934
 
 I re-did the setflag() function, so it now will always report back
 a positive incrementing int at 100ms intervals. And it starts with 0
 on program start. 
 
 There are some other places that initialize _udcounter, I think this
 might need to be got rid of, but I didn't do that in this patch. 
 
 Read the longwinded diatribe in the Changelog. 
 
] 
[newbie-install-docs-update.dpatch
jimmyhua73 at yahoo.com**20060523155757
 
 Updated the installation document for newbie
 
] 
[robotd mfprintf regression fix changelog
quozl at us.netrek.org**20060524004957] 
[robotd mfprintf regression fix
quozl at us.netrek.org**20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[revised coding style and darcs discipline
quozl at us.netrek.org**20060523050927
 Rewrite of the coding style and patch acceptance criteria based on 
 feedback on the mailing list from Stephen Thorne and Trent Piepho.
] 
[Declare_war fix
williamb at its.caltech.edu**20060522012930
         * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
           added boolean to declare_war function to indicate whether to
           add delay and send delay message.  Fixes the case of unwanted 
           war delay message when switching teams, and also prevents robots
           from entering a state of permanent declare war delay.
] 
[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
b6dee5047f3ad1b702fdf91038115bde57caf7f0

From netrek at gmail.com  Mon May 29 06:57:44 2006
From: netrek at gmail.com (Zach)
Date: Mon, 29 May 2006 11:57:44 +0000
Subject: [netrek-dev] mypatch.dpatch darcs send -o yourfile.dpatch
In-Reply-To: <20060529114610.GE887@us.netrek.org>
References: <ecfa260c0605290428j32e424d4ld2c80707f57bd69c@mail.gmail.com>
	<20060529114610.GE887@us.netrek.org>
Message-ID: <ecfa260c0605290457p3faafbcbi14534f31718296b5@mail.gmail.com>

Cool. I noticed I do not receive copies of my own posts to netrek-dev!
But when someone references it then I see it. How can I tell the
netrek-dev mailing list to send me copies of my own posts? I see my
post in the archive:
http://archives.us.netrek.org/pipermail/netrek-dev/2006-May/003411.html

Zach


From netrek at gmail.com  Mon May 29 07:04:42 2006
From: netrek at gmail.com (Zach)
Date: Mon, 29 May 2006 12:04:42 +0000
Subject: [netrek-dev] Features I'd like to be added to server (long)
In-Reply-To: <Pine.GSO.4.58.0605290327370.12165@sue>
References: <Pine.GSO.4.58.0605290327370.12165@sue>
Message-ID: <ecfa260c0605290504i292ed3eex14ebaae36c3f55e3@mail.gmail.com>

wow keep the ideas rolling, good stuff~

zach


From jimmyhua73 at yahoo.com  Mon May 29 09:11:02 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 29 May 2006 07:11:02 -0700 (PDT)
Subject: [netrek-dev] Vanilla build broken :(
In-Reply-To: <20060529064529.GE8047@us.netrek.org>
Message-ID: <20060529141102.98624.qmail@web35309.mail.mud.yahoo.com>



--- James Cameron <quozl at us.netrek.org> wrote:
> On Sat, May 27, 2006 at 05:37:19PM -0700, Jimmy
> Huang wrote:
> > I agree it should have been documented. 
> > sh autogen.sh
> > ./configure --prefix==/tmp/netrek
> 
> Are you sure about that double equals sign, Jimmy? 
> I've not tried that.

That's a tipo. I've tried it, and it doesn't work :-).


Jimmy



From jimmyhua73 at yahoo.com  Mon May 29 20:12:38 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Mon, 29 May 2006 18:12:38 -0700 (PDT)
Subject: [netrek-dev] More minor house-keeping on robotd
Message-ID: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>


When I first found the mfprintf function not working.
My first solution was to remove it. All calls to
mfprintf were commented out and replaced with fprintf.


Now, thanks to Trent's and James' efforts. It is
working again. 

During the manual patching, some of the original calls
to mfprintf remained commented out. So here is the
patch to fix this. 

Also, removed comment on how mfprintf SIGSEV's. This
is no longer true. 

Attached is the patch and Changelog. No news, as this
is housekeeping work. 

Along the same lines, I found a bunch of calls to
fprintf that were there from the very beginning! Not
sure if it is more appropriate to change these to
mfprintf.  Not sure what to do about these, I'm
leaving them alone for now :-). 


Jimmy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mfprintf-calls-changelog.dpatch
Type: application/octet-stream
Size: 30644 bytes
Desc: 3077174388-mfprintf-calls-changelog.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060529/058539a7/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mfprintf-calls.dpatch
Type: application/octet-stream
Size: 32713 bytes
Desc: 2875811182-mfprintf-calls.dpatch
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060529/058539a7/attachment-0003.obj 

From xyzzy at speakeasy.org  Mon May 29 23:31:36 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Mon, 29 May 2006 21:31:36 -0700 (PDT)
Subject: [netrek-dev] More minor house-keeping on robotd
In-Reply-To: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
References: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.58.0605292111150.28394@shell2.speakeasy.net>

On Mon, 29 May 2006, Jimmy Huang wrote:
> During the manual patching, some of the original calls
> to mfprintf remained commented out. So here is the
> patch to fix this.

This appears to be a bugs in darcs.  Those changes were made in the patch
robotd-fixes1.dpatch, then rolled back.  darcs should have undone all the
changes.  Maybe this is why James didn't apply my mprintf fix along with all my
other robot fixes, because that file didn't get rolled back.

robotd-fixes1.dpatch changed these files:
$ darcs diff -p '^robotd-fixes1.dpatch$' | grep diff
diff -rN -u old-netrek-server/Vanilla/robotd/assault.c new-netrek-server/Vanilla/robotd/assault.c
diff -rN -u old-netrek-server/Vanilla/robotd/decide.c new-netrek-server/Vanilla/robotd/decide.c
diff -rN -u old-netrek-server/Vanilla/robotd/main.c new-netrek-server/Vanilla/robotd/main.c
diff -rN -u old-netrek-server/Vanilla/robotd/shmem.c new-netrek-server/Vanilla/robotd/shmem.c
diff -rN -u old-netrek-server/Vanilla/robotd/socket.c new-netrek-server/Vanilla/robotd/socket.c
diff -rN -u old-netrek-server/Vanilla/robotd/update_players.c new-netrek-server/Vanilla/robotd/update_players.c
diff -rN -u old-netrek-server/Vanilla/robotd/util.c new-netrek-server/Vanilla/robotd/util.c

Then the rollback only changed these files:
$ darcs diff -p '^UNDO: robotd-fixes1.dpatch$' | grep diff
diff -rN -u old-netrek-server/Vanilla/robotd/assault.c new-netrek-server/Vanilla/robotd/assault.c
diff -rN -u old-netrek-server/Vanilla/robotd/decide.c new-netrek-server/Vanilla/robotd/decide.c
diff -rN -u old-netrek-server/Vanilla/robotd/shmem.c new-netrek-server/Vanilla/robotd/shmem.c
diff -rN -u old-netrek-server/Vanilla/robotd/update_players.c new-netrek-server/Vanilla/robotd/update_players.c

The changes to robotd/util.c, robotd/socket.c, and robotd/main.c didn't get
undone at all.  Some of the other files are missing changes too.  The first patch
changed update_players at lines
@@ -142,11 +142,13 @@
@@ -277,7 +279,8 @@
@@ -1091,7 +1094,8 @@
@@ -1349,7 +1353,7 @@

The undo patch only undid code at:
@@ -1094,8 +1094,7 @@
@@ -1353,7 +1352,7 @@

The problem isn't just here.  My robot fixes that I sent to James don't appear
to have been applied correctly.
$ darcs diff -p '^fix use of un-initialized variable$'
  * fix use of un-initialized variable
  Fix a warning about a un-initialized use of pldist in update_players().
  It didn't matter, but fix the warning anyway.

No diff!  The patch shows up as being there, but it's just blank!  Same with
this one:

$ darcs diff -p 'fix mfprintf()'
  * fix mfprintf()
  When mfprintf() was changed from varargs to stdarg, it wasn't done
  correctly.  Fix this.

blank!

Please, switch to Mercurial, darcs doesn't work!


From quozl at us.netrek.org  Tue May 30 00:19:36 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 30 May 2006 15:19:36 +1000
Subject: [netrek-dev] mypatch.dpatch darcs send -o yourfile.dpatch
In-Reply-To: <ecfa260c0605290457p3faafbcbi14534f31718296b5@mail.gmail.com>
References: <ecfa260c0605290428j32e424d4ld2c80707f57bd69c@mail.gmail.com>
	<20060529114610.GE887@us.netrek.org>
	<ecfa260c0605290457p3faafbcbi14534f31718296b5@mail.gmail.com>
Message-ID: <20060530051936.GB7069@us.netrek.org>

On Mon, May 29, 2006 at 11:57:44AM +0000, Zach wrote:
> Cool. I noticed I do not receive copies of my own posts to netrek-dev!

This is your choice.  Use the mailing list page to change it, the URL is
at the end of every post, or read the headers in the messages.

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


From netrek at gmail.com  Tue May 30 01:44:39 2006
From: netrek at gmail.com (Zach)
Date: Tue, 30 May 2006 06:44:39 +0000
Subject: [netrek-dev] mypatch.dpatch darcs send -o yourfile.dpatch
In-Reply-To: <20060530051936.GB7069@us.netrek.org>
References: <ecfa260c0605290428j32e424d4ld2c80707f57bd69c@mail.gmail.com>
	<20060529114610.GE887@us.netrek.org>
	<ecfa260c0605290457p3faafbcbi14534f31718296b5@mail.gmail.com>
	<20060530051936.GB7069@us.netrek.org>
Message-ID: <ecfa260c0605292344q767f9af2if42f7c114d2e9953@mail.gmail.com>

On 5/30/06, James Cameron <quozl at us.netrek.org> wrote:
>
> This is your choice.  Use the mailing list page to change it, the URL >is at the end of every post, or read the headers in the messages.

I already had it set to send me a copy of my own posts, but it's not
working. I confirmed this by checking the options here:
http://mailman.us.netrek.org/mailman/options/netrek-dev

" Receive your own posts to the list?" is marked "Yes."

Zach


From quozl at us.netrek.org  Tue May 30 01:49:48 2006
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 30 May 2006 16:49:48 +1000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <Pine.GSO.4.63.0605291438251.8380@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
	<Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
	<20060529110323.GD887@us.netrek.org>
	<Pine.GSO.4.63.0605291438251.8380@fcnep.argivfvba.arg.vy>
Message-ID: <20060530064948.GF7069@us.netrek.org>

On Mon, May 29, 2006 at 02:46:38PM +0300, Stas Pirogov wrote:
> Well, I'm attaching three patches actually to fix following:
> 
> * config.h.in comment in wrong place fix

Taken.

> * sys/socket addition to tools/players.c

Rejected.

I'd like this done by configure.in in config.h, so that we should only
need to #include "config.h" for this to be included.  You're welcome to
have a go at that, there are ample other functions that seem to do this.

> * swap aclocal and libtoolize to remove warning

Taken.

> Hope you can drag them couple more days, so I won't have to patch CHANGES 
> as well :)

I've added a patch to ChangeLog.  This concern should go at the end of
the month.

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


From xyzzy at speakeasy.org  Tue May 30 02:32:07 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Tue, 30 May 2006 00:32:07 -0700 (PDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <20060530064948.GF7069@us.netrek.org>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
	<Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
	<20060529110323.GD887@us.netrek.org>
	<Pine.GSO.4.63.0605291438251.8380@fcnep.argivfvba.arg.vy>
	<20060530064948.GF7069@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605300027580.31990@shell3.speakeasy.net>

On Tue, 30 May 2006, James Cameron wrote:
> > * sys/socket addition to tools/players.c
>
> Rejected.

Why shouldn't tools/players.c have sys/socket.h?  It calls a bunch of
socket functions that are defined there.



From keyos at keyos.org  Tue May 30 06:34:13 2006
From: keyos at keyos.org (Stas Pirogov)
Date: Tue, 30 May 2006 14:34:13 +0300 (IDT)
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <20060530064948.GF7069@us.netrek.org>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
	<Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
	<20060529110323.GD887@us.netrek.org>
	<Pine.GSO.4.63.0605291438251.8380@fcnep.argivfvba.arg.vy>
	<20060530064948.GF7069@us.netrek.org>
Message-ID: <Pine.GSO.4.63.0605301421540.9833@fcnep.argivfvba.arg.vy>

On Tue, 30 May 2006, James Cameron wrote:

> On Mon, May 29, 2006 at 02:46:38PM +0300, Stas Pirogov wrote:
> 
> > * sys/socket addition to tools/players.c
> 
> Rejected.
> 
> I'd like this done by configure.in in config.h, so that we should only
> need to #include "config.h" for this to be included.  You're welcome to
> have a go at that, there are ample other functions that seem to do this.
>

Well, I'd like to understand a little bit better what do you mean. Today
there are three types of use for config.h (at least that's what I can 
see):

1. if some condition is met #define VARIABLE ... (configure decision)
2. if some VARIABLE is defined - define INCLUDE_VARIABLE to be some 
   include file, otherwise define INCLUDE_VARIABLE to be NULLFILE (compile 
   time)
3. if some VARIABLE is defined - do something (define functions, include 
   files, etc.)

In order to use type 2 decisions there are #include INCLUDE_VARIABLE 
directives in code files, so if the variable is set you include something,
if not you include "null"

Type 3 requires only config.h be included (or defs.h that is included 
lots of times instead of config.h)

What kind of patch would you like to see ? To have type 2 variable defined
for <sys/socket.h> ? There are plenty of files that include <sys/socket.h>
directly these days. Why to begin replacing all that with some variable ?

Stas.

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


From quozl at us.netrek.org  Tue May 30 17:42:44 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 31 May 2006 08:42:44 +1000
Subject: [netrek-dev] build problem (mp.h)
In-Reply-To: <Pine.GSO.4.63.0605301421540.9833@fcnep.argivfvba.arg.vy>
References: <ecfa260c0605280735s68bfa9c4h478dcf92eee5bfaa@mail.gmail.com>
	<Pine.GSO.4.63.0605281923050.27171@fcnep.argivfvba.arg.vy>
	<20060529060235.GC8047@us.netrek.org>
	<Pine.GSO.4.63.0605291203200.27171@fcnep.argivfvba.arg.vy>
	<20060529093048.GA887@us.netrek.org>
	<Pine.GSO.4.63.0605291247210.8380@fcnep.argivfvba.arg.vy>
	<20060529110323.GD887@us.netrek.org>
	<Pine.GSO.4.63.0605291438251.8380@fcnep.argivfvba.arg.vy>
	<20060530064948.GF7069@us.netrek.org>
	<Pine.GSO.4.63.0605301421540.9833@fcnep.argivfvba.arg.vy>
Message-ID: <20060530224244.GA4454@us.netrek.org>

Sorry, Stas, I was wrong, Trent was right.  players.c should have an
include for sys/socket.h, and the only reason it's working at the moment
is that some other file is including sys/socket.h ... I was far too
energetic in my removal of includes.

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


From quozl at us.netrek.org  Tue May 30 17:45:43 2006
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 31 May 2006 08:45:43 +1000
Subject: [netrek-dev] DI & Rank
Message-ID: <20060530224543.GA6808@us.netrek.org>

Someone has proposed:

"... rank be available when stats are four grades below those required
(if not generally, then at least for Admiral).  As per the standard
description, if your stats are one below the cutoff, then 2x DI is
required to achieve the higher rank."

Opinions?

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


From netrek at gmail.com  Tue May 30 17:51:21 2006
From: netrek at gmail.com (Zach)
Date: Tue, 30 May 2006 18:51:21 -0400
Subject: [netrek-dev] DI & Rank
In-Reply-To: <20060530224543.GA6808@us.netrek.org>
References: <20060530224543.GA6808@us.netrek.org>
Message-ID: <ecfa260c0605301551i28a21aecy620b6d8adb9906b3@mail.gmail.com>

On 5/30/06, James Cameron <quozl at us.netrek.org> wrote:
> Someone has proposed:
>
> "... rank be available when stats are four grades below those required
> (if not generally, then at least for Admiral).  As per the standard
> description, if your stats are one below the cutoff, then 2x DI is
> required to achieve the higher rank."

There are many with many magnitudes the DI but due to stats never get
rank. Somne learn faster than others and while learning this was
reflected in relatively poor stats which can make achieving higher
level ranks near impossible. Perhaps we could allow promotion at 3xDI
with stats -2.5 and 4xDI with stats -2.0 and 5xDI with stats -1.5 so
it is not just based on a whole number factor.

Zach


From stephen.thorne at gmail.com  Tue May 30 18:07:23 2006
From: stephen.thorne at gmail.com (Stephen Thorne)
Date: Wed, 31 May 2006 09:07:23 +1000
Subject: [netrek-dev] More minor house-keeping on robotd
In-Reply-To: <Pine.LNX.4.58.0605292111150.28394@shell2.speakeasy.net>
References: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605292111150.28394@shell2.speakeasy.net>
Message-ID: <3e8ca5c80605301607n5cd519ffx3c68982ae855f49f@mail.gmail.com>

On 5/30/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> Please, switch to Mercurial, darcs doesn't work!

Yuck.

I'm going to spend some time investigating what's actually gone wrong
here. At the very least, I need a testcase I can pass over to the
darcs folks to put in their bugtracker.

In the mean time, can you attempt to pull accross the revision history
into a mecurial repo? tailor.py is a tool I used to go from CVS to
darcs, it may support mecurial.

-- 
Stephen Thorne

"Give me enough bandwidth and a place to sit and I will move the world."
  --Jonathan Lange


From jimmyhua73 at yahoo.com  Tue May 30 23:38:47 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Tue, 30 May 2006 21:38:47 -0700 (PDT)
Subject: [netrek-dev] DI & Rank
In-Reply-To: <20060530224543.GA6808@us.netrek.org>
Message-ID: <20060531043847.28632.qmail@web35308.mail.mud.yahoo.com>

--- James Cameron <quozl at us.netrek.org> wrote:
> "... rank be available when stats are four grades
> below those required
> (if not generally, then at least for Admiral).  As
> per the standard
> description, if your stats are one below the cutoff,
> then 2x DI is
> required to achieve the higher rank."
> 
> Opinions?

Okay, I'm not sure what the question is. 

So let me rephrase it. 

Your stats are 7 and so you need 640 DI to make
Admiral. This is Double DI

Your stats are 6 and so you need 1280 DI to make
Admiral. This is Quad DI

Your stats are 5 and so you need 2560 DI to make
Admiral. This is 8x DI. 

Your stats are 4 and so you need 5120 DI to make
Admiral. This is 16x DI.

Isn't Double DI and Quad DI already in the netrek
code? 

Now, when he says 4 grades below. I assume his stats
are 4. And he wants to make Admiral with 5120 DI? 

Ummm. NO. Even in my school, there is a time limit
before they WON'T let you graduate. I think it's 7
years. 

Jimmy


From xyzzy at speakeasy.org  Wed May 31 02:52:37 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 00:52:37 -0700 (PDT)
Subject: [netrek-dev] DI & Rank
In-Reply-To: <20060530224543.GA6808@us.netrek.org>
References: <20060530224543.GA6808@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605310048310.29418@shell2.speakeasy.net>

On Wed, 31 May 2006, James Cameron wrote:
> Someone has proposed:
>
> "... rank be available when stats are four grades below those required
> (if not generally, then at least for Admiral).  As per the standard
> description, if your stats are one below the cutoff, then 2x DI is
> required to achieve the higher rank."
>
> Opinions?

Can't you also rank with 4x DI and stats two below and 8x DI and three below?
16x DI for 4 below, that's a lot of hours!  320 DI * 16 = 5120 / 5 stats =
1024 hours.  I think Chewbaca has that many, I added a feature to Paradise
2000 because he had >1000 hours and made the player list columns not line up.


From xyzzy at speakeasy.org  Wed May 31 02:59:21 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 00:59:21 -0700 (PDT)
Subject: [netrek-dev] More minor house-keeping on robotd
In-Reply-To: <3e8ca5c80605301607n5cd519ffx3c68982ae855f49f@mail.gmail.com>
References: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
	<Pine.LNX.4.58.0605292111150.28394@shell2.speakeasy.net>
	<3e8ca5c80605301607n5cd519ffx3c68982ae855f49f@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0605310054280.17388@shell3.speakeasy.net>

On Wed, 31 May 2006, Stephen Thorne wrote:
> On 5/30/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
> > Please, switch to Mercurial, darcs doesn't work!
>
> Yuck.
>
> I'm going to spend some time investigating what's actually gone wrong
> here. At the very least, I need a testcase I can pass over to the
> darcs folks to put in their bugtracker.

Something is very messed up with darcs.  If you look at the actual gz patch
files in darcs for the UNDO robotd-fixes1, and my robot patches, everything is
there.  But if you run darcs diff to see the changes, they are missing!  Same
thing if you just look at the working version of the code, the changes aren't
there.


From jimmyhua73 at yahoo.com  Wed May 31 03:07:17 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 31 May 2006 01:07:17 -0700 (PDT)
Subject: [netrek-dev] More ideas for robotd
Message-ID: <20060531080717.85088.qmail@web35315.mail.mud.yahoo.com>

Well, 

I've been running a newbie game with virutally all
robots for the past 24+17 hours. 

settings are:
hm 0
hcr
ogh

No SIGSEV's so far, so the code is quite stable now. 

However, I think there's still room for improvement. 

1. I noticed that the robots are not correctly
tracking who carries and who does not. It seems there
is a change in server code. This flag is no longer
sent PFORBIT. The robots use these and
PFBEAMUP/PFBEAMDOWN to see who is carrying. The
minimum needed for the code to work right is PFORBIT -
I THINK.  

Anyways, we have 2 choices, make the bots smarter so
they don't need the player flags. Or change the robotd
code. Quozl, what's your preference?

2. Actually, since the bots don't know they all carry,
it's been great, as planet takes have been happening
left and right. Genocides have been happening every 4
hours or so. 

But in truth, the bots suck at taking, and once this
is fixed, their planet taking stats will take a nose
dive.  Geno's will rarely occur. I am thinking about
adding a toggle switch, for logic so that bots will
not mark other bot carriers for ogging. It will be
configurable, the way the other logic I added is
configurable... What do you think? Would this code
change be accepted into the repository?

3. Trent fixed the dodging of the robots by making the
server send over torp direction information to the
robots (and other clients). We can modify the robot
code so, it deduces the torp direction if the server
doesn't send it. Is this worth coding? 

4. Also, I am quite impressed with the robot's blind
dodging capabilities, that I think I would like to add
a toggle switch (dumbing down the bot), so it does
blind dodging as in before. (Make the bots easier to
fight against). 

5. Found a race condition, where if the robot wants to
refit, and his homeworld is taken over, he does some
weird stuff on the homeworld until he blows up on his
own planet. After he comes back in, it's all good as
he comes back in as the ship he wanted to come in
as.... This should be fixed. 

6. Got a server load spike up to 0.50 occassionally
(usually around 0.01) now that the dodge code is
fixed! But they dodge really well now. I don't even
torp anymore.  I phasor those guys to death. Work on
optimizing the code or wait for faster computer? This
is on an Athlon Xp1800.

Jimmy
 




From netrek at gmail.com  Wed May 31 09:01:00 2006
From: netrek at gmail.com (Zach)
Date: Wed, 31 May 2006 14:01:00 +0000
Subject: [netrek-dev] DI & Ran
In-Reply-To: <20060531043847.28632.qmail@web35308.mail.mud.yahoo.com>
References: <20060530224543.GA6808@us.netrek.org>
	<20060531043847.28632.qmail@web35308.mail.mud.yahoo.com>
Message-ID: <ecfa260c0605310701o21f92b1bg4faff5832d52e55b@mail.gmail.com>

On 5/31/06, Jimmy Huang <jimmyhua73 at yahoo.com> wrote:
> Okay, I'm not sure what the question is.
>
> So let me rephrase it.
>
> Your stats are 7 and so you need 640 DI to make
> Admiral. This is Double DI
>
> Your stats are 6 and so you need 1280 DI to make
> Admiral. This is Quad DI
>
> Your stats are 5 and so you need 2560 DI to make
> Admiral. This is 8x DI.

8x seems to be the limit. Fisher tested 16x stats last night and no
promotion to Admiral.

Zach


From netrek at gmail.com  Wed May 31 09:02:39 2006
From: netrek at gmail.com (Zach)
Date: Wed, 31 May 2006 14:02:39 +0000
Subject: [netrek-dev] DI & Rank
In-Reply-To: <Pine.LNX.4.58.0605310048310.29418@shell2.speakeasy.net>
References: <20060530224543.GA6808@us.netrek.org>
	<Pine.LNX.4.58.0605310048310.29418@shell2.speakeasy.net>
Message-ID: <ecfa260c0605310702r7249e188l18494d163099fe59@mail.gmail.com>

On 5/31/06, Trent Piepho <xyzzy at speakeasy.org> wrote:
>
> Can't you also rank with 4x DI and stats two below and 8x DI and three below?
> 16x DI for 4 below, that's a lot of hours!  320 DI * 16 = 5120 / 5 stats =
> 1024 hours.  I think Chewbaca has that many, I added a feature to Paradise
> 2000 because he had >1000 hours and made the player list columns not line >up.

Fisher has over 5,000 DI on continuum.

Zach


From jimmyhua73 at yahoo.com  Wed May 31 09:43:23 2006
From: jimmyhua73 at yahoo.com (Jimmy Huang)
Date: Wed, 31 May 2006 07:43:23 -0700 (PDT)
Subject: [netrek-dev] DI & Rank
In-Reply-To: <ecfa260c0605310702r7249e188l18494d163099fe59@mail.gmail.com>
Message-ID: <20060531144323.59225.qmail@web35307.mail.mud.yahoo.com>

--- Zach <netrek at gmail.com> wrote:
> > Can't you also rank with 4x DI and stats two below
> and 8x DI and three below?
> > 16x DI for 4 below, that's a lot of hours!  320 DI
> * 16 = 5120 / 5 stats =
> > 1024 hours.  I think Chewbaca has that many, I
> added a feature to Paradise
> > 2000 because he had >1000 hours and made the
> player list columns not line >up.
> 
> Fisher has over 5,000 DI on continuum.

Hi, 

I think whomever is asking for this change should just
be promoted to Admiral when he requests it of the
server god. And the server god should look at it from
a case to case basis. 

I don't think the server should automatically do this.
You don't automatically promote the janitor of a
company to CEO just because he's worked there longer
than everyone else. 

8x DI should be the limit, that's just my opinion at
least. 

Jimmy


From williamb at its.caltech.edu  Wed May 31 13:45:44 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 31 May 2006 11:45:44 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
Message-ID: <Pine.GSO.4.58.0605311142050.25167@clyde>

I've run into a problem with this patch.  For observers, p_status is not
being sent correctly.  Before patch, they always get status sent as
PALIVE.  With patch, status changes to PEXPLODE upon locking onto a
ship who is in combat, and it never changes back.  I noticed this
when trying to look at observer tractors..they weren't displaying, and it
was because observer thought he was dead (p_status == PEXPLODE) so they
weren't drawing.
Bill


From xyzzy at speakeasy.org  Wed May 31 17:30:37 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 15:30:37 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.GSO.4.58.0605311142050.25167@clyde>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
Message-ID: <Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>

On Wed, 31 May 2006, William Balcerski wrote:

> I've run into a problem with this patch.  For observers, p_status is not
> being sent correctly.  Before patch, they always get status sent as
> PALIVE.  With patch, status changes to PEXPLODE upon locking onto a
> ship who is in combat, and it never changes back.  I noticed this
> when trying to look at observer tractors..they weren't displaying, and it
> was because observer thought he was dead (p_status == PEXPLODE) so they
> weren't drawing.
> Bill

I'm not sure what exactly you are saying here.  Is it the status of the
observer's ship, or of the ship the observer is observing?  Or the observer's
idea of the status of other observers?

Say I have an observer 'g', who is watching player '1', and there is another
observer 'h' and another player '2'.

Which client has the wrong status, and which player does it have the wrong
status for?

g's client thinks g is PEXPLODE?
g's client thinks 1 is PEXPLODE?
1's client thinks g is PEXPLODE?
g's client thinks h is PEXPLODE?


From xyzzy at speakeasy.org  Wed May 31 18:23:58 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 16:23:58 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
	<Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
Message-ID: <Pine.LNX.4.58.0605311622290.23915@shell2.speakeasy.net>

On Wed, 31 May 2006, Trent Piepho wrote:
> On Wed, 31 May 2006, William Balcerski wrote:
> > I've run into a problem with this patch.  For observers, p_status is not
> > being sent correctly.  Before patch, they always get status sent as
> > PALIVE.  With patch, status changes to PEXPLODE upon locking onto a
>
> I'm not sure what exactly you are saying here.  Is it the status of the
> observer's ship, or of the ship the observer is observing?  Or the observer's
> idea of the status of other observers?

I think I know what's wrong now.  This patch should fix it.

 The code to handle SP2 status/flags sampling didn't understand status of
 POBSERV.  Fix it to treat someone in POBSERV state as if they are PALIVE,
 which is what the client (which also doesn't know about POSERV) gets
 told.
>


From xyzzy at speakeasy.org  Wed May 31 18:24:37 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 16:24:37 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.LNX.4.58.0605311622290.23915@shell2.speakeasy.net>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
	<Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
	<Pine.LNX.4.58.0605311622290.23915@shell2.speakeasy.net>
Message-ID: <Pine.LNX.4.58.0605311624180.23915@shell2.speakeasy.net>

For real this time

On Wed, 31 May 2006, Trent Piepho wrote:
> I think I know what's wrong now.  This patch should fix it.
>
>  The code to handle SP2 status/flags sampling didn't understand status of
>  POBSERV.  Fix it to treat someone in POBSERV state as if they are PALIVE,
>  which is what the client (which also doesn't know about POSERV) gets
>  told.
> >
>
-------------- next part --------------

New patches:

[observer SP2 status fix
Trent Piepho <xyzzy at speakeasy.org>**20060531225305
 The code to handle SP2 status/flags sampling didn't understand status of
 POBSERV.  Fix it to treat someone in POBSERV state as if they are PALIVE,
 which is what the client (which also doesn't know about POSERV) gets
 told.
] 
<
> {
hunk ./Vanilla/ntserv/genspkt.c 1190
 	    if (pl->p_status != POBSERV || pl == me) {
 #endif
 		switch(pl->p_status){
+#ifdef OBSERVERS
+		case POBSERV:
+#endif
 		case PALIVE: /* huh, we must work */
 		    highest_active_player = i;
 		    if(pl->p_flags & PFCLOAK){
}

Context:

[experimental rework for wait queue dumping changelog
quozl at us.netrek.org**20060527090326] 
[experimental rework for wait queue dumping
quozl at us.netrek.org**20060527090226
 
 	* ntserv/openmem.c: experimental rework to support wait queue
 	dumping, and multiple server instances in separate shared memory
 	segments.  Provide interface so findslot will be able to detach
 	from an active game segment and create and attach to a new game
 	segment.  Accept NETREK_PKEY environment variable.
 
] 
[experiment slot number change command changelog
quozl at us.netrek.org**20060527071222] 
[experiment slot number change command
quozl at us.netrek.org**20060527071121
 
 	* ntserv/ntscmds.c (do_become): add experimental and not yet
 	functioning code to support change of slot number for a player.
 	Requires client-side support and further work.
 
] 
[robotd-toggle-newlogic-news.dpatch
jimmyhua73 at yahoo.com**20060527025530] 
[robotd-toggle-newlogic
jimmyhua73 at yahoo.com**20060527024334
 
 On request, the new logic that the robotd uses can be turned on and off
 via a commandfile or command sequence. Currently defaulted to off. 
 
 hcr -> assume humans carry
 ogh -> ogg carriers while I am bombing
 
 	* INSTALL.Newbie updated INSTALL.Newbie to document newer switches.
 	Need to include all possible robot switches in the future. 
 
 	* robotd/data.c added initialization of global variables hm_cr and 
 	ogg_happy
 
 	* robotd/data.h added global variables hm_cr and ogg_happy
 
 	* robotd/decide.c added check for ogg_happy mode before 
 	check_ogg while bombing
 
 	* robotd/dmessage.c added hcr and ogh message decoding. 
 
 	* robotd/update_players.c moved conservative assumptions that
 	humans carry into a new function called army_check3. 
 
 	* robotd/update_players.c added logic so army_check3 only 
 	executes if (hm_cr) global variable is active. 
 
 
 
] 
[resolve conflicts with newbie-configurable-robots-changelog.dpatch
Stephen Thorne <stephen at thorne.id.au>**20060526081423] 
[newbie-configurable-robots.dpatch
jimmyhua73 at yahoo.com**20060526063547
 
 	* INSTALL.Newbie updated documentation to show how to configure
 	the robots to be dumber
 
 	* robotd/data.c changed default updates=2.0 instead of 1.0, decreases
 	CPU load by 50% and fights about the same. 
 
 	* robotd/dmessage.c allow decoding of local messages and commandfile
 	messages even if robot is in INL mode. In INL mode, robots will 
 	ignore other players and GOD's commands. 
 
 	* robots/newbie.c checkpos() returns 1, to avoid compiler warning
 
 	* robots/newbie.c added a bunch of comments on what each option
 	does, when Merlin forks a robot. 
 
 	* robots/newbie.c modified the command so robots now read a command
 	file on startup. 
 
] 
[newbie-configurable-robots-changelog.dpatch
jimmyhua73 at yahoo.com**20060526064353] 
[ping pong plasma bot changelog
quozl at us.netrek.org**20060525050440] 
[deprecate dan quayle in t-mode messages changelog
quozl at us.netrek.org**20060525041559] 
[deprecate dan quayle in t-mode messages
quozl at us.netrek.org**20060525041344
 
 	* include/defs.h (WARMONGER): add customisation setting for
 	configuration of local warmonger, so that we are not caught by
 	change again so easily.
 
 	* ntserv/daemonII.c (political_begin): deprecate Dan Quayle in
 	favour of George Bush, subject to mailing list discussion.  Patch
 	by: William Balcerski with rework by James Cameron.
 
] 
[rewrite build test script changelog
quozl at us.netrek.org**20060525013820] 
[rewrite build test script
quozl at us.netrek.org**20060525013317
 
 	* autogen.sh: add res-rsa to autoconf re-run,
 
 	* tests/build: test for correct directory, use darcs get instead
 	of put, use autogen.sh instead of running autotools here, add the
 	install target.
 
 	"darcs put" is slow, the darcs manual recommends "darcs get" instead,
 	which is certainly faster.  But "darcs get" must have the exact path to
 	a repo, not like "darcs put".  So a test is added to check that we are
 	in the right directory first.
 
] 
[Player position sign fix
williamb at its.caltech.edu*-20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[help bot deal with ping-pong plasma
Trent Piepho <xyzzy at speakeasy.org>**20060525030034
 The robot has code to deal with Ping-Pong plasma, but it's an old
 version.  It doesn't work properly with the current ping pong plasmas,
 written by Trent Piepho in 1995 (so the old ones are really old!). 
 Basically, the bots needs to allow for plasma fired by a friendly player
 becoming hostile to it.
       
 Also sets the pl_team member of the plasma struct, which makes getting
 the plasma's team easier.
] 
[help client with plasma war in ping-pong mode
Trent Piepho <xyzzy at speakeasy.org>**20060525025806
 In Ping-Pong plasma mode, a plasma changes teams when it is bounced. 
 There is no way to send this change to the client, so the client doesn't
 know.  For example, if a player at peace with us but who we are at war
 with bounces our (or a teammate's) plasma back at us, it appears to the
 client that the plasma is friendly.  But really, it's not, since we are
 at war with the plasma's new team.  Fix this by setting the plasma's war
 flag if the player is hostile to the plasma's team.
  
 In order to take advantage of this, clients will need to be sure to:
 1. Not assume that the player's own plasma is friendly.
 2. Not assume that plasma from the player's team is friendly.
 3. Make sure the check the plasma's war flags, and not the flags of the
 player who fired it.
 
] 
[robotd omnibus 2 changelog
quozl at us.netrek.org**20060525003615
 Addition of ChangeLog and NEWS entries to cover Trent Piepho's rework 
 of Jimmy Huang's changes to robotd.
] 
[fix ranlib for solaris changelog
Stas Pirogov <keyos at keyos.org>**20060524235806] 
[fix ranlib for solaris
Stas Pirogov <keyos at keyos.org>**20060524235510
 
 	* configure.in: test for ranlib was failing on Solaris. This is
 	probably caused by different /bin/sh interpreters.  This fix should
 	satisfy all of them.
 
] 
[remove res-rsa/configure
Trent Piepho <xyzzy at speakeasy.org>**20060525015328
 This is a generated file and shouldn't be kept in the repository.
] 
[torp dir for robot
Trent Piepho <xyzzy at speakeasy.org>**20060524082754
 Hadley's bot expects to get torp direction from the server, but the
 server only sends it for your own torps.  Changed to send it for other
 players' torps too.  Without it, the bot thinks all torps are going
 straight up, making it a very bad dodger (unless you attack from below). 
   
 This should be fixed to only turn this on for the robot, so as not to
 help borgs.  This will have to wait on a better way to detect robots.
] 
[fix calls to req_cloak_off()
Trent Piepho <xyzzy at speakeasy.org>**20060524082708
 Some calls to req_cloak_off() were missing the function's argument,
 the reason string.
] 
[fix res danger
Trent Piepho <xyzzy at speakeasy.org>**20060524082437
 The check for res danger would make the robot cloak when near _any_ home
 planet, so it would cloak even when bombing it's own core.  Unfortunately,
 it is not possible to tell from the planet flags whose home world a
 planet is.  Changed the code to only check the normal home planet
 indexes, skipping the bots's own HW, for proximity.  This makes the code
 much smaller and faster.  Realistically, the HWs are always at the
 standard indexes, even with non-standard planet layouts.  Included a bit
 of code, #if'ed out, that will find home worlds by name, the way the bot
 does when it wants to refit.
] 
[fix use of un-initialized variable
Trent Piepho <xyzzy at speakeasy.org>**20060524082353
 Fix a warning about a un-initialized use of pldist in update_players(). 
 It didn't matter, but fix the warning anyway.
] 
[fix crash in RCD generation
Trent Piepho <xyzzy at speakeasy.org>**20060524082241
 The code to generate the RCD message didn't handle the case when there
 were no visible friendly and/or enemy ships.  In this case,
 _state.closest_{e,f} would be NULL.  Do what clients do in this case, and
 use me->p_no when no suitable other player is known.
] 
[fix closest_planet
Trent Piepho <xyzzy at speakeasy.org>**20060524082149
 closest_planet() would usually return NULL every other time it was
 called.  For speed, it would check the previous closest planet first,
 then look for a _closer_ planet.  If it didn't find one, it returned
 NULL, rather than the previous (and current) closest planet (which
 it now returns).  
] 
[fix neutral planet check
Trent Piepho <xyzzy at speakeasy.org>**20060524082029
 Fix several bugs with check_take().  It didn't handle the case when no
 enemy planets were left.  It looked at the last enemy planet in the list,
 rather than the target enemy planet when deciding if it should take neut
 planets.  It would skip looking for neuts when it found an enemy agri and
 _didn't_ have enough armies to take it.
] 
[adapt when assaulting
Trent Piepho <xyzzy at speakeasy.org>**20060524081723
 The assault planet code didn't re-check the target planet after the
 assault started.  If the planet was taken by another player on a friendly
 team, or modified by god, the robot would still try to bomb/take it, even
 when that action was no longer possible.  The robot will now check for
 planets is can not drop on, and abort the assault if so.  It will not try
 to bomb planets it can not bomb.  It will also stop reinforcing planets
 when they get to 4 armies.
] 
[fix mfprintf()
Trent Piepho <xyzzy at speakeasy.org>**20060524081613
 When mfprintf() was changed from varargs to stdarg, it wasn't done
 correctly.  Fix this.
] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com*-20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[robotd mfprintf regression fix
quozl at us.netrek.org*-20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com*-20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[PROJECTS update
williamb at its.caltech.edu**20060524093948
 Removed twarp observer bug from PROJECTS list, as this has been fixed.
] 
[Player position sign fix
williamb at its.caltech.edu**20060524080901
 * genspkt.c: With short packets on, positions in the negative (i.e. on player
 death) were being reported incorrectly. 
] 
[conflict resolution 2006-08-24-a
quozl at us.netrek.org**20060524042919] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522213300
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[fix SP_2 flag sending for real changelog
quozl at us.netrek.org**20060524024253] 
[fix SP_2 flag sending for real
Trent Piepho <xyzzy at speakeasy.org>**20060524002833
 The sndFlags function will not send flags of observers (except for
 PFOBSERV of course).  The SP_2 flag sampling code will sample the flags
 of robots now.  It wll not sample observers' flags, except for an
 observer's own flags.  The SP_2 sampling code will update the last sent
 flags data, so shield/cloak are not sent again via sndFlags().  When
 sndFlags() does send flags, it will sent the correct shield/cloak and not
 zero.
] 
[remove generated autotools files
quozl at us.netrek.org**20060524015023
 aclocal.m4 and configure are generated files, they are generated using
 autogen.sh from configure.in, and as such they do not deserve to be in the
 repository and are costing us time and energy as they change.
] 
[misc bugs update
quozl at us.netrek.org**20060524014925] 
[deprecate README.darcs execution in favour of autogen.sh changelog
quozl at us.netrek.org**20060524011944] 
[deprecate README.darcs execution in favour of autogen.sh
quozl at us.netrek.org**20060524011759
 
 	* autogen.sh: add GNU standard autotools configuration sequence,
 	deprecating execution of README.darcs.  Manual build process then
 	becomes "sh autogen.sh" followed by the usual configure, make, and
 	make install.
 
] 
[newbie-fixes.dpatch changelog conflict resolution
quozl at us.netrek.org**20060524005953] 
[newbie-fixes.dpatch
jimmyhua73 at yahoo.com**20060523153223
 
  Bug fixes:
 
   1. Merlin gets moved on genocide. Now Merlin moves himself back.
   2. You can get Merlin into a race condition by timing your join and
   joining something other than what Merlin chooses for the warring teams.
   This is fixed (I think). I was never able to time this right!!!
   James please check again!
 
  Known Bug:
 
  1. t-mode criteria is hardcoded into Merlin as 4 players a side.
 
  ChangeLog here:
 
      * robots/newbie.c changed some tabbing for better indent and bracing
      consistency.
 
      * robots/newbie.c added #defines POSITIONX and POSITIONY so there's
      only one place the change the desired x and y position of Merlin
 
      * robots/newbie.c added checkpos() function which checks for changes
      in Merlin's position. Replaces him back into POSITIONX and POSITIONY
      once it finds that Merlin has stopped moving for 15 seconds.
 
      * robots/newbie.c corrected misspellings of various comments
 
      * robots/newbie.c modified num_players() function to return
      the correct *next_team based on t-mode settings also
 
] 
[robotd_udcounter.dpatch
jimmyhua73 at yahoo.com**20060523143934
 
 I re-did the setflag() function, so it now will always report back
 a positive incrementing int at 100ms intervals. And it starts with 0
 on program start. 
 
 There are some other places that initialize _udcounter, I think this
 might need to be got rid of, but I didn't do that in this patch. 
 
 Read the longwinded diatribe in the Changelog. 
 
] 
[newbie-install-docs-update.dpatch
jimmyhua73 at yahoo.com**20060523155757
 
 Updated the installation document for newbie
 
] 
[robotd mfprintf regression fix changelog
quozl at us.netrek.org**20060524004957] 
[robotd mfprintf regression fix
quozl at us.netrek.org**20060524004752
 
 	* robotd/util.c (mfprintf): fix a regression caused by conversion
 	  to stdargs done on Fri Oct 31 09:15:42 2003.
 
] 
[revised coding style and darcs discipline
quozl at us.netrek.org**20060523050927
 Rewrite of the coding style and patch acceptance criteria based on 
 feedback on the mailing list from Stephen Thorne and Trent Piepho.
] 
[Declare_war fix
williamb at its.caltech.edu**20060522012930
         * proto.h, warnings.h, enter.c, interface.c, socket.c, rmove.c: 
           added boolean to declare_war function to indicate whether to
           add delay and send delay message.  Fixes the case of unwanted 
           war delay message when switching teams, and also prevents robots
           from entering a state of permanent declare war delay.
] 
[fix lack of shields shown on practice robots and iggies changelog
quozl at us.netrek.org**20060523040534] 
[fix lack of shields shown on practice robots and iggies
quozl at us.netrek.org**20060523040421
 	* ntserv/genspkt.c (sndFlags): for practice robots, terminators,
 	and hunter-killer, in conjunction with short packets version two,
 	shields were not being sent.  Changed to send shields in SP_FLAGS.
 	See also "S_P2 new flag sampling" in updateShips().  Reported by
 	William Balcerski.
] 
[robotd-indent-fix.dpatch
jimmyhua73 at yahoo.com**20060523010939
 
 fixed indentation to follow existing code. 
 
 The following files were changed:
 
 decide.c, main.c, shmem.c, socket.c, update_players.c, util.c
 
 
] 
[resrsa-gmp-autoconf.darcs
Trent Piepho <xyzzy at speakeasy.org>**20060522210616
 
 The test for gmp in the res-rsa autoconf file failed for gmp version
 3.  In gmp3, functions are #define'd to different names in gmp.h, for
 example mpz_init() becomes __gmpz_init().  Since the autoconf test
 doesn't include gmp.h, it didn't find the new names.  The fix, copied
 from http://www.kaffe.org/pipermail/kaffe/2000-November/090303.html,
 is to just do a new test with the gmp3 names if the first test fails. 
] 
[remove glib-config from Makefile.in
Trent Piepho <xyzzy at speakeasy.org>**20060522212353
 The Makefile includes calls to glib-config, which aren't necessary to
 build the server, and fail if glib-config doesn't exist.  If someone
 wants to enable the (disabled) database timing functionality that uses
 glib, they can just add the options when they run configure.
] 
[revise build test after libtoolize adoption
quozl at us.netrek.org**20060522061037
 Stephen Thorne's addition of libtool to the configuration requires a
 change to the build test sequence, to run libtoolize and aclocal.
 Also it is no longer necessary to make configure executable, as autoconf
 does that for us.
] 
[setteam usage fix
quozl at us.netrek.org**20060522022327
 	* tools/setteam.c: fix error in usage propogated from setplanet,
 	and remove unnecessary include.
] 
[Observ mask fix
williamb at its.caltech.edu**20060522014159
         * socket.c, redraw.c: removal of lockup for observers under
           declare war/transwarp/refit situations.  Reverses previous
           patch by restoring PFWAR and PFREFITTING mask to observers.
] 
[resolve conflicts with changelog
Stephen Thorne <stephen at thorne.id.au>**20060522011533] 
[transcription of ChangeLog data for Jimmy's patch
Stephen Thorne <stephen at thorne.id.au>**20060522005345] 
[robotd-fixes1.dpatch
jimmyhua73 at yahoo.com**20060521152116
 
 changelog entry here. 
 
     * robotd/assault.c added extra check not to bomb your own armies. 
     Bots will try to bomb own armies when 2 carriers drop on same planet.
     And planet ends up with >4 armies. 
 
     * robotd/decide.c changed some tabbing
 
     * robotd/decide.c corrected logic in check_take function. Robotd now
     takes neutral planets. Before it had a tendency to ignore neutral 
     planets. Also used to crash out when no more enemy planets. Both are
     fixed with this. 
 
     * robotd/main.c, shmem.c, socket.c, update_players.c
     removed mfprintf function. replaced with fprintf function until such
     time that mfprintf function is fixed so it doesn't crash. Bandaid. 
 
     * robotd/update_players.c changed some tabbing, added some missing
     braces.
 
     * robotd/update_players.c changed closest_planet() function to 
     return the current closest planet instead of NULL when it cannot
     find a closer planet. 
 
     * robotd/util.c added comments to reflect that mfprintf causes
     crashes for as yet unknown reasons. 
 
 
 
] 
[fix two second delay on client connection if daemon not running changelog
quozl at us.netrek.org**20060521123415] 
[add game pause/resume/terminate tool, setgame changelog
quozl at us.netrek.org**20060521115308] 
[add max duplicate ip count for pickup play changelog
quozl at us.netrek.org**20060519080824] 
[add install-ntserv target for live updates changelog
quozl at us.netrek.org**20060519061157] 
[mute banned observers changelog
quozl at us.netrek.org**20060519042833] 
[fix changelog conflict from att patch
Stephen Thorne <stephen at thorne.id.au>**20060519024319] 
[Transwarp war errormsg
williamb at its.caltech.edu**20060519021844] 
[ATT fixes
williamb at its.caltech.edu**20060518081658] 
[resolve ChangeLog conflict again
Stephen Thorne <stephen at thorne.id.au>**20060518095505] 
[resolve ChangeLog conflict - this is getting annoying
Stephen Thorne <stephen at thorne.id.au>**20060518095316] 
[adding aclocal.m4
Stephen Thorne <stephen at thorne.id.au>**20060518020621] 
[fix two second delay on client connection if daemon not running
quozl at us.netrek.org**20060521123246
 
 	Remove the two second delay experienced by clients that connect to
 	a server on which the daemon is not running.  Also fix a cause of
 	initial connection failing, which happens if the daemon does not
 	start up within the hoped-for interval.
 
 	Solution is implemented using the SIGUSR1 signal, but only during
 	the initialisation window between when ntserv forks the daemon and
 	the daemon completes initialisation.  The signal is not used at
 	other times.
 	
 	* ntserv/daemonII.c (main): send a SIGUSR1 to parent process
 	(ntserv) once initialisation of shared memory is completed and
 	regular SIGALRMs are about to commence.
 
 	* ntserv/openmem.c (openmem): remove two second delay that was
 	used to hope for daemon to initialise.
 	
 	* ntserv/openmem.c (startdaemon): add a wait for SIGUSR1.
 
] 
[add game pause/resume/terminate tool, setgame
quozl at us.netrek.org**20060521115034
 
 	* tools/setgame.c: add script utility for pausing, resuming, and
 	terminating the game.
 
 	* tools/Makefile.in: add setgame target.
 
 	* ntserv/input.c (input): send bad version packet to terminate
 	client as soon as a GU_GAMEOK termination is requested.
 
 	* ntserv/daemonII.c (udplayers): terminate daemon as soon as
 	possible if a GU_GAMEOK termination is requested.  Change nplayers
 	to nfree, to better explain what the variable is.
 
 	* include/struct.h (game_ok): remove unused macro.
 
] 
[add max duplicate ip count for pickup play
quozl at us.netrek.org**20060519075351
 Adds a new etc/sysdef option DUPLICATES which is the maximum number of
 pickup player slots allowed from the same IP address before the next
 connection is given the Q32 response.
 
 This is a denial of service filtering feature.
 
 The default is 3.  Set this above 16 to make it ineffective.
 
 Set this to less than half of the number of players per side, otherwise
 abusers may not be ejected or banned by majority vote because a majority
 would be impossible.
 
 Does not affect robots, unless they join via the pickup queue ... which
 would be a misconfiguration.  Robots normally join via a special queue.
] 
[add install-ntserv target for live updates
quozl at us.netrek.org**20060519060623
 Addition of a target install-ntserv to the ntserv Makefile so that a
 server operator can do a live update of ntserv during a running game.
 
 The target moves the existing in-use ntserv binary into an archive
 tree before installing the new ntserv binary.  This makes it possible
 to manually back out of an installation if the new binary breaks
 badly.
 
 Other methods to test a new ntserv binary include running it manually
 for connection back to the client.  See ntserv command line options.
] 
[mute banned observers
quozl at us.netrek.org**20060519042723
 Banned observers are allowed in and can speak, which was a surprise, but the
 code has always allowed this since observers were added.  Change to prevent
 banned observers from talking.  Simplify ban logic further.
] 
[patch acceptance policy regarding patch name and comment
quozl at us.netrek.org**20060519015208
 Define a new policy of not changing ChangeLog and NEWS until release.
] 
[add setteam utility source
quozl at us.netrek.org**20060518061257
 The actual source now, so that builds complete.
] 
[add setteam utility
quozl at us.netrek.org**20060518055920
 Add a utility for viewing and changing the starbase reconstruction timer
 and surrender timer, both of which are in struct teams.  Although these
 timers can be manipulated by other means, setteam makes it easier to 
 script.
 
 Some common code now exists in setplanet.c and setteam.c that deserves
 factorisation.
] 
[resolve conflict
Stephen Thorne <stephen at thorne.id.au>**20060518034143] 
[improve the autoconf system to use AC_PROG_LIBTOOL and @RANLIB@ correctly.
Stephen Thorne <stephen at thorne.id.au>**20060518014309
 	* tests/build: Set the configure and mktrekon files executable, just in
 	case.
 
 	* configure.in: Add AC_PROG_LIBTOOL macro.
 
 	* ntserv/Makefile.in: Use the @RANLIB@ and @RANLIB_FLAGS@ macros.
] 
[fix the OSX build by passing the -c flag to ranlib.
Stephen Thorne <stephen at thorne.id.au>**20060517111623] 
[Fix style of some code patched by Jimmy, as per Trent's code review
Stephen Thorne <stephen at thorne.id.au>**20060517030403] 
[move wdt reset from SIGALRM handler to input handler
quozl at us.netrek.org**20060518024416
 Slots may jam in POUTFIT after KWINNER if the user terminates
 the client ungracefully ... such that the TCP connection is gone but
 the ntserv lives on.
 
 During this time, daemon synchronisation still sends SIGALRM to the
 ntserv, and ntserv's SIGALRM handler still resets the p_ghostbust
 timer.
 
 Prototype solution is to move p_ghostbust watchdog timer reset from
 within the SIGALRM handler to the section of main loop that is
 executed when input arrives from the client.
 
 Monitoring the p_ghostbust timer with gdb shows it is now reset for a
 dormant client on receipt of ping responses.
] 
[updateplayers.dpatch
jimmyhua73 at yahoo.com**20060516075315
 
 Treats humans and bots differently. 
 
 Humans with a high planet rating > 4 are assumed to carry once they
 have a kill. 
 
 Humans alive longer than 5 minutes with 1 kill are also assumed to carry. 
 If you have 2 kills, the time they assume you carry drops to 2.5 minutes...
 
 Uses the OggV packet and "robot!" login to ID the robots. Needed to change
 server source code and newbie.c source to help support this. All
 those changes are already there if you have the newbiebetter.dpatch.
 
 Jimmy
 
] 
[newbie better 2 changelog fix
quozl at us.netrek.org**20060516070248
 Applying the principles of the Software Release Practice HOWTO
 http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/
] 
[newbiebetter.dpatch
jimmyhua73 at yahoo.com**20060516071923
 
 newbie now will generate t-mode games randomly any team against
 any other. Also, won't start diagonal games. 
 
 newbie starts up bots with -g option so server knows about the bots. 
 
 genspkt.c also modified so server tells clients which clients
 are newbie bots. 
 
 Merlin still nukes bots based on "robot!" login. So, if you want
 to pretend to be a bot, you may get nuked.  Robots will ID each
 other based both on "robot!" login and also OggV packet. 
 
 If you are the only player on a server and have a "robot!" login...
 The newbie game ends...
 
 
] 
[changelog for Compilation fix for gcc4.0
quozl at us.netrek.org**20060516040416] 
[Compilation fix for gcc4.0
williamb at its.caltech.edu**20060516015945
 Fix for jimmy's code with gcc4.0, compiler doesn't like variables declared in this way, so
 moved the int declare to top of the function.
 This patch contains the following changes:
 
 M ./Vanilla/robotd/assault.c -1 +1
] 
[enable CONTINUOUS_MOUSE by default
quozl at us.netrek.org**20060515223159
 Upgrade of Continuum to 2.11.0 revealed a regression caused by not
 adopting the features file from the previous server.
] 
[post-release notes for 2.11.0
quozl at us.netrek.org**20060515100328
 Changed the notes regarding the release process, to assist self or others
 for next release.
] 
[TAG 2.11.0
quozl at us.netrek.org**20060515091704] 
Patch bundle hash:
3eb48f672a95fc289d1190642aacefa9cf8aba79

From williamb at its.caltech.edu  Wed May 31 18:36:35 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 31 May 2006 16:36:35 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
	<Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605311630360.5409@clyde>

> I'm not sure what exactly you are saying here.  Is it the status of the
> observer's ship, or of the ship the observer is observing?  Or the observer's
> idea of the status of other observers?
>
> Say I have an observer 'g', who is watching player '1', and there is another
> observer 'h' and another player '2'.
>
> Which client has the wrong status, and which player does it have the wrong
> status for?
>
> g's client thinks g is PEXPLODE?
> g's client thinks 1 is PEXPLODE?
> 1's client thinks g is PEXPLODE?
> g's client thinks h is PEXPLODE?
>
Ok without patch, observer thinks his own status is PALIVE, and other
players are PALIVE, except when they are blowing up, then they are
PEXPLODE.

With patch, observer initially thinks his own status is PALIVE, but
then it switches to PEXPLODE and stays that way.  Other players are
PALIVE, except when they are blowing up, then they are PEXPLODE.
The event that triggers switch from PALIVE to PEXPLODE is sending in the
practice robot.

Bill


From williamb at its.caltech.edu  Wed May 31 18:45:52 2006
From: williamb at its.caltech.edu (William Balcerski)
Date: Wed, 31 May 2006 16:45:52 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.LNX.4.58.0605311622290.23915@shell2.speakeasy.net>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
	<Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
	<Pine.LNX.4.58.0605311622290.23915@shell2.speakeasy.net>
Message-ID: <Pine.GSO.4.58.0605311645290.5804@clyde>

This patch fixes the problem thanks.
Bill

On Wed, 31 May 2006, Trent Piepho wrote:

> On Wed, 31 May 2006, Trent Piepho wrote:
> > On Wed, 31 May 2006, William Balcerski wrote:
> > > I've run into a problem with this patch.  For observers, p_status is not
> > > being sent correctly.  Before patch, they always get status sent as
> > > PALIVE.  With patch, status changes to PEXPLODE upon locking onto a
> >
> > I'm not sure what exactly you are saying here.  Is it the status of the
> > observer's ship, or of the ship the observer is observing?  Or the observer's
> > idea of the status of other observers?
>
> I think I know what's wrong now.  This patch should fix it.
>
>  The code to handle SP2 status/flags sampling didn't understand status of
>  POBSERV.  Fix it to treat someone in POBSERV state as if they are PALIVE,
>  which is what the client (which also doesn't know about POSERV) gets
>  told.
> >
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>
>


From xyzzy at speakeasy.org  Wed May 31 18:59:59 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 16:59:59 -0700 (PDT)
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.GSO.4.58.0605311630360.5409@clyde>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
	<Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
	<Pine.GSO.4.58.0605311630360.5409@clyde>
Message-ID: <Pine.LNX.4.58.0605311653030.23915@shell2.speakeasy.net>

On Wed, 31 May 2006, William Balcerski wrote:
> The event that triggers switch from PALIVE to PEXPLODE is sending in the
> practice robot.

Strangely, that makes sense.  When you said, entering combat, that didn't make
sense.  The robot does, because it is a non-observer player above slot 15.
The SP2 flag code sends players 0-15 in one chunk, and only if necessary,
sends 16-31 in another chunk.  It was ignoring obserers and not sending
anything at all about players 16-31 until the bot came in, then it sent the
info for those players but did POBSERV -> PDEAD/PEXPLODE instead of POBSERV ->
PALIVE.


From quozl at us.netrek.org  Wed May 31 21:22:54 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 1 Jun 2006 12:22:54 +1000
Subject: [netrek-dev] Real fix for SP2 flags
In-Reply-To: <Pine.LNX.4.58.0605311624180.23915@shell2.speakeasy.net>
References: <Pine.GSO.4.58.0605311142050.25167@clyde>
	<Pine.LNX.4.58.0605311519560.3780@shell2.speakeasy.net>
	<Pine.LNX.4.58.0605311622290.23915@shell2.speakeasy.net>
	<Pine.LNX.4.58.0605311624180.23915@shell2.speakeasy.net>
Message-ID: <20060601022254.GB4620@us.netrek.org>

On Wed, May 31, 2006 at 04:24:37PM -0700, Trent Piepho wrote:
> observer SP2 status fix

Taken.

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


From quozl at us.netrek.org  Wed May 31 21:24:59 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 1 Jun 2006 12:24:59 +1000
Subject: [netrek-dev] More minor house-keeping on robotd
In-Reply-To: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
References: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
Message-ID: <20060601022459.GC4620@us.netrek.org>

Taken.

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


From xyzzy at speakeasy.org  Wed May 31 22:11:08 2006
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed, 31 May 2006 20:11:08 -0700 (PDT)
Subject: [netrek-dev] More minor house-keeping on robotd
In-Reply-To: <20060601022459.GC4620@us.netrek.org>
References: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
	<20060601022459.GC4620@us.netrek.org>
Message-ID: <Pine.LNX.4.58.0605312010210.15502@shell2.speakeasy.net>

On Thu, 1 Jun 2006, James Cameron wrote:

> Taken.

How is that going to work?  These changes are ALREADY in darcs patches, but some
bug in darcs is making it skip them.  Is it going to ignore this patch too?


From quozl at us.netrek.org  Wed May 31 23:05:13 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 1 Jun 2006 14:05:13 +1000
Subject: [netrek-dev] netrek-server-vanilla-2.11.1 released
Message-ID: <20060601040513.GA18476@us.netrek.org>

netrek-server-vanilla 2.11.1 was released today, with some more
significant changes.

http://quozl.linux.org.au/netrek/
cdd1f3765b4d420a1d5992cbf650b889  netrek-server-vanilla-2.11.1.tar.gz

Summary of changes: (from NEWS)
- fix CHAOS torp detonation which was allowing wtemp [Balcerski}
- add experimental future support for slot number change [Cameron]
- added toggle switches to new ogging and carrier tracking logic [Huang]
- remove res-rsa/configure [Piepho]
- help bot deal with ping-pong plasma [Piepho]
- help client with plasma war in ping-pong mode [Piepho]
- deprecate dan quayle in t-mode messages [Balcerski]
- server sends torp direction, robots dodge better [Piepho]
- make robots cloak near enemy home planets due res danger [Piepho]
- make robots take neut planets once there are no enemy planets [Piepho]
- make robots recognise planet situational change while assaulting [Piepho]
- various robot fixes that triggered comprehensive work by others [Huang]
- fix lack of shields shown on practice robots and iggies [Cameron]
- fix two second delay on client connection if daemon not running [Cameron]
- add game pause/resume/terminate tool, setgame [Cameron]
- add max duplicate ip count for pickup play [Cameron]
- add install-ntserv target for live updates [Cameron]
- mute banned observers [Cameron]
- add team configuration tool, setteam [Cameron]
- prevent hung slots by changing ghostbust timer reset method [Cameron]
- newbie random games against any non-diagonal team combination [Huang]
- enable CONTINUOUS_MOUSE by default [Cameron]

--
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/20060601/d780d284/attachment.pgp 

From quozl at us.netrek.org  Wed May 31 23:18:41 2006
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 1 Jun 2006 14:18:41 +1000
Subject: [netrek-dev] More minor house-keeping on robotd
In-Reply-To: <Pine.LNX.4.58.0605312010210.15502@shell2.speakeasy.net>
References: <20060530011238.56221.qmail@web35303.mail.mud.yahoo.com>
	<20060601022459.GC4620@us.netrek.org>
	<Pine.LNX.4.58.0605312010210.15502@shell2.speakeasy.net>
Message-ID: <20060601041841.GA18766@us.netrek.org>

On Wed, May 31, 2006 at 08:11:08PM -0700, Trent Piepho wrote:
> How is that going to work?  These changes are ALREADY in darcs
> patches, but some bug in darcs is making it skip them.  Is it going to
> ignore this patch too?

Don't know.  Check the .tar.gz release just now against your repository,
in case we've missed anything else.

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


From bogus@does.not.exist.com  Fri May 26 14:39:30 2006
From: bogus@does.not.exist.com ()
Date: Fri, 26 May 2006 19:39:30 -0000
Subject: No subject
Message-ID: <mailman.118.1150856357.12168.netrek-dev@us.netrek.org>

sent in updateSelf.  As for the packet order, I am pretty sure that
sndPStatus (which is called from updateShips) is sent before sndSelf
(which is called from updateSelf), as I could monitor client-side that
your status is changed 1 update before your whydead is updated.  However,
I cannot find the exact line(s) of code where this order is determined.
It might be in the fatten packet part of the UDP code.  I know the packets
are ordered by type via packets.h, but then the flushsockbuf function
starts stuffing packets in that fit, so I really am lost as to packet
order.

I do know that in the sndSelf function, when whydead changes, it is sent
high priority by TCP rather than UDP.  And I tested this patch to see that
indeed, whydead is sent for observers on geno.
>
> 1.  if the code is meant to do the same thing, add a new static
> function, such as sp_s_you_criticality() or something, and call that
> function from both places that do this same thing ... this is called
> factoring,
>
Yes it is meant to do the same thing, I can factorize it, however there is
one line I am not sure of.  In the updateSelf function, the way it
determines whether to use sndSelf or sndSSelf is by the following:

if(send_short &&  me->p_fuel < 61000  ) { /* A little margin ... */

I am not sure why it looks at fuel, whereas for other places in the code
it just checks send_short.

> It might also be time to make 0x40 and 0x80 more formally declared.
> Interesting that it causes server packets to be restricted to 0-63 type
> codes, wasting bits in the type char.  Perhaps some day we should change
> sendClientPacket to remove this prioritisation overload.
>
Regarding the semicritical packets (0x40), I can't figure out how the
sendSC function works either :).  Specifically, what line checks to send
the packet only if sequence number is 0x40?