Comments/Ratings for a Single Item

I noticed you did not link to the alternative JavaScript mouse-click handler. Was that a conscious decision or just an oversight? It is true the alternative handler doesn't offer very much over the standard one when there are no multi-leg moves in the variant, but you still would have the buttons for local navigation, and it would cure the rank expansion on selecting a piece.

Hmmm... I did not exclude this by choice. The code was generated by your GC code generation tool. What should I add to enable this?

Apart from the GAME code for in the Pre-Game / Post-Move / Post-Game sections, the tool also gives a link that you can put in the HTML rule-description section of the preset:

<script src="/membergraphics/MSgame-code-generation/movepiece.js"></script>

Ah, got it. I didn't copy that because I didn't really understand it ... Since it was in the HTML rule description I ignored it. I have added it now.

That ability to review moves locally is really nice! Will this work if added to other presets that are not based on your generated code?

That ability to review moves locally is really nice! Will this work if added to other presets that are not based on your generated code?

To make this possible you need more than just the move list (which is always on the page), because replacement captures are not reversible. For unprogrammed presets it would be enough to have the starting position, as moves there would always be fully described. If the preset is programmed to automatically execute implied side effects (such as for e.p. capture and castling), the JavaScript would have to mimic that.

The GAME code in the betza.txt include makes use of a feature that Fergus created for this purpose: it can pass an initialized variable to the JavaScript normally embedded in the page. This way it passes the FEN of the initial position plus a comma-separated list of move numbers of e.p. and castling moves. Only when the page defines this variable the JavaScript will create the button bar.

I suppose this could have been designed a bit smarter. Now that I think about it, there isn't really any need to have the GAME code specify the initial position (unless it alters it, like in a shuffle game): the variable that now passes this could also have been initialized in preset-specific JavaScript embedded in the 'rules' section. E.g. <script>var startFEN="....";</script>, generated by the tool together with the link to the common script. That could then be added to any non-programmed preset. Of course the Game Courier standard system could be made to always emit the start FEN of the initial position (taken before it executes the Pre-Move code for the first move).

For a programmed preset it is in general not possible to do this navigation based on the move list, as there is no knowing how the GAME code would have interpreted those move texts. You would either have to embed a list of all game positions in the page, or try to save some space on that by mentioning only the differences between subsequent positions. This could even be done in a reversible way (so that you don't need the start position, but the current one will do): each move could be encoded as a comma-separated list of piece ID + square coordinate, which, depending on the occupant of the mentioned square, would either place or remove the mentioned piece. Differnet turns could be separated by semicolons. Normal non-captures would then require 8 characters, e.g. Pe2,Pe4; , and captures 12, e.g. pd5,Pc4,pc4; . The moves could then be run forward as well as backward, if they firrst mention all deletions, and then all additions.