Comments by HGMuller

But they indicate rifle captures instead.

Note that you can paste your Diagram in the PTA, and press the Piece Table button to get the HTML for a piece table including images and textual move descriptions, like the one I put in my 'Demotion' submission. The table there was entirely generated in this way, as all pieces were sliders, leapers or compounds of those. For more complex pieces the generated descriptions might not be perfect, and need some hand editing. But usually there aren't many of those, and what it generates for them might still be partly usable.

(Flush the browser cache first, though.)

I tried it for your variant, and it produced thefollowing:

	hussar	makes a lame (1,2) leap via the (0,1) square, or steps one square straight backward or sideways
	lancer	makes a lame (1,2) leap via the (0,1) square, or steps one square diagonally backward
	equesrex	steps one square in all 8 directions, or makes a knight's jump
	camel-queen	makes a (3,1) leap, or slides in all 8 directions
	striped-gryphon	steps one square diagonally and from there can continue to slide orthogonally outward, or makes a (3,2) leap
	cobra-manticore	makes a knight's jump, slides up to 2 squares orthogonally, or jumps to the 2nd square orthogonally if that is empty and from there must continue to slide diagonally outward
	paladin	slides diagonally, or makes a knight's jump up to 2 times in the same direction
	zebra-nightrider	repeatedly makes a knight's jump in the same direction, or makes a (3,2) leap
	marshall	slides orthogonally, or makes a knight's jump up to 2 times in the same direction
	assasin	makes a (3,1) leap, or makes a (4,3) leap
	ninja	jumps to the 3rd or 4th square diagonally, or makes a (4,1) leap
	lightcannon	slides orthogonally to an empty square, or jumps over the nearest piece orthogonally for capturing only
	heavycannon	jumps over the nearest piece orthogonally, or jumps over the nearest piece straight ahead for capturing only
	mammoth	steps one square in all 8 directions, jumps to the 2nd square diagonally, jumps to the 2nd square orthogonally, jumps to the 3rd square orthogonally to an empty square, or jumps to the 3rd square diagonally to an empty square

The Heavy Cannon obviously confuses it, while it could have been smarter contracting the descriptions of the Mammoth (But the latter would have sounded better if the XBetza had described it as KSmT.) And it sometimes ignores that the piece is not fully symmetric.

It doesn't say whether the King is exempted from morphing, or whether a resulting piece would stay royal if it does.

Note that a piece that moves as the piece in the FIDE setup that started on the file it is currently on is known as a Querquisite, and that the pieces used here are very much related to this. So it might be good to refer to this, for better historical context.

This is basically just a sub-variant of Avatar Chess on a 9x9 board, with different, more regular assignment of the morph targets to the squares. The only 'novelty' is that there are now also some squares where pieces don't morph.

And what is the point of including three basically identical diagrams? I would suggest reducing this to a single one.

This is the most original and inventive chess variant I ever encountered, and I like that very much. I agree that the current submission is not suitable as a rules page, though. We do have pages for external links, and it can be used as one of those. But it would be a pity if there is no full rule description of Turnover on this site.

That accessing the rules link requires a login is of course a deal breaker...

Also here having three diagrams that show the initial setup seems redundant.

The move diagrams seem to be screenshots from an Interactive Diagram, but they use color coding for the moves. This mode of highlighting turned out to be unsatisfactory on monochrome displays, which was the reason that a mode was added to the I.D. that highlights with symbols recognizable by their shape, in addition to color. The I.D. would automatically switch to that mode when it detects a gray-scale display, and can do that because it is interactive. For static images I would recommend using the shaped marker symbols in the screenshots, forcing that mode of highlighting by including the line useMarkers=1 in the Diagram definition.

The remark in red on the Dragon Horse seems superfluous, and even a bit patronizing; the reader can expected to be smart enough to notice such hings himself. You don't write a similar remark for tha Cardinal, where it would apply just as well. But it is normal that pieces can access the entire board; alsmost all pieces do that. If anything would deserve a special note, it would be on pieces that are color bound.

The Pawn can move and capture one or two squares forward.

Also here it doesn't specify how a King would morph.

The comments I made to Snappy Chess also apply here. In fact the games are so similar that they could be considered sub-variants of each other.

It might be a bit optimistic to assume that the average reader will know how a Chinese Horse or a Janggi Cannon moves, though.

I am interested in the idea and perhaps a little less in the formulation of the description.

But what people will see here is the description, and not your ideas. It is the task of editors to make sure the presentation is concise and clear.

Your description is plain wrong: pieces are not bound to columns at all; each piece can reach the entire board. It is just that they move differently in different files (which is the usual English Chess jargon for what you call 'columns'). And even that is not strictly true, as there are Pawn moves in all files, and on 1st and 9th rank every type can be anywhere.

It is also not clear whether a piece morphed into a Pawn on 2nd rank has a double move. The Interactive Diagram doesn't grant one.

The description is also ambiguous as to whether castling is allowed; 'takes place' seems wrong wording for being allowed anyway. Whether it will take place depends on the players.

The Motif set has a KnightQuueen piece, which is probably the Amazon you are referring to. I very much doubt that an AI would be able to design piece images in 'Motif style'.

Is it possible to have promotions triggered by capturing that only occur in a specific part of the board?

To get back to this question: initially I thought this is such a specialized case that it should be left to a custom-scripted promotion routine. But now I have an idea for how this could be achieved in a general way. In the mean time I encountered a case where promotion instructions according to the captureMatrix collided with those according to the morph board. (In particular: a Pawn that would demote when capturing, but promote normally when reaching the last rank, even with a capture.) I let the morph prevail in that case.

If the morph could contain a symbol for forced non-promotion (which, unlike an indicated no-op, would then suppress any promotion specified in the captureMatrix), you could simply use that to suppress the capture-driven promotion on an arbitrary part of the board. Perhaps this could even be done by specifying "promotion to itself" in the morph. (Currently this would be rejected, to make sure you can have two types with the same piece ID that morph into each other, in order to make the morphing entirely transparent, treated as a single unaltering piece which just changes its move.)

I usually design pieces with Inkscape on Linux. This allows you to download a raster-format picture (e.g. the photograph of an elephant), and then draw a vector image on top of it, by clicking points on the outline to define a curve. Then I use the 'edit curve' fuction to bend the line segments in shape so that they follow the outline, adjust their width and color. In the end I delete the raster image, and set a fill color for the curves, and save as .svg file.

The link now points to an accessible website. But this website unfortunately contains a very incomplete rule description. The most essential part seems to be missing (namely that a move consists of moving only the outer-most ring of a combination).

Would it be all right/adequate if I just live with the preset the way it is (at least for now) and go ahead and make my Advancer move vs. Joe?

Of course. There never was anything wrong with the rule enforcing, in the sense that all legal moves would be accepted, and all illegal moves would be rejected. The problem was only with the highlighting, which, in the accelerated mode, might highlight moves that would not resolve an existing 'locust check'. This made it easier to accidentally enter such an illegal move (which then would be rejected by the legality enforcing).

But that highlighting problem was already fixed on May 13.

I think the Interactive Diagram now completely implements the rules as I understood those. To make this easy to achieve with the custom Tinker script, I had to make a few modifications in the standard betzaNew.js script powering Interactive Diagrams. In particular how it handles exemption of moves from the effects of morph and captureMatrix by dressing those with an apostrophe in the XBetza move descriptor, and how it resolves conflicting instructions specified in these two:

For one, the apostrophe now does not prevent a custom Tinker script for being applied to the move. If it is desirable that such a script only affects part of the moves, it can always be made smart enough to make that destinction itself. But it was inconvenient that moves that should excluded from the specified morphing/banning could then not be adapted in other ways (such as adding an unload on their origin square).

And I think I provided a more natural way to resolve conflicts between morph and captureMatrix: if the captureMatrix specifies a type change, it is executed first (even if the morph for the moved piece would have specified a different type change). But then morphing is applied according to the morph for that resulting type, rather than the original piece. This made it possible to implement the Turnover promotion rules by having Pawn and King morph into Queen on the last rank; even when a piece that was originally (say) a Knight 'unstacks' to split into a (moving) Pawn and a (remaining) Bishop, it is the arival of the Pawn (or the transformation that it brings about on a turnover victim) that triggers the promotion.

This behavior can be controlled with maxPromote, as it only applies to pieces that are not specified as promoting (the promotion purely controlled by morph, not by promoZone). For promoting pieces a morph specified for the moving piece would cause the captureMatrix to be ignored. (And one can always suppress promotion by zone for those pieces by setting promoZone=0.)

Anyway, your code employs huge tables that somehow define how a piece moves, and I don't understand how these work.

The format used to encode (possibly complex) moves in the table is to split those into a sequence of rides ('legs'). Each ride is characterised by four parameters: maximum number of steps, x-step, y-step, and an integer where each bit corresponds to a 'power' that the leg has. (Like can-capture-destination, can-move-to-destination, can-e.p.-capture-to-destination, base steps cannot jump, base steps must jump, can-hop-over-destination, initial-move-only, must have as many steps as previous ride, etc.) Each move is encoded as the number of legs N, followed by N leg descriptions of four numbers each. The moves of a piece are tabulated all behind the other, the end indicated by a dummy move of zero legs (i.e. just a 0).

For example, an orthodox Rook would be encoded as four simple slides in different directions:

1 99  0  1 3
1 99  1  0 3
1 99  0 -1 3
1 99 -1  0 3
0

Where the 3 stands for can-move (1) and can-capture (2). The 99 is used to indicate an unlimited range. For leapers this would be 1. The moves of all pieces are all stored one after the other in the same array 'legdefs'; I use functions with the name of the piece label that return the index in legdefs where the moves for that piece starts.

A bent rider like Griffon would have moves consisting of two legs, like

1  1 1 1 3
2  1 1 1 1
  99 1 0 3
2  1 1 1 1
  99 0 1 3
...

(showing one simple F move, and two bent slides). The first leg of the latter is a (1,1) leap to an empty square, the second leg an unlimited-range slide with (1,0) or (0,1) step that can move or capture.

There is a GAME-code routine NextLeg which interprets the table in order to lay out all tabulated moves for a given piece on the board, and for each move it can make to a valid final destination it then calls a routine to do something with that move. (Like comparing it to the input move, or add it to the array of legal moves for highlighting.)

There is a slight complexity: normally you only have to worry about (pseudo-)legality for the last move in the game, and do that in Post-Game code. The earlier moves were already vetted in the turn they were entered. So you can take them at face value, performing them 'no questions asked'. This does not work for moves with implied side effects (i.e. board mutations not indicated in the move notation), such as e.p. capture. Such moves would have to be generated for every move in the game, and if the explicit part matches the stored move, the generated side effect would have to be performed as well.

To this end moves with implied side effects are always stored behind all others, and the routine that returns the index of the first move to be tried for a piece of that name has a parameter that indicates whether you want to try all its moves, or only those with implied side effects. By convention pieces without such special moves point to an empty movelist (a single 0), stored at the start of legdefs.

It seems I misunderstood the rules then, which is no wonder considering the awfully deficient description at the given link. I assumed that 'turnover' meant that you would combine the moving ring with what was present in the destination square, no matter what color the latter originally had. In that case Ke8xd8 would be legal. (Even though a bit pointless...)

Apparently 'turnover' only applies to enemy victims? Is it not possible to recombine your own pieces? Or is this included in what is described as 'move'?

I don't have Zillions.

It was announced in a longer Comment to which this is a reply.

I don't get it. The rule description at the link says the rules for moving a Castle (=King) are:

Castling:

•  The whole Castle can move one square for any side, except forward.

• The WHOLE Castle can take the opponent's  Castles, Fortresses, Towers and Walls one square for any side, except forward.

• Its Wall can turnover Forts and Citadels one square for any side. 

The third point seems to state that you can split off the Wall (= Pawn), leaving a Citadel (= Queen) behind, and merge the Wall with the existing Citadel on d8 to create a Castle there. The whole Castle should only move (leaving nothing behind) when moving the Wall would bring a bare Wall in the destination (i.e. when the destination was empty, or contained an enemy that should be captured rather than turned over). Forward moves are an exception to that latter rule; and are not allowed to capture in the first place.