Comments/Ratings for a Single Item

You pasted the call to GameEnd for black in the "Initial Moves" section, instead of the Post-Game2 section.

Ok, that was definitely wrong! But fixing that didn't solve my problems. Now I get "move must be piece ID plus board step"

That is weird. It also says:

And for general reference, here is the complete list of moves:

1. gosub GameEnd true;

So it thinks the GAME code in the Post-Game2 section is a move?! That surely explains why it complains about the move syntax. It baffles me how it could ever start to parse its own code as if it were a move. Perhaps Fergus has an idea how this can happen? I suspect the presence of this in the Initial-Moves section did some persisting damage to the entire preset.

It is midnight here now; if the problem still exists tomorrow I can look at it further.

I suspect the presence of this in the Initial-Moves section did some persisting damage to the entire preset.

Yes, this was my thought as well, but I downloaded the php file and found no traces of it...

Perhaps Fergus has an idea how this can happen?

Since the "MOVE:" command is the only command that would add something to the moves list, I searched for it in betza.txt and found this code:

  do while < var k count var mvs:               // for all legs
    eval join "MOVE: " trim elem var k var mvs; // apply the move
    inc k;
  loop;

I haven't analyzed it, but I don't know what else would be responsible.

Are you sure you saved the code twice, after you moved the gosub GameEnd from the Initial-Moves section to Post-Game2? Very often changes become only effective after the second time. I have had to go through dozens of times through the sequence Play - Bug manifests itself - Menu - Edit - Fix the bug - Save - Menu - Play - Bug still manifests itself - Menu - Edit - (Inspect code, bugfix is already there) - Save - Menu - Play - Bug no longer manifests itself. If you saved only once, chances are that the preset still thinks the gosub is in the Initial-Moves section, even though the Edit function does no longer show it there. With Game Courier, what you see is not always what you get.

I was aware of this problem and saved several times, but it still didn't work. I created new settings, just to be certain, and that worked. The Initial Moves section always appeared to be empty, but wasn't. Apparently, when you put something in there, you can never get rid of it. I overlooked it before, but the following was in the php code:

$default['movelist'] = <<<'NOW'
1. gosub GameEnd true;
NOW;
$default['movenum'] = <<<'NOW'
1
NOW;

So now I'll fix the php manually and clean up my extra settings file. Thanks for the help!

How do I make en passant work? I added an e to the pawn move for "fmW*fceF" but that doesn't seem to do it. Is that not right?

Yes, you did that right; it is supposed to work that way. But I had not implemented setting of e.p. rights by a W* move in the betza.txt include. (Which needs other code than that for setting the rights on a lame leap, which sets them on jumped-over squares rather than visited squares.) In fact I had not implemented the W* at all, yet. The Betza compiler encodes this special case by specifying a range of -1, but the interpreting GAME code should then of course recognize this special case, to recalculate it as the distance of the fromSqr to the board middle. I quickly added the code for that yesterday evening, when I saw you would need it.

I added the code for setting the e.p. squares now, and tested it in the preset you made.

Very nice! Almost perfect. I think my last problem is promotion. It only shows queen, rook, bishop, and knight as options, but I put "QRWEBN" in the Promotion Choice field.

Ok, I found the issue. For some reason, it put "N n B b R r Q q e e w w" as the options (the E and W were both lower-case for some reason.)

Well, the JavaScript in the wizard page that flushes the GAME code uses this line for generating the promotion array:

        if(choice[i] != 3) psupply += ' ' + ids[i] + ' ' + ids[i].toLowerCase();

The array ids[] contains the piece IDs. It does not take them directly from the promotion string you typed; this just determines the content of the array choice, encoding what type of promotion this is (e.g. to captured pieces only). Only the second occurrence is forced to lower case, and if the IDs already where lower case, the first one stays that. Normally the Diagram takes the IDs as first letter of the name (when not explicitly given in the piece definition), capitalizing it. But in the Play-Test Applet you then in general change the name and the ID (and move). So the likely explanation is that you typed a lower case ID when altering ID / name and move for Wolf and Eagle.

I suppose I should just write ids[i].toUpperCase() for the first occurrence, to exclude this. Or perhaps already convert the ID to upper case in ids[] when you alter it.

I looked at the code in the preset, and I still see one issue: the castling partners do not seem to be defined correctly (e1 e1 e12 e12) instead of (a1 l1 a12 l12). I don't know how that could have happened. This game has castling, does it not? The Interactive Diagram made by Aurelian defines the King move as KisO3.

It says KisO4 in the list, which is correct, but I didn't update that one. I had guessed that it defaulted to that based on the board size. But I didn't put the king on the board either - it starts there (if that matters.)

I updated those values and now castling works correctly too.

This is VERY impressive. It is now possible to make presets for typical variants with no writing of GAME code at all. Thank you for making this!

The Play-Test Applet indeed adapts the default King move to the board width, by making the castling end as usual w.r.t. the corners. Identifying the castling partners is a bit tricky, though. Originally the Interactive Diagram allowed castling with corner pieces and Rooks (which in some variants start closer to the King). For the AI this was not acceptable, so I added code to scan the board to locate the piece that can castle, look how wide the rank is that it is on (the board could be irregular, or have holes, e.g. Omega Chess), and defines the extreme squares as 'corners'. If those squares are empty, it scans the rank towards the King to find a piece. Later I implemented the j modifier to explicitly shift the castling square inward (so the AI could also do Omega Chess, where the square behind the Rook is not empty).

In the Wizard Tutorial I state that if you are not interested in the FEN, you can just put one piece of every type you need on the board. I realize now that this is wrong: You need to put the someting at the edges on the King rank to get the correct castling partners. I guess I should alter the Diagram script to entirely rely on the j (and board holes, if any) for identifying the castling partners, irrespective of whether these are empty in the initial position. That makes the generated GAME code less dependent on the initial setup. The King would still have to be in the right place, though.

I am glad you like it. For variants with less-typical rules, such as the Jumping Chess, one still has to write GAME code. But often that can be limited to code to implement the non-standard rules. I try to make this as simple as possible, though. Confinement to board zones (at the pseudo-legal level) can now be enforced by just defining a single function for vetoing moves based on the square coordinates of those. I am not entirely happy with that yet, because it does not pass the location of any hopper mount. So it cannot be used to implement the Janggi rule that Cannons cannot jump over Cannons. In the Diagram hops are treated transparently, though: you don't have to indicate the mount when entering the move. As a consequence there can be an arbitrary number of them. Perhaps I should have the move generator remember what was the last piece hopped over, and also pass that to the user-supplied routine.

For larger flexibility I guess it would be good to allow a user-supplied callback for the move generator, so make it easy to call it for your own purposes. Like testing whether there exists a move that is mandatory (by whatever criteria you want).

It would be even nicer if instead of a button that shows you the GAME code so that you can copy-paste it, there would be a button 'Create Preset'. Which would send the HTML requests to the server (through AJAX calls) that are needed to open the preset edit page, and deposit the the code there as if the Save button was pressed. This should be technically possible, as the pages are on the same server.

Of course the user should then have to supply the name of the variant, and the name of the settings file first. But there could be text entries for those. The Wizard could in response display the link through which you can edit the created preset. Or perhaps open that preset in edit mode itself, in another browser window. The user would then only have to adapt the settings for the graphics (color, piece theme...).

I need to make a rule-enforcing preset for Brouhaha. Does this support making GC presets with Brouhaha squares? I know there's a function (BadZone?) I can use to disallow moving to the border, but I would need to allow it in the case of a capture.

I have forgotten how exactly I implemented this, but there is an variable 'brouhaha' which is set to an empty array in the include code. I suppose that setting it would work, and that the Play-Test Applet generates the code to set it, when you created it with Brouhaha squares. (At the bottom of the piece table there is a button that allows you to black out squares rather than place pieces. You should do that first, and then later move a piece to the blacked-out square to make it a Brouhaha square.)

[Edit] I checked it out, and the GAME code in the betza.txt include file simply tests in HandleMove whether the origin square is in the defined 'brouhaha' set and is evacuated (i.e. not also a drop, like in a swap move). If so, it deletes the cell as part of move making. (Which happens before testing whether the move was fully legal.)

It doesn't remove the Brouhaha square during testing for full legality for the purpose of highlighting. In theory this could cause highlighting of moves with pieces that are pinned on Brouhaha squares. (E.g. if c0, d0 and e0 are Brouhaha squares, and your King is on c0, your Bishop on d0 and an enemy Rook on e0, moves with the Bishop would still be highlighted.) It also doesn't remove the Brouhaha square when the piece on it is locust-captured. The latter should be easy to fix, if the need ever arises.

How can I make a King castle 3 squares short and 4 squares long? The l and r modifiers are relative to the player, so it seems I need the ability to specify a different betza for white and black.

The l and r modifiers are relative to the player, so it seems I need the ability to specify a different betza for white and black.

You can specify an extra parameter castleFlip=1 in the Diagram to swap the meaning of l and r on castlings.

I am not entirely happy with that; I guess a neater solution would be to apply the l <-> r swap on all of black's moves. And perhaps this should be applied automatically based on the specified symmetry (none, mirror, rotate), where mirror then should do it, and none / rotate not.

Varying the directions based on a symmetry setting is what ChessV does. They symmetries are called rotational, mirror, and none.

But this castleFlip option doesn't help for generating a Game Courier preset, right?

Indeed, there is no way to specify it in the Applet. Making it automatic would solve that. Except that there isn't really a way to specify 'rotate' symmetry either. But I suppose you could use 'none'.

The easiest way is probably to generate tables for a symmetric King, and then change one of the castling distances by editing the generated code. The tables get comments to indicate what piece they are for, and you will easily recognize that castling range in the King section. E.g. for O2 castling you will get something like

1  1  0  1     3 // king(84)
1  1  1  1     3
1  1  1  0     3
1  1  1 -1     3
1  1  0 -1     3
1  1 -1 -1     3
1  1 -1  0     3
1  1 -1  1     3
2 99  1  0    72
   1  2  0     9
2 99 -1  0    72
   1 -2  0     9

just change the -2 on the last line to -3 to get 3-step Q-side castling.

This is strange. I've put all the contents into the preset, and things mostly work, but a Bishop keeps disappearing. Whichever side to move's bishop disappears!

https://www.chessvariants.com/play/pbm/play.php?game%3DJanus+Kamil+Chess%26settings%3Dstandard

This is weird indeed. But it already happens in the 'menu' page, and I am not sure any of the supplied GAME code (in particular the Pre-Game code) is already activated there. And since this is not a shuffle game the Pre-Game code should not do anything other than assigning to the parameters that later will define the behavior when vetting moves. It is also not caused by the movepiece.js script; the Bishop is already missing in the Page Source. And Game Courier itself is aware that the Bishop is missing, as it displays it as a 'captured piece'.

What happens when you comment out the betza.txt include? Or when you only put in the include, and leave out the variant-specific assignments? There is a lot of code in betza.txt, but it is almost all subroutine definitions, which should only be invoked from the Post-Move / Post-Game sections. And these should not be activated when it is just displaying the initial position on the menu page. (I doubt that even Pre-Move would be activated there.) The only code that executes on include is a few assignments, none affecting the board position.

Remove the include file and the problem persists. If I replace it and remove the rest of the pre-game code, it crashes "function P is not defined".

I think some game code is definitely being run even by the 'menu' page because it shows this warning:

NOTICE: The setup shown here has been modified from the original setup thanks to running code for this game. If this game randomizes the setup, then you may expect to see a different setup when you actually play the game.