Comments/Ratings for a Single Item

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.