Comments/Ratings for a Single Item

Is there any way to make the applet recognize hopping pieces like Cannons (mRcpR) and Vaos (mBcpB)?

Well, it is a computer program written in a Turing-complete programming language, so anything is possible. But by themselves (i.e. in 3-men end-games like the applet calculates) pure hoppers like Paos, Vaos or Grasshoppers will never have any mates (i.e. they are 'insufficient-mating-material draws'), because they could only attack the bare King by hopping over their own King, effectively giving the latter King an extra sliding move. But even a Queen alone, which has all possible sliding moves, cannot checkmate a King. One doesn't need to generate an EGT to see that. So it is a bit pointless.

Pieces that have hopper moves in addition to normal captures might be able to force mate, but due to their own King being the only available 'mount', it would be very unlikely that their hopping move has any influence near the bare King when their normal moves do. And I don't know any variant that has such pieces anyway.

Hoppers could become of interest in 4-men situations, but making a 4-men version of the applet would be a challenge in itself. It would probably be more useful to first generalize the applet to handle divergent pieces, or bent sliders. Even if the generator supports that, there still would have to be some extra functionality in the user interface for defining pieces that have such moves.

Checkmate on larger boards

I upgraded the checkmating applet: it is now capable of generating the 3-men EGT on boards of other sizes as well. I put two controls in the text where you can select the number of files and ranks. It works up to 16x16; on my computer it could then still generate the EGT in about 10 sec. (Although this might also depend on what piece you are calculating for.)

I also put in some check boxes for selecting some board types other than rectangular: Omega-Chess type with Wizard squares, a Gustavian board, or the board used for 4-player Chess on chess.com. These are implemented by patially filling a rectangular board with unmovable, uncapturable obstacles, so you would always have to specify the outermost dimensions of the board. (E.g. Omega Chess would be 12 x 12.)

I also added checkboxes for selecting two rule modifications: you can calculate the EGT under the rule that stalemate is a win. (Used f.e. in Wildebeest Chess, to make the KWK end-game a win.) I also added a winning condition that I consider of interest myself, namely that you win when you can force the opponent into a corner. This tells you in end-games that are general draws whether the problem is some special complication in delivering the final blow (such as with Wildebeest), or that your material is just to weak to confine the bare King. Playing with stalemate=win rules is no good measure for that, as this rule makes driving into a corner easier, because you can use the threat of stalemate to do it, even when the corner is still far away.

The page for checkmating individual pre-configured pieces has also been upgraded; it also contains controls for the board size (which by default is still 8x8). These can be preconfigured through the URL, with the CGI arguments ?files=F&ranks=R.

It all seems to work; I don't really have trusted data to compare with, for most of these features.

The playable diagram (but not the statistics) seems to be allowing the defending king two moves each turn now. Chromev0.92 on Windows.

Same in FireFox. It always moves twice in its turn. I am not aware of changinng anything recently. But I don't know how long it already does this.

[Edit] The page implemented the computer move by providing a function WeirdPromotion(), and abusing it for scheduling a call to the routine that searches the best move from the EGT and plays it (DoMove()), through a SetTimeout call. I guess that at some point the standard Diagram script started calling WeirdPromotion() twice for every move. (Perhaps for generating the move notation?) So two calls to DoMove() were scheduled. I now changed the code in the page to keep track of whether a timout is already pending, before allowing a new one to be scheduled. This appears to solve the problem.

Could you make the same fix for the EGT.html page (as linked from the piececlopedia articles)?

Could you make the same fix for the EGT.html page (as linked from the piececlopedia articles)?

OK, done.

It would be a very nice feature to include bent riders. The gryphon mates but I'm curious for pieces like R2 then bishop and B2 then rook. I think they are both major (WD is major to my knowledge so probably R2 is too, B2 then rook could be trickier).

Unfortunately it is not very easy to include the bent riders. For one, their retrograde moves are not the same as their normal moves. The current program assumes they are, and uses the same move generator for both. It would also raise the design problem for how to indicate the bent slides.

The current move-definition pane does allow you to define limited-range sliders such as R2, btw. Just define a regular Rook by clicking the W squares twice, and then for each paths click the H square to cut off the slide there. Usually the ability to jump doesn't have much use at this stage of the game; both WD and R2 can force checkmate in the same number of moves. It is just the statistics that changes a bit.

So R2-then-B can certainly force checkmate, as R2 already can. B2Z reaches a subset of the B2-then-R destinations, and it is also able to force checkmate. So I expect the B2-then-R to do it even faster, as the fact that it cannot leap directly to the Z squares should hardly hinder it.

Thanks for the analysis!

There is one caveat: R2 (and WD) lose their mating potential on 12x12. Adding Camel moves cures this, even up to 16x16 (the largest the Applet can do). So I have little doubt R2-then-B would have mating potential there.

For B2-then-R very large boards actually make it easier. Because from a large distance you could use the R legs as if the piece were a Rook. Even an invulnerable one, because the bare King cannot approach it. And the F step can be used to tighten the noose around the bare King. So it should be a very easy checkmate.

Thanks once again for the insight!

I was trying to setup KWWvsK endgame (W stands for wizard), but the ai makes knight moves for some reason.

You probably forgot to press the Calculate button after changing the piece move;  on loading the Applet calculates KNNK. (Because that is fast, as there are no forced mates.)

Btw, KWWK is also a dead draw. Because a Wizard cannot move from c1 to a1 in an odd number of moves. It is color bound, but within its color it is meta-color alternating, switching its coordinates between odd and even each move. And a1 and c1 have the same meta-color.

Hello H.G.

Can the applet do a piece that moves like a manticore for the 6 directions that are not the two back most and also moves back like a rook and like a bishop?

Later edit: Ok, it seems you did only classic bent riders. Thanks!

The Applet here only does normal sliding, no bending at all. The main problem is that I don't have a good idea how one would have to define such a piece. In the Applet I made for Jean-Louis' book the Griffin and Manticore are selectable by buttons, but then you cannot make asymmetric pieces like those you describe.

Checkmating with a piece that has an orthogonal slide is usually very easy, though. It only needs a minimal mobility in the other directions. E.g. WfR already does it. (And note that W is a sub-set of the Manticore.) WfRfB is very easy.

Thanks HG!

For some reason the calculate button does not appear anymore!

There never was one in the 2-vs-1 applet. It starts calculating when you press 'Apply' or 'Design ready'. For the 3-vs-1 applet a separate button was needed because you have to enter the moves of two pieces, and you don't want calculation to start after defining the moves of just one of the pieces. (As it takes quite long, and cannot be interrupted.)

Oh! My bad!

Well, so the NC doesn't mate, unless very particular situations. The falcon probably even less. That was what I was going for! Thanks!

NC indeed cannot foce checkmate. I suppose that this is why in Wildebeest Chess stalemate is a win. A Falcon/Bison (CZ) should have no problem checkmating a bare King.

It seems I have made a confusion. Thanks for clearing things out.

The author, H. G. Muller, has updated this page.