Comments/Ratings for a Single Item

The Diagram's AI implements rules of not passing through or out of check as a generalized en-passant capture, where in the case of a royal any piece would be allowed to make the capture through its normal capture moves. So whether moving through check is allowed can be indicated in the move of the royal by having it create e.p. rights. For castling this is implied already by the O atom, also that the starting square itself becomes an e.p. square, so that castling out of check is also illegal.

XBetza uses the n on a stepper atom (W, F, where non-jumping has no meaning) to indicate it creates rights. On sliders that repeat such steps I now create them only at the end-point of each step. So that nQ on a royal means you cannot move through check, but you can move out of check. Which is in general what you want. That you also create rights where the piece ends up doesn't matter, as the piece could be captured there anyway. If it would automatically also create rights on the starting square of a slider leg, it would be rather cumbersome to describe the case where you want to allow moving out of check; you would have to make it a 2-leg move, first making a single step without creating rights, and then continue as a slider (through a range toggle), a sort of 'rectified' Griffon, yafnK. So I opted for creation of rights at the target square of a step, also for single steps.

But for Apothecary Chess you want to have this on larger leaps, where the n cannot be used for this purpose, and you want it on the initial square. The solution is very cumbersome: you would have to break up the N and C moves into King steps seamlessly glued through mp modes, and furthermore make an extra back-and-forth step to the starting square to make the step that arrives there create the e.p. rights, as a step that leaves it can not.

Perhaps I should just adopt the convention that initial moves on royal pieces automatically create the rights at the starting square, so that they can never be made out of check. This is usually the rule. The problem is that you can then never indicate that you do want to allow it out of check. Another possibility would be to double the i modifier for this purpose, as an indication you have to be 'extra virgin' to make the move, i.e. not even checked.

[Edit] For now I have disabled all i moves on a royal piece that is in check, in the AI. (It doesn't make a distiction based on the number of i.) I also changed the handling of e.p. capture by the AI somewhat: at any square along its path the piece checks whether it hits a square for which e.p. rights exist. If they do, and the move can capture e.p. has e mode, or c mode when the last moved piece was a royal, it allows the e.p. capture irrespective of the square occupant. For e.p. on non-royals you better make sure they never generate rights on a square occupied by an enemy. For royals, the captures are never really made, but as soon as it is detected they are possible the line terminates with a winning score, as it would mean the royal gets captured. This allows for instance forbidding hopping over enemy pieces that are protected, as is needed in Metamachy.

The modifier x does not seem to work when used on a final leg, at least when it comes to highlighting a selected piece's moves. For example, when I give a piece the move xK and press its name to show its moves, it will show red capture moves, but that's it.

Well, xK borrows moves from neighbors, and the move diagram shows pieces on empty boards. So there isn't really anything to show. On the board it would just behave as the compound of all its neighbors, without specially indicating which those neighbors are.

It does seem mildly useful to highlight the squares where it could borrow from, like it does now. I am not sure why it does that in red, which is the color for capture-only. I guess I should define an entirely new color for it.

There might not be much to show on an empty board, but xK does not show move highlights when actually moving pieces on the board.

Argh! You are right. It used to do that, but I broke it when implementing the Imitator. Both the Imitator and the move borrowing call the old move generator used for highlighting recursively. But for the imitator I added an extra argument, to restrict the moves of the target piece to the mode that you imitate (e.g. if you have a cI it should only imitate the captures). I had forgotten to pass this argument in the call for borrowing moves, and the missing argument then was interpreted as 0, so that you would never borrow anything.

Thanks for spotting this; I now fixed it.

The selective imitation does not really work satisfactorily anyway on multi-leg moves. Because it is not clear what are captures and what not. E.g. a Checker would have a capture in its first leg, and then a non-capture where it lands, and the selective imitation would now always reject one of the legs. While intuitively we think of the move as a capture (I think). So perhaps multi-leg moves should be considered captures when any of their legs makes a capture, no matter what the other legs do, for the purpose of selective imitation.

Not sure if there exist any CVs with selective imitation anyway, so this didn't have a very high priority...

I'm glad you got the move borrowing fixed, but there is one small problem. When a piece borrows from another piece that has a borrowing move in the same vector as the vector that the piece is using to borrow the move from, the diagram takes unusually long to render the move when the piece is selected and gets stuck in a frozen position when you try to move it.

For example, lets say that a piece with the move RbxW is directly behind a piece with the move sRfR2bxW. Notice that both have the bxW for borrowing moves. If I click the piece in front and then try to move it, the diagram will freeze.

I think what is happening is that when a piece with x on a final leg borrows a move, it always borrows all the moves of the piece it's borrow from, including borrowing moves. Since the pieces in the example above have the same borrowing move (bxW), when the piece in front borrows the move of the piece in the back, the diagram will generate that move on top of the original, but since the borrowed move included the same borrowing move as the original move and neither piece had moved, the diagram will repeat this procedure over and over, resulting in an infinite loop.

Fortunately, the fix for this little problem is simple. Either don't include any move with x on a final leg when adding the borrowed move to the original, or include an additional condition in the loop for generating moves that prevents the infinite loop.

Right, I did not account for multiple move borrowers. I do exclude borrowing from the same piece type, as Odin's Rune Chess has a pair of move-borrowing Kings that start next to each other. So I learned about the problem you experienced the hard way too.

Passing a flag that suppresses recursive borrowing, as you suggest, would indeed be a more robust solution. A more complex solution would be to make a list of piece types from which you already borrowed. Or even better, moves that you already borrowed, and don't borrow moves you already have borrowed from another piece (or had to begin with). That would avoid duplication of moves when you have more than one piece of the same type next to you, or pieces with overlapping moves suchas Q and R. Which would greatly increase the efficiency of the AI as long as it has no transposition table.

I think I will go for the simple flag, though, and hope one day I will get to equip the AI with a TT. In fact the infra-structure is already in place: the routine now passes a mask that suppresses some of the modes by clearing their flags, for the purpose of imitation. There I use it for clearing m or c flags. But the x flag is also in there.

[Edit] It should be fixed now. (Untested!)

I can't find a way to give extra moves power to an already moved pawn. On a 12x12 board, I'd like to have the pawn go towards the middle of the board more moves even if moved. The pawn will start at rank 3 and should have available a 1,2,3 initial move or after a move of 1 a 2 move. How is that made?

Also HG, May you repeat what a stand for. It seems it is not present in the article. I'm trying to make a 41,43 falcon and I need that information. And if you have time for that, may you tell me the XBetza notation for a 41&43 falcon. So far I have afafafsKafsafafK which does not give false positives but there are other pats that should work. Later edit: @HG I think I got the 41&43 falcon: afafafsKafsafafKafafraflKafaflafrK

fW* is a move up to half-way the board, from any position (but always allows a single step). If you want that only from the Pawn's initial rank, you should write ifW*. But if later moves should be able to do it too, you can leave out the i. The move automatically generates e.p. rights on all squares moved through. If it is non-capturing, you should of course add an m. (Should work similarly for fF*, btw.)

Later edit: @HG I think I got the 41&43 falcon: afafafsKafsafafKafafraflKafaflafrK

Well, this is definitely the correct approach. Unfortunately you have to give the mirror-image paths that bend two times separately, because after an initial s for the first bend, the equivalence between r and l is broken. This could have been avoided by redefining the meaning of r and l after an s, to mean 'same direction' or 'opposite direction' as that s. But alas, the diagram doesn't use that convention; r there is always 'to the right'. So you have to split the s in an r and l move put on a separate atom, so that the direction of the first bend is explicit, and all subsequent bends can be adapted to it.

As to your 'long-neck Falcon' (Vulture?): it depends of course on how exactly you want it to move, but it seems to me there could be more paths; the targets can be reached through 4 shortest paths, depending on whether you make the first bend after 0, 1, 2 or 3 steps, and then bend back immediately afterwards. Those that start bending after 1 or 2 steps have a bend in the opposit direction, and need to be split. That would mean 6 paths starting from K.

I had figured out that there are six paths, but I did not found the last 2.

HG, If a game has both regular and berolina pawns can they both promote? How?

Define them as the first two pieces in your list, and add the parameter (or change its value) maxPromote=2 .

@HG I have came up with this:afafafsKafsafafKafafraflKafaflafrKafraflafKaflafrafK. That is for the long neck falcon=vulture maybe.

@HG I have came up with this:afafafsKafsafafKafafraflKafaflafrKafraflafKaflafrafK. That is for the long neck falcon=vulture maybe.

That looks OK to me. Cumbersome, but I see no shorter way to do it. This Vulture is a very complex piece, and there is no way to describe it without specifying which paths it can take. Each path runs through 3 squares, each destination can be reached through 4 paths, and there are 16 destinations. That makes for a lot of squares to be indicated in the description.

woudn't it be a idea for bent riders to use > or <. (example Gryphon would be F>R)

Ideas are plentiful. But a system where different legs of a move each have separately indicated atoms fits more with the proposed Betza 2.0 extension than with the XBetza extension that is described here. (And which only mentions the start atom, and describes the remaining legs of the move through modifiers.)

What you propose is not precise enough to be flexible; it doesn't describe which directions of the Rook move can follow the Ferz. E.g. what if you want to have a piece that should only bend in one direction (a chiral half-Gryphon)? And what if the second leg is not a Rook but a Nightrider? The angle(s) you can bend by must be explicitly specified, and just using symbols like < and > doesn't give enough possibilities.

Hello again HG, If both regular and berolina promote and the promotion rules allow promotion in steps (say in regular chess knight and bishop at the sixth rank, rook at the seventh and queen at the eighth) and I do not want the berolina to promote to regular or the other way around how do I write the promochoice variable. Thanks!

This is something that is not possible with the diagram alone. When you specify multiple promoting pieces they all promote according to the same promoChoice string. Unless you specify a promoOffset; then you have Shogi-style promotions, and each promotable piece will promote to a predetermined type promoOffset further in the list, and the only choice you have is to promote or defer.

The diagram script has a 'hook', however, with which yuou can provide your own JavaScript function for verifying promotion choice: when you embed a function WeirdPromotion in the page, it will be called after any move, passing the square coordinates, moved piece and (in any) proposed promotion choice. And can then return the actual promotion piece, including a code that means refusal of the move. Using that you could define the promoChoice as the combination of all possible choices of all promotable pieces, and let the WeirdPromotion routine refuse any choice that does not belong to the piece type. Downside is that this will not affect which piece types will be highlighted in the table, when you have to make the choice. Because WeirPromotion is only called after you made the choice.

Then I think I am happy with the possibility of the "promotion" from berolina to regular and the other way around. Thanks!

HG, I need a pawn that can move as a rook only forward from the defensive side until the middle regardless of the previous moves, capture regularly and also en passant. The way I did it (regular: mfWfceF and berolina: mfFfceW) an en passant caputure is possilbe at midboard which is in error. May you please help?

I have no idea what you mean. Can you give a sequence of moves where these definitions do not work as desired?

I've been using the diagram here: https://www.chessvariants.com/index/listcomments.php?itemid=1200173ceb826d24&order=DESC.

It seems that only when playing against the computer this situation appears. A sequence leading to it starts with: 1. f7 f8 2.g7. And then black moves something. White tries to go g8 and now white has the option of capturing en passant at g7. This should not happen.