I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case

Certainly.  I'd imagine there are other cases that will turn up.

Actually, this could also be used for Losing Chess, where you can only make a non-capture if there are no captures.  So all non-captures could be IllegalUnlessOnlys.  Although this would be an inefficient way to do it since it's likely to happen a lot.  A more efficient way would be to have the losing rule listen for both MoveBeingGenerated and MoveBeingMade messages.  In MoveBeingGenerated it just needs to make note of whether any capture was generated.  This wouldn't work if we had to worry about pseudo-legal moves, but Losing Chess has no check/checkmate so I don't think that's a concern.

We cross-posted.  I hadn't seen your latest message when I posted mine.

Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion.

Thank you, this makes a lot of sense.  It is cleaner and should occur so infrequently that the cost is minimal.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case

Certainly.  I'd imagine there are other cases that will turn up.

Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi

Sure, but Chu Shogi is important enough to warrant support and the anti-trading rules are appealing enough that they have been implemented in some fashion in several variants (Elven Chess, Golem Chess, Odyssey).  BTW, I now support Elven Chess, although still not Chu, mostly because I haven't found the significant time it will take to code all that and gather the graphics.

Well, I don't see much difference between what I did and what you propose here, considering the different frameworks we have. And the frameworks aren't so different. It is just that I consult the equivalent of these 'rule objects' in the daughter node. But that is also after the move has been made, and when that move is deemed illegal it is also unmade, and ignored in the parent (because its score is -INF). I could also differentiate different shades of illegality in the return code, if I wanted (as any score below -INF would effectively cause the move to be ignored), and take special action for an IllegalUnlessOnly code, like stashing moves for conditional later search, without subjecting them to the particular rule that made the move illegale 'IfNotOnly'. (Note that a move could be illegal for more than one reason, though; a forbidden trade could also expose your King!) And I also reacch a point where it can be concluded that no other legal moves are available, where I then have to take action to have the stashed moves searched. (In my case because bestScore is still at -INF after all other moves have been tried.)

It is just that I am to lazy for this cumbersome stashing of moves. Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion. But this time with the 'rule object' that rejected the move temporarily disabled, so these same moves won't get rejected again. This is of course very inefficient (especially without hash table...), but since it is a 'never happens' case, code simplicity prevails over run-time efficiency.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case. (It is not really only move: there could be several rule-violating moves that solve the mate. E.g. you might be able to capture the protected Golem with two different Golems.) But there have to be rule parameters that specify which rules can be switched off in this case. As I programmed it now I can only switch off the 'no trading when protected' rule. (Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi...)

BTW, this already turns out insufficient: the counter-strike rule can also have to be suspended. E.g. black Ka4, Pa5, Pd5, Gc6, white Nb4, Gc4. (Other pieces in start position.) White plays Nb4xc6, for a discovered check. Pd5xc4 could cure the checkmate, but the counter-strike rule forbids this after NxG.

So I must also create ways to switch off more anti-trading rules. The enforcement of such rules (as well as checking and baring) are controlled by a 'property word' for each piece type, where the bits correspond to the various rules. (When you click the 'move' header in the piece table these properties are shown behind the piece value, in parentheses.) I guess I could implement the mateExemption parameter as specifying a mask, with which the property words will be ANDed in case no legal moves were found during the retry.

Code-wise it is much simpler to just redo the entire node under conditions where the GxG captures would be considered legal. All other moves would be immediate hash hits anyway.

I could certainly do something like this, and if I was writing a dedicated Golum engine I would.  Sorry, I should have been more explicit.  I am wondering if I can do it inside the framework I currently have (which of course you don't know in detail.)  I don't want to add extra code to the search function that is specific to a single game.  But you have given me an idea of how this might be incorporated into the framework in a general way that - hopefully - would be useful for other games.

Whenever a move is made, a MoveBeingMade message is sent to every Rule object, which can then return IllegalMove to deem it illegal.  (For example, the CheckmateRule tests to see if a royal piece is attacked and returns IllegalMove if so.)  I suppose I could add another possible return value - IllegalUnlessOnly (or words to that effect.)  Moves with those returns would initially be unmade, as with illegal moves, but set aside.  If there are only IllegalUnlessOnly moves, then they would all be made again and the IllegalUnlessOnly returns ignored.  This would add a tiny bit of overhead, but only a couple of if-thens at each node unless the value is actually used.

Good job with the Interactive Diagram!  It's pretty close to playing correct Golem Chess.  And, since it's mostly for demoing a game, I don't think it's essential for the ID to impelment every minor rule.  This is a pretty uncommon corner-case.  The anti-trading rule only at range 2 is more common though.  I made a similar decision to make it only applicable at range 2 in my game, Odyssey, which has been in ChessV for years but I have never gotten around to publishing.

I found a loophole for easily allowing the forbidden trades as checkmate evasion, in the Diagram! There already was a parameter tradingThreshold, which served to implement Chu Shogi's exemption of 'bridge captures' from the Lion-trading rules: when you gain more than this threshold in the exchange, it is no longer forbidden to trade the protected piece. This can conveniently be used for suspending the anti-trade rule, by setting it to a large negative value. So in the mate-handling code (executed when after all moves have been searched bestScore is still at -15000) I added

    if(exemption) {
      var h = threshold;
      threshold = -15000; exemption = 0;
      bestScore = AlphaBeta(stm, alpha, beta, eval, last, preLast, depth, borrow, ply); // redo without trade ban
      if(ply == 0) bestNr = bestScore; // needed because in the root we return the best move instead of the score
      threshold = h; exemption = 1;
    } else ... // normal mate handling

This redoes the search of the node without trade ban (with a cleared flag exemption set through a new mateExemption parameter to prevent infinite recursion).

That does the trick: If I set up a mate through a7-a5, Ke8-a4, Gd8-c6, d2-d3, switch on AI, and then Gd1-c4, it will play Gc6xc4. If I set up a normal favorable trade, like Rh8-h6, Ra1-a6, Gd1-f6, switch on AI, and then Gd8-h6, it refrains from Gf6xh6, even though that would gain it a Rook.

Flush the browser cache...

This diagram isn't working properly. Capturing a golem is demoting it to a half-golem, but of the wrong side. The half-golem should be the same side as the golem was.

This is a (still imperfect) attempt with the Interactive Diagram. Even for this I needed to adapt the Diagram script: although the new move-entry system does allow promotion to enemy (as needed when capturing a Golem), the AI did evaluate it as if the capturing piece changed into a Half-Golem of its own color. The type changes are dictated by a user-supplied routine WeirdPromotion; this was the easy part.

Of course the AI assigns the same value to Golem and Half-Golem, as it uses mobility as only guidance. Having it upgrade the value because of a user-specified demotion of pieces that capture it seems asking for too much. That raises the question how to handle this. Perhaps the Diagram should have a parameter value that can be used to overrule the automatic piece-value assignment.

The Golem and Half-Golem are subject to the Diagram's anti-trading features of the protected and counterStrike kind. These also forbid trading of adjacent Golems, though. Actually I think it is a flaw that Golem Chess allows this. For a Lion an adjacent piece would be captured through hit-and-run, and protection would be ineffective and not lead to trading. This is why the Chu-Shogi Lion-trading rules are as they are. For the Golems it still leaves an easy way to trade those, though. Of course I could have the Diagrams protected feature exempt adjacent capture. That would even give a better representation of the Lion. But I intentionally did not do that to make it more useful for pieces that cannot rifle-capture...

And no special exemption for checkmate yet... In the Diagram this is more difficult, because it only rejects the illegal captures after search, in the daughter nodes. So it becomes more difficult to communicate to the parent the move was rejected for this reason, so it can decide to redo those.

[Edit] Hand-tuning of piece values through a value=N line with N in centi-Pawn immediately after the line with a piece definition is now generally supported. (And used here to set the Golem value to about double that of what its mobility would suggest. That seems reasonable; it is like having two Half-Golems on the same square.)

Is this really so hard to implement? I had a somewhat similar situation in the Interactive Diagram for Tamerlane II, where 'King Succession' (swapping King with a Prince as a move) is only allowed when you are checkmated. (I suppose the 'only-move exception' here in practice also only occurs when checkmated, as it is hard to imagine you could be stalemated when you still have a Golem.) So I could handle it by some extra code in the section that handles mates once it is detected that you have no legal moves. This code is almost never executed, so there is no slowdown in normal play. It then testst whether succession is enabled, and if so, tries all possible swaps with pieces of the designated successor type.

In an analogous approach you could, in a position without legal moves, generate the illegal Golem captures, search those, and return the score of the best. Since you had already generated them as pseudo-legal moves, and then rejected them in the special legality testing code, you could have the latter code stash the moves somewhere, and let the mate-handling code retrieve them, so you don't really have to generate anything.

Code-wise it is much simpler to just redo the entire node under conditions where the GxG captures would be considered legal. All other moves would be immediate hash hits anyway. Like

Search(stm, alpha, beta, depth, legalGxG)
{
  nrOfMoves = GenLegalMoves(stm, legalGxG); // the second parameter would suppress the special legality test on GxG
  if(nrOfMoves == 0) { // we are mated
    if(!legalGxG) { // well, maybe not really, as we might have rejected a GxG
      return Search(stm, alpha, beta, depth, TRUE); // redo allowing all GxG
    }
    return (incheck? -INF + ply : 0); // stalemate correction
  }
  for(ALL_MOVES) { // normal search
    ...
    score = -Search(!stm, -beta, -alpha, depth-1, FALSE);
    ...
  }
}

You could try to be smart and let the re-search depend on whether there actually were any rejected GxG moves, but since you will virtually never be checkmated, efficiency here is not really relevant. It hurts more that you have to pass an extra parameter to Search. But you could use the e.p. square for that (assuming you pass that, to indicate where e.p. capture is possible). By setting it to the location of the captured G after GxG you could indicate this G is now fair game even when protected.

This is an interesting game I'd like to implement, but the following is problematic:

4.  As an exception to rule 1 above, you may capture a defended Golem or Half-Golem two squares away with a Golem or Half-Golem if it is the only legal move you have.

I don't have the ability to retroactively rule an otherwise illegal move legal based on the outcome of every other move.  I doubt any chess engine is going to do this.  There is a ZRF, and I've looked at it and don't believe it does this either, but I can't be 100% sure.  I have changed computers several times since I last had Zillions installed.

Very interesting!

Half-golem capturing adjacent half-golem:  It says 'If a piece other than
a Golem captures a Golem, the capturing piece is removed from play, and the
Golem is replaced by a Half-Golem of the same ownership as the Golem.' 
But it also says 'A Golem or Half-Golem may always capture an adjacent
Golem or Half-Golem.'

What happens here?  And likewise, if a half-golem captures an adjacent
full-golem, is the capturing piece also removed?