Note: This would be better suited for the netrek-dev (netrek-dev at us.netrek.org) 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 127.0.0.1, 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 127.0.0.1, 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. John -- 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 : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20101022/4585177d/attachment.pgp