If an alias ends with a question-mark (?), it must not contain a plus-sign, and this indicates that the alias (without the question-mark) is to be considered "ambiguous." Ambiguous aliases may not be used in games that use the NO_CHECK rule (the ambiguity will be reported to the player at the time of order-entry). For example, TYR is an ambiguous alias in the standard game map, since it is commonly used as an alias for both Tyrolia and the Tyrrhenian Sea.

If the placeName is preceded on the line by an oldAbbrev and an arrow (->), this indicates that the location being named is a pre-existing location whose abbreviation is currently oldAbbrev. This allows you to completely rename a map location, and/or provide a different standard abbreviation or a different set of aliases. When renaming a location in this way, all existing information about that location (such as adjacencies to this location from other locations) is automatically adjusted to reflect the new abbreviation instead. Note that if you wish to rename a multi-coast space, every coast must be separately renamed. That is, if the map defines SPA and SPA/SC and SPA/NC, it is not sufficient to simply rename SPA; separate rename directives must also be given for the coastal regions or they will retain their original name, abbreviation, and aliases.

If the terrain is AMEND, all pre-existing data for the abbreviation (from an earlier such line) will be retained, and the adjacency information given on the line will modify that which is already on record. If an area listed to the right of ABUTS begins with a dash (-), then the area is removed (if possible) from any pre-existing list of adjacencies for the location in question.

In all other cases (that is, if the terrain is not AMEND), the adjacency information given on this line will silently supplant (become valid instead of) any previous such line for the same location. In this way, maps can be changed on the fly, such that what was a LAND location can become COAST or WATER and/or can obtain different adjacencies.

The abut locations must be the DPjudge standard abbreviations (the first abbreviation given after the equals-sign in each placename line).

Specifying Army and Fleet Restrictions
This directive is case-sensitive. Army and fleet restrictions are specified by use of upper- and lower-case as described below. Everything must be in upper-case except the following:

• The abbreviation for any COAST location that a fleet cannot occupy must be listed entirely in lowercase. For instance, on the standard map, Spain must be listed as spa since fleets may only occupy either SPA/SC or SPA/NC. Specifying a location using lower-case after the same location was given earlier using upper-case, or vice-versa, will cause the previous location's terrain type and adjacencies to be forgotten (or, in the case of AMEND, will cause the previous location to be converted to the new casing, and its adjacencies preserved so they can be modified by the AMEND directive).
• In the list of adjacencies, any location that a fleet could occupy but into which a fleet cannot move from the location in question must be listed entirely in lowercase. For example, on the standard map, Tuscany must be listed as tus in the list of locations adjacent to VEN, since a fleet cannot move directly from Venice to Tuscany.
• In the list of adjacencies, any LAND or COAST location to which an army cannot make a direct (non-convoyed) move from the location in question must be listed with its first character in uppercase and the remainder in lower-case. This is useful to specify offshore islands, and therefore no example on the standard map can be given. Consider, however, allowing an army to be convoyed into the Tyrrhenian Sea (call it Sicily). To implement this, the Tyrrhenian Sea would be given the terrain type PORT (to allow both fleets and armies to occupy the space and to allow fleets in that space to convoy) and all land spaces adjacent to the Tyrrhenian Sea would list their adjacency to that space as Tys (rather than TYS or tys) to indicate than an army may not move directly to the space despite the fact that movement from a COAST (such as Naples) to an adjacent PORT (the Tyrrhenian) would otherwise be allowed. Convoyed movement would be allowed, though, so an order such as A Nap-ION-TYS would be perfectly valid.

Specifying Multi-Coast Spaces

• If an area abuts a multi-coast province, its adjacencies must list only the coasts that are reachable, and must not list the main space itself (for example, RUM is listed as being adjacent to BUL/EC, but not to BUL itself).
• The line for every coast of a province should appear in the map file before the line for the space itself.
• If the map will undergo terrain changes during play, it is important to note that the fleet-friendly space listed last is the one on which a unit in that space will be put if a terrain modification requires it. For example, if a fleet is in Rome when Venice becomes a WATER space, the map file will need to direct that Rome becomes a multi-coast province by adding entries for ROM/EC, ROM/WC, and rom. By listing ROM/WC after ROM/EC, the fleet in Rome will be placed on the west (rather than the east) coast.

Power Restrictions and One-Way Adjacencies
An abut location (appearing to the right of ABUTS) may optionally be preceded by one or more power abbreviations, separated from the location abbreviation by a colon. This indicates that movement across the adjacency is only allowed for units owned by the listed power(s). For example,
     COAST SPA ABUTS EI:NAF
indicates that an English or Italian unit in Spain may move directly to North Africa (and may support actions in North Africa). Units owned by other powers do not have this capability. Power abbreviations are not necessarily required before the colon; if none are given, the adjacency will be essentially impassable by all units. This is useful to set up one-way adjacencies, such as the following example:
     WATER SKA ABUTS BAL
     WATER BAL ABUTS :SKA
This indicates that a unit may move from Skagerrak to the Baltic Sea, but not vice-versa. Without the :SKA, the map would be declared to be in error, as one-way adjacencies are otherwise illegal.

Center Ownership Restrictions
Further restriction on the power eligible to use an adjacency may be made by supplying any number of comma-separated supply centers in a parenthesized list at the end of the abut location. For example,
     BLA ABUTS AEG(CON,SMY)
indicates that a unit in the Black Sea is adjacent to the Aegean Sea if and only if the power that owns the unit also owns both Constantinople and Smyrna.

Special Restrictions
After considering any power and center ownership restrictions that may be given, then if an area listed to the right of ABUTS begins or ends with any non-alphabetic character or characters, all such characters specify restrictions on the adjacency (these are special restrictions; beyond those covered by the upper- and lower-case rules listed above). The recognized restrictions are as follows:

~ (tilde) [implementing weak movement across straits]

1. Support cannot be offered across the adjacency.
2. Movement across the adjacency has no strength (except that given by any supporting units). This means that even if the move is made with one valid support, a unit HOLDing at the destination will not be dislodged. This also means that an unsupported move across the boundary will not cut any support being offered by a unit at the destination.

* (asterisk) [implementing the Cape of Good Hope Rule from the 1900 Variant]

1. Movement across the adjacency (to the listed space) is done at half-strength. This includes convoyed movement whose final step is the crossing of the adjacency.
2. Support cannot be offered across the adjacency.
3. Movement across the adjacency does not cut any support being offered by a unit at the destination (unless the move dislodges the supporting unit, of course).
4. Any unit attempting to retreat across the adjacency is destroyed if any other retreating unit attempts a retreat to the destination space (the other unit succeeds in its retreat attempt).

Any and all leading underscores (_) in a powerName will not be displayed when the power is referred to in results and on the graphical map. This is useful to cause powers to alphabetize after others (and thus be displayed in a specific order in the results and on the graphical map).

A plus-sign (+) appearing anywhere in the powerName indicates that the next character in the name is to be displayed in upper-case. Any plus-sign appearing in the ownWord will be displayed as a space.

If preceded by oldName, which must be the name of a previously defined power, followed by an arrow, that power gets renamed to the new power name.

If the center is preceded (immediately, with no intervening space) by a dash (-), the center is removed (if possible) from any pre-existing list of home centers for the power, and added to the list of unowned supply centers. This allows for locations to lose "home center" status. Factory and partisan sites may also be removed in this same manner.

Multiple lines for a single powerName may be used to handle long lists of centers.

This type of line sets a "current power" such that all following lines (that specify initial owned centers and units) will apply to this power (as opposed to any other) until another powerName directive is encountered.

Claiming New Home Centers
One or more center may be specified as &SC and each of these indicates that the power will be eligible to build in one owned non-home center; once having done so, that center will permanently become a home center for that power. Note that such a "claimed" home center may even be a center that also serves as a home center for another power (whenever it is under that power's other control).

Building in Non-Supply Centers
If the center is preceded (immediately, with no intervening space) by a plus-sign (+), the location is not a supply center, but the power will be eligible to build there. This type of location is referred to as a factory site.

Conditional Building in Non-Supply Centers
If the center is preceded (immediately, with no intervening space) by an asterisk (*), the location is not a supply center, but the power will be eligible to build there if and only if the power owns at least one, but not all of his original home supply centers. This type of location is referred to as a partisan site.

Alternative Home Centers
An alternative home center is a supply center where you may build if you forego building in a normal owned and open home center. Otherwise stated, it increases the number of build centers, but not the number of builds. Say you have 3 home centers and 1 alternative home center, all open and owned by you, that would allow you to build 3 units in any 3 of the 4 centers. To indicate an alternative home center, precede the center with an at sign (@). To restrict its usage to a subset, list the home centers between round brackets and separated by commas immediately after the center name. E.g. @CAL(NYO) designates CAL as an alternative to NYO only.

Hiding Builds
When a center is preceded by a tilde sign (~), any unit built there is only revealed in the results of the next movement turn. The adjustment results will simply state BUILD HIDDEN and no unit will be displayed on the map. See also the HIDE_BUILDS rule for applying this effect to all builds for all players. This sign can be combined with other signs if you want to apply more than one special property to the same center, as in ~@CAL(NYO).

The word NEWYEAR can be used as a season, and has a special meaning. A flow may contain one or more NEWYEAR directives, which instruct the game when to modify the game-year. A simple NEWYEAR will increment the year game-by one, and NEWYEAR:5 (for example) will increment it by five. Any flow that does not include a NEWYEAR directive will increase the game-year by one after the final phase in the FLOW.

The word IFYEARDIV can also be used as a season, and also has a special meaning. This word will cause the game's next phase to be set to the first phase in the flow if the game-year is indivisible by a specified number. For example, the flow descriptor IFYEARDIV:10 means that the flow will continue normally only if the game-year is divisible by ten. Otherwise, the initial listed element of the FLOW will be next. The divisor may also include a modulus. For example, IFYEARDIV:2=1 means that the flow will be reset (to its first listed element) if the game-year is even, and will continue normally if the game-year is odd.

When any phase that is not supported by the DPjudge code is current, all players will be shown the "waiting for processing" notice on their Webpages, and it will be up to the Master to advance the game to the next phase using the PROCESS command sent to the e-mail interface. (Deadlines will still be in force for these phases, however.)