Comments by H. G. Muller
'Mate' is for positions with white to move, 'mated' for positions with black (the bare King) to move. Mated-in-0 means black is already in (check)mate, mate-in-1 means white's (best) move will terminate the game. The number in those columns is the number of positions from which the result can be forced in the given number of moves (3rd column). There is no mate-in-0, but the logical successor of mate-in-1 would be positions where white can capture the King (which would be illegal in a variant with a checking rule), given in the fore-last row.
The final row gives the total of the columns, expressed as a fraction of the total number of pseudo-legal positions (= ignoring any checking rule, but without multiple pieces on the same square). For generally won end-games the left will be close to 100%, but the black-to-move fraction will be much lower, because of positions where black can capture a King or an unprotected piece. For generally drawn end-games the right number will be close to 0%, but the left number will be much higher because of King captures, and can be over 50% if white has a strong piece.
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.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
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).
Since this comment is for a page that has not been published yet, you must be signed in to read it.
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:
?
Since this comment is for a page that has not been published yet, you must be signed in to read it.
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.
But some hints to where I put my code and what that code should be are very welcomed.
I think the variable 'mln' gives you the current move number in the Post-Move sections. What you want is special treatment for the first few ('prelude') moves, and then the normal procedure possibly followed by gating when this would be required. So something like:
if == mln 0: ... // do what has to be done for the first prelude turn elsif == mln 2: ... // do what has to be done for the third prelude turn else: gosub HandleMove true; set waiting where #ori 0 -1; // square behind moved piece if not flag #ori and == 1 rank #ori != @ space #waiting: // virgin first-rank piece with something behind it add space #waiting #ori; // gate the piece empty #waiting; endif; endif;
You stil would have to suppress normal moves for the pieces waiting to be gated. I suppose the easiest way to do this define an alternative version of those that looks the same but does not have any moves, and put those on 0th rank. When its turn comes to be gated you then put the version with moves on the board.
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.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I have just read that thismove does not work in premove
All the more reason to not do anything there.
I am not sure it would ever make sense to add code in the Pre-Move section, when you automate through the PTA. Because Game Courier is configured to "not add moves" in that case, you should be in the same state at the start of the Post-Move section as you are in Pre-Move.
This would only be possible with significant additional GAME-code programming. For one, you would have to program enforcement of the 'prelude', as the HandleMove routines in the Post-Move sections only handle normal board moves. So the code should first test the move number, and do something else for the first few moves.
Apart from that you would also have to add code after the call to HandleMove, in order to automatically step the piece on board that is gated.
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.
Should I add : Should I add " ##############" before and after?
Indeed, you should, because you want the extra hand ranks to be colored black as well.
Strange. 13 should be a valid index for an array of length 19. That means the array should have some internal elements that are undefined. What happens if you print
console.log(
)?25 comments displayed
Permalink to the exact comments currently displayed.
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.