Latest Ratings and Comments

When castling, the king move four squares toward one of the rooks, and the rook jumps to the other side of the king.

That definitely sounds more sensible. I had to add a special parameter castlingGap to the Interactive Diagram to support the weird way of castling that is described in the text. (I see the Diagram in the article has already been changed to castle in the normal way, though, unlike the one I first published in the comments.)

Umm, I did not even know this rule existed. WinBoard restricts the shuffle only to have the Bishops on different colors. I agree the rule makes no sense. I have also seen descriptions that did not allow the Bishops to be on adjacent squares. (That also seemed to make little sense.)

The Interactive Diagram would have to struggle to enforce this rule, because there is no way to tell it directly that a pair of pieces of different types would have to be placed on different square shades. As a work-around you could 'mark' the shades by piece type, by defining the nominal start position with a back rank RBRBNKNCQA, so that RNQ are on dark squares, and BKCA on light. You can then order a sequence of shuffles, RNQ,BKCA,QA,!BNRKC .

The first shuffle solely serves to put Q on a random dark square, the second to put A on a random light square, and the third then randomly swaps the two. The remaining pieces then have to be shuffled the usual way, i.e. the Bishops would have to go on opposit shades (indicated by the ! prefix).

I guess it would be useful to extend the shuffling capabilities of the Diagram with a prefix to indicate the piece should stay on the same color as it was in the nominal setup. Sy This would be indicated by #, then the shuffle instructions could be K#QC#AR!BN,QA, with a nominal setup where Q and A start on different shades.

I finally got to upgrading the Diagram so that it would be able to support (a limited form of) double locust capture. In particular, I considered it a blemish that it was not able to handle the Lion Dog that occurs in the large Shogi variants (which can make up to 3 radial King steps per turn, and thus capture up to 3 pieces in one move). The AI of the Diagram was already capable of supporting any number of locust captures, but up to now it was not possible for the user to enter a capture with more than one locust victim (in addition to the normal victim in the destination square).

This is now fixed, albeit in a clumsy way. The Diagram still does not support locust capture of any pair of pieces, but only those where these victims are on the same ray, on the first and second square. But that is exactly what the Lion Dog needs. (This limitation came about by the fact that it still uses only a single e.p. square, which then implies the second square.)

There was a lot involved in getting this to work. (It needed new code for generating the move notation, parsing such moves when you paste a game, communicating it to and from the AI, and of course for interpreting the clicks made when you enter a move.) I hope that I got everything right. I also made the Diagram smarter in understanding XBetza descriptors that have both destructive and non-destructive action at the square connecting the legs. (These need a different set of clicks to play: non-destructive intermediates, like the corners in a bent-leaper trajectory, never need to be clicked, while locust victims do.)

The Lion Dog can now be represented in XBetza notation as: KADGHcavKmcafcavKpafcafKcafmpafK . This is a bit cumbersome, but I saw no easy way to allow a 2-out-1-in move (using v in the 3rd leg) only when the first square gets captured or already was empty, and forbid it (using f)when it was an occupied square that was hopped over. So 3 types of three-leg moves need to be described. I guess to also describe null move an extra abK would be needed.

The rule of castling is not correct as far as the Rook is concerned. When castling, the king move four squares toward one of the rooks, and the rook jumps to the other side of the king.

This will be corrected in future editions of A World of Chess, by JL.Cazaux and R.Knowlton.

In addition, the name Tressan has to be corrected to Tressau on this page.

The rule of castling is not correct as far as the Rook is concerned. When castling, the king moves three squares when castling short and four when castling long. The rook jumps to the immediate square on the other side of the king.

This will be corrected in future editions of A World of Chess, by JL.Cazaux and R.Knowlton.

But why the limitation to set up queen and archbishop on different coloured squares, when they can change the square colour by moving like rook resp. knight?

The re-definition of the piece images is at the bottom of the Pre-Game section in all these presets. Somewhat further down in this discussion Aurelian posted a link to an ongoing game with this preset, where the problem manifests itself.

Very good, having cleared the cache and deleted the cookies, the AI no longer commits the illegality of not converting the bishop. Now it plays 24 ... Qc4. Continuing the game it developed like this:

1.g3 d5 2.d4 f5 3.Bg2 e6 4.f4 Qb4 5.c3 Qb5 6.Nf2 g6 7.Nd3 a5 8.a4 Qc4 9.Nd2 Qc6 10.Ne5 Qb6 11.b3 Nc6 12.Ndf3 Qd6 13.Ba3 Qd8 14.Bc5 Qa6 15.Qf2 Nxe5 16.Nxe5 b6 17.Ba3 Nf7 18.Nxf7 Bxf7 19.O-O Qf6 20.c4 dxc4 21.Bxa8 Qxa8 22.Ki1 cxb3 23.Rb1 Qd5 24.Rxb3 Qc4 25.Rd3 b5 26.axb5 Qxb5 27.Qa1 i5 28.Rb1 Qd5 29.Bc5 Qa8 30.Qa4 c6 31.Bb6 Bd8 32.Bxd8 Kxd8 33.Rdb3 Qa6 34.Rb6 Qa7 35.Qxc6 h5 36.Qd6 Qd7 37.Rb8#

Thanks for showing me the solution. So when will we see the Interactive Diagram offered on the Google Apps Store?

Fergus, Are you here?

How to remove a piece from the diagram. For example if I want to put the King on another square than those on which they stand by default?

You can move the pieces over the board, just like you can when you use the diagram for playing. If you want to remove a piece that you selected by mistake, but do not want on the board after all, it is a bit more tricky: you would have to capture it with another piece, and the Diagram only accept attempts to capture if they are pseudo-legal moves (i.e. when the piece to capture gets highlighted when you select the piece you are going to capture it with.) Best way is just to move the piece next to the opposing king (moves to empty squares are always accepted, even when not pseudo-legal), and then capture it with the king, and finally move the king back to where it belongs.

Also, how to use "paste an existing diagram". For example, I want to create a play-test for Shako. What can I paste in that box, an image? the link for the shako page? something else? I don't know how to use this?

That box is for pasting diagram descriptions of the type you get when you press the 'Show HTML' button at the bottom of the article. It is intended for trying out diagrams that you modified by editing the text of their description, e.g. to implement some features that the Play-Test applet would not allow you to switch on. Such as Shogi-style promotion. You can then first make the Diagram without that feature, ask for the HTML, paste it in a text editor to modify it, and copy-paste the modified version back into the diagram. Or when you get a Diagram from another page (by asking for 'Page Source', and copy-paste from there. (I discovered that also there you have to paste it into a text editor first; directly copying from the Page Source seems to leave in all kind of invisible formatting information the Play-Test Applet chokes on.)

E.g. when you want two promoting piece types, you would have to add the line maxPromote=2 to the Diagram description, otherwise only Pawns will promote.

[Edit] I forgot to say: there is also a button for creating GAME code for automating a Game Courier preset. Originally the paste box was added to make it possible to convert an Interactive Diagram that you made before and posted somewhere else to GAME code. Without the need to entirely recreate the Diagram through the Applet. Which for large variants would be more cumbersomet than just copy-pasting an existing and well-tested Diagram into the box, and pressing the GAME-code button.

It is ready to be published.

Piece list added !

Thank you, I got it working

H.G. Muller, thanks for the comments. I've also been doing some testing in ChessV.

White: Queen, Black: Queen

White wins: 94

Black wins: 93

Draws: 113

White: Griffon, Black:

White wins: 177

Black wins: 48

Draws: 75

I'm currently running test on the Archbishop and Chancellor.

The Queen-Griffon was matchup is fairly lopsided in the simulations, but its close enough that that I still found it fun to play myself. I haven't tested the Griffon-Lion matchup yet either in the computer or over the board, but your results for the KaFafsW Lion make me think that it could be unplayable. I will run some tests with the Q2afsW after my current games finish running and see if this tones down the Lion sufficiently.

Ok, thanks HG! Fergus if you can help?