The single square of the draughts model can be isolated and used to disclose problems in definition. The model should be read in conjunction with the dmt model: draughtssq68sde.dmt in the Models directory associated with DMT072.

This shows one of the squares of the draughts board: square number 68

To load the display it is necessary to execute the Run.e file. Because of the way the model is built, it is not enough to define the position of a single piece, as in

b11 = [6,8];

since the visualisation operates with dependency driven by the lists wpieces, bpieces, wcrowned, bcrowned etc.

/* valid positions for pieces are:
	[1,2], [3,1], [5,1], [7,1], [2,2], [2,4] etc
 and a piece that is placed off the board is at [1000,1000] - initially:
 
 b1 = [2,6];
 b10 = [4,8];
 b11 = [6,8];
 b12 = [8,8];
 b2 = [4,6];
 b3 = [6,6];
 b4 = [8,6];
 b5 = [1,7];
 b6 = [3,7];
 b7 = [5,7];
 b8 = [7,7];
 b9 = [2,8];
 bcrowned = [0,0,0,0,0,0,0,0,0,0,0,0];
 w1 = [1,1];
 w10 = [3,3];
 w11 = [5,3];
 w12 = [7,3];
 w2 = [3,1];
 w3 = [5,1];
 w4 = [7,1];
 w5 = [2,2];
 w6 = [4,2];
 w7 = [6,2];
 w8 = [8,2];
 w9 = [1,3];
 wcrowned = [0,0,0,0,0,0,0,0,0,0,0,0];

*/

An unfortunate aspect of checkcol() is the hidden role for a global variable: blank, that is set to the value "blank" in the actual script:

func checkcol {
        para coord;
        auto ans,i;
        ans = blank;	/* 'blank' is global */

        for (i=1;i<=12;i++){
        if (`"b"//str(i)` == coord)
                ans = black;
                }
        for (i=1;i<=12;i++){
        if(`"w"//str(i)` == coord)
                ans = white;
                }
        return ans;
}


Can move a piece off the square [6,8] by redefining

b11 = [1000,1000];

say: can then move the piece w11 to this square:

w11 = [6,8];

The model works because bgcol in the definition of square68:

window square68 = {
    type: DONALD
    box: [p68, q68]
    pict: "piece68"
    bgcolor: bgcol
    sensitive: ON
};

happens to be the same as bgcolor, as used in the definitions:

colsqr68 is (Square68 == white)? white:((Square68 == black)? black: bgcolor);
A_Piece68 is "fill=solid,color=" // colsqr68;

which are used to determine the colour of the donald circle representing the draughts piece.

If we change the background of the scout window to red, via

%scout
bgcol = "red";

and then move the piece from this square, via

%eden
w11 = [1000,1000];

the hidden problem in the colour definition for the square is disclosed.

Can check the effect of crowning a piece also:

wcrowned = [0,0,0,0,0,0,0,0,0,0,1,0];

This (unexpectedly!) has no effect on the colour of the king dot: kingcol68

This is because there is a dependency of the form:

iscrowned ~> [kingcol68];

but nothing to ensure that iscrowned is redefined when wcrowned or bcrowned is altered. To fix this, we would need to change the definition of 

kingcol68 is (iscrowned([6,8]) == 1)? red: colsqr68;

to the form

kingcol68 is (iscrowned([6,8], wcrowned, bcrowned)==1) ? red : colsqr68;

as in the definition of Square68 with reference to bpieces and wpieces which checkcol does not use explicitly in computing its result:

Square68 is checkcol([6,8], bpieces, wpieces);


A further (unresolved) problem is that there is no layering in DoNaLD, so that when we arrange for iscrowned([6,8]) to be true, the white circle representing the piece may not get displayed beneath the red dot.