Comments by HGMuller

Unlike in Part 1 the pieces are described in a strange, LISP-like format. Is this ZoG code? I doubt it is a good idea to write articles in a programming language, rather than plain English... Programming languages are for running them in a computer, possibly after downloading. It seems to me the article should be accompanied by some 'viewer software' (e.g. in JavaScript) to present it to the user in a more digestible format. (E.g. calling up a description by clicking on the piece in the main image, or selecting a name from a pull-down menu with only names in alphabetical order.)

Also, 'Volume' is usually a courser subdivision than 'part'. Sub-divisions of 'parts' are usually called 'chapters' or 'sections'.

Swedish Cannon would be pR,mR.

Indeed. So there actually already exists an application of such a feature. Perhaps I should implement it. (But for now only with a single backup move set.)

Another interesting feature could be something I have just seen on chess.com: capturing a piece of a particular type could give you an extra move. (Or, equivalently, force the opponent to pass his turn because he is 'in shock'.) This is a powerful anti-trading rule, which has about the same effect as the Chu-Shogi Lion-capture rules. You cannot attack such a 'shock piece' with its counterpart in order to trade it directly, as it would capture you, and use the extra move to withdraw, hit -and-run style. And you cannot make a counter-attack on the opponents shock piece when your own is threatened by something else, as the opponent would capture your shock piece, and use the extra move to withdraw his own.

This might be ready for publication.

P.S.S. If you do decide to use the Interactive Diagram, you will need to lean HTML in order to properly embed one in your pages.

That isn't really necessary. The editors in the article-submission page can be switched to WYSIWYG mode. You can type your text there, and then swicth them back to 'Source Code' to get the corresponding HTML. Only in the section that will contain the Diagram you cannot do that. But the Setup section doesn't have to contain anything other than a Diagram. So you can always leave the edit window for that in HTML mode, and just paste the HTML code for an Interactive Diagram there that you obtained from the Play-Test Applet.

The PTA can also supply you with a nice table (with piece images) for pasting in the Pieces section in Source-Code mode. That you can switch safely to WYSIWIG, for editing the descriptions.

I don't know what you count as 'admin department', but I have the status of editor here. Meaning I have FTP and SSH access the the server machine, and can edit other people's Comments and articles through extra menu options. I was given these rights for the specific purpose of maintaining and developing the Interactive Diagram, and upgrading articles wherever possible by replacing their main diagram with an Interactive Diagram that could play the described game. Sadly I haven't been able to do much of the latter lately, due to lack of time. I had been going at it alphabetically earlier, but never progressed beyond H. And in the mean time the capabilities of the I.D. have been extended such that many variants I had to skip at the time could get one too.

I am not sure what 'old fashioned' means. But suggestions for improvements are always welcome.

Things I personally dislike about the site is the primitive nature of the article-submission system, without any help for inserting diagrams. (Requiring you to go to other diagram-generating pages, and then copy-paste HTML code.)

I am not sure why it would be beneficial for Game Courier to be on a separate domain. (It used to be at play.chessvariants.com before it was moved to the 'play' sub-directory.) Domain names are pretty much becoming a technical detail, which users mostly ignore. If there is a page they want to visit often they just book-mark it.

The captureMatrix only looks at the pieces on the origin and destination. For multiple capture it would have to be not a matrix but a multi-dimensional object.

But I did not see that as a problem. In the example you give an adjacent Lion is captured. Under Chu-Shogi rules this would also be allowed. In the current form the rule thus gives the closest approximation to the original Chu-Shogi rules. You can even allow bridge capture, by exempting the caKcabK moves from application of the capture matrix by suffixing those moves with an apostrophy. (No way to still forbid it when bridged by P or GB, though.)

BTW, it is still possible to handle more complex cases by scripting. By defining an xxxTinker() JavaScript routine you can examine the move it is passed as argument, and set the '64' bit of the variable 'kind' to let the move trigger the forced pass (kind |= 64;). Or the '32' bit to make it a prioritized move.

There seems to be a typo in the promotion rule for Strong Makruk (Kuhn instead of Kohn).

The diagram is rather ugly cut & paste work.

I guess it should be possible to make an Interactive Diagram for this variant, though; it falls in the category of 'regular variants', which only differ from orthodox Chess by having different sliders, leapers and their compounds and board-size parameters.

I once tested the effect of limiting the promotion choice to weaker pieces, (like only Knights), and it turned out there almost wasn't any. I suppose that in practice promotions can almost always be prevented by sacrificing a minor for the Pawn that is going to promote or has just been promoted. So promotion is worth a minor. For promotion of pieces weaker than a Knight (such as Silver or Ferz) this might no longer be true, though.

Indeed, 'kind' is a global variable, the bits of which can be set during the tracing out of a move path by (possibly recursive) calls of NextLeg(), or the StackMove() that this results in. (Which again optionally calls xxxTinker() via AlterMove().) In the end the bit flags indicate whether the move passed through a square that was mutated in the previous two moves, and thus a discovered attack, recapture or pin enforcement. And thus now also whether it is prioritized or triggers a forced pass.

The problem is that the capture matrix also specifies what should happen for moves to an empty square. Hit-and-run captures make a capture, but end on an empty square. It is not obvious that an occupant should dominate the empty square here.

I don't think it would be wise to make the very general function of the apostrophe of exempting from capture matrix and morph board subject to restrictions that depend on the kind of move it is applied to. The trade threshold only makes sense for double captures.

My bad. I wrecked the betza.js script in the attempt to also make the n modifiers work for larger orthogonal or diagonal leaps than 4 squares. In betzaNew.js I did it correctly. Now it should work in both (after browser-cache refresh).

The j modifier might not work as desired on larger leaps, though: it would require all intermediate squares to be occupied. I assume it would be more useful to require that only a single intermediate square is occupied.

If the call stack overflows you must have many more layers of calling. Probably a long sequence of AlphaBeta. So the line gets too long because it awards extra turns all the time. (The forced pass and following move are not counted towards the depth.)

AlterMove calls Tinker (= CustomScript), and doesn't touch 'kind'. So it should not matter which of the two sets the 64 bit in kind.

I would have to test this myself, but might not have time before tomorrow evening.

ifmnD doesn't seem to work.

I think this was already fixed; try refreshing the browser cache.

I suppose that the various variants in a collection are very similar. Otherwise there would be little reason to present those as a collection. So it is hard to imagine that the reting of the individual variants would differ very much, if at all.

Shuffle variants could be considered very large collections.

Ah, of course. The problem is that the Tinker script you wrote does not test the color of the pieces. So the Lion sees itself in case of igui. The capture matrix does distinquish friendly capture from enemy capture, and normally you would only define a shock on the latter. Of course you could also have the Tinker script test for return to the starting square, and refrain from modifying kind in that case.