Comments by HGMuller

That is a completely unexpected implementation of nand. I would expect x nand true to evaluate to not x. What you describe would be x or not y. I think it is a mistake to call that nand.

I am not so sure this should not happen. I am in fact pretty sure the historic rules were that burning would occur in this case. Any other rule open a can of worms in terms of inconsistencies, and additional rules needed to resolve those..

PyChess is a web version of Fairy-Stockfish?

You can also play the latter directly under WinBoard, as a local program. It might be much stronger.

[Edit] I had a look at the PyChess FAQ, to get an idea of how that site works. It states that the "play against AI" functionality there uses a version of the Fairy-Stockfish engine that is running on the server. This means the thinking time of the engine has to be severely limited to not overload the server. The FAQ states that even on level 8 it is limited to less than 1 sec (one assumes using a single CPU thread). The time control that you can select (base time per game and increment per move) is just for the human player.

When you download and run Fairy-Stockfish on your own PC, you can have it think many seconds (or minutes or hours), using all CPU cores.

In normal Chess Fairy-Stockfish should be similar in strength to regular Stockfish. Which would be around 1500 Elo stronger than Zillions of Games (3400 Elo vs 1900 Elo on the CCRL scale). Since the rule of thumb is that doubling thinking time gains an engine some 70 Elo, you would have to make Zillions think a million times longer than Stockfish, to approach the latter in strength. Stockfish at 1msec/move should still easily beat Zillions at 10 sec/move.

The lower levels of the AI on the PyChess website are probably implemented by using Stockfish' UCI_LimitElo option in addition to reducing its thinking time. This option intentionally randomizes the evaluation, increasing the probability for the engine to play moves it would otherwise recognize as sub-optimal / blunders.

There are many ways conceivable for how multi-square pieces would behave, differing in the details. In the Dev case it is especially troublesome for the AI that all occupied squares should be under attack; this means the legality of moves that capture it cannot be judged on their own merits, but require examination of the entire move list. This is a problem that transcends that of multi-square pieces, btw: you would also encounter it in variants that specify some piece can only be captured if it has multiple attackers.

I suppose one could nearly implement this through custom scripting in the existing I.D. code, with the xxxTinker routine, but in a rather complex way: the routine could test whether it is called for a new node by examining the node count, and when it is clear a variable for each Dev to record which of its components is attacked, and set up an empty array for moves. Each move hitting one of the Dev components would initially be rejected, but moved to the array of reserve moves. And the corresponding Dev component would then be marked as attacked.

After generating all moves it should then be tested which Dev has all its components attacked, and the shelved captures of such a Dev could then be appended to the official move list. This can currently only be done by writing a wrapper for the move generator routine. But perhaps an official interface should be provided for the user to add a custom routine for calling after move generation completes (e.g. xxxDone).

Is it possible to have promotions triggered by capturing that only occur in a specific part of the board?

Not through configuring with standard options. But by custom scripting (e.g. adding a function WeirdPromotion) it should be easy.

I noticed a bug where its Shogi promotion parameter (|) blocks out the second player's promotion moves where the morph parameter comes into effect.

This is fixed now. I had added codes 999 and 998 in the internal representation of the morph array for optional and forced Shogi promotions (1000 already existed for chess-like promotion choice), but these were not exempted yet from adding 1024 if black moved. (Which is done for codes that represent piece type.)

Besides | for optional Shogi promotion there existed a & for indicating forced Shogi promotion (i.e. using promoOffset), which I added to avoid having to specify the ID of the promoting piece (which in Shogi often is a two-letter combination +L). This was undocumented, because it never worked. The reason for this failure was that the editor mutilates the & character in the Diagram definition. So I now use ^ for forced Shogi promotion instead (which did not have a meaning yet in the morph parameter). For Pawns on the last rank this is really the symbol you would want to use.

while you are at it, can you copy the Shogi promotion code from betzaNewer over to betzaNew?

You like the 'purple method' better? I did copy the code, but also left in the old code in an if-then-else construct. For now it always uses the purple method, but it would be easy to make this subject to a new parameter.

There are no pictures in cgi-bin. By convention it is a directory for server-side scripts/programs, which will run to create dynamic content for sending to the client. The file fen2.php there dynamically creates PNG images, by rendering SVG images with sizes and colors that can be specified in the URL as a so-called query string.

The SVG images it seeks in the directory /graphics.dir/svg/xxx, where xxx is the value specified for theme in the query string t=xxx. Any file yyy.svg in that directory can be rendered, by specifying p=yyy in the query string.

Unfortunately the server does not provide direct access to these directories through the HTTP web interface, because there is a file index.html in them which will be retreived with priority. This is supposed to contain an overview of what is available, but it might not be up to date. (It is a static file, so it would have to be edited to include new images added to the set.) The trick to get around this is to use a script 'list.php' that is also in those directories, and will generate the output that the server would have given you when the index.html file had not been present. (Which is a list of filenames; no preview of what they contain. The Play-Test Applet uses these scripts to build its piece table.) E.g. /graphics.dir/svg/alfaerie/list.php.

It turned out that the order in which the various promotions were generated determined how clicks were mapped onto piece types, and this was different for promotions resulting from morph and from promoZone. Now it simply uses the type displayed in the square that was clicked.

It seems you mean up to 3 times as a W/F, and that you also want the moves to be able to jump. When you already explicitly included the D/A, there is no need to indicate the jumping in the two-step descriptor. So this can simply be mcafW.

The 3-step move is more tricky, if you want to allow triple capture and combinations of jumping and capturing. Ideally this would be mpcafmpcafW, so that on every intermediate square it could either move, hop or capture. But not even the betzaNew.js script can handle that. For technical reasons moves with a destructive (c) and non-destructive (mp) non-final step have to be split, (non-destructive intermediates do not have to be clicked when entering the move), and the script only attempts one such a split. One of these days I should fix that; it is a legacy from the time where you could only have a single locust victim anyway.

But for now the combination cafmpcafWmpafmpcafW (where for the first leg the split has been made by hand, and each descriptor only needs a single split for the second leg, which can be done automatically) works.

Again ideally, the bracket notation for this would be H[cW-D][cD-W][cW-cW-W]. This is a more intuitive description, clearly mentioning all combinations of capture and jump. The [cW-D] component currently doesn't appear to work, though, and is treated as [cW-W]. Which is a bit of an omission, since [W-DD] and even [cW-DD] is understood correctly. Increasing stride in the bracket notation only appears to work when it occurs with a leap-rider transition. I should be able to fix that easily, even before there is a general implementation of the bracket notation.

This is a first attempt. The page contains JavaScript wrappers for the routines that perform and take back moves and the handler for mouse clicks. The Giant is represented by Vizirs on every square it covers. A 'first click' (for origin selection) on a Vizir is rounded to the lower-left corner of the 2x2 area. The move wrappers test whether the moving piece is a Vizir, and if so drags the other 3 with it after saving the old occupants of the destinations (to restore those on take back).

The remaining part is controlled by a custom routine giantTinker. For Vizir moves it suppresses those that are not left-corner. Moves with the latter are suppressed if there are friends in the destination area, and get a burn zone covering that area added when accepted.

Captures of a Vizir by other pieces are initially rejected, but backlogged in an array of spares. After move generation a newly ntroduced custom routine AddSpares (requires browser cache flush!) makes two passes through the list of spares; first it records all attacked squares, and then it test for every move whether all squares covered by the giant it hits are under attack. If so, the move is copied to the normal move list.

I did not address the issue of Cannons jumping over a Giant yet.

The hit-and-run captures are not indicated in this move diagram. Note there is no need to squeeze all possible moves in a single diagram, in a rules explanation. For strongly overlapping moves doing so would result in indecipherable spaghetti. Much better to use as many diagrams as is needed to make each of those clear and easy to understand.

In the Interactive Diagram the move diagrams initially only indicates plain (non-)captures, plus potential hopper mounts and locust victims. The destinations of the latter only appear when you materialize an opponent piece on them by hovering/touching. I think that in the case of static diagrams it would be best to provide a separate diagram for cases where presence of a piece is needed to activate a move to a square elsewhere, and only indicate the squares where this can happen by a special marker symbol in the primary diagram. Or even with a background color, so they can combine with plain moves to the same square.

Of course we could consider including interactive move diagrams in Jocly rule descriptions, similar to those that can be summoned in the Interactive Diagram.

General implementation of the bracket notation might make some of this unneeded. I mean, [K?fsQ] for Gorgon seems clear enough; why would you need a special notation (which no one would know or remember) for such a rarely used piece? The Griffon is much more common. The 'again, including backwards' issue also solves itself in bracket notation, where you would simply prefix the continuation leg with ab.

Problem with null move is indeed how to enter it, not how to describe it. An unconditianal null move could be assigned to the King, but that is just a kludge, as a null move cannot really be assigned to any piece. There could also be a parameter allowPass=1 to enable null moving, which could then provide an extra button to play it, rather than a tricky combination of board clicks that users might not be aware of. Because there is no enforcement of turn order, turns can always be passed when the AI is off. And when the AI is on there could be a button 'Pass' next to the button 'Move', which would do the same, but for the other player. Of course some provision for this should be made as well in the game notation.

The zig-zag/circular slides now use a different internal representation than other (more general) multi-leg moves. This is undesirable, and should be integrated. The whole problem can be reduced to the possibility for optional early termination of a multi-leg sequence. Using parentheses re-introduces the problem that the special z/q representation tried to solve, namely that slides are expanded into different, strongly overlapping lame leaps. Which makes move generation very inefficient. Problem is that the parentheses often indicate early termination of a sequence of intermediate legs, which must still be followed by a final one. (Which makes them similar to hook movers.) So it is not really an 'early termination' of a longer move. If the entire path was precomputed (maximum number of repeats) there should be a provision for optionally skipping a number of legs, to continue with the final part.

I once coined the idea to use the E atom in the bracket notation for a null leg on an edge square. Which would make the Edge Hog simply [E-Q][Q-E]. Using a semicolon separator in the bracket notation for indicating the remaining legs are for 'shooting only' would probably solve the crooked rifle-capture problem. The modifier cc could then be used for indicating a juggernaut leg, like pp could be used for hopping over arbitrary many.