Comments/Ratings for a Single Item

2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one;

I never tried to publish a GC preset, but it seems to me that the diagram that is shown on that page is entirely the responsibility of the user. So if it doesn't show the same pieces as what the actual preset uses, it is because you ordered it to show different pieces.

You could even use an Interactive Diagram on that page, instead of a static one from the Diagram Designer. I recall that I made such a substitution on several GC pages, for variants that only appeared to exist on this site as GC presets, without a real article describing the rules. (Matts Winther's variants are typically presented like this; the GC page links to his own website for the rule descriptions.)

I agree that in most cases this page is entirely redundant, and just an annoyance to the user. There might be a reason for it if the same variant has multiple presets with different piece representation, to give the user a possibility to pick the representation he prefers.

This is just a testimony. I'm not a champion in coding and sometimes I don't understand 100% of what I'm doing, but the Wizard is really very good to generate a game code for GC. I have done it for Bigorra, for Camel Decimal Chess and yesterday for Patchanka. The only difficulty I had is when I have several different promotions to manage. I had to use the "morph" instructions and this is not given automatically by the Wizard. I solved my difficulty by copying from the Bigorra's GC where that issue had been solved for me by someone else.

What I found strange in the full process of submitting a new game with "all features inside" is to write 1) a regular page for presenting the game (in which I now put the ID in the Setup section) like this one; 2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one; 3) the preset itself where the Wizard is helpful indeed, like this one.

Maybe the process could be simplifed a bit, for instance I'm not sure that the page 2) is really useful.

I do not discard also that I'm doing something not optimal. I have often the feeling that Fergus, HG you are doing your best to help us (and you do it very nicely and kindly) but you do not always realize how much things looking simple for you can be difficult for common people with no specific education in coding.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

That could be done, or just take the text "Invoke the preset" and add "(click here to start)" or some such. The simipler the better.

The Wizard generates GAME code. It does not create a preset.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

Is it actually less important of a step than using the Play-Test Applet, which does have a link?

I never use this Wizard to generate presets, but I presume that using the Play-Test Applet is actually a step in using the Wizard, whereas starting with the default preset is no more of a step in this than having a blank canvas is a step in generating AI art.

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

This page is about using a Wizard to generate a preset for you. It is not about making your own from scratch. For that, I would refer you to the Game Courier documentation and various tutorials.

But it has nothing to do with the Wizard for GAME Code Generation.

Doesn't it? Is it actually less important of a step than using the Play-Test Applet, which does have a link?

Why not just look on the Game Courier page, where there is a link to it?

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

But it has nothing to do with the Wizard for GAME Code Generation. Why not just look on the Game Courier page, where there is a link to it?

That's precisely the link I was asking for. If H.G. would just (please!) put it into the article, I'd find this much, much easier.

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

There is no blank preset, but there is a default one with only default values. Just go to https://www.chessvariants.com/play/pbm/play.php without a query string.

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.

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.

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

Misère, Anti-chess, Codrus Game, Take Me Chess, Duck Chess, That one couchtomato's variant shared in Discord at 14/11/2021 (this one is prob a mistake tho), Quinquereme Chess, Teutonic Knight's Chess, Mainzer Schach, Ghostarelay, etc.

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

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.

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 there a way to make stalemate a win for the stalemated player?

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

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.

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

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.

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.

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:

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

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.

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

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

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.

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

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. 

I am not sure what you men. You did use the Play-Test Applet to create a rule-checkinf GC preset before, not? So just set up a board for normal chess, alter the King move to plain K to get rid of the castling, and ask for the GAME code.

...to go this way I can tell you what you should add to a preset for 'nocastle' chess automated with the Play-Test Applet in order to make it play Conquer.

I would like to go this way, but I can't get any further with the preset for 'nocastle' chess. Where am I wrong?

I'm afraid I won't be able to manage it.

I didn't expect you would, but if you think it is worth to go this way I can tell you what you should add to a preset for 'nocastle' chess automated with the Play-Test Applet in order to make it play Conquer. In particular at the bottom of the Pre-Game section you can add

set checkrule 0;

to indicate that the king can be exposed and must be captured to win. Then at the bottom of the Post-Move 1 section you can try

if != @ #victim:
  set victim toupper #victim;
  add #victim #ori;
endif;

and to the Post-Move 2 section the same with tolower instead of toupper. I think that should do it.

Sounds very promising. But I'm a little unsure about your [edit]; '...and set the parameter checkrule to 0 at the end of the Pre-Game section. And then add a few lines of custom code at the end of the Post-Move sections for automatically placing the color-flipped capture victim on the square of origin.'

I'm afraid I won't be able to manage it.

When I test this GC, every time I move one piece, I have to wait about 6 seconds before I can move a piece from the opposed side. Do you know why it is so long? Is that because the board is large and there are many pieces?

Indeed, because of the generality the GAME code generated by the Play-Test Applet is not very fast, and for huge games this can become very noticeable. When used for playing a game on-line between two different people 6 sec processing time for a move is not really a problem. When playing against yourself for testing I can see it would be a nuisance. Game Courier does impose a time limit on the processing of a move by the GAME code, though, and when we would exceed that limit the preset would no longer work.

Most time consuming is usually the move highlighting; the GAME code always calculates all moves of all pieces in the latest position, in order to hide a list of those in the page the user gets to see after having submitted a move. So that when he clicks a piece on that page the moves of that piece can be highlighted instantly, without further communication to the CVP server. But it is wasteful, as of all pieces usually just one will be clicked, and the moves of all othe pieces would have been generated in vain. Especially with fully legal highlighting (which I think is the default) preparing the move list is a lot of work, as every possible move has to be tested for exposing the King, which it must do by generating all opponent moves after the move has been made. So if each side has ~100 moves, it will need to generate ~10,000 moves in total to figure out which of the 100 moves are legal. (Of course most moves would not expose the King, but you can only know that after you have tried all opponent moves, because any you haven't tried yet could still hit the King. When a move is illegal you could discover that much sooner, perhaps even on the first reply you tried.)

If you are satisfied with pseudo-legal highlighting it would be much faster. You would have to append to the Pre-Game section:

set pseudo 1;

for that. But this would also highlight moves that leave your King in check. Game Courier would still reject those moves, though, if you actually try to play one.

Another time-critical task is detection of checkmate, in positions where you nearly deliver one. This test only has to run until it finds a legal move, but if there are very few of those you will have to judge many other moves before you stumble on the legal one. And for all these moves many opponent moves might have had to be generated before you stumbled on the King capture that made them illegal. In one of Aurelian's games this actually made the preset exceed the time limit, in an unfavorable case. I improved the situation a bit by giving priority to generating the opponent moves of the piece that captured the King on the previous move we tried, but it can still take a long time.

It would be nice if the highlighting could be delegated to an Interactive Diagram in the Game Courier page. The GAME code would then not have to generate a complete list of legal moves, and by generating those locally with the Diagram there would be no need for communication with the CVP server to highlight the moves when the user clicks a piece. So you still would have instant response for that, as the processing time is also small, since only the moves of that clicked piece would have to be tested for legality. But I don't see that happen.

THANK YOU HG. That's great. It works. I think I now have the full GC for Bigorra, thank you for your help.

When I test this GC, every time I move one piece, I have to wait about 6 seconds before I can move a piece from the opposed side. Do you know why it is so long? Is that because the board is large and there are many pieces?

Sorry, my bad. You are correct that you have to use the labels you use for these pieces in the preset (I did not know those, so I used the full names). But in GAME code the operator has of course to preceed both operands, and I wrote the == between them. What I intended to write was

if == #mover T and == 15 rank #desti and == 14 rank #ori: add DW #desti; endif;

It doesn't work.

I've tried

if #mover == TROLL and == 15 rank #desti and == 14 rank #ori: add DIREWOLF #desti; endif;

and

if #mover == T and == 15 rank #desti and == 14 rank #ori: add DW #desti; endif;

None of them works. The GC can be played but the Troll doesn't get promotted.

For the Troll you can leave it out of the morphers array, and append to the Post-Move 1 section something like:

if #mover == TROLL and == 15 rank #desti and == 14 rank #ori:
  add DIREWOLF #desti;
endif;

and in the Post-Move 2 the corresponding code for black:

if #mover == troll and == 0 rank #desti and == 1 rank #ori:
  add direwolf #desti;
endif;

I've tried it on few pieces for Bigorra (Knight, Camel, Giraffe) and it seems to work. I will try with more later. I will have to see how to deal with the Troll after this. Thanks

My apologies for those who might have already tried to use this feature: I changed it again, in order to simplify the code, and make it more efficient for other purposes the morph parameter has in the Interactive Diagram, namely confining pieces to a board zone. There are now no longer separate morphers and morphs array for each color, but they must be combined into one:

set morphers (X Y Z x y z);
set morphs assoc
  X ((All Q))
  Y ((R N B Q Q B N R))
  Z ((All Q) (All R) (All B))
  x ((All q))
  y ((r n b q q b n r))
  z ((All q) (All r) (All b))
;

The rule that the ranks should be listed starting at the promotion zone (so high to low for white pieces, low to high for black) still applies.

The idea is that a future version would allow you to specify the words 'barred', 'check' or 'win' instead of the label of the piece to promote to; this would then (respectively) ban moves to the corresponding square, treat reaching the square as a check to the opponent (so that he loses when he cannot remove the piece from that square in his next turn, but wins when he captures your King), or terminate the game immediately as a win (without having to worry about possible retaliation against the piece that reached the square, or your King).

I uploaded a new version of the betza.txt GAME-code include file now, which tests for the presence of morph arrays in the HandelMove routines, and performs the promotion instructions these convey for altering the piece type. This works slightly different than mentioned before, because it has to account for the possibility of an asymmetric game, where the black morphs are not automatically implied by the white ones. So the morphs have to be specified for each color separately.

I tested this now, and it looked like it would work on square boards. (Unfortunately GAME code itself is broken for non-square boards, so it doesn't work there yet.)

For the white specification the ranks are now mentioned from high to low, and there will be no morphing on ranks that are omitted. This to save the user the trouble of writing many trailing zeros for all the ranks where nothing happens, if morphing only takes place near the promotion zone. (Which is usually the case.) So the example I gave before should now be specified in the pre-game code as:

set wmorphers (X Y Z);
set wmorphs assoc
  X ((All Q))
  Y ((R N B Q Q B N R))
  Z ((All Q) (All R) (All B))
;

set bmorphers (x y z);
set bmorphs assoc
  x ((All q))
  y ((r n b q q b n r))
  z ((All q) (All r) (All b))
;

Note the double parentheses: the inner pair encloses the square info on a rank, the outer pair encloses a number of ranks (even if only one rank needs to be specified). A bare 0 between the outer parentheses can still be used to indicate a rank where nothing happens. For a symmetric game the black specification only differs from the white one by having all piece labels in lower case, and the array names strating with b instead of w.

A future version of the Play-Test Applet will append this automatically to the generated Pre-Game code for converting any morph parameters that were specified in the converted Interactive Diagram.

I will try to put it in the betza.txt include file tomorrow. Perhaps we should reverse the order in which the ranks are tabulated, starting at the promotion zone. Then you don't have to start with so many zeros. Pieces tend to morph on the far end of the board, and everything beyond the end of the array could be considered a zero, so that you wouldn't have to write so many zeros.

For the Troll I suppose the preset will still need some dedicated GAME code in the Post-Move sections, to suppress the promotion if rank #ori (the rank the piece moved from) equals 12 (or 3). In the ID you can exclude some moves in the Betza descriptor from application of the morph, by suffixing them with a quote. (So the Troll move is G'H'fmWfcF, which would suppress morphing on the G and H move.)

yes, it looks clear. I guess it is not implemented yet because I tried it right now for Bigorra and no promotion occurs.

Question: in the case of my Troll which promotes only when moving 1 square, how it will work?

I suppose a good way for defining how pieces morph into other types upon reaching a certain board square would be the following:

set morphers (X Y Z);
set morphs assoc
  X (0 0 0 0 0 0 0 (All Q))
  Y (0 0 0 0 0 0 0 (R N B Q Q B N R))
  Z (0 0 0 0 0 (All B) (All R) (All Q))
;

In this example X, Y and Z are piece labels of promoting pieces, and the morphers array specifies which pieces can morph. The associative array morphs would then define an array for each of those, to specify on which ranks they morph, and if they do, where on the rank to what. The ranks are tabulated low to high, and a 0 would indicate nothing happens on that rank. If there is morphing, for each square on the rank it is specified to what piece type. Or, if the first element is All (assumed to be not a valid piece label), the second element applies to all squares of the rank.

So the example (for an 8x8 board) shows a piece X that promotes to Q on 8th rank, a piece Y that promotes to the piece that started on the promotion square on 8th rank, and a piece Z that promotes on the last 3 ranks, to B on 6th, to R on 7th and to Q on 8th.

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.

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

Daniel Zacharias wrote on 2022-11-16 UTC

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.

Should be fixed now. Turned out e.p. squares were never cleared until another double push was made. Apparently g8-g6 had been the latest double-push, so when a Pawn then captured to g7... Amazing that no one ran into this problem before.

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.

Some time ago I tried using the game code wizard to make a preset for a large (18x18) game using a few crooked sliding pieces. Now I notice that one of them, the Hornet from Seenschach, works in the applet but not in the generated code. The way I defined it was Wafs(alar)7Wafsal(aral)7WzB. Part of the move works, but the zB seems to be ignored, even though the generated code appears to include those moves as well.

I am not sure that this is feasible. Alice Chess is basically a 3-dimensional variant (with 2 levels), where all pieces have two-leg moves where the seccond leg changes level, and which are lame or (locust-)capturing by their orthodox move in the first leg. But the code in the include file used by the wizard assumes 2-dimensional boards.

Of course you can map the 3d board onto a wider 2d board (16x8, or perhaps 18x8 to allow a dead zone in between the boards that even Knights cannot cross, deleting the squares in that guard zone from the board in the Pre-Game code). And then define all moves as 2-leg moves that have a (dx, dy) = (+-18, 0) leap as second leg. There is no way to describe that in Betza notation, so the Interactive Diagram could not be used to generate the legdefs array with move definitions. But you could of course write that by hand. Either from scratch, or by adapting the code generated for orthodox chess, adding a second leg to each move. E.g. the Bishop in orthodox Chess would have

1 99  1  1     3 // bishop(104)
1 99  1 -1     3
1 99 -1 -1     3
1 99 -1  1     3
0

and this would have to be changed to

2 99  1  1     3 // bishop(???)
   1 18  0     1 
2 99  1 -1     3
   1 18  0     1
2 99 -1 -1     3
   1 18  0     1
2 99 -1  1     3
   1 18  0     1
2 99  1  1     3
  1 -18  0     1
2 99  1 -1     3
  1 -18  0     1
2 99 -1 -1     3
  1 -18  0     1
2 99 -1  1     3
  1 -18  0     1
0

And you would have to determine the new starting index for Bishop in this array, and put it into the B and b function definitions instead of 104.

I am not sure whether this would have the desired effect for castlings and e.p. captures, though. (Or indeed how the latter are supposed to work in Alice Chess in the first place.)

What would be a good method (if there is one) to use this to make Alice Chess?

Indeed. There is no need to generate anything else there than the castlings. And for castlings the code would know that you cannot do those while in check anyway. So you can simply return the index of the castling moves in legdefs in the second case.

it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0.

I don't understand this part. Is it about the number at the end of the K definition? I had the checked check there because the normal King move (with castling and leaping) had different numbers.

For now I have solved this as follows: when a move is indicated as an initial one, it will still be rejected if the mover is not virgin. But if it is, it will be tested whether the mover is in an array inocheck, which by default is set to (K k). If it is, this will add the origin of the move to the set of e.p. squares. And hence consider it illegal if that square is under attack after the move. If you want to forbid any other piece to use inital moves when attacked, or when your royal does not have the label K, or you have multiple royal types, you could set the inocheck array to contain the types you desire.

As dicussed this can in theory fail in the presence of hoppers. Although it is extremely unlikely that you would ever want to play an initial move designed to get you to safety to stay in the path of a hopper. Anyway, it seems to solve the problem with the game you mentioned, as this now says 'checkmate!' above the board. It is also not possible to have both initial moves that can, and that cannot move out of check on the same piece.

About your implementation of that preset: it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0. This call only has to generate moves with an implied side effect, i.e. a change of the board state not explicitly expressed in the move eneterd by the user. This is used when playing out the moves of the game for the purpose of setting up the current position, to make sure the side effects are properly applied, but where there is no need for testing the (pseudo-)legality of the moves. As this would presumably have been done before the move was allowed to be appended to the game. Normally the only moves that do have side effects are e.p. capture and castling. So there is no need to generate other initial King moves than castling in that case; the extra moves you defined do not have side effects.

Thank you. At first I thought I could just override GameEnd and have it check for check before mate, but then it was announcing Check! every move.

This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general

If I understand this correctly, it should work as long as the game doesn't include hoppers. It does seem reasonable to assume that King cannot normally make special moves to escape check.

Is there a way I could add en passant to a leaping move?

Edit I found another solution that seems to work—setting checked to 1 before GameEnd both post game sections.

You cannot use the variable 'checked' the way your code does (in the functions K and k), because the betza.txt include file does the mate test before the check test (which sets this variable). As a result the variable 'checked' is undefined during the mate test, which apparantly is interpreted as not being in check. So the mate test thinks the King, still in its initial position, can use its initial jumps to escape the check, and hence does not see it as mate.

There currently isn't a good alternative. Perhaps all initial moves of a royal piece should be forbidden when in check. Castling is forbidden when in check, but this is implemented as a property of the castling rather than of the fact that it is defined as an initial move. The mechanism by which this is implemented is that castling creates e.p. squares along the path of the King, including the starting square. And that any move to an e.p. square will always (locust-)capture the royal piece, if that was the last-moved piece. (Otherwise only e.p.-capable pieces would perform the capture.) So what really should happen here is that the initial King moves create an e.p. square on the original King location.

[Edit] This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general: a King could make a leap towards a hopper, and therby activate the hopper for capture to the square it just left. While it would not have been in check by that hopper if it had stayed there. For castlings this cannot happen, as there will also be a Rook in between King origin and any piece that would be standing outside of the Rook. Although a bent hopper might be activated by the Rook. An enemy Grasshopper outside of the Rook would attack the Rook after castling, which could lead to the accusation of having castled through check. Or, when the King would end next to the Rook's original square, to moving through check on its destination square, which would no longer be checked after the castling.

In this game which uses generated game code, it seems like there's a problem with detecting checkmate. If I try playing T f5-d8, it's only check, even though black has no legal moves.

I'm having some problems with this game. First, I can't seem to get the piece images to show correctly. Right now it looks ok at first, but when viewing a game from black's perspective it's all wrong again.

Because you're using the Alfaerie:Many set, which includes some flipped pieces, you need to include a value for $flipped. Since you are not using any flipped pieces in your game, you should set it to the same value as you are setting $pieces to.

That would be too bad. But I don't think anyone but Fergus can fix bugs in Game Courier or the GAME code interpreter.

I am not sure about Fergus being available, HG.

This error is weird: the error message obviously comes from the GAME code used to automate the preset, from the move parser. But it seems thise is called in an unexpected context: Game Courier tries to feed the game history to the code in the Post-Move sections twice. And the second time the position has already been changed from the initial one to some weird one, which indeed has a Z on g4.

For debugging I added a statement

printr $space

at the end of the Pre-Game section. When I then use the preset in Play mode, and play the given game, the page that complains about the error contains two dumps of the $space array. The first is the initial position (as expected), but the second is

Array
(
    [a12] => d
    [b12] => l
    [c12] => u
    [d12] => z
    [e12] => o
    [f12] => q
    [g12] => k
    [h12] => o
    [i12] => z
    [j12] => u
    [k12] => l
    [l12] => d
    [a11] => r
    [b11] => m
    [c11] => n
    [d11] => b
    [e11] => a
    [f11] => y
    [g11] => y
    [h11] => a
    [i11] => b
    [j11] => n
    [k11] => m
    [l11] => r
    [a10] => x
    [b10] => i
    [c10] => e
    [d10] => g
    [e10] => s
    [f10] => c
    [g10] => c
    [h10] => s
    [i10] => g
    [j10] => e
    [k10] => i
    [l10] => x
    [a9] => p
    [b9] => p
    [c9] => p
    [d9] => p
    [e9] => p
    [f9] => p
    [g9] => @
    [h9] => p
    [i9] => p
    [j9] => p
    [k9] => p
    [l9] => p
    [a8] => @
    [b8] => @
    [c8] => @
    [d8] => @
    [e8] => @
    [f8] => @
    [g8] => @
    [h8] => @
    [i8] => @
    [j8] => @
    [k8] => @
    [l8] => @
    [a7] => @
    [b7] => @
    [c7] => @
    [d7] => @
    [e7] => @
    [f7] => @
    [g7] => p
    [h7] => @
    [i7] => @
    [j7] => @
    [k7] => @
    [l7] => @
    [a6] => @
    [b6] => @
    [c6] => P
    [d6] => @
    [e6] => @
    [f6] => @
    [g6] => P
    [h6] => @
    [i6] => @
    [j6] => @
    [k6] => @
    [l6] => @
    [a5] => @
    [b5] => @
    [c5] => @
    [d5] => @
    [e5] => A
    [f5] => P
    [g5] => @
    [h5] => @
    [i5] => @
    [j5] => @
    [k5] => @
    [l5] => @
    [a4] => P
    [b4] => P
    [c4] => @
    [d4] => P
    [e4] => P
    [f4] => @
    [g4] => Z
    [h4] => P
    [i4] => P
    [j4] => P
    [k4] => P
    [l4] => P
    [a3] => X
    [b3] => I
    [c3] => E
    [d3] => G
    [e3] => S
    [f3] => C
    [g3] => C
    [h3] => S
    [i3] => G
    [j3] => E
    [k3] => I
    [l3] => X
    [a2] => R
    [b2] => M
    [c2] => N
    [d2] => @
    [e2] => A
    [f2] => Y
    [g2] => Y
    [h2] => A
    [i2] => B
    [j2] => N
    [k2] => M
    [l2] => R
    [a1] => D
    [b1] => L
    [c1] => U
    [d1] => Z
    [e1] => O
    [f1] => Q
    [g1] => K
    [h1] => O
    [i1] => @
    [j1] => U
    [k1] => L
    [l1] => D
)

This is neither the initial nor the current position, although it does have some characteristics of the current position.

Perhaps Fergus can shed some light on how the Pre-Game section could be executed twice when entering a single move in Play mode.

I'm having some problems with this game. First, I can't seem to get the piece images to show correctly. Right now it looks ok at first, but when viewing a game from black's perspective it's all wrong again.

Second, there's this error

ILLEGAL: P g4-g6 on turn 1:

There was no P on g4. The piece on g4 is a Z.

Go back with your browser's BACK button, reload the page, and try again.

For diagnostic purposes, here is the full movelist:

1. P g4-g6 
1... p g9-g7 
2. Z i1-g4 
2... a e11-i7 
3. P f4-f5 
3... a i7-d2; q-dest 
4. A h2-e5 
4... q d2-i7 
5. P c4-c6 
5... q i7-i3 // - check! -
6. E j3-i3

I have no idea what I did wrong

The betza.txt include file for GAME code generated by the Play-Test Applet now also supports crooked and circular pieces (in general 'custom trajectories'). Even in combination with a p or g modifier.

OK, works now.

I just turned on the group write bit for the file. Try it again.

I tried to update the betza.txt GAME-code include file, but I get this error message:

Upload of /home/chessvariants/public_html/membergraphics/MSgame-code-generation/betza.txt
was allowed but failed! The cause of failure is unknown.

Just to be sure: I can use the word 'resign' as a string literal expression > operand without it being confused for a command? Like

if == resign thismove:
 resign
endif;

Yes, but you should include a semicolon after the second line. Without it, this code would result in an error.

Just to be sure: I can use the word 'resign' as a string literal expression operand without it being confused for a command? Like

if == resign thismove:
  resign
endif;

?

OK, thanks. This will make life easier, as indeed I would otherwise have had to break from several levels of subroutines.

Some explanation: the error message was from my own parsing routine. My code works by comparing the input move to all legal moves generated in the position before the move, and it needs a complete description of the move to do that. (Not only the basic move, but also optional freedrops or suicides that occur as (possibly mandatory) side effects.) So I don't rely on move parsing as it occurs when you feed a move primitive to GC through a MOVE: prefix, as this would also change the position, but wrote my own parser that extracts all square coordinates and piece labels from all primitives. Which again is called from another 'do everything' subroutine so that users only have to put a single subroutine call in the Post-Move sections. So if the parser doesn't see a hyphen in a move primitive, it exits through die without any of the primitives having been fed to GC.

What is the recommended way to handle resign (or drawn) in presets that have the checkbox ticked to not include moves in the code?

I don't believe the issue is with that in particular. In tests I just did with Extra Move Chess, resign and drawn worked as they should. Your code does some things differently, which I already mentioned below.

The GAME-code manual says that resign should not be used in code,

That may be a suggestion. I tried it directly in the code, and it did work. It made White resign as soon as he entered his first move.

but when I don't do anything about it, attempts of a user to resign will just draw an 'invalid move syntax' error message.

Is that the precise wording of the error message? Using multiple grep searchs, I did not find any text, PHP, or JavaScript file with code for that error message.

I can of course test for the input command to be 'resign' at the start of the ParseMove subroutine (and for efficiency reasons only do that test on the final move of the sequence, or even defer it to the point where it is rejected as a valid move). But what should I do then?

Yes, it may be a good idea to detect it before processing the move. If you are evaluating moves before playing them on the board, you want to evaluate resign and drawn moves differently. In Extra Move Chess, the code plays each move on the board before evaluating it. This is probably why it has no problem with resign or drawn.

Prefix thismove with MOVE: and offer it for execution?

That's what I would recommend. In general, you should be doing that for every move somewhere in your code.

And what happens to the control flow after that? Will it terminate execution of the remainder of the Post-Move code, or should I explicitly abort execution after it?

The resign, lost, won, and drawn commands all include return, which will exit the run_subroutine() function. This will end the current subroutine, and if the command occurs at the main level, this will end the entire GAME Code program. When moves are automatically included in the code, they are placed at the main level between the Pre-Move and Post-Move subroutine calls. But if you are executing the command from within a subroutine, it will exit only that subroutine, and program execution will continue from the point after that subroutine was called.

I have just modified these commands to exit the program entirely using the same method as the new exit command.

Incidentally, the end and stop commands are not particularly useful here. The end command works only on the main level, and the stop command just returns from the innermost call to run_subroutine(). There is no command for halting program execution from within a subroutine.* The die command uses PHP's exit() function, which exits the whole PHP script, but that's overkill for naturally ending the game. Ideally, you should be using MOVE: at the main level, or when your subroutine comes across resign or drawn, it should exit the subroutine with an error code, and the following code should immediately check whether the error code has been given and take appropriate action at the main level if it has.

* I just added the exit command, which does exit the GAME Code program.

@Fergus:

What is the recommended way to handle resign (or drawn) in presets that have the checkbox ticked to not include moves in the code? The GAME-code manual says that resign should not be used in code, but when I don't do anything about it, attempts of a user to resign will just draw an 'invalid move syntax' error message. I can of course test for the input command to be 'resign' at the start of the ParseMove subroutine (and for efficiency reasons only do that test on the final move of the sequence, or even defer it to the point where it is rejected as a valid move). But what should I do then? Prefix thismove with MOVE: and offer it for execution? Put resign in the code after all? And what happens to the control flow after that? Will it terminate execution of the remainder of the Post-Move code, or should I explicitly abort execution after it?

As this seems a general problem with not including moves in the code, and resigning games seems a universal feature that should never be tampered with, I wonder if it wouldn't be a better solution to exempt resign from not being included in the code, and have Game Courier always recognize and execute it, irrespective of the checkbox setting.

I have now adapted the betza.txt GAME-code include file to use the setjsvar command to pass the start position to the client as a JavaScript variable 'impmoves', and adapted the movepiece.js file that the client can link to to use this variable. This restores the ability to navigate locally through the game history with the aid of the buttons that will appear below the board.

Ah yes, I had been experimenting a bit. Your previous client script was not bothered by this piggy-backed info, because it didn't match any of the square coordinates. Thank you for providing a more regular way to do transfer info. For now I just commented out adding that last element to $extralegal from the betza.txt include file; when I have more time I will try out the new way.

Since my copy of Mighty Lion Chess wasn't handling en passant capture, I updated it to the latest code. After doing so, I was unable to move pieces by clicking on them. This was so both in the code I was testing and in the already-tested stable code. On investigation, I found out that the list of legal moves included the move "zzz,rlbqkbnrpppppppp32PPPPPPPPRLBQKBNR,4". This was screwing things up. Please limit the use of the list of legal moves to properly formatted moves.

In case you need to pass other data to JavaScript, I have just added the command setjsvar. Use this like you would set. It will store values into an associative array keyed to the variable names, and after the program runs, it will write JavaScript variable assignments. It will write numeric values as is, put quotation marks around strings, and JSON encode arrays. It will write the assignments before the legalList assignment, so that you cannot use it to overwrite this variable.

So there is an item ID, a summary and a description. The item ID determines the URL (and I will never repeat the mistake to make that very long!).

Right so far.

The index will list item ID + description, the comment headers will list summary + description. Apparently summary and description are set to the same text when first submitting a new article? It is the summary that can be controlled by the author through the 'Edit index information', as 'Item name'.

I don't think this is right.

The Summary is also called the Item Name, and the latter name is perhaps clearer. The Description is a one-sentence(ish) blurb. The ItemID is a unique permanent identifier, which the URL is also based on. Then there are Index Entries, with a Link Text and Link Description; these are used on search pages (except What's New, which has its own description), and the header on comment threads use the Item Name and the Link Description (???).

When you first submit a page, you provide an Item Name and a Description. An ItemID is created based on that Item Name (generally with a prefix MS, MP, etc. and with spaces replaced with hyphens, etc.). The ItemID is meant to be a permanent unique id, and the URL for the page is based on this ID as well.

The Description that you provide when you first submit a page just populates the initial Index Entry, together with the Item Name. Most pages will only ever have this one Index Entry, but you can have more; see in particular the Piececlopedia, where a piece with multiple common names is given and Index Entry for each name, for ease of discovery. (We also distinguish "Primary" index entries, and the query can filter down to only those primary entries if you don't want the duplicates.)

You can update the Item Name. This will not update the ItemID nor URL (because those are meant to be permanent), so these can diverge. Also, changing the Item Name doesn't update the Index Entry, which might be a little confusing. I think users can't add index entries (perhaps to prevent exploiting them for greater visibility), but updating them may be made available.

This is true; it was released a bit quicker than I expected. But the omission of the start square in where should already have been fixed; I noticed that this morning.

I did test the code now.

You appear to be posting untested code. I have seen various instances of the where operator with only two arguments. It should take three, because the value returned is relative to a coordinate given in the first argument.

Ah, and you published it too! Thanks. The icon in the index still might have to be changed, as this is not a game description.

So there is an item ID, a summary and a description. The item ID determines the URL (and I will never repeat the mistake to make that very long!). The index will list item ID + description, the comment headers will list summary + description. Apparently summary and description are set to the same text when first submitting a new article? It is the summary that can be controlled by the author through the 'Edit index information', as 'Item name'.

Since the summary only seems to appear in the comment headers, which also always show the description, it doesn't make much sense to have those nearly the same. It would actually be more logical if the comment headers showed the same information as the index, i.e. use the item ID instead of the summary. Or, in other words, set the summary to the item ID, or something close to it, that doesn't repeat what the following description already says.

So, there's two different descriptions. There is the IndexEntry description which I have changed to what you request. But the Item table has a separate description, (called Summary), which is shown when viewing or commenting on the actual page. This field is limited to 64 characters, so I set it to 'Using the Play-Test Applet to generate Game Courier presets' because yours was too long.

I posted a short tutorial on how to generate GAME code with the Play-Test Applet. But I aready regret the description I have given it (GAME code generation with the Play-Test Applet (a tutorial)). I called the item 'GAME code generation', because I wanted to avoid long URLs that refer to it (such as /membergraphics/MSplay-test-applet-for-chess-variants/*). But it appears the name of the item will automatically be written before the 'description', at least if the 'Unpublished submissions' list uses the same format as the alphabetical index will eventually use. That duplicates the 'Game code generation' phrase, which looks a bit silly, and wastes precious space that could have put to better use.

So my request is for an editor to change the description to:

A tutorial on using the Play-Test Applet for automating Game Courier presets