Comments/Ratings for a Single Item

ok!

Why does the below diagram asks to put the gated piece on the board?

It should not. That is a feature for Musketeer-type gating. Earlier today I had uploaded a buggy version, which switched that on by default, instead of only with the option autoGate=1. But it has long since been replaced. It seems you are still using an old version of the script. What happens when you click on the 'move' header in the piece table?

I have corrected some spelling mistakes.

I changed mention to a table to a list, because the underlying HTML was for a list, not a table.

I don't follow what the x modifer does. An example would be helpful.

It's not clear how FyafsF is supposed to describe the Griffon. Should the second F be an R?

I rewrote the description of the leadng i modifer to use the word initial and to omit use of the word virgin, which was being used in a figurative rather than a literal sense.

Is mp something different than the moving and hopping modifiers combined? Does mpafsK mean the same as N? If so, how does it work?

I'm not familiar with Bifurcators, and other readers might not be too. An illustration to how the piece works or a link to a page on this type of piece would be helpful before describing what gabyabsR  is doing.

Is mp something different than the moving and hopping modifiers combined? Does mpafsK mean the same as N? If so, how does it work?

I now elaborated on that, and hope this will make it clear.

I don't follow what the x modifer does. An example would be helpful.

I think we have to discuss presentation strategy here. The list of modifiers below the diagram also serves the purpose of a quick reference guide, which can always be kept in view by people who are using the sandbox diagram. Elaborating on each of them, explaining examples, would easily quadruple its size, so that it becomes difficult to use for that purpose. I do in fact give an example for x, (mNxaN) but I don't say what it is. (It is in fact the Knight of Knight-Relay Chess, which moves (without capturing) like a Knight (mN) and induces Knight moves at a distance of a Knight move (xaN)).

Would it be an idea to add an extra section where each of the examples mentioned in the 'quick reference' are discussed in depth?

It's not clear how FyafsF is supposed to describe the Griffon. Should the second F be an R?

Did you read the 'more about a' link in the 'quick reference'? It opens a box that should make this clear. I presented it this way, because most people wanting to use XBetza (e.g. for making an Interactive Diagram for their variant) would not need the complexity of multi-leg moves, and be completely satisfied by combining Knights with Bishops, or perhaps make a HFD. Even the need for directional modifiers is quite rare (outside Shogi). Not many people use bent riders, bent lame leapes, locusts, bifurcators, pieces that induce moves in other pieces, or displace those...

I don't want to burden the 95% of people with stuff they don't need, and deter them by it. The a is a highly advanced feature of XBetza, almost never needed.

But it would of course be bad if I hid it so well that people will miss it alltogether. The more-about-a box was actually a remnant of the old sandbox diagram I posted as a comment to the Betza article (since then pushed far in the background noise). In a real article I have more space, and perhaps I should move most of what is now in the box to the preceding section about XBetza above the sandbox, or a new section about multi-leg moves. (With an initial warning that people who just want to do basic things can skip that section.)

To answer your question: The yafsF part of FyafsF means the move starts as F to an empty square, to fork there (y is "move and continue as slider"), and then continue in the (relative) fs direction, i.e. as a Rook. That is a Griffon, except for the F moves. (Because a Rook makes at least one step; it cannot null-move.) So the latter are slammed on separately.

I'm not familiar with Bifurcators, and other readers might not be too. An illustration to how the piece works or a link to a page on this type of piece would be helpful before describing what gabyabsR  is doing.

Bifurcators are an invention of Mats Winther. But when I looked for them, I could not find any mention of them in the Piececlopedia. (Do we have a search function here?) I know Mats describes many variants on his own website, mostly based on very innovative piece designs ('Catapults' are another invention of him).

Note, however, that the sandbox diagram is available as an interpretation aid: to know what it means you only have to copy-paste it in the Betza move-entry, assign it to a piece, (e.g. 'betza2'), and then click on the name of that piece to summon up the move diagram. As this is some kind of hopper, even the move diagram will be interactive for pointing out the hopper's mount by hovering the mouse pointer over a square in its path (or touching that square on a touch-screen device). That would make it obvious what the piece does; as they say, a picture is worth a thousand words.

One reason for giving the examples was to provide people with something to try out the sandbox diagram with something non-obvious.

[Edit] I now added a section at the end, which discusses the examples of the more complex pieces in detail.

HG,

The script works wonderfully. Thanks! 

Microsoft edge got updated last night. I think this is why!

Problem is that it still assigns zero value to the Joker, because it determines piece values at the start of the game, when the Joker has no moves yet. Not sure how to put a value on it; it seems to depend a lot on what the opponent has. So some sort of average of the opponent piece values. But it should be a weighted average, as stronger pieces tend to move more frequently than weaker pieces. And of course it should be weighted by the number of each type the opponent has as well. So something like SUM(over pieces) value*value/SUM(over pieces)value.

I was wondering about that :)!

OK, I just uploaded an updated script that fixes that.

HG,

If you have time to make the interactive diagrams AI work on the particular cases of chess960 (for the initial position randomness) and gross chess (for the promotion rule) I'd really apreciate it for my apothecary games as I think I would be able to do interactive diagrams on them, too.

I did post an Interactive Diagram for Gross Chess. You can simply look up that comment, click 'View' to see it in isolation, and then ask your browser for the 'page source' to see the HTML. Then you will see the diagram definition between the <div> tags and the supporting JavaScript for handling the special promotion rule between <script> tags. You can just copy that JavaScript. You might have to adapt the numbers a bit to bring it in accordance with what promotions you want to allow where, but that should be easy, as it is a very straightforward routine. Programming in JavaScript is a hundred times easier than writing 'game code'...

As to the shuffling: you would have to tell me by which rules you want to shuffle.

I had found a function called weird promotion. I'll get to it tommorrow. Thanks HG!...

Later Edit: I don't understand how the rule that states that you must have the pieces in reserve is implemented. 

I'll take a look on Grand chess also, I guess!

Oh, that rule is a standard feature of the diagram. You can also see that in the definition of the Gross Chess diagram itself. You just prefix the piece ID in the promoChoice setting with an asterisk (*). (Must still make the AI understand that, though.) Choices that cannot be made on last rank (like staying a Pawn) can be prefixed with an exclamation point (!). So you don't have to worry about that in WeirdPromotion(). The problem is that the way the diagram works it would offer all pieces mentioned in promoChoice that are available for the user to promote to, irrespective of what rank in the zone you are on. So the task of WeirPromotion is just to reject the choices that are not allowed according to the specific promotion rules, and I think the version there does that by considering them the choice to not promote at all. By replacing the choice by a Pawn, as if the user had chosen that. On the last rank, where a Pawn would not be allowed, this can never happen, as every other choice would be allowed there.) I think in newer versions of the Diagram script WeirPromotion() can actually cause the Diagram to refuse the move completely (rather than just the promotion), by returning 1022 as choice.

Various examples mention that fs continues a move at a 45 degree angle, but there is no prior mention of this in your descriptions of the modifiers. Where you are overloading the meanings of the modifiers by giving new meanings to pairs of modifiers, it would be helpful to explicitly spell this out in your quick reference.

Well, the main text says:

The latter is specified by the directional modifiers on the continuation leg, and is triggered by a diagonal direction specification causing a 45-degree change in direction (as directions are always relative to the previous leg).

So there is nothing new in the use of fs here; it has always meant 'diagonally forward', i.e. at an angle of 45-degrees to 'forward'. It is just that 'forward' is a relative notion. And frankly, I don't see how that could be different. The moves of a chess piece start off in many different directions, so if you want to describe a move with a fixed shape, it is only the angle between the steps that count. An absolute orientation would be useless; it would be different for each move of the symmetry-equivalent set. Angles must always be given compared to some frame of reference; for the first step the piece is still in the origin, and the symmetry is not yet broken, so we take the player as the reference.

[Edit] As the old text apparently was not clear enough, I moved part of what was hidden in the more-about-a box to the XBetza section, and also added some more explanation there. I completely rewrote the content of the hidden box, to make more like a reference guide than an explanation.

I just searched for the text you quoted to read it in context, and the search brought me directly to your comment quoting it. Did you remove it?

Apparently so; this was one of the things from the XBetza section that was also mentioned in the hidden more-about-a box in other wording, and when I amalgamated the two, and in response to your remark, I changed it to:

For instance, directions on continuation legs are always specified relative to the preceding leg, as we want the notation to specify moves of a fixed shape. Thus f should be read as "in the same direction", (e.g. mafF is a lame Alfil.) and fs as "deflected by 45 degrees left or right". This rotation of the frame of reference means that continuation legs always use the same system for specifying directions as the K atom: even for oblique and diagonal atoms f in a continuation leg only specifies a single move.

I have made some revisions for the sake of clarity, though I'm not done reading it over yet. I have also started on creating a system for keeping track of revisions. When you update your submission, a relatively permanent copy will also be saved to the Revisions table. In time, I will add the ability to view, compare, retrieve, and delete specific past revisions.

I made a few more revisions, published this page, and changed its type from Game to Desktop Publishing.

Is there a way to have a piece jump 4 squares diagonally? As it is now, the diagram doesn't appear to have that option as a single move/atom.

Yes: mpafA

The 'a' means again, so two A steps.  The 'mp' means the first square can either be empty, or occupied and passed over.  In other words, doesn't matter what's there, so the two steps are glued together.  And the 'f' restricts the second step to the same direction as the first (forward, relatively speaking).

It would be nice to be able to use (4,4) in place of an atom to specify an arbitrary step.

The X suffix for 'extended' atoms was somewhat of a hack, to quickly solve a problem that occurred. I am not very happy with it, expecially since the amount of extension is dependent on the lateral step of the atom. I don't like the coordinate notation (1,4) much either. For one, I would like to reserve the parentheses for grouping modifiers, or just for the purpose of enhancing readability. Brackets like [1,4] would look better, IMO.

The dilemma here (as always) is whether we want to go for something universal, which requires an infra-structural investment (in this case the brackets and the comma) to make it work even in simple cases, or use an ad-hoc solution that captures a few cases in a very simple way (such as the X suffix), but offers no universal relief. BTW, the suffix solution could be made universal by allowing repeated suffixes, like in Roman numerals vs arabic digits. Depending on the frequency distribution of the numbers encountered in practice, one system or the other would on average give the most compact representation. (Or, to say it differently, run-length encoding only gives compression on texts that frequently contain long repetitions of the same character.)

The X system is lame, however, and I now regret having implemented it. Perhaps it is not too late to change it. A better solution of this type would be to have two suffixes: X for adding an H step, and Y for adding an A step to any given atom, and allow repetition of as many X and Y as is needed. Primitive, but more consistent than the current X suffix. And HXX for [0,9] is still only 3 characters vs 5, HXXX for [0,12] is 4 vs 6, only after HXXXXX for [0,24] the coordinate system starts to need fewer characters. And would we ever want to describe pieces that leap more than 24?

The atom table would then become (1 quadrant shown):

HX CX ZX GX DYY
DX NX AX CY ZY FYY
WX FX DY NY AY
H  C  Z  G
D  N  A  Z
W  F  N  C
#  W  D  H 

I think adding the Y extension and repeatable suffixes is a good idea. It might also be a good idea to allow the X and Y extensions to be combined in case there is a leap that one extension cannot simplify on its own. It may not be a perfect solution, but it should be good enough to suit the needs of most variants.

Personally, I like [x,y] a LOT better than adding X and Y as suffix atoms, which is a pretty ugly hack.

And, yeah, using brackets and saving the paranthesis makes sense.  (Betza 2.0 is easier for me to comprehend than XBetza.)

@HG,

Does the extended notation understand that the royal piece cannot move in certain ways out of check?

For example in orthodox chess the king cannot move out of check.

In my apothecary games the virgin king may make a knight or camel leap 1 rank back, but not out of check.

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.

OK, I see. So the AI thinks it has more e.p. rights after a W* move than it should have. I will look into it.

[Edit] I think it is solved now. The AI and the old system for entering human moves have a quite different way of indicating e.p. rights, and the algorithm for converting the rights generated by the human move to a format the AI could understand is not perfect. But I now changed it such that at least it should not imagine e.p. squares where there are none.

I'm slowly learning how to use this notation. Is there a way to define a piece that can jump over friendly pieces but not enemies, or vice versa?

'Officially' not. In XBoard's implementation there also is a modifier 't', (which stands for 'tame'). In combination with p in a non-final leg it limits hopping to friendly mounts, and in combination with c in a final leg it means you cannot capture royalty. I did not implement that in the Interactive Diagram though. I could of course do that, if there is any demand for it. But it would still leave the opposit case unaddressed, where you can hop only over friends. And we are running out of letters...

Perhaps a better solution would be to allow a more general way of restricting modifiers, though use of non-alphabetic characters. E.g. p' could be hop over friends only, and p" hop over enemies only.

I would like to make some extensions of XBetza notation. But not all of those would be backward compatible. So I want to poll opinions on how bad this would be.

W*, F*

Now that I defined the n modifier on stepper/slider atoms as generating e.p. rights, the rule that a 'flexible range' like fW* would always generate e.p. rights has become counter-productive. When this is wanted it could be described with fnW*, and the rule prevents use of the flexible range for pieces that cannot be e.p. captured. (Such as the Ninja Pawn of Hadean Chess.) So I would like to drop it. Problem is that there might be many diagrams around that rely on this rule for their Pawn moves.

The j modifier

I 'overloaded' the j modifier to mean a double step size on the first step of a sliding move, so that jB can be used to describe a Ski-Bishop. I would like to generalize this to all rider moves, with the understanding that on larger leap the modification of the first leap would turn it into the corresponding step (W or F). So that jAA could be used to describe a 'Skip-Bishop', visiting the odd squares on the diagonal (and not blockable on the even squares). The official (legacy) meaning, however, would be repetition of an Alfil leap that must jump over an occupied square. But it seems to me that no one uses, or would want to use such a move.

Flexible and free castling

Currently flexible castling has to be specified through a separate O atom for each possible King step. This because, in contrast to other atoms, a range on O indicates an exact range, rather than a maximum. This because that is usually needed for a castling. But not so for flexible castling, which on a very wide board then can lead to cumbersome notations like isO1isO2isO3isO4isO5. Perhaps it would be an improvement to extend the normal syntax of Betza notation, and allow specification of a range with the aid of a hyphen: isO1-5. A second problem are alternative castlings where the Rook does not end up adjacent to the King. The move definition would then not only have to specify the distance travelled by the King, but also where the Rook ends. Perhaps it is an idea to specify this as a 'decimal fraction' in the range: isO2.1 could mean that the King moves 2 steps, but that the Rook would not end next to the King, but keeps one empty square between the two. Then isO2.0 would mean the same as isO2.

I don't understand what you are saying about the j modifier, but the rest of it sounds perfectly reasonable.

So that jAA could be used to describe a 'Skip-Bishop', visiting the odd squares on the diagonal (and not blockable on the even squares).

Isn't this what AA already means?

AA repeats alfil moves, so it would move on even squares, not odd.

Ok, thanks. Now I understand. Like the Slip Bishop from the Seeping Switchers.

Yes, sorry. I mixed up Skip-Bishop with Slip-Bishop (George Jeliss' All-the-King's-Men terminology). The former indeed is synonymous with Alfilrider AA. Then jAA could be the latter. The only way to describe that now would be to decompose it as a number of (partially) lame leaps, like you can do with any rider: FafmpafFafmpafafmpafF..., with alternating mp and (default) m legs to ignore or test for emptiness all squares on the path

Ok, the j modification is a good idea then. FafmpafFafmpafafmpafF... is certainly not desirable :)

I'll get this implemented in ChessV. (The other two changes are not applicable - special rules like castling and en passant are not supported via XBetza.)

I am probably a bit late in commenting, but jAA has a meaning in Classic Betza notation (an Alfil-jumper-rider, i.e. a piece needing hurdles for each Alfil step it takes), and changing that meaning to something very ad-hoc is probably a bad idea. Either adding a new lowercase letter for slip-movement or attempting for a generic solution with different types of movement in the two legs of the move as in Betza's proposal t[FAA] would be better. Or new uppercase letters for the atoms slip-Rook and slip-Bishop.

OK, good point. Problem is that only the w is still unused as a modifier. And I am not sure the slip-pieces are the all-important application that deserves to use it. We are really running into a fundamental limitation of XBetza, namely that the entire move must be expressible with a single atom. Stride-halving (as in a ski-slider) is still relatively easy through including a dummy initial leg. But stride doubling would require indefinite repetition of a pair of steps of the initial atom, and there is as yet no provision for that. The natural way to do that would be to enclose the part of the description that can be repeated in parentheses (possibly followed by a number to specify a maximum number of repeats). For the Slip-Bishop that would give (afmpaf)F. This notation could also handle pieces like Mao-riders. Or circular / zig-zag riders. So it is a potentially very powerful device. But it is rather cryptic.

Capitals for new atoms are still in more abundant supply. We could do S for Slip-Bishop, and P for Slip-Rook ('Panda'). OTOH, we could also overload another modifier. E.g. q in the sense of circular doesn't seem meaningfull on slider atoms. So qB, qR and qQ could be Slip-Bishop, Slip-Rook and Slip-Queen.

The natural way to do that would be to enclose the part of the description that can be repeated in parentheses (possibly followed by a number to specify a maximum number of repeats). For the Slip-Bishop that would give (afmpaf)F. This notation could also handle pieces like Mao-riders. Or circular / zig-zag riders. So it is a potentially very powerful device. But it is rather cryptic.

Ultimately, we will probably want something like this, but I don't think we need it yet and I'm not currently available to work on implementing something this complex.  (Or even dedicating enough time to thinking about how it should go.)  So I'd table this for now.

q in the sense of circular doesn't seem meaningfull on slider atoms. So qB, qR and qQ could be Slip-Bishop, Slip-Rook and Slip-Queen.

This proposal seems perfectly reasonable to me.

Modifier repetition

The diagram now implements repetition of modifier groups through including those in parentheses: x(y)zA = xzAxyzAxyyzA.... This makes it possible to encode moves like a Mao-rider or Quintessence (= Crooked Nightrider). I was a bit dismayed, though, by how lengthy these encodings still are. The Quintessence, for example, would require (alar)N(aral)Nar(alar)Nal(aral)N. The problem is two-fold: because the move deflects alternately left or right, the smallest repeating group needs to contain two legs. But we need to indicate both moves with an even and an odd number of steps.

And to indicate that the two turns in the repeating group have to be made in opposit direction, we need to explicitly write l and r. Which means we have to write everything a second time for indicating the mirror image. That problem already existed for pieces like the Falcon, where the zig-zag path is either aflafrK or afraflK.

The z and q modifiers

So far XBetza used z and q only in their legacy meaning of crooked and circular pieces, respectively. There can be a very natural use of these in multi-leg move descriptions too, though. In particular in continuation legs (which then would never interfere with the legacy use on single-leg moves).

So in multi-leg moves we use z and q as alternatives to l and r. Where q means 'the same as in the previous leg', while z means the opposit. If there was no l, r or s in any previous leg, both z and q mean the same as s.

This allows move specifications like (az)N for the Quintessence, which 'expands' to NazNazazNazazazN.... The first z in a longer path can be read either as l or r, (so the descriptions actually define two mirror-image paths) and from then on they alternate. The zig-zag path of the Falcon can then be written as afsafzK. The Rose could be writen as (afq)N.

In ChessV, the q prefix on simple riders now makes them slip-riders.
qB, qR and qQ represent the Slip Bishop, Slip Rook and Slip Queen respectively. A number can follow to limit the length of the move.

A number can follow to limit the length of the move.

How do you count this? Single and double-length steps each count as one?

That's right. This is implemented internally as a step-then-slide move, same as the Gryphon move.

Chiral move sets

A problem with the group repetition is that the left-right reversed path for an oblique atom is not always equivalent. E.g. with 'sharp' turns (bl or br) for a Knight the path e4-f6-g4 (br) is a D step, while e4-f6-d5 (bl) is an F step. This requires splitting of the oblique moves into two chiral sets. This can be done by using hl or hr as leading direction set.

It is a tossup, however, whether the l or r specified in this initial direction set conforms to the path that follows. We therefore define two new direction sets, hs and hq, which by themselves would mean 'all directions' and are thus pointless. But when a repeated group contain z and/or q follows, the meaning of the latter will be determined as if the hs had mentioned the l and r that would be in the hl or hr set to which the initial step belongs, while the hq would count as the opposit direction.

That's right. This is implemented internally as a step-then-slide move, same as the Gryphon move.

Upon further consideration, this leads to a question.  "yafsF", the Gryphon move step-then-slide move, by itself, does not allow stoppong on the F square.  So, should "yafsF3" count the ferz-step toward the max range of 3?  I tried this on the sandbox and it seems to just lock it up.  My feeling is that it should probably count.

So, should "yafsF3" count the ferz-step toward the max range of 3? I tried this on the sandbox and it seems to just lock it up. My feeling is that it should probably count.

There definitely is a bug here, but yafsF3 should mean something entirely different. The rules for range toggling are that any range specs are dropped, and the basic atom undergoes slider <-> leaper conversion. So F3 converts to plain R (and the equivalent R3 would convert to F). So you should get (if it was not buggy) a two-leg move where the first leg is F3, and the second leg is R (with fs deflection, i.e. 45 degrees). That is, 1, 2 or 3 diagonal steps, followed by an unlimited orthogonal slide.

There is no way in XBetza to get a limited range in a continuation leg. Perhaps this is a mistake, as hook movers are not very common. So it might be better to apply a specified range to the final leg, rather than to the first.

Without range toggling (afsF3) the range is taken as the total. But that would not specify where it has to turn the corner; it could be 2xF + W or F + 2xW.

The rules for range toggling are that any range specs are dropped, and the basic atom undergoes slider <-> leaper conversion. So F3 converts to plain R (and the equivalent R3 would convert to F). So you should get (if it was not buggy) a two-leg move where the first leg is F3, and the second leg is R (with fs deflection, i.e. 45 degrees). That is, 1, 2 or 3 diagonal steps, followed by an unlimited orthogonal slide.

Well, ChessV doesn't support that kind of move, so I guess I will just drop support for the integer at the end.  You can still define what I was suggesting, just not with XBetza.  For example:

SomePiece.Step( <1, 0> ).SlideAfterStep( <0, 1> ).MaxSteps = 3;

Which is more verbose than the typical XBetza, but probably easier to understand.  ChessV only takes a subset of XBetza anyway, since it is restricted by what the internal move generator can handle.  (XBetza isn't interpreted to generate moves - which would be too slow - only to configure the piece so the move generator does the right thing.)  For moves that turn along the path, it only supports: step-then-slide; slide-then-step; or a fixed number of single steps (e.g., the Falcon.)  As such, the y operator is defined directly into the ANTLR grammar as a special case and can only appear once.

Does XBetza allow defining pieces that capture by stopping in the square just before the captured piece?

Also, somewhat related to that, I was thinking there are a lot of potential pieces that could be defined if it were possible to specify different priority levels for movement options, such that a piece must make the highest priority kind of move available. For example, there might be a piece that moves as a queen, but can only make a non-capturing move if it has no available captures.

Another question I have is, does 0 have any meaning when used as a piece's range? If not, perhaps it could be used to indicate that a piece must move as far as possible in whichever direction it goes.

Does XBetza allow defining pieces that capture by stopping in the square just before the captured piece?

yamcfyambK comes close to defining a Queen that does that, aka Rococo's Advancer; it is, however, what Charles Gilman called a ‘Strict’ advancer, in that it also can't approach a friendly piece (as doing so would capture it), as well as (as a byproduct of the implementation) being unable to approach the edge once it's left it. Adding mQ would lift those restrictions at the expense of making the capture upon advance optional. Idk if it's possible to do better without extending the notation though

Another question I have is, does 0 have any meaning when used as a piece's range? If not, perhaps it could be used to indicate that a piece must move as far as possible in whichever direction it goes.

Afaict (istr it was declared explicilty at some point though idr where) 0 corresponds to unlimited range. gabQ handles going as far as possible provided there's a piece in the way, but is subject to the same edge case(!) as the advancer wrt the boundaries of the board — again I doubt it's possible to contrive a way around that without dedicated extensions

Beware that y is an alternative mode to m or c. So that yc would range-toggle on an empty square, but not when you make a capture. It is true that Advancer capture has to be specified as a 3-leg move, to exclude pure rifle capture to an adjacent square. But the proper way to do that is make the first leg the slider move to the final destination (which always should be empty), and from there make the rifle-capture step in the forward direction: yafmcabQ. This still suffers from the edge or a friendly piece blocking the move.

A possible extension of XBetza would be to allow use of o on non-final legs in the meaning of moving beyond the board edge. (Which basically is also what the original Betza o does on a final leg, except that it then maps the piece back to the board as if the latter were a cylinder.) By writing yafmcoabQ the problem of approaching an edge would then be solved, as the second leg could then go to an empty square, an enemy or off board. The only thing it could not do was approach a friendly piece.

If the second leg would also have a p mode it could hop over a friendly piece, solving the problem of blocking by such a piece. But alas, it could then also hop over an enemy piece, so that capture becomes optional. In the XBoard implementation of XBetza there is a t modifier, which in combination with p or g would mean friendly hopping only. But the Interactive Diagram does not implement that. But since the introduction of the u ('unload') modifier, there is an alternative: instead of a hop on the second leg you can specify a friendly capture d, and then on the next leg unload the captured piece: yafdabuQ. (This relies on a u leg unloading the piece that was captured last during the move, not necessarily the piece captured at the final destination.

y is an alternative mode to m or c. So that yc would range-toggle on an empty square, but not when you make a capture.

It seems to range‐toggle on capture in my informal testing in the sandbox: a yamcfyambK on g3 capturing a pawn on g11 is only allowed to move to g10 as its final destination (whereas a yamcfambK, w/o the second y, can move back as far as it wishes). Is that a bug?

yafmcabQ is probably more elegant in any case though

This seems very, very complicated. I think capture-by-advance and capture-by-withdraw are worthy of "direct" support. I know we are running out of modifier letters. How about we take one of the remaining letters and use it exclusively as a prefix to give us 26 more? For example, if "x" is unused, x would be a prefix and we could say that xa is capture-by-advance and xw is capture-by-withdraw. And, if we should ever need even more, we could start using xx as a prefix.

That would give new meaning to the name xBetza.

x is already taken sadly (for move‐relayers that ‘eXcite’ other pieces). Afaict the only (ASCII — I'd wager few would support using þ, ß, ⱶ, ⁊c.) letters that aren't yet used in XBetza are t and w — of which the former had a meaning for Betza himself (though iirc the article he introduces it in also features incompatible meanings for a number of other letters). w as a prefix (to ‘widen’ the available options?) sounds plausible I think

What about using numbers after lowercase letters to indicate separate meanings? It might look weird, but it would allow using any letter any number of times.

I think notation would be intuitively more clear with punctuation characters rather than digits as suffix to lower-case letters. E.g. c' or c". That gives me an idea: the range-toggle could be decoupled from the move mode, by using a' for starting a new leg with range toggle, and plain a for starting a new leg of teh same type. That way the y and g on non-final legs could be deprecated.

Suffix char is fine too. I don't really think a' is better than the current y, though, and adding new options and deprecating should be avoided in my opinion unless it's a huge win. Besides, a' should probably be capture-by-advance. Sure, there's " but I would avoid multiple suffixes as long as reasonable.

While it is true that ya = ma' = a', and ga = pa', there was no such thing for ca' or da'. If Advancer capture would be worth having its own symbol, it would seem more natural to me to make that c'. I am not sure it is, however; Advancers are not that common, so that it isn't too bad if their description is a bit complex. Furthermore, I can imagine several variations on this kind of capture, e.g. where the piece ends two steps before the piece it captures, or that it captures the nearest piece in the direction it moves. Having a dedicated notation for each of those would lead to a proliferation of dedicated (rarely used) modifiers. I'd rather have a powerful general system relying on commonly used modifiers.

Advancer capture seems related to Fire-Demon burning. It would be nice to have a method for appending a 'burning leg' to a move, which would not actually be made by the moving piece, but would execute the operation specified by the mode (c, d or e) there whenever it is possible, but would not block the move if it is not possible. Say we would specify this as t (for 'terminate'). Then the Advancer could be yaftcQ: a Q move to an empty square with range toggle (y), after which the move can terminate, but must continue in the forward direction (with a single step because of the range toggle) to capture if there is anything to capture. Without the f it would have been a Queen that burns like a Fire Demon. (A Fire Demon would be vsvmca'tcQaamcatcKamcatcK.)

[Edit] An alternative for using a new modifier is to indicate burning by cc (or dd). Duplication of characters is a common device even in the original Betza notation (e.g. NN = Nightrider, ffN = Shogi Knight). An Advancer would then be yafccQ. There would be no need to invoke quoting, or use the t. The latter could be used as an alternative to a, for starting a new leg with toggled range (so that it would obviously stand for 'toggle'). That would allow range toggling on a capture, such as would be needed to describe Fire-Demon-like burning (mctccQ = slide to move or capture, and then burn all adjacent foes).

I wonder whether it would do any harm to redefine the meaning of y as just indicating a range toggle, rather than m with a range toggle. The meaning of the combination ya would remain the same, as a without any explicit mode indicator defaults to ma. Only in combination with an explicit mode it would make a difference: currently ycaX means yaXcaX, i.e. a range toggle on an empty square, or a locust capture without range toggle. While the new meaning would be a locust capture with range toggle, without the possibility to end the first leg on an empty square.

The point is that I cannot imagine a combination of a range-toggling mode and a different non-toggling mode would ever be needed. In fact it appears that in the XBetza implementation of the Interactive Diagram (and its conversion to GAME code) such combinations don't even work as the old definition of y required. Due to a bug the range toggling specified by y already 'leaks' into modes that were specified as alternatives to it, and up to recently this was never noticed.

This redefinition of y removes the need to resort to using non-alphabetic characters for now, as ya takes the function of the proposed a'. The modifier t can then be kept in the proposed meaning of 'terminate', (as alternative to a) to indicate the remaining legs of the path are not performed by the piece, but just administers its 'influence' (such as burning). On second thought using an explicit indicator for the start of the 'influence path' is more versatile than using a separate mode (like cc) for burning, because it also allows burning according to a multi-leg path. The latter might be needed to emulate burning of non-adjacent pieces through a (dummy  or lame) intermediate square.

With this new meaning of y, the Advancer would be ytfcQ. An Advancer that stops 2 squares before its victim would be ytfafcQ, and one that captures the first piece in the direction it moves tfcQ.

I also gave some thought to the issue of 'initial' moves. It is reasonably common that such moves depend not on whether the piece was moved before, but on whether it is in its initial location. E.g. for Pawns in Crazyhouse, which have the double push on the 2nd rank even when they were moved, captured and dropped before. This interpretation of 'initial' could be indicated by a leading ii on the move, instead of just a single i.

The ii modifier (or something similar meaning the same thing) is a genius idea. For the burning, there may be some merit to having something to determine certain specifics of the burning move (i.e. whether the move is passive as well as active, and if it is, which piece has priority in a conflict b/w the burning pieces) with diagram parameters. XBetza wouldn't necessarily be able to handle those specifics on its own.

Are any of the ideas here: http://chessvariants.wikidot.com/joe-s-strange-notation of any value to extended Betza notation or piece icon design, or are they too divergent? My iconology attempt was to define the move of the piece with the icon without using actual footprints or numbers, and I haven't seen any other attempts to do so, although I haven't been very active recently.

All these pieces can already be described through the general mechanism XBetza uses for multi-leg moves. The notation you proposed is much less general, and can handle only some very specific cases. E.g. D/W describes a W followed by D as well as a D followed by W move, as well as simple W or D moves. But what if there is a piece that only does simple W, or D after W? In XBetza you can describe each of these moves separately, e.g. mafmpafW would be a move that makes 3 W steps in a linear fashion (f), where the square reached in the first step must be empty (m), while the 2nd square should be empty or hopped over (i.e., its occupant is completely ignored, mp). That is, it is a W followed by D. The bent version would be mampafW, i.e. it would drop the directional f restriction after the first step. Writing an s there would force a 90-degree turn at that point.

It is true this makes the description of your  W/D a bit cumbersome (WDafmpafWmpafafW), but that seems justified for a piece that really has a rather elaborate and complex set of moves: three different ranges (WDH), the latter half lame in a multi-path way (can be blocked by two, but not by a single piece). By assigning a very specific (and therefore hardly ever useful) meaning to a certain notation, you can of course always be more compact in the rare case where that notation would be useful.

Note that when the Betza j modifier is interpreted as 'must jump over exactly one piece', the W/D could be written as WDnHjH, which is also not so bad. And at least allows the piece to have an nHjH move without having either W or D.

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.

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

The Snaketongue is simple: a vertical W step followed by the outward turn is simply vWvyafsW (same as the manticore but with v prepended to each component).

The ship is trickier, as the first step can be in any direction and by the second step there's no way to specify which is the right twist (as there hasn't been a bend yet and l and r are relative). It may be worth special‐casing z and q here too(?) but meanwhile it can be done in a slightly hacky way involving the mp modality trick (i.e. a square that can either be empty or a mount, so it doesn't matter what's there). That gives two solutions: FvmpasyazW which (other than the F step) moves one forward, ignoring wahatever is there, turns 90° for another W step, then turns 90° again for the rest of the Rook move; or alternatively smpyasW which steps one space sideways, ignores what's there, then turns 90° and continues, now vertically, as a rook (note this latter one already includes the F step)

@HG:

quite incidentally while trying some of these, I input yafqF as a move, which seems to give a pandacub (Gilman's name for the forward‐only Slip‐rook, ft[WDD]) for some reason? Not sure exactly what I expected (though sth gryphon‐like would have made sense I think?) but it definitely wasn't that.

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...)

@Bn Em: your trick for the Ship with the z is clever, but makes the description even less intuitive. When I made the Tamerlane II diagram this alternative use of z did not exist, though. I am not sure if defining a meaning for z and q without first using an s would be helpful. But, come to think of it, s is a dummy on a diagonal atom, as lF is the two left moves, and rF the two right moves, so together these are a full Ferz. But such a dummy s could be used to define the symmetry breaking as used by following z or q. I guess it would be most useful to define it such that it causes the diagonal atom to be interpreted as an oblique one with the longest leap in the sideway direction (i.e. as sN would have been interpreted). Then the Ship would be FsyafqF.

I have no idea why yafqF does what it does. Without a preceding s or oblique leg it triggers the code for the old Betza meaning, which lays out the entire path for the circular piece, with a special mode flag to indicate it can be terminated at any square along the path. But the preceding leg must utterly confuse it...

Thank you HG and Bn for your answer, it's fascinating, although I can't understand everything.

I have tried the strings you said for the Ship. Not all of them work. Maybe I haven't caught what you meant.

flbryafrFfrblyaflF: doesn't work. It skips the F-square

smpyasW: it works, but I really don't have the skills to understand why (it looks like "sympa" a French equivalent of "cool" or "great" that you say when something is nice)

FvmpasyazW: doesn't work. Strange pattern: B+incomplete Manticore

flbryafrFfrblyaflF: doesn't work. It skips the F-square

That is correct. But then you simply add it explicitly: FflbryafrFfrblyaflF.

All the bent trajectories you can specify with XBetza skip the first square (or actually the entire first leg if it is more than a single square, or even all non-final legs if they have more than two legs). All legs mentioned in a description are compulsary, and must contain at least one step if they are sliding.

This was a choice; it could have been defined such that slider continuation legs can make 0 to infinite steps, rather than 1 to infinite (like the initial or only leg can). But what would you do then for a piece where you don't want that? E.g. a Griffon that cannot move to the F squares, even though it can be blocked there? It is much easier to add the F moves to a piece that not naturally has those, than it would be to prevent it from stopping on the first square of its path. So asR is a hook mover that must turn a corner, and cannot move like a simple Rook. If you would want it to move as a simple Rook as well, as the Hook Mover from the large Shogi variants can, just write RasR.

smpyasW […] looks like "sympa"

Well the ship is certainly a sympathic piece ;‌)

FvmpasyazW: doesn't work. Strange pattern: B+incomplete Manticore

Sounds like a Crooked Rook (=Girlscout) move to me, which would make sense in the old/non‐continuation‐leg interpretation of z. It gives me a Ship when I try it; maybe try refreshing your Cache? (Ctrl–Shift–R)

BTW, I now made it such that FsyafqF for the Ship works too. (Refresh cache!)

Explanation: q in a continuation leg stands for l or r that would bend the path in same direction as before / initially. So fq can mean either 45-degrees left or right. Now the s at the start of the multi-leg part defines 'sideways' as the initial direction (which for diagonal atoms would otherwise be ambiguous). So the move toward the lower right bends to the right (if you imagine it to start to the right), so it bends 45-degree right again for the second leg, which makes that move straight down. The move to the upper right, however, had to bend left if it startes horizontally to the right. So the leg after that one bends left, making it move straight up.

Bright! Thank you

I am still a bit unhappy with the need for an s prefix on a diagonal atom (where it does not select any initial direction) in order to define a meaning of q and z in following legs. Perhaps we should always classify all moves of an atom as either bending left or right; for oblique atoms this is natural, as the left and right moves are mirror images. For orthogonal and diagonal atoms this would be artificial, but could be adopted as a convention. E.g. on a diagonal atom fr and bl could be defined as bending right, while fl and br could be defined as bending left. For an orthogonal atom we could define f and r as bending right, and b and l as bending left. (I cannot imagine a case where this would be useful for f and b, though.) A Ship would become FafzF with these conventions, as we want the initial fr step to bend left, i.e. in opposit direction as the (artificially assigned) initial bend.

@Jean-Louis:

I would still like your opinion on whether you think F(F-fsR) would be a less cryptic notation for the Griffon (and F(F-fzR) for the Ship, KNAD(cK-K)(cK-bK)(K-bK) for the Chu-Shogi Lion, where (cK-bK) is the igui, (cK-K) the locust and double captures, and (K-bK) the turn pass). Or perhaps F[F-fzR] with brackets instead of parentheses?

[Edit] Just to try it out a bit I now made it such that notations like [fF-fsR] are also accepted for multi-leg moves. The interpretation is still very flaky, though. Basically the atoms mentioned in the later legs are ignored, except their range (which must be leaper or infinite). The direction is purely derived from the angular spec in front of them. So it does not matter whether you would write B, R or Q as continuation leg. I suppose that I could make it such that it checks whether the directional spec is compatible with the mentioned atom, and issue an error message when it is not. Nice feature is that the first atom can be a distant orthogonal or diagonal leap, and then combine with a slider in the next leg. So the Osprey would be D[D-fsB]. It can also be made non-jumping, e.g. R2[nD-fsB].

@HG: I'm embarrassed to answer you. I see Betza's notation as a convenient and intuitive way of describing the moves of a chess piece. I believe XBetza's notation has another goal, that of being able to be understood by an AI for the cases not covered by the basic notation. In that respect, what you have done works. I can't say which form is the best because I am very soon lost in the deciphering (even with strong effort, I'm lost in the explanations).

I would have said that a Ship should be something like F&$vR, I use other characters as examples, but they could be anything, & meaning "then" and $ meaning "away from the starting square in both x and y". A Gryphon would be F&$R, a Snake vW&$B, an Osprey D&$B. That would permit to differentiate a N&$B (Unicornio from Grant Acedrex) from a N&$R (used in some large CVs).

But this is just a "user's" point of view, ignorant of the constraint of programming and consistency with the rest of the XBetza language.

I see Betza's notation as a convenient and intuitive way of describing the moves of a chess piece. I believe XBetza's notation has another goal, that of being able to be understood by an AI for the cases not covered by the basic notation.

In principle there is no limit to what an AI can understand; it is just a matter of how much effort you put in creating it. And I subscribe to the goal of making move description convenient and intuitive, even for moves that are intrinsically more complex, such as the Griffon, Falcon or Chu-Shogi Lion. So think it is worth it to put a great deal of effort in achieving that goal.

But for any system of notation it seems important that it is unambiguous, and covers sufficiently many cases. Betza himself has suggested the t[F,R] notation for Griffon, but this is not unambiguous, as an 'Acute Griffon', which would continue inward instead of outward, making a 135-degree turn, (or the piece that can continue in all four Rook directions), would be written the same. Furthermore, the leading t seems redundant here: the 'then' meaning could be implied by the presence of the brackets. I think Betza suggested also other uses for the brackets, like z[F,W] for a slider that alternats W and F steps in a crooked way, but this distinction could also have been made by using other separators than comma for that, e.g. [W/F]. Once non-alphanumeric characters are allowed in the notation, lots of options are available.

I hope you agree that it hardly matters for the intuitive understanding whether one would write F&R, F-R, [F-R] or [F,R]. But now suppose that we want to slam extra W moves on a Griffon... I don't like WF&R so much, because intuitively you would parse this as (WF)&R, as punctuation usually separates 'words'. While it is intended to mean W(F&R). This is why I think it would be better to require some sort of parentheses around the complex moves. And to stay as closely as possible to Betza's legacy, these can be brackets. With W[F-R] there is little doubt that the W is a separate move.

The ambiguity problem has to be solved by putting some directional specification on the continuation legs, to distingush outward from inward, or even between several possible outward directions (such as in the case of the Ship). In your example you suggested a new prefix character ($, as we have run out of letters) for indicating 'outward'. This has the advantage that we can keep using the original directional modifiers in the meaning they have in the absolute frame of reference. This works well for the Ship, where you can write F&$vR to make the extra v pick out the vertical of the two outward Rook paths.

But I wonder whether introducing a whole new system for indicating relative directions is worth it. For one, the use of an absolute direction to disambiguate equivalent relative directions only rarely works; the Ship is a favorable case. It would for instance not work on a 'Chiral Griffon', which would bend always in the same relative direction (left or right), to give a rotation-symmetric rather than reflection-symmetric move pattern. And how would you know that in N&$R 'outward' would mean 'in the direction of the long component'? Some are v and others s so you cannot use those to indicate it. And if you define the meaning of 'outward' on oblique moves as in their long direction, how would you describe a piece that would continue like a Rook in the short direction of the knight move? It seems that we would have to create a whole new system for describing relative directions, or groups of directions, similar to the existing Betza system for absolute (initial) directions, but using puntuation characters instead of the familiar fbvlrs. That would involve a lot of new characters, but perhaps these could be chosen in a somewhat intuitive way, so they would not be too hard to remember (like ! for outward, ^ for inward, < for turn left, > for turn right, _ for < or > and | for ! or ^). But it still seems a hassle, which can be exploited only very rarely.

So I think there is a lot of merit in sticking to the existing Betza scheme for indicating directions, but interpret them as relative directions on continuation legs. Then instead of needing a new symbol like $ or ! for 'outward', we can simply use f for outward. In a sense the Betza directional modifiers have always been relative: for simple moves they are relative compared to the way the player is looking. We also say fmWfcF for black Pawns! (And in a 4-player game even v and s have player-dependent meaning.) Is F&fR really any less intuitive than F&$R ? You would lose the possibility to disambiguate the two outward Rook moves by use of an absolute direction, but you now have a simple way to write a (right-handed) Chiral Griffon: F&frR. One always has to compromise: what makes one piece easier to describe, will make some other piece that behaves in the opposit way more difficult to describe. I think it would be a mistake to judge a description system solely on how well it does on a single piece that you happen to use, but is not very common, and even less representative for the general problem.

There also is a more fundamental issue: writing the Griffon as F&fR or [F-fR] assumes the move can also be terminated without making all its legs, after just the F step. It might be subjective whether this is intuitive or not; it seems to me that this is mainly inspired by the case at hand (i.e. bent slider). Problem is there are many other cases where you would not want this. E.g. lame leapers like the Mao also need a multi-leg description to indicate where they can be blocked. But if W&fF or [W-fF] also allows making a W move, how can we describe the Mao then? And if fcF&fmF would also allow plain capturing diagonally forward (fcF), how would we describe the Checker? We do need a way to describe complex paths that cannot be terminated half-way. One way would be to forbid incomplete moves, so that these have to be described as separate moves when they are desired. (Advantage: no new notation needed. Disadvantage: move descriptions get longer.) The alternative is to introduce a different symbol for continuations that are only optional. E.g. [F~fR] could mean a Griffon that can make F moves, as the fR continuation is optional. While [F-fR] could not make the F move, although it can be blocked on the F square, as the fR continuation is mandatory. Actually I sort of like this latter solution, even though it requires introduction of a new symbol.

I would also like to have some feedback from other people, on what they would consider intuitively clear in these matters.

I think mpsyasW is pretty clear, but perhaps not very intuitive. What if doubling a direction made it absolute instead of relative? Then the ship could be something like FyafvvF or FyavvsF. It's not clear to me how exactly combinations of directions should be interpreted.

I think mpsyasW is pretty clear, but perhaps not very intuitive.

Well, I think it is a justified complaint that it is not easy to see that there is a Rook move hidden in there. The bracket notation [smpW-sR] would make that more explicit. The notation of a full Griffin based on this idea would be [mpW-sR], and would automatically visit the F squares, as these are now reached by the first sideway Rook step. But it literally requires some 'out of the box' thinking to detour the trajectory over an auxiliary square (sW), and subsequently make that square fully transparent by giving it mode mp. And this obscures the fact that in reality the first square visited by the piece (in the sence that it can move to it or be blocked there) is an F square. That distracts greatly from the intuitiveness.

Doubling of directional modifiers is a bit tricky, as sometimes it is needed to prevent such modifiers from combining to the intermediate direction. E.g. if we want to describe a Knight that lacks the two backward-most moves, we must specify an s and an f direction on it. But we cannot just write fsN, as this means flNfrN, and fl and fr describe individual N moves. To prevent that we write ffssN.