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: username@domain.tld

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). Howeve