Comments/Ratings for a Single Item

I have something similar in Short Sliders.

The Queen being on White's left, try ilO3irO4. The ID (or so I'm told) reverses it automatically for Black.

How do I make the Interactive Diagram allow up to 3 spaces for Queen-side castling and up to 4 spaces for King-side castling? The way it currently is now allows up to 4 spaces on each side.

Added Interactive Diagram to page. This diagram makes use of Game Courier sets, and it includes a static image to display if JavaScript isn't enabled.

Worthy of mention is the CRNBAKBNRQ setup, which is used in Victorian Chess. I have been placing Queens and Chancellors in the corners of various size boards since 1997.

I am very sorry and apologize since my lack of signing my comment below has led to a misunderstanding. It was late, and I simply forgot.
My name is Bernhard Hermes, and I am not H.G.Muller, and I sometimes use signs like :-(

(And, it seems, I sometimes add unnecessary 's's to English verbs...)

I actually like that proposal a lot!

In more lightweight games we coud have A=Alfil and C=Cannon.

'Thus a FEN string always should use those piece letters with a well
defined, preferable traditional meaning: this moment I suggest
J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R).'

I was under the impression that the most 'traditional' name for N+B+R is
Amazon. Thus it would still be able to have a good encoding using
well-known names, namely C-Cardinal, M-Marshall and A-Amazon -- seems to
me this would use names everybody in the chess variant world immediately
understands. They just don't happen to just by chance match Archangel and
Centaur ;-)

'I regard this to be a very big weakness,  ...'

It is not that bad, if you realize that there is a different mechanism in WB protocol to achieve the same thing: by sending a move to the engine, you implicitly ask the engine if this move is valid. If it isn't, the engine ignores it, and sends an 'Illegal move' message to the GUI. The GUI then undoes the move on the display, and relays the illegal-move message to the user, or engine opponent. As most engines are not considering the possibility that their moves might be illegal, the game then usally hangs, however. But the GUI doesn't have to know about the rules in this case.

There is a big advantage of having the GUI understand the game, though, when you cannot rely 100% on the engines. Then the GUI itself can judge the legality of the moves sent to it, make the engine that does the illegal move forfeit (you don't want to give engines the power to make their opponent forfeit...), and forfeit engines that do make false illegal-move claims. And in WinBoard_F this functionality can be switched on optionally in many variants. The other variants can still be played, with legality checking off.

| if there is only ONE castling move possible at all, it will be 
| matched by ANY string starting with 'O'. 

Why would you want that? It still would not help to understand all games of variants that interchange the O-O and O-O-O notation.

I am not sure why you would want to allow translation in PGN, but not in FEN. In WinBoard I added the external option (/pieceToCharTable) to alter the piece indicators. These would then be used consistently in both FEN and PGN, without any internal tags. The most common case where this is needed is for reading PGN files from a different language. The problem with the tags you propose, is that they still would have to single out one language as 'standard', and other languages will never agree with that. So I think it is better to make that specification external. After experience with some less-known variants (e.g. Knightmate) I realized that this translation should be independently settable for the external interface (saving and loading FEN and PGN), and each engine. This to play engines using different 'standards' against each other. It might even be desirable to have a separate translation table for external reading and writing, so that the GUI could be used to convert PGN files in one language to another one.

I don't think the J-system you use for Janus Chess is acceptable: it only works for opening positions. It should be possible to play from arbitrary positions specified by FEN. And you have no way to indicate that Pawns cannot promote to C in positions where there is no A/Janus on the board. The only logical solution would be to use the J for Janus Pawns, different from Capablanca Pawns by not being able to promote to C. But for Chancellor-Chess positions without a Chancellor, you would then need yet another letter for 'Chancellor Pawns'. And this is what I don't like at all. In Seirawan Chess you would need Capablanca Pawns on an 8x8 board, different from normal Pawns, so you would also need different indicators for Pawns in normal and Capablanca. Or use different letters for Capablanca Pawns on 8x8 and 10x8 boards, to preserve compatibility with existing 10x8 FENs. It quickly prolifirates, and becomes very awkward... Much better to just consider them different variants.

H.G.M.: '... there is no way in WB protocol to request it from the engine ...'

This is true also for UCI. I regard this to be a very big weakness, which I have avoided in SMIRF's TMCI protocol, which is unfortunately used by nobody else but your Smirf-O-Glot. 

Because engines using that new FEN and multi-variant approach still have to be written, why not to extend used protocols in this point? A GUI SHOULD be able to ask an engine for ALL possible moves. There is no need for an intelligence for this inside the GUI, because it would not be able to grow with upcoming new variants.

H.G.M.: '... the O-i-h system ...'

Nevertheless I would like to use following convention for stored PGN files: if there is only ONE castling move possible at all, it will be matched by ANY string starting with 'O'. 

The use of different letters e.g. M (Marshal) instead of C (Chancellor) or C (Cardinal) instead of A (Archbishop) should not be handled by the FEN string, but by a new to be defined PGN translation tag e.g. for embassy chess: [translate 'M=C C=A']. This is for showing traditionally translated piece letters (to be used on the GUI and PGN only, but NOT inside FEN). An exception to this is the use of J=Janus, having the special meaning of avoiding any Chancellor. Here it would be necessary to use also an additional tag [translate 'O-O=O-O-O O-O-O=O-O'] because of the unlucky old switched encoding decision inside of Janus.

Thus a FEN string always should use those piece letters with a well defined, preferable traditional meaning: this moment I suggest J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R). ANY big piece type MENTIONED inside the INITIAL sent FEN might be used for promotions, additionally all the well known 8x8 and 10x8 standard pieces (but using J would disable C).

'If the effort isn't too big' is a big if. Normal chess, Capablanca, FRC and CRC are similar enough not to cause too much trouble. Although I consider it already a nasty trait that some of the rules have to be implied by the board size, such as to which pieces a Pawn may promote. If a board width of 10 is taken to imply Chancellor and Archbishop are allowed, the problems with Janus Chess or Chancellor Chess I would consider already pretty bad. To unify those with Capablanca/CRC would require different letters for their Pawns. In Janus Chess you would have to indicate the deviating castling mode amongst the rights.

In the O-i-h system you would always be able to deduce if the K-side or Q-side rook is to be used by the ordering of the King and Rook destination? I guess we could indeed consider it a defining property of a castling that it swaps the order of King and Rook. I am not aware of any exceptions to this, even in FRC/CRC the King is required to be between the two Rooks. So I guess your system is acceptable for in the PGN, with the additional preference rule that if there is only one castling possible to the given side, it would be written as O-O or O-O-O.

The way the move is transmitted between engine and GUI in WB protocol is a matter specific to the WinBoard GUI. And WinBoard does generate the list of allowed moves itself, there is no way in WB protocol to request it from the engine. As this type of castling with multiple King and Rook destinations is about as crazy as they get, anticipating this format would probably enough to cover everything. Even the normal castling requires the GUI to recognize castlings, and know which Rook to move and where. (This caused problems when I had Fairy-Max play Cylinder Chess, as a King crossing the side edge was considered a castling, and led to the displacement of a second piece on the display board!) In fact, with the assumption that the relative orientation of King and Rook destination squares implies which Rook has to be used (and even if there are several Rooks on that side, only the one nearest to the King could be involved in castling), there is no need to convey any information in the 5th character other than that it is a castling. So an O here would be quite convenient, as promotion pieces have to be lower case in WB protocol.

For a really dumb interface (like my battle-of-the-Goth javascript viewer) it is necessary to fully specify from- and to-square of each piece that is moved separately. So there I transmit O-O as e1g1h1f1 and e4xf5 e.p. as e4f5e4f4.

H.G.M.: '... how much effort one should put into upkeeping a unified approach ...'

Why not, if the effort isn't too big? So let's try out some ideas.

H.G.M.: uses: 'Ke1-i1&Rj1-h1'

Maybe I am too traditional, but I would like to have an encoding startig with 'O'. Here I would suggest to write 'O-i-h' using the first column letter for an untypical King's target square and the second one for an untypical (not inner neighbored) Rook's target square.

H.G.M.: '... but simply as FROM and TO square ...'

Appending a letter (I would prefer the involved Rook's/piece's source column letter) is only a partial solution, because this forces the GUI to somehow generate the input gesture squares, which demands, that its programmer has anticipated this (what is not necessarily the case at a new variant). But, because the problem of two unique squares representing this move exists nevertheless, it would be covering more, to use those square coordinates also for to communicate the move.

Nevertheless here again is an encoding problem, when a free castling would also allow to place the Rook on different selectable squares. Thus I still have problems with such types of castlings.

My understanding of a GUI is, that it has not to know much about chess. It has to ask for all the possible moves, have the user make a selection e.g. by clicking at two squares, and to communicate this choice to the engine, using the move code it has sent before by request.