Comments by HGMuller

Why would you take the King off the board for this?

The purpose of the accelerated check test is not only to determine whether the King is in check in the current position, but also to greatly facilitate testing whether the King would get exposed by any of the moves. One contribution to this is to mark every square where the King itself cannot go. The King is taken off to prevent it would block enemy slider moves (or lame leaps), creating the illusion that it would be safe to "step into his own shadow".

The test is NOT done by only processing all pseudo-legal moves. Because that would not reveal which pieces are protected (and thus cannot be captured by the King). For the purpose of knowing where the King could go the move generator should basically work under the fiction that all destinations contain the enemy King. That applies to empty squares as well friendly pieces; these will be marked as inaccessible to the King when the move hitting those is a move that can capture. Even when it cannot capture what is actually there.

The code I use avoids this by trying each pseudo-legal move and checking whether any piece in the new position is checking the King.

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves. So you would have to do enemy move generation several times. (And who knows how mobile a royal piece can be, in a chess variant?) Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once. Then for each King moves only have to test whether the destination is marked. And to know whether you are in check it would just have to test whether the square the King is currently on is marked.

But the fiction that every square where you are allowed to capture contains a King should also be applied to locust captures. And this wasn't done.

The accelerated check test would not work in variants where there are multiple absolute royals. (Extinction royaly is no problem; there it just skips the check test completely if there still is more than one royal.)

The first position in each row is for the non-capture. So if the Cannons are number  12 and 13 in the table, the Cannon x Cannon indications would need to be in the 13th and 14th element of the row. So 12 'nothing special' positions in front of them.

There is no row for empty squares, as empty squares cannot be moved. So you would have to specify this in the 12th and 13th row of the matrix. But it seems you are doing it in the 13th and 14th.

With the current coloring scheme it is very hard to distinguish occupied squares from empty squares; the pieces blend in too easily with the bright square and arrow colors. I would recomment to decrease the saturation of all the board colors by at least 50%. E.g. by giving the image a 50% (or even 70%) transparency and have a whitish background shine through.

I think you have Missed my previous comment here, HG!

I was out of town for the computer-chess tournament in Zundert.

I don't know how to say that the source piece cannot hop to move, to capture, or capture said type. Meaning both ? and $.

I am not sure what you are asking. If you cannot hop to move or capture, you cannot hop at all, right?

$ indicates you can neither hop over, nor capture said type. If you can capture, but not hop, it would be indicated by ^. It is not possible in general to specify multiple effects for the same piece-combination in the captureMatrix, and in most cases this would not be meaningful anyway. (E.g. it makes no sense to specify what you promote to is the capture is forbidden.) The hop ban is special in this respect, as it does not refer to the occupant of the destination square, so that the move can involve 3 piece types. To cover the case of the Korean Cannon I introduced the $ symbol.

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.