Comments by FergusDuniho

Is there any reason for the pawn function to include non-capturing moves since the actual movement is handled by the subroutine?

The function has to handle potential moves, since it is used to determine whether a potential move is legal. Back when functions were used only with the checked subroutine, the pawn function would only have to concern itself with capturing moves. Now that the stalemated subroutine systematically makes a list of every legal move for the purpose of displaying legal moves when a player clicks on a piece, it is important for each function to cover every possible move a piece can make. When a piece has only a function and no subroutine, the function has to cover both potential and actual moves. But when a subroutine is used for the actual moves, all the function has to cover are the potential moves.

This code is designed to show that a string or expression between braces will be evaluated immediately:

set a Adam;
def a1 {#a};
def a2 #a;
print fn a1;
print fn a2;
set a Abel;
print fn a1;
print fn a2;

Here is the output:

Adam

Adam

Adam

Abel

If this is 'Post-Move' code, the Pawn has already landed on the to-square, so that it is no longer empty?

Correct.

verify == captured @;

verify not capture; should also work.

For my understanding: why is it necessary to copy the screen to a variable, before testing it. Is there a problem with writing

capture screen;

When I started what became the GAME Code language, I started with commands, which simply took arguments, and I let arguments be separated by spaces. I added expressions to the language later, and I used Polish notation, which also used spaces as separators, because it was easier to implement than infix syntax with parentheses, and its prefix syntax would be quicker to interpret too, which matters for an interpreted language written in another interpreted language. Because of these choices, it's not easy to distinguish between an expression and a list of arguments. So, instead of letting an expression be used anyplace an argument can be used, only some commands can interpret expressions. These include commands for setting variables or for controlling the flow of the program.

That's now fixed too. When displaying the board from Black's perspective, the CSS uses right and top instead of left and bottom, but I had pasted some code using left and bottom.

The diagram for the rules page alone still has the pieces too big, it seems.

The script is fixed, but the image is cached. If you modify the URL in some way, such as rearranging arguments in the query string, this will stop it from showing the cached image.

The same thing happened to me. The reason why is that the preset lists the sides as "Black White" instead of the usual value "White Black". Although his pieces are white, and he is moving first, it says he is playing Black. This is because the name of Black is being used for the first player in the preset. The author of the preset should correct this to avoid confusion.

This is fixed.

This is fixed.

This is now fixed. After changing how drawdiagram.php uses the scale value, I didn't properly account for pieces that were smaller than 50x50. While David had made the Alfaerie pieces all 50x50, I had not done the same for my pieces, which usually came in various sizes that fit within 50x50. So, I added some code for that.

Game Courier has not been designed to use the scale value while drawing the board. It still uses it only after the board has been drawn, but the script that drew the board was not using the scale value on desktops. So, I corrected that.

Curiously, the board looks better on Game Courier than in the Diagram Designer. So, I may have to modify drawdiagram.php to use the scale value after drawing the board and while drawing the pieces.

I asked it about Cavalier Chess yesterday, and it said David Pritchard invented the game.

To prevent the recoloring of pieces not meant to be recolored, such as Shogi pieces, I stopped assigning values to $originalwhite and $originalblack if the set doesn't already have known colors.

Thanks for reporting this. This is now fixed. It turns out that Kamikaze Mortal Shogi was running older code than Shogi was.

There's a bug with this preset now where when you select a piece to drop no squares are highlighted as legal moves

Thanks for reporting this. It's now fixed.

Very nice that you can simplify your stalemate routine in the fairychess include file

It was more extensive than one routine, and it wasn't about simplifying it. As my previous comment indicated, this was about removing the cause of error in that routine and others with similar code. The problem was that using two separate variables for storing the legal moves had allowed bugs to creep into existing code.

but please don't do it in such a way that it breaks presets of others through changing the underlying behaviour of GAME code or Game Courier.

I kept on top of what needed to be fixed, and I fixed everything in a timely manner. There was some delay in fixing betza.txt, because it is not in the includes directory, and I didn't see the bug report on it until my computer was off, and I was in bed with my Likebook Mars. Now that you're an editor, I suggest that you move betza.txt to the /includes/ directory and replace the other ones with stubs that just include it from the includes directory.

So if you want an array that contains the legal moves as text rather than coordinates, and also contains special moves, just give it a new name, and use it by that name in the user code

What I wanted was for the $legalmoves array to contain all the legal moves, because various stalemated subroutines were using setlegal to build a list of legal moves and then checking whether there were any legal moves by checking the count of $legalmoves with a line like this:

return cond count system legalmoves false true;

The bug I described earlier was caused by splitting the legal moves between two variables. The $extralegal array was a kludge I created for the sake of storing some legal moves as strings while storing other legal moves as coordinate pairs. However, I was combining them into a new array called $legalList for use with forms and JavaScript, and this array listed all legal moves as strings. Creating another array would not have helped with anything.

Generated-code games are now giving an error saying "You may not set $extralegal with setsystem."

That's now fixed. I changed the line setsystem extralegal #xtl; in betza.txt to setsystem legalmoves merge $legalmoves #xtl;. Since $extralegal did not appear in any individual presets using this include file, nothing more needed to be done.

The problems with Hexagonal Chess and Napoleonic Chess are now fixed.

That's now fixed. Since finished games have no legal moves left, $legalmoves was null, and then $legalList got assigned to null, which threw a fatal error a little further down. It now gets assigned to an empty array if $legalmoves is null, which allows things to work correctly.

There may be a problem affecting more than one preset's code, possibly. When I try to move Black pawn e7 to e6 in the following log the preset won't let me for some reason:

I did not encounter the same problem. It could have been a temporary bug I introduced while streamlining how legal moves are stored just earlier today.

Because GAME Code was storing legal moves in two separate variables, and I wasn't always keeping this in mind, the stalemated subroutine in the fairychess include file was returning the wrong result for positions like this one:

It was claiming this was checkmate when the check could be prevented by capturing the Queen with a Pawn or blocking with one on g1. This was because the Pawn moves, which included a promotion, were being stored in $extralegal instead of in $legalmoves, which stored legal moves only as coordinate pairs, and the stalemated subroutine, as well as other similar subroutines, checked only the value of $legalmoves. To keep things simpler, I abolished the $extralegal variable, and I stored all legal moves in $legalmoves as strings using notation, and not as arrays of coordinates. With this change made, I was able to slim down the findmates subroutine to this:

// Finds each mating move in current position.
// Parameters:
// side: which side is moving
sub findmates side:
    local enemyking king mates moves mv;

    if match #side 1 white White first:
        set king #Kpos;
        set enemyking #kpos;
    else:
        set king #kpos;
        set enemyking #Kpos;
    endif;
    set mates ();
    ban none;
    setsystem maxmove 0;
    store main;
    setsystem legalmoves ();
    if not sub stalemated #king:
        set lglmvs $legalmoves;
        foreach move #lglmvs:
            set moves explode chr 59 #move;
            foreach mv #moves:
                set mv trim #mv;
                eval "MOVE: {#mv}";
            next;
            if sub checked #enemyking:
                setsystem legalmoves ();
                if sub stalemated #enemyking:
                    push mates #move;
                endif;
            endif;
            restore main;
        next;
    endif;
    setsystem legalmoves #mates;
endsub;

I did notice and correct one problem after this. It was recording some moves as belonging to the @ piece, which is the piece symbol used for empty spaces. This was because it was running the function for converting to notation as soon as setlegal was called, which happened to come before restoring the position. To correct for this, I had it get the piece type from the destination space if the origin space was empty, and if both were empty to not include the piece type. In the future, it would help to call setlegal only after restoring the position or to explicitly spell out the move if it will be anything out of the ordinary.