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:
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.