Comments by H. G. Muller

The comment contains the board image twice, the second time as a plain image below the Diagram (which works), the first time as background-image to the <table> element that contains the board squares as cells. The background of these cells is then set to transparent.

For some reason this does not work anymore. The I.D. on the Eurasian Chess page also lost its background, and I am sure this worked before. Is there some global style definition now that gives <tr> elements a background color? These are the only elements between the <td> and the <table>. A background color of the table would be displayed behind the background-image.

OK, I see. The betza.txt code actually does say 'check'. Problem was that by searching for 'say check' I did not find that, because there are quotes around the word 'check'.

It appears that it would only ever say 'check!' when the preset is using the accelerated method for testing legality of highlighted moves. This is the default method, because it is faster. But it is not entirely reliable. The reliable method would try out all pseudo-legal moves, and then generate opponent moves in each of the resulting positions, to see if any of those captures the King. All opponent moves will have to be tried to conclude the move is legal (which usually is the case), and on a large variant this can take very long (to the point where GC aborts the GAME-code execution). And in that branch of teh code it would never say 'check!'.

In the accelerated test it would generate the opponent moves not after the move that has to be tested for legality, but before it. (Meaning that it has to do it only once.) If any of those hit the King, the move that was just made apparently delivers check. After a move considered for highlighting it then only retries such an existing checking move, to see if the check was resolved, and all moves that hit squares mutated by the move-to-be-highlighted (which could have been discovered, and now hit the King). That is a huge time saver.

Where it goes wrong is that during this accelerated check test it actually removes the King, and tests whether it was in check by testing whether a move that hits the square it was on is capture capable. This to avoid a slider check is blocked by the King, making the square behind it to be safe to move to. King moves can then be tested for legality simply by testing whether their destination was marked as attacked. But this procedure does not mark squares that are attacked by locust capture. Such as an Advancer does.

Can someone suggest an example where the capture matrix is used?

Minjiku Shogi, Makromachy. For Golem Chess I described how it could be done in the Comments. (At that time I had already made an I.D. in the old way, uses a WeirdPromotion custom script.)

You did not get the point. Does the preset say 'check' when you check with any other piece than an Advancer? I think it doesn't. So then this has nothing to do with the piece being an Advancer.

By default the preset would apply the checking rule, so moves that leave your royal exposed will be refused. To switch that off (for variants where King capture is a goal) you would have to add an extra line on GAME code to the Pre-Game section. (As the Interactive Diagram does not distinguish thuse cases, but simply allows you to play on in checkmated positions.) The preset enforces the rules. It does not generate conversation during the game.

The Sneaky Snails!

Note to Fergus: although this preset is automated through the PTA, this only applies to the playing after the 'prelude'. So Aurelians question is about the GAME code for the case turn == 0 in the Post-Move sections, which is not relying on anything in the include file.

@Aurelian: I do notice you change the restrictions on what is allowed as input, and then change them back after the move gets handled. Note that the betza.txt include file normally runs under conditions (set in the Pre-Game code, where it was included):

setsystem maxmove 4;     // move + suicide + freedrop + promotion
setsystem omitmoves 1;   // in case they forgot to tick checkbox
ban commands;
allow pass 2 pass 3;     // later legs can be skipped

which is different from what you try to restore. (But of course your variant might not need all the move types that the betza.txt file supports.)

Some comments:

I am not sure whether changing the allowed input format in the Post-Move section would work. This section is only invoked after the move has already been entered, so during entry the format defined in the Pre-Game section might still apply, and cause rejection. Perhaps you should set the prelude format in white's Pre-Move section (subject to the condition turn == 0). And then restore it only at the end of the prelude section in black's Post-Move code.

Aren't you making life unnecessarily difficult for yourself, by allowing the players to place both pieces in the same turn? If you would allow two turns for the prelude (only calling HandleMove when turn > 1) you would only have to process a single move. And then you could call ParseMove true/false in the betza.txt include in order to extract the move parameters #ori and #desti, and use those to make the move.

Of course this would not give you rule enforcing in the prelude, as nothing would stop a player from moving, say, his King to the back rank. So you would have to test whether rank #ori equals 4 (or 5, for black), and whether rank #desti equals 0 (or 9 for black). And whether ther actually was a piece on #ori, and whether #desti was empty. If your rules require a specific order of placement, both prelude turns could use the same code. (If not you would need a turn-dependent test on the moved piece type, which could replace the test on the origin rank, as the piece type would only be found there anyway.)

Should I be able to use $dest to get the destination square before HandleMove runs?

I suppose not, because to work with betza.txt the preset has the "do not add moves" checkbox ticked, so that Game Courier does not handle the move itself before it invokes to the Post-Move code. And I suppose $dest would be set during GC's handling of that move.

I am not even sure this variable would be set after HandleMove returns. At some point HandleMove passes the move to GC with the aid of an "eval MOVE: xxx" statement, but I am not sure whether this is equivalent to latting the move be handled automatically.

But HandleMove has its own variables to describe the move: #ori, #desti, #moved and #victim, which will be set after HandleMove returns. And for side effects: #promo, #suicide, #freedrop and #dropped. When not applicable the first three will have value 0, and #dropped will be undefined if #freedrop is invalid.

Anyway, HandleMove true starts with calling ParseMove true. This extracts the values for all these parameters in so far these were explicitly specified by the move notation. Implide side effects are then derived by generating all moves of the indicated piece, and match those with the move parameters that were given in the input notation. If there is a match it then takes the additional parameters from the generated move (such as #suicide when the move was an e.p. capture).

So in a code section where HandleMove is not useful (e.g. because you are in the prelude), and you don't feel like parsing the 'move' that the player entered yourself, you could call ParseMove if the syntax of what the player was supposed to enter is compatible with that of normal moves.

Yes, I had seen it, but had no time to look into it yet.

Quickly glancing at the code in betza.txt suggests that it would never say 'check'; searching for "say Check" only finds "say Checkmate" where it terminates a game, as one of the possible reasons for termination. So I would be surprised if you had ever seen it say 'check'.

Is it supposed to say 'check'?

Janggi is a bit difficult to implement in the I.D., because of the rule that the Palace diagonals are also valid orthogonal directions. I suppose it could be done by morphing, but you would need a different piece type for each square in the Palace, for R, C, K and A. Ban on jump and capture can be indicated by $ in the captureMatrix, in a type-dependent way.

best I've done I think is brFlDfsNlAfHblFXlbDYbrNY

Longest checkmate is indeed 130 moves, but there are only very few positions where this piece can force checkmate. Only 38.4% of the positions with the strong side to move are won (and immediate King capture already contributes 18.4%). So this is not a piece with mating potential. (For comparison: with the Wildebeest, which cannot even force mate in 2, white on move already wins 24%.)

If I understood Fergus correctly all that is needed to do it is compare the value of turn instead of mln. Like

if == 1 turn:
... // code for first prelude step
elseif == turn 2:
... // code for second prelude step
else:
  gosub HandleMove true;
  ... // code for performing the gating if needed
endif;

The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn. But that would affect every preset automated through the PTA, and I have never encountered a case where it did not work.

Is there a way to enter XBetza on this?

Not on this page. But you could use the configurable applet page that the Piececlopedia links to, and write the Betza move you want in the URL.

I wanted to try out the Blue Gecko (frB4lbW2flFbrFfW) but I can't limit the B move to 4 on this diagram.

I guess I should extend the move-definition aid to 11x11 one of these days. But in case of the Blue Gecko, why bother? The 4th step of the B move will hardly ever be needed. And even when you leave out the frB move altogether, it can already force checkmate. You could also use B3 plus a direct AY leap, which shows that adding the AY leap does not shorten the mate (on 8x8, at least).

OK, so the betza.txt code, which thus aims to test for whether the move is the one that was just entered, would work fine even in the presence of comments?

And the code to test for whether we are in prelude should look like

if == 0 $mline[$mln]->movenum:

?

I am not aware of any such sources.