This file describes the mechanism for restricting which players may enter
games on the Judge.  Restrictions may be set for all games, or for
individual games.  Games may be restricted to a limited set of players
(the .ALLOW list), or opened to all players except those specifically
excluded (the .DENY list).

These lists may be manipulated using the following commands:

	SET ALLOW PLAYER [-]address
	SET DENY PLAYER [-]address
	SET ALLOW MASTER [-]address
	SET DENY MASTER [-]address

where the master of a game can add or remove players from the .ALLOW and
.DENY files for their particular games.  In addition, the JK can use these
commands to add and remove players (or masters) to the Judge .ALLOW and .DENY
lists remotely, by signing on to the CONTROL game, and issuing these commands.
By including the '-' prepender, the listed player will be removed from that
file.

For example, let's say I am Mastering a game DUMMY, and I want to make sure
that Joe@Blow.com can't sign on to the game, I would issue the command:

SIGNON mdummy password
SET DENY PLAYER joe@blow.com

or, let's say I wanted to prevent joe from getting on my judge altogether,
I'd issue the command:

SIGNON mcontrol password
SET DENY PLAYER joe@blow.com

[obviously, if I'm operating locally, it's simpler just to edit the file,
 but you see what I mean.]

The mechanism relies upon the following four files.  The players.* files may
appear in the Judge's directory or in an individual game's directory (or
both); the masters.* files may only appear in the Judge's directory:

players.ALLOW - a list of all players that will be allowed to be players on
                the judge (or game).
players.DENY  - a list of all players that are barred from playing on this
                judge (or game).
masters.ALLOW - a list of all players that are allowed to act as masters on
                this judge.
masters.DENY  - a list of all players that are barred from acting as masters
                on this judge.

When a player signs on to the judge (or onto a game), the judge will:

1) Look for a file players.ALLOW in the judge's directory.  If it finds
   it, it will look for this player's name.  If it finds it, it will allow
   the player to continue.  If it doesn't find the player's name, it will not
   allow the player to continue.

2) If there is not a players.ALLOW file, it will look for a players.DENY
   file.  If it finds that, it will look in that file for this player.  If it
   finds the name, it will not allow the player to continue.  If it doesn't
   find the player, it will allow the player to continue.

The Judge follows the same process when a user attempts to sign on to a game,
except that the players.DENY and players.ALLOW files will be looked for in
the D<gamename> directory.

Similarly, when a player attempts to CREATE a game, the judge will follow the
same algorithm, looking for masters.ALLOW and masters.DENY files in the
judges directory.

There are several VERY important things to remember take note of:

1) I would recommend using the players.ALLOW file in the main directory
sparingly.  If you only list 5 players in this file, those are the ONLY 5
players that can sign on to the judge.  This is much more useful for the
games file, as this can be used for setting up invitation-only games.  You
create the game, and set up the seven players you want to have in the game,
and those are the only ones that will be allowed in, including Observers.

2) Whenever a change is made to any of the files using the judge, the judge
will save the previous version of the file as <file>.bak.  Currently, only
one player per command can be added.

3) The format of the files is:
=<player address>
the '=' is required.

4) If you already have the blacklist file (dip.blist), you will need to copy
it to players.DENY.

Larry Richardson  1/95