Comments by HGMuller

That would indeed be better, but not everyone has the ability to do it. The feature in fen2.php was mainly intended as a solution for those who cannot. And a cleverly designed piece set, such as Bob's, can exploit the feature through having separate background and foreground symbols, which are intended to  be combined. That could save an enormous number of images.

Lame crooked or circular riders such as nzDD should work now (after browser-cache refresh).

Well, what programmers would have to specify for configuring the Diagram, and what users will finally get to see as a result of that, are completely independent issues. And I am usually a lot less considerate towards programmers than towards users. It is also worthwhile to have a unified method for specifying things, rather than completely different methods for each feature. Irregular promotion zones are already specified in the I.D. through a FEN-like board image, not through a case-label-like list of square coordinates.

What I would want the user to see in a variant with pieces that have location-dependent moves is a piece table with a separate entry for each possible move (so that the user can request move diagrams for each case selectively, by clicking those entries). And the name fields in the table should then get a list of squares where this move applies appended to them. Certain shorthands like a1-h4, or dark/light squares could be used in those lists. The image could be the same for all these entries, or different, as the Diagram's creator thought best. Personally I like to be able to see unambigously how a piece moves from its image, without having to deduce it. So for the Elk Chess Diagram I used a different representation for the Elk on light and dark squares (a Pegasus when it moves like a Knight, a Rook where it moves like a Rook). For Xiangqi I would be inclined to use the same Pawn image on both sides of the River, though.

As for configuring the I.D., I have been experimenting a bit with a new parameter moveMap, embedded between the piece definitions. This can define a FEN of lower-case letters abc..., where a then refers to the preceding piece definition, b to the one before that, etc. This map would than define the morph boards of all the piece entries it refers to. (While the existing morph parameter would define morphing in terms of piece ID rather than sequence in the table, and apply only to a single entry.)

As a shorthand for defining the various moves a piece can have I experimented with the possibility to write a comma-separated list of move descriptors in the field of the piece definition where normally the (single) move descriptor goes. The Diagram script would then automatically expand that to a separate entry for each move in the piece table, with all identical properties except for the move. This would work in cases where you want the piece to be represented by the same image everywhere. This is only useful, though, if the list of squares to which the move applies is appended automatically to the piece name; this cannot be done by hand when the name dield is automatically duplicated. This would require some smartness in the script for recognizing rectangular areas (including files and ranks) or square shades.

Considering that so very few variants would make use of this feature, I wonder if the latter is worthwile...

This is indeed something that cannot be done through the Applet, but which can be specified in the HTML for an Interactive Diagram. With the promoChoice parameter you can specify several 'promotion sets', separated by slashes. For each piece that promotes you can then specify a morph parameter to indicate where it promotes, and a digit 1-9 would indicate which of the extra promotion sets should be offered as choice there. (For the first set the square in the morph value should be set to *.)

Well, it is the same thing in the sense that you are specifying square properties. Which can be that the piece reaching it will change its move permanently (true promotion) or only for as long as it is there (location-dependent moving).

The first 10 moves were already given in the MSM, where it is said that these are the only moves given in the historic source, which at that point just says that "a Lion mate follows":

1. +B-6f, K-5d; 2. +Bx4d, K-6e; 3. +B-6f, Kx6f; 4. +SMx9i, Phx9i=; 5. +BT-5f, Kx7f; 6. +BT-6g, K-8g;
7. +BT-7h, K-9h; 8. +RC-11f, SMx11f; 9. BT-10i, Kx10i; 10. Ln-12g

I don't see any justification for calling this army 'FIDEs'. It doesn't use any FIDE pieces (except of course for the obligatory King and Pawns); and that the pieces have moves limited do slides, Knight leaps or King steps is true for many other armies as well. You could consider 'Forward Fighters' if you want to keep the alliteration, but in fact the qualification 'forward' is also a bit dubious; the Nutty Knights are more 'forwards' than this army.

Since Spartan Kings behave as if they are promoted Hoplites, and thus demote on capture, this situation would require promoting a passed Hoplite. The rule description does not specify whether this is allowed. In Spartan Chess there is a restriction on when you can promote to King, and it is not obvious how this rule should be extended to the case where Hoplites fight in an army headed by a Persian King. One possible extention would be that a Persian King already counts as a pair in itself, and that its presence thus suppresses the King option on promotion. Then the situation could never occur.

You can embed a JavaScript function xxxShade(x,y) on the page, which returns a color (like '#ffc080'). (Where xxx is the value of the satellite parameter.) Which will then be used for the square with internal coordinates (x,y). (Where the lower-left corner is (0,0).)

The problem with coordinates is that these are not just for dressing up the image, but are used in notation. By allowing arbitrary coordinate labels it would be possible to define coordinates for which SAN can no longer be unambiguously parsed.

Well, I suppose that part of the reason a Lion is so valuable is that it can so easily checkmate on its own. That makes it hard to predict the value relative to pieces that cannot. The most obvious method for taking away the mating potential would be to keep the piece devoid of Knight moves.

The Lion Dog in the interpretation where it can do 2-out-1-in locust captures might be more valuable. (But I don't really like that piece, as there seems no defense against this.) The Tenjiku Free Eagle might qualify on 15x15 (where the Lion loses importance due to its slowness, and the ability to move as Queen is worth quite a lot). You could even beef it up to a 'Super Eagle' by allowing also two Wazir moves per turn (QcaWcaFcabK, possibly also adding DA). Even QcabK could be pretty strong.

It would be hard to achieve the desired value without locust captures. Perhaps with hook moves (diagonal to avoid lone mating), but Tengu Dai Shogi already exists. If you plan to allow entirely new moves, AD rifle captures could be a useful building block. Unlike the Lion's igui these can attack steppers with impunity. And unlike the Lion Dog, you can defend against the igui forks by attacking the square it is on, as all igui moves end on the same square.

Umm, indeed. It seems I spoiled this when adding fast castling. There one always also has a 1-step castling possibility, and to avoid the ambiguity this causes it has to be entered as capture of the Rook you want to castle with. Normal 1-step castling also would require such a kludge, but so far was never implemented (because it occurs only rarely). So for normal castling moving the King on top of your own Rook would be interpreted as castling to the Rook square. The code I added to take care of the fast-castling case relied on the setting of a 'realto' variable, which would hold the true King destination if the input move put that at the Rook. As last thing during move execution the King would then be moved there. But in case of normal castling this 'realto' currently remains undefined, and moving the King there would make it disappear.

For now I let normal castling always set 'realto' to the King location indicated by the input move. This should fix the problem in Skica.

This means there is still no support for O1 castling. But when it would be needed I suppose it can now be easily implemented by replacing the destination of the generated move by the Rook location in the generated move when the King makes only a single step. (Which the fast-castling generator already does.) But that would still leave an issue in variants where the King can both make a single step or end at the Rook square. One then would have to design a move-entry kludge for distinguishing those moves. I suppose entering 1-step castling as RxK would not be very crazy, as in this case the Rook would indeed end on the King square (and it cannot be confused with any legal Rook move).

And this would actually be relevant if there had been, say, a black Rook on a1.

But this is critically dependent on the definition of stalemate. If it is defined as having no pseudo-legal moves that do not expose your King, the earlier positions would not be stalemates, and the moves to those would then be allowed.

I would say a single link to a functional chessvariants-related content is always allowed, especially in a Comment. We even have article pages especially for external links.

Since the layout of the article was a mess (text overlapping the images in my FireFox, and excessive indentation of the images), I tried to shape it up a bit.

I also put in a link to the Interactive Diagram, which by now is pushed back pretty deep amongst the Comments.