Ratings & Comments

I agree that the way XBetza handles multi-leg moves is not very intuitive. I don't think it is too late to switch to a more intuitive notation, as long as it doesn't allow specification of moves that would not be possible to specify in XBetza. Because then it would be quite easy to just equip the Interactive Diagram (or XBoard) with a simple pre-processor, which just converts the more human-friendly notation to XBetza before interpreting the latter.

E.g. how about writing multi-leg moves always within parentheses, using a hyphen as leg separator, and requiring all atoms should be 'compatible'? Where compatibility means they should either all be multiples of K steps, or of the same oblique leap. The Griffin would then be F(F-fsR), and the pre-processor would act on anything between parentheses, run through the legs to see whether range-toggling is needed. Depending on that it then translates the hyphen to a or ya. So that it ends up with the modifier string yafs, after which it then writes the leading atom F to get the equivalent XBetza. (I guess we could also use square brackets and commas, to stay closer to Betza's original suggestion: F[F,fsR].)

As to your specific questions: the Snake is easy: vWvyafsW. This is just the Manticore with all its moves prefixed with a v. The Ship, however is hard. This is not so much the fault of the notation, but caused by the fact that moves with different initial steps bend in different directions, and you have to indicate which (while for the Snake all moves bent in both directions). The only way to do it is to separate the left-bending from the right-bending move, i.e. the diagonal from the anti-diagonal first steps. This in itself is cumbersome, as there are no shorthands like v or s for diametrically opposed diagonal moves. So you have to write out all directions, and being diagonals, each direction requires two letters. E.g. a Ferz moving along an anti-diagonal is flbrF, and in the Ship you want those to bend to the right (i.e. fr) in the next leg. So you get flbryafrF for these two paths. And then you have to write the other two paths in the same way, changing all l into r and vice versa. This is how I did it in my Diagram for Tamerlane II. (Note that flbr[F,frR] as it would look in the proposed more intuitive system would not be much less cumbersome...)

@Greg or another editor.

I think I know where the bug comes from in the Very Heavy Chess preset.

The "Pre-Game" block doesn't have the right squares, it has been cut-and-paste from Heavy Chess.

Instead of

setflag b2 b9 i2 i9 f2 f9; set k f9; set K f2; set ep false; set bpr 8; set wpr 3; set wcastle d2 e2 g2 h2; set bcastle d9 e9 g9 h9;

it should be:

setflag c2 c9 j2 j9 g2 g9; set k g9; set K g2; set ep false; set bpr 8; set wpr 3; set wcastle e2 f2 h2 i2; set bcastle e9 f9 h9 i9;

Could you make the correction?

Also the "Rules URL" is wrong, pointing to Heavy Chess instead of Very Heavy Chess.

I could do the correction myself but I don't think it will be saved for everyone.

Thank you

I'm impressed by this development. But it is complex for me to understand, despite of the very clear text, it is not intuitive for me. I'm particularly interested by bent riders. A Gryphon without W or R in the string is strange, I understand the explanation but it is too bad there is no a modifier to say "move outwards as X". I'm not at all a computer language expert, I confess.

I got the string for the Gryphon, I can derive the one for Manticore by replacing the F by W. I think this is right. But I failed in fiding the string for the Ship (an half-Gryphon, only sliding vertically, not horizontally) and the Snake(tongue) (an half-Manticore, 1 step v then sliding diag away, never 1 step h then diag). What is the solution?

Thanks a lot

OK, the pawn on e3 made all the difference. Clearing the cache I do all the time, to test new features.

The code was lacking a test at the second leg to see if the locust squares that were entered so far matched the move that was currently being generated, and would thus also highlight the third leg of all other possible triple captures. This should be fixed now.

Good catch, it had escaped my testing! (Another case that had escaped my initial testing, but which I discovered later myself, was Fischer castling with K@c1 and R@b1, because the code tried to calculate the destination of the Rook from the direction the King moves in. While it should have tested what side the Rook is on initially!) Yet another bug I fixed recently was in preserving left-right symmetry when shuffling; this did not work correctly on a board with an odd number of files.

@Fergus,

Could you please take a look at problem described bellow by me an HG?

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.