Comments/Ratings for a Single Item

Hopefully I have implemented it correctly.

It works, but not always, as the captured pieces show.

[Edit] I have now played a few games where there were no problems.

[Edit, Edit] Now another game with captured pieces. 

'Captured pieces' are something that Game Courier shows automatically, but has no effect on the playing of the game. What is shown is not controlled by any user-supplied code; it is just the difference between what is on the board now, and what was there at the start of the game.

While captured pieces are shown automatically, this can be controlled in the code if the default manner of handling captured pieces does not fit with the rules of the game.

Ah. Anyway, since what is shown does not affect the game, I don't understand what the problem is.

If I understand correctly, no captured pieces may be displayed (and removed from the board) in Game Courier, as all captured pieces are added to the capturing party (in Conquer, of course).

Well, I don't know what is the purpose of displaying the captured pieces; as I said, displaying them has no effect on processing of the game by Game Courier, and in most variants it is mostly redundant information, as what was captured can be deduced from what is still left on the board. So one suspects that it is merely a visual aid to the players and observers to easily see the material balance.

The way GC calculates it (difference between current and initial board population) does not make it perfectly suited for that purpose, though, since pieces can disappear from the board in other ways than capture. In particular, after a promotion it would count the Pawn as 'captured', even if no Pawn was captured at all, and it would no longer show the resulting Queen as captured, even if a Queen had been captured. And it has no provision for indicating a negative difference if the original Queen was still around.

In a game like Conquer a negative material balance will occur quite often. If a visual aid for judging that balance should probably show the difference between the white and black population of the current position, presenting negatives as pieces of the opposit color. According to Fergus it should be possible to overrule the default presentation with GAME code, but I would not know how, and I don't think it would be worth it anyway.

I understand that, but the following simple situation can't be right:

Instead of 32 pieces, there are now only 31 pieces on the board. That doesn't fit with Conquer.

Instead of 32 pieces, there are now only 31 pieces on the board. That doesn't fit with Conquer.

Given the rules of the game, you need code for processing the captured piece after it is captured. When a capture has been made, I think you want to add the captured piece to the origin square of the piece that moved and flip its side. You should do this for both actual moves and potential moves. You would also want to turn off the display of captured pieces with this code in the Pre-Game section:

setsystem capturedpieces false;

I understand that, but the following simple situation can't be right:

Indeed, that cannot be right. The code that was appended to the Post-Move sections should have placed a white Pawn on d4 in this case, as 'victim' was not empty (@) here, but a black Pawn.

If you would post a link to the preset, I can try to debug it.

I am grateful for the code to turn off the display of captured pieces - I added it and it works.

...I think you want to add the captured piece to the origin square of the piece that moved and flip its side. 

This is exactly the goal of Conquer. Unfortunately, I have no idea what the required code should look like - I'm not a programmer ( you remember: 'That's a part of life. We don't all have the same capabilities or inclinations').

Do you have any idea what the codes might look like? Would be nice if.

It would look like a simpler form of what Shogi does, as it would move the piece to an already identified space.

if capture:
  set mynewpiece flipcase realname alias $old;
  add #mynewpiece $origin;
endif;

This should work if you're not using aliases:

if capture:
  add $old $origin;
  flip $origin;
endif;

It looks like the code for Shogi omits doing this in the stalemated subroutine, as moving a captured piece off-board does not affect whether the move leaves the King in check. If your game had check in it, you might have to deal with this in the stalemated subroutine. But since you don't have check, maybe putting the piece back on the board will not affect the evaluation of which moves are legal. In that case, it may not be essential to deal with it during the simulation of potential legal moves.

But since you don't have check, maybe putting the piece back on the board will not affect the evaluation of which moves are legal. In that case, it may not be essential to deal with it during the simulation of potential legal moves.

Indeed, this is exactly why it is sufficient to just do this at the very end of Post-Move. The preset was automated through the betza.txt include, not by fairychess.txt, so it needs different code to do that from what you give.

I run into a problem that I don't understand, though. The code I suggested, which Gerd put in the preset, relies on the variable 'victim' to contain the captured piece. But printing it shows it is always equal to @ at the end of Post-Move. Even when I print it directly after the only place in betza.txt where it is set:

  set victim cond != #desti #ori space #desti @; // no self!
print . #ori . , . #desti . , #victim;
print space #desti;

it prints @, both for #victim and space #desti:

d2,d4,@
@
e7,e5,@
@
d4,e5,@
@

But how can space #desti be @ on d4-e5 if the preceding move was e7-e5? I would have expected a Pawn there. The checkbox "Do Not Include Moves in Code" is ticked in this preset, so the Pawn should still be there.

it prints @, both for #victim and space #desti:

If space #desti is @, then victim will be set to @ no matter whether #desti and #ori are the same, because the cond statement will evaluate to @ either way.

But how can space #desti be @ on d4-e5 if the preceding move was e7-e5? I would have expected a Pawn there. The checkbox "Do Not Include Moves in Code" is ticked in this preset, so the Pawn should still be there.

Since your automatically generated code runs mainly in the Post-Game section, it works very differently than the code I usually write. I think Conquer would be simple to program in the usual way with the fairychess include file, but maybe it's not as simple for your automatically generated code.

It should be fixed now; it had to do with the betza.txt script treating normal capture of a piece that could be e.p. captured also as e.p. capture, which removed the victim before the destination square was examined for its occupant. I now made sure the destination square is never included in the e.p. squares, when e.p. rights are created.

This makes the problem go away, but it would still not 'recruit' an e.p.-captured Pawn (where the destination square is empty). So we need to expand the code appended to the Post-Move sections a bit, by having it start with the line:

set victim cond #imp p #victim;

This makes the victim a pawn (p) for any move with implied side effects. (Which here are only e.p. captures.)

Is there a way to make stalemate a win for the stalemated player?

Is there a way to make stalemate a win for the stalemated player?

Currently not. Is this needed? It would not be difficult to add. Unfortunately not in a backward-compatible way that is also logical, as currently the stalemate result is controlled by a GAME-code variable staledraw, shich by default is set to 1, and specifies a draw for any non-zero setting. When set to 0, it makes stalemating a win. I could make it suche that setting it to a negative value makes stalemating a loss.

Is this needed?

Not really. I was just looking and thought it should have been there. I don't know of any games that actually use it though.

The Duke of Rutland's Chess is one CV where stalemating the opponent results in losing the game:

https://www.chessvariants.com/historic.dir/rutland.html

P.S.: It may be an interesting idea for this CVP website for members (and/or editor[s]) to tag games where stalemate is either a win for the player giving it, and/or a loss for the player giving it. Baring an enemy king seems to be always a win if opponent cannot retaliate next move (if not a drawn case like for some chess endgames), and a tag for such might be considered too [edit: Losing Chess is close to being an exception].

Chaturanga, Misère, Anti-chess, Codrus Game, Take Me Chess, Duck Chess, couchtomato's variants shared in Discord at 14/11/2021 & 23/04/2022 (these 2 might be a mistake tho), Quinquereme Chess, Teutonic Knight's Chess, Mainzer Schach, Ghostarelay, etc.

I was aware of Duck Chess, but because this needed an alternative search routine in the AI of the Interactive Diagram, I just hardcoded the rule there. And the generated GAME code would not work anyway, as it is a multi-move game. (And it is a 'never happens' case there anyway.)

In the ID the obvious way to specify it would be staleMate=loss. In the GAME code I could make it configurable through staledraw = -1, and make the Play-Test Applet generate that when it was specified in the ID. There would have to be a pull-down menu on that page for configuring the stalenate result then; a checkbox would no longer be enough.

BTW, the only practical consequence of this rule seems to be that some KPK end-games with edge Pawn can now be won. Usually not even the strong side cannot force the weaker opponent to stalemate him, and having stalemate a draw is already enough deterrent for the strong player not to do it. Losing Chess is of course an exception to this, as even a weak player can force a lot because of the mandatory capture.

This page really needs a button or link (somewhere in the last two paragraphs before "Alternative code for handling the mouse") to send to a blank GC preset page in a new window.

I have wondered if a blank GC preset page (or Settings File) exists or can be created (page not being quite the right word for it, though I don't know what is, other than just calling it a preset, period). Except for the first one ever made, after Fergus made Game Courier, when there were zero presets. I have always just altered a preset made by someone, including myself, to begin making a preset for a CV of mine.

That's probably the easiest route currently. But if a blank one isn't possible, maybe the link can go to a preset for orthodox chess.