Comments by HGMuller

After some more consideration I would prefer the "null move doesn't change imitation" over "null move = King move" rule. Because then it would not matter whether you define check by a second move in the same turn, or as a move after a hypothetical null move. I am afraid the concept of a null move is only natural to engine programmers.

If all your pieces are from the same set, I am going to recommend using aliases instead of the newer method of rewriting $pieces.

Note that I added several 'Automatic' sets, each of which contains all available pieces of the corresponding style. E.g. alfaeriePNG, alfaeriePNG35, Utrecht/Small, XBoard, XBoard33.) That makes it easier to satisfy the 'same set' condition.

These all use the (fully capitalized or lower-cased) image names as internal piece labels. If I understand everything correctly that would not be a problem, and can be hidden from the user by defining an alias for those to be used in notation.

White moves a Queen.  Then black moves a Knight.  It is now white's turn again.  At this instant, for purposes of determining if the white King is in check, black's Joker still moves as a Queen.

That seems consistent. If black would have moved his Joker (as a Queen) instead of the Knight, and this Joker would then have delivered a Queen-like check at the end of this move, it seems logical that you could also use it to deliver a discovered check, by unblocking it with the Knight.

It can still be freely chosen whether the Joker would mimic the last-moved piece of the opponent, or the last-moved piece period. The rules could have been such that the black Knight move switches both Jokers to Knights, instead of just the black one. This is just a different kind of imitator.

All this would only be relevant if you aim a Joker at an uncastled King, which would want to castle on that move. It seems unusua that someone would expose his King this way, so the practical difference might be awfully small.

Well, I think he meant that during your own turn enemy Jokers have no move (so that you can never move into their check), but that whether they deliver check should be judged in the opponent's turn (after he released the piece, but before he pressed the clock, as it were).

That means that the Interactive Diagram isn't compliant with other rules of Apothecary.  That said, I think that is fine.  It is unreasonable to expect a simple "prototype" testing engine like the ID to enforce very nuanced rules exactly for all games.  But I do think the question is not as clear as you make it out to be.  If you add a Joker to Xinagqi, how does it imitate the King?  Is it restricted to the palace?  If it is not currently in the palace, can it move?  Does it "check" the opponent king across an open file?  Only in the palace?

Indeed, I don't worry about that. The purpose of the ID is not to provide an exact implementation of any particular variant. Just to provide a set of tools that makes it possible to get a fair approximation. And, as I said, this whole issue is a moot point. You could probably play hundreds of games before you encounter a situation where a Joker check would or would not make castling illegal or would checkmate or stalemate depending on this.

In general I don't think much of rules or rule complications that have next to zero effect on actual game play. I would always go for simplicity when it does not matter.

As for a Xiangqi Joker; this doesn't seem decidable by logic. It depends on whether you consider confinement as part of the move rules, or as an independent property of the piece type. Like the Joker would not mimic the royalty either, and can use a King move to step to an attacked square any time it wants. But of course you could make rules that would mimic any properties of the last-moved piece type.

Is there some problem with the Post Your Own Game page? When I enter game information and press the 'Step 2' button I get nothing but a blank page with the text '$personid is CroydThoth' (my username) at the top.

For me this appears to work normally. But it might depend on what exactly you entered as data in the first step. Fergus would probably know straight away what the problem is. However, I happen to be working on an enhanced copy of the submission pages, and I put some additional diagnostic output in those that could be helpful for determining which path exactly you take through the script, and thus where it might run aground. So if you want you could try to submit through this page, and tell me what is printed in that case.

[Edit] I did discover a flaw in the submission2.php page: the <LABEL> tag for the format SELECT is not closed. This cannot cause the effect you describe, though. But it had the nasty consequence that any mouse click on the page would scroll it back to get the SELECT in view.

The way I have always looked at this is that to know whether a square is attacked by the opponent during your turn you should pass that turn, and see whether the opponent then can move there. So the question then is what the turn-pass would do for the movement capabilities of the Joker. There are several cases that could be argued for:

1. The Joker keeps its move from the previous turn, because no piece was moved during the turn pass, leaving the 'last-moved piece' just as it was. In Greg's diagram black would be stalemate if the Joker had moved to b2 through a Knight move (e.g. imitating a black Knight that just moved to b2 while capturing it). But checkmate if it had been capturing a Bishop that just moved there, as it would then still be imitating that Bishop, and thus check black.
2. The turn pass is considered a move of the King (like in Chu Shogi it would be a move of the Lion). The Joker would then always check like a King during the opponent turn. In Greg's diagram black would always be be checkmated, even if it had moved there through a Knight move (e.g. imitating the Knight that was on b2 while capturing it).
3. The Joker must imitate the null move. It would then not be able to deliver check at all, and the position would always be stalemate. (During its own turn it could still capture a King, though, through whatever move it has then.)

Is there really no better solution for this? Extra fields should be avoided as much as possible, and I don't like the use of the extra + at all. E.g. WinBoard treats the castling field in Seirawan Chess as a general rights field, (indicating the virginity of all back-rank pieces, from which gating and castling rights follow), by mentioning their file.

The same could be done here: initially the Bishops would be in the rights field, as they can convert. If one converts the rights for both disappear. If one fails to convert on its first move, its conversion rights disappear. The rights that remain for the other now become an obligation. If the first Bishop is captured in the virgin state, you could leave its rights, implying that conversion of the one that is still there is still optional.

Or you could write an X in the rights field to indicate an undetermined conversion right exists. The X changes into the Bishop file ID to indicate that Bishop must convert, or disappears when no more conversion is allowed.

I didn't have time to actually debug this, but the m in (cmpaf)2cB  is asking for trouble. This is like describing a plain Bishop (on 8x8) as (maf)7B rather than just B. You would get exponentially many paths to a distant destination, because it tries to use all intervening squares as intermediates to step on. So you could go from a1 to h8 in 64 different ways, which are all completely equivalent. I suppose that NewClick gets confused by this: it highlights the Lance in cyan, indicating that there are multiple moves to or over it. But then it turns out there is no way to resolve the moves by an additional click.

With just  (cpaf)2cB each leg would automatically skip all empty squares, and you could fly over up to 2 pieces, optionally capturing the enemies. And it would be able to do that only in a single way, each leg going from one occupied square to the next.

There could be a problem in combining destuctive modes with non-destructive modes in non-final legs. Although I am not sure if that is also the case with NewClick.