> Ideally, I would like something like this that still uses a graphic image when JavaScript is disabled.

This is exactly what I did in my Chu Shogi description on this site, which is intended as the 'show case' for how this feature can be applied. Of course the article already did have a static image, so I just put that between {noscript} {/noscript} tags, so it would show up when JavaScript is turned off.

But that would not make the text description of the diagram go away. When JavaScript is active it replaces the description text by the HTML table description of the diagram, but when it is not active, it obviously cannot do anything.

I guess this can be avoided by giving the {div id="diagram"} element an initial style="display:none" qualifier, and have the JavaScript then change this to display:inherit after having replaced it by the diagram. I'll add that statement to the .js file. The initial invisiblility, and alternative noscript content would obviously have to be provided by those who want to incorporate the diagram in their text. If I expand this article with a design wizzard similar to what I have now on http://hgm.nubati.net/variants/diagram/design.html I can make it add the display:none qualifier. The submission script would then also have to do that when it processes a [diagram] directive in a non-HTML submission.

> It would work only when rule enforcement is already programmed, and how it works would depend upon how the rules were enforced. However, I could devise a means for letting the user provide the same data for a diagram without programming the rules.

Well, I don't know GAME code, but it seems to be a programming language. Which is way beyond the abilities of the average non-programmer user to provide. The whole idea of the rule-aware interactive diagram was that a noob user should be able to define the game. E.g. for Elven Chess all that would have to be provided by one not using a design wizard is

[diagram]
files=10
ranks=10
promotionZone=3
promoChoice=QNRB
symmetry=rotate
pawn:P::pawn:a3-j3
dwarf:D:K:man:a2,j2
knight:N::knight:b2,i2
bishop:B::bishop:c2,h2
rook:R::rook:a1,j1
elf:E:BW:cardinal:d2
goblin:G:RF:marshall:g2
queen:Q::queen:f2
warlock:W:KNADmabKcaKcabK:lion:e2
king:K::king:f1
[/diagram]

graphicsDir=../member.graphics/MSmyvariant/
whitePrefix=White
blackPrefix=Black
graphicsType=png
squareSize=36

The only advantage I can see of solving this on the server side is that it would also work when JavaScript is disabled. That could be a legetimate design goal, but in that case I think it would be essential to provide a sort of compiler in the submission script that transforms a similarly simple description of the game to GAME code.

I have already started to implement what I described. I have rewritten subroutines that check for checkmate and stalemate to additionally create an array of all legal moves, which it then passes to JavaScript. When the JavaScript is showing legal moves, it does not rely on the GAME Code that created the array. The showing of legal moves is done entirely on the client side with JavaScript. The calculation of which moves are legal is done beforehand on the server with GAME Code. So, what could be done is to have Game Courier create a diagram, copy the diagram and JavaScript for it to another page, and manually add an array of all legal moves for the position displayed in the diagram.

So it now also works when rule enforcement is not already programmed?

At present, I am only focusing on adding the ability to display legal moves within Game Courier, and this requires code for enforcing the rules. Nevertheless, it is presently possible to use Game Courier to create interactive diagrams without the rules programmed if you know what to copy from the page source and how to write the legalMoves JavaScript array. In the future, I will make this simpler for the user.

>> Ideally, I would like something like this that still uses a graphic image when JavaScript is disabled.

> This is exactly what I did in my Chu Shogi description on this site, which is intended as the 'show case' for how this feature can be applied.

I just went there, turned off JavaScript, and didn't see the diagram anymore.

> Of course the article already did have a static image, so I just put that between {noscript} {/noscript} tags, so it would show up when JavaScript is turned off.

I searched the source of your Chu Shogi page for noscript, and it didn't turn up.

> But that would not make the text description of the diagram go away. When JavaScript is active it replaces the description text by the HTML table description of the diagram, but when it is not active, it obviously cannot do anything.

You could just put the parameters for the JavaScript code in the JavaScript as a series of variable assignments. Or you could encapsulate your code in a function and pass parameters in the function call.

Okay, the static image now shows up when JavaScript is off, and no parameters show up on the page when it is off.

Hi H.G.

Is there a (preferably simple) way for your 'Interactive Diagrams' to generate diagrams for unusual board shapes such as hexagonal, circular or custom boards?

Thanks H.G. for your reply. "Custom board" diagrams are described this way in Game Courier documentation, so it seems your answer of 'no' is right on, as I had very oddly shaped boards as one possible thought, for one thing.

For now, I had been a bit curious about circular boards, and wished to test making a diagram for one from scratch, by simple means if possible. If I wish to, I think I can cut and paste the http address for an existing setup diagram, such as I've seen on a number of webpages on this website. I'd be confined to using the setup that it depicts, unless I combined it with other (preferably circular!?) setup[s], to create a 3D (or even 4D?!) variant of my own, for example.

Even using just one circular board setup diagram, however, I might invent my own rules for the piece movements to be used for any possible variant of mine, to be played on that circular board. Recall (naturally) that many variants have been created using just the setup for standard chess.

In regard to diagrams for "custom boards" again, I also was thinking of, say, even 8x8 boards with graphics on individual squares (or some of them). I think I've seen at least one such board used for a variant included on this website. A whimsical thought that came to me the other day would be to somehow combine Chess and Snakes & Ladders, though it would be a very involved and lengthy project to complete, I suspect.

It is a good idea to test out your future submission techniques, but it escapes me why you have to do it in the comments to my interactive diagrams submission. If you don;t want to pollute your own submissions with non-informative and possibly failed experiments, why do you pollute mine? This is totally off topic. The Interactive diagrams are not 3D, and not circular, but limited rectangular 2D boards, as this is how HTML tables look.

My apologies H.G.

1. Is it possible to add and foul, a piece that imitates the last move of the opponent?

2. I'd like on a 10x10 board to make the promotion zone from rank 8 to rank 10 for pawns. Pawns should promote to maximum rooks at ranks 8 and 9 and everything on rank 10. Can I do that?

Thanks, for this wonderful tool you just uncovered for me!

Describing a Fool is currently impossible, as there is no Betza notation for that. Because the diagram doesn't enforce turn order, the concept of 'previous move' is a bit fuzzy. Although it is used to implement e.p. capture. So I suppose it should not be too difficult to fix this.

As to promotions: when you specify a zone depth of 3 it would ask you to choose a piece from the legend every time you move a Pawn to rank 8, 9 or 10. By specifying a promoChoice that includes P it will also allow non-promotions. But you could then always pick all allowed pieces everywhere. To refuse 'promotion' to P on rank 10, and to N, B and Q on rank 8 and 9, you would have to put additional JavaScript in your submitted page. Before performing any move the diagram tries to call a function WeirdPromotion that it does not define itself, and which must specify the piece to appear on the to-square, as a result of the move coordinates and proposed piece. I use that in Werewolf Chess to force pieces that capture a Werewolf to turn into one:

function WeirdPromotion(x1, y1, x2, y2, promo) {
  if((board[y1][x1] & 15) != 6 && // King immune
     (board[y2][x2] & 15) == 5) promo = board[y1][x1] & 1024 | 5 + 512;
  return promo; // normally a no-op
}

It should be possible to provide code here that would turn a Pawn on 10th rank to Q, and the choice of a Queen into a Rook on 8th and 9th.

Note that the diagram is not (yet) intended as a way to actually play the game. Just as a convenient way to demonstrate how the pieces move.

Still is a very useful tool, so thaks for it!

What do I do with the result, as I'd like to experiment with playing the game a little bit before submiting it. Earlier I've deleted a pawn and I had to do it all over again. I do not want to repeat that. Now that I tried it a bit it doesn't seem worthy for publishing IMO.

When you have pressed the 'Create HTML' button after having set up the initial position, a text pane will appear right of the diagram, which displays the text that you have to paste in a HTML document at the point where you want to make the diagram appear. You would have to paste that in the submission form of your article (e.g. in the 'Setup' section) to make the diagram appear there.

If you want to use it in another place than an article here on CVP, you would have to also copy the .js file to which the HTML text refers to the proper place, as well as the piece graphics used. If you want to use the diagram on your own computer, you can design it with complete URL for the graphics directory, pointing to the chessvariants.com website, (and later edit the nameof the js file in the diagram definition to a complete URL), and paste it in some HTML page. It would then only work in your browser when you are on-line, though.

Ok, so only there! Thanks!

I was still adding a paragraph to my previous post; be sure not to miss it. You can use the diagram elsewhere, but you would have to copy the image files and JavaScript file that are present on CVP, or fully link to those.

BTW, the underlying JavaScript can actually do more than what is needed to just power the diagrams as used on CVP. It also supports functions to collect a game, and navigate through it. You would just have to put buttons in the HTML to activate these functions. See for instance http://hgm.nubati.net/variants/elven, where I use the diagram on my own website. You can also copy that HTML page, and then replace the diagram in it by your own from the Design Wizard.

Ok, thanks! I actually know nothing about JS but i'm good with general programming so I guess i'll handle myself!

In the meantime, I think I inadvertently posted 2 variants I did not suppose to, How do I delete them?

Ok, I have no clue how to do what you've just said on my computer, if you have the time to tell me the baby steps, or let me send you the html code that the wizard has done, make work on your machine and then send me the result i'll owe you a beer, in my first trip to US, or your first trip to Romania

OK, here it comes! Copy the text below to a file, ad save it on your computer as 'trial.html'. If you then open that file with your browser it should show an interactive diagram for Elven Chess. Then you can try replacing the diagram definition inside the file (the pink part) by what you get from the Design Wizard for your own variant. You will have to change the definition of graphicsDir to http://www.chessvariants.com/graphics.dir/alphaerie , (i.e. replace the ".." in the location by the URLof the CVP website) and the link to the JavaScript source (in the first line) to http://www.chessvariants.com/membergraphics/MSinteractivedia/betza.gif (or leave that line in place, as it is already written that way in the HTML below).

Note that in this context the legend belonging to the diagram is not hidden below it, but placed openly next to it. This is caused by the presence of a 'table' element with id="pieceTable" (highlighted in green) elsewhere on the page.

Well, it doesn't show a diagram of elven chess, but the own text of the html, this is what it happens when I try to upload it on the website, too. What am I doing wrong?

What happens when you paste the URL that is given by the src= of the script tag into the address field of your browser?

It says: "The image [...] cannot be displayed because it contains errors" where [...] stand for the content of the src=

That is the correct response; it means it could read the file and inspect its contents. (It is not really a .gif file but a .js file that I renamed to .gif, because the CVP submission form did not allow me to upload .js files. So it is not surprising the Browser does not recognizeit as a valid GIF image file.)

That makes it strange that the text of the diagram description is not replaced by the diagram. Because this is what the JavaScript is supposed to do. I suppose you do see the diagram on the Elven Chess article on CVP, and on http://hgm.nubati.net/variants/elven ?

Yes, I see the diagram there.

I solved it, for some reason using open office instead of notepad does that, now I'll try to paste my own code!

The graphics are wrong, but the script works! For images it shows just cracked images!

It works great for the other game, the one with archbishops!

It works now, have you done something HG? or I just copied stuff wrong the first time?

Must have been a copying error. I was just reformatting my earlier posting that showed the required HTML, adding borders and background coloring to it, but not changing anything substantial.

Now I can actually play games, thank you H.G., I see now how silly they look. Thank you very much! It's now getting late here. See you soon!

I have added a nice improvement to the ShowMoves(N) function associated with the diagram. Before, this function used to show the moves of the Nth defined piece that was defined, on an empty board. And if you invoked it again for the same piece, it restored the original board position. So that you could attach it with an onclick="ShowMoves(N)" to a HTML element that describes the piece in your submission text, to make clicks on it interactively show the moves.

The new feature works for variants with Shogi-style promotions (i.e. where you defined a non-zero promoOffset P to relate each unpromoted piece N to a unique promoted partner N+P). When you invoke the function a second time with the same N it shows the moves of the promoted piece.  It only reverts to displaying the origial position when invoked a third time. For unpromotable pieces the second invocation already makes the board revert to the original position, as before.

In addition it now always shows the name of the piece it displays the moves of in the message above the board. A good place to see it in action is the Chu Shogi article.

All your work the passed weeks with the diagrams is great, but I must ask:

1.Do they support hexagonall mappings?

2.Do they suport Xiangqi style rivers?

I think the short answer to both questions is no. Any hope for these facilities soon?

I am not sure what you mean by 'Xiangqi-style rivers'. As for graphical representation, Xiangqi is played on grid-points rather than squares, and the diagram will never be able to do that, as it is just a HTML table with images in the squares and lines between the squares. So displaying a River is just a tiny detail of something it cannot do in the first place.

If you mean that you just want certain pieces to be limited to a fraction of the board, this is already possible. The latest .js script for the diagram checks if there exists a user-supplied function BadZone(file,rank,piece,color). If there isn't, it assumes any piece can venture anywhere on the board. But if there is, it only accepts moves where the fuction returns 0 for the destination square.

To indicate the zones by coloring of the board the user can similarly supply a function Shade(file,rank), which returns a color.

So to do Xiangqi (with a western-style board) the HTML page defining the diagram would need to contain the extra text

<script>
function BadZone(x, y, piece, color) {
  if(piece = ELEPHANT) return (color ? y < 5 : y > 4);
  // cases for King and Advisors
  ....
}
function Shade(x, y) {
  var color = 0;
  if(y > 4) color = !color; // board halves
  if(x > 2 && x < 6 && (y < 3 || y > 6) color = !color; // palace
  return color;
}
</script>

As for hexagonal boards: this is currently definitely not supported. It would not be totally impossible to support something close to it in the current framework, however. The board must be a HTML table, which means rectangular cells. But it is possible to have cells extend over more than one column in HTML. So by doubling the number of columns, and then alternately fuse odd+even or even+odd on different ranks, you would get a masonry-like pattern which should be close enough.

Thanks, It's nice to know for future projects!

I've noticed somthing odd with my diagrams for small apothecary 1 chess (the ones on my computer that use the javascript). The griffin, and griffin only shows grey pseudo-check moves. This can't be right and needs fixing.

And the queen in small apothecary 2!

Ah, this is a consequence of the new way to handle the royal piece. The diagram must think Griffin and Queen are royal. By default the last-defined piece is royal. If you don't want that, you can add a line

royal=N

to the diagram definition, with N the ordinal number of the King.

Ok, thanks!

You were correct,H.G., I did written royal=3 (as was my case) and I'm fine!

H.G.

Diagrams don't seem to work anymore, just code appears!

> Diagrams don't seem to work anymore, just code appears!

Is this still the case now? It could have been due to an update of the browser you use, which prevents it from using .gif files as JavaScript sources. Initially the JavaScript powering the diagram was uploaded as a .gif file, because the CVP software did not allow me to upload .js files. But the Chrome browser did not want to use the .gif file from the very start, and Fergus then copied the .gif file to a .js file, and altered the upload scripts so that I could update that. But recently the diagrams that were still using the .gif file also stopped working for me in FireFox, and became active again when I changed them to use the .js file. The diagram creator now also will refer the .js file rather than the .gif file in the diagrams it creates.

Hello and welcome back, H.G. long time no see.

Unfortuneatly diagrams don't seem to work at my end, I can't figure out why.

Moreover I'm moving to another city these days and I can't get back to you early.

Anyway talk to you soon.

P.S. Off topic HG if you have the time take a look on my two published apothecary games, as you were a influence in their desing!

Yeah, I was very busy with other stuff (such as writing an engine for Tenjiku Shogi), and I semi-lost the password Fergus had assigned me last time when logging in was impossible, (and I of course forgot because it was not my usual one) while attempts to get a new password ran into error messages only. Eventually I managed to find the e-mail with the password again, and once logged in, was spontaneously asked to change it (which did work, so that now I again have a my usual password).

> Unfortuneatly diagrams don't seem to work at my end, I can't figure out why.

I am not sure what you mean by 'at your end'. Is this for diagrams that you created yourself? Or is it even impossible to see the diagrams here on the website? (E.g. the one of Caissa Brittania my previous post links to, or that in the article about Macadamia Shogi.) What browser are you using? Is JavaScript enabled?

Caissa Britania works, I've just checked. Omega chess doesn't. Also the diagrams on my hard drive don't work. I use Mozilla Firefox 52.02(32bit). Java script is enabled. Macadamia shogi works, nice game by the way, I've just noticed it!

Omega Chess should work now too. Funny thing was that when you clicked the 'View' link at the bottom-right to see the comment in isolation it did already work. Problem was that I referred to the JavaScript file through a relative path "../membergraphics/MSinteractive-diagrams/betza.js". But the Omega Chess page is apparently in another place of the CVP file-system tree, one level deeper than usual (/large.dir/omega/rules.htm), so that this was not correct on the rules page. I now used an absolute path by removing the leading "..".

I guess I never tried to see the diagram on the pages of the articles themselves. When you post them, after seeing the preview, you are routed to the total comments listing, and there you would also see it in a context where the path name would be correct.

As for the diagrams on your hard disk: where does the link in the <script> tags point to? If it points to a betza.gif instead of a betza.js file, this would explain why it doesn't work.

I have now checked out all diagrams I could remember having made, and they all seem to work (in FireFox, at least). As a demo for the various things that can be done with the interactive diagram, I listed links to all of these below:

In comments to existing chess-variant articles:

• Xiangqi
• Quang Trung
• Eurasian Chess
• Caissa Brittannia
• Gross Chess
• Centennial Chess
• Scirocco
• Tamerlane Chess
• Tamerlane II
• Grant Acedrex
• Omega Chess
• Spartan Chess
• Falcon Chess
• Four Board Chess
• Golden Age Chess
• Wildebeest Chess

Variants of my own design using an interactive diagram in their article:

• Team-Mate Chess
• Werewolf Chess
• Mighty Lion Chess
• Elven Chess
• Macadamia Shogi
• Cashew Shogi

Historic Shogi variants for which I wrote an article using an interactive diagram:

• Wa Shogi
• Chu Shogi
• Dai Shogi
• Dai Dai Shogi
• Maka Dai Dai Shogi

Hey, my diagram won't work. Could you help me? The code that I used is below. I am using my own uploaded images, just so you know.

<script type="text/javascript" src="../membergraphics/MSinteractive-diagrams/betza.js">
</script>
<div style="float:none;margin:0 40px 20px 0;">
  <div class="idiagram">
    files=12
    ranks=12
    royal=5
    castleFlip=1
    promoChoice=QCRGBN
    graphicsDir=../membergraphics/MSchess-and-a-half/
    whitePrefix=w
    blackPrefix=b
    graphicsType=gif
    squareSize=51
    lightShade=#DDDDDD
    darkShade=#B8B8B8
    startShade=#0000FF
    symmetry=mirror
    pawn:P:ifmnDifmnHifmR4fmWfceF:Pawn:a2-c2,e2-h2,j2-l2
    knight:N:NimpafN:Knight:b1,k1
    guard:G:WF:Guard:d2,i2
    cat:C:KADcafK:Cat:e1,h1
    king:K:KilO5isO4isO3isO2isO1isO0:King:g1
    queen:Q:QirO5isO4isO3isO2isO1isO0:Queen:f1
    nightrider:NN:NN:Nightrider:,
    centaur:X:WFN:Centaur:,
    star cat:S:KADGHcafKcafmpafKmpafcafK:StarCat:d1,i1
    kraken:∞:U:Kraken:,
    rook:R:R:Rook:a1,l1
    bishop:B:B:Bishop:c1,j1.
  </div>
</div>
<script>
  function WeirdPromotion(x1, y1, x2, y2, promo) {
    var typ = board[y1][x1], r = (typ & 1024 ? 0 : 11);
    if(y2 != r)  return promo;
    if((typ & 511) == 2) return 7;
    else if((typ & 511) == 3) return 8;
    else if((typ & 511) == 4) return 9;
    else if((typ & 511) == 5) return 10;
    else return promo;
  }
</script>

It does not like spaces in front of the key-words / piece names. I am aware that the new editor adds those automatically, every time you open the text-to-be-edited in source mode, which is extremely annoying.

Don't worry about it; I will fix the diagram script so that it automatically strips leading spaces from the diagram definition, and then your diagram should work again. Editing of comments that contain a diagram will still be a disaster, though; it seems that editing source there doesn't let you edit the original source, but instead tries to reconstruct a source from the displayed text, in which process it completely destroys the diagram definition. But submissions with diagrams can then be edited without tricks.

[Edit] Leading spaces should now be ignored. Please test if this solves your problem. Don't forget to reload the page with Shift pressed to flush the old betza.js script from the browser cache.

I have a few questions.

1. Is it possible to describe pieces like the Rose or Crooked Bishop using this notation, which doesn't support the "q" or "z" modifier? Same goes with cylindrical piece
2. What is the "j" modifier supposed to do?
3. Can you merge multiple cells together for a masonry pattern?

The interactive diagrams are completely broken. If you click on a piece, none of the squares are highlighted, and clicking on the target square does nothing.

Thanks for warning me. It should work again, now. When I added the interface with the engine two variables were not declared in the diagram script, but in the page that defined the diagram on which I tested. So it did no longer work with the existing pages. Now I declare those variables in the diagram script.

As to your earlier questions: 'q' and 'z' are not yet implemented in the Betza compiler. I did not kow any variants that featured Rose or Crooked Bishop. Do you have need for them? 'pp' For multi-hopper (which I would need for Tenjiku Shogi) is also not implemented yet.

As to 'j': In the original Betza notation this is ill-defined for oblique moves, like its counterpart 'n'. You would not know to which square(s) it appies. It also seems redundant; e.g. a Dababba that must jump ('jD') can also be written as a hopper with range 2 ('pR2'). In XBoard's XBetza implementation I overloaded the 'j', giving it a different meaning on atoms that do not move 'over' any squares, like W and F: on sliders using such steps the 'j' would mean they skip the first square ('ski-slider'). This is just for conveniece, as it can also be written with the aid of the 'again' modifier: a Ski-Rook would be 'ygaW', meaning that after a first Wazir step it toggles range to infiniteboth on an empty square ('y') as on an occupied one ('g'). But 'jR' looks less obscure.

On the 'O' atom XBetza uses for castling, a 'j' would mean to skip one file when looking for the castling parter starting from the corner. So 'sjO2' would mean castling not with the corner piece, but with the pieces one step inward (i.e. the Knights in FIDE). Omega Chess needed this. But the diagram uses a kludge for this: it always allows castling with a piece that moves like a Rook. So in the diagram I currently ignore the 'j'.

Chess on a Really Big Board uses a Rose, and Golden Age Chess on a Really Big Board uses both Rose and Crooked Bishop. Also, the "j" doesn't work. Writing "jA" or "jD" just gives me a regular leaper.

Well, that is what I said: j was still ignored. But I implemented it now. (Be sure to refresh your browser cache!) The results are undefined when used on oblique atoms, however (like jN). And on G and H atoms it forces jumping if there is a piece on one or two of the overflown squares. Before stepping atoms (W and F) or their derivatives it means they ignore the first square on their path. So jB and jR are Ski-Bishop and Ski-Rook.

[Edit] The q modifier now also works. It always rotates 45 degrees per step, even for orthogonal or diagonal atoms. There is no way yet to indicate direction of curvature; it always bends in both directions for a given start direction (such as fqW4). The Rose is qN or qNN.

[Edit2] Same for z now. It turns 90 degrees in alteratig directions. Also here the trajectory that starts bending right always occurs together with the one that starts bending left after the same first step.

There's still a few problems. The betza parser incorrectly interperets L as (2,3) and J as (1,3), when it should be the other way around. Second, there's something wrong with my diagram here, because the Knight's initial moves (imafN) aren't darkened. Third, your Four Board Chess and Golden Age Chess don't give en passant rights to the pawn. And finally, I would suggest adding Betza's "o" for cylindrical pieces, in addition to "oo" for toroidal ones.

Ah, good catch. I always use C and Z, because I can never remember which of L or J is the Camel. Fixed now.

As to the darkening of initial moves: the problem was that the i modifier was listed with the first leg, while it was tested at the destination, after the second leg. The diagram should now remember the i setting from the first leg even for multi-leg moves. I had never used initial multi-leg moves; I would be inclined to write the move as imN2. This does overlap with the normal move, however, generating it twice, with as a result that the move specified last will prevail. So the total move had to be written as imN2N to get the desired effect.

As to o for cyclinder and oo for toroidal: done!

I was aware of the e.p. problem; the imW6 move does not automatically grant e.p. rights. Furthermore, the code currently only uses 2 e.p. squares even when rights are granted, at 3/8 and 5/8 of the multiple push. Here up to 5 squares would have to be tested. So I should completely redesign e.p. testing. Also, the imW6 is not really describing the Pawn, as from 3rd rank it would still have W5 etc. This is really not an 'initial move', but a location-dependent move rule. For which Betza notation isn't really suitable. Unless something is invented to mean: up to half the board. (W* ?).

BTW, the q and z modifiers can now be combined with p and g, to get crooked and circular hoppers.

[Edit]I have redesigned the e.p. testing now. It tests all squares the rights-creating piece has moved through. This will work both for forward orthogonal and for diagonal moves. In addition, an asterisk as range now indicates 'distance to the 'River' (i.e. the line separating the board halves) or 1, whichever is larger. So that fW* can be used to indicate a Pawn that can always move up to River (and fF* a Berolina Pawn with such a range). Such a move will always create e.p. rights.

I frequently access this site with my Kindle Touch's browser, and I have noticed that using a different color to mark which spaces a piece may move to is not very effective on an e-ink device. To illustrate, here is a grayscaled screenshot of an interactive diagram showing how a Queen moves in Chess and a Half.

Indeed, this is no good. Part of this is Nicolino's fault, by using too dark shades for the normal board checkering; it seems his light shade is already as dark as what I use (and is default) for dark squares. But especially yellow, used to highlight non-captures, is too bright to show up well in grey scales. I guess color coding is not an ideal method on grey-scale devices, unless you are very careful in selecting the colors.

It seems to be difficult to detect if you are running on a grey-scale device from JavaScript. My e-reader still reports screen.colorDepth 16, as opposed to my laptop, which reports 24. Perhaps I should have the diagram use a darker shade of yellow (or perhaps of every color) when running with colorDepth <= 16, assuming most color displays nowadays have at least 24-bit 'true colors'.

[Edit] I have now modified the script to detect colorDepth (after the initial rendering), and adjust the square shades to pure white and very light grey if this is <= 16, irrespective of what the user defined. A darker shade of yellow is then used for 'move or capture' highlights. Ufortuately I don't know how to test if this is satisfactory; I have an old and cheap model Kobo e-reader, it has a browser, but I do not know how to flush its cache. So it keeps using on the old, cached script...

• #FFFFFF: Light squares
• #E8E8E8: Dark squares (grey scale)
• #E0E0E0: Dark squares (default)
• #FFFF00: Move or capture (color)
• #F0F000: Move or capture (grey scale)
• #FFE000: Jump move or capture
• #D0D000: Initial move or capture
• #00F000: Move only
• #00B000: Initial move only
• #00FFFF: Locust capture (destination click to follow)
• #FF0000: Capture (only)
• #0000FF: Capture own piece
• #505050: Forbidden King move

It does help a bit that some colors will only be used on empty squares, others only on occupied square. The move-only and move-or-capture colors will only be used on empty squares. While playing on the diagram (locust) capture will only occur on occupied squares. Unfortunately in the move diagrams capture is also indicated on empty squares; perhaps I should switch to displaying a dummy black piece on the target squares in that case.

[Edit] What also helps is to not use checkering of the board at all when displaying a move diagram. I guess there is no need at all for checkering in that case; the checkering is only useful when you are playing, and want to know if a distant diagonal mover now hits one of your pieces. In a move diagram diagonal moves are highlighted themselves.

Another trick I learned: I can safely use floating style for a diagram in a comment, when I put the whole comment inside a 1x1 table. Then it will ever stick out into the comment below it, not even if you open the legend below the diagram. I tried this in the Wildebeest diagram; I needed the floating style to be able to get the pieceList and board in the same view, so that I could touch the pieces in the list and see their diagram appear, as my e-reader as a portrait-shaped screen, and the diagram and list would not fit side by side.

Looking at your list of colors on my Kindle, #E8E8E8 and #FFFF00 are hard to distinguish from each other, and #E0E0E0,  #F0F000, #FFE000, and #00FFFF are also hard to distinguish from each other. There is very little difference between these and #D0D000. Lastly, #00B000, #FF0000, and #505050 look virtually the same. The most distinct color on the list is so dark I can barely read it on my Kindle. On my desktop, it reads #0000FF.

What I had in mind was switching from the use of colors to using some kind of image or images. I figure if you can put a piece on any space, you could also put a marker on a space. By having different shapes, image markers could remain more distinct on a greyscale screen. The one difficulty is that you might not be able to superimpose a marker on top of a piece. The way I got around this in Game Courier was to mark spaces with a border around a piece or space. This worked by changing the CSS for the piece, and it worked on empty spaces by using a small, resizable, transparent gif as the piece image on empty spaces. Another possibility, which I haven't tried out, would be to give each space a background image instead of a background color and to change this accordingly.

Whatever you use, it would be helpful to include a legend that will tell people what the different colors or markers mean. You may know what they mean, but the average visitor who comes across one of these diagrams will not. For example, I just looked at diagrams for the Rook and the Cannon in Metamachy, and the only difference between them is that one used a lighter shade of grey than the other. If you're turning Betza codes into diagrams, would it also be possible to translate these codes into written descriptions that could appear underneath a diagram?

On my desktop, it reads #0000FF.

That is the brightest pure blue you can get. I guess lowering the saturation could make it lighter. (But the it would be more like the others...) This color is only used for capturing own pieces (and so far I have never had to use that).

Yeah, colors are not ideal on grey-scale devices. Although my e-reader says it has 16 bit color depth, the grey shads 0xFFFFFF and 0xF0F0F0 were absolutely the same. So it is more like it has only 16 shades of grey! Main purpose of this exercise was to at least show where a piece can go at all, and prevent complete masking of it by the board checkering.

The one difficulty is that you might not be able to superimpose a marker on top of a piece.

Indeed, this is exactly what stopped me from doing this so far. before the "interactive diagram" I had "moves at a glance" images, which were just for showing hard-coded moves in a fixed position. I did highlight those with images (of colored dots, which would defeat the current purpose, but of course that ca be trivially changed), and the markers there obliterated the pieces on the square (which I worked around by having the capture marker bring its own black Rook with it).

The way I got around this in Game Courier was to mark spaces with a border around a piece or space. This worked by changing the CSS for the piece, and it worked on empty spaces by using a small, resizable, transparent gif as the piece image on empty spaces. Another possibility, which I haven't tried out, would be to give each space a background image instead of a background color and to change this accordingly.

I only became aware recently that you can have background images. This solution seems technically the best. There could for instance be various patterns of dotting or (cross)hatching. Note that the color system is rather 'luxurious'; because so many colors were available I made distinctions that were not strictly necessary. E.g. empty squares and occupied squares could use the same markers in other meaning; it would not be too illogical to give locust capture and slider non-captures the same markings, as both are moves after which the piece can continue. Also distinguishing capture of own or enemy pieces need not be distinguished: you can see which color piece you will capture.

Another problem is that images of some pieces could be large, not leaving much free space in the square to recognize a background shape. Perhaps it should be done the other way around, using the piece images as background!? Then the highlights would cover the pieces, and could all be small circles / squares / triagles / stars with transparency around them. That sounds exactly like what is needed.

Disadvantage is that piece graphics of different sizes might need different sets of marker images. Although I suppose that when we center the marker images, the can be suitable for a range of sizes. I mostly use 50x50 for large diagrams (Alfaerie or XBoard50), and 33x33 for smaller ones (Utrecht or XBoard33). But currently the diagram can be used for any size, and it would be a pity to lose that property.

Whatever you use, it would be helpful to include a legend that will tell people what the different colors or markers mean.

Well, on grey scales this is just beyond what color highlightig can do, even with a legend. But with shaped markers that is of course different. My feelings about legends are a bit double. For the experienced user their presence can easily turn into an annoyance. They can be made collapsable, but they should not be hidden too well, or novice users would never fid them. Further more, opening them should not push other valuable stuff out of view, or make the elements the user is acting on jump to other places.

Do you have a suggestion where best to position such a legend relative to the diagram?

If you're turning Betza codes into diagrams, would it also be possible to translate these codes into written descriptions that could appear underneath a diagram?

Interesting idea. For the trivial cases, like BN, this would of course be easy ("Moves as Bishop or Knight"). For the Chu-Shogi Lion it would be a challenge, and what it produces might not be very good. (KNADcaKmcabK: "Moves and captures like King, Knight, Alfil or Dabbaba, or captures as King and then again as King in any direction, or passes a turn"). It also depends on how you far you wat to go explaining things. Is "Moves as Alfil or Dababba" acceptable, or must it say "Makes a (0,2) or a (2,2) jump in every direction"?

P.S.: the submission form just tried to trash this comment, by complaining that I must be signed in after I pressed submit buttom in the preview screen. Fortunately I had guarded against that this time, but this is very, very bad! Especially since it tends to happen after you worked on a comment for a very long time...

P.S.: the submission form just tried to trash this comment, by complaining that I must be signed in after I pressed submit buttom in the preview screen. Fortunately I had guarded against that this time, but this is very, very bad! Especially since it tends to happen after you worked on a comment for a very long time...

This happened to me earlier today. Let's see if I can catch it. I will logout in another tab while writing this.

That worked after I fixed the addcomment.php script.

Didn't the leap color used to be more orange? Now it is almost impossible to distuingish from a slide.

OK, I made some progress. The pieces of the diagram are now displayed as background image, rather than as cell content. Highlighting can now be done through background color, or an image as cell content. For the board checkering, holes in the board, and from-square/to-square highlights it will always use color. But for the move-target highlights I now made marker images with the names of the color that otherwise is used for highlighting this type of move, like "markerFFC000.png". These will then be displayed on top of the piece images.

A few issues remain:

1) The marker images are now taken from the same directory as the piece graphics. This obviously makes it necessary to put copies of them with each piece set, which is annoying. But has the advantage they can be tailored to the piece set, e.g. to the match the size well. I guess the script could be made smart enough to take them from dedicated directories, switching between them depending on the defined square size.

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

3) On a color display I like highlighting with background colors better. (I think it is more visible. But perhaps this is because I am now used to this.) With grey scales the colors are a disaster, though. So I am probably going to force marker highlighting automatically on displays with a colorDepth <= 16. For other displays it is now subject to a new diagram parameter useMarkers=1. I set this parameter for now in the two most-recently posted diagrama, the comments to the "Betza notation" and "Wildebeest Chess" articles, so people can judge them. For now useMarkers=1 can only be used with the xboard33 piece set (graphicsDir=/membergraphics/MSelven-chess/), as this is the only place where I uploaded marker images so far.

Please let me know if the new rendering method gives any problems on other browsers, and what you think of the current set of markers on color or grey-scale displays.

I was just checking out the XBetza Sandbox on my Kindle. Some of the markers seem faint, and in comparison with my desktop monitor, the checker includes some yellow circles that do not even show up on my Kindle. Although using different colors for the markers might work well on a color display, it would be best to make them all black on a greyscale display.

Also, the betza2 does not display any moves on my monitor or on my Kindle.

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

You could also use the single background property for multiple values, such as background color, background image, background repeat, and background position.

OK, the marker images were just a flat color, which was a bad idea. I have now given them all a black outline, and have tried to make the inner colors brighter by mixing in some white for the darker colors red and blue. This should now be recognizable against any background.

As to the betza2 moves: the problem is that this piece is defined as a Grasshopper. So it has no moves on an empty board! Which is what the diagram shows, moves of the piece on an empty board. This is very nice for ordinary leapers and sliders, because you see their complete move potential, without anything being blocked. But for hoppers, which acquire moves only because of obstacles, it is not very satisfactory. That also holds for locust capture, which is not possible without a victim being present, but there (like with ordinary captures) the ShowMoves routine at least shows the location where a victim would have to be. But you still cannot see where the piece would end up if it makes such a locust capture.

I don't have any good ideas for how to solve these problems. For sliding hoppers, rather than making the board empty, the ShowMoves function could dump some platforms in their path. But then you would never know if the hopper could have moved beyond those if they had been absent. You can of course hope that if the platform is located far enough from the piece, the suggestion that it is an infinite-range sliding hop is correct. But in the case of a Dababba that mandatorily jumps (jD), you would have to place an obstacle next to it to enable the move, and you would not be able to see or even suggest that there could also be a on-capture to that adjacent square. For locust capture, a piece could have multiple possible targets (a Checker has two), and statically indicating where the piece ends up after such a capture would not reveal which final destination belongs to which capture target. (Think of the Chu-Shogi Lion, or Ultima pieces.)

How about the following?: When displaying the move diagram of a piece on an empty board, the mouse cursor becomes a 'virtual opponent piece'. If the user hovers it over the board, the diagram would be recalculated as if there was an enemy piece on the square he is hovering over. In particular, if he hovers over a square marked as locust victim, it will show where the piece can land after taking that victim. And if the square is in the path of a hopper, it will show the moves of the hopper with a platform there. (Where capture-only destinations are indicated in red even though the board is currently empty, as it now does for divergent normal pieces.)

When pieces get too complex, i.e. their moves depend on too many conditions in other squares, it is just ot possible to illustrate it in a static diagram. This is the whole idea of providing a diagram where people can move around pieces, rather than just responding to clicking on a piece name. They can then set up situations they wonder about, e.g. for the locust capture, to see what happens if they make it. But it is true that the move diagrams makes the user aware of locust captures, while potential hops remain completely 'silent'. Perhaps there should be a marker symbol (like an inverted white triangle) in the move diagrams to indicate squares where the piece could hop over something. The Grasshopper then would show up as a Queen. Not sure how I should do it for the Pao, which has both real non-captures and potential hops for capturing on the same squares...

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

That seems to do the trick! Thanks! This is really starting to look good now.

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

However, something different would have to be done for a grasshopper, which could not move any distance past the screen. Perhaps a move that could be continued further could be represented by an arrow in the direction of the move, and a move that cannot be continued could be represented with an octagon, the shape of a stop sign.

I have implemeted the idea now to show potential hops in the move diagram as a separate symbol. (Currently I use the same marker as on the board is used for King moves that step into check. Which is also a case of "possible under other circumstances".) It doesn't really produce the desired effect; on the Grasshopper it is OK, but the betza1 piece was defined as an enhanced Pao, mRpcR. And because the move-only access to a square is defined by a different Betza atom as the hop possibility, the latter overwrites the former. So the information that non-captures to these squares are valid moves is lost...

This is a manifestation of a more general problem: what if the same square can be reached for different purposes? Currently only the last generated highlight survives, and I leave it to the user to decide what this should be (by writing the order of the various moves). By writing the Pao as pcRmR the potential-hop marker would be overwritten by the move-only marker. So far that didn't cause any problems in practical cases. E.g. a Rook that also jumps to the second square should be written as RD, and not as DR, so that the D jump overwrites the sliding move, and remains visible. You don't have to know that you could go to the same square through a blockable move if you can get there with a leap, after all. If you had a RmD it would be problematic, though. The capture to the second square is now blockable, the non-capture is not. There is no symbol for that combination of moves. For overlapping riders it is even more hopeless: suppose you had a Rook-Dababbarider RDD. It would show up the same as a Rook, which suggests that distant moves can be blocked on squares closer to the piece. That is true for access to the odd squares, but access to the 4th square (say) is not blocked by an obstacle on the 1st or 3rd square (because the DD leaps over those), but it would be blocked by an obstacle on the 2nd square. Having separate symbols for such weird situation is not productive, I think.

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

I am afraid this will get too complex to still transfer information. In general you cannot fully desribe every potential situation in a static picture. Suppose you had a piece like Mats' bifurcators, which change direction after (or before) colliding with a screen. There the number of squares you could reach if there was a screen in an undetermined position fills an entire sector of the plane, and it would be completely obscure what position a screen would need to be at to reach a particular potential target.

So I think the purpose of the markers should merely be to warn the user that something tricky is going on which would alter the picture in an unexpected way if the square was occupied. (The expected way being that it blocks the ray, and all symbols identical to it 'downstream' would just disappear.) Not to encode in detail what it is that would change. That the user can discover interactively, by indeed putting something on the marked square. He can already do that in the setup diagram, by moving pieces into a similar constellation, but a simplified possibility could even be added in the move diagram through the 'hover trick'.

That being said, it still seems bad to have a move diagram of a Pao only show non-captures without a hint of hopping, or only show hop locations without a hint it could simply move there. (A similar situation occurs in Quan Trung Chess, where there is a "grasshopping Rook locust"). So perhaps the potential to hop should not be indicated by a marker, but by a grey background color, so that it can combine with any marker, rather than erasing it. The move diagram is not checkered, so it would be the only deviating background color, so no problem on a grey-scale device. And when background color is the main method of highlighting, it could draw the grey cross marker in the hop squares.

I have now implemented the 'hover method': when you are displaying a move diagram it will show the piece on an empty board. But if you hover the mouse pointer over a marked square it puts an enemy pawn there, and shows the moves in the presence of this Pawn. This can in particular be used to elucidate hop targets (grey background), to see what kind of moves the screen enables, and locust capture squares (cyan star), to show where you have to move to make the indicated capture.

On touch-screen devices, where you cannot hover, a touch when a move diagram is being displayed will count as hovering the square, and materialize a Pawn there. Switching back to the setup diagram

[Edit]

I now implemented a method to reduce 'collisions' between moves of different type to the same square in move diagrams. For normal moves and captures the highlighting system itself already takes care of this, by defining different colors/symbols for move-or-capture, move-only, and capture-only, and also showing the latter in empty squares. But for hopping moves and locust captures there was a problem, as these moves are never really possible on an empty board, but only indicate potential moves. These potetial moves can coincide with real moves on the empty board. The potetial moves therfore now use the opposite highlighting system as the others. When normal moves are indicated by symbols, the move diagram will use background color to indicate potential hops, and both a symbol and a color to indicate locust capture. In the latter case, the symbol will only be drawn if it does not collide with another symbol, irrespective of the order in which the correspoding moves are defined in the Betza move string. This way a normal move will never be hidden by a hop or locust capture, while it will always remain visible that there is a potetial hop or locust capture over the square as well. When color is used as principal highlighting method, the potential moves will be indicated by drawing a question mark in the square.

E.g. for a Checker the locust victims coincide with normal non-captures, and in the move diagram this will be indicated by the move-only symbol, plus a background color. The user is thus warned that other move potetial is present when this square would be occupied, and can then hover over the square to 'realize' this potetial, by materializing a Pawn there, and calculating the actual move through the square for this case. If it was a locust capture, the victim would now be marked with the locust-capture symbol, and the destination square would be highlighted as a normal move. For a hop, only the destination square would be marked.

These diagrams are a wonderful thing. They can easily describe various moves that Game Courier can't handle without using complicated code. However, I have a few suggestions that, in my opinion, would make the diagram even better.

• Tame pieces - The modifier t on a final (or only) leg of a move means that move cannot capture royal pieces in XBoard. In other words, it is the opposite of the modifier k on a final (or only) leg of a move, which means that move can only be used to capture royal pieces. This modifier should be relatively easy to implement.
• Custom definition of royal pieces - Currently, the only piece that is specified as royal by the diagram is the last piece on the diagram. Some variants may have more than one kind of royal piece (i.e. Chu Shogi), which makes this a useful extension, especially if the royal pieces must stay out of check.
• Triple Captures - This is without a doubtthe hardest extension to implement. Adding this would, in theory, require adding a lot more code to handle the second locust capture. However, this extension would be necessary for the Lion Dog, which can capture three pieces in a straight line, and other pieces that can capture three pieces at once. There might be a way to do this with the WierdChain function. However, that function hasn't been used in your diagrams other than in the Paco Shako diagram.

Wow, you really dived deep into this. Thanks for the feedback. The 't' in XBoard was a kludge to allow approximate representation of moves that were too difficult to handle correctly, by making it possible to 'round up' the move to something that was doable, in the sense that it would include every pseudo-legal move and then some. That way the GUI would not block the entry of any legal move because it though it was not in the piece's repertoire. And then leave it to the engine to refuse the 'and some', should the user try to play it. (XBoard protocol allows engines to do such a thing.) But this strategy fails when XBoard would think one of the 'phantom' moves was checking the King. Enforcing the checking rule makes it that you have to be exactly right in your moves: if some moves are not supported, you cannot play those, but if extra moves are supported, you sometimes cannot move other pieces because it is imagined this would leave you in check. The 't' modifier was added to make it possible to selectively disable checking by all extra moves, so the latter problem cannot occur.

But the diagram does not test for full move legality; its purpose was to demonstrate how pieces move, and not showing some of the pseudo-legal moves because of checking restrictions only caused confusion. (I later added greying out King moves that directly stumble in check, to get a good representation of slider Kings that cannot pass through check, without obscuring what the pseudo-legal moves of the King really are, to do 'Caissa Brittanica'.) So the diagram does not really need the 't', as it accepts any move anyway, and the harm in highlighting spurious moves would not go away by it. And I did not know any variant that really had pieces that could not capture royals with one of their normal capture moves. So I figured the 't' was not needed.

In case of an 'emergency', there is a work-around, BTW: the diagram script looks for the presence of a user-supplied function

BadZone(x, y, piece, color)

which allows you to veto moves that the Betza encoding would allow. I used this to confine the pieces to their zones in Xiangqi, but it could also be used to veto a move because the indicated piece type cannot capture what is at square (x,y). Or to implement variants with restrictions on what can capture what, of which the 'tame' moves are just a special case. And this does affect the highlighting! (The 'k' I added to make it possible to implement the King-facing rule of Xiangqi, which was borrowed by some western chess variants as well.)

Triple moves are indeed a pain. XBoard supports those now. It would require a lot of messy code. I don't think that 'chaining' like in Paco Shako would be the simplest way to do it. It is definitely also on my wish list.

Custom definition of royal pieces is already possible, though the parameter royal=N . In the most recent version this is even implemented as setting a flag for piece type number N, rather than remembering the value of the parameter. So you can have several such lines in the diagram definition, indicating multiple royals. But since the diagram doesn't take account of the checking rule, there is not much effect of defining something as 'royal'. Only its own moves are then sometimes greyed out. And games like Chu Shogi, which do have multiple royals when you insist on representing Prince differently from King (as kanji pieces would), doesn't really have a checking rule, so that in fact the royals should not lose any moves even when they do stumble into check. The diagram doesn't test for game end.

The BadZone function is indeed very useful. For example, if you wanted forbidden moves of royal pieces into check (which are highlighted dark gray) to not show up at all, all you need to do is use this function in your script, which works with both moves that move directly into check and castling moves that land on or pass through check:

function BadZone() { return blockFlag; }

However, this function isn't elaborated on very well. It has four parameters - x, y, piece, and color. The parameters x and y can be used to track the destination square of a piece (i.e. typ = board[y][x]) but piece and color are shrouded in mystery.

You said that you used this function to "confine pieces to their zones in Xiangqi," which is very interesting and could be very useful, as I am reasonably certain that you all four parameters there, though I could be wrong. Perhaps you can show me the function that you wrote to do this?

The diagram is in the comments to the Xiangqi article: https://www.chessvariants.com/index/listcomments.php?id=33312 . From its page source:

        function BadZone(x, y, piece, color) { // enforce board zones
          if(touched) return 0; // not during ShowMoves()
          if(piece == 4) return (color ? y < 5 : y > 4); // Elephant: across river
          if(piece != 3 && piece != 8) return 0; // otherwise OK if not Advisor or King
          return x < 3 || x > 5 || (color ? y < 7 : y > 2) && (board[y][x] & 511) != 8;
        }
        function Shade(x, y) {
          var col = 0;
          if(y > 4) col = !col;
          if(x > 2 && x < 6 && (y < 3 || y > 6)) col= !col;
          return col;
        }

The argument 'piece' contains the type of the moved piece, and 'color' indicates its color (non-zero = 1024 = black). The routine is called for a proposed move, so board[y][x] at this point is still the victim. I suppose the exception made for allowing a King to leave his Palace to capture the other King is not really necessary when its move is defined as WfkR; King and Advisors could simply be allowed in either Palace, as they have no moves that would bring them to the opponent Palace other than the one that must capture a King.

Interestingly, the diagram doesn't grey out the squares that would result in moving into check when the royal piece is a Universal Leaper (XBetza notation: U), like the Emperor in Maka dai dai Shogi.

Could be that I did that intentionally. The universal leaper moves are generated by a piece of code that is completely different from the code that generates other moves. (As they are not relative to the start square.) And this code doesn't test for the target squares being attacked. In the Maka Dai Dai Shogi diagram the Emperor was the only royal piece, (as it was the last piece mentioned), but I did not want any royal piece, (as there is no rule against putting yourself in check there), and the fact that it is a universal leaper now hides this. But later I added commands to the diagram to set the royal piece by hand, and allow multiple or none. So this kludge is no longer needed.

I also noticed another thing about the diagram that I thought was very weird. When the diagram has at least 73 different pieces it starts combining the IDs of the first 6 pieces and replacing the actual ID of the piece with those. Specifically, it does this for the first group of 6, and then it skips two pieces. This process repeats until all 6 IDs have been used (So if the first 6 IDs are 1, 2, 3, 4, 5, and 6, the overwritten IDs would be 11, 12, 13, 14, 15, 16, 21, 22, 23, and so on all the way to 66). For example, the diagram in you page on Maka Dai Dai Shogi replaces the IDs of the Furious Fiend (+Ln), Buddhist Spirit (+DS), Teaching King (+Dv), Crown Prince (+DE), and Emperor (+K) with PP, PGB, PE, PSt, and PT, respectively. This is probably due to a bug in the source code, as I can't see any reason to think that it was intentional. However, this is only a guess. Do you have any suggestions as to what might be causing this?

Interestingly, I answered my own question. When looking at the source code, I found this line of code that was responsible for the pieces IDs being overwritten:

for(i=1; i<7; i++) for(j=1; j<7; j++) ids[64+8*i+j] = ids[i] + ids[j]; // combis

When I removed it from the source code, the problem disappeared. Honestly though, I have no idea why this line of code was in there. Logically speaking, wouldn't you want every piece to have the correct ID on it, instead of having the IDs of some pieces overwritten with something else?

Oops... It seems there has been a mixup of versions at some point. This code was added as a hack to do Peace Chess, where pieces can combine to 'embracing pairs' coexisting on the same square. The IDs for these combinations are generated here automatically. Piece Chess of course only has 6 basic piece types, so for that purpose having the pair codes start at 64 located them well beyond 'nType', with a large safety margin. But I should never have used that hacked version for replacing the script that powers the diagram in general, at least not without modification. There is no reason why the 64 could not be replaced by (say) 400, to not wreck any variants with fewer than 400 piece types. (Without this hack the limit was 512 piece types; the 512 bit is used to indicate piece virginity, the 1024 bit for piece color.)

Thanks for spotting this; I will fix it soon.

I wonder if there is a way to make a piece capture everything in its path? For example, in Taikyoku Shogi there are range-capturing pieces that destroy everything in their path (including friendly pieces). In Betza 2.0 this behavior could be indicated using cd0. Perhaps the WeirdChain function holds the answer?

Currently the diagram is limited to a single locust capture. Which already makes the Lion Dog of the large Shogi variants fall beyond its capabilities. If this were solved (e.g. by allowing an array of locust-victim coordinates), the XBetza notation could specify each number of victims separately, e.g. RcdafRcdafcdafR ... Which for a big board like Taikyoku's 36x36 becomes of course very cumbersome.

Perhaps there would be some benefit of extending XBetza notation with a 'repeat count' on a group of modifiers. This would then replace the 'a' modifier. A leading '0' on the number could indicate 'exactly that many', where otherwise it would mean up to that number. So cd02fR would then mean cdafcdafR. Where the expansion rule is that the repeat count would group with preceding modality modifiers, and following directional modifiers. (So that you could still slam an initial directional modifier on the first leg, and a different modality modifier on the last one. That would allow description of the Tenjiku jumping generals as multi-hoppers: Rp14cR or Rp0cR.)

About your idea of including piece descriptions in the piece table:

Overall, including piece descriptions in the piece table is a good idea that I think should be implemented. Here are my thoughts on it:

First and foremost, including piece descriptions for a piece in this way should be optional, so you don't have to do it for every single piece in the table, which would be quite tedious, especially for larger games like Hook Shogi and Taishin Shogi. Of course, you can put in default descriptions for predefined pieces, but the programmer should also have the ability to override these. For null descriptions you could simply replace the empty string with a hyphen.

Regarding implementation, I recommend putting all the piece descriptions in an array so you can use JavaScript variables to hold piece descriptions if need be. And when setting piece descriptions in the diagram script, I would suggest putting the descriptions after everything else in the colon-separated list, like so:

name:id:move:image:startingHand:description

This way already existing diagrams won't get screwed up by this new implementation.

If you do implement this, make sure to update this page to include information about it.

Intelligent Diagrams!

I now equipped the diagram with a simple generic AI, so that you can play against it as a demo. It is not very strong; just a simple alpha-beta searcher with a recapture extension instead of an all-capture Quiescence Search, set for a depth of 2 ply. Somewhat like micro-Max 1.6. Except that it doesn't even have good piece values; it guesses these by itself.

Any Interactive Diagram should now automatically have the clickable phrase 'Play it!' on the line below the diagram that also served to open the piece overview. If this is clicked, the AI is switched on, and a button bar will appear. Any move played in the diagram will then automatically be replied to with a move of the opposite color. The diagram will continue to do this until you hide the button bar by clicking the 'Play It!' again. The diagram will collect all moves (both yours and those of the AI) into a game, and the button bar will allow you to navigate through that game.

Great work HG!

I am not sure what you mean by 'shuffling'. Something like in Chess960? The diagram just sets up the position that you specify. It would be hard for a general diagram to know what kind of shuffling is acceptable. (E.g. must the King stay between the Rooks? What if there even aren't Kings or Rooks? Or when there are multiple ranks of pieces? Or brouhaha squares?) And what should trigger the shuffling? Refreshing the pase, to re-initialize the diagram? Should there be a button for it, and if so, where?

It might be better to just start with the squares that contain shuffled pieces empty, and put all pieces in the 'hand' in the initial position. People can then first set up the shuffle the want by dropping the pieces, and start playing from there.

Of course it would also be possible to just embed a small JavaScript routine in the HTML page that does the shuffling in the way you want it.

BTW, I added a hidden feature to the Diagram. (This was really only for debugging purposed, and I am not sure I am wise to mention it. For people might take it serious, but they will probably discover it anyway.) When you click the 'move' header in the piece table, the column toggles to display the piece values estimated by the AI instead of the moves in Betza notation. Don't believe them; it makes exactly the same errors as most people do when guessing piece values!

By shuffling i meant like in 960 indeed. I remember you doing the shuffling especially for this game but I then lost it when I lost the device where it was saved. Once I get to the interactive diagram on apothecary chess I will ask this favor of you. Thanks!

You know what? I will add type-differentiated promotions to the Diagram as a standard feature. So you won't have to use any custom-supplied WeirdPromotion() routine for that. This is easy to do: I will allow suffixing any piece ID in the promoChoice string by a number. Which, when present, will be taken to mean the number of ranks (counted from the back) where it can promote. Pieces not suffixed like that will use the value given for promotionZone instead. So by writing in the Diagram definition

holdingsType=1
promoZone=3
promoChoice=!P*N*B*R2*Q1

the pieces N, B, R and Q must be in the hand (where they get by being captured) to allow promotion to them, due to the asterisk. (The P has no asterisk, because it is not really a promotion, so nothing has to be available. It is just forbidden on the last rank because of the !.) But even when the piece is available, Q would only be allowed on the last rank, and R on the last 2 ranks. B and N can be chosen on rank 1-3, P only on 2 and 3.

[Edit] I have uploaded a version of the Diagram script that implements this now. A beneficial side effect is that it now does the correct highlighting in the piece table for the pieces that can be chosen. With WeirdPromotion you could reject some choices after they were made, but it did not have any effect on the prior highlighting. It can be tested in the Gross Chess diagram.

Great to hear this!

I now also added shuffling to the standard diagram script. You just have to specify a parameter shuffle=... with a string of piece IDs, mentioning all the piece types you want shuffled. If you prefix one of the IDs with ! it will make sure the pieces of that type are equally distributed over the square shades. If there is a piece that has castling as one of its moves, and the pieces in the corners of the specified position are of the same type, it will make sure the castling piece ends up between the other two. (Better only use that when all shuffled pieces are on the same rank!) If you specified a symmetry in the diagram (e.g. symmetry=mirror) it will respect that symmetry; otherwise it shuffles black and white independently.

So all you have to do to turn a Diagram for FIDE into Chess960 is specify shuffle=N!BRQK .

Shuffling is triggered by pressing the 'Restart' button in the AI control bar. It then restarts from a new shuffle.

I rigged the Diagram in the Metamachy article to shuffle the Eagle, Lion, Queen and King.

The new AI is pretty impressive. But I must ask you something. As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?

As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?

Do you have any suggestion for how that could be implemented? I guess that what makes it difficult is that the move-entry system makes non-destructive intermediate squares transparent, so that a back-and-forth move to an empty square only leaves a marker on the selected piece. And clicking that again deselects it. I guess I could change the priorities there, so that clicking a piece that has marked itself as target will result in a null move, rather than a deselect. It should always be possible to deselect it by clicking another piece. (And if you have no other piece, there is no reason to deselect it in the first place.) Currently it only does that if a locust victim has been specified.

But is this really important? I always though that null moves are merely a hypothetical possibility, and that in practice it would almost always be very bad to play them. The pieces that can do null moves in Shogi are so powerful that you are not very likely to get into zigzwang if you have them.