Comments by HGMuller

@HG, In the context of my before the previous example I think the ":" symbol does not influence the preset although it works fine in the interactive diagram!

I finally had time to look at this. The preset as it was indeed ordered completely random shuffling of Y and W. Which means that YY-WW or YW-YW is also a possible outcome. The way the shufflespecs work in the preset is that the second element of the triplet specidies the set of pieces that have to remain symmetrically located, and the third element specifies the set of pieces that must be equidistributed over square shades. A 0 there means there are no such pieces (and if both are non-zero, the third element is ignored). The first element then contains the remaining pieces, and must be non-empty.

By putting (W Y) in the first element, you asked for an unrestricted shuffle. Because the first element must not be empty, you have to put one of the two there (say Y). The other (W) can then go into the second element, and will be symmetrically shuffled (either as W.-.W or as .W-W.). The Y will then be 'shuffled' over the remaining open spaces, which in this case is just placement there as there is nothing left to choose.

I am not sure why the automatic generation did not work; I haven't looked yet what shuffle string you specified there. Perhaps it failed to put one of the Y, W in the first element, and put them both in the second. Anyway, try if this works:

set shufflespecs (
  (Q V U) // shuffleset
   0
   0
  (I M) // shuffleset
   0
   0
  (Y) // shuffleset
  (W)
   0
   0 // mirror to get black
);

All these pieces can already be described through the general mechanism XBetza uses for multi-leg moves. The notation you proposed is much less general, and can handle only some very specific cases. E.g. D/W describes a W followed by D as well as a D followed by W move, as well as simple W or D moves. But what if there is a piece that only does simple W, or D after W? In XBetza you can describe each of these moves separately, e.g. mafmpafW would be a move that makes 3 W steps in a linear fashion (f), where the square reached in the first step must be empty (m), while the 2nd square should be empty or hopped over (i.e., its occupant is completely ignored, mp). That is, it is a W followed by D. The bent version would be mampafW, i.e. it would drop the directional f restriction after the first step. Writing an s there would force a 90-degree turn at that point.

It is true this makes the description of your  W/D a bit cumbersome (WDafmpafWmpafafW), but that seems justified for a piece that really has a rather elaborate and complex set of moves: three different ranges (WDH), the latter half lame in a multi-path way (can be blocked by two, but not by a single piece). By assigning a very specific (and therefore hardly ever useful) meaning to a certain notation, you can of course always be more compact in the rare case where that notation would be useful.

Note that when the Betza j modifier is interpreted as 'must jump over exactly one piece', the W/D could be written as WDnHjH, which is also not so bad. And at least allows the piece to have an nHjH move without having either W or D.

@Aurelian: I haven't had time to visit CVP since it came back on line. I will have a look at the shuffling problem you mentioned.

@Jean-Louis: there is an explanation of y and a here. Indeed a means 'again', and y can be used only in combinaton with it, where ya then means 'again with range toggle', i.e. when the move started as a leaper (as is the case with F) the next leg will move as a rider of the same stride. fs means 'forward sideways', but the convention is that this should be interpreted in an orientation where the previous leg defines the forward direction (think of the controversy for the move of the Grant Acedrex Unicorn!). So fs deflects the path by 45 degrees, pure s would deflect by 90 degrees, bs would deflect by 135 degrees. So the ya would turn the F into B (range toggle), but a 45-degree rotated B is an R. So yafsF is an F step followed by an outward R. Without the y (i.e. afsF) there would be no range toggle, and the second leg would be an outward W step. Which would give you a Moa.

It seems the server is back in business?!

Please back it up ASAP!

I do have a VPS available (rented up to Oct. 6) where we could practice the process of cloning the website. Apache, PHP and MySQL are installed, as well as ftp and ssh servers. Tell me if you want an account with root access on it.

You wrote "graphics.dir/alfaerie/ " instead of "/graphics.dir/alfaerie/ " in the preset. Therefore it complains that the string does not start with a forward slash.

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

OK, done.

OK, there are three problems:

1. The last two lines of the Pre-Game code have no semicolon at the end.
2. The .. at the start of the string assigned to dir in the forelast line should be deleted, to make it an absolute path.
3. The definition of the W image got totally messed up; it should be:

  W "../alfaeriemisc/compounds/wzebrawazir.gif" w "../alfaeriemisc/compounds/bzebrawazir.gif"

For this piece you made use of the % convention in the Interactive Diagram, for indicating where the white or blackPrefix should go. The script for flushing the game code does not support that convention yet, so it put the color prefixes (w or b for this set) in front of the path name as usual. I could probably automate this, but in the preset the path name has to be relative to the path assigned to $dir, and it might be difficult to deduce that from the full path name that the Diagram expects with the % convention. So I guess the best solution is to let the user, when he wants to incorporate pieces from a different folder, just post-edit the Pre-Game code generated by the Play-Test Applet for such 'guest' pieces (like W in this case).

I think it is a mistake to not take the turn situation fully into account for the repetition rule. For one, it is illogical: we do condider the same board position not a repetition of the other player is on move. Game-theoretically a position is different when the side to move can still make a double move, or must do his second move. So why consider them the same?

In general it is bad to declare draws through an artificial arbitrary rule in positions that could be won without that rule. It seems not far fetched at all that a position is vastly better when you can do a two-move turn. E.g. the first move could discover a Bishop attack on the Queen, which you then take with the second move.

I can confirm that the Mamluk and Seige Elephant properly work when I replace the symbols used for them (.JW and .ET) by an ordinary Camel and Elephantrider, the labels of which do not start with a period (J and EE). In the startup FEN and in the functions defined for the pieces near the end of the Pre-Game section.

@Fergus: Did you see my question about this, amidst the flurry of postings that appeared yesterday?

Any time a Pawn takes a double or triple step and passes through the capture square of an opposing Pawn, that Pawn may capture the opposing piece as if it had only moved one square.

This seems incorrectly phrased, as in case of a triple step the capture could also be performed as if the Pawn had only moved two squares. Perhaps it is best to say "as if it had moved to that capture square".

BTW, this game is very similar to Mexican Chess, where the Camels are called Conquistadores, and start between Knight and Bishop. On CVP Mexican Chess only appears as a Java Applet.

That was my intention. Do you think this is a bad option?

No, just unusual.

I notice that the piece labels for Mamluk and Seige Elephant both start with a period. Have you tried whether the Caliph works? (It also has a label starting with period.)

@Fergus: can there be a problem with functions that have a name starting with a period? The GAME code generated by the Play-Test Applet generates functions with the name of the piece label, which return the start index of their move description in the legdefs array.