Ratings & Comments

Thanks, HG. I got it. Good luck!

HG, Actually in the following it is not about an error. But I need to figure out how to edit the already done preset so that when the joker that imitates a pawns it inherits only it's basic properties, no double move, en-passant, promotion. The way I had done that earlier was to treat the pawn separately and when it is the case that it is the last piece for it I imitate a barren pawn piece. This worked fine. But I do not know how to do it here. The diagram will still not be able to do that and that is fine for a newcomer, the game is complicated enough as is, but for the game code I think I can do it, just guide me a bit to how.

The GAME code in the betza.txt include file updates a variable 'toimitate' in its HandleMove routine, so that it will contain the ID of the piece to imitate on the next move. You could use the trick with the dummy piece also here. Say that its ID would be X or x, you could add this code in the Post-Move 1 section after the call to Handle move:

set toimitate cond == #toimitate p x #toimitate;

And in the Post-Move 2 section the same, but with capital P and X. The == #toimitate p tests whether the next piece to imitate would be a pawn, and if so, changes it to x, but otherwise leaves it as it was.

Thanks HG!

I now fixed the Play-Test Applet's GAME-code generation such that it does use the correct way for specifying a move as imitation in the 'legdefs' table it generates.

One caveat: the trick the betza.txt include file uses for determining whether moves are legal during highlighting is not reliable when imitators are present. Because it determines the pinned pieces and attacked squares before the move. And the move will usually change what the imitator is immitating. So it is recommended to use highlighting of all pseudo-legal moves, by specifying

set pseudo 1;

at the end of the Pre-Game section.

Thanks, for that HG!

It seems in the game code I can castle out of check and that should not happen.

I think it just highlights the move as legal but doesn't let you actually do it.

I verified this. You are correct!

That is a consequence of pseudo-legal highlighting. The issue of moving into / out of / through check is what makes the difference between fully legal and pseudo-legal moves.

Ok!

@HG, Hello I want to use the dummy piece trick here the way you suggested a while ago. I don't know how to define the dummy pawn (a pawn with no capture, en passant or promotion).

EDIT: I mean without having to redo the diagram from scratch.

Can you help me?

I think another design contest would be nice. I like having the option of two different numbers; I could do something nice with 62 spaces if we need more submissions.

(This is the same Sam Trenholme who made Schoolbook a long time ago. I’ve given up on password recovery, so I’m just using a new account. As an aside, Gmail isn’t getting the verification emails.)

Whether a piece can promote or not depends on its ranking in the piece list and the value of maxPromote. If you want a Pawn that cannot e.p. capture you just leave out the e mode. E.g. fmWfcF instead of fmWfceF.

You will find it in the alphabetical index under P. It can generate GAME code for rule enforcement / highlighting in Game Courier presets. But it has no provisions for uncommon rules like Frog kissing, or mixture of chess and shogi promotions. So it would be necessary to supplement it with code of your own.

To add a new piece (say X / x)  to the GAME-code generated by the Play-Test applet you would have to add its move definitions at the end of the legdefs array, and supply functions X and x that return where in the legdefs array you have done that. Determining the latter is a bit of a pain; there are comments in the legdefs table that in parentheses indicate where the definition for each piece type starts, and you can then count the numbers appearing after that. Note that because the 'bare Pawn' is an asymmetric piece you would need different definitions for the white and the black one.

The move definition of a (white) FIDE Pawn is:

1  1  0  1     1
1  1  1  1     2
1  1 -1  1     2
1  1  0  2   16577 // pawn(1)
1  1  1  1     4
1  1 -1  1     4
0

The first 3 lines would suffice for the Shatranj Pawn; each line starts with the number of legs (always 1 here, as Pawns only have simple moves), the forward and sideway step size, the 'range' (= number of times the step can be repeated) and finally a code to indicate what the move can do (2 = capture, 1 = non-capture, e.p. capture = 4) and other details (like whether it is a virgin-only move). So the 4th line is the double-push, the 5th and 6th are the e.p. captures. For your bare Pawn you would leave these lines out. The final 0 indicates that the definition ends there, and that the moves that follow (if any) are for another piece. The move specifications for a piece should always end with such a 0.

In the example I copied this from the white Pawn was the first piece, so it starts at element 1 of legdefs. The special moves of that Pawn start at element 16 (as the three normal moves each take 5 numbers to describe). That means that just behind legdefs there is a line

def P cond #0 1 16;

that tells the code that the move definitions of piece P start at 1 (normal moves) and 16 (special moves = moves having side effect, such as creation of e.p. rights, or disappearance of pieces elsewhere). For pieces without special moves the latter number should always be 0. So for the bare Pawn you would have to add a line there like

def X cond #0 ... 0;

where the ... is the location in legdefs where the move definition starts.

@HG, I had managed to do it despite some small setbacks. You know what's funny? This game also has berolina pawns!

I have also created dummy berolina pawns and made the trick for them, too!

In my opinion riders based on a leap other than a king step are very awkward to play with. That holds for NN, but also DD and AA. It is never intuitively clear whether the path between such a rider and a distant target is blocked, especially when the blocker is far from both. For me that makes them annoying pieces.

I guess the problems with tactically non-quiet opening positions can be avoided by putting all pieces more valuable than a Nightrider two ranks behind the Pawns. Then the Pawns will block any Nightrider attacks on them. And of course make sure all Pawns and pieces directly behind them start protected.

I find nightriders difficult to visualize, even with the three-colored board, but despite that they seem to work well in the grand apothecary games since there are enough pawns and weaker pieces to block them.

Thanks for the comments guys! Hopefully there are more to come.

@HG,

The awkwardness of nightrider I expect it goes away with sufficient play. Anyway computers don't "feel" it. But if the game is badly designed computer play will yield very biased results. At a practical level you need not have all heavier pieces 2 ranks behind a pawn and GAC A,C & M proves that. Just most of them. I guess there is reason for experimenting. Because this way you don't need to go all in with the theoretical approach.

@HG, By the way. The interactive diagram evaluates vultures less than 12 directions leapers such as the champion. Isn't this weird?

This is probably because Vultures can easily be blocked. A Falcon, which also has 16 targets, empirically tested as about equal to a Rook. Th Vulture has 4 paths rather than 3, but each path can be blocked in 3 places rather than 2. The 4 non-capturing leaps add comparatively little.

The value estimate of the Diagram takes this into account by measuring the average number of moves in randomly generated positions where 25% of the squares are occupied.

Hi Aurelian. I belong to those who are not at ease with NN. Same with DD or AA and all their compounds. I had tested once a FDD to finally give it up. But I agree that they can be used if the game is designed for, like yours. It also requires a certain anticipation from the players who are not used to, and this is precisely what I'm missing from my side.

Thanks for the reply Jean-Louis!

@Jean-Louis

I have not designed these games for the nightriders but they seem to work ok probably because of the high board density.

I would expect it to be weaker against more different pieces of roughly the same value. Because it allows the opponent more opportunities to do a move that makes the Imitator harmless in its current location.

In comparing the joker inthe 10x10 games with the joker in 12x12 games I've noticed that having more "options" is good. Imagine a KJBB vs KJBN the KJBB side has an advantage because the joker sees more potential moves.

Virtually all chess programs generate moves completely from scratch in every new position they reach. So after 1. e4 (and the opponent's reply) they would generate all Knight moves again (and now Ng1-e2 would be amongst those), and would try to generate new Rook moves (again without getting any). What you mention would only be relevant if you wanted to generate moves incrementally, by deriving the new list of moves from one you already had, by adding some new moves, and deleting some old, but keeping most of them. This can be done, but for games with the complexity of orthodox chess is not very much faster than generating the moves from scratch. That is, it could be much faster, but it would be very complicated to achieve that. So no one does it. (I wrote a kind of blog about it on talkchess.com, though, under the title "The Mailbox Trials'.)

For larger variants (larger board, more pieces) the incremental method could become competitive, however. I used it in my Tenjiku Shogi engine ('Inferno'), and could reach a speed of 500k positions/sec, which is similar to what most engines for orthodox chess can do, despite the 4 times larger board and and 5 times as many pieces. One problem is that it would be quite hard to make it general enough to do many variants. The incremental method must figure out which slider moves are blocked and which discovered by the move that is searched. If all sliders move along orthogonals and diagonals (as they tend to do in Shogi variants, and certainly do in orthodox chess) it is still manageable, but if the variant also has bent sliders (like the Griffon) or hook movers (like in Maka Dai Dai Shogi) it becomes far more complex to figure that out. The area move of the Fire Demon and Vice General in Tenjiku Shogi is almost impossible to do incrementally, so Inferno generates that from scratch in every position.

Alpha Zero relies on an enormously large neural network for evaluating a position, and suggesting moves to search. This takes so much time to compute that the time to generate moves is completely negligible to it, no matter how inefficiently you do it.

Thanks a lot, HG!

A mistake most starting chess programmers make is trying to optomize these kinds of things. It is not a good use of your effort. Even if you double the computational speed of your program, that is only good for about 70-100 ELO. The important thing is being bug-free and the optimizaitons make things more complicated and introduce more bugs.

Yes, Greg I'm sure you are correct. Moreover in this context it matters less. This is a training program. It can take more time to learn the game, but as HG has said, it is of little consequence.

Also note that LeelaChess Zero, the imitation of Alpha Zero that can run on a PC, took about 6 months of computer time donated by a large collaboration of people with powerful computers to learn how to play Chess. For AlphaZero this only took 4 hours, but only by virtue of the fact that they used 5000 of their servers equiped with special hardware that calculated hundreds of times faster than an ordinary PC. On a single PC you would be lucky to achieve that in 6 years of non-stop computing.

I'm aware of this fact, but I'm not sure about six years. Isn't it closer to a few months?

Pretty sure H. G. is correct. There is a reason I spend no effort on the neural network approach.

It would be a few month when you had a few dozen computers with very powerful GPU boards as graphics cards. For orthodox chess.

But I should point out there is another approach called NNUE, which uses a far simpler neural net just for evaluation in a conventional alpha-beta search. This is far easier to train; for orthodox chess a few hundred-thousand positions from games with known outcome would be enough.

Well hundreds of times slower it is not that but. 1000 times slower will be 4000 hours which is 167 days. That is doable. I have one computer for one game (2 in total, remakes of apothecary chess). But my games are 10x10 and have bent riders and an imitator which could itself make things much worse. There could be artifices in the beginning by inserting fake endgame conditions which will train things like "Do not exchange your queen for a knight!".

Anyway I'm doing this because it is the only thing that motivates me so far. With the new treatment (actually 3 years now), I am able to pay attention to stuff. I really enjoy doing this. And the programming is not that hard actually, although there are also NN things I do not understand.

@HG and @Greg Thanks for your advices!

@HG,

The alpha-beta search would have replaced the feature extraction part of the NN. That is from what I understand. That is the part I did not understood (especially what filters does the CNN use). Anyway even if it takes a huge amount of time the algorithm will still improve. So I could present a user with monthly updates. But I'm afraid it will take time until an challenging AI is outputed by the program.

Once again thanks a lot for your help!

You will be already 5000 times slower by the fact alone that Google used 5000 servers, (if I recall correctly), and you only have a single PC. And each Google server contained 4 TPU boards, each capable of performing 256 (or was it 1024) multiplications per clock cycle, while a single core in a PC can do only 8. So I think you are way too optimistic.

I am not sure what your latest comment refers to. If it is the difference between AlphaZero and NNUE: the main point there is that the NNUE net uses 5 layers of 32 cells, plus an initial layer that can be calculated incrementally, (so that the size matters little). While the AlphaZero net typically has 32 layers of 8 x 8 x 256 cells.

I don't want to discourage you, but the task you want to tackle is gigantic, and not very suitable as an introductory exercise in chess programming. A faster approach would be to start with something simple (at the level of Fairy-Max or King Slayer, simple alpha-beta searchers with a hand-crafted evaluation) to get some experience with programming search, then replace its evaluation by NNUE, to get some experience programming neural nets. The experience you gain in the simpler preliminary tasks will speed up your progress on the more complex final goal by more than the simple tasks take. Also note that you will have the disadvantage compared to people who do this for orthodox chess of not having high-quality games available to train the networks.

@HG,

Yes, in my previous comment I was referring to the difference between neural net and the NNUE approach. Alpha Zero's neural net has 2 parts. A CNN feature extraction part and a fully connected classification part. In the NNUE, from what I understand, you keep only the second part. I have said that I did not fully understand how the CNN part works. I'm not sure what filters it uses. But I do not think this is a question for here anyway.

Indeed such questions are more suitable for talkchess.com.

But the fact that the AlphaZero NN also has a 'policy head' next to the evaluation is not the largest difference. IIRC this is only a matter of the final layer, which calculates a preference for each possible move in the same way as the score of the position is calculated. (I.e. each move output is fully connected to the previous layer.)

The main difference is the size. The AlphaZero net is so large that even using a Google TPU or a fast GPU to calculate it slows down the engine by a factor 100-1000, in terms of positions/sec searched. The NNUE only slows the engine by a modest factor, even on a CPU, because it is so small.

@HG, Thanks for not discouraging me. That matters a lot, thrust me. I'll then slowly train weak bots but stronger every time. Maybe in time hardware will become available. And also, who knows, better software ideas. Good luck!

A NNUE with an alpha-beta search is fine: Stockfish 15 is stronger than any other chess player in the world, either human or computer.

The main thing that is interesting with Alpha Zero is that it can play a super human game of chess with no human chess knowledge except the game's rules. So, for example, any opening or midgame strategy is has is not based on human play.

Actually, when programming a new game it is not easy to do alpha beta search. I was thinking to add some positional features (like moving the central pawns) to the input of the neural network. This should speed thinks up a bit.

What do you mean? Alpha-beta search is always the same, no matter what variant it is used for. It does not even have to be a chess variant. As long as it is a deterministic 2-player game with perfect information it should work the same.

I meant the pruning!

What pruning? Alpha-beta search only prunes after a beta cutoff, and this does not require any knowledge about the variant.

Ok, HG, I could have misconstrued something. But from what I understand I'd have to cut some moves while doing the alpha beta search. For example, after a certain number of plies. And then do the classification learning. Have you said something else? Anyway, I was saying that I can use handcrafted features at input to the neural network.

The only moves that are pruned in an alpha-beta search are those whose score could not possibly affect the move choice at the root, because they are in a branch that has already been refuted. E.g. if you find that in a position that is at least equal (i.e. you have already searched a move that does not lose anything), and an alternative move has a reply that loses a pawn without compensation, you would consider that alternative move refuted. It would be a waste of time to continue searching other replies to the move, in order to determine whether these make you lose even more. Because losing a Pawn is already bad enough to dissuade you from playing that alternative move.

This is purely determined from the scores of the moves; you don't need any variant-specific knowledge for it.

Hi H.G.

My memory/understanding may be off, but I thought if for a chess engine line A is at least = and line B results in doubled isolated pawns without compensation, then line B would be pruned out. It's not due to material loss (e.g. a pawn for nothing) but rather due to chess-specific knowledge (that doubled isolated pawns are bad if not compensated for). I could imagine a CV where the opposite might be true, depending on the rules of movement or topology of the board, i.e. where doubled pawns might be good (e.g. in a game of Berolina's Pawns).

Well, it is a bit more subtle than that, because you would not know what line B leads to without searching it first. And after you have done that, it is too late to prune it. So what really happens if that after you have found the single reply to the first move of line B that leaves you stuck with the doubled Pawns, you consider the first move of B refuted, and you prune the remaining replies to it.

But you are right in the sense that positional characteristics can also be sufficient reason to reject a move. This is purely a matter of evaluation, though. Whatever search method you would use, it should in the end give you the line to the position with the best evaluation that you can force (the 'principle variation'). If there is no mate in view the evaluation of positions must be based on heuristics. Piece values are one such heuristic. In general one should base the evaluation only on features that are not easily changed. Otherwise it would be pretty meaningless, as you know the game must go on from there (even though it is beyond your capability to take into account what will happen then), and if the feature would in general not persist after the next move it is pointless to optimize it. But next to material composition pawn structure is definitely a persistent feature (with FIDE or Shatranj Pawns!). King safety as well, when the King is a slowly moving piece.

What you will have to consider in evaluation can indeed depend very much on the rules of the variant. Using a neural network for evaluation (as both AlphaZero and NNUE do) and training that on positions from games is a method to avoid having to think about that yourself; you hope the NN is clever enough to recognize the important features, and quantify their importance. Whether this leads to different pruning in alpha-beta search is of no importance; this kind of pruning is guaranteed to have no effect on the principal variation that will be found. With or without pruning this would be the same. The pruning is just an optimization to get that same result, which was fully specified by the evaluation of the tree leaves, without wasting time on lines that neither of the players would want to play.

From conventional chess engines it is known that pawns on the forelast rank, and king safety can have values comparable to the material value of a minor.

A quick overview for those who are interested ... A traditional Chess program has 3 parts:

Move Generation - Given a position, find all legal moves for the side on the move.

Search - Recursively play out moves and counter-moves to find the best sequence (called the PV or Principal Variation.)

Evaluation - At the leaf nodes on the end of each search path, evaluate the position. This function returns a number - the more positive, the better for player 1, the more negative, the better for player 2.

Chess variants. To program a chess variant, you definitely need to change Move Generation. You probably also need to change the Evaluation function. If nothing else, at least give material values to the new piece types. This is the most pronounced of all the evaluation terms. But other things may need to be altered -- for example, pawn structure is important, but should not apply to Berolina Chess.

The Search is typically extended by something called a Quiescent Search. The Evaluation function cannot reliably detect pins, forks, hanging material, etc., which would all affect the evaluation a lot. So, the Evaluation function can only be used on "quiet" ("quiescent") positions. So after the search function searches all legal moves to the desired depth, it then hands off to Quiescent Search, which continues searching recursively, but searches only captures (and, in some programs, checking moves too, but this isn't common in chess variant engines.) This way, all exchanges in progress are played out and hanging pieces are captured before the position is evaluated.

So, with that background on Quiescent Search ... Remember how I said the Search function doesn't need to change for different variants? Well, that's not entirely true. For some variants, like Shogi (or other variants with drops), or double-move variants, there are no "quiet" positions. So traditional Quiescent Search doesn't work. Other approaches must be taken. ChessV doesn't modify the Search function for different variants at all. That's why it doesn't play Shogi. It does play Marseillais Chess, but I haven't modified the Search, I'm basically just sweeping the issues under the rug... I don't know how Zillions-of-Games works for certain, but I believe it has no Quiescent Search function at all. It modifies the Move Generator to support different games, but there is no variant-specific Search or Evaluation.

ChessV handles the Evaluation by building it from various elements that can be turned on, off, or configured. (Pawn structure, king safety, outposts, colorbinding, open file bonuses, castling rights, etc.) You can find out basically everything ChessV does for every game it plays by looking at the Game Reference: http://www.chessv.org/reference/games/

Thanks Greg, My conundrum comes from the definition of leaf nodes. In the traditional way you apply the evaluation function, but in the MCTS of Alpha zero are only when the endgame conditions apply.

I thought AlphaZero used the output of its NN for evaluating leaf nodes. That makes it different from 'normal' MCTS, which would randomly play out games until they satisfy a win or draw condition, and uses the statistics of such 'rollouts' as a measure for the winning probability in the leaf.

The NN outputs a probability distribution over all the possible moves (illegal moves are set to 0 and the probabilities sum to 1). The MTCS call for this distribution, combine it with an exploration coefficient and Dirichlet noise, to form a score, and choses a move to expand until a certain number (in chess is 6000) of nodes have been visited. Nodes are expanded until leaf nodes are explored. This link explains it better than I:

https://joshvarty.github.io/AlphaZero/

That describes the 'policy head' of the NN, which is used to bias the move choice (which is otherwise based  on the number of visits of the move and that of the total for the node, and the move scores) when walking the tree from root to leaf for finding the next  leaf to expand. But my understanding was that when the leaf is chosen and expanded, all daughters should receive a score from the 'evaluation head' of the NN in the position after the move, rather than just inheriting their policy weight from the position before the move. These scores are then back-propagated towards the root, by including them in the average score of all nodes in the path to the expanded leaf.

I do not understand "tgat". You probably meant that.

Indeed. Hard to avoid typos on these virtual keyboards of Android devices... I corrected it.

I'm not sure I understand what you say, HG!

What is not understandable? Typo! What else.
By the way, details about programming are not clear for most people. How to deal with it?

I did not meant the typo!

By the way, details about programming are not clear for most people. How to deal with it?

I don't think there is any "fix" to this issue.  I am not sure there is any issue at all.  Some conversations are going to involve things other people don't understand.  That said, the talkchess forums are the usual place for these kinds of discussions, but I am happy to have some discussion here as well.  Some people who are not chess programmers may still be interested in whether the new neural-network techniques being applied to orthodox chess can be applied to chess variants.

That sounds plausible.

Testing

There is a 'Restart' button in the AI panel (which would start a new game, but shuffle the pieces in case of a shuffle variant), as well as a |< navigation button for getting back to the initial position of the current game (undoing all manipuations that were made so far). But you would have to open the AI panel to see those buttons. I never payed much attention to this, because the browser refresh seems an alternative that works just as well.

Slowless in loading is in a sense a self-inflicted problem: I let the Diagram script intentionally delay 1 second before executing the code that creates it. This was to solve the problem that comment pages contain multiple Diagrams, each of the comments referring to the script (because at the time they were posted the user assumed he would have the only comment with a Diagram on that page). If the first Diagram then immediately starts executing the script, the other Diagrams might not have been loaded yet. Ideally the script should only execute after the page has completely loaded. I tried to do that using onload="Init()", but that never was executed. Probably I was doing something wrong, but I have no idea what.

In principle generating the Diagram with the script should be very fast, probably faster than loading a dedicated image. Because the JavaScript and piece images should all come from the browser cache, if you have viewed other pages with Interactive Diagrams and the same pieces from the same set before. A dedicated image would be specific for the page you are loading, and you would most likely not have seen it before.

Hi J-L

I have a vague feeling that the 'What's New' section used to be prominently displayed on the CVP main page, but somehow it got buried a bit. Bugged me initially, but I got used to it. Still, it might be a turnoff for newbies to the site who don't know where to look for all the vital info covered by 'What's New'.

Very nice!  This has come a long way.  One small glitch I noticed is that if you click to move a piece and then right-click to reset, the banner still says "position after (half)move 0" rather than returning to its original state.

Sorry I didn't respond sooner to the question about why I don't use the interactive diagram as the main diagram.  I think it was primarily because I wanted complete control over how the board looked.  Now it has lots of options to set colors, etc., but if I remember correctly, it didn't originally let you set squares colors.  Now you can pick piece graphics, set square colors, and set border color.  I think that mostly addresses the concerns.  I can only think of two outstanding concerns (one is probably very easy to address, the other is probably not.)

First, I am assuming you cannot change the rank/file notations.  This is generally unimportant, but there are exceptions.  For example, in Brouhaha, the files have different names so that the main portion of the board still has the usual files a through h.

Second, to the right of the board, I was listing the pieces and locations using the long-standing format of the Chess Variant Pages.  I then started adding the array FEN (perhaps not useful to some, but very useful to others as the most compact descripton of all the pieces, their starting locations and notations.)  If it was possible to add text below the piece list for the optional specification of array FEN, or whatever the author wanted to write there, I think that would be sufficient.

Now it has lots of options to set colors, etc., but if I remember correctly, it didn't originally let you set squares colors.  Now you can pick piece graphics, set square colors, and set border color.  I think that mostly addresses the concerns.  I can only think of two outstanding concerns (one is probably very easy to address, the other is probably not.)

Well, the options to color the squares and use arbitrary sets of piece images has been there from the very beginning. What is a relatively recent addition is that you can also enable a rim with coordinates around the board, and specify the color and letter color of that.

About the coordinates: there already is an option 'firstRank' which you can use to specify how ranks are counted. (And then enables the display of the coordinate rim.) I don't have something like that for the files, as I couldn't imagine this would ever be needed. Bfore 1 comes 0, and indeed some variants count 0-9. But what comes before 'a'? Anyway, it should be easy to implement an option 'fileLabels' that would override normal labeling.

I did not quite understand the other request. You are referring to the 'satellite' that can be embedded in the text to display the pieces as clickable items in an 'unnumbered list'? Would the FEN have to appear as the last item in that list? The list would only be added if you embed the HTML <ul> directive with the proper satellite id in your text. I could easily make it such that items you already specified in that list remain at the bottom of it after the Diagram scripped has filled the table with the piece items. If you want the FEN to appear below the table, you could write it there yourself in the HTML. Or do you expect the Diagram script to generate the FEN? Not all sets of piece IDs would allow a position to be encoded as FEN, though. (There could be multi-letter IDs, of some pieces might have the same ID.)

P.S. There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

The obvious remaining reason to favour static images over the interactive diagram is that the latter only works with Javascript enabled. I suppose the obvious(?) way around that would be to also have the design wizard generate a link to a Diagram‐Designer‐ or Scalable‐Diagram‐Editor‐generated (if the latter gets installed?) image and wrap it in <noscript> tags?

P.S. There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

The same is true for the first two comments to be moved to this thread, when viewed through the main comments page (EDIT: and apparently this comment too; the comment editing form has the following warning above it: The ItemID 836609b4fd3c40eb no longer matches any item in the Item table.)

the options to color the squares and use arbitrary sets of piece images has been there from the very beginning

Ok, sorry.  Not surprising that my memory is inaccurate ...

Anyway, it should be easy to implement an option 'fileLabels' that would override normal labeling.

That would be great, it its not too difficult.  Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense.  Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...

Regarding the array FEN, no, I am not asking the interactive diagram to generate it.  If I could add custom text under the list or under the board that would do it.  My appologies if this is already possible - it may well be.

There is something very strange with the title of your posting, which is not equal to the title of the subject thread.

Yes, my post was a standard reply.  Don't know what happened here, but probably another glitch of the site move.

That would be great, it its not too difficult.  Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense.  Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...

There is a problem, though: I see that you are using 'x' and 'z' for the edge files on your Brouhaha page. But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator. There must be some restrictions on file labels to make notation work. If it was only a matter of choosing what to display in the margin of the board diagram it would not matter what labels you choose. (As long as they are not so large they would not fit in a cell the size of a square.) But the SAN generator and move parser must also be adapted to use those labels.

Regarding the array FEN, no, I am not asking the interactive diagram to generate it.  If I could add custom text under the list or under the board that would do it.  My appologies if this is already possible - it may well be.

Well, the Interactive Diagram is just an element in the HTML page you would submit as an article or comment. It would be entirely up to you to design the rest of the page. You just embed the Diagram and its 'satellites' in the page you design by inserting a HTML tag pair with the proper id (or, for the board element, with class="idiagram") in the place where you want those to appear. The board element will contain the Diagram's specification, which will be deleted by the script, and then all the recognized elements (board diagram, piece table, piece list, piece descriptions) will be filled with the proper content according to the specs.

There only would be a problem if you would want to have extra text embedded in the elements that are filled by the script, because anything you write there would be replaced by what the script generates for that element. The reason for having the script generate those elements, rather than have the user write them, is usually that they contain clickable items that must invoke functions of the script. It would not be very hard even for an HTML-ignorant user to supply a list of pieces and their starting squares (by using the WYSIWYG mode of the editor), but clicking the pieces would then not summon the move diagrams.

[Edit] Perhaps we get away with the 'x' in Brouhaha: there are only Brouhaha squares on that file. They can never be destinations, and SAN would never mention a square of origin unless there is a need to disambiguate. And since the piece starting on this square is color-bound, and its Brouhaha squares for the same player are of different color, disambiguation for a Cleric move would never be needed. So the 'x' would never appear as a square coordinate in the move notation, and the fact that the move parser assumes it will never be a square coordinate will not hurt.

But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator.

This is an excellent point.  ChessV doesn't use SAN at all and I'm not really familiar with it so this didn't occur to me.  Probably best that I change the extra files to 'y' and 'z'.

Probably best that I change the extra files to 'y' and 'z'.

Well, if it is important for backward compatibility you could keep the 'x' for Brouhaha, as I explained in the edit of my previous posting. I suppose there aren't many other variants where simple a-... file IDs would not be satisfactory. Perhaps Omega Chess.

I think that there is very little reason to ever use anything else than consecutive letters to indicate the files, so a general way to define arbitrary individual names seems like overdoing it. A satisfactory solution would be to define 'w' as the letter preceding 'a' (to avoid xyz), and count backwards through the alphabet when more-'negative' letters are needed. So for Brouhaha we would use 'w' and 'i', and could describe the system by specifying a simple offset (e.g. firstFile=w). Another possible system would be to define the number of 'extra files', which would be assumed added to the board proper both left and right, and would have their own system of letter assignment from near the end of the alphabet. The first file of the proper board would then always be 'a'.

(I think I've fixed the subject title for comments in this thread; it wasn't an artifact of the site move, but rather of me not being thorough enough in database edits when I moved over the two first comments.)

The Interactive Diagram can now also generate the list of pieces and their starting square as lines of text, rather than as a table (like it was doing in the original posting of this Diagram). Whether one or the other method is chosen depends on how you embed the piece list on the page. In both cases the HTML tag pair that indicates the point where the list will be inserted will have to have id="pieceList". When the tag having this id is an unnumbered list (<ul>), the Diagram script will fill it with clickable list items for the pieces. When it is a paragraph (<p>) it will create text lines from clickable spans to describe the initial piece set up, like in the example below.

I am not sure whether the blue text for reminding people that the text can be clicked is optimally placed; there seems enough room to put it behind the 'White:' header on the same line.

Note that the starting squares of black pieces are now also mentioned. This is another improvement; only the white pieces used to have their starting squares mentioned. Because those are the only coordinates the user must supply when specifying the Diagram. For the black pieces one usually depends on the symmetry setting (mirror or rotate) to deduce the black starting squares from the white. The Diagram now converts the deduced starting squares to text form so that it can give them for the black pieces even in those cases (and for asymmetric setups displays those as given by the user).