Author: David Norman and Eric Wald
Description: Defines the syntax for messages between DAIDE clients and servers.
Keywords: Diplomacy artificial intelligence DAIDE Parlance DPP message syntax

# Parlance Message Syntax

Modified from version 0.14 of the Diplomacy AI Development Environment Message Syntax, which was last updated on 2 April 2006.

The following document defines the language which will be used for communications between a client and server, and for negotiation between two clients, in the Diplomacy AI Development Environment project. Statements which use "will", or "must" are mandatory, and must be observed. Statements which use "should" or "may only" are recommended, but cannot or will not be enforced.

The syntax is split into a number of levels. Each level completely includes all previous levels. The levels are:

Level 0 | No Press
Level 10 | Peace and Alliances
Level 20 | Order proposals
Level 30 | Multipart Offers
Level 40 | Sharing out the Supply Centres
Level 50 | Nested Multipart Offers
Level 60 | Queries and Insistences
Level 70 | Requests for suggestions
Level 80 | Accusations
Level 90 | Future discussions
Level 100 | Conditionals
Level 110 | Puppets and Favours
Level 120 | Forwarding Press
Level 130 | Explanations
Level 8000 | Free Text

All clients must implement the commands in all levels — they should not assume that they will never be playing in a game that is above the level they are designed for. When a client receives a message that is above its intended level, there is a response it can use to indicate this.

The Diplomacy AI Development Environment Message Syntax is based on the structure and syntax of the DPP Language written by Danny Loeb. However, a significant number of changes have been made from the DPP Language in order to make it more powerful and more consistent.

### Common terms

There are a number of terms which are used by a lot of commands. They are:

- Power — can be one of AUS, ENG, FRA, GER, ITA, RUS, TUR. These may be changed for variants other than Standard; see the MAP token for details.
- Province — can be one of ADR, AEG, ALB, ANK, APU, ARM, BAL, BAR, BEL, BER, BLA, BOH, BRE, BUD, BUL, BUR, CLY, CON, DEN, EAS, ECH, EDI, FIN, GAL, GAS, GOB, GOL, GRE, HEL, HOL, ION, IRI, KIE, LON, LVN, LVP, MAO, MAR, MOS, MUN, NAF, NAO, NAP, NTH, NWG, NWY, PAR, PIC, PIE, POR, PRU, ROM, RUH, RUM, SER, SEV, SIL, SKA, SMY, SPA, STP, SWE, SYR, TRI, TUN, TUS, TYR, TYS, UKR, VEN, VIE, WAL, WAR, WES, YOR. Alternative abbreviations must not be used. These may be changed for variants other than Standard; see the MAP token for details.
- Coast — can be one of NCS, ECS, SCS, WCS; in addition, NEC, SEC, SWC, NWC might be accepted.*
- Season and Phase — can be one of SPR (Spring Moves), SUM (Spring retreats), FAL (Fall Moves), AUT (Fall retreats), WIN (Adjustments).
- Unit type — can be one of AMY, FLT.

### Notation

In the text, anything in [square brackets] may be omitted.

Anything which is specified twice followed by an ellipsis (...) may be repeated any number of times (including once, but at least once unless it is also in [square brackets]). Anything which is specified three times followed by an ellipsis must be repeated at least twice.

Any (round brackets) are part of the syntax of the language.

### Internal Representation

Internally, all tokens are represented as a 16-bit value. Details of the value for each token are provided in the Client-Server Protocol Document. Conversion between 16-bit values and text can be done. All text versions of the tokens are 3 characters long, alphabetic only, and not case-sensitive.

## Level 0 : No Press

In this section, we just have the syntax required for getting a game up and running, ordering, retrieving results, and general game management.

### (o) Choosing a game.*

#### client_command = LST

#### server_message = LST ('gamename') (players_needed status) ('variant_name') (variant)

The client can request a list of games on the server by sending LST. The server will respond with a LST message for each game, followed by a YES (LST) message. Each LST message will contain:

- 'gamename' — a name to uniquely identify this game, as detailed in the SVE command
- players_needed — the number of unfilled or disconnected powers
- status — a status code for the game, as listed below
- 'variant_name' — the name of the variant
- variant — the game options, as listed in the HLO message.

Each status will be a single token from among the following:

- status = NME — Accepting new players
- status = OBS — Running, with a full set of players
- status = IAM — Running, with some positions available for takeover
- status = TME — Paused, with a full set of players
- status = DSD — Paused, with some positions disconnected
- status = SLO — Finished, with a solo result
- status = DRW — Finished, with a draw result
- status = OFF — Closed, without a result

Alternatively, the server can respond with REJ (LST) if it does not have multi-game capabilities.

#### client_request = LST ('gamename')

The client can send this command to request the LST message for a single game. In this case, the YES (LST) message will not be sent. If the specified game does not exist, the server will instead send REJ (LST ('gamename'))

#### client_command = SEL ('gamename')

This command is sent by the client to the server at any time, including before any NME, OBS, or IAM message. It chooses a game to participate in by its 'gamename', as included in the LST message.

Warning: After sending this command, the client must be prepared to receive a new Representation Message, in case the selected game uses a different map than the current game.

The server will respond with YES (SEL ('gamename')) if the game selection is successful, even if the client had already been participating in the selected game, or REJ (SEL ('gamename')) if there is no game by that name.

#### client_request = SEL

#### server_message = SEL ('gamename')

The client can also send SEL with no parameters, to request the name of the currently selected game. The server will respond with SEL ('gamename'), or with REJ (SEL) if the current game has no name, such as in a server without multi-game capabilities.

### (i) Starting the game.

#### client_command = NME ('name') ('version')

This should be sent by the client to the server as soon as it has connected. It contains the name and version of the client. Both name and version are text fields. They may only contain letters, numbers and underscore. The server will respond with YES (NME ('name') ('version')), or REJ (NME ('name') ('version')) if the game has already started.

The name and version are stored by the server, for storing game records when the game ends. It is not possible for a client to request information about which client is playing each power.

#### client_command = OBS [('name') ('version')]*

This is sent by the client to the server in place of NME, to indicate that the connected client is actually just an observer, and doesn't wish to take part in the game. Observers are informed of the game progress as turns process, but do not take any part in the game. The server will respond with YES (OBS ('name') ('version')) if the name and version were specified; YES (OBS) otherwise.

#### client_command = IAM (power) (passcode)

This is sent by the client to the server in place of NME, to indicate that the client is rejoining the game following a loss of connection. Passcode is the passcode which was sent to the client by the server in the original HLO message at the start of the game. The server will reply with YES (IAM (power) (passcode)) if the takeover is allowed, or REJ (IAM (power) (passcode)) if the passcode is wrong, the game is not waiting for a replacement of the specified power, or the game has not started.

Following a successful IAM message, a MAP and HLO message are NOT sent. The player is straight into the game where it left off. Note that there may have been messages which were lost as the connection broke. These messages will not be resent on reconnection.

Until a successful NME, OBS or IAM message has been received, the client will be treated the same as an observer, except that if the game is in progress, no results messages (ORD, NOW and SCO) will be sent.

#### server_command = MAP ('name')

Once the client has joined the game, the MAP token is sent to specify the map which is to be used, as soon as the HLO or OBS has been received and acknowledged. The name is unique to the map — so if the client has played a game on a map with this name before, then this will be the same map again. The Standard map is called 'standard'. name can include only letters, numbers and underscore. Map names are not case sensitive.

The client may request another copy of the MAP message at any time, by sending MAP with no parameters.

The client should respond with YES (MAP ('name')) if it is to play on the map, or REJ (MAP ('name')) if the client can not cope with the requested map.

If the client does not know the map, then instead of replying with YES (MAP ('name')) or REJ (MAP ('name')), it can request the map definition with:

#### client_message = MDF

The server will reply with the map definition of the form:

#### server_message = MDF (powers) (provinces) (adjacencies)

(powers) is the list of powers. For example, (AUS ENG FRA GER ITA RUS TUR).

(provinces) is the list of provinces. This is broken further into two sections — ((supply_centres) (non_supply_centres)).

(supply_centres) is of the form ((power centre centre ...) (power centre centre ...) ...) where centre is a supply centre province, and power is the power for which the centre is a home centre. power is UNO for neutral supply centres. Also, in the case of a variant where a supply centre is a home centre for two or more powers, power may be of the form (power power ...). Note that the home centres are the locations where a power may build new units, but are not necessarily the location where the units start the game.

(non_supply_centres) is the list of all non-supply-centre provinces.

(adjacencies) is the list of what is next to what. It is of the form ((prov_adj) (prov_adj) ...).

(prov_adj) is of the form (province (unit_type adj_prov adj_prov ...) (unit_type adj_prov adj_prov ...) ...).

unit_type is one of:

- mdf_unit = AMY — list of provinces an army can move to
- mdf_unit = FLT — list of provinces a fleet can move to
- mdf_unit = (FLT coast) — list of provinces a fleet can move to from the given coast.

adj_prov is one of:

- adj_prov = province — a province that can be moved to
- adj_prov = (bicoastal_province coast) — a coast of a province that can be moved to

The type of province can be determined from its adjacencies. An inland province only has army adjacencies. A sea province only has fleet adjacencies. A coastal province has both. A multi-coastal province has entries for each coast.

Note that for a land province surrounded by sea, there will be an AMY entrance with no provinces listed.

So, the map for Standard would be (with some provinces skipped, and line breaks added for clarity):

    MDF (AUS ENG FRA GER ITA RUS TUR)
    (((AUS TRI BUD VIE) (ENG LON LVP EDI) ...
    (UNO POR SPA BEL ...)) (ADR AEG ALB APU ...))
    ((ANK (FLT ARM BLA CON) (AMY CON SMY ARM))
    (ADR (FLT ION ALB TRI VEN APU))
    (CON (AMY BUL SMY ANK) (FLT BLA (BUL ECS) (BUL SCS) AEG SMY ANK))
    (BUL (AMY GRE SER RUM CON) ((FLT ECS) RUM BLA CON) ((FLT SCS) CON AEG GRE))
    (BOH (AMY TYR MUN SIL GAL VIE))
    ...)

No map will ever contain a province abbreviation which is also has a defined meaning in the Diplomacy AI Development Environment syntax, except that the tokens for provinces and powers on the Standard map may be reused on variant maps.

No map will ever contain more than 256 provinces.

Once the client has received the Map Definition, it should then reply with YES (MAP ('name')) if it is able to use the map, or REJ (MAP ('name')) if it is not. If the client wishes to do some processing on the map before the game starts, then it should do this before sending YES (MAP ('name')).

The client can send the NOW and SCO commands to the server to determine the supply centre ownership and starting positions for the variant.*

The client must not assume that the supply centre ownership and starting positions will be the same as for the other games which use the same map; for example, a Fleet Rome game might use the same map name as Standard. Note that for some variants, the map name may be different, but the actual map is the same as another variant.*

On all maps, the condition for a solo is having more than half the supply centres in the game. So for a map which has 34 or 35 centres, the victory condition is 18 centres.

#### server_message = HLO (power) (passcode) (variant)

The server sends this to each client when the game starts. power is the power to be played by this client, or UNO for an observer. passcode is an integer value which is required to rejoin the game. variant is of the form (variant_option) (variant_option) ..., and contains the details of any options for the game. For example:

HLO (ENG) (1234) ((LVL 20) (MTL 1200))
You are England. Your passcode is 1234. This is a level 20 game, with 20 minutes (1200 seconds) per movement turn.

variant_option can be any of the following:

- variant_option = LVL n — game is of syntax level n. This variant option will always be specified.
- variant_option = MTL seconds — maximum number of seconds available for movement turns. If not specified, there is no time limit.
- variant_option = RTL seconds — maximum number of seconds available for retreat turns. If not specified, there is no time limit.
- variant_option = BTL seconds — maximum number of seconds available for build turns. If not specified, there is no time limit.
- variant_option = DSD — deadline stops on disconnection. If a player disconnects when it has orders due, the deadline timer stops.
- variant_option = AOA — any orders accepted. Any orders which match the syntax for an order will be accepted, whether they are legal or not. If not specified, then only orders which could be valid will be accepted.*

The variant options will always be specified in the order they appear in this document.

The client can send the command HLO to the server with no arguments at any time. The server will reply by sending another copy of the HLO message, or REJ (HLO) if the game hasn't started.

### (ii) Current Position

#### server_message = SCO (power centre centre ...) (power centre centre ...) ...

This is sent from the server to each client at the start of the game, and after each Fall Retreat turn (or Fall Movement turn if there are no retreats). It indicates the current supply centre ownership. Unowned centres are listed against the power name UNO. For example, at the start of the game:

SCO (AUS BUD TRI VIE) (ENG LPL EDI LON) (FRA BRE MAR PAR) (GER KIE BER MUN) (ITA ROM NAP VEN) (RUS STP MOS WAR SEV) (TUR ANK CON SMY) (UNO NWY SWE DEN HOL BEL SPA POR TUN GRE SER RUM BUL)

The client can send the command SCO to the server with no arguments at any time. The server will reply by sending another copy of the latest SCO message, or the starting SCO message if the game hasn't started.

#### server_message = NOW (turn) (unit) (unit) ...

This is sent from the server to the client at the start of the game, and after every turn. It indicates the current turn, and the current unit positions. For example, at the start of the game:

NOW (SPR 1901) (AUS FLT TRI) (AUS AMY BUD) (AUS AMY VIE) (ENG FLT LON) ...

Fleets in multi-coastal provinces have a province and coast bracketed together. For example:

(RUS FLT (STP SCS))

Before a retreat turn, units may have a list of retreat options, prefixed by MRT (Must retreat to). For example:

(ENG FLT NTH MRT (LON YOR EDI NWG))

If a unit has no possible retreats, then it will still be listed, and the player still must order the disband. For example:

(ENG FLT NTH MRT ())

Retreat options will include a coast if a fleet can retreat to a multi-coastal province. For example,

(TUR FLT CON MRT (BLA SMY (BUL ECS) (BUL SCS)))

The client can send the command NOW to the server with no arguments at any time. The server will reply by sending another copy of the latest NOW message, or the starting NOW message if the game hasn't started.

#### client_request = HST (turn)

Any previous turn's results may be requested by sending the HST command to the server with the turn as a parameter (for example, HST (SPR 1901) ). The server will reply by sending the ORD messages for that phase, followed by SCO and NOW messages to give the position after the turn requested. SCO will be sent after every HST command, not just those where supply centre ownership changes. REJ (HST (turn)) is sent if the requested turn doesn't exist.

### (iii) Submitting orders

#### player_request = SUB (order) (order) ...

This is sent from the player to the server, to submit orders for the next turn. order can take the following form:

- Movement phase orders:
  - order = (unit) HLD — Hold
  - order = (unit) MTO province — Move
  - order = (unit) SUP (unit) — Support to hold
  - order = (unit) SUP (unit) MTO prov_no_coast — Support to move
  - order = (unit) CVY (unit) CTO province — Convoy
  - order = (unit) CTO province VIA (sea_province sea_province ...) — Move by convoy
- Retreat phase orders:
  - order = (unit) RTO province — Retreat to
  - order = (unit) DSB — Disband unit
- Build phase orders:
  - order = (unit) BLD — Build unit
  - order = (unit) REM — Remove unit
  - order = power WVE — Waive build

unit is a unit, and must be in the form as given by the NOW command — that is, (power type province) — for example, (ENG FLT LON).

province is any province. For a fleet moving to a province with multiple coasts (Spain, St. Petersburg, or Bulgaria on the Standard map), it must be of the form (province coast).

prov_no_coast is a province with no coast specification.

sea_province is a province where a fleet may be to convoy.

Examples:

- SUB ((ENG AMY LVP) HLD) ((ENG FLT LON) MTO NTH) ((ENG FLT EDI) SUP (ENG FLT LON) MTO NTH)
- SUB ((ENG FLT BAR) MTO (STP NCS)) ((ENG FLT NWY) SUP (ENG FLT BAR) MTO STP)
- SUB ((ITA AMY TUN) CTO SYR VIA (ION EMS)) ((ITA FLT ION) CVY (ITA AMY TUN) CTO SYR) ((ITA FLT EMS) CVY (ITA AMY TUN) CTO SYR)
- SUB ((ENG AMY YOR) CTO NWY VIA (NTH)) ((ENG FLT NTH) CVY (ENG AMY YOR) CTO NWY) ((ENG FLT NWG) SUP (ENG AMY YOR) MTO NWY)
- SUB ((ITA FLT NAP) BLD)
- SUB ((RUS FLT GOB) REM)

All unused builds must be waived, even if they are unusable.

The server will reply to each order (not each message), in left-to-right order through the orders, with a THX message. This is of the format:

#### server_message = THX (order) (note)

order is the order as submitted. note is one of the following:

- note = MBV — Order is okay
- note = FAR — Not adjacent
- note = NSP — No such province
- note = NSU — No such unit
- note = NAS — Not at sea (for a convoying fleet)
- note = NSF — No such fleet (in VIA section of CTO or the unit performing a CVY)
- note = NSA — No such army (for unit being ordered to CTO or for unit being CVYed)
- note = NYU — Not your unit
- note = NRN — No retreat needed for this unit
- note = NVR — Not a valid retreat space
- note = YSC — Not your supply centre
- note = ESC — Not an empty supply centre
- note = HSC — Not a home supply centre
- note = NSC — Not a supply centre
- note = CST — No coast specified for fleet build in a multi-coastal province, or an attempt to build a fleet inland or an army at sea.
- note = NMB — No more builds allowed
- note = NMR — No more removals allowed
- note = NRS — Not the right season

Alternatively, it will reply with REJ (SUB (order) (order) ...) if the game has not started.

Any order which receives a note other than MBV has been rejected by the server, and a corrected order should be submitted in its place.

Movement and retreat orders can be changed by giving a new order for a unit. Builds and retreats can be canceled by ordering NOT (SUB (order)). The server will reply to this with YES (NOT (SUB (order))), or REJ (NOT (SUB (order))) if the order could not be canceled. Alternatively, an entire turn's orders can be cleared with NOT (SUB), to which the server will reply with YES (NOT (SUB)).

#### server_message = MIS (unit) (unit) ...

#### server_message = MIS (unit MRT (province_list)) (unit MRT (province_list)) ...

#### server_message = MIS (number)

This command can be sent by the server immediately after the last THX message following a SUB command. If sent, it indicates that the server does not have a full set of orders. The first form is used during a movement phase, and indicates the list of units which have not been ordered. The second form is used during a retreat phase, and indicates the list of dislodged units which have not been ordered. The third form is used during a build phase. If number is positive, it indicates that the player must order that many more disbands. If number is negative, it indicates that the player must order that many more builds.

The first two forms of the MIS command use exactly the same parameter format as the NOW command.

The player may request a copy of the current MIS command by sending MIS with no parameters. The server will respond with REJ (MIS) if the game has not yet started or has ended. If there are no outstanding orders, then the server will reply with MIS with no parameters.

#### player_command = NOT (GOF)

This is sent by the player to the server. It tells the server not to process orders until the deadline. It is the equivalent of set wait on the judges. The server will reply with YES (NOT (GOF)), or REJ (NOT (GOF)) if the game has not started, the power has been eliminated, or the game has ended.

#### player_command = GOF

Go ahead and process orders when everybody is in. The server will reply with REJ (GOF) if the game has not started or has ended, or YES (GOF) if everything is okay. It will immediately follow this with MIS (...) (as when an incomplete set of orders is submitted — see SUB) if not all orders are in for this player.

If the player does not send GOF or NOT (GOF) during a turn, the server will assume it is ready to process as soon as it has received a complete set of orders. (That is, GOF is assumed each turn.)

### (iv) Results

#### server_message = ORD (turn) (order) (result)

This is sent by the server when the turn has processed. turn is the turn which has just processed, with the same format as in the NOW command.

order is an order performed by a player. One ORD message is sent per unit for a movement phase, one per retreat for a retreat phase, and one per build, disband, or waive for a build phase. It has exactly the same format as in the SUB and THX commands.

result is the result of the order. It can be one of the following:

- order_result = SUC — Order succeeded
- order_result = BNC — Move bounced
- order_result = CUT — Support cut
- order_result = DSR — Move via convoy failed due to dislodged convoying fleet
- order_result = NSO — No such order (for a support, convoying fleet, or convoyed army)

In addition, a second token may be included:

- RET — Unit was dislodged and must retreat.

In the case of a unit which was convoying or holding, RET may be the only token.

Retreat orders will always have a result of SUC or BNC. BNC indicates the unit was destroyed by a bounced retreat.

Build orders will always have a result of SUC.

Waived builds are reported as (power WVE) for the order. For example:

ORD (WIN 1901) (RUS WVE) (SUC)

If a power waives multiple builds, then multiple waive ORD messages are sent.

When the turn processes, the series of ORD messages will be immediately followed by a SCO (if the centre ownership has just been updated) and a NOW message. The NOW message will always be the last message in this sequence.

Turns may be skipped (for example, a retreat turn where nobody has any retreats). The NOW message indicates which is the next turn.

The previous turn's results may be requested by sending an ORD command to the server with no parameters. The server will reply by resending the last movement turn's ORD message, and any subsequent Retreat or Build ORD messages, or REJ (ORD) if the game has not started or the first turn has not yet processed.

### (v) Saving and Loading a game

#### server_command = SVE ('gamename')

The server can send this at any point. It is a request for the client to save the current game with the name given. gamename will never be more than 8 characters, and can include only letters, numbers and underscore. Game names are not case sensitive. The client should save everything it will need in order to be able to resume the game at a later date. Once the game is saved, the client should respond with YES (SVE ('gamename')). If there is an error saving the game, then it should respond with REJ (SVE ('gamename')). Once the game has been saved, the client should continue playing.

#### server_command = LOD ('gamename')

The server can send this to the client instead of sending a HLO message. It indicates that the game specified is to be loaded and restarted, rather than a new game started. See SVE for details of gamename. The client should load the game and then respond with an IAM command, and then start playing from the loaded position. If the game can not be reloaded (for example, because a game with that name has never been saved), then it should respond with REJ (LOD ('gamename')).

If a player fails to reload the game, then the game will be started and the player in question will immediately be placed in Civil Disorder.

Note that the client does not need to store the current game position, as it can immediately send the commands HLO, NOW, SCO, and ORD to find out the state of the game. All that needs to be stored is the power being played, the passcode as provided by the HLO command, and details of past press and alliances that the client wishes to store.

#### server_message = OFF

This command is sent by the server, and indicates that the client should exit. The client should exit without replying.

### (vi) Deadlines

#### server_message = TME (seconds)

This message is sent by the server, in games where there is a time limit for the turn. It indicates the number of seconds until the next deadline. It is sent immediately after each turn has processed (that is, after the ORD, SCO (where appropriate), and NOW messages).

In addition, the client can request TME to be sent at other times. To do this, the client sends TME (seconds) to the server. The server responds with YES (TME (seconds)) to confirm this, or REJ (TME (seconds)) if seconds is negative, or is longer than the length of the longest deadline, or if there are no deadlines. The server will then send TME (seconds) to the client, seconds seconds before the deadline, every turn.

The client can cancel such requests with NOT (TME (seconds)) for a specific request, or NOT (TME) for all requests. The server will respond with YES (NOT (...)) if the request was canceled, or REJ (NOT (...)) if the specified request was not found or if the server cannot cancel time requests.

Also, the client can send the message TME with no parameters. The server will respond with TME (seconds) where seconds is the time to the next deadline, or REJ (TME) if there is no current deadline.

The client should not acknowledge the TME message from the server.

### (vii) Errors and Failures

#### server_message = PRN (message)

This message is sent from the server to the client, and indicates that message was received from the client by the server, but does not have a correct set of parentheses. The PRN message will also not have matching parentheses; the client should cope with this. No reply should be sent to the server.

#### server_message = HUH (message)

This message is sent from the server to the client, and means that the server determined that message had a syntax error in it. The token ERR is inserted into the message immediately before the first offending token.

This error can also be caused by trying to use a form of the Diplomacy AI Development Environment syntax which is not available at the syntax level for the current game.

The PRN and HUH messages may also be sent from the client to the server, if the client believes that a message from the server is incorrectly bracketed or contains illegal syntax. However, the server and client must not send HUH or PRN in response to a HUH or PRN message.

#### server_message = CCD (power)

This message is sent from the server to the client, and indicates that the specified power has been declared to be in Civil Disorder, because the network connection to the power has been broken, or because the power failed to load a saved game. If the power reconnects, the server will send the message NOT (CCD (power)).

#### server_message = CCD (power) (turn)*

This message is sent from the server to the client, and indicates that the specified power failed to get its orders in by the deadline for the specified turn. However, this does not indicate that the power has been declared permanently in civil disorder, merely that default orders have been issued for that turn.

If the game is of the DSD variant, then when a power disconnects which has not yet submitted orders, then the server sends NOT (TME (seconds)) immediately after the CCD message to indicate that the deadline timer has stopped, and sends TME (seconds) following the NOT (CCD (power)) message when the timer restarts.

### (viii) Admin Messages

#### client_request = ADM ('name') ('message')

This message is sent from the client to the server, and contains an admin message — that is, a message to do with the running of the game (for example, I'm having connection problems, or server going down, or I have to leave shortly). It can be sent by any client — player or observer — and can be sent before, during or after the game. It should not be used for negotiation. The server may interpret the message as a command, or it may forward the message to every client.* The server may be configured to refuse admin messages, in which case it will reply to the client with REJ (ADM ('name') ('message')).

### (ix) End of the game

#### server_message = SLO (power)

This command is sent from the server to the client, and indicates that the game has ended due to a solo by the specified power. It is sent after the SCO message and before the NOW message.

#### player_command = DRW

This command is sent by the player to the server, to indicate that the player would accept a DIAS draw at this point. The server responds with YES (DRW), or REJ (DRW) if the game has not started.

DRW can also be sent from the server to the client, to indicate that a draw has been declared. This will happen as soon as all non-eliminated players have simultaneously indicated that they will accept a draw at that point.

If a turn processes after DRW is sent from the player to the server, then the command is ignored. The player must resend the command each turn if it continues to want a draw.

If the player changes its mind, it can clear its request for a draw with NOT (DRW). The server will respond with YES (NOT (DRW)), or REJ (NOT (DRW)) if the game has not started.

#### server_message = SMR (turn) (power ('name') ('version') centres [year_of_elimination]) (power ('name') ('version') centres [year_of_elimination]) ...

This message is sent from the server to the client immediately after the SLO or DRW message, and informs the client as to who was playing each power. centres is the number of centres held by the player at the end of the game. If this is 0, then year_of_elimination is included, and is the year that the player dropped to 0 centres.

The client can send the command SMR to the server with no arguments at any time. The server will reply by sending another copy of the SLO or DRW message, if any, followed by the the SMR message, or REJ (SMR) if the game has not yet ended.*

## Level 10 : Peace and Allies

In this level, we add some very basic press between players.

### (i) Extending the HLO command.

In addition to the previous variant_options, the following may also be given at the start of the game:

- variant_option = PDA — Partial draws are allowed (that is, NoDIAS).
- variant_option = NPR — No press during retreat phases
- variant_option = NPB — No press during build phases
- variant_option = PTL seconds — number of seconds before a movement deadline that all press between powers must stop. If not specified, then 0.

### (ii) Extending the DRW command

In a PDA variant game, the player can send the DRW command with a parameter — the list of powers in the draw:

#### {PDA} player_command = DRW (power power power ...)

If all surviving powers submit a DRW command with the same list of powers on the same turn, then a draw is immediately declared including those powers.

Multiple DRW commands may be submitted. Each one does not supersede previous DRW messages; instead, it adds an additional draw combination which the power will accept.

The server will respond to each DRW message with YES (DRW (power power power ...)), or REJ (DRW (power power power ...)) if the game has not started, or if the list of powers includes an eliminated power.

When a draw is declared in a PDA variant game, the draw message includes a parameter — the list of powers in the agreed draw.

The player may still send a DRW command without a parameter in a PDA game — it is the same as sending a DRW command listing all surviving powers.

The player can cancel a partial draw request with NOT (DRW (power power power ...)).

### (iii) Sending and Receiving Press

#### client_command = SND (power power ...) (press_message)

#### client_command = SND (power power ...) (reply)

These are sent by the player to the server, to send press_message to the list of powers given. The recipient list should not include the sending power. The message sent applies to the current turn, unless otherwise specified by its contents.

The server will reply with one of the following:

#### server_message = CCD (power) (SND (power power ...) (press_message))*

power is in civil disorder, and so can not receive press. If multiple powers are listed in the SND command, and the server sends a CCD reply, then the message has not been sent to anybody (including the ones that are not in civil disorder).

#### server_message = OUT (power) (SND (power power ...) (press_message))*

power has been eliminated from the game. If multiple powers are listed in the SND command, and the server sends a OUT reply, then the message has not been sent to anybody (including the ones that have not been eliminated).

#### server_message = HUH (SND (power power ...) (press_message))

Syntax of the SND message is illegal. This may be a genuine syntax error, or it may be because press_message contains a token which is not allowed at the language level of the game. ERR is inserted immediately before the first token to cause an error. See HUH in Level 0 for details.

#### server_message = REJ (SND (power power ...) (press_message))

Either the game has not started, or it is a retreat phase in a NPR variant game or a build phase in a NPB variant game, or the press deadline has already passed in a PTL variant game,* or the sending power has been eliminated.

#### server_message = YES (SND (power power ...) (press_message))

The message was sent successfully.

When the message is sent successfully, the target players will receive the message in one of the following forms:

#### server_message = FRM (power) (power power ...) (press_message)

#### server_message = FRM (power) (power power ...) (reply)

The first power is the power which sent the message. The power list and the press_message are as in the SND command.

We have now covered every command in the Diplomacy AI Development Environment syntax. The remainder of this document covers the contents of press_message and reply.

### (iv) Proposing an Offer

#### press_message = PRP (offer)

This indicates that the sending power is proposing an offer. offer can be in one of three forms:

#### offer = PCE (power power ...)

Propose Peace between the listed powers. The list of powers should include the power or powers receiving the message. Eliminated powers must not be included in the power list. This offer is continuous; that is, not just for the current turn.

#### offer = ALY (power power ...) VSS (power power ...)

Propose an Alliance between the powers in the first list. The list of powers should include the power or powers receiving the message. The second list is the powers to ally against. Eliminated powers must not be included in either power list. This offer is continuous.

#### offer = DRW

Propose a Draw. In the case of a PDA game, this may also be DRW (power power power ...). The list of powers does not need to include the powers receiving the message. The list of powers must include at least two powers. Eliminated powers must not be included in the power list.

#### offer = SLO (power)

Propose a Solo to the specified power. Note that a player can't actually order a solo — but it may be able to move its units in a way that causes one to occur.

#### offer = NOT (offer)

All of the available offers can have NOT placed in front of them to mean the opposite. Double negatives should not be used!

### (v) Responding to an offer

To respond to a message, one of the following can be sent:

#### reply = YES (press_message)

Accept the offer

#### reply = REJ (press_message)

Reject the offer

#### reply = BWX (press_message)

Refuse to answer. None of the sending power's business.

#### reply = HUH (press_message)

The message proposal contains a token sequence too complicated for this player to understand — usually because the player is not able to handle all of the tokens available for press at the current level. In this case, the token ERR should be inserted immediately before the first token which could not be understood.

The above responses should only be sent as a response to a received message. press_message should be identical to the received message.

### (vi) Reporting your abilities

If the player sends a response of HUH, it should immediately send a second message informing the other player as to what it can understand. This is done with:

#### press_message = TRY (tokens)

List all of the tokens which the player can process when received in the press_message part of a FRM message. Tokens should be a subset of PRP PCE ALY VSS DRW SLO NOT YES REJ BWX. In addition, the following tokens from higher levels may also be included if they can be processed by the player: XDO DMZ AND ORR SCD OCC CHO INS QRY THK FCT IDK SUG WHT HOW EXP SRY FOR IFF THN ELS XOY YDO FRM FWD BCC SND POB WHY

The player does not need to list TRY or HUH in tokens, and should not send a HUH message in response to a TRY or HUH message.

A player which can not process Press (that is, which is only designed to work at Level 0) should respond to any FRM message with:

- SND (power) (HUH (ERR press_message))
- SND (power) (TRY ())

Where power is the sending power, and press_message is the received message.

All tokens which can be processed by the player may be included in games of any level (so that it can just have a fixed TRY message which it sends if it don't understand something). There is no requirement to remove higher-level tokens from the TRY message in lower-level games. The server will remove all higher-level tokens from the TRY message before passing it onto the receiving power, and may also reorder the tokens.

## Level 20 : Order Proposals

In level 20, we add two new forms for offer.

#### offer = XDO (order)

This is a proposal that the given order be ordered. The order should be for either the sending power or a receiving power. order uses the same format as in the SUB command.

#### offer = DMZ (power power ...) (province province ...)

This is a proposal that the listed powers remove all units from, not build any units in, and not order any units to move, retreat, or support or convoy a move to any of the listed provinces. The powers involved in the DMZ should all be recipients of the message. Eliminated powers must not be included in the power list. This offer is continuous.

Both of these are responded to using the responses in level 10.

## Level 30 : Multipart Offers

Level 30 adds the ability to offer multiple things in one offer.

#### multipart_offer = AND (offer) (offer) (offer) ...

These offers are made as a group, and should be accepted or rejected as a group. This is usually used for offers such as “I support you and you support me.”

#### multipart_offer = ORR (offer) (offer) (offer) ...

These alternative offers are made. The player should accept or reject them as a group, and then use further press (if necessary) to decide which part of the offer is to actually occur. This is usually used for offers such as “I will make one of the following moves.”

At level 30, AND and ORR must not be nested; that is, they must not both appear in the same message, and neither is allowed to appear more than once. All AND and ORR offers must include at least two sub-offers. That is, AND (offer) is not allowed.

## Level 40 : Sharing out the Supply Centres

Level 40 adds the ability to discuss who will gain which supply centres and provinces.

#### offer = SCD (power centre centre ...) (power centre centre ...) ...

The given supply centre distribution is offered. This is typically used when an alliance is sharing out the centres of the powers they are allied against. Any centres not listed are not part of the proposed division. Eliminated powers must not be included in the distribution of centres. This offer is a long-term plan, and doesn't necessarily indicate that the centres will be taken this turn.

#### offer = OCC (unit) (unit) ...

This is a suggestion that a power place a particular unit in a particular location. unit is in the same format as for NOW; for instance, PRP (OCC (ENG FLT BEL)). Alternatively, the token UNT may be used to represent any unit type. For example, PRP (OCC (ENG UNT BEL)). This offer is a long-term plan, and doesn't necessarily indicate that the units will be placed there this turn.

## Level 50 : Nested Multipart Offers

Level 50 allows AND and ORR to be nested. For example:

PRP (ORR ((FRA AMY PAR) MTO PIC) (AND ((FRA AMY PAR) MTO BUR) ((GER AMY MUN) MTO BUR)))

It also adds a new multi-part offer.

#### offer = CHO (minimum maximum) (offer) (offer) (offer) ...

minimum and maximum are integers. This is an offer to accept between minimum and maximum of the listed offers. minimum and maximum may be the same, in which case it means to choose exactly that many. For example:

CHO (2 2) (SCD (ENG NWY)) (SCD (ENG DEN)) (SCD (ENG SWE))
Choose two centres from Norway, Denmark, and Sweden.

## Level 60 : Queries and Insistences

In Level 60, we add the ability to insist on a proposal, and to ask questions.

#### press_message = INS (offer)

The syntax for INS is exactly the same as for PRP, and the available replies are also exactly the same. The only difference is that PRP should be seen as a suggestion, where as INS is much more forceful, and implies that relations between the two powers will be worsened if the offer is not accepted. If offer is something that the sending power can enforce on the board (for example, an order for one of his own units), then the receiving power should expect it to happen whether it likes it or not.

#### press_message = QRY (offer)

The syntax for QRY is the same as for PRP and INS, except that where a power list is included, there is no requirement for it to include the sending or receiving powers. QRY is asking a question (for example, “Is there an alliance?”), rather then proposing — (for example, “How about an alliance?”). QRY can be responded to in exactly the same way as PRP and INS; however, the following extra responses are also available for QRY:

#### reply = THK (QRY (offer))

I think that offer is true.

#### reply = THK (NOT (QRY (offer)))

I think that offer is not true.

#### reply = FCT (QRY (offer))

offer is true.

#### reply = FCT (NOT (QRY (offer)))

offer is not true.

#### reply = IDK (QRY (offer))

I don't know.

Note that for QRY, offer is not really an offer at all, it is a request for information.

#### press_message = SUG (offer)

The syntax for SUG is the same as for QRY, and once again, where a power list is included, there is no requirement for it to include the sending or receiving powers. SUG is suggesting that something is in the mutual interest of the sender and all recipients, but is not something they can directly influence. For instance, Italy may want to say to Austria that it is in their mutual interest for Russia to order to the Black Sea. Replies to SUG are the same as for PRP; however, the response is an indication of agreement or disagreement, rather than an indication as to whether offer will actually happen.

THK and FCT can also be used as a message in their own right, to pass information without first being queried for it.

#### press_message = THK (offer)

I think offer is true.

#### press_message = FCT (offer)

offer is true.

No reply is expected to either of these.

Note that THK (QRY (offer)) and THK (offer) have exactly the same meaning, except that the former is the response to a query whereas the latter is volunteered without being asked. The same applies to FCT (QRY (offer)) and FCT (offer).

## Level 70 : Requests for suggestions

In Level 70, we add the ability to ask for suggestions. Requests for suggestions come in two forms:

#### press_message = WHT (unit)

What should unit be ordered to do? This can either be for a unit of either the sender or a recipient. In the former case, it is a request for a suggestion. In the latter case, it is a request for information.

WHT messages should be replied to using PRP or INS to propose or insist on a move (as if it was an initial proposal/insistence, rather than a response to a WHT), IDK (WHT (unit)) if the receiving power doesn't have a suggestion, or with BWX (WHT (unit)) if the receiving power doesn't want to tell.

#### press_message = HOW (province)

How do you think we should attack province? This should be responded to with PRP or INS to propose or insist on moves, REJ (HOW (province)) to indicate that the province should not be attacked, IDK (HOW (province)) if the receiving power doesn't have a suggestion, or BWX (HOW (province)) if the receiving power doesn't want to tell.

#### press_message = HOW (power)

How do you think we should attack power? Responses are the same as for HOW (province). power must not be an eliminated power.

## Level 80 : Accusations

Level 80 adds the ability to accuse another power of going back on its word.

#### press_message = EXP (turn) (press_message)

#### press_message = EXP (turn) (reply)

Explain your moves in turn given press_message that you previously sent.

The standard replies can be used, including:

#### reply = YES (EXP (turn) (press_message))

#### reply = YES (EXP (turn) (reply))

Yes, I know. (No explanation given.)

#### reply = REJ (EXP (turn) (press_message))

#### reply = REJ (EXP (turn) (reply))

I didn't send press_message.

#### reply = IDK (EXP (turn) (press_message))

#### reply = IDK (EXP (turn) (reply))

There is nothing to explain — they don't conflict.

In addition, the following is available.

#### reply = SRY (EXP (turn) (press_message))

#### reply = SRY (EXP (turn) (reply))

I'm sorry.

Especially after a YES or BWX message, it should be common for the next message to be INS (NOT (PCE (power power ...)).

## Level 90 : Future discussions

Level 90 adds the ability to talk about the future. To do this, one command is added:

#### offer = FOR (turn) (offer)

#### offer = FOR ((start_turn) (end_turn)) (offer)

For the turn specified, or for all turns from start_turn to end_turn inclusive, offer applies. turn is of the form phase year. The timing specified by FOR overrides any timing indicated by offer.

## Level 100 : Conditionals

Level 100 adds the ability to make a conditional offer.

#### press_message = IFF (condition) THN (press_message) [ELS (press_message)]

If the condition is met, then the THN applies; otherwise, the ELS part (if any) applies.

A condition takes the same format as an offer.

IFF can often be used in conjunction with FOR. For example:

IFF (NOT (XDO ((RUS FLT (STP NCS)) BLD))) THN (PRP (FOR (SPR 1902) (XDO ((ENG FLT NWY) SUP (RUS FLT GOB) MTO SWE)))) ELS (INS (FOR (SPR 1902) (XDO ((ENG FLT NWY) SUP (GER FLT DEN) MTO SWE))))

It is recommended that IFF statements always be worded so that the receiving power would prefer the THN part to the ELS part.

## Level 110 : Puppets and Favours

Level 110 adds the ability to trade in favours, and to become a puppet of another power.

#### offer = XOY (power) (power)

Power X owes power Y. The powers listed must not be eliminated.

The amount owed is indicated by the context. For instance, a player may ask for "You support me to X, and I owe you." The amount it owes is the value of the support. This is for when a player is asking for something now, and offering to return the favour later, not yet knowing how it will reciprocate.

#### offer = YDO (power) (unit) (unit) ...

Control of the listed units is given to power. If the owner of the units is the sending power, then it is allowing the named power to decide the orders for those units (which it should do using PRP (XDO ...) ). The orders for the units must still be entered by the owning power. The power must not be an eliminated power.

## Level 120 : Forwarding Press

Level 120 adds the ability to forward press from one power to another. This adds three extra commands to the message syntax:

#### offer = SND (power) (power power ...) (press_message)

#### offer = SND (power) (power power ...) (reply)

This is a request for the first power to send the message given. The sending power (the first parameter) must be a recipient of the message, although there may be other recipients of the request too (who should not act on it or reply to it). Eliminated powers must not be included in any part of the message.

#### offer = FWD (power power ...) (power) (power)

This is either a request or an offer for any messages received from any of the powers in the first parameter to the power in the second parameter to be forwarded to the power in the third parameter. Eliminated powers must not be included in any part of the message. Powers should not appear more than once in the message. For PRP and INS messages, the second and third parameters should be the sending and receiving powers of the FWD message. If the second parameter is the sending power, then this is an offer to forward. If the third parameter is the sending power, then it is a request to forward. The FWD message may be sent to several powers, in which case only the power which appears in the second or third parameters should act on the message. This offer is continuous.

#### offer = BCC (power) (power power ...) (power)

This is exactly the same as FWD, except that the sending and receiving powers are now the first and third parameters. This is an offer or request to forward everything sent, rather than everything received.

#### offer = NOT (FWD (power power ...) (power) (power))

#### offer = NOT (BCC (power) (power power ...) (power))

This is an offer/request to cancel a previously agreed FWD or BCC.

#### press_message = FRM (power) (power power ...) (press_message)

#### press_message = FRM (power) (power power ...) (reply)

This is a message to inform a power of a message the player has sent or received. No response is required. Eliminated powers must not be included in any part of the message. There is of course no guarantee that the forwarded message is genuine.

Care should be taken to avoid message passing loops. In general, a player should not forward a message that already contains the segment (FRM (forwarding power) (power being forwarded to) (press_message)).

## Level 130 : Explanations

Level 130 adds the ability to ask why a power thinks something. In response to a THK or FCT message, the player can reply with:

#### reply = WHY (THK (offer))

#### reply = WHY (FCT (offer))

This is a request for an explanation as to the reason why the sender thinks the offer in the THK or FCT message is true. Available replies are BWX if the player don't want to tell, REJ if it wants to deny knowledge of the THK or FCT message, or another THK or FCT message to give further information. Additionally, the player can also give any other message which gives further information (most notably, a FRM message if it was heard from another player). Finally, there is one new response available:

#### reply = POB (WHY (THK (offer)))

#### reply = POB (WHY (FCT (offer)))

The position on the board, or the previous moves, suggests or implies it.

WHY can also be used in other contexts:

#### reply = WHY (SUG (offer))

Why do you think that would be good for us?

#### reply = WHY (PRP (offer))

#### reply = WHY (INS (offer))

Why are you proposing that?

This level also adds some additional uses of IDK:

#### reply = IDK (PRP (offer))

#### reply = IDK (INS (offer))

I don't know whether I'll accept that. Throw in something else to make it worthwhile.

#### reply = IDK (SUG (offer))

I don't really know whether I desire that.

## Level 8000 : Free Text

This level allows natural language press. Both press_message and reply can be any string of ASCII characters.

## Appendix A : Complete List of Tokens*

The following is a complete alphabetical list of tokens specified in the Diplomacy AI Development Environment Syntax. Token numbers refer to Version 1, Revision 14 of the Client-Server Protocol Document, except for those indicated with an asterisk, which are listed as used by the Parlance framework. Where multiple token numbers are given, Parlance currently uses only the last one listed; the others have been used in previous versions or other sources, and might be found in obsolete software.

Note that this table contains a few tokens not used in this document, for various reasons.

Token | Number | Token Type | Usage | Meaning
--- | --- | --- | --- | ---
ADM | 0x481D | Command | Client <---> Server | Administration Message
ADR | 0x520E | Province | Sea | Adriatic Sea
AEG | 0x520F | Province | Sea | Aegean Sea
ALB | 0x5421 | Province | Coastal | Albania
ALY | 0x4A00 | Press | Offer | Ally
AMY | 0x4200 | Unit Type |  | Army
AND | 0x4A01 | Press | Offer | Logical AND
ANK | 0x5530 | Province | Coastal Supply Centre | Ankara
AOA | 0x4900 | Parameter | HLO | Any Orders Allowed
APU | 0x5422 | Province | Coastal | Apulia
ARM | 0x5423 | Province | Coastal | Armenia
AUS | 0x4100 | Power | Austria
AUT | 0x4703 | Phase |  | Fall Retreats
BAL | 0x5210 | Province | Sea | Baltic Sea
BAR | 0x5211 | Province | Sea | Barents Sea
BCC | 0x4A22 / 0x4A23 * | Press | Offer | Blind Carbon Copy |
BEL | 0x5531 | Province | Coastal Supply Centre | Belgium
BER | 0x5532 | Province | Coastal Supply Centre | Berlin
BLA | 0x5212 | Province | Sea | Black Sea
BLD | 0x4380 | Order | Build Phase | Build
BNC | 0x4501 | Order Note | ORD | Move Bounced
BOH | 0x5000 | Province | Inland | Bohemia
BPR | 0x4401 | Order Note | THX | Server is Processing a Turn (REMOVED)
BRA | 0x4000 | Miscellaneous |  | Opening Parenthesis
BRE | 0x5533 | Province | Coastal Supply Centre | Brest
BTL | 0x4901 | Parameter | HLO | Build Time Limit
BUD | 0x5107 | Province | Inland Supply Centre | Budapest
BUL | 0x5748 | Province | Bicoastal Supply Centre | Bulgaria
BUR | 0x5001 | Province | Inland | Burgundy
BWX | 0x4A02 | Press | Reply | None of Your Business
CCD | 0x4800 | Command | Server to Client | Power in Civil Disorder
CHO | 0x4A23 / 0x4A22 * | Press | Offer | Choose
CLY | 0x5424 | Province | Coastal | Clyde
CON | 0x5534 | Province | Coastal Supply Centre | Constantinople
CST | 0x4402 | Order Note | THX | No Coast Specified
CTO | 0x4320 | Order | Movement Phase | Move by Convoy to
CUT | 0x4502 | Order Note | ORD | Support Cut
CVY | 0x4321 | Order | Movement Phase | Convoy
DEN | 0x5535 | Province | Coastal Supply Centre | Denmark
DMZ | 0x4A03 | Press | Offer | Demiliterised Zone
DRW | 0x4801 | Command / Press | Client <---> Server | Draw
DSB | 0x4340 | Order | Retreat Phase | Disband
DSD | 0x490D | Parameter | HLO | Deadline Stops on Disconnection
DSR | 0x4503 | Order Note | ORD | Convoy Disrupted
EAS | 0x5213 | Province | Sea | Eastern Mediterranean Sea
ECH | 0x5214 | Province | Sea | English Channel
ECS | 0x4604 | Coast |  | East Coast
EDI | 0x5536 | Province | Coastal Supply Centre | Edinburgh
ELS | 0x4A04 | Press | IFF | Else
ENG | 0x4101 | Power |  | England
EPP | 0x490C | Parameter | HLO | Eliminated Power Press (REMOVED)
ERR | 0x4902 | Parameter | HUH | Error location
ESC | 0x4403 | Order Note | THX | Not an Empty Supply Centre
EXP | 0x4A05 | Press | Message | Explain
FAL | 0x4702 | Phase |  | Fall Movements
FAR | 0x4404 | Order Note | THX | Not Adjacent
FCT | 0x4A07 | Press | Message / Reply | Fact
FIN | 0x5425 | Province | Coastal | Finland
FLD | 0x4504 | Order Note | ORD | Move Failed (REMOVED)
FLT | 0x4201 | Unit Type |  | Fleet
FOR | 0x4A08 | Press | Offer | For specified Turn
FRA | 0x4102 | Power |  | France
FRM | 0x4802 | Command / Press | Server to Player | Message From
FWD | 0x4A06 | Press | Offer | Forward Received Press |
GAL | 0x5002 | Province | Inland | Galecia
GAS | 0x5426 | Province | Coastal | Gascony
GER | 0x4103 | Power |  | Germany
GOB | 0x5215 | Province | Sea | Gulf of Bothnia
GOF | 0x4803 | Command | Player to Server | Go Flag
GOL | 0x5216 | Province | Sea | Gulf of Lyons
GRE | 0x5537 | Province | Coastal Supply Centre | Greece
HEL | 0x5217 | Province | Sea | Helgoland Bight
HLD | 0x4322 | Order | Movement Phase | Hold
HLO | 0x4804 | Command | Server to Client | Hello (Start of Game)
HOL | 0x5538 | Province | Coastal Supply Centre | Holland
HOW | 0x4A09 | Press | Message | How to attack
HSC | 0x4405 | Order Note | THX | Not a Home Supply Centre
HST | 0x4805 | Command | Client to Server | History
HUH | 0x4806 | Command / Press | Server to Client | Syntax Error / Not Understood
IAM | 0x4807 | Command | Client to Server | I am
IDK | 0x4A0A | Press | Reply | I Don't Know
IFF | 0x4A0B | Press | Message / Reply / Offer | If
INS | 0x4A0C | Press | Message | Insist
ION | 0x5218 | Province | Sea | Ionian Sea
IOU | 0x4A0D | Press | Offer | I Owe You (REMOVED)
IRI | 0x5219 | Province | Sea | Irish Sea
ITA | 0x4104 | Power |  | Italy
KET | 0x4001 | Miscellaneous |  | Closing Parenthesis
KIE | 0x5539 | Province | Coastal Supply Centre | Kiel
LOD | 0x4808 | Command | Server to Client | Load Game
LON | 0x553A | Province | Coastal Supply Centre | London
LST | 0x4820 / 0x4E02 * | Command | Client <---> Server | Game Listing (Not yet accepted)
LVL | 0x4903 | Parameter | HLO | Syntax Level
LVN | 0x5427 | Province | Coastal | Livonia
LVP | 0x553B | Province | Coastal Supply Centre | Liverpool
MAO | 0x521A | Province | Sea | Mid Atlantic Ocean
MAP | 0x4809 | Command | Server to Client | Map to be used for this game
MAR | 0x553C | Province | Coastal Supply Centre | Marseilles
MBV | 0x4400 | Order Note | THX | Might Be Valid
MDF | 0x480A | Command | Client <---> Server | Map definition
MIS | 0x480B | Command | Server to Player | Missing Orders
MOS | 0x5108 | Province | Inland Supply Centre | Moscow
MRT | 0x4904 | Parameter | NOW | Must Retreat to
MTL | 0x4905 | Parameter | HLO | Movement Time Limit
MTO | 0x4323 | Order | Movement Phase | Move To
MUN | 0x5109 | Province | Inland Supply Centre | Munich
NAF | 0x5428 | Province | Coastal | North Africa
NAO | 0x521B | Province | Sea | North Atlantic Ocean
NAP | 0x553D | Province | Coastal Supply Centre | Naples
NAS | 0x4406 | Order Note | THX | Not At Sea
NCS | 0x4600 | Coast |  | North Coast
NEC | 0x4602 | Coast |  | Northeast Coast
NMB | 0x4407 | Order Note | THX | No More Builds Allowed
NME | 0x480C | Command | Client to Server | Name
NMR | 0x4408 | Order Note | THX | No More Retreats Allowed
NOT | 0x480D | Command / Press | Client <---> Server | Logical NOT
NOW | 0x480E | Command | Client <---> Server | Current Position
NPB | 0x4906 | Parameter | HLO | No Press During Builds
NPR | 0x4907 | Parameter | HLO | No Press During Retreats
NRN | 0x4409 | Order Note | THX | No Retreat Needed
NRS | 0x440A | Order Note | THX | Not the Right Season
NSA | 0x440B | Order Note | THX | No Such Army
NSC | 0x440C | Order Note | THX | Not a Supply Centre
NSF | 0x440D | Order Note | THX | No Such Fleet
NSO | 0x4505 | Order Note | ORD | No Such Order
NSP | 0x440E | Order Note | THX | No Such Province
NST | 0x440F | Order Note | THX | No Such Type (REMOVED)
NSU | 0x4410 | Order Note | THX | No Such Unit
NTH | 0x521C | Province | Sea | North Sea
NVR | 0x4411 | Order Note | THX | Not a Valid Retreat
NWC | 0x460E | Coast |  | Northwest Coast
NWG | 0x521D | Province | Sea | Norwegian Sea
NWY | 0x553E | Province | Coastal Supply Centre | Norway
NYU | 0x4412 | Order Note | THX | Not Your Unit
OBS | 0x480F | Command | Client to Server | Observer
OCC | 0x4A0E | Press | Offer | Occupy
OFF | 0x4810 | Command | Server to Client | Turn Off (Exit)
ORD | 0x4811 | Command | Server to Client | Order Results
ORR | 0x4A0F | Press | Offer | Logical OR
OUT | 0x4812 | Command | Server to Client | Power has been Eliminated
PAR | 0x510A | Province | Inland Supply Centre | Paris
PCE | 0x4A10 | Press | Offer | Peace
PDA | 0x4908 | Parameter | HLO | Partial Draws Allowed
PIC | 0x5429 | Province | Coastal | Picardy
PIE | 0x542A | Province | Coastal | Piedmont
POB | 0x4A11 | Press | Reply | Position on Board
POR | 0x553F | Province | Coastal Supply Centre | Portugal
PPT | 0x4A12 | Press |  | Puppet (REMOVED)
PRN | 0x4813 | Command | Server to Client | Parenthesis error
PRP | 0x4A13 | Press | Message | Propose
PRU | 0x542B | Province | Coastal | Prussia
PTL | 0x4909 | Parameter | HLO | Press Time Limit
QRY | 0x4A14 | Press | Message | Query
REJ | 0x4814 | Command / Press | Client <---> Server | Reject
REM | 0x4381 | Order | Build Phase | Remove
RET | 0x4506 | Order Note | ORD | Unit must retreat
ROM | 0x5540 | Province | Coastal Supply Centre | Rome
RTL | 0x490A | Parameter | HLO | Retreat Time Limit
RTO | 0x4341 | Order | Retreat Phase | Retreat to
RUH | 0x5003 | Province | Inland | Ruhr
RUM | 0x5541 | Province | Coastal Supply Centre | Rumania
RUS | 0x4105 | Power |  | Russia
SCD | 0x4A15 | Press | Offer | Supply Centre Distribution
SCO | 0x4815 | Command | Client <---> Server | Supply Centre Ownership
SCS | 0x4608 | Coast |  | South Coast
SEC | 0x4606 | Coast |  | Southeast Coast
SEL | 0x4821 / 0x4E03 * | Command | Client to Server | Select Game (Not yet accepted)
SER | 0x510B | Province | Inland Supply Centre | Serbia
SEV | 0x5542 | Province | Coastal Supply Centre | Sevastopol
SIL | 0x5004 | Province | Inland | Silesia
SKA | 0x521E | Province | Sea | Skagerrak
SLO | 0x4816 | Command / Press | Server to Client | Solo
SMR | 0x481E * | Command | Server to Client | Summary
SMY | 0x5543 | Province | Coastal Supply Centre | Smyrna
SND | 0x4817 | Command / Press | Player to Server | Send Message
SPA | 0x5749 | Province | Bicoastal Supply Centre | Spain
SPR | 0x4700 | Phase |  | Spring Movement
SRY | 0x4A16 | Press | Reply | Sorry
STP | 0x574A | Province | Bicoastal Supply Centre | St Petersburg
SUB | 0x4818 | Command | Player to Server | Submit Order
SUC | 0x4500 | Order Note | ORD | Order Succeeds
SUG | 0x4A17 | Press | Message | Suggest
SUM | 0x4701 | Phase |  | Spring Retreats
SUP | 0x4324 | Order | Movement Phase | Support
SVE | 0x4819 | Command | Server to Client | Save Game
SWC | 0x460A | Coast |  | Southwest Coast
SWE | 0x5544 | Province | Coastal Supply Centre | Sweden
SYR | 0x542C | Province | Coastal | Syria
THK | 0x4A18 | Press | Message / Reply | Think
THN | 0x4A19 | Press | IFF | Then
THX | 0x481A | Command | Server to Player | Thanks for the order
TME | 0x481B | Command | Client <---> Server | Time to Deadline
TRI | 0x5545 | Province | Coastal Supply Centre | Trieste
TRY | 0x4A1A | Press | Message | Try the following tokens
TUN | 0x5546 | Province | Coastal Supply Centre | Tunis
TUR | 0x4106 | Power |  | Turkey
TUS | 0x542D | Province | Coastal | Tuscany
TYR | 0x5005 | Province | Inland | Tyrolia
TYS | 0x521F | Province | Sea | Tyrrhenian Sea
UKR | 0x5006 | Province | Inland | Ukraine
UNO | 0x490B | Parameter | SCO | Unowned
UNT | 0x4202 / 0x4A24 * | Press | OCC | Unit
UOM | 0x4A1B | Press | Offer | You Owe Me (REMOVED)
VAR | 0x4E07 | Command | Client <---> Server | Variant Name (Not yet accepted)
VEN | 0x5547 | Province | Coastal Supply Centre | Venice
VIA | 0x4325 | Order | Movement Phase | Move via
VIE | 0x510C | Province | Inland Supply Centre | Vienna
VSS | 0x4A1C | Press | ALY | Versus
WAL | 0x542E | Province | Coastal | Wales
WAR | 0x510D | Province | Inland Supply Centre | Warsaw
WCS | 0x460C | Coast |  | West Coast
WES | 0x5220 | Province | Sea | Western Mediterranean Sea
WHT | 0x4A1D | Press | Message | What to do with
WHY | 0x4A1E | Press | Reply | Why
WIN | 0x4704 | Phase |  | Fall Builds
WRT | 0x4A22 / 0x490C * | Press | SND | With Respect To (REMOVED)
WVE | 0x4382 | Order | Build Phase | Waive
XDO | 0x4A1F | Press | Offer | Moves to do
XOY | 0x4A20 | Press | Offer | X owes Y
YDO | 0x4A21 | Press | Offer | You provide the order for these units
YES | 0x481C | Command / Press | Client <---> Server | Accept
YOR | 0x542F | Province | Coastal | Yorkshire
YSC | 0x4413 | Order Note | THX | Not Your Supply Centre
| 0x0000 - 0x3FFF | Integer | Various | Used for years, number of builds, etc.

## Appendix B : Language Definition*

Embedded in this document, including its comments, is a BNF-like formal syntax specification. The language elements are found in H4 headers, and in B wrappers at the beginning of LI elements. Each has a "word = message" structure, except that it may contain named anchors, it may be prefixed by an option tag wrapped in {braces}, and the operator may instead be "+=" or "-=".

Specifications using the "=" operator are only legal at the given syntax level or above. Those using the "+=" operator are legal at any syntax level, but should be removed by the server at lower syntax levels. Those using the "-=" operator should be removed at all syntax levels. Some specifications use the "!=" operator; they were either legal or under consideration at some point, but are not legal now, and should be ignored while parsing the document.

Specifications with an option tag are only legal when the given option is in effect. Currently, this only includes PDA (partial draws allowed) and AOA (any orders allowed).

## Appendix C : Changes from the official document

The following is a list of differences between this Parlance syntax document and the official DAIDE syntax document:

- All instances of "AI", except those occurring in the phrase "Diplomacy AI Development Environment", have been changed to either "client" or "player", as appropriate. After all, the most frequently-used client is not, in fact, an AI. Many of the second-person pronouns have also been changed, in favor of phrases like "the client" or "the player".
- Several minor grammar changes have been made. These don't affect the semantics, but make it sound nicer. In particular, the oft-misunderstood Latin abbreviations "e.g." and "i.e." have been changed to their English equivalents, even though David almost always uses them correctly.
- The four alternate coasts defined in the protocol are listed with the four cardinal ones. Other software may or may not actually accept them; in either case, they need to be in the document to avoid having future map writers use their TLAs.
- Section (o) under Level 0 has been added, listing the multi-game commands as implemented by the Parlance server. These commands are not guaranteed to be accepted by other servers, particularly with the exact syntax specified here.
- Optional name and version parameters have been added to the OBS command. This was David's response to a somewhat ridiculous idea for allowing observers to send NME messages. Currently, only Parlance is known to send or use those parameters; other servers currently send HUH when the name or version are included, upon which Parlance clients will send the OBS without parameters.
- The map name has been specified as not implying a given starting position. That question has come up at least twice within the DAIDE community, with conflicting answers; this answer avoids problems with recovered games after a crash.
- A recent addition to the AOA specification, "and are for a unit owned by the AI sending the order," has been omitted, because the Parlance server accepts absolutely any order when AOA is specified, even those for non-existent or foreign units.
- This document specifies that a client, not just a player, may send HLO without arguments to request a new copy of the HLO message. Appendix B of the official document contradicts itself on that point. Given that the HLO message contains variant rule information, as well as power and passcode assignments, observers might desire an extra copy.
- SCO and NOW commands sent by clients before the game starts are specified to return copies of the starting messages, in accordance with a statement under the MDF specification. The official document also allows the server to send REJ (SCO) or REJ (NOW) in this case.
- The CCD message has been divided into three distinct message types: One for a disconnected power, one for a power that failed to get orders in on time, and one for responding to a SND command. The second and third cases merely add a second parameter to the CCD message. Other clients have not yet exhibited problems upon receiving these extended commands; the Mapper in particular works fine, if a little confused.
- As with the CCD response to an attempt to send press, a second parameter has been added to the OUT message, listing the failed press command.
- This document specifies that the server may interpret an admin message as a command, instead of forwarding it to other players. This allows Mapper users to send commands beyond the limits of this syntax document.
- A client command to request the SMR message, along with the game result, has been added. This could be useful for a client that joins after the game finishes. Note the Parlance server also has behavior, disabled by default, for listing clients that have taken over positions from clients of a different name and/or version; however, that behavior has not yet been included in this syntax document.
- The PTL variant has been listed as a reason for rejecting a SND command.
- Appendix A is much more complete, including obsolete tokens and token numbers.
- Appendix B describes how the syntax has been integrated into the document as a whole, instead of listing the syntax itself. As part of this, many more syntax items in the main text are prefixed with "label = ".
- This document fails to mark the latest set of changes in underlines and strikeouts.
- This document includes a few other wild ideas, commented out. Some of them have been implemented, and at least one is left over from a previous version of the document.