Comments by HGMuller

Well, if there are no other contenders for that rule, then it would certainly help me. Or perhaps exempt .js files in general: browsers would typically cache those themselves, so they won't request them even from Cloudfare unless the user would explicitly bypass or flush his browser cache.

But why are you so certain that you cannot control Cloudfare through a script on chessvariants.com? I guess you flush files from the Cloudfare cache (or perhaps the entire cache) through a TCP/IP connection. So why not have the submission script open a TCP/IP connection to it, and send the required commands over it? Or do you have to solve some "I am not a robot" puzzle there?

Strange anomaly

I have started an attempt to determine piece values on a 12x12 board, about which very little is known. I use Fairy-Max self-play for this. To not make the games too long, the basic start position I use consists of a FIDE army augmented with 4 Pawns (to close the Pawn rank). So the board is pretty thinly popuated. The 4 central Pawns start on 4th rank, to speed up engagement, but the 3 Pawns in each wing start on 2nd rank, to provide some King shelter. The Knights also start in a somewhat advanced position, on 3rd rank behind the central Pawns, as does the Queen (to not have too many unprotected Pawns in the start position.

To determine piece values I delete some pieces from this setup, or sometimes replace them by fairy pieces. The side with the weaker piece can be compensated by giving the opponent Pawn odds, for which I always delete the same Pawn (on the h-file). Such Pawn odds alone results in a 68-70% win of the side with the extra Pawn. I only trust results when the total advantage is closer to equality than Pawn odds.

I don't want to delete more than a single Pawn, because Pawns are highly cooperative pieces, and I cannot be sure that deleting two Pawns gives twice the advantage of deleting a single one. By always granting the same simple Pawn advantage (or none at all), I can get a reliable 'measuring stick' on which the values of other pieces can be mapped. This poses a problem if there is a gap of more than 2 Pawns in the 'piece-value spectrum', though: I cannot play those 1-on-1 without getting an imbalance that is too extreme. I solve that by also introducing fairy pieces with values in the gap, and also determine their value.

I try to avoid Bishops, (and color-bound pieces in general) because of the pair-bonus problem, which would introduce yet another unknown. Which, if not handled properly by the engine, might invalidate the results. So I tried to find a very 'Bishop-like' piece that is not color bound. My first choice was this: to break the color binding of a Bishop, I gave it Wazir moves. To compensate for that (and prevent mating potential), I take away the Ferz moves. But to not affect the more distant B moves, they can still be blocked on the F squares. (So basically this is a Tamerlane 'Picket' + Wazir.)

Such a modified Bishops beats a Knight on 12x12 (as ordinary Bishops also do). The strange thing is that when I then handicap them with Pawn odds, they still beat the Knight, by about the same score. The extra Pawn doesn't seem to help the Knight at all! I have never seen that before; normally deleting a Pawn lowers the score by about as much as the pure Pawn-odds advantage. I watched a few games, and often they end in Knight + Pawns vs modified Bishop + Pawns, where the Knights are still judged by the engine to be ahead (because there are more Pawns on their side). But the Knight then almost always loses. The 'WazirPicket' can easily prevent advance of many isolated Pawns, by guarding a diagonal. And by just stepping in front of a Pawn it attacks as well as blocks it, so that the Pawn easily falls. Even connected passers are easily destroyed this way, if they still have far to go. (And on 12x12 they usually have; I use promotion on last rank only.)

I guess the WazirPicket is just unrepresentatively dangerous to Pawns, in the absence of pieces that can protect those. (And Knights are pitifully slow on 12x12...) So that the value of opposing Pawns shrinks to almost nothing in the late end-game.

My next attempt at a non-color-bound substitute for a Bishop will only change the mF moves of a Bishop to mW, but leaves the captures in place. This will also have the advantage that it cannot be blocked on a square that it doesn't attack, so that it cannot be blocked with impunity (as lame leapers can). Such a piece cannot do more damage to Pawns than ordinary Bishops can, but the mW move does allow it to switch color on non-captures. (Hence I dubbed it Swishop.)

This is very strange. Why do you need custom evaluation for KRK in the first place? Fairy-Max had absolutely no trouble to win KRK on its normal evaluation. (Which has Rooks completely neutral, and use the parabolic centralization table for Kings.) In the latest Fairy-Max version I use what you could call custom evaluation for checkmating a bare King (it just multiplies the centralization bonus for that King by a large factor), but that was only needed for end-games with many centralizing pieces (such as KFFFK in Makruk), because these did not bother to leave the center just for driving a single piece into a corner. Checkmating with Rook is very easy on any size board; you almost need no search depth for it at all. You just shephard the King towards the corner with your Rook, keeping the latter protected from behind by your King.

I suppose you do switch off null move?

The only thing I can think of that causes what you describe is contamination of the hash score with draw scores resulting from repetitions. What happens when you disable repetition detection (accepting PV hash cutoffs)? I don't really understand how a line that makes progress could get draw scores from this, though.

Can you post a game of how it typically plays KRK? (Best would of course be one that it bungles.)

Here is thinking output from a version of Fairy-Max that doesn't use the special bare-king evaluation, for position 8/8/8/5k2/3R4/8/5K2/8 w - 0 1 :

mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
28	  #12 	121.4M	1:17.65	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Re4 Kg6 7. Rf4 Kh6 8. Kf5 Kg7 9. Kg5 Kh7 10. Kf6 Kh8 11. Kf7 Kh7 12. Rh4 
27	  #13 	61.4M  	0:40.03	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re6 Kf5 5. Re4 
26	  #12 	46.8M  	0:30.38	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
25	  #12 	28.3M  	0:18.23	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
24	  #12 	15.6M  	0:09.85	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Kg3 
23	  #12 	10.3M  	0:06.45	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
22	  #13 	7.44M  	0:04.55	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re2 Kg5 5. Re5 
21	  #14 	5.88M  	0:03.52	1. Kf3 Ke5 2. Rd3 Kf5 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Kf4 
20	  #18 	4.72M  	0:02.74	1. Kf3 Ke5 2. Rd1 Ke6 3. Kf4 Kf6 4. Re1 Kg6 5. Re3 Kf6 6. Re5 Kg6 7. Kg4 
20	  #22 	4.50M  	0:02.59	1. Ke2 Ke6 2. Kf3 Kf6 
20	+4.59 	3.68M  	0:02.07	1. Ke3 Ke5 2. Rd8 Kf5 3. Re8 Kg5 4. Ke4 Kf6 5. Re5 Kg6 
19	+4.57 	2.37M  	0:01.27	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kc6 4. Kd4 Kd6 5. Re5 Kc6 6. Rd5 Kc7 7. Kc5 Kb7 8. Rd6 Kc7 9. Kd5 Kc8 10. Ke4 
18	+4.56 	1.54M  	0:00.81	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kh5 6. Rg4 Kh6 7. Rg8 
17	+4.55 	1.12M  	0:00.57	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kg6 6. Kh4 Kg7 7. Kg5 Kh7 8. Rf7 Kg8 9. Kf6 
16	+4.54 	729185	0:00.35	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
15	+4.54 	518699	0:00.25	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
14	+4.54 	354924	0:00.15	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kc7 6. Kd5 Kd7 7. Ke5 
13	+4.53 	218794	0:00.09	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kb5 6. Kd5 Kb4 7. Ke5 
12	+4.53 	150300	0:00.06	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg5 4. Rf4 Kg6 5. Kg4 Kh6 6. Kf5 Kh5 
11	+4.52 	107753	0:00.04	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Kf4 Kf6 5. Re3 Kg6 6. Ke4 
10	+4.50 	54436  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 Kf6 
9	+4.52 	36093  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 
8	+4.51 	20251  	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 
7	+4.50 	9192    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Re8 Kf6 4. Ke4 
6	+4.49 	5719    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 
5	+4.49 	2747    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 
4	+4.48 	559      	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 
3	+4.48 	223      	0:00.00	1. Ke3 Ke5 2. Re4 
2	+4.48 	23        	0:00.00	1. Ke3 Ke5 
1	+4.49 	13        	0:00.00	1. Ke3 

You do realize that this drives up the bandwidth it requires to download the page, and increases the server load? Browsers would display a table of individual piece images without any further server access, once the complete Alfaerie set is in their browser cache. And the most commonly used pieces certainly would be, from visiting other pages on this site. Perhaps a rare piece (such as the Grasshopper) would have to requested once (from Cloudfare!), and then the user would have that cached too.

A monolythic image of the entire position would be unique for every article though, and have to be downladed. Using a PHP script to generate the image 'on the fly' means it cannot even be cached by Cloudfare.

The 'diagram designer' was not made by me, but by Fergus. I am only responsible for the 'Interactive Diagram'. Because you explicitly address me, I will answer for the latter:

It is certainly not possible in the Interactive Diagram to use other board topologies, such as hexagonal bords, or circularly deformed boards. All boards must consist of a corner-connected grid of squares. Irregular shapes of such boards (such as e.g. in Omega Chess, with its wizzard squares, or the citadel of Tamerlane Chess) can be emulated by declaring some squares in the smallest surrounding rectangle to be inaccessible 'holes'. The Design Wizard in the Interactive Diagram article has no provisions for defining those, though. But you can just edit the HTML code that it delivers to add the holes; you only need to define an extra 'piece' with the name 'hole', followed by a list of squares that should be holes.

Now I am confused. I thought you exempted PHP scripts from caching by Cloudfare, through one of the rules. I don't see how it could be otherwise. PHP scripts are running on the server, not in the client. Surely Cloudfare is not running PHP for us? That would be a much heavier task than just caching the output these generate. (And how would it get the scripts? Normally scripts should not be loadable from other machines, just their output.)

Indeed, its absence is unintended. When we split the mc leg into mNmafsWcafsW it does work as intended, so the presence of both m and c on the same leg seems to confuse it. I will have a look at the script, to see if it is just a matter of more carefully recognizing the condition that has to add the pawn on hover, or whether the Betza parser should already split up such move in the internal representation.

[Edit] OK, I fixed it. It was not only that the hover did not work, but the W squares were not indicated at all as (locust) capture targets in the primary move diagram. Turned out the code for indicating those was in a branch that only treated cases where there were no m rights. Now I also test for locust captures on non-final legs with m rights, and that automatically makes the hover work as well.

For 'engine-defined variants', the definition in the fmax.ini file should also specify a 'pieceToCharTable' (to indicate which images should be used for what piece) and a 'parent variant' (normally 'fairy', unless there are some special rules that you want to borrow from another variant, such as a wider promotion zone, or the possibility to gate pieces). They go on the 'Game:' line, after the name of the variant, separated by #, like

Game: frog # PNBRQ.FKpnbrq.fk # fairy

if you want to depict the Frog as an elephant (because the F is in the 7th place of the pieceToCharTable, and WinBoard's 7th piece image is an elephant). The last piece mentioned for each color will always use the King symbol.

It will also be helpful to make Fairy-Max inform WinBoard on how the Frog moves, so that you will be able to play the games with legality testing on. To this end you should append the following two lines to the game definition:

#
# F& FH

This will make Fairy-Max emit a 'piece' command at the start of the game for F (the '&' indicating it applies to F of both colors), to indicate it moves as a (Betza) FH. (The other pieces move as WinBoard would expect a piece with that image to move, so there is no need to (re)define their moves.) Unfortunately Fairy-Max is not smart enough to construct the Betza notation that XBoard needs from the move definition as it was given on the 'f:' line. I still hope that I can make some future version of Fairy-Max work entirely from Betza move definitions in the fmax.ini file, rather than from the list of step vectors and primary/secondary move rights it uses now.

I am sad to say that there still seems to be a problem with the ChessV.Engine.exe WinBoard engine, which I failed to catch and report before, even though I should have realized something was amiss by the long time it took to load ChessV. When I run this engine from the command line, it nicely prints "feature done=1" at the end of a long list of features (ending with the variants feature), in response to "protover 2". But when I run it under WinBoard it does not do that. So that WinBoard, after a timeout (which fortunately occurs after 10 sec, as ChessV did not start with feature done=0), WinBoard qualifies it as a WB v1 engine, which apparently sets the variants list to just the current variant, 'normal'. (This is arguably a WinBoard bug, but it was a hack to make WB v1 engines dedicated to a specific variant, such as TSCP-G work.)

This doesn't seem just a failure to flush the feature done=1 when running under a GUI; in the WinBoard debug log the "feature done=1" never appears, but after sending the engine a move, before it starts thinking, it resends the option definition for "Weakening" instead.

Btw, the syntax of that option definition is wrong (which causes it to be rejected by WinBoard): the closing quote should be at the very end, not immediately after the option name, like

feature option="Weakening -slider 0 0 15"

[Edit] And from the command line it doesn't seem to respond to the 'quit' command.

Well, for one the spaces are missing behind the # and & in the piece-descriptions for WinBoard, which probably leads to WinBoard ignoring them altogether. Which is just as well, as HH and WH are not the Betza notations for the moves of the Hannibal and Waffle: you defined the Hannibal for WinBoard as a Trebuchet-rider. But for Fairy-Max you defined it as a Modern Elephant, which has no moves in common. But even when ignoring the piece definitions, WinBoard will revert to the default move of the piece, which for the Elephant that you use in all cases will be the Alfil move.

The F moves of the Hannibal and the W moves of the Waffle will then be rejected by WinBoard as illegal, when Fairy-Max plays them. And Fairy-Max can recognize checkmates where WinBoard still sees a possibility for the King to escape, to a square that the Hannibal or Waffle attack without WinBoard being aware of it. And then WinBoard would judge the mate claim by Fairy-Max illegal.

OK, I sort of fixed this too. To show the move diagram the move generator must be run in a special mode. Normally (i.e. when playing moves on the board) it would just indicate the pseudo-legal moves. But running t on an empty board for the purpose of displaying a move diagram would then omit all captures. So in this mode it applies extra highlights on empty squares, to indicate what could happen there if it was occupied. In particular red or yellow highlights when enemy pieces could be captured there. (And it also indicates 'virtual' hopper mounts / locust victims on the end-point of non-final legs.)

But the highlighting for the 'destroy' mode (capture friend) is not really well developed. There are 7 possible non-empty combinations of mcd, and mc (yellow), m (green) and c (red) have their own color. There are no distinct colors for d, md, cd and mcd, though, there only is blue. Considering that I haven't really encountered any variant where friendly capture is possible, it seems wasted effort to elaborate very much on this. The problem is compounded by the fact that the highlighting for entering moves is not completely consistent: on empty squares it distinguishes mc (yellow) and m (green), even though capture is never possible there for lack of anything to capture. But actual captures are always highlighted in red, without distinction between mc and c. So when an mcd move hits an opponent, should I highlight in red, to indicate it is a capture, or in blue, to indicate that a friendly capture would also have been possible on that square?

I think the real problem is that the ChessV.Engine.exe is defective; see my posting in the ChessV comments.

Note that Fairy-Max calls this game 'frog' only because the user configured it this way; Frog Chess is neither pre-cofigured in Fairy-Max, nor an XBoard standard variant. It would be just as easy to make Fairy-Max use the name that ChessV uses.

I am not sure it is 'unfortunate' that XBoard protocol only defines a very limited list of standard variants. The problem is that such a list, no matter how long you make it, will never be (or stay) complete anyway. To be future-proof, any name should be allowed. This means the names are not really part of the protocol anymore than the names of chess engines are; they are just data, and the protocol prescribes only what commands should be used to communicate them.

IMO the list of standard variants is already way too long; many variants in the list have no special properties, and only differ from each other (or from orthodox Chess) through board size, array, and piece moves. And the latter properties have basically become freely specifiable parameters for 'engine-defined variants'. So variants like Capablanca Chess, CRC, Great Shatranj really have become redundant, and are maintained only to deal with 'legacy engines'. Because the latter would not reply to the 'variant' command that selected them with a 'setup' command for specifying the array and board size.

The concept of engine-defined variants does raise the problem of name standardization, though. Which becomes more than a cosmetic problem when we want to play engines against each other. Perhaps GUIs should already provide a work-around for cases where engines disagree on the name of a variant they both play, like a per-engine 'alias list' of variant names. Which the GUI then should apply (in either direction) on both variant names received from the engine and sent to the engine.

Ughh, this was a case of a >= that should have been a > in the Diagram script. The algorithm is that the promoOffset is added to promotable pieces (all types from 1 up to and including maxPromote) to get the promoted type. When this gets larger than the number of defined pieces, it is replaced by the promoted type of the first piece. The latter was introduced to not explicitly have to define all the Golds that result from promotion of a host of different Maka Dai Dai Shogi or Thai Shogi pieces; if the first piece is a Pawn, and promotes to Tokin, all pieces that also promote to Tokin can then be put last amongst the set of promotable pieces. After that can follow the unpromotable pieces, and then all the promoted types that are explicitly defined. So if (say) maxPromote=10, and promoOffset=15, piece 1 will promote to piece 16, pieces 11-15 will be unpromotable. Piece 16 and higher are the promoted types. But if only six are defined (16-21), these will be the promoted versions of 1-6, and 7-10 will all promote the same as 1, to 16.

I fixed it now, thanks for reporting.

Just an idea: some chess GUIs allow 'reverse' entry of moves, by first clicking the destination square, and then the piece that should go there. (Usually in combination with some 'auto-complete' mode, where the move is executed immediately if only a single piece could reach the clicked empty square, and pieces that you click move immediately if there is only one place they could go.)

If you would in general allow the origin and destination of a move to be swapped, the difference could in exceptional cases (such as fast castling) be given a special meaning. Such as the reverse order (empty square x King) would indicate the castling, and move the Rook as a side effect.

I always like the 'not castling through check' rule as a form of e.p. capture: the King makes a double step, and can then be taken by a capture-capable move to the square it passed through in the subsequent move. As exposing your King to capture is illegal, such a castling would be illegal.

In this interpretation it would be legal to castle over a square that was diagonally attacked by the Joker from a distance, as after the castling that Joker would no longer move like a Bishop, and thus not be able to execute the e.p. capture of the King. I am not sure how the Joker moves after castling: as a Rook, as a King, both or neither. The rules would have to specify that. If it would move as a King, then a black Joker on e2 would make white castling illegal, as that Joker could in the reply become a King and attack f1/d1. Basically the rule would become: the King cannot pass a square during castling that it could not legally move to.

It is always a tricky question whether a Joker can deliver check. In most positions this is not important, as most moves would alter the Joker's capabilities in a way that resolved the check. But it can be important to distinguish checkmate from stalemate. Basically the question boils down to how the Joker would move after a turn pass of the opponent, because the 'in-check' definition involves the fiction of a turn pass. Must it also pass a turn, or will it just keep the move it had on the turn before? In the former case the position w:Ke3, Je2 b:Ke1 would be a stalemate, in the latter case it might be a checkmate (if white black moved Ke1 on the move before).