The Diplomacy Judge User's Manual

Copyright © 2003, 2004 by Russell M. Blau. The content of this Manual is licensed under a Creative Commons License.

Cover page image adapted from William R. Shepherd, "Europe at the Present Time", The Historical Atlas, 1911.

The njudge software described in this manual was originally authored by Ken Lowe, and is owned by David C. Kovar. Redistribution and use in source and binary forms are permitted provided that it is for non-profit purposes, that this and the above notices are preserved and that due credit is given to Mr. Lowe.

Diplomacy™ is a trademark of Avalon Hill, a division of Hasbro, Inc.

Table of Contents

1.   Introduction

1.1.  About the Judge

1.2.  About this Manual

1.2.1.  How Information Is Presented In This Manual

1.2.2.  Terminology

1.3.  Where to Find Further Information

1.4.  Translations

2.   Introduction to the Judge

2.1.  Quick Start for New Users

2.2.  Communicating with the Judge

2.3.  What Do I Do If the Judge is Down

2.4.  Date Formats

3.   User Registration and Administrative Commands

3.1.  The Single Most Important Judge Command

3.2.  User Help Commands

3.3.  Player Information and Registration Commands

3.4.  Game Information Commands

4.   Creating, Observing and Joining Games

5.   Deadlines and Dedication (or, Get Your Orders in on Time

5.1.  The Deadline System

5.2.  Dedication Systems

6.   Entering Orders

6.1.  Move, Retreat, and Adjustment Orders for the Current Phase

6.2.  Convoy Routes Must Be Specified

6.3.  Submitting Orders for Future Phases

7.   Other Player Commands

7.1.  General Commands

7.2.  Deadline-Related Commands

7.3.  Draw/Concession Commands

7.4.  Press Commands

8.   Creating and Mastering Standard Games

8.1.  Changing Moderation Status

8.2.  Master-only Commands

8.3.  Standard Game Moderation Commands

8.4.  Game Access Settings

8.5.  Press Settings

8.6.  Deadline-Related Settings

9.   Configuring Variant Games

9.1.  General Variant Settings

9.2.  Machiavelli Settings

10. Alphabetical Index of Commands

1.     Introduction

1.1.    About the Judge

This is a guide to using the Diplomacy™ Adjudicator, better known as the Judge, an automated program for the on-line play of the strategy game Diplomacy™, published by Hasbro, and many of its variants.

This manual only covers Judges using the "njudge" software, distributed from the Njudge Project (see section 1.3). These are not the only computer adjudicator programs in existence; you can get information about others from the sources listed below. You can also play Diplomacy on-line through human adjudicators, or by postal mail, or even (believe it or not!) face-to-face.

Diplomacy played via e-mail has existed for almost as long as e-mail has been available to the private consumer. There are several groups, such as the AOL Diplomacy group, the well-regarded CompuServe Diplomacy group, and the Cat23 group that have organized to run games over the web not using the Judge system. But it is the Judge system that defines a good portion of the Internet hobby, and has probably influenced more of its development than anything else. (There is also a system called the "DPJudge", which has a WWW interface and uses different software than the Ken Lowe judges, although it is an outgrowth of the email Judge system. This manual does not cover the DPJudge.)

The initial Judge code was written by Ken Lowe in the late 1980s as a project to test his understanding of the C programming language. The code has since been and continues to be improved upon by the hard work of several different programmers. Ken Lowe also set up and acted as judgekeeper for the first Judge, USWA. USWA carried the hobby for several years assisted by one or two other Judges, until it folded, causing concern that the Judge hobby would die with it. Fortunately, though, other hobbyists came through and set up Judges. At this writing, there are over a dozen public judges in operation world-wide, including several for non-English-speaking players.

Each Judge is operated independently by a volunteer administrator, known as the Judgekeeper, and is identified by a four-letter code (such as "USWA" in the previous paragraph). At the moment, each Judge is a completely autonomous system. Users must register with each Judge separately, and communicate with each Judge separately. In particular, different Judges may be running different versions of the njudge software, so commands that work on one Judge will not necessarily work on all others. Where possible, this manual will indicate the software version in which each command was introduced.

Finally, using the Judge requires some knowledge of the rules of Diplomacy. The Diplomacy rules themselves are copyrighted by Hasbro, and are available (at this writing) at http://www.hasbro.com/common/instruct/Diplomacy.PDF. However, this manual does not cover either the rules or the strategy of Diplomacy.

1.2.    About this Manual

This document is called the User's Manual because it is designed for users, not for system administrators. This manual is intended as a useful reference for anyone who masters, plays in, or observes games on a Judge. However, new users may find it easier to start with the introductory Guide to the Judge, available by sending the command "GET guide" in a message to the Judge.

The purpose of this manual is to list all the commands that users may send to the Judge, provide examples of proper and improper usage of the commands, and explain what kinds of errors may occur and how to fix them. It is not a guide to how to play the game of Diplomacy. Section 1.3 lists many useful resources for players on strategy, tactics, variants, and other game-related information.

1.2.1.   How Information Is Presented In This Manual

The following chapters of this manual include examples of commands to the Judge. To make the examples clearer, they will always be displayed in a distinctive style. Commands to send to the Judge will appear like this:

GET filename

Words shown in ALL CAPS, like "GET" in the example above, are keywords that should be typed exactly as they appear. Words shown in lower case, like "filename" in the example, are placeholders that you replace with specific information (in this example, the name of a file you want the Judge to send you). The use of upper and lower case in these examples is only for the purpose of distinguishing between keywords and non-keywords; the actual commands can be typed in either upper- or lower-case (with one exception; see section 5.1).

Also, the Judge generally ignores spacing between keywords, so, for instance, "SET NOWAIT" works just as well as "SET NO WAIT" or even "SETNOWAIT". (But inserting spaces inside a keyword, like "SET NOW AIT", will cause an error!) This was not always true on versions before 1.4.0, so if a multi-word command that looks right, like "I AM ALSO", causes a mysterious error message, try the same command without spaces (IAMALSO) and see if it works that way.

Items in square brackets are optional. Words separated by vertical bars (|) indicate a choice of one of the words. Again, these symbols are only shown to explain the proper syntax. Users do not type in the square brackets or vertical bars!

Most command options are self-explanatory. "name" means the name of a game, which must be no more than 8 alphanumeric characters. "email" means a valid email address. "power" means the name (not just the first letter) of one of the powers in the game, which depends on the variant being played. The letter "p" will be used where the initial of a power is required.

Caution: whenever any setting is described in this manual as the "default," that means only that it is set that way in the software as provided from http://www.njudge.org/ – however, any Judgekeeper can change the default for games created on his system, and Masters can change those defaults for individual games. When in doubt, check the game listing (see LIST, section 3.4) to see what settings are actually in effect.

A number in braces {like this} in the right-hand margin after the command definition indicates the first Judge version number in which the command appeared. If this number is absent, then the command is believed to be available in all currently used Judge versions (although this has not been verified). [Note: some commands marked as version {0.8.9} may actually have been introduced in versions 0.8.8 or 0.8.7, but this makes no real difference since no public Judge is running either of those two versions at this time.] There are also a few Judges running customized software not based on the njudge code; these Judges are unlikely to accept the commands shown with a version number in this Manual. To find which Judges are running which versions of the software, see http://gem.win.co.nz/judge/judgevers.html.

Examples that illustrate an entire email communication with the Judge will be shown as illustrated below, but will not follow the upper- and lower-case convention discussed above:

Finally, examples of responses from the Judge will be shown as in the following illustration (most mail headers have been omitted in the interest of clarity):

1.2.2.     Terminology

Here are a few commonly-used terms that you should be familiar with:

Judge

The Diplomacy adjudicator computer program.

Judgekeeper (also "JK" or "administrator")

A human being who administers the Judge software.

Master (also "Gamemaster" or "GM")

A human being, not necessarily the same person as the Judgekeeper, who is in charge of a particular game being played on the Judge.

Moderator

In a "moderated" game, this means the same thing as Master. But, in an unmoderated game, any player can act as a Moderator and do many (but not all) of the things a Master can do. See sections 8.1 and 8.2 below.

Observer

A person who is not playing in a game, but who receives the game reports and, in some cases, may be able to communicate with the players through the Judge.

Player

A person who is participating in a game being run on the Judge.

Power

One of the positions (7 in a standard game) played in a game being run on the Judge. Please note that "power" identifies the position being played, while "player" identifies the individual playing that position.

1.3.   Where to Find Further Information

The most complete source of information about the online Diplomacy hobby is the Diplomatic Pouch website, at http://www.diplom.org/. Click on "Online Resources" for a comprehensive index of documents and links to other sites covering all aspects of the hobby.

The rules of Diplomacy are available (at this writing) from Hasbro at http://www.hasbro.com/common/instruct/Diplomacy.PDF.

A list of Judges that are open to the public, their e-mail addresses, their Judgekeepers, and their available games, can be found at http://www.diplom.org/openings/openings.html. The Diplomacy Pouch also maintains a Game Queue system at http://www.diplom.org/DP-cgi/setqueue, where you can sign up for a new game.

For Judge players, Alain Tésio's Diplomacy Tools at http://www.floc.net/ are indispensable. This site allows you to retrieve a map of the current position of any game on any public Judge; game history and list information; and stored maps of previous moves. You can also set up a customized page that keeps track of all your games, including deadlines (converted into your local time zone), maps, results, and even a link to send mail to the Judge. Many tasks can be performed more quickly and easily using these tools than by using Judge commands!

For more information about the njudge software itself, to report bugs, or to participate in development, see the Njudge Project webpage, http://www.njudge.org.

To find which Judges are running which versions of the software, see http://gem.win.co.nz/judge/judgevers.html.

Finally, the most current version of this manual should be available at http://members.cox.net/russblau/.

1.4.   Translations

At this time, we are not aware of any translations of this Manual into other languages. If any translations are provided, we will list them here in future editions.

2.     Introduction to the Judge

2.1.   Quick Start for New Users

If you have never used the Judge before, don't worry – you don't have to read this entire Manual before you start playing. However, there are some basics you need to understand. This Manual is designed more as a reference than as a tutorial; you might find it easier to start with a page designed for new players. Check the links at http://www.diplom.org/Online/judge.html. But, if you insist on reading ahead, here are the suggested key sections:

• Read sections 1.1, 2.2, 2.3, and 3.1 so that you understand what the Judge is, what it does, and what it doesn't do.
• Read section 1.3 and take a look at the various resources listed there. Especially, check out the Judge Openings List and the Game Queue page, if you want to find a game that you can join quickly.
• Read about the REGISTER command in section 3.3. Then, when you are ready to play, you can register on the Judge that is hosting your game.
• Read about the SIGN ON command in section 4. You will need to use this to join a game.
• If you are joining a new game, rather than taking over a replacement position, then you will probably want to use the SET PREFERENCE command in section 7.1.
• Read section 5.1 so that you understand how deadlines are set, and why it is important to pay attention to them.
• If you have played Diplomacy face-to-face or in other settings, you probably already know how to write your orders, but you might want to review section 6.1 to see what formats the Judge will accept. You should definitely read section 6.2, too, because sooner or later you are going to be involved in a convoy order.
• Finally, skim through section 7 to see other commands that you might need to use during a game. The most important ones to understand are SET WAIT, SET ABSENCE, and the PRESS commands in section 7.4. Don't worry about "color options" and "fake options" at this point; just read the basics about how to send a press message to one or more other players, including the "delivery options" section.

The Judge itself provides a more extensive guide for new users. Send an e-mail message to your favorite Judge (running version 1.4.0 or higher) containing the line "GET GUIDE" in the body.

2.2.   Communicating with the Judge

The Judge is an e-mail based system. All communications to and from the Judge are sent by e-mail. There is no direct WWW access to a Judge, although Judge information can be retrieved and viewed through several WWW sites. In order to use a Judge, therefore, you must have e-mail access and you must obtain the e-mail address of a Judge (see section 1.3).

It is highly recommended that you use a mail program or system that allows you to send plain-text messages (also known as ASCII or Unformatted Text in some software), as the Judge cannot process any messages that contain HTML tags, MIME encoding, or other non-text commands. However, most problems with formatted mail can be avoided by religious use of the SIGN OFF command (see section 3.1).

If the Judge is functioning correctly, it should send a reply to every e-mail message sent to it. The reply is ordinarily sent to the address found in the last Reply-to: header contained in the received mail message. Usually this will be the same address that your message was sent from, but some users may wish to receive the Judge replies at a different address. You may be able to change your Reply-to address using your mail software; alternatively, however, you can simply type a return address at the beginning of your message, using the following format:

REPLY-TO: [email protected]

If you are getting unwanted duplicate replies from the Judge, see SET ADDRESS in section 7.1.

Commands to the Judge are entered in the body of the mail message. The Judge does not process the subject line, but does echo it back in its reply so that you can easily tell which reply corresponds to which outgoing message.

2.3.   What Do I Do If the Judge is Down?

Yes, it does happen sometimes: you send a message to the Judge, and no reply comes back; or, a deadline goes by but you receive no results, no late notice, nothing at all. There can be a couple of explanations for this.

It could mean (a) the Judge is down, in which case it will usually process your message when it comes back up; (b) your mail didn't reach the Judge in the first place, which could be due to a problem with your ISP or some intermediate system in the Internet mail relay system; or (c) the Judge did send you a message but you didn't receive it for one of the reasons suggested in (b). Some "anti-spam" programs have been known to falsely identify particular Judges as spam senders and block mail messages from them without warning. If this happens to you, you can either complain to your ISP or find another ISP for sending and receiving email.

A good way to check whether the problem is with your email or with the Judge is to view the Judge Openings List (see section 1.3), which will report the last time each Judge's listing was updated. If your Judge's time is not about the same as all the others', then there is something wrong with the Judge. At this point, the Judgekeeper will already have been sent an email from the Openings List alerting him to the problem, so there is no need for you to contact him directly. You may also wish to check the rec.games.diplomacy newsgroup to see if there is any announcement about the Judge's status.

If the Judge is down, don't continue to send mail to it; wait until it responds to the messages you have already sent. At best, sending repeated messages will flood your inbox with a huge volume of replies when the Judge revives, and may delay processing of games. At worst, you may end up having the wrong commands recorded, because the Judge may not receive your messages in the same order as you sent them. The best thing to do is just wait until the Judge is restored, even though this can be nerve-wracking for some people. You may be recorded as "late" if a deadline expires during the time the Judge is down, but any Master will surely forgive such an offense, and if it is an isolated incident then the effect on your dedication ratings will be minimal.

If you are a Master and the Judge goes down for an extended period, it is usually best to wait until it is restored before trying to "fix" any problems. If you send commands to change deadlines, for example, the Judge may process the pending turn before it gets to your SET DEADLINE command, so that you could inadvertently change the deadline for the next phase. One thing that you can do while the Judge is down, however, is to send a SET NO LIST command if your game is public. If the deadline and grace period should expire during the outage, this will prevent the game from being listed publicly, and prevent any of your players' positions from being taken over by a replacement. Once the Judge is restored, you can then set an appropriate new deadline.

2.4.   Date Formats

Several Judge commands involve the use of dates. The Judge accepts dates from users only in a few specific formats. If you are using a Judge that has been modified to accept non-English commands, you should check with the Judgekeeper to determine whether the date strings have also been changed.

Dates may include one or more of the following elements:

• A weekday, which must be one of these three-letter abbreviations:

  SUN | MON | TUE | WED | THU | FRI | SAT

• A month, which must be one of these three-letter abbreviations:

  JAN | FEB | MAR | APR | MAY | JUN | JUL | AUG | SEP | OCT | NOV | DEC

• A day of the month (a number from 1 to 31, inclusive), optionally followed by a comma;
• A four-digit year
• A numeric time using the 24-hour clock format "hh:mm"

In general, these elements may appear in any order. So, for example, "Jun 15 23:30" and "23:30 15 Jun" are equivalent (and, for that matter, "Jun 23:30 15" works too, even though this syntax makes no sense to humans).

If the weekday is used, then the month and numeric day may not be used. The weekday is converted into the next date (after the current date) that falls on that day of the week. So, if today is a Tuesday, "Tue" refers to the day one week from today.

If no year is specified, the current year is assumed unless the month specified is earlier than the current month and is no more than six months away; in that case, the following year will be assumed. So, if it is currently December, "10 Jan" is assumed to refer to the next year; but if it is currently February, the same date will be assumed to refer to a date in the past.

If a day number but no month is specified, the next date with that day number will be used. If today is June 1, then "15" without any month will be assumed to refer to June 15. If today is June 20, however, the same command will refer to July 15.

If a month but no day is specified, the first day of the month will be assumed, unless it is the current month, in which case the current day will be assumed.

If no weekday, month, day, or year is specified, the current day is assumed (except for the HISTORY command, see section 3.4).

If no time is specified, a default time will be assumed, which depends on the specific command being executed.

All dates and times are based on the clock settings of the computer system that the Judge is running on; usually, this is the local time zone of the Judge system.

Dates are used in the commands: HISTORY, SET ABSENCE, SET DEADLINE, SET GRACE, SET START.

3.     User Registration and Administrative Commands

Before you can join or observe a game on a Judge, you must be a registered user of the Judge. There are a few commands, however, that anyone can use even if they are not registered (one of these, of course, is the command to register yourself).

3.1.   The Single Most Important Judge Command

In this Manual, the last shall be first; thus, we begin with the last command that should appear in every message you send to a Judge:

Indicates the end of commands in a message to the Judge. This prevents your signature file (or taglines inserted by your e-mail provider) from being interpreted as orders and/or being sent out as part of a press message. If this command is not used, the Judge will attempt to parse all characters in the mail message until the end of the file is reached. This can result in your moves being rejected due to errors, or worse: too many players to count have revealed their passwords because they forgot to put ENDPRESS and SIGN OFF after their press, and also forgot to set their mail program to send plain text messages. Their mail programs then attached a nicely formatted HTML copy of their entire message, including the SIGN ON command complete with password, after the plain text version, which the Judge duly treated as part of their press! You should develop a habit of including this line at the end of every message you send to the Judge.

3.2.   User Help Commands

The Judge will send the file 'file' by return mail. In the rest of this document, single quotes will be used to signify the names of help files.

Get file 'flist' for a complete list of available files. Get file 'info' for a description of the more important files. Both of these files are included in the new user package, which you can retrieve with the next command:

Get the new user package of files. These files are generally sent automatically to new users at the time they register with a Judge (see command REGISTER in section 3.3), but they can be specifically requested with this command. These files are the ones that all new users should read before attempting any Judge Diplomacy games.

The file 'info' is sent by return mail, and any other text following this line in the email message is ignored. This is equivalent to GET INFO followed by SIGN OFF. Exception: If this command appears after a SIGN ON or equivalent command (see section 4), then the Judge will process additional text following the HELP command.

Retrieve the current version of the Judge software. The optional level specification is not currently used, but in some future version may generate a log of changes since the specified version.

3.3.   Player Information and Registration Commands

Equivalent to INFO PLAYER (see below) for the address of the user sending the command. (Note: before version 1.0.0, returned only the player's numerical dedication rating.)

Retrieve the entire registration database (this command may be disabled by the Judgekeeper, and is disabled on many Judges). See WHO IS, below, to retrieve registration data for one or more users.

Associate the existing registration information for email (which must be an email address that is already registered with this Judge) with the new mail address from which this command is sent. If your return address changes, you can use this command to tell the Judge that you are the same person without having to resubmit a complete form. You must send this command from the new address, and use your old address in the email position.

The Judge will send the current player data information (games played, deadlines missed, positions abandoned, etc.) for the given e-mail address. See section 5.2 for an explanation of the dedication statistics contained in this information. (Unlike WHO IS, below, this command requires a complete email address.)

Register as a Judge user. Only registered users may join or create games. You must register individually with each Judge on which you want to play. Optionally, you can register on many Judges by using the Web form at http://devel.diplom.org/Email/registration.html, rather than using this command.

This is a multi-line command. The first line must be "REGISTER" and the last line must be "END"; all lines in-between are in the form "field: value". To see the specific fields included in the registration database, get file 'form'. This file contains a template that you can edit and send back to the Judge.

The default house rules (get file 'house.rules') require that all users provide, at a minimum, a correct Name (first and last) Address (containing at least city and state/province/postal code), Country, Email address and Level. (The Level field must have one of the following values: Novice, Amateur, Intermediate, Advanced, Expert. See SET LEVEL, section 5.1.) Moderators of particular games may have additional requirements.

If the field "package: yes" is included in the registration, the Judge will send the new user package of files (see GET PACKAGE, section 3.2).

The registration information is associated with the mail address from which it is received. (See section 2.) A user may update his/her registration data at any time by sending a new REGISTER command from the same mail address. (Important: changing the Email field in your registration does not change the address the Judge will reply to, or associate your registration with that email address. To associate your existing registration with a new address, use I AM ALSO, above. To receive Judge messages at a different address, use SET ADDRESS, section 7.1.)

Retrieve registration information for particular players. Each can be either a complete or partial address; all registered mail addresses that start with the characters matching email will be listed. For example, the command "WHO IS m" will list all users who have an email address that starts with "m". However, email cannot be omitted entirely. This command sends the user's complete registration form (which can be used as a template for a new or revised registration).

3.4.   Game Information Commands

Note: each of the following commands (except "MAP *") may be used after signing on to a particular game, without the "name" specification, to receive information about the signed-on game.

Retrieve (by email) history information for the specified game. The history information is all the messages that an observer would have seen had he been signed on for the time period. This includes turn results, broadcast press, and informational notices (deadline adjustments, late notices, etc.), but not any partial press. You may find it easier to retrieve this information from Alain Tésio's exceptional "Diplomacy tools" site, http://www.floc.net/. (Note: the history is not available in unfinished Blind games, except to a Master.)

The command "HISTORY name" without any other arguments will retrieve all history for the period from one week ago (real time) to the present, up to a maximum of 1000 lines. Other command specifications can be used to change the time period covered and the length of the response, as follows:

(Syntax 1)

HISTORY name [FROM date] [TO date] [LINES n]

This form retrieves the history information for the specified game ("name") for the specified time period (in real time rather than game time). For the valid "date" formats, see section 2.4. If "FROM date" is omitted, the start of the period is the current system time minus 7 days. If "TO date" is omitted, the end of the period is the current system time. If a date is specified but does not include a time of day, the time period begins or ends at midnight on the specified date.

To get the earliest part of the history (or the whole history), use a date that is known to be earlier than the game start date. 1 Jan 1990 (or Jan 1, 1990) is usually sufficient for this purpose.

The "lines" option can be used to limit (or increase) the number of lines that will be returned by the adjudicator. The default is 1000.

Examples:

This will return history of game "foo" starting at midnight on Jan 1, 2003, up to the end of the records (the present date) or 1000 lines, whichever comes first.

This will return history of game "foo" from the start of the game up to a minute before midnight on Dec 31, 2002, or 5000 lines, whichever comes first.

This will not perform as expected – if the start date is not specified, it defaults to the current system time minus seven days. Since the end date is before the start date, it will be ignored. Therefore, this command will produce the same results as "HISTORY foo" with no arguments.

(Syntax 2)

HISTORY name EXCLSTART turnId [EXCLEND turnId] [BROAD]

Retrieves the history information for the specified game excluding specific phases. The keyword "EXCLSTART" is not optional. The returned history contains turns from start of game to (but not including) the EXCLSTART turn, and (if specified) from the EXCLEND turn to the end of the stored history.

The format for 'turnId' is: SYYYYP where:

S - the season (ex: 'S' for Spring, or 'F' for Fall) (some variants may have other seasons)

Y - each digit in the game year. (e.g., 1901, 1425, 1999)

P - Phase (e.g., 'M' for Movement Phase, 'B' for builds, 'R' for Retreats)

Some examples of valid turnIDs:

S1902M (Spring 1902 Movement Phase)

F1999B (Fall 1999 Adjustment (Builds) Phase)

No checking is done to determine whether the turnIDs given are actually found in the game. The default action for erroneous turnIds is to return a history for the entire game. If the EXCLSTART turnID is invalid, the EXCLEND turnID will be ignored.

Examples (assuming that "foo" is a Standard game):

Returns the complete history.

Returns the history for game-years 1901 and 1902 only.

Returns the history from game-year 1906 to the end of the records.

By default, this version of the command retrieves only phase results. However, if a draw notice is found outside the excluded set of phases, the draw notice will be included.

The optional BROAD specification will cause broadcasts and other notices to be included in the history. In the worst case, with the BROAD command, the returned message can be anywhere from 200 Kb to as much as 1 Mb. (Bewareusing this flag!)

Retrieve the current status of the specified game, including players, unit positions and supply center holdings. (Among other things, this can be useful to determine which players are late in sending their orders at a particular time.) If the command LIST without a name is given before signing on to a game, the Judge sends a short list of all current games. The LIST FULL version sends a detailed report including the player list of each game.

[This command has been removed in Judge version 1.5.0 and higher. It was frequently disabled by Judgekeepers running earlier versions.]

Retrieve a postscript map of the current status of the game. Not all variants are supported. The "N" option sends the file in plain postscript format instead of uuencoded, compressed ps format. Rather than use this command, you can obtain maps of any game in multiple formats from Alain Tésio's outstanding "Diplomacy tools" site, http://www.floc.net/

[Removed in version 1.5.0: see previous entry.]

This command must be followed by a LIST output from any judge and will produce a map based on that output. The "*" is real and is not replaced. The "N" option is as above. The LIST output supplied must not have any characters added to the beginning of the line, such as the comment (">") character.

Retrieve an historical summary of the specified game indicating who took what power over when and which supply centers each power owned throughout the game.

Retrieve registration database information (see WHO, section 3.3) for all players associated with game 'name'. If the game is Gunboat, this command can only be used by a signed-on Maser. The optional FULL argument will return information for observers as well, while the default only returns information for the players and Master(s).

4.     Creating, Observing and Joining Games

Note: only one of the commands in this section may be used, once, in each message to the Judge. Further, the only commands that can appear before one of the commands in this section are the ones listed in section 3.

Create a new game on the Judge. The "?" character is required. This command will fail, of course, if the game "name" already exists, or if the Judge is not allowing creation of new games. The game will be Standard unless a variant and/or options are specified. The variant and option specifications for this command are the same as those accepted by the SET VARIANT command, section 8.

In most cases the person creating the game will also want to act as Master. See section 8.1 for how to do this.

Enter the next available game that is forming. Make sure to leave a space after the "?" character.

Enter a particular game that is forming. Do not leave a space after the "?" character. The variant and option specifications are required if, and only if, these options were used in the CREATE or SET VARIANT command. Only registered users may sign on to a forming game. For example, to sign on to the forming Gunboat Chaos game 'mixup' with the password 'guessme':

Note: You may need to sign on more than once before the game starts. You can sign on more than once during the pre-game period, for example, to check the game listing, to change your preference list, or to send a press message to the Master. Each time you do so, you must use the full syntax shown above including the "?" and all variant options.

Sign onto an existing power that you own, or take over an abandoned power. Replace the letter "p" with the initial letter of the power. For example, to sign on as Russia in the game 'stab' with the password 'secret' (remember, commands are not case-sensitive):

Only registered users may take over an abandoned power. However, any user may sign on to an existing position if they use the correct password. This allows you to access your games from a secondary email account. If the SIGN ON command does not come from the player's mail address of record, a copy of the Judge's response will be sent to that address as a precaution against cheating. (If you are getting unwanted duplicate responses because your return address does not match what the Judge has on file for you, use the SET ADDRESS command; see section 7.1.)

Become an observer. An observer will receive the same game reports and broadcasts as the players. The ability of observers to send press themselves is controlled by flags set by the moderator (section 8.5).

5.     Deadlines and Dedication (or, Get Your Orders in on Time!)

5.1.   The Deadline System

The Judge system administers deadlines for all games. House rules normally require that you submit orders before the deadline whether you are finished with negotiations or not! It is considered unsportsmanlike, and possible grounds for expulsion, to deliberately submit orders late for any reason, or to continue negotiating past the deadline (unless your orders are already submitted). On the other hand, illnesses, email interruptions, and other unintended reasons for missing deadlines do occur, and so the Judge system provides a grace period for these events. If you miss both the deadline and the grace period, your position may become abandoned and taken over by another player.

Deadlines are always determined by the Judge's "local" time, which is simply whatever time the system clock says on the computer that is running the Judge software. The deadline notices included in Judge messages will specify the "local" time zone, in hours before or after GMT. For example:

This particular Judge's local time zone, as indicated by the "-0600", is six hours earlier than GMT (i.e., U.S. Central Standard Time). If you don't want to mess around with converting this to your own local time zone, do what the author does – go to http://www.floc.net/observer.py?page=login_screen and create your own customized page, which will list the deadlines for all your games in your local time zone (after you set up your page and tell it which time zone to use).

Unless otherwise specified, orders will be processed on the following schedule. These default settings may be changed by the Judgekeeper, and may be further changed for individual games by a Master, or by any player in an unmoderated game, so be sure to check your own game's listing.

Move    clock 1410 min 12.00 next  71.00 grace 167.00 delay 0.50 days -MTWTF-
Retreat clock   -1 min  0.00 next  23.00 grace  71.00 delay 0.50 days -MTWTF-
Adjust  clock   -1 min  0.00 next  23.00 grace  71.00 delay 0.50 days -MTWTF-

Each value goes with the keyword before it, not after. (So the first line means "clock 1410"; "min 12.00"; etc. – not "clock 1410 min" or "12.00 next".) The meanings of the various settings are as follows:

clock

If non-negative, indicates the minutes past midnight to which the new deadline will be set. 1410 is eleven thirty pm. If negative, this parameter is ignored, and the new deadline is set at exactly "next" hours after the time the previous phase was processed.

min

Indicates the minimum number of hours that can elapse between the previous phase and the new phase. Thus, in the above example, there will be at least 12 hours after a build or retreat phase before the movement orders will be processed. This parameter has no real use other than to prevent a runaway situation if all of the powers in a game were to go CD.

next

Indicates the number of hours after the previous phase is processed that the new deadline will be set. This may be increased to fit into the values of the 'clock' and/or 'days' parameters. In the default case, movement orders are three days after the previous phase. However, because of the "clock" setting, the deadline will be advanced to 11:30 p.m. on the third day; and, because of the "days" setting, if the third day falls on a weekend it will slide to Monday. (Note: the "next" interval is specified as 71 hours, rather than 72, because of the interaction between "next" and "clock". The Judge does not process seasons instantaneously. If the Spring 1901 phase is processed, for example, at 11:35 pm Monday, then a "next 72.0" setting would require the next deadline to be at 11:35 pm Thursday; but, since "clock" requires that the deadline be exactly at 11:30 pm, this would push the deadline forward to Friday.)

In any event, the next deadline should never be earlier than the deadline from the most recently processed phase (thus, for example, if the moderator manually extends the current deadline for two weeks to allow for a player absence, but then the turn is processed because the absent player was nice enough to submit orders before he left, the next deadline will still be approximately two weeks away). The only exception to this is if the moderator manually resets the deadline to an earlier time.

grace

Indicates the number of hours the adjudicator will wait after the deadline expires if not everyone has gotten their orders in yet. In the default case, a grace period of one week after the initial deadline is allowed. When the deadline comes up, a reminder message will be sent to everyone who hasn't gotten their orders in and a notice will be sent to the other players and observers in the game indicating who is late. Another reminder will be sent to the late parties, and a notice to all other participants, every day.

If the game is set "NoNMR" (the default), the Judge will wait for orders until the end of the grace period. Then, a notice will be sent to all players and observers in that game indicating that the late power has been abandoned. Abandoned powers may be taken over by anyone not already playing a power in the game merely by signing on with any password. No orders will be processed until the late power returns or is taken over.

If the game is uses the NMR setting, the power will be deemed abandoned if orders have not been received by 24 hours before the end of the grace period. If you are running an NMR game, therefore, your grace periods must be at least 24 hours and normally should be at least 48. At the end of the grace period, if complete orders still have not been received, either from the original player or a replacement, the power will be declared in "Civil Disorder" and the phase will be processed with incomplete orders. On subsequent phases powers marked CD will not be considered when deciding whether the deadline should slide. When a valid SIGN ON is received, the CD and/or abandoned status will be cleared.

As with the deadline, the program should never set a grace period that is earlier than the grace period from the last processed season, although a moderator can change this manually.

delay

Indicates the number of hours after the last required orders have been received before the orders will be processed. The default is 0.5 hours, so that if all powers get their orders in before the deadline, the orders will be processed thirty minutes later. This gives people a little time to change their mind after orders are submitted.

days

Specifies which days of the week are valid for the setting of the initial deadline. An uppercase letter indicates that that day of the week is okay. If the letter is lowercase, then the deadline is delayed until after noon. A dash indicates that the deadline cannot fall on that day of the week. Unless the "StrictGrace" flag has been set, the grace period also will be extended to a day that is valid for the initial deadline. Warning: this parameter is an exception to the general rule that adjudicator commands are not case-sensitive!

These parameters can be changed by a moderator using the SET command. For example:

These commands will (a) set the default move deadline to (at least) 48 hours after the previous phase was processed, and (b) require a one-hour delay after the last player submits (timely) move and build orders before the turn can be processed. These commands will not change the deadlines for the currently pending phase. See section 8.6.

In addition, a moderator can use the following commands to override the standard deadline settings for the current phase only: SET DEADLINE; SET GRACE; SET START. See section 8.6.

Orders can be sent in any time before the deadline. If multiple movement orders are received for the same unit, the most recent one received will override the earlier one. Attempting to build or remove too many units during the adjustment phase will cause the earliest received build/remove requests to be ignored. Thus you can send in preliminary movement or adjustment orders immediately and then send in revised orders after you change your mind from diplomatic talks. Beware, though, that if everyone gets their orders in before the deadline, the orders may be processed before you have a chance to get your revised orders in.

If you include a SET WAIT command with your orders, you can avoid having your orders processed before the deadline. When you've decided that your orders are final, you can send in a message with a SET NO WAIT command to allow the orders to be processed as soon as the delay period expires and everyone else has their orders in. Remember that SET WAIT is cleared when the orders are processed, so you have to explicitly set it again (if you want it) for each phase.

If the reply mail to any order indicates that there was an error or you have a unit that you did not supply an order for or you didn't explicitly specify all your builds, remove or retreats, the flag indicating that your orders have been received will not be set. All builds must be specified or explicitly WAIVE'd before the adjudicator will consider your build orders complete, unless it is impossible to build all units (e.g., five supply centers taken in a single year or no vacant home centers). An error free set of orders will be required to set the "has submitted orders" status. If no error free orders have been received by the time the grace period expires in an "NMR" game, the partial orders will be processed and the CD status will be set for your power. See the discussion on grace periods above for more info on what happens when you miss a deadline and taking over abandoned powers.

5.2.   Dedication Systems

"Dedication" refers to a player's history of submitting moves on time and playing each position out to the bitter end. Doing this is good; sending orders late and abandoning your position when the game is going against you are bad. Playing Diplomacy is a group effort and can take quite a while to complete (as you know if you've played face-to-face); nobody wants to play with someone who just disappears in the middle of the game.

The Judge tracks player dedication in three ways. System (1) tracks all games ever played on the Judge (unless the Judgekeeper has reset the data files). Systems (2) and (3), which are newer, only track turns played since they were installed on the Judge (which varies by Judge, but was no earlier than 2002).

(1) The original dedication system, which has some flaws but is being maintained for continuity, is based on a point system. The default values, which like all Judge defaults can be changed by a particular Judgekeeper, are as follows:

+3 points for getting your orders in on time.

-1 point for each "deadline missed" reminder the judge sends you.

-50 points for becoming abandoned.

-100 points for missing the grace period and going CD.

There is no penalty for resigning before a deadline, if you submit complete orders before you resign. However, you will continue to receive the -1 point penalty every day that your power remains abandoned after the deadline. If your power goes CD after you've resigned without anyone else taking the power over, you will receive the CD penalty as well (this is to discourage you from resigning when you're down to a few units which could be used to affect the final outcome of the game, but you've just lost interest).

(2) The "ontime ratio" system. In this system players are rated based on what percentage of their total turns they have submitted on time. We use the following formula:

                     Turns Submitted Ontime
      Rating  =  -----------------------------
                        Total turns due

Therefore each player has a rating between 0.0 and 1.0, with higher rankings being better than lower ones.

(3) The "CD ratio" system, which compares the number of times a player has gone into Civil Disorder (i.e., failed to submit complete orders by the end of the grace period, regardless of whether the game was NMR or not), to the number of games he has started. We use the following formula:

                             Times in Civil Disorder
      Rating =  ----------------------------------------------------
                   Games started + abandoned positions taken over

Again ratings range from 0.0 to 1.0, but in this case lower ratings (fewer missed grace periods) are preferable. (Actually, a player who is really sloppy about deadlines could theoretically achieve a ratio above 1.0, but we won't dwell on such an unhappy possibility.)

GMs or others creating games can restrict who is eligible to sign on to the game based on dedication ratings, using the commands SET DEDICATION, SET ONTIMERAT, and SET RESRAT. See section 8.4.

To see dedication rating information for yourself or any other player, see the commands INFO PLAYER and GET DEDICATION, section 3.3.

6.     Entering Orders

6.1.   Move, Retreat, and Adjustment Orders for the Current Phase

Following a SIGN ON command, a player may submit orders for his power for the current phase simply by typing those orders in the body of the mail message. Multiple orders can be entered on one line by separating them with commas or semicolons.

Most orders can be written the same way they are customarily written in face-to-face games, using the abbreviations shown in the Diplomacy rulebook.

Warning: the syntax for convoys is different than in the standard Diplomacy rules. See section 6.2.

Warning: if you want to support a fleet moving to a bi-coastal province, you must specify the coast to which the fleet is moving. If you omit the coast in a support or move order for a fleet that can move to either coast of a province, the Judge will arbitrarily add a coast to the order (namely, the first one on its list). This may lead to unintended results!

Also, unlike standard Diplomacy, the Judge does not require or permit you to specify the power that owns a unit you are supporting or convoying. (So you would just write "A Ven S A Tri" rather than "A Ven S Austrian A Tri".) And, again unlike standard Diplomacy, the Judge will not accept orders that are impossible or badly-written (like A Par-Mun, or F Nth S Philadelphia-Boston), or for units that you don't actually control. Instead, erroneous orders will raise the "error flag," and orders will not be processed until the errors are corrected.

If you have submitted any orders for the current phase, the Judge will list these orders in its reply to every message you send to it, until the phase is processed. It is highly recommended that players check the orders in the Judge reply to make sure their orders have been parsed as they intended, and to make sure that all units have been ordered!

The following is an exhaustive list of the order syntax recognized by the Judge. Some of these order formats may only be used in variant games. Items in [square brackets] are optional.

Movement orders:

[<type>] <s-prov> <holds>
[<type>] <s-prov> <moves>   <d-prov> [<coast>]
[<type>] <s-prov> <moves>   <c-prov> <moves> <c-prov> ... <moves> <d-prov>
[<type>] <s-prov> <support> [<type>] <s-prov>
[<type>] <s-prov> <support> [<type>] <s-prov> <moves> <d-prov> [<coast>]
[<type>] <s-prov> <convoy>  [<type>] <s-prov> <moves> <d-prov>
[<type>] <s-prov> <proxy>   <power>
[<type>] <s-prov> <transforms> <type>

Retreat orders:

[<type>] <s-prov> <moves> <d-prov> [<coast>]
[<type>] <s-prov> <disband>

Adjustment orders:

<build>     <type>   <s-prov> [<coast>]
<remove>    [<type>] <s-prov>
<transform> <type>   <s-prov> [<coast>]
<waive>
<maintain>  [<type>] <s-prov>

The symbols used in these definitions are defined as follows:

<type>       = "army", "a", "fleet", "f", "wing", "w" or <empty>.
<s-prov>     = Source province.
<d-prov>     = Destination province.
<c-prov>     = Intermediate water province in a convoy route.
<power>      = Power name or abbreviation of two or more characters.
<holds>      = "h", "hold", "holds", "stand", "stands".
<moves>      = "-", "->", "m", "move", "moves", "move to", "moves to".
<support>    = "s", "support", "supports".
<convoy>     = "c", "convoy", "convoys", "transport", "transports", "t",
               "fast ferry", "ferry", "ff", "f".
<proxy>      = "p", "proxy", "proxy to".
<disband>    = "d", "disband", "disbands".
<build>      = "b", "build" or <empty>.
<remove>     = "r", "remove", "d", "disband" or <empty>.
<waive>      = "w", "waive".
<maintain>   = "maintain".
<transforms> = "transforms to", "transform to", "transform", "transforms",
               "trafo", "tr".
<transform>  = "transform", "transforms", "trafo".
<coast>      = "/nc", "(nc)", "/north coast", "(north coast)"

Note: "wing" units, "proxy" orders and "transform" orders can only be used if the moderator has enabled the corresponding variant setting. The "maintain" order is used only if the SET ANY DISBAND flag is in use.

Province names can be abbreviated or can be spelled out. Valid abbreviations can be found in the 'map' file for the variant you are playing (use the command "GET MAP" for the standard map, or "GET map.xxx" for variant map "xxx"). When including a <coast>, you can of course replace "north" or "n" with another direction as appropriate.

Here are some examples of valid orders (assuming that the player actually controls the units given in the orders):

Movement phase orders:

Note that, as in the example "Lon-Nth", it is not necessary to specify the unit type, but since Nth is a sea space the order will be rejected if the unit in Lon is not actually a fleet.

Retreat phase orders:

As these examples show, retreats are written exactly like movement orders, except when you are disbanding a unit.

Adjustment phase orders:

The order for "F StP/sc" will be interpreted as either a build or a removal, depending on whether the power has more supply centers than units, or vice versa. But see section 6.3 regarding phased build/removal orders. In the case of a removal, the unit type is also optional, so "Tun" would be a valid removal order, too.

Note the difference between disband orders in a retreat phase, and removal orders in an adjustment phase. In a retreat phase, the word "disband" is required and comes after the unit type and location; in an adjustment phase, the word "disband" or "remove" is optional and, if used, comes before the unit type and location.

Similarly, the syntax for transform orders (which are used only in variant games) depends on whether it is a movement or an adjustment phase. In a move phase, the unit location comes first, followed by the transform command, then the new unit type. In an adjustment phase, however, the transform command comes first, followed by the new unit type, then the location. Examples (assuming, in each case, that the player currently has a fleet in Brest and an army in Spain, and that the current game settings permit the desired transformations):

Movement phase:

Adjustment phase:

In both cases, the order will fail if the player does not specify the new unit type (because this command is supported in variants that recognize other unit types besides armies and fleets); however, specifying the old unit type is never required, and is not permitted in the adjustment phase. The transformation of the army in Spain to a fleet will also fail unless the player specifies which coast the fleet is to be placed on. Finally, please note that while transform orders can be abbreviated as "trafo", they cannot be abbreviated as "t" because that abbreviation is reserved for convoy orders.

Revisions to orders can be sent in any time before the phase is processed. Orders may be processed before the deadline unless the SET WAIT command has been used (see section 7.2). The last valid order for a particular unit will be honored. For Adjustment phases, if you submit more build orders than you can use, the last one(s) received will be honored. If no valid order is received for a particular unit in an NMR game, it will be listed in the reports as "No order processed".

6.2.   Convoy Routes Must Be Specified

Unlike human adjudicators, the Judge requires that convoy routes be specified. (Get file 'rules' for complete details on differences between the Judge and the standard rules.) To do a convoy, you must order each participating fleet to convoy the army, and also must order the army to follow a specific convoy route. For example:

The "wrong" column is correct according to the standard rules of Diplomacy and the usual practice in human-adjudicated games, but on the Judge it will raise the error flag!

The convoying fleets do not have to belong to the same power as the army, or as each other; but if the route specified for the army does not match up exactly with the fleet orders, the convoy will fail. As shown above, only the army has to specify the entire route; the fleets only need to give the origin and destination.

The Judge generally does not check the "reasonableness" of a convoy order, because of the complexity of checking all possible units along all possible convoy paths. Convoy orders will be accepted as long as the convoying fleet and the convoyed army actually exist, and the destination is a (land) province defined in the map file, unless the optional StrictConvoy flag is set (see section 8.3).

6.3.   Submitting Orders for Future Phases

Orders can be submitted for future phases using the following commands:

Clear any pending orders entered with the PHASE command. (Note: there is no way to clear orders entered for the current phase.) This clears both conditional and non-conditional future orders.

<season> = "Spring", "Summer", "Fall" or "Winter".

<phase>  = "Movement", "Retreat", "Adjustment" or "Build".

Seasons and phases can be abbreviated by their first letters, except in the case of Summer (used in some variant games), which is abbreviated "U". Spaces between the items are optional.

For example:

The orders following the PHASE directive will be collected and saved until the indicated phase occurs. Some syntax checking will be done on the orders, but the full list of errors can't be determined until the actual phase occurs. That error list will be mailed to you when the orders are processed. In most cases, the syntax for phased orders is the same as for current orders, but there is an exception for build and removal orders. In a phased order, you must include the specific command "build" or "remove" (or "disband").

If any pending orders are found for a particular phase, your power will get the "orders have been received" status automatically whether or not there were any errors or if the orders are incomplete. All orders until the next PHASE directive or the end of the mail message will be saved for the specified phase.

Only orders are saved. In particular, press messages cannot be delayed for later transmission. An exception to this is that the SET WAIT and SET NO WAIT directives will be propagated to the future phase. Your pending orders will be listed in replies to intervening order submissions.

As noted above, subsequent build orders will override earlier ones if more build orders are received than you have supply centers. Thus, when submitting orders for future build phases, you should list your builds in reverse order of preference in case you don't get as many supply centers as you were expecting.

Submit conditional orders. These statements can only be used after a PHASE command; they cannot be used for the current phase's orders. The THEN's are optional for old Fortran programmers. The conditions are of the form:

<condition> = [NOT] [<power>] [<type>] <prov>

Conditions may be combined with the keywords "AND" and "OR" evaluated left to right. You can use parenthesis to change the precedence. The condition evaluates to "true" if a unit of the specified type belonging to the specified power is present (or not) in the specified province at the beginning of the specified phase. The province must be specified, but the type and power are optional and interpreted as "any" if not specified. The power, type and province can be specified in any order. Powers can be abbreviated to two or more characters or spelled out. For example:

Conditional statements can be nested with expected results. The end of a line closes off all parentheses and the end of the mail message closes all open IFs without an error being reported. (As with all other examples, the white space above is just for illustration and is not required.)

7.     Other Player Commands

The commands in this section must follow a valid SIGN ON command, and may be used by any player. Unless otherwise noted, these commands are also available to Masters. Observers may also use the SET ADDRESS, SET PASSWORD, and RESIGN commands, and any press commands that have been enabled by the Master.

These commands will only affect the game for which the player signed on in the same message. If, for example, you want to change your password or return address in more than one game, you need to send a separate message for each game.

7.1.   General Commands

Withdraw from the game. This must be the last command in the message to be effective; so if you want to broadcast a farewell message, do so before you enter the RESIGN command. A Master cannot RESIGN. See command EJECT, section 8.2.

Change where your game reports go. If you don't specify an address, the address from the mail headers (specifically, the last Reply-To: header encountered) will be used. If you sign on and the address in the mail headers does not match the reporting address you will get two replies, one to each address. This can be fixed by using SET ADDRESS with no reply address specified. You can also specify multiple addresses separated by commas, but no spaces, to receive reports at two (or more) addresses. Example:

Change your password. Passwords must contain only alphanumeric characters.

Record a preference list for power assignment. May only be used before powers are assigned (of course), and should appear immediately after an initial SIGN ON entering a forming game. A player may indicate that he has an equal preference for two or more powers by enclosing them in square brackets. For example, "SET PREFERENCE E[FGR][TAI]" would indicate that the player's first choice is England; after that, he would prefer any of France, Germany, or Russia equally; and after that would take any of the remaining powers. If the list is a single asterisk ("SET PREFERENCE *"), then a random power will be assigned if allowed by the game settings (see SET PRFBOTH, section 8.3). If this command is not used or the list is empty, the player will be assigned a random power only after all players who have submitted preferences have received their assignments (unless the game is set to require random assignment for all powers, see SET PRFRAND, section 8.3, in which case this command has no effect).

7.2.   Deadline-Related Commands

Request or cancel an absence period. Does not affect the deadline for the current phase, but no subsequent deadlines will be set during the absence period. Neither start_date nor end_date can be before the current date. If end_date is before start_date, the command will be ignored. If end_date is omitted, an absence period of 24 hours is assumed. If absences are overlaid, they count as separate absences. However, Judge versions 1.4.0 and higher will reject attempts to set overlapping absences.

Observers and eliminated (inactive) players cannot set absences. Masters can.

SET NO ABSENCE cancels one pending absence period. The end_date is ignored. The first absence found that includes start_date is cancelled.

Setting an absence never extends the current deadline; it only takes effect when a turn is processed, if the next deadline using the normal settings would fall after start_date. A player who is going away needs to either submit their orders for the phase that is pending at start_date before they leave, pick a start_date that is early enough so that this won't be a problem, or ask the Master to extend the current deadline. (Understandably, Masters may be unhappy if you choose the last option.) It is also recommended (though not required) that start_date and end_date be days on which deadlines normally fall; for example, in a weekdays-only game, setting an absence to start or end on a Saturday or Sunday may yield undesired results.

Start_date and end_date may use any of the date/time formats described in section 2.1. Examples of valid date formats:

Note that the last example will not work if it is sent on Saturday, Sunday or Monday, as the Judge will interpret "Sat" as the following Saturday, and "Tue" as meaning 'this coming Tuesday', not 'Tuesday next week' as the player seems to intend; the Judge will reject the absence because it appears to end before it begins. It is therefore better in most cases to specify the dates.

Only a maximum of three (3) absences can be pending at any given time for a single player. Once an absence expires, however, it is removed from memory and its "slot" becomes available for another request. If you need to change a previously-set absence, first use SET NO ABSENCE to remove the old one, then use SET ABSENCE to set the correct dates. Otherwise, you will use up two of your slots.

Each absence request will generate an informative message to the Master, and he will also see the pending future absences every time he sends a message for the game (along with pending orders).

If an absence request exceeds the game limit (see command SET MAX ABSENCE in section 8.6), a message will be sent to the Master who must manually activate the absence for it to take effect. Generally, the Master should do this by using the BECOME power command (see section 8.2) and setting the absence for the player, as this allows the player to cancel or change the absence later if desired. (Also, the Master, like each player, has only three absence "slots," and might use them all up setting absences for other players.) The MAX ABSENCE setting is ignored if the absence is set by a Master, even using BECOME.

Sets/clears the wait flag. If the Master or any (eligible) player has this flag set, orders will not be processed before the deadline. See also SET STRICT WAIT, section 8.3. This flag is automatically cleared when orders are actually processed (not necessarily at the deadline), and must be set again for the next phase.

7.3.   Draw/Concession Commands

Cast a vote for or against a concession (if the moderator has enabled this command; see SET [NO] CONCESSION, section 8.3). Replace "p" with the initial of the power you wish to concede to. Even though you may only concede to the largest power on the board, the Judge requires you to specify the power to be sure you really know to whom you are conceding. SET NO CONCEDE is only necessary to clear a previously-ordered concession, since a concession can only be approved by unanimous vote.

Concessions are cleared every time orders are processed, so you need to re-set a concession (if you still want it) every phase.

Note: The only valid forms of these commands were "SET [NO] CONC" until version 1.4.0, which added the "SET [NO] CONCEDE" forms.

Cast a vote in an automated draw. The powerlist option is only valid if the game is set NoDIAS. Any draw vote, DIAS or NoDIAS, is good for one phase only. All draw votes are cleared at the end of a phase, so you need to cast your vote again every phase (if you still want to agree to a draw). It is normally not necessary to use SET NO DRAW unless you change your mind in the middle of a phase, since no draw can be passed without consent of all active players.

The term "DIAS" means "Draws Include All Survivors". By default, all games are DIAS. The moderator can change this with the SET NO DIAS or SET DIAS commands. See section 8.3. In a DIAS game, a surviving player cannot be excluded from a draw. In a NoDIAS game, a surviving player may give up his right to be included in a draw. In either case, unanimous approval of surviving players is required for a draw to be passed.

In a DIAS game, a player may cast his vote for a draw by issuing the command SET DRAW. He may withdraw earlier approval by issuing the command SET NO DRAW. If at any time all surviving players agree to a DIAS draw, the game will be immediately terminated (without waiting for the next deadline), and all participants in the game will be informed of the result.

The situation for NoDIAS games is a bit more complex. To vote for a NoDIAS draw, a player issues the command "SET DRAW powerlist", where powerlist is a list of the identifiers for the powers he wishes included in the draw. When a player gives approval to powerlist and powerlist includes his own power, he is also implicitly approving any subset of powerlist that also includes his power. On the other hand, when a player gives approval to powerlist and powerlist does not include his own power, he is implicitly approving any subset of powerlist, and any subset of powerlist plus his own power.

For example, if Austria issued the command SET DRAW AEG, he is approving the draws AEG, AG, AE, or A. Note that by including himself in his draw list, he is assuring that he cannot be excluded from a draw. If Austria issues SET DRAW A, he is accepting any draw as long as it includes him. If Austria issues SET DRAW FT, he is approving FT, F, T, AFT, AF, AT, or A.

If, under these rules, more than one draw is approved by all players, the draw including the most players passes.

In a NoDIAS game, SET NO DRAW is equivalent to the command SET DRAW x, where x is the power issuing the command. This means that the player will only accept a concession to himself.

Here are a few examples of the NoDIAS draw mechanism in action. The players listed are assumed to be the only survivors.

France: SET DRAW AEF

England: SET DRAW AEF

Austria: SET DRAW AEF

Results in a three-way draw between Austria, England, and France.

France: SET DRAW AE

England: SET DRAW AEF

Austria: SET DRAW AEF

Results in a three-way draw between Austria, England, and France.

France: SET DRAW AE

England: SET DRAW AEF

Austria: SET DRAW AE

Results in a two-way draw between Austria and England.

France: SET DRAW AEF

England: SET DRAW AE

Austria: SET DRAW AE

This game does not end in a draw.

France: SET DRAW A

England: SET DRAW A

Austria: SET NO DRAW

Results in a concession to Austria.

7.4.   Press Commands

Send a press message. Note that at least one of delivery-option or fake-option must be included after PRESS (to specify who will receive the message), but not after BROADCAST (which automatically goes to all players and observers). The adjudicator will send as press any text that it encounters until it reaches a line containing one (and only one) of the keywords ENDBROADCAST, ENDPRESS, or SIGN OFF by itself. In particular, it will ignore any orders or other command keywords appearing in the text of press.

The types of press allowed depend on the game settings. Press messages can be sent to one or more individual players, or can be broadcast to all players and observers. White press refers to messages sent to other players in which the Judge identifies who the message is from. Grey press is sent out anonymously; the sender may sign his own, or someone else's, name to it, but the Judge will not verify the source of the message. Fake press (which may be white or gray) is a message sent to one or more players that is made by the Judge to appear as a broadcast message to all people or to an alternate set of people. Finally, Postal Press is delayed until after the results of the current phase have been processed (while all other press is sent immediately).

The results of the LIST command will indicate, among other things, the types of press allowed in a particular game. Possible settings are:

None:

No press at all is allowed, except press to and from the Master.

White:

Only white press is allowed in this game.

Grey:

Only grey press is allowed in this game (however, press to the Master will always be sent as white press).

White/Grey:

Both white and grey press are allowed. By default press will be white (press to the Master will always be sent as white press).

Grey/White:

Both white and grey press are allowed. By default press will be grey (however, press to the Master will always be sent as white).

-------

Observer any:

Observers can post press with the same restrictions as regular players. This is the default and does not show up on list output.

Observer white:

Observers cannot post grey press. In a game that only allows grey press from players, press from observers will show up as white press.

Observer none:

Observers cannot post press at all, except to the Master.

-------

Partial Allowed:

Players may send messages to any one or more other players.

No Partial:

Only broadcast messages to all players can be sent. Press to individual players is disallowed, except press to the Master only. This option is only useful in Gunboat variants where the identities of the other players are unknown.

-------

No Fake:

Messages sent to individuals cannot appear as broadcast messages or vice versa, nor can messages sent to one group of individuals appear as though it was sent to an alternate group.

Partial may be Faked:

Messages sent to individuals can appear as broadcast messages or can appear as though they were sent to an alternate group.

Partial Fakes Broadcast by Default:

Messages sent to individuals will appear as broadcast messages to all players unless otherwise specified.

Partial Fakes Broadcast:

All messages, whether broadcast or to individuals, will appear as though they were a broadcast message to all players.

-------

PostalPress:

Players may send delayed (broadcast-only) messages that will not be distributed until after the current phase is processed. This may be enabled in addition to, or in lieu of, other forms of press.

The press setting values listed above can also be used by a moderator as command keywords, after the SET command, to change the types of allowable press. See section 8.4. For example:

would mean that all press (except to or from the Master) would appear to be a grey broadcast message, even if it is actually sent to only one player. The commas are optional. (The press settings that appear in the LIST results will not be in exactly the same format as shown above; for example, the "Observers None" setting would appear as "No Observers".)

Note: If fake press is allowed in a game, press to the Master will not be faked, and you will get scolded if you try.

By default, games are "White, Partial Allowed, No Fake, No PostalPress".

Options:

Note: The BROADCAST command without options is equivalent to "PRESS TO ALL"; that is, the message will be sent to all players. However, using the PRESS command without any options will result in no message being sent. This is to prevent accidental broadcasts, which can result in your secret attack plans being sent to the entire game. Finally, if BROADCAST is followed by options, it is treated exactly the same as a PRESS command (so if, for some odd reason, you wrote "BROADCAST TO G", the message would go only to Germany and not to the entire game).

(1) color-options

WHITE | UNANONYMOUS | UNANONYMOUSLY

The message is sent out with your power and return address specified. This is only necessary if white and grey press are both allowed and grey is the default. This is the most common use of press, and results in a message that looks something like this:

GREY | ANONYMOUS | ANONYMOUSLY

The message is sent out with no indication as to the originator. This is only necessary if white and grey press are both allowed and white is the default. Suppose France sends the command "PRESS GREY TO G": then Germany will receive a message like the following, with no indication that it came from France:

(2) delivery-options

TO list

+list

The message will be sent only to the list of powers specified. The list consists of the single character identifier for the powers combined as a single word. Thus "PRESS TO FRG" would send the message to France, Russia and Germany in a Standard game. In most variants the first letter of the power is usually the character (but not always; for instance, India in the Youngstown variant is 'N' because 'I' is used to represent Italy). The special characters 'O' and 'M' are interpreted Observer and Master respectively in all variants.

Warning: only use initials in the list; you may be dismayed if you type "PRESS TO Turkey", because the Judge will try to interpret "Turkey" as a list of initials. In a Standard game, this will result in an error message, because U, K, and Y are not valid power initials; in some variants, however, you might end up sending a message to six players!

TO ALL BUT list

-list

The message is sent to all powers except those specified in the list. Note that since all press that can be read by Observers is archived in the game's history file, a message sent "PRESS TO ALL BUT R" (for example) will be available to Russia by means of the History command. Use "PRESS TO ALL BUT RO" to be sure that the message isn't archived. Also, remember that a Master is able (if he wants) to read all press regardless of how it is addressed.

(3) Fake options

The Judge's "fake press" options are not often used, and as a result are not widely understood. "Fake" press is press with a forged "To" line; you cannot use these options to make it look like press came from someone else. To hide the origin of press, you have to use the "GREY" color-option.

The main use of "fake" press is to try to fool certain players into thinking that other players did or did not see your message when that is not the case. For example, you could send a partial press only to one player but make it look like a broadcast; or you could send a partial press to France and Germany addressed only to France (so that France doesn't know Germany also saw it). Some combinations of these options will work but not make much sense; for instance, if you send a message to Italy and it says "Press to Turkey" at the top, he will obviously know it is faked.

[NO] FAKE [BROADCAST]

The message is faked (or not) as a broadcast message to all players. The "NO FAKE" option is needed only in a game that has the "Partial Fake Broadcast by Default" setting.

FAKE [PARTIAL] delivery-option

The message is faked as going to the set of people specified even though it may be a broadcast message or be a message sent to an alternate set of people. The delivery-option may be any of the forms listed in the previous section.

For fake press, you must first specify the real recipients of the press (if not specified, a broadcast is assumed), then put the word "FAKE" followed by the addressees to be named in the message header (again, if not specified, it is assumed that a fake broadcast is intended). For example, "PRESS FAKE TO FRG" will be interpreted as a broadcast message to everyone that is faked as going to France, Russia and Germany rather than a message going to France, Russia and Germany that is faked as a broadcast. If the latter was intended, the keyword "FAKE" can be placed at the end as in "PRESS TO FRG FAKE" or the keyword "BROADCAST" must be specified as in "PRESS FAKE BROADCAST TO FRG". As an example in a Grey press game allowing fake broadcasts, Italy might start off the game by posting the following press message:

Everyone but Germany would get a press message that looks like this:

[Remember, however, that if Germany thinks to issue a HISTORY command, he can see this in the history archive. If this is undesirable, the command here should read "PRESS TO ALL BUT GO FAKE BROADCAST".] Then in the same (or a separate) message to the adjudicator (since there can be more than one press message per mail message) Italy could send the following:

Russia would get the message with a header of "Message to Russia in 'gamename':". Remember, we said this was a Grey press game -- if the game was White press, Italy's name would be in the header (which would kind of spoil the effect). If it was White/Grey, Italy would have to throw in the "GREY" keyword to get the effect, but even then (or if the game was Grey/White) it wouldn't quite be the same since if Germany really meant to be so obnoxious why wouldn't he just send the messages out as white press?

Press to the Master only is always allowed, no matter what the press settings are, so that requests for deadline extensions, or any other message needing the Master's attention, can be sent without having to resort to direct email outside of the game. Likewise, a Master can always issue press commands, to communicate with the players.

There are some commands that cause the Judge to send messages to all the players (e.g., changing your return address in a non-gunboat game). If one of these commands has been processed and a partial, faked partial or grey press message is attempted, the Judge will send out the notice(s) as separate messages, to all players, and the partial, faked, or grey press will be sent as designated.

Diaries allow a player to record his thoughts during the game for broadcast at the end of the game. If the diary command is given with no options, it will default to "DIARY RECORD". Options are:

RECORD: "DIARY RECORD" begins a new, numbered diary entry. The Judge will read until encountering "ENDPRESS", "ENDBROADCAST", or "SIGN OFF" (just like a normal press entry).

LIST: When a player issues "DIARY LIST", the Judge will return a numbered list of his created entries, and the date and time they were created.

READ [number]: Issuing "DIARY READ" allows a player to read an entry he has already made. The number of the entry to read must be specified (it can be obtained from "DIARY LIST").

DELETE [number]: Deletes the specified diary entry numbers. Note that diary entries are not reused, so it's possible to have "holes" in the numbering scheme if any entry but the most recent one is deleted.

Terminate a Press or Broadcast message. Note that either form of this command will terminate either kind of message. This command must appear on a line by itself, or else it will be treated as part of the text of the message. Unlike most commands, these words cannot contain a space after the letters "END". Likewise, if "SIGN OFF" is being used to terminate a press message (not recommended), it must appear on a line by itself.

Send a delayed broadcast. If postal press is enabled, this command will append the lines following it to the postal press file, until an ENDPRESS, ENDBROADCAST, or SIGN OFF is encountered. When the orders process, the postal press file is mailed to everyone signed on to the game. All Postal Press is sent to all players and observers; there are no "partial" or fake options.

8.      Creating and Mastering Standard Games

The commands in this section are used to "moderate" games; that is, control various game settings affecting deadlines, press, etc. Usually, these commands are issued by a Master, who is a non-participant in the game. However, the Judge also is configured to run "unmoderated" games, in which any of the players can change some of the game settings. Many Judges do not allow unmoderated games, so check with the Judgekeeper before attempting to start this type of game. The term "moderator" means either a Master in a moderated game, or any player in an unmoderated game.

8.1.   Changing Moderation Status

When a game is created, the user who created it is (under the default settings) signed on as a player. To make the game moderated and become a Master, the user should include this command immediately after the CREATE command. The Judgekeeper can modify the default settings so that the person who creates a game automatically becomes a Master, in which case this command is unnecessary; however, it does no harm to use it anyway.

Changes a game from unmoderated to moderated. This is set by default by the "BECOME MASTER" command.

Can only be issued by a Master. Changes the game from moderated to unmoderated. As noted above, many Judgekeepers do not permit unmoderated games.

8.2.   Master-only Commands

The commands in this section can only be issued by a Master, and therefore cannot be used at all in unmoderated games.

Allows the moderator for a game to assume the identity of a particular power. The power specification may be spelled out or abbreviated. Any commands following this will be interpreted as if they had been submitted by the specified power; this allows a Master, for example, to change a player's password or to submit orders for a power. As a result, no Master-only commands (including another BECOME) can follow a BECOME command.

The player for "power" will receive a message from the Judge advising him that the Master used the BECOME command and confirming all commands entered by the Master. Warning: this message will include Master commands that preceded the BECOME command. Masters therefore should not use any commands in the same message as a BECOME that they wouldn't want the player to see.

The BECOME command is useful in a number of situations. One use is to submit commands for a particular power if, for example, the player for that power gets disconnected from the network and calls the Master on the phone to give his orders.

(Note, however, that a Master can submit orders for any unit in the game without using the BECOME command. Orders for multiple units can be specified on the same line, separated by commas or semicolons; but you shouldn't mix orders for units belonging to multiple powers on the same line. This technique is used in some variants to allow the Master to manipulate the players' orders in some way before entering them into the Judge. In other situations, the BECOME command is preferred, because otherwise the true owner of the power will not receive the confirmation reply from the Judge. Also, the "orders have been received" flag will not be set for a particular power if their orders were submitted by the Master without the BECOME command. It this case, it may be necessary to use the PROCESS command to get the phase processed.)

You can also use the BECOME command to SET ABSENCE for a player, either because the player isn't clear on how to do it themselves, or because their requested absence exceeds the current MAX ABSENCE setting. The MAX ABSENCE setting does not apply to absences entered by the Master using the BECOME command. However, Masters should avoid approving unusually long delays without the consent of the players (anything over two weeks is generally considered "unusually long," although this depends on the expectations of players in a particular game).

The BECOME command does not reveal the power's password to the Master (except on some older versions of the Judge software). However, the Master can use the SET PASSWORD command after BECOME to set a new password for a player who has lost or forgotten theirs. Example:

Resign a particular power. This is the only command a Master may use to resign himself. If an email address is specified, the command will work to resign observers too. The "EJECT power" form will not work if more than one person is signed on to the specified power (which can occur if there is more than one Master or more than one Observer in a game).

Forces a game to begin, even if not enough players are signed on. The missing players will be filled in by 'dummy players' that are already abandoned (to allow real people to sign on).

To suspend a game. Players can still send press, but moves will be blocked. No game processing or deadline expiration will occur. Periodic messages will be sent to remind of the pause state. To resume the game, the master should issue the "RESUME" command.

Will send to the Master a prediction of the current turn, using partial orders already entered.

Promote the Observer with the specified email address to a Master. A game may have more than one Master at any time. This will not work unless the person specified is already signed on as an Observer in the game.

Direct the Judge to process orders immediately with whatever it has in its list. Partial or nonexistent orders do not cause powers to be considered in civil disorder. This can be useful after a ROLLBACK command or if you want to not wait for a player for some particular reason. If the optional (but highly recommended) phase is specified, the PROCESS command will be ignored unless that is indeed the current phase. Specifying the phase allows you to avoid potential disaster if the Judge processed the desired phase shortly ahead of getting your request. Without it, your command would process the next phase, which could potentially expose orders that players had pending. A typical "season year phase" specification might be "Fall 1905 Retreat". Abbreviations like "F1905R" will also work.

Roll the game back to the specified turn number. The turn number is displayed in all the reports and lists, starting at 001 for spring 1901 moves (in a Standard game) and incrementing for each actual phase that's played. Retreats and adjustments that are not played do not increment the turn number. If turn_number is omitted, the game will be rolled back to the immediately preceding turn. Specifically, this command will roll back the game to its state immediately before turn_number was processed, so if you want to roll the game back to the very start you could use "ROLLBACK 001". By contrast, "ROLLBACK 002" would return a Standard game to the state that existed after Spring 1901 Moves but before Fall 1901 Moves.

History is kept for at least a month, but it may not be possible to go back too far – this command is intended to go back one phase for the case where one person's orders get messed up and need to be resubmitted. Orders for intermediate turns that were skipped over should remain intact, but those previous orders may wind up being meaningless based on changes in the results of the reprocessed turn. Any pending orders that existed will also be reprocessed so if they were revised by hand the first time the replayed phase was processed the revisions may get lost.

Most Masters make it a policy never to rollback a turn except to correct an adjudication error (which is rare). If you do rollback a turn, you should immediately enter the necessary corrections to orders and PROCESS the turn again.

This command will cause all partial press between the players to be copied (silently) to each Master as well. This is useful in games involving novice players to help in identifying and correcting common mistakes. It is also useful as a precaution against cheating. Note, however, that in non-gunboat games players may communicate directly rather than going through the Judge, so you may miss traffic. If you use this option you must pay careful attention so that you don't leak any information to the other players.

This command clears the "All Press" flag.

If enabled, no announcements about player abandonment, power takeovers and such will be broadcast to the other players or observers. Its purpose is to prevent information from being disclosed in gunboat games, particularly tournaments where multiple games may lose the same player.

If enabled, allows Observers to use the SET ALL PRESS command to see partial press between players. Use with caution, for obvious reasons.

Return the game to the position immediately prior to the start of the game. Powers will be unassigned and the game will be flagged Manual Start, so that a Master must then use the SET AUTO START command to start the game. Games can only be unstarted if no turns have yet processed. This can be useful if a player is ejected or resigns, allowing everyone to start fresh instead of forcing a replacement player to take over the abandoned position.

8.3.   Standard Game Moderation Commands

Most of the SET commands in this section (and in all following sections relating to game moderation) will generate a message that will be sent to all people involved in the game to alert them to a change in the game parameters. Everyone active in the game should agree before standard game settings are adjusted. A Master has discretion to extend deadlines for particular turns upon request; a Master ordinarily should not, however, shorten the deadline without player consent.

Restart a paused, completed or terminated game. Any player can resume a game unless a Master has used the SET NO RESUME command, in which case this command is only available to Masters.

Command under development. Enable this flag to direct the Judge to automatically create a new game with identical parameters when this one ends (in a draw or victory), except that the new game will be set to 'NoList'. Disable it to cancel a previous request. Fails if a sequence number cannot be added/incremented on current game name.

Determine whether turns will be processed automatically, or only when the moderator executes the PROCESS command. SET AUTO PROCESS (the default) is equivalent to SET NO MANUAL PROCESS, and vice versa.

Determine whether the game will automatically start when it has enough players signed on. AUTO START (the default) is equivalent to NO MANUAL START; and vice versa. If game was MANUAL START and ready to go, then SET AUTO START will start it.

All of these commands are now obsolete, and are retained for compatibility only. They were used to record information used to track games in various rating systems (Boardman numbers, which were used to track postal and email standard Diplomacy games; Electronic Protocol numbers, which were used to track email games only; and Miller numbers, which were used to track postal and email variant games). None of these numbering systems are currently being maintained. These commands could be used only after receiving a number from the number custodian.

Sets or clears the NMR flag. If set, the Judge will process orders after the grace period even if all powers have not yet submitted complete ones. Default is "NoNMR". See section 5.1 for more details.

Sets the comment that appears in the full listing format. The full comment consists of the rest of the input mail message up to (an optional) SIGN OFF command.

Sets the comment that appears in the brief listing format. The text string should be under 60 characters in length.

Disables/enables concessions in DIAS games. Enabled by default. See section 7.3.

Disables/enables requirement that all draws must include all survivors. Default is "DIAS". See section 7.3.

Enables/disables public listing of the game. If a game is set NO LIST (the default) then only people who know about it will be able to see it. Useful for "by invitation only" games. PUBLIC is equivalent to LIST, and PRIVATE is equivalent to NO LIST.

Determine whether the Judge will assign powers exclusively using the preference lists entered by the players (PRFLIST - this is the default); randomly assign powers to all players (PRFRAND); or assign a random power to any player that requests it, and powers according their preference lists to all other players (PRFBOTH). See SET PREFERENCE in section 7.1.

Clear/set the flag that allows one player to give control of one or more of his units to another player. Default is "NO PROXY". See section 6.1 for proxy syntax.

Designate a game as rated or unrated. By default moderated games are rated and unmoderated games are unrated. Unrated games will not affect the players' dedication rating. This flag may also be read by third-party rating systems.

If enabled (default), any player can resume a terminated game. If disabled, only a Master can. This flag is on by default because the Judge creates all games as unmoderated by default; however, there is probably no good reason to leave it on in a moderated game.

If enabled, disallows "implausible" convoys. This is disabled by default, so fleets can be ordered to convoy any army to any province defined in the map file. If set, only convoys that could conceivably succeed may be ordered. (As of the current version, the plausibility checking is rather minimal; it only rejects convoys if either the origin or destination province has no adjacent sea spaces.)

Determines the ability of players to use the SET WAIT command. If STRICT WAIT is set, only players who have moves currently required will be allowed to use SET WAIT. If NO STRICT WAIT is set (default), any currently active player can use SET WAIT.

Declare the game over without a resolution. If the game has not started, it will be ended and no one can ever sign onto it again.

8.4.   Game Access Settings

The commands below can be used to restrict who is permitted as a player in a particular game.

Restrict which users can sign on, based on the "Site" field in the player registration database. ANY is the default. Since the "Site" field contains whatever users put in their registration forms, this command is no longer widely used (nor, in your author's opinion, useful). This command harkens back to the day when electronic mail was a novel system available at a relatively small number of locations with big computer systems, and users who got their email access at the same "site" were likely to know one another. Seems quaint now, doesn't it?

Add an address to the "allow" list for the game; or, using the "-" prefix, remove an address from that list. Important: if an "allow" list exists for a game, then only addresses on that list will be able to sign on as a player or observer. This can be used to set up an invitation-only game. Warning: putting a player on the "allow" list does not have the same effect as removing him from the "deny" list! See SET DENY PLAYER, below.

Enable or disable a requirement for a moderator to approve new players before they can submit moves. Disabled by default. If enabled, the flag has no effect on players already in the game, but new players may not submit orders until a moderator approves them using the SET APPROVE[D] command. Note, however, that if the moderator sets this flag before players sign on for the game, all players would start in "not approved" status and would not be able to submit orders until approved.

Disapprove/approve a player from making moves. Disapproved players will have any move orders rejected by the judge. A list of power letters to be processed follows. This allows a moderator to make sure that a new player meets whatever eligibility requirements may exist for a particular game (e.g., being able to communicate in a specific language) before participating. All players are approved by default, unless they join the game after the SET APPROVAL command has been enabled. A moderator can set or unset any player's approval status with this command at any time, regardless of whether the SET APPROVAL command has been enabled.

Restricts access to the game to those people with a dedication point rating equal to or greater than the indicated minimum level. Note: setting the level to 0 or higher will prevent any newly-registered player from joining the game. The minimum level can not be higher than the moderator's current dedication rating. The default setting is -10000. See section 5.2.

Add an address to the "deny" list for the game; or, using the "-" prefix, remove an address from that list. Any address on this list will be unable to sign on as a player or observer. Note that the "deny" list is not checked if an "allow" list exists.

Restricts access to a particular class of player. The three official classes are Novice, Intermediate, and Expert. Amateur means either Novice or Intermediate, and Advanced means either Intermediate or Expert. "Any" of course means any class of player may play (and is the default). Players can change their classification (if they feel their level has changed) by re-registering. See command REGISTER in section 3.3.

Restricts access to the game to those people with an ontime ratio equal to or greater than the indicated minimum level. The minimum level can not be higher than the moderator's. The default setting is 0, which allows any user to play. This setting will not affect a newly-registered player, since that player by definition has a "perfect" ratio (0/0). See section 5.2.

Restricts access to the game to those people with a Civil Disorder ratio lower than or equal to the indicated maximum level. The maximum level can not be lower than the moderator's. The default setting is 1.0, which allows any user to play. This setting will not affect a newly-registered player, since that player by definition has a "perfect" ratio (0/0). See section 5.2.

8.5.   Press Settings

The following commands can be used by a moderator to enable or disable various types of press. More detailed descriptions of each type of press are in section 7.4. The default settings are "WHITE" and "PARTIAL MAY BE FAKED", and as noted below.

Disables/enables players to send blank press messages. Usually not very useful to enable.

Disables/enables receiving broadcast press messages (does not affect any player's ability to send broadcasts). This command can be used by Observers as well as Masters. Enabled by default.

Disallow all fake press.

Sets press option to grey only; i.e., the Judge will not identify the sender of any press messages (except to/from a Master).

Sets press option to grey by default with white allowed. Players will have to use the WHITE keyword to send white press.

Disables/enables players who are marked as late from sending any press (except to a Master). Disabled by default.

Disables/enables the sending of press message during minor phases (retreats and builds). Face-to-face (and many postal) games commonly do not allow minor phase negotiations, Judge games historically have, so this is enabled by default. Cannot be changed once the game is in progress.

If enabled, players cannot send any press (except to a Master) until they have submitted valid orders. Disabled by default. If you use this setting, you should warn all players to use SET WAIT after submitting their initial orders, until they finish negotiating.

Disables all press/broadcast messages (except to/from a Master).

Restrict the types of press messages that Observers can send. The options are as follows:

ANY – Observers can send press subject to the same restrictions as regular players (this is the default).

NO – Disallows all press from observers.

WHITE – Observers may send white, but not grey, press messages.

Disables/enables the ability to send non-broadcast messages to individual powers. Enabled by default. (Partial press to and from the moderator is always enabled.) SET PARTIAL without any modifiers (see next two commands) allows partial press but does not change any of the "fake" settings.

All messages, whether broadcast or partial (except to/from a Master), will appear as though they were a broadcast message to all players. If, and only if, BY DEFAULT is included, then players may use fake-options (as explained in section 7.4) to make their messages appear as non-broadcasts.

Partial press messages will be faked only if the sender expressly uses a fake-option.

Turns postal press on or off. Disabled by default. Postal press is press published with the results of the turn.

Sets press option to white only. All press will disclose the identity of the sender, and the GREY option will not be accepted.

Sets press option to white by default; grey press may be sent by expressly using the GREY keyword.

8.6.   Deadline-Related Settings

Change the deadline for the current phase. This can be either earlier or later than the previously-set deadline, but a moderator should have a very good reason before setting it earlier. If the new deadline is later than the old one, the grace period will automatically be extended to the appropriate interval after the new deadline. The reverse is not true, however; if the deadline is moved to an earlier date, the grace period will not automatically change. See section 2.4 for the available date formats.

Change the grace period for the current phase. This can be either earlier or later than the previously-set grace period, but cannot be earlier than the current deadline.

Disables/enables late counting. Disabled by default. If enabled, every time a player is late the late messages will include a count of the number of times this player has been late in the game. This counter will be reset when a new player takes over.

Sets the maximum absence duration that a player can set, in days. Default is 15. This does not apply to absences set by a Master. The number can be set no higher than 31 and no lower than 0. See SET ABSENCE in section 7.2 for further details.

Change the default deadline calculations for the game. The "setting" specification may be any of the following: CLOCK, MIN, NEXT, GRACE, DELAY, DAYS. See section 5.1 for explanation of each setting. These settings will affect the calculation of all future deadlines, but will not affect the current phase.

Change the earliest date/time at which orders can be processed for the current phase. If date is later than the current deadline, the deadline will also be extended to date. This command is rarely used, since it is usually easier for the moderator to use SET WAIT. However, if all players' orders are in and no one has set "wait," and the turn still isn't processing for no apparent reason, you should check this setting as a probable cause.

Determines whether the "days" setting will apply to the grace period. If enabled, the grace setting will be applied as an absolute time interval after the deadline. If disabled (default), then grace periods will be extended, if necessary, to conform to the "days" setting. For example, if a game has deadlines on weekdays only and a 24-hour grace period, the default setting would set the grace period for Monday if the deadline is on Friday. However, the Strict Grace flag would cause the grace period to expire on Saturday in this situation.

9.     Configuring Variant Games

The Judge is capable of adjudicating a wide variety of variants of the standard Diplomacy game. Some of these are "rules variants" using the standard map with modified rules (e.g., different types of units, different number of powers, different starting positions, etc.). Other variants include a different map as well as non-standard rules.

For a list of all variants currently supported by a particular Judge, send the command "SIGN ON ? password XXX" (where "XXX" can be anything that is not a valid variant name). Most variants have an "info" file that describes the variant, which can be obtained by sending the command "GET INFO.variant", where "variant" is a valid variant name.

The Judge also recognizes a few "variant options" that can be combined with any variant (including the Standard "variant"). These also have their own INFO.option files (for example, "GET INFO.GUNBOAT").

The variant can be specified either by including it in the CREATE command, see section 4, or by using the following commands before the game starts.

To change the variant of a game, or add an optional rule. This can only be done before the powers are assigned and before the requisite number of players for the new variant type have signed on. SET VARIANT can only be used to set one option per command (unlike CREATE). Note: if the game has been set as a variant and it is desired to un-set this, use "SET VARIANT STANDARD".

Disable the specified optional rule. This command can only be used to remove options, not to change the underlying variant type. To change the variant itself, use SET VARIANT.

9.1.   General Variant Settings

The following commands can be used either in conjunction with a pre-packaged variant, or to "roll your own" variant on an existing map by modifying various rules. Since these commands alter the nature of the game, they can only be issued by a moderator before the game has begun. Unless otherwise noted, all these optional rules are disabled by default (that is, the default setting is "NO" or "NORMAL").

Allows a power to build in any owned (home or non-home) center during a build phase.

Allows powers to disband any unit during a build phase (and thus gain the option to rebuild on a buildable center if desired). Players must submit an order for every unit (use "maintain" for units that are to be kept). A 'wait' is set for all active players during the build phase. Opposite of SET NORMAL DISBAND, see below.

Transformations on attacked but not dislodged units will fail/work. See SET TRANSFORM, below, for an explanation of the transformation options.

If enabled, units are automatically disbanded when dislodged; i.e., no retreats are permitted.

Enable/disable the display of all owned centers (not just those of the power sending the command) in "Blind" variant.

Set the game to start in a build phase, with no units, so that players can choose a different initial stating unit position. Has no effect on variants that already start in a build phase (such as Chaos).

Set the number of centers required to win the game to number. This will cause the game to end when the first player reaches this number of winning centers. If more than one player reaches this value in the same year, then it is increased to one more center than the top players have. The players can still end the game before the victory condition is achieved, using the SET DRAW command.

Disables/enables fleets in coastal provinces from participating in a convoy. Default enabled for Machiavelli games, disabled for all other variants (including Machiavelli2).

If enabled, players can voluntarily disband a unit during a normal movement phase. Default enabled for Machiavelli, disabled for Machiavelli2 and all other variants.

Disables/enables provinces with dual behaviour (both land and water). This is only available as an option in certain variants (including Standard) where it is coded into the map file. Get file 'duality' for more details.

Disables/enables gateways. This can only be used in a variant that has this option coded into its map file. Get file 'info.colonial' for an example and explanation.

Allow builds to be made only in the building power's home centers during build phase. (Default setting for Standard games.) See also SET ANY CENTER, above; SET ONE CENTER, below.

Disables/enables "HongKong" rule. Can only be used in a variant that has this option coded into its map file. Get file 'info.colonial' for an example and explanation.

Uses the standard rules for disbands on a build turn; i.e., a power can only disband when it has more units than centers. Opposite of SET ANY DISBAND, above.

Allow a power to build in any owned (non-home) center during a build phase, as long as one home center is still owned.

Sets the number of players (not powers) in the game. When the number of players is set to less than the number of powers, the game will begin when that number of players signs on to the game, assigning excess powers evenly among the players, thus enabling players to play multiple powers. Get file 'info.duplex' for more information and an example. (It is not meaningful to set this value to more than the number of powers in the game.)

Disables/enables optional rule allowing portages.  A "portage" is basically the opposite of a convoy: it allows an army to carry a fleet across a land province. You can come to your own conclusion about how realistic this would be. It works just like a normal convoy: one or more armies can participate to set up a portage chain, and the portage will fail if not all armies in the chain are sucessfully ordered. The destination province must have its coast specified if it has one. For order-writing purposes, write the move as a convoy (that is, order the fleet to move through one or more intermediate land provinces to its destination, and order each army to "convoy" the fleet).

Sets the number of powers (not players) in the game to something less than the normal number for the variant being played. The Judge will assign players to the specified number of powers using whatever method the moderator has specified (preference lists or random assignment). So, for example, "SET POWERS 5" in a Standard game means that the Judge will stop after assigning five powers, and the other two powers will not exist: their units will be missing and their centers open for capture as neutral supply centers. This is more intended for variants where the number of powers can be varied without upsetting game balance. The number of players will be adjusted to equal the number of powers, unless set to a lower value using the SET PLAYERS command.

Disables/enables railways. Can only be used in a variant that has this option coded into its map file. Get file 'info.colonial' for an example and explanation.

This setting is enabled by default. If disabled, the player list will not be revealed in SUMMARY output after the game terminates. This is useful for gunboat tournaments where player lists may be the same in multiple games. It is not useful in a non-Gunboat game since the player identities will already be known.

If enabled, the number of players (not powers) in the game will not be revealed to the players or observers. This is intended for use in duplex games.

This setting is enabled by default, except in Gunboat games. If it is disabled, changes to game settings will appear to be made by 'someone@somewhere'. Otherwise, the changer will have their email shown.

Enables or disables a "summer" movement phase between Spring and Fall. (This phase is abbreviated "U" for purposes of commands such as "HISTORY", "PHASE" and "ROLLBACK".) Enabled by default for Machiavelli, disabled by default for Standard games.

Enables or disables Touch Press. When enabled, each player can only send one broadcast message per turn, and can only send partial press to players with whom they are touching (defined as a legal Wing move). Players can always send partial press to the GM, and cannot send press to Observers. When disabled, players can send press as permitted by the standard press settings.

Enables or disables unit transformation orders (e.g., changing an army to a fleet, etc.), according to 'transform-option'. The command must include either the NO flag or a transform‑option, but not both. The available options are as follows:

NONE (equivalent to SET NO TRANSFORM); or

<when>:<where>, in which

<when> is either MOVE or BUILD; and

<where> is one of:

HOME[CENTRE|CENTER]

ONE[CENTRE|CENTER]

ANY[CENTRE|CENTER]

ANYWHERE

NONE

CENTRE and CENTER are interchangeable (and optional). ANY is assumed to be an abbreviation for ANYCENTER, so ANYWHERE must be spelled out in full if used.

If you omit the "when" specification, it defaults to BUILD. So, "SET TRANSFORM :ANYCENTER" is the same as "SET TRANSFORM BUILD:ANYCENTER".

If you omit the "where" specification, it defaults to HOMECENTER. So, "SET TRANSFORM MOVE" is equivalent to "SET TRANSFORM MOVE:HOMECENTER".

SET TRANSFORM <where> without a ":" will return an error message.

SET TRANSFORM NONE and SET NO TRANSFORM do not work correctly in njudge versions 1.3.1 and earlier. Once transform options are turned on in these versions, there is no way to turn them off (except by manual editing of the game file by the Judgekeeper)!

If activated, the transform options operate as follows:

"When" options:

MOVE:  Allows transformations in a move phase where permitted by the "where" option. A unit that is ordered to transform is deemed to be holding, and may receive support from other units to hold. If the unit is dislodged, the order to transform fails. If a unit is attacked but not dislodged, the result depends on the setting of the Attack Transform option (see SET [NO] ATTACK TRANSFORM, above).

BUILD:  Allows transformations in a build phase where permitted by the "where" option. Because it may be possible for a player who otherwise has no adjustments required to transform a unit in a build phase, an automatic 'wait' is placed on the build phase if this option is set.

"Where" options:

HOME CENTER: Transformations are allowed during the specified phase only for units on a player's home centers.

ONE CENTER: Transformations are allowed during the specified phase in any center as long as the player owns at least one home center.

ANY CENTER: Transformations are allowed during the specified phase in any center.

ANYWHERE: Transformations are allowed during the specified phase in any land province (units can never transform at sea). However, wings that are blockading may not transform during a build phase. Of course, an army may not transform into a fleet unless it is in a coastal province.

NONE: No transformations are allowed during the specified phase.

See section 6.1 for the syntax of transformation orders. Note, in particular, that the type of unit to be transformed into must always be specified (because this option can be used in games with Wing units).

9.2.   Machiavelli Settings

Machiavelli™ is a complex variant of Diplomacy, set in Renaissance Italy, that was commercially published by Battleline Games and later acquired by Avalon Hill. Machiavelli games have a variety of scenarios and optional rules that can be implemented on the Judge. These commands can only be issued by a moderator before the game starts. Get file 'info.machiavelli' for more specific information on standard and optional rules for this variant.

Disables/enables optional rule that allows bribes from nonadjacent players.

Disables/enables optional assassination rules.

Disables/enables optional rules allowing players to borrow money from the bank.

Disables/enables optional rules that introduce random events into the game: variable income, bank loans, assassinations, famine and plague.

Disables/enables optional famine rules.

Disables/enables optional fortress rules.

Disables/enables the use of garrisons.

Disables/enables Machiavelli 2nd Edition (1995) rules. If disabled (default), Machiavelli 1st edition rules apply.

Disables/enables money. Without money, Machiavelli is similar to normal Diplomacy, where you need to own one city for each unit built.

Disables/enables optional plague rules.

Disables/enables optional rules that allow double strength units.

Disables/enables storms. Works as per plague, except causes fleets at sea to be eliminated randomly (in a storm).

10.     Alphabetical Index of Commands

Following is a list of all commands available on the Judge, except those limited to the Judgekeeper. Each command is indexed by the section number in which it is described in this manual. In compiling this index, optional flags that reverse the meaning of a "SET" command (such as "SET [NO] something") have been omitted.