Ratings & Comments

Try clearing your browser cache (cached images and files, any browser) assigning KADGHmcavKmpafcavKcafcmpavK (the complete Lion Dog move) to the star piece in the XBetza sandbox, and making the following moves: b2-b4 c2-c4 d2-d4 f2-e3 e12-e4 e4xd4xc4xb4. You should see spurious highlights e3 and e1 (it only works if the first and second squares in a direction are occupied by enemy pieces). If you don't see spurious highlights after this, then it must be something on my end.

Here's the game log for Very Heavy Chess in question, that seems to have a bug.

@ Greg: If you have time these days, please try to fix the preset, and/or the log (Black may need to take back his last move).

https://www.chessvariants.com/play/pbm/play.php?game=Very+Heavy+Chess&log=panther-timurthelenk-2021-339-162

Maybe it only takes place when I clear my browser cache.

Edit: I tested this in Edge, and yes, it only works if you clear your browser cache.

I am sure I am not using the old script. Try doing the same thing in the sandbox that you did last time, but with the following moves instead: b2-b4 c2-c4 d2-d4 e12-e4 e4xd4xc4xb4. You should notice spurious highlights when asked to enter the third leg of the move. Note that the bug only works if both the first and second square in a given direction are occupied by enemy pieces.

Fischer castling now should work in the Interactive Diagram, including the AI.

<script type="text/javascript" src="/membergraphics/MSinteractive-diagrams/betza.js">
</script>
<div class="idiagram">
  graphicsDir=/graphics.dir/alfaeriePNG35/
  graphicsType=png
  symmetry=mirror
  shuffle=N!BRQK
  pawn::::a2-h2
  knight:N:::b1,g1
  bishop::::c1,f1
  rook::::a1,h1
  queen::Q::d1
  king::::e1
</div>

Either I cannot reproduce it, or I don't understand what you mean. When I go to the Betza Sandbox, and assign the more compact description of the Lion Dog I gave below to the 'star piece', and play e12-e3 b2-b3 c2-c3 d2-d3 (all illegal, but just to set up a situation), I can then enter e3xd3xc3xb3, and I don't see any spurious highlighting or other irregular behavior. While there are still lot of pieces in range for the KADGH direct captures.

Are you sure you are not running a cached version of the old script?

Hi Georgi,

The easiest way, (and the way I use), is to switch the format from Markdown to WYSIWYG.  Then click the quotation marks from the toolbar to enter blockquote mode.  Then copy the text you want to quote from the section above the edit form and paste it in.  Hitting the enter key twice will exit blockquote mode so you can start typing your response.

Thanks a lot Greg! 

The triple capture ability for Lion Dogs works perfectly, at least in regards to executing the moves. There seems to be a problem when highlighting destination for the third leg of a triple capture move. The possible destination squares (aside from the one travelled to via the second leg) generate in all directions where there is a piece on one such square in said direction.

Edit: Also, the moving piece isn't deselected if it can't move back to its starting square when the diagram generates the moves for the next leg. There also seems to be a problem with contageous promotions not taking effect if you make a three leg move to an empty square

But I still haven't learned how to incorporate a previous message or parts of it.

Hi Georgi,

The easiest way, (and the way I use), is to switch the format from Markdown to WYSIWYG.  Then click the quotation marks from the toolbar to enter blockquote mode.  Then copy the text you want to quote from the section above the edit form and paste it in.  Hitting the enter key twice will exit blockquote mode so you can start typing your response.

I would like to have the abstract preset for Dragon Chess deleted.

Indeed. Please see my comments on the Sultan's game page from October 20 and 21.

Thank you for your comment and the discussion.

Indeed. See my comments from October 20 and 21 for the Sultan's game.

I have made an attempt to implement Fischer castling in the Interactive Diagram. There is no special XBetza notation for this; a shuffle game has to be specified with a 'nominal' setup. This setup defines (together with the XBetza normal castling definition) where the king must end up, and what the castling partners are (the corner pieces, which must be of equal type). If such a castling is defined, any shuffle that involves the king will then be restricted to make the king end up between the castling partners, and will activate Fischer castling.

To support the shuffle rules of Capablanca Random Chess I enhanced the Diagram's shuffle feature: An exclamation point before a piece in a shuffle specification now either means that pieces of that type should be equally distributed over square shades, or, when there only is one such piece, that it must remain on the shade it is already on. This way Q and A can be forced on different shades by putting them so in the nominal position, and order an extra shuffle of only Q and A to determine which one goes on which shade. The shuffle specs are thus QA,N!BR!AC!QK.

Initially a Diagram always shows the nominal position; there is no spontaneous shuffle. To shuffle you have to press 'Restart' in the AI control bar.

[Editor's Note: Disabling this diagram to keep it from interfering with the one on the page.]

<script type="text/javascript" src="/membergraphics/MSinteractive-diagrams/betza.js?nocache=true">
</script>
<div class="idiagram">
files=10
ranks=8
promoZone=1
promoChoice=NBRQAC
graphicsDir=/membergraphics/MSelven-chess/
squareSize=35
graphicsType=png
shuffle=QA,N!BR!AC!QK
pawn:P:ifmnDfmWfceF:pawn:a2,b2,c2,d2,e2,f2,g2,h2,i2,j2,,a7,b7,c7,d7,e7,f7,g7,h7,i7,j7
knight:N:N:knight:c1,h1,,c8,h8
bishop:B:B:bishop:d1,g1,,d8,g8
rook:R:R:rook:a1,j1,,a8,j8
queen:Q:Q:queen:e1,,e8
archbishop:A:BN::b1,,b8
chancellor:C:RN:chancellor:i1,,i8
king:K:KisO3:king:f1,,f8
</div>

I extended XBetza notation to give new meaning to the use of the z and q modifier in continuation legs of multi-leg moves, where the original meaning of crooked and circular are not useful. The intention was to solve the problem that in a bent trajectory that contains an s (also in combinations fs / bs) the equivalence of l and r is broken. A move described as afs...W starts like the Xiangqi Horse (W, and from there diagonally outward). But in a description like afsafrW the next bend in the path is 45 degree to the right, irrespective of whether whether the first bend was taken to the left or right. It thus describes two different move shapes (Alfil-like or Camel-like), rather than two orientations of moves of identical shape. That is incovenient: it preclude the use of s for compactifying the notation, and forces one to write the two symmetry-equivalent paths separately (afraflWaflafrW for the Camel-like or 'crooked' version).

From now on this can be written as afsafzW. The z then indicates that the path bends in the opposit direction as the preceding s. A sequence of z legs would thus always describe a crooked path. Similarly, a q would indicate bending in the same direction as the previous bend, and a sequence of q legs would give a circular path. This new use of the modifiers allows the description of the Falcon move to be shortened to afafsKafsafzfK: the first atom describes a path that bends after 2 steps, the second atom one that bends immediately, and then either bends in opposit direction (fz) or goes straight on (f).

Note that on oblique atoms the symmetry is broken from the very start, even without the use of an s. Such moves are interpreted as if they started in their longest direction. (So g1-f3 would be a 'left' move.) You should thus never use l or r in continuation legs of an oblique atom, or after an s leg, but always use z or q instead.

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.

[Edit] I guess that the slightly more compact KADGHcavKmpafcavKcafcmpafK would also work. This only needs two descriptions of the 3-leg move. One for the 3-out move that captures the adjacent victim, and in addition optionally the one on the second square. And another that in any case captures two squares away, and then either continues either out or in. Possibly making a normal capture on its destination. The disadvantage of this is that for the 2-out-1-in move the victims are captured in reverse order (furthest first). Which could make a difference in the case of contageon, when both the captured pieces are contageous. (As they could be in Maka Dai Dai Shogi. Although this is of course a 'never happens' situation.)

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.