Comments/Ratings for a Single Item

It seems to work for me: I get a 'Pao version' of the Gryphon. Can you give an example of a constellation of pieces where it doesn't work?

I've added an example, I will do more when I am back home

OK, I can get it too now. It only appears to add the spurious Rook moves in two directions, and only when the mount is on an F square. In fact the piece behaves like a bifurcator, going to the second leg not at the mount, but one step in front of it. It is apparently the yafscpF contribution that does this.

And it seems to be caused by the 'original' use of 'p' in the final leg. When I use 'p' in the new meaning of ending on an occupied square for a non-final leg, as in yafscpafF, everything works fine. Which is surprising, as the Betza parser should convert p to paf on any final leg, on reading the description, so that they really should be the same thing. This is apparently what goes wrong.

This is definitely a bug in the Interactive Diagram code. I will look into it. Thank you for reporting it!

[Edit] OK, I have fixed it. The problem was that the Betza parser turned the old-style 'p' on final legs to a multi leg move, by making it into a non-final leg with 'p' mode, and adding an extra leg for the part of the trajectory after the mount. In the internal representation each leg lists how many legs still follow, so that they can be skipped whenever an earlier leg cannot be completed. The existing parser did not increase this skip count on legs before the leg with the old-style 'p', so that when they were blocked the newly added leg for after the mount was not skipped, but was considered another independent move. So when the first F step in yafscpF could not be made because of a blocker, it would transplant the path that should have come after the mount in the second leg to the piece itself.

I also fixed another problem: finite-range hoppers were not working properly. E.g. pR5 would not be an R5 that had to pass over exactly one obstacle, but would be a pR that could only land on the first 5 squares behind the mount. I think in original Betza notation the range should apply to total range, and changed the code accordingly. Downside is that it is not easily possible now to describe hoppers with a fixed finite range after the hop. (Unless that range is 1, in which case the range-toggling 'g' modifier can be used.) I suppose an 'Extended Grasshopper' that could land (precisely) 2 squares behind its mount can still be described as gafafQ (where gafQ would be an alternative notation for gQ, the normal Grasshopper).

Note that caching on this website is broken, so that you might not be able to benefit from the fixed diagram code I uploaded until the site maintainer takes manual action to make the changes visible!

I also suggest adding the hovering pawn in  for pieces like mNmcafsW on the movement diagram

Indeed, its absence is unintended. When we split the mc leg into mNmafsWcafsW it does work as intended, so the presence of both m and c on the same leg seems to confuse it. I will have a look at the script, to see if it is just a matter of more carefully recognizing the condition that has to add the pawn on hover, or whether the Betza parser should already split up such move in the internal representation.

[Edit] OK, I fixed it. It was not only that the hover did not work, but the W squares were not indicated at all as (locust) capture targets in the primary move diagram. Turned out the code for indicating those was in a branch that only treated cases where there were no m rights. Now I also test for locust captures on non-final legs with m rights, and that automatically makes the hover work as well.

Another bug, on the movement diagram squares that may be only reached to capture own pieces are labeled red instead of blue.

OK, I sort of fixed this too. To show the move diagram the move generator must be run in a special mode. Normally (i.e. when playing moves on the board) it would just indicate the pseudo-legal moves. But running t on an empty board for the purpose of displaying a move diagram would then omit all captures. So in this mode it applies extra highlights on empty squares, to indicate what could happen there if it was occupied. In particular red or yellow highlights when enemy pieces could be captured there. (And it also indicates 'virtual' hopper mounts / locust victims on the end-point of non-final legs.)

But the highlighting for the 'destroy' mode (capture friend) is not really well developed. There are 7 possible non-empty combinations of mcd, and mc (yellow), m (green) and c (red) have their own color. There are no distinct colors for d, md, cd and mcd, though, there only is blue. Considering that I haven't really encountered any variant where friendly capture is possible, it seems wasted effort to elaborate very much on this. The problem is compounded by the fact that the highlighting for entering moves is not completely consistent: on empty squares it distinguishes mc (yellow) and m (green), even though capture is never possible there for lack of anything to capture. But actual captures are always highlighted in red, without distinction between mc and c. So when an mcd move hits an opponent, should I highlight in red, to indicate it is a capture, or in blue, to indicate that a friendly capture would also have been possible on that square?

I would use a overlapping red and blue square for cd (I first thought about purple, but that would be too confusing with blue)

I don't know. Divergence is rare, friendly capture even rarer. If the latter occurs at all, I would expect it to be as a special rule that captures in general can also take friendly pieces. I.e. that d would imply cd, and on all pieces except Pawns even mcd. In that case the only possible confusion would be between mcd and cd in a move diagram. We could use a blue circle for mcd, but the diagram also has a mode to use background colors for highlighting, and what to do there? Lighter blue, perhaps? Using the same shape marker with another color is bad practice to begin with, as the markers were intended for use of pure black & white displays (e-readers and such). I am not very keen on preparing for stuff that might never be encountered, such as divergent pieces that capture enemies in a different way from capturing friends.

BTW, when I fixed the hover thing, I also added hover squares for squares where lame leapers can be blocked (i.e. non-final m-only legs), so that hovering over them would place a blocker, and make the moves passing over it disappear (like it would make hopper moves over it appear). I am not sure whether that was a good idea; perhaps I should use anothe color / symbol for such squares.

It seems that there are very few to almost no variants having capturing own piece, similarly to how outside XQ there are no variants with a separate checking move (but that has a separate modifier as well). I would suggest making the friendly capture marker hexagonal and the checking marker (currently no marker) octagonal dark red or a crown.

The 'unload' modifier

I have been working on an extension of XBetza notation in WinBoard/XBoard: the 'u' modifier. This stands for 'unload', meaning a piece that was captured elsewhere is not removed from play, but reappears in a new location. This to allow pieces that displace others.

After some thinking it occurred to me that it would be best to have a move that has a 'u' modifier to unload the piece on the starting square of that move. This in contrast to other mode specifiers (such as 'm' or 'c'), which specify what the move can do on the destination square. This because the destination square is bound to be occupied by the piece that moves, while the starting square will naturally be emptied. Of course this could be cured by having unloads only on the destination square of a non-final leg of a multi-leg move, but that would just lead to complex representation of simple moves.

So ucR now means a Rook move that captures on the destination, but unloads that captured piece on its starting square. In other word, a move that can swap location with an enemy piece. Similarly, udR would describe a swap with a firendly piece, as in XBetza 'd' stands for "capture friend".

Of course it is possible to use the 'u' in a multi-leg move as well. E.g. afudQ would describe a Queen with a two-leg move. The first leg to an empty square ('m' is the default mode for non-final legs in XBetza), the second leg continuing (as Q) in the same direction ('f'), and doing the friendly swap (udQ). Normally a slider move continuing in the same direction would be pointless. (Well, not entirely; it guarantees the length of the move is at least 2.) But now that the intermediate square (start square of the second leg) is used for unloading, it suddenly becomes relevant where on the path it is. Like with locust captures, the user entering a move would first have to select the intermediate square (which WinBoard indicates by highlighting it in cyan, as with locust victims). After which the target square(s) get marked (in this case only one), and clicking on that would finish the move, where the piece in the destination is bumped to the intermediate square. This is part of the Valkyrie move in Odin's Rune Chess. The full Valkyrie would be QudQafudQ, a normal Queen, a Queen that swaps position with a friend, and a Queen that displaces a friend to a formerly empty square on the path it took.

Move induction

In Knight-relay Chess a Knight induces extra Knight moves in friendly pieces that are a Knight jump away from it. In the Interactive Diagram I used an ad-hoc extension to the move description to indicate such a thing, by considering the induction step (from inductor to induced piece) plus the induced move as a single multi-leg move. The first leg of this move then carried an 'x' modifier, indicating that it wasn't a real move, but just an interaction that 'excited' the target to make the step described in the following leg(s). In XBetza notation, where legs are separated by 'a', this would be xaN. So far so good.

But in Odin's Rune Chess, the King doesn't have a move of its own, but can move as any of the adjacent friendly pieces. To describe that with move induction would be awkward; every non-royal piece must be an inductor, but they would not induce their move on any piece, just on the King. They would be selective move inductors, and so far XBetza has no device to specify such selectivity.

But then it dawned on me that I was looking at this from the wrong perspective. The non-royal pieces in Odin't Rune Chess are not (selective) move inductors, but it is a universal property of the King, which is a move borrower. If we could define a move descriptor for that, it would only have to be applied to the King, and would not have to be type-selective.

Fortunately the same 'x' can be used to indicate this, by strapping it on the final leg of a multi-leg move (or on a simple move); its use in move induction will always be in a non-final leg, as the induced move must follow. So if no move follows an x-leg, it can be taken to mean reverse excitation, from target to source, instead of from source to target. The King in Odin's Rune Chess would then be fully described by the XBetza notation xK: borrow moves from pieces a King step away.

I wonder if this system is universal enough to handle most cases of move induction that occur in CVs. Are there any other variants that use move induction? I only know of Scirocco, where the Dervish, and its promoted form the Harpy, are universal move inducers similar to the Knight in Knight Relay Chess.

There is the Mimotaur, invented by V. R. Parton.  The mimotaur moves as a queen when not capturing.  When capturing, however, it must move as the piece being captured.

Ummm... That could indeed be seen as some sort of induced move. One difference with the previous cases is that it induced by a foe rather than a friend. So far the 'x' modifier was only assumed to work on friends. I guess 'x' could be defined as a 'combining modifier', so that xc doesn't mean you can capture or induce, but means you can only induce foes. (And then xd for friends.) This is not unprecedented in Betza notation; e.g. in frF the f and r also combine, to indicate the intermediate direction.

But a reciprocal capturer is pretty awful to describe. You would either need to make every other piece a selective inducer acting only on the Mimotaur, or treat the latter as a move borrower. Which would have to make it borrow through a host of different moves, each type-specific, and furthermore raise the problem that it should only borrow the move in that direction. An alternative is to equip the Mimotaur with a host of different type-specific captures. If you would need type-specifity anyway, that would be a lot simpler than treating it as induction. But imagine how long the move description would get if you would add a Mimotaur to Tai Shogi...

None of these solutions seems very appealing. Yet the idea of reciprocal capture is not so outlandish; the Ultima Chameleon has it too. (Of course in that game it must then capture in all kinds of weird ways, rather than through all kinds of moves.) I would be inclined to solve it in a completely different way. XBetza notation has used up almost the entire lower-case alphabet, but capitals are still plentiful. So it seems a workable idea to define a new atom (say M for Mirror) that does not have a fixed move, but borrows the move from another involved piece. So cM would mean reciprocal capture.

But a reciprocal capturer is pretty awful to describe.

I had a feeling it would throw a wrench in the works but you did ask :)

So it seems a workable idea to define a new atom (say M for Mirror) that does not have a fixed move, but borrows the move from another involved piece. So cM would mean reciprocal capture.

This seems reasonable

I guess that if we are adding new, flexible-move atoms, having I for Imitator (i.e. a piece that moves as the previously moved piece type) could be a useful addition too. This is also a reasonably common occurrence.

My concern with the Immitator is that it is a complex concept and we don't really know what it means.  A couple discussions of this over the years have demonstrated that it is a very tricky concept with different interpretations.

Well, I suppose that those discussions mainly were about what should be considered 'in check' or 'passing through check' in the presence of an Imitator. And that isn't really a subtlety of the Imitator, but of the checking rule employed by the CV. That is outside the scope of Betza notation, which only has the purpose of indicating pseudo-legal moves.

The main problem I see is whether the imitation is 'recursive', in the sense that it would be able to imitate a previous imitator. The same problem exists with move borrowing, btw. The way I currently implemented that in XBoard aims to be non-recursive. Because Odin't Rune Chess defined it that way, but also because recursive borrowing easily leads to infinite recursions, when two move borrowers can borrow from each other. You would have to keep track of which pieces you already borrowed from. Or better yet, which moves you already borrowed, so that you would never generate duplicat move. For XBetza duplicats are not a crime, though; you can for instance say KR or DR, where the first is sloppy, but a unique alternative for the second in unreasonably cumbersome.  For Imitation this problem doesn't exist, and I think the most common type would be recursive, imitating the last-moved non-imitator.

There also is the problem whether you imitate special properties of a piece (like promotion), or just the set of target squares. But this problem also exists with move borrowing or induction. E.g. in Knight Relay Chess you cannot promote a Pawn through an induced Knight move. (You cannot even move it to first rank, so this is really a confinement issue.) But promotion is again outside the scope of Betza notation, the latter just describes methods of locomotion. There are some CVs where the set of moves that allow you to promote is not equal to that where you can defer promotion. (In particular micro-Shogi, where you (mandatorily) only promote only on capture, but there also are variants where you can promote on a null move in the zone, while plain null moves are not allowed.) This would be most conveniently described by just giving a separate move description for promoting moves.

There is an article about 'Mimics' here on CVP, which I stumbled on when looking for Mimotaur. It also mentions a 'Strict Imitator', which imitates the actual move, rather than the piece type. I would say that is just another atom.

I try to remain pragmatic; Betza certainly was, with his z and q modifiers. If it is simple and useful, it is worth having, even if it is not perfect in the sense that it can do everything. The way XBoard uses XBetza move descriptions makes it already useful to describe approximate moves, so that it knows what is certainly not pseudo-legal. Having a recursive imitator in the toolkit would certainly be helpful.

I think another question is whether a white imitator imitating a black pawn moves as a white pawn or a black pawn.

I never considered that a serious issue. Is there really any variant where it moves as an opponent Pawn? To me this seems as insane as wondering whether, when it imitates the opponent's Queen, it should capture your own pieces or those of the opponent.

HG,

Have you made a documentation with all your additions to Betza notation?