Ratings & Comments

Indeed, that is a very useful feature!

I now uploaded the EGT.html to the Interactive Diagrams membergraphics folder. It can be linked to from the Piececlopedia pages, with the arguments to specify the move, name and symbol for the piece in question through the parameters 'betza', 'name' and 'img' (where the latter should be the root Alfaerie name, i.e. without the w/b prefix and extension). I guess we would want to do this both for pieces with general mating potential, and pieces that can only force mate in exceptional cases, but perhaps through different remarks. E.g.

• This piece can almost always force checkmate on a bare king. Try it!
• This piece can only force checkmate on a bare king from some very favorable positions. Try it!
• It is not possible to deliver checkmate with just this piece and a King.

I also submitted an article, called 'Checkmating Applet', with the more general version of the applet that I had on my website. This includes the interface for defining piece moves. (I left out the button for some specific (mainly Musketeer Chess) pieces.)

While doing this it turned out the form for editing a submission has a pretty bad bug: in the first draft I had forgotten to adapt some links, and it included a header that turned out redundant. But when I try to edit, the edit window initializes each time with the first version I submitted, reverting all the changes I made in previous edit sessions, I then have to redo all these, and not forget a single one, or I would be back to square a1...

(And, a little hack for more flexible formatting: if the Introduction section is the only non-empty one in a member submission, the header is suppressed, and you can use your own html headers directly.)

Oh wow, I didn't know that!  Thanks :)

That was my understanding of how Fergus reworked the upload script.  I've put such a placeholder file there, so we'll see soon whether that's right.

I could see the checkmating applet fitting in its own page.  If nothing else, that'd be a little more convenient for linking to, and would give it its own index entry for comments.

(And, a little hack for more flexible formatting: if the Introduction section is the only non-empty one in a member submission, the header is suppressed, and you can use your own html headers directly.)

@HG

By the way in the definition of the default file as it is downloaded you are trying to define an U (probably an unicorn or nightrider) but you are just putting down another knight. An extra "s" is required maybe. That is for future not carefull users. Also for the V and S pieces you defined an camel zebra compound twice. No ideea what is all that about :)!

Thanks!

The actual thing I'd like to use if for is to test the 5 man endgames for my 2 apothecaries games.

That is beyound the scope of the program as the 2 apothecary games are 10x10 and even worse it uses the joker (fool, imitator) which is not being defined in FairyGen.

But there seems to be enough information for me to build the program myself for a more general purpose. The main dificulty is probably the board representation as an 64 structure bits is not usefull any more. The joker implementation should be more staightforward but there maybe have to be some recurrence there too. I still have not though about it :)!

@Aurelian:

FairyGen can be downloaded from http://hgm.nubati.net/fairygen.zip . The archive contains a README.txt with an extensive description for how to use it.

@Ben:

This is a nice idea. But I think the initial posting would still need editor assistance to upload it as an attachment, as *.html is not one of the allowed file types in the upload script. Fergus made some special provision in that script which allowed me to update the /membergraphics/MSinteractive-diagrams/betza.js file, and I hope this works by allowing the use of any filename that already exists, so that it would also work for an already-present .html file. (I have no way to test that, though.)

So perhaps you should just put a (dummy) file /membergraphics/MSinteractive-diagrams/EGT.html on the server, so I can update it to the real version, and later edit it when necessary. I don't think there is any need to create a separate member-submitted article just for the purpose of hosting the EGT.html attachment; I would not really know what to write in there, and the article format enforced on member submissions is not very suitable for anything other than chess-variant descriptions anyway.

Would it be better to work in as something you can edit directly later?  IIRC, the way your interactive diagrams are hosted through a post-your-own-page attachment?  I think we can reindex correctly; I'll look into that later, but want to throw the idea out now in case you see another problem with it.

@HG

What I had found is something else!

So back to square one! Silly me!

@HG!

I had found it by google, in the end, here:

http://home.hccnet.nl/h.g.muller/EGTB.html

So I guess that settles it.

Thanks, HG!

HG,

Hello!

Earlier on this post you had mentioned Fairy Gen.

I have a few questions:

1. Where  can I find it?

2. Is it yours? Who has authored it?

3. Is it open source? Can I see the code?

It appears that the JavaScript version of the EGT generator has too much 8x8 logic hard-coded into it that for now I cannot easily change it to also do other board sizes. I posted a version of the page on my website that only prints a summary of the statistics, and can accept arguments w.r.t. the image, move and name of the piece as 'get' arguments to the URL. Like:

http://hgm.nubati.net/rules/EGT_CVP.html?name=archbishop&betza=BN&img=cardinal

It already links to images and the diagram JavaScript present on the CVP website (I used Alfaerie .gif images), but from my own website this of course had to be done through "off-site" links of the type "http://www.chessvariant.com..."; when it would be on the CVP site the initial site address could be omitted from those links.

Perhaps a CVP editor can copy the page to the CVP website (and possibly dress it up with CVP logos). Apart from the link to the diagram's betza.js script in <script> tags and to the directory with piece images as graphicsDir in the diagram's description, and a link to the directory with marker symbols for the diagram at the end, the page is 'self-contained'. (I.e. the JavaScript for building the EGT and probing it during play is inside the page.)

Beware that the EGT generator currently can only do regular sliders and leapers, and that it would be blind to more advanced modifiers supported by the diagram, such as divergence, multi-leg moving or hopping. Pure hoppers would not have mating potential with only their King as support, though, and most other pieces in the Piececlopedia are regular slider/leaper compounds, so this doesn't seem much of a problem. (Bent sliders are a problem, though, so the Gryphon cannot be handled yet.)

The calculation is entirely done client side, so that is no problem. I will try to prepare a version that takes the Betza description of the piece from the URL. (And perhaps the name of the image to be used for this piece as well.) And it will just print a statistics summary rather than the entire DTM table. I will also omit the interface for letting the user design its own pieces.

I like the approach being described.  The endgame-generator is awesome and we should certainly make it available here, so long as the actual computation is done client-side.  (Our hosting provider terminates the entire server when our CPU quota is exceeded.)

That's all pretty much how I was thinking of how to implement it too.  Since the Piececlopedia is fairly small, I'm inclined to just edit by hand.

I've been wanting to database-ify some Piece information; maybe linking to the applet page with piece Betza notation, drawn from such a table, would be a good starting point.

If you read what Christian Freeling has said about Grand Chess, you might buy the argument that Grand Chess is one of the most excellent modest variants. Late night ideas - am writing a reply about Hannibal Chess, and got sidetracked to a slight variant of Grand Chess which I will have to exorcise before I can go to sleep. (Sorry, Kevin, I'll finish your reply tomorrow. ;) In considering what Christian thinks about his design, I came back once again to the idea that the piece set is not complete until you use the 3 king + rook/bishop/knight pieces also. So Almost Grand replaces the queen with the centaur (N+K), the archbishop with the dragon bishop (B+K), and the chancellor with the dragon rook (R+K), and all else is as Grand. This army is a little weaker than Freeling's, mostly from losing the ability to leap over adjacent pieces. Clearly it works for all the Carrera-Capa variants, and might actually help those games a little by toning down the power of the queen equivalents plus losing the archbishop's ability to checkmate without the aid of any other piece. I admit that after playing Grand Chess, playing Carrera-Capa made me feel claustrophobic!

Now this is such an obvious idea someone must have done it before. Can anyone point me to such a game?

 

I still would appreciate some response from an editor on my proposal, even if it is just a firm rejection...

Those three statements are all true.  The cannon must jump over exactly one piece (of either color) in order to capture.

 

In the picture above the black cannon at f12 is putting the white king in check.  Is that correct for a standard cannon movement? If no, I have to fix some code.  I went to piece-o-pedia and the cannon must jump a screen for the attack.  Am I correct with the following statements:

1) the white king is not in check

2) the black cannon at f12 can not attack anything due to a mess of black pieces in front of it.

3) the white cannon at g1 can take cannon g12

===

I think I am correct, but I want to check with my fellow chess players to confirm that I understand the cannon capture move.

 

Today I was thinking about possible obstacles to more than one chess variant being played by several (or many) people face-to-face presently (or in future) at given location(s), ideally at CV clubs (but at the least at some CVs tournament held at a physical site). One matter is how to determine which variant(s) will be played (all year round or even on one given day), e.g. in a club, but what may entirely determine this at any given time is the CV equipment available at a given location, for a given time period.

We've heard of card sharks, who are good at all sorts of card games that use a standard 52 card deck, but CV sharks might be harder to ever come by in large numbers in offline play, since all CVs do not use the same equipment. Still, offline CV tournaments (or clubs) that involve a relatively small number of CVs (not always the same ones, necessarily) might become relatively common one day. Standardized, mass produced CV equipment that can be used for a large number of existing CVs would be helpful. CVs that can use the same equipment as for chess (maybe with a small number of extra pieces added, as in Seirawan Chess) would be particularly golden, for the time being at least.

There's also the problem of how to make more people interested enough in CVs locally, though a potential CV physical club (or tournament) organizer can learn from any local Bridge, Chess, Go etc. club or tournament organizer that they might know. An extra chore could be to make a pamphlet about whatever are deemed to be the most essential CV 'basics' (besides the CV club/tournament location & hours info) to distribute locally, perhaps even in schools. At the moment tournaments for bughouse just by itself (or as side events to more serious children's chess tournaments) have something of a foothold, in Canada at least, now more often with cash prizes involved. Face-to-face events have one advantage, based on the experience of chess players and organizers, in that perhaps any cheating (especially with cash prizes at stake) could be easier to detect than for online play (sticking to the latter alone has some big advantages otherwise, as we have seen with Game Courier's features, plus chess and/or CV servers that offer fast [e.g. 5-minutes per side] time controls for CV players, for the given CVs that are available to choose from).

Meanwhile, here's a link provided on this very website, which includes mention of a CV Construction Kit:

https://www.chessvariants.com/where.html

I am not sure how this comment could have ended up in this untitled discussion; I am pretty sure I posted it as a reply to Garth Wallace's piece-definition topic. This must be a bug of the posting system. Perhaps an editor can move this comment to the topic where it belongs. Moved. I'm not sure what could've happened to it initially. --BR

From a practical point of view: the Jocly move generator defines each piece type through a 'graph', which is a board-size array. For each square this stores a set of 'trajectories', where each trajectory is a set of (squares, rights) combinations. The 'rights' part indicates under which conditions the piece can move there: when it is empty, occupied by an enemy (the latter still distinguishing royal and non-royal enemies), or never (but passing through it). First occupied square in the trajectory normally makes all later squares inaccessible (but does not affect other trajectories), except when a capture specifies hopper-capture, in wich case it only considers the moves behind the first occupied square. (This obviously was added as a not very general kludge to be able to do Xiangqi.) By listing this for each board square separately, it does allow location-dependent moving, and boards of irregular topologies. Although the principal reason for doing it that way was probably just efficiency: the graphs would never contain any moves that stray off board, so you would never have to test for that during move generation.

The extended Betza notation used by the XBoard GUI (XBetza) indeed implements general hopping as the ability of a step V, or repeated sequence of identical steps VV* (together referred to as a 'leg' of the move) as a condition on the occupancy of the final square of that leg, namely that it must be occupied, but will not be affected. This makes no sense in final legs of a move, but in non-final leg this 'p' modality supplements the usual 'm' or 'c'. It makes no difference between friend or foe (as hoppers usually don't), but XBoard allows the use of the combination 'tp' to limit the hopping to friendly mounts. (At some point the alphabet is just too small... XBoard also uses 'tc' for a 'tame capture', i.e. one that cannot capture royalty.) As you remarked locust capture can be indicated by a non-final leg with capture rights. And lameness as a non-final leg with 'm' rights only.

To define pieces as the Ultima Withdrawer, still another modality is needed. In principle the move can be seen as a locust capture that starts with a King leg, and then reverses direction for a Queen leg of minimally 2 steps. (Which again can be seen as a King leg followed by a Queen leg in the same direction.) You cannot combine this move with a normal Queen move, because that would make the capture optional. (Which in Ultima it isn't.) But if you always force the detour, the move must not be blocked by a friendly piece there. This can be done by also giving it hop rights (so total modality of the first leg 'mcp'). But that still fails when the Withdrawer wants to move away from a board edge. So I needed an extra modality on non-filal legs for that ('o'), which means 'can (temporarily) leave the board. Then 'mcpo' on the first leg would do it. Similarly, the 'Advancer' would be given a move that overshoots its final destination to make a capture, and then inverts direction.

In my proposal for a Betza 2.0 I tried to solve the problem of combination moves like castling (or catapult pieces) by defining a 'u' modality for 'unload'. The idea is to have one piece transport the other. In any case there also has to be a modality for 'friendly fire' (I picked 'd' for 'destroy'), which enables you to capture friendly pieces. A 'u' in a later leg would then leave there what you 'picked up' (= captured or destroyed) on a previous leg.

Move induction (as in Knight-Relay Chess) is also an interesting problem. It could be seen as a move of the induced piece, but then it would have to 'probe' if a friendly Knight is attacking it. This can be done by a leg step that can hop onto friendly Knights only, and use the first two legs of the move to make back-and-forth Knight jumps, and then a final Knight jump if that was possible. Or it can be seen as a move of the inducer, where it hops onto a friendly piece, transports it by another Knight jump, unloads it there and then retraces its steps. When every piece is inducible, and only a single piece type can induce, the latter method is conceptually simpler. Otherwise you would have to assign the inducible moves to every piece. Except that it is rather cumbersome to have the inducer retrace its steps after it unloaded the induced piece. But for convenience you could make a special unload modality for that ('tu'), which would mean 'unload and return'.

As to the ambiguity of move definitions: to get rid of that you would have to abandon the concept of trajectories, but make 'lameness' an intrinsic part of the definition. So each move becomes a set of squares to be modified in some specified way, (usually just the 'from-square' that gets emptied, and the 'to-square' that gets to hold the moved piece or its promotion choice), plus a set of squares on which a certain condition has to be fulfilled with respect to its occupancy (usually that they have to be empty). As mathematical sets are considered the same irrespective of the order in which their elements are mentioned, and can mention each element only once, you would have no freedom in specifying the move. But this quickly leads to very cumbersome descriptions for sliders (which would be decomposed into lame steps of various distances), and even worse for sliding hoppers (which would have to specify each of their distant hops as a number of combination of empty and occupied squares along their path to make sure the move is only allowed if there is exactly one occupied square in the path).

Because of the "inside-out rook" problem, I started trying to define equivalence for pieces in terms of what conditions (relative piece positions) a move can be performed under, until I realized that this was a much better way of defining moves in the first place. the inside-out rook demonstrates that the sequence of steps is entirely irrelevant, only which squares relative to the starting square can it be blocked on and how.

So at this point, I changed my approach. Instead of a path being a sequence of steps, it becomes a destination vector and a set of "tests", where a test is a pair of a vector and a state that must be true of the square that vector away from the starting square for the move to be legal.

A welcome byproduct of defining everything in terms of vectors from the starting square, instead of vectors from the previous step in a sequence, is that "exotic" board topologies become much easier to deal with. The sequence method was fine for hex boards (it's just a different set of basis vectors), but trying to define, say, a bishop on a moebius strip board was weird (try it!). But if all vectors are treated as having the same origin, there's nothing special about it.

Nice, right? Oops, forgot about divergent captures. Okay, instead of just a destination vector, we have a set of results, a set of "things that happen when the move is taken", which can include a destination and/or capture vectors. The Chu Shogi Lion's igui capture can be expressed as a move with a capture vector but no destination vector, since the Lion doesn't move; a null-move like the Lion's jitto is a move where the result set is the empty set ∅. Promotions? Another kind of member of a result set.

There's still a problem with promotion though. We need to know when it's an option. All moves are relative, but pawn promotion happens at a certain absolute position. Let's say that there is a "promotion zone" state for squares, and any pawn step onto a square with that state is a move with a promotion result. En passant can be defined in terms of a capture move to a "just stepped over by a pawn's double move" state. Of course hte problem here is that "state" is very vague. A promotion zone is permanent, but the en passant square only exists for one turn, and there's no way of specifying that sort of thing within this system yet.

Another important thing has been left out: black and white, or more generally sides. At this point I'd been mostly ignoring them and was thinking in terms of just e.g. "knight" rather than "black knight" and "white knight". I was more or less treating captures as explicitly affecting the opposite side. But that's not very flexible (it disallows, say, a hopper that can only use friendly hurdles, or a piece that can capture friendly pieces). Abstracting away the actual human players (who may not even exist, e.g. in a chess problem), what is the distinction between the sides? Alternating turns! Counting from the beginning of a game, white pieces move on odd-numbered plies and black on even-numbered plies (and neutral on all). So we should include, as part of a move's condition (set of tests), which plies it may be performed on, in most cases some number modulo the number of sides. Together with obligate promotion, we can even define oddities like Petkovian half-neutrals, which change sides when moved. Now that we've introduced a time dimension, we can even include that in our test vectors, allowing us to define en passant more concretely in terms of the previous turn's position instead of hand-waving an "en passant square" state.

I'll get into royal status, mimics, what a "state" really is, rethinking captures, and generalizing to almost everything later, but it's getting late and I have work tomorrow.

For a while now I've been playing with the idea of defining chess pieces in strictly mathematical terms. Originally this was meant as a more flexible/descriptive alternative for Betza Funny Notation, perhaps as a way of specifying pieces for chess-variant-playing AIs, but there is also the possibility of defining operations and functions over them, and maybe even proving some things algebraically.

My early attempts were to define pieces as sets of possible paths, where paths are sequences of steps, and steps are vectors; notation would use the Kleene star for unlimited equal steps. So a wazir, for example, would be {(0,1),(1,0),(0,-1),(-1,0)}, and a rook would be {(0,1)(0,1)*,(1,0)(1,0)*,(0,-1)(0,-1)*,(-1,0)(-1,0)*}. Since most pieces are symmetrical it would make sense to parameterize this as a kind of shorthand, but since some pieces aren't symmetrical it shouldn't be assumed (in the way that "a 1,2 leaper" usually implies the (1,-2), (2,1), etc. leaps). This works for the usual steppers, leapers, and riders, and even bent riders; it's basically how people usually think of chess moves, just in more formal terms.

But this starts to get awkward where pawns are involved (and a way of describing chess pieces that has trouble with pawns is seriously flawed!). First off, we need to separate passive moves from captures. That's not too bad; we can even do so by introducing a "capture step" distinct from a passive step, which must be to a square occupied by an opposing piece, and this lets us do fun things like define the Chu Shogi Lion and the Locust. Then there's the initial double move, and promotions. We can introduce a new kind of "step" that is a promotion to another piece type to deal with these: the initial double-step can be implemented by defining a "starting pawn" that has it, where every move ends with a "promotion" to a "basic pawn" piece that doesn't. The promotion step is also strange, because it always happens at the end, but if you define operations that derive pieces from other pieces (like a "double move" operation that derives a Hook Mover from a Rook) in terms of sequence concatenation, you can end up with a promotion in the middle, or even more than one. So we've unfortunately introduced a distinction between "well-formed" and "ill-formed" pieces, and a need for some sort of normalization.

Introducing hoppers also complicates things. We have to introduce another step, one that requires a hurdle like the capture step but doesn't capture it. But now we've introduced the possibility of moves that "collapse": after all, what is the difference between a (1,2) knight move, and a pair of a regular mao-move and a mao-move over an obligatory hurdle?  Or between the latter and a pair of a regular moa-move and a moa-move over an obligatory hurdle? Equivalence is a mess.

I never found a satisfying way of dealing with en passant, or castling. Defining a piece in terms of the path is travels doesn't lend itself to a move where two pieces are repositioned.

Finally I realized that this approach fundamentally allowed for pathological alternate definitions of pieces. For example, take the rook. One or more equal orthogonal steps, right? Now let's define an "inside-out rook": a piece that leaps orthogonally directly to the square right next to its final destination, then slides by orthogonal steps until it reaches its starting square, then finally leaps directly to its final destination. This piece behaves exactly like the basic rook. It's entirely equivalent: any square it can reach, a standard rook can also reach under the same conditions, and vice versa. Yet it is considered a different piece. While the example is obviously contrived, similarly weird things could be produced by operations that concatenate or interpolate paths.

In computer self-play without opening book Capablanca Chess has only about half the draw rate of orthodox Chess (about 16%, vs 32%). These are all games that start well within the draw margin, though. So as play approaches perfection, they should eventually get a 100% draw rate. A large body of opening theory can be viewed as an attempt to play perfectly at least for the first 20 moves, or so, reducing the game phase in which result-changing errors can occur accordingly.

Does FisherRandomChess (Chess960) produce fewer draws than regular Chess when opponents are about equal in strength? How about Capablanca Chess?

I did commented on the video about triagonal. And don't forget about tetragonal. A (1,2,3,4) leaper would be to long for this though :)!

2:35, he came so close to defining the unicorn ('triagonal' slider), then just kinda went "nah".

8:18, looks like probably the best shot of the starting position.  That one pawn on the backmost rank is odd.  It also looks a little different to me, so maybe it's a replacement queen?

I like the "projected" 3D boards, shrinking as the levels go up, for ease of reaching the pieces inside, though I wonder whether it makes seeing moves harder.

https://www.youtube.com/watch?v=3wFQPSEPgWc&feature=youtu.be&fbclid=IwAR2LYMJcOnnWGPuNDp03EOvKjtxy7DeLBg2UcNKtyxC-sBVULLOs52wl1Sk

Here's a sub-wiki re: Glossary of Chess, under which a brief description of two-board-using 'Basque Chess' can be found. I'm wondering if this match playing technique in any sense properly qualifies as a chess variant. It sort of reminds me of my own recent attempt to create a four-board-using variant (as inspired by this thread's subject heading), i.e. my '3D Chess War' idea, which I'm also not sure should be called a real variant (whether or not it proves to be at all enjoyable, if tried):

https://en.wikipedia.org/wiki/Glossary_of_chess#B

Sound good!

 

I propose that Capablanca Random Chess be left exactly as the inventor described and a new variant be developed. For a name I suggest Capablanca Shuffle Chess (CFC). This variant would have the initial placement of the pieces randomly placed. No requirement for all the pawns to be protected, bishops could start side by side, the queen and archbishop could also start side by side. Initial king position, rook positions, and castling as in Capablance Random Chess. Any comments or suggestions?

Capablanca Random Chess was supposed to be a mix of Capablanca Chess and FisherRandomChess. However neither of these variants required all pawns to be protected. Also FRC did not require that Bishops not be adjacent. If this adjacency rule is not used then logically the rule that Queen and Archbishop not be adjacent would not be applicable. If a CRC game changes the rules from the original inventors rules does the name need to be changed out of respect for the inventor and for consistency? There is a game called Modern Capablanca Random Chess where the black pieces are placed in an inverted order compared to the white pieces.

I would recommend to forget about the protected-Pawn restrictions in the numbering system. The inconvenience of not having direct mapping formulas between numbers and positions seems much worse than having some numbers that correspond to invalid positions.

Note that WinBoard already allows positions to be entered by number, and that the World probably would not become a better place by having ChessV and WinBoard use incompatible numbering systems.

The WinBoard system is a generalization of the traditional Chess960 numbering, to make that applicable to almost any variant. For each piece type you divide the total number by the number of placements for that type (for determining placement of subsequent pieces), and use the remainder as placement code for the current piece type. If the variant has normal castling rather than Fischer castling, you first place the  King and Rooks (or whatever serves as castling partner) in their normal positions. If the board width is even you then place all pairs of color-bound pieces such that they are on different shade. Then you place all remaining pieces on the still open squares, ignoring square shade. In games with Fischer castling you are then left with 3 opens squares, and occupy them by the King between the castling partners.

Currently the WinBoard implementation has some limitations: numbering is not unique if a certain color-bound type occurs in more than two copies. (As this never happened in any of the supported variants, I did not bother with that case.) Also, the order in which pieces are placed depends on the piece encoding WinBoard happens to use, traversed high to low in order to make sure Q is placed before N. And it only recognizes Bishop, Ferz and Alfil as color bound, placing them in the order A, F, B. (Relevant for 'Courier960'!)

Especially the piece order seems hard to objectively define so it would cover every conceivable variant. I want to propose to derive it from a 'mother position', which for Chess960 obviously would be the FIDE array. The pieces can then be ordered according to where they stand on the baseline in this reference position, e.g. for white from left to right this would lead to the order R, N, B, Q, K. They would then be placed in top-down order: K, Q, B, N, R. But B is color bound and present in multiple copies, so it gets precedence: B, K, Q, N, R. Now in variants with castling K and R drop out (either done first or last, but always in a predetermined way), so the final order is B, Q, N, as in Chess960. For CRC it seems logical to use the Capablanca position as reference (as the name suggests that).

It should be easy to write a universal shuffling routine that takes a given position and a random number, and then shuffles that position according to the number. Unfortunately WinBoard now places the super-pieces in the order C, A, Q, which is not what the Capablanca start position would suggest when traversed from left to right.

Why does ChessV not support CRC?  Simply because it hasn't been a priority.  Nor, as far as I know, has anyone previously asked for it.  But I will add it since it shouldn't be too difficult.  One thing I will need to do it find a range of position numbers with a unique mapping of position numbers to actual positions.  FRC has this but CRC does not and the rule that all pawns must be protected makes this difficult.  I could just have a database of positions I suppose.

H.G. Muller: Thanks, I did not think of looking at Winboard. This is what I wanted. However, if you know of an engine that plays CRC I would also like to know about that.

Please contain your emotional outbursts. While I normally enjoy fixing bugs, I'm less inclined to do so when someone makes a huge stink about one. So, for now, I'll just tell you how to work around it. Open another tab, log in to the site, then go back to the tab where your comment was seemingly lost and reload it.