Note: This would be better suited for the netrek-dev
(netrek-dev at mailing list.  I am setting that list as the
To: address for this reply and adding netrek-forever as a Cc: on this
reply and leaving the original message, except for my in-line comments,
intact.  Please send follow-ups to netrek-dev; thanks.

On Fri, Oct 22, 2010 at 12:56:06PM -0700, bipolartribble wrote:
> OK, I downloaded and built the 2.17 vanilla server code and got it
> working in the standard Bronco pre-t configuration by setting PRET=1
> in the sysdef file.  This gives me the standard 4 robots (or players)
> per side and a small number of planets required for a win (default is
> 3 I believe), configurable in the sysdef file.
> However, I ran into some problems trying to build it to work like a
> sturgeon server, or at least like the one on the metaserver.  That one
> has 8 robots per side, and you have to take all the planets to win.
> First issue I hit is that even though there's a STURGEON variable in
> sysdef, that's not enough, you have to run ./configure with
> CFLAGS=-DSTURGEON and rebuild everything to enable it.

	That's not the correct way of doing it, and the various
	bits of the server documentation should explain the proper way,
	which is modification of include/config.h after "configure" is
	initially run.

	One of my on-going projects, time permitting, is to get rid of
	the legacy nonsense in include/config.h that conditionally
	compiles in support for the additional game modes depending on 
	#define settings; all game modes should be able to be selected
	by a server admin by simple modifications to etc/sysdef with no
	need for re-compiles.  This work is, obviously, not finished at
	this point.  One must ensure that the settings in
	include/config.h are valid according to the liberal comments in
	that file _and_ the writeups in docs/CUSTOMIZATION first and
	then select the specific functionality in etc/sysdef.

	Yes, it's a mess.  And at some point when I [or anyone else that
	would care to do the work, hint hint :)] has time the mess will
	get straightened out.

> After doing that, I got the basic functionality--I can upgrade and
> send myself 'u' to get my upgrades.  However, there are two problems:
> * I can't take the home planet of the enemy.  It says it's not allowed
> in pre-t mode and there's no sysdef option to toggle this.  This holds
> even if I set PRET_PLANETS=10 (all the planets).
	Correct; pre-t does not permit dropping on homeworlds because of
	abuse.  We have people that idle on the server during pre-t and
	unless they are peaced with whatever the opposing team is anyone
	that drops and takes homeworlds will end up killing the idlers.
	People were doing this intentionally and a patch was added by
	Karthik or myself to prevent this activity.  I suppose this
	behavior can be made a sysdef-controlled feature if it's felt to
	be warranted.

> * I can't get 8 robots (or players) per side; I changed
> MIN_NEWBIE_SLOTS, MAX_NEWBIE_PLAYERS, and anything else I could find
> in the sysdef file that looked promising.

	Not surprising.  Can't get more than 4 bots per side in pre-t,
	either, and nothing ends up being logged in var/ERRORS as to
	why.  Might have something to do with DUPLICATES but I seem to
	recall testing against that at one point and it ended up not
	being the cause; however I have no notes of that testing and my
	memory is a little fuzzy.  I do recall patching a test server
	instance and making the number of bots admin-configurable a
	couple years back and running into the behavior you describe for
	pre-t mode.

> Is PRET=1 mutually exclusive from newbie mode?  I did try setting
> PRET=0 and NEWBIE=1, but then NO robots got created at all.
	All the modes are mutually exclusive; in fact you run the risk
	of creating a humanity killing blackhole inside our solar system
	if you try to run the server with more than any single mode
	enabled at any given time.

> One other strange observation.  When I run the server in bronco mode,
> if I attach the client netrek using, then NO robots get
> created, but if I use the actual (routable) IP address for the local
> host, then it works.  Looks like a bug where it's not realizing the
> local loopback IP is valid.  (Note that it *connects* to the server
> when I use, so it finds it, it just doesn't create any
> robots.)
	In bronco mode there are no bots except the practice bots that
	are spawned when one hits * or whatever you have that mapped to
	when no other humans are present.

	In the bot modes there is a sysdef setting, ROBOTHOST, that is
	supposed to control which IP bots join on.  This is necessary
	for multi-homed servers or servers that host more than a single
	instance of the server.

When I was the most junior Democrat in the Senate, I voted for John Paul
Stevens.  He was a Republican nominated by a Republican president who was
going to be up for election, and we voted for him, and proudly.

-- Senator Patrick J. Leahy, now chairman of the Judiciary Committee, on his
respect for the associate justice who is retiring, New York Times, 10 April 2010
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :