
** MAIN README FILE FOR SERVER **

README of 24-Jul-1996

If you have any comments or improvements you would like to offer then please
email them to vanilla-l@anthrax.ecst.csuchico.edu which is the distribution
list for the server development team.  See the end of this document for how
to send your changes back.


NOTE!!! If you need to get RSA working then you will have to get the 
res-rsa.tar.Z.crypt file.  This contains the RSA specific code.  It has to be
encrypted because of US government legality over cryptography getting exported
outside the US.  If you are from outside the US then there is a PGP equivalent.
To get the crypt key please email vanilla-l@anthrax.ecst.csuchico.edu or
mcp@cs.umd.edu and say that you are a US or Canadian citizen and you will get
the key.

Do you really need to obtain and install the RSA component?  Perhaps not.

If you are setting up a Netrek Server behind a firewall, such that nobody on
the rest of the Internet will be able to play on the server, you do not need
to bother with RSA client authentication.  The Netrek Server will work fine
without it.

RSA is only really required on the Internet, where you cannot track down and
annoy people who try to create robot programs.  With the formalised network
management of large companies, there is much cheaper protection.

You don't need the crypt key for the RSA package if you are setting up a Netrek
server within your organisation that will not be used by players outside your
organisation.






Instructions for Building and Setting up the Server (24-Jul-1996)

	Edit the file Server/config.h.in to meet your requirements.  You may
choose to leave this as is for a pure Vanilla default server.

	To setup the server to your machine's architecture run the configure
program.  This is a script that will check your system for system dependent
differences and configure the server to deal with these.  It will also prompt
you for the directory into which the server is to be installed.

	Configure will make two files for the server to deal with the 
differences.  These are config.h and system.mk.  After these are made you may
want to check the files to see if the defines are what you like.  Most people
don't need to do this.

	After you have done this then go to the source root directory and do a
make depend. This will setup your makefiles to rebuild an object if any include
files it uses change.

	Now you're ready to make the server. Just type make in the source root
directory.

	If everything is made ok then type 'make install' to move the files to
LIBDIR.

	If everything is compiled and in the right locations then start by
setting up all the files correctly. Here are the files and what they do:
	.sysdef 	- This has a lot of tunable parameters
	.time		- This has the playable/clue hours in it
	.banned		- A list of players that are banned from server
	.clue-bypass	- A list of players that don't have to go through
			  clue checking
	.conquer	- A file the server modifies that has the server's
			  stats in it
	.features	- A list of special features allowed at the server
			  that some clients might have. Some of these
			  features may be considered 'borgish'.
	.global		- A file the server modifies that has the server's
                          stats in it
	.motd		- This is the information about the server for the
			  players.
	.motd_clue	- Another motd for clue playing hours.
	.planets	- Current planet layout
	.players	- player database
	.reserved	- RSA public/global key listing for verification

	Some of these files have a tunables that will allow you to change the
server to your choosing. These files are; .sysdef, .time, .banned, .clue-bypass,
.features, .motd, .motd_clue. The other files should not be modified by you. 
These are made by the server or through front-end utilities.
			
	If the install worked then go to the LIBDIR. There are two programs that
should be running all the time. They are:

	1. newstartd - This waits around for a connection from a client. It then
		forks and execs an ntserv.  This also accepts connections from
		the metaserver and via telnet for the current player list.

	2. update - This wakes up once a day and gets a new key list from the
		metaserver port 3530. It then makes a new .reserved through
		rsa_keycomp and reconstructs your .motd file.  [Note that this
		program need not run if you are behind a firewall].

	Start these two programs.  Once they are running then try connecting to
the server and check things out.  If there is a problem then check out the
DEBUG.HELP file for possible solutions.

README of July 30, 1992:

Hello (again).  This is the final release of the Bronco Netrek Server.
As before, the CHANGES files list all modifications made since the previous
release.  The only new information is that my e-mail address will be
<terence@janet.ucla.edu> after August, 1992.  Should be good for a couple
years.

"Exciting" new features:

* Netrek hockey.  This is an external robot that works with no server mods.
* Mergescores tool.  For combining the player databases of two servers, or
  perhaps for combining the databases of INL tourneys, and other special 
  games etc.
* UDP client source.  Not the greatest, but the known bugs are fixed,
  and the better X citizen patch has been applied.  Also has Hugh
  Moore's independent team bitmaps.

Notes for new server admins:  timecheck.c has hardcoded server hours.
These need to be updated for your server.  Read the comments at the
beginning of newstartd.c before using newstartd.  The top level
directory structure should contain ntserv, tools, and startup.
lockout() and isCensured() perform login lock out and message
censure by user id.

Notes for current bronco-based server admins: This release should be
easy to merge in -- the diffs should not be significant.  Note that
ntserv/Makefile and tools/Makefile have changed.

Terence Chang
<terence@ece.cmu.edu>

README of Feb 20, 1992:

Hello.  You are looking at the source tree for the bronco.ece.cmu.edu Netrek
server archived on Feb 20, 1992.  These sources are based on the Netrek
sources which resided at scam.berkeley.edu on Feb 7, 1991.  All
modifications to these sources were made by Terence Chang
<terence@ece.cmu.edu>.  These modifications are marked by /* TMC */ and are
documented by the CHANGES files in each subdirectory.

The original README files were written by Kevin Smith and Scott Silvey.  If
you are looking for documentation on setting up a server, I suggest you look
for hints archived at sites listed on the alt.games.xtrek FAQ.

Also, there is no source for a client here.  If you need the client sources,
I recommend using the client source archived at scam.berkeley.edu or
alternative sources at other archive sites.

Looking at copyright.h and copyright2.h, I feel obligated to say something
about copyrights myself, but being kind of ignorant about such matters I am
placing my modifications in the public domain.  I would appreciate a one line
acknowledgement in the of any server that uses part or all of my sources.

Terence Chang
<terence@ece.cmu.edu>


README of Sep 12, 1990:

netrek - A distributed TCP/IP based xtrek with tons of features.

    Original xtrek written by Chris Guthrie and Ed James.
    This version written by Kevin Smith and Scott Silvey.

Note:  Don't try to call "sequent.Berkeley.EDU" with this code.  It will
  fail for reasons described in "Security:".

    Overview:

netrek is a socket based xtrek written for BSD Unix 4.3.  To run it on a 
SYS V machine, you will have to deal with the standard incompatibility 
problems like bcopy(), srandom(), <string.h>, etc..

This release supports X10 and X11.  Details of this in the netrek directory.

The overall scheme is that the user has a binary which understands his
graphics needs.  It calls up the netrek server which (through inetd) starts
up a process which talks to the client (details in startup/ and ntserv/).
Then the user plays the game.

    Security:

There is a slight problem with security for this game.  If you install this
program on your local system, and use the code exactly as presented here,
there is nothing to prevent someone from making a binary which has some 
built in robot-like features (automatically phaser anyone within a certain
range, automatically fire lots of torps into any close enemies, etc.).  The
TCP/IP protocol is designed to minimize the amount of cheating anyone
can actually do, but a computer's ability to phaser and aim the torpedo
cannon is better than a humans (in general).  

On the other hand, this paradigm does present a really nice robot language.  
You could perhaps have a contest to see who can design the best unassisted
robot.  And since the client is written in C, you wouldn't have to learn
a new language to write a robot (and there is a nice layer - socket.c - 
between the local data structures, and the TCP/IP information sent back
and forth).

To provide some security for the binaries which your users may use, the
file reserved.c was written.  It is identical in both ntserv/ and netrek/.
It is a binary verification module which makes sure that the client
can perform some deterministic encryption of 16 random bits of data.
Change this algorithm, and then only your binaries will work with your 
server (other binaries will fail the security test, and be kicked out 
of the game!).

    Features:

Above and beyond the underlying design of this game, new features include:

- Multiple ship types including starbases.
- Plasma torpedoes - 'f' (must get 2 kills and refit to use).
- Tons of options in terms of display setup (multiple message windows,
    varies bitmaps for the planets, etc...)  Pop up an options window
    and try some of them out - 'O'.
- Players saved.  You now log into the game before playing.  Pick a name
    and a password.  Some number of options are saved with the player 
    (like his keymap), and lots of stats are kept about him.  If he plays
    well enough, he might be promoted to an Admiral!  (Note: for any
    stats capable of promoting s player to accumulate, the game must 
    be in 'tournament' mode - 2 teams of 5 players each.  
    P.S. DI stands for 'Destruction Inflicted')

There a ton of features beyond these, including tractor and pressor 
beams, robots which insult you, a configuration file to personalize the 
game, and lots of neat stuff.  Try it out!


Providing Patches (24-Jul-1996)

If you want to make it even easier for your changes to be adopted by the server
maintenance team, provide them as context diffs.  The easiest way to do this is
to use the primary Makefile's "patches" target to make a set of patches.  Unpack
the original distribution some place else, then configure it, then build the
patches.  For example, assuming you are in the Server directory of your modified
version of the server;

	% setenv SOURCE `pwd`
	% setenv PATCHDIR /tmp
	% cd $PATCHDIR
	% tar xf Serverx.yplz.tar
	% configure
	% cd $SOURCE
	% make patches

