Comments by HGMuller

It is easy to see this piece cannot checkmate. The only mate positions are white: Ka3 or b3, Xc6; black Ka1 (and symmetry equivalents). But to force the King to a1 the X would have to cover c1 while the bare King is on b1. And to be able to move to c6 you have to cover that. But it cannot cover c1 and c6 at the same time; its move spans only 5 squares on the same rank or file. So there aren't any forced mate-in-2 positions.

FXDY could in principle do that, because it can cover c1 and c5 (where it has to be to deliver checkmate) at once. But it turns out to be too clumsy to drive the bare King towards the corner. Add a WX move, and it can, though.

If I understood Fergus correctly all that is needed to do it is compare the value of turn instead of mln. Like

if == 1 turn:
... // code for first prelude step
elseif == turn 2:
... // code for second prelude step
else:
  gosub HandleMove true;
  ... // code for performing the gating if needed
endif;

The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn. But that would affect every preset automated through the PTA, and I have never encountered a case where it did not work.

Is there a way to enter XBetza on this?

Not on this page. But you could use the configurable applet page that the Piececlopedia links to, and write the Betza move you want in the URL.

I wanted to try out the Blue Gecko (frB4lbW2flFbrFfW) but I can't limit the B move to 4 on this diagram.

I guess I should extend the move-definition aid to 11x11 one of these days. But in case of the Blue Gecko, why bother? The 4th step of the B move will hardly ever be needed. And even when you leave out the frB move altogether, it can already force checkmate. You could also use B3 plus a direct AY leap, which shows that adding the AY leap does not shorten the mate (on 8x8, at least).

OK, so the betza.txt code, which thus aims to test for whether the move is the one that was just entered, would work fine even in the presence of comments?

And the code to test for whether we are in prelude should look like

if == 0 $mline[$mln]->movenum:

?

I am not aware of any such sources.

Using grid would probably help you avoid this problem too. With grid, you should be able to make one column or row diagonal, though I have not yet tried using grid with hexagonal boards. My CSS code for hexagonal boards uses absolute positioning, as grid was not yet part of CSS when I wrote the code. Anyway, absolute positioning is another alternative to using tables.

I am not familiar with this technique, but a problem could be that it is not just about positioning the images, but also about translating mouse clicks to cell coordinates. (Which must also work for empty cells, for entering non-captures.) In the table version I have attached event handlers to the cells for this.

It does not. I have made that mistake too and had to correct it. To use $mln to get the move number, you need to get $mline[$mln]->movenum.

This is somewhat important, because the first things that the HandleMove routine does in the betza.txt include after the move is parsed is:

  set all == mln $maxmln;          // indicates last move

Note there is no $ there, so we might be talking about different things, and this one might be a legacy variable. The purpose here is to determine whether the subsequent move generation needs to generate all pseudo-legal moves, and compare the input move against those for testing its legality. Or whether it can simply assume the move is legal, because it is not the final move of the stored game, and thus must already have passed the legality test on the turn where it was entered. If the latter is the case only the moves with implied side effects are generated, (e.g. e.p. capture or castling), for the purpose of reconstructing the side effect, and apply it to the board together with the entered move.

I cannot image how this would work if mln was not the current move number.

Is it possible to make an Interactive Diagram use a hexagonal board?

The current standard scripts do not support that. The I.D. represents the board through a HTML table, and in theory it should be possible to create a table with a masonry-like tiling, shifting each subsequent rank by half a cell. This could be done by giving the first cell on each rank colspan 1, 2, 3, 4, ..., and all other cells colspan="2".

I have tried this, though, and it works to some extent. But for reasons that I do not grasp yet it also changes the height of the ranks in a way that I could not control.

Once the pieces are displayed on the hexagonal grid defined by the table, suppressing cell borders and coloring would allow display of a custom hexagonal board image as background.

I have just read that thismove does not work in premove

All the more reason to not do anything there.

I suppose I implemented the idea I described earlier in this thread, to give U moves a penalty in the positional range. I don't remember when I did that. (Or in fact that I did it at all.)

BTW: K-side castling is done with the pocketed Knight, instead of the Rook! Better move the pocket squares to 2nd rank.

You must not write anything on the row behind the =. Probably /..$= would already do. On encountering the = filling of the matrix skips to the friendly captures/hops, and at the same time copies what you already have defined in the row (so ..$ here) to the corresponding friendly interactions. What you continue after that will start to overwrite the copied friendly interactions.

We could also ask the more general question of not keeping anything other than chess variants. Something to think about.

Indeed, that occurred to me too. We could easily delete all lines in the jocly-allgames.js file that do not refer to chess variants.

OTOH, the preferred access to the variants on this website appears to be through the Jocly overview page, not through the 'other Jocly games' link that the applet always shows. It is a bit silly when you first have to select a variant you don't want to play, and then switch. And the switch works in the applet, but not for the rule description page we embedded the applet in.

But the overview page also needs refactoring; listing the available variants by date is not helpful at all to the unwary visitor of this website. I am not sure what the best presentation is, though. I suppose alphabetically, even though this competes with what you could do (with some more knowledge and effort) in the site's alphabetical index.

I am also thinking of 'modernizing' the install here. By replacing jocly.game.js the Jocly core is already fully compatible with the recent source code. The only variant in the CVP install that has not been back-ported to source yet is Tenjiku Shogi. Since all game-specific model and view files include a version of the chessbase model and view, there is no harm in different variants needing different versions of these.

So we could replace all model and view files in the chessbase folder by those from the most-recent compile, and the images and supporting info file these use in the chessbase/res sub-tree as well. I think Tenjiku Shogi exclusively uses sprites, mesh files and diffusemaps from the shogi2 subdirectory, which does not exist in the source tree. Only jocly-allgames.js must be made to always have the extra line defining Tenjiku Shogi, compared to the version created by building Jocly from source.

The Wikipedia has it that the player with the weakest player has the Jade General, and the strongest player the King. I am not sure if and how we should implement that in Jocly.