Diplomacy Map by Joe Campbell: fnord@evilgeniuses.org Ankara Armenia Constantinople Moscow Sevastapol St. Petersburg Syria Ukraine Livonia Warsaw Prussia Silesia Berlin Kiel Ruhr Munich Rumania Bulgaria Greece Smyrna Albania Serbia Budapest Galacia Vienna Bohemia Tyrolia Trieste Finland Sweden Norway Denmark Holland Belgium Venice Piedmont Tuscany Rome Apulia Naples Burgandy Marseilles Gascony Picardy Paris Brest Spain Portugal North Africa Tunis London Wales Liverpool Yorkshire Edinburgh Clyde North Atlantic Ocean Norwegian Sea Barents Sea Gulf of Bothnia Baltic Sea Skagerrak Helgoland Bight North Sea English Channel Irish Sea Mid-Atlantic Ocean Western Mediterranean Gulf of Lyon Tyrrhenian Sea Adriatic Sea Ionian Sea Aegean Sea Eastern Mediterranean Black Sea Switzerland swi adr aeg alb ank apu arm bal bar bel ber bla boh bre bud bul bur cly con den eas edi eng fin gal gas gre bot lyo hel hol ion iri kie lon lvn lvp mar mao mos mun naf nap nao nth nwy nwg 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 jDip

in Work - DATC Compliance

DATC Compliance Statement

jDip is fully 2000 rulebook/DATC compliant with version 2.4 of the DATC. The DATC (Diplomacy Adjudicator Test Cases) is a document that contains guidelines for rule interpretation and test cases to validate rule interpretations, ensuring accurate adjudication.

The 2000 Rules are followed, and form the basis of the adjudicator.

The 2000 rules, however, are not clear in all cases. In cases where the 2000 rules are not clear the preferences in the DATC are strictly followed. These are outlined in DATC Section 4. Clarifications of preferences between jDip and the DATC are provided below.

How to Check Compliance

All DATC test cases, along with additional adjudicator test cases, are available in the jDip source distribution (see the Download section), and by CVS. See the Getting Started document for more information on how to download and setup the jDip programming environment.

Once setup, the test suites may be run with ant. There are two targets: ant testadj and ant testadjlogged. The test target with logging will create detailed output regarding the evaluation of each tested case.

DATC Section 4 Clarifications

4.A.2. CONVOY DISRUPTION PARADOXES

2000 Rules are used; when paradoxes are detected, they are resolved with the Szykman paradox resolution rule. This is the preferred method of the DATC.

4.A.6. CONVOY PATH SPECIFICATION

Path specifications are allowed but not required. No specification of a path is preferred. If no path is specified, any valid path will be used, and all paths must fail for a convoy to fail. However, if a path is specified, and fails, the convoy will fail, even if other paths exist. This allows maximum flexibility yet allows compatibility with older systems of adjudication.

4.A.7. AVOIDING A HEAD TO HEAD BATTLE TO BOUNCE A UNIT

The preferred approach (“b”) is used. To quote from the DATC:

A dislodged unit has only no effect on the area where the attacker departed from, when it was engaged in a head to head battle (DPTG). This resolution is more natural, because before the unit was dislodged it was already engaged in a fight with the third unit and bouncing it. From the rulebook point of view, it can be defended by saying that swapping two units with a convoy, is a special rule which makes an exception to the other rules. This exception also includes the possibility of bouncing a unit, even when it is dislodged.

4.D.3 through 4.D.6. TOO MANY AND TOO FEW ORDERS

The jDip GUI does not allow a multiple orders per unit or per province. When entering orders using the GUI or typing them in, the last order for a unit will be used, replacing a previous order for a unit. This makes the most sense for the interface. See 4.E.2 for details on how legal orders are interpreted.

Note that the core adjudicator routines of jDip may be used by other programs. Such programs may create multiple orders for a single unit or province. When multiple orders exist, the core adjudication routines will do the following:

4.D.3. MULTIPLE ORDERS TO THE SAME UNIT

jDip will use the last order for a unit, whether legal or not. it is up to the user of jDip core routines to ensure that there is one order per unit.

4.D.4. TOO MANY BUILD ORDERS

If multiple builds are specified, the first legal builds are used (as per DATC).

4.D.5. MULTIPLE BUILD ORDERS FOR ONE AREA

The first legal builds for a specific area are used (as per DATC).

4.D.6. TOO MANY DISBAND ORDERS

The first legal disband orders are used (as per DATC).

4.E.1 and 4.E.2. ILLEGAL AND POORLY WRITTEN ORDERS

jDip goes through tremendous lengths to both try and interpret orders typed in (verses those entered with the mouse), and make sure they make sense within the context of the current situation. This is as per the DATC.

By default, jDip only allows legal orders to be entered. However, order legality checking can be disabled. In this case, only one order per unit will be allowed but orders that do not make sense (e.g., non-adjacent non-convoyed moves) can be entered. This is useful in no-press games, for example.

In either case, orders are always checked for legality during adjudication, since adjudication cannot occur without a set of legal orders.

4.E.3. IMPLICIT ORDERS

Implicit orders are not supported.

4.E.4 PERPETUAL ORDERS

Perpetual orders are not currently supported.

4.E.5. PROXY ORDERS

Proxy orders are not currently supported.

DATC Section 7: Colonial Variant

The Colonial Variant is not supported in the current version of jDip. When the Colonial Variant (and associated rules) are supported, compliance with Section 7 will be re-evaluated.

Search