Comments by HGMuller

Strange that it doesn't work for you. When I copy-paste the I.D. definition into the PTA directly from the Page Source (from the line satellite=megalo to the line king::KispO9::k1) I do get a 16x16 board with the Megalomachy setup. It doesn't look very well, because even the specified squareSize of 33x33 is too large to fit it on the PTA page, and the I.D. in the Megalomachy article uses the 50x50 alfaerie pieces. Because it also uses betzaNew.js it automatically shrinks those images to fit the squares, but the PTA still uses betza.js, which doesn't do that, but clips the pieces instead. But that should not affect the generation of GAME code.

I get this error:

Cannot make a diagram with 0 pieces on an 8x8 board!

It probably means that you copy a lot of invisible stuff together with the Diagram definition; the line below the quoted error message makes an attempt to show you what you actually pasted. If I copy-paste directly from your latest comment into the PTA, I also get the error message, and for the pasted text it says:

<main><article id="maincontent"><div class="commentgroup"><div class="Comment"><div><table><tbody><tr><td class="line-content">satellite=megalo</td>...

So there is an enormous amount of HTML garbage prefixed and interleaved with the actual definition, and the PTA chokes on it. What exactly corrupts the Diagram definition might depend on your browser. I made the PTA resistant to the garbage that is added by copying from a FireFox Page Source (but you might have to flush the browser cache to benefit from that?)

Anyway, the safest method is to first paste the Diagram definition into NotePad;this will cleanse it of most invisible stuff. Then you can copy-paste it from there into the PTA.

link?

The correct query for opening the preset in Edit mode is &submit=Edit, not &edit=true.

The problem appears to be the fast castling, and now that I think about it, I believe I never implemented fast castling in the betza.txt GAME-code include file. So the entries in the legdefs table that would be interpreted by the JavaScript powering the Interactive Diagram as fast castling are mistaken for something that makes the GAME code crash.

For now I recommend commenting out the four lines that define the fast castling at the end of legdefs, like:

1  1 -1  1     3
//2 99  1  0    88
//   1  9  0    25
//2 99 -1  0    88
//   1 -9  0    25
0);

The King will then not be able to castle, but at least you can continue implementing the other aspects of the variant in the preset. In the mean time I will try to support fast castling in betza.txt. And when I have done that, you can uncomment the lines again.

Where can your work on Jocly with François, HG, can be found?

That depends on what exactly you want. The source code is in my on-line git repository, but it is currently not possible to view that interactively on line because the hosting company disabled the viewer for that ('GtitWeb'), and I haven't had time to fix that. It is still possible to pull from the repository with 'git', to view the source code locally. And I suppose François has a mirror of it on GitHub.

If you want to see a running install featuring the newly added games, you can use the one on CVP (just select any of the dedicated variant links on the Jocly overview page, and then click 'other jocly games' at the bottom right to select a game), or the one on my website, which are old Jocly installs that I hacked to add some variants. I suppose that François has put up a version directly compiled from the most recent source code somewhere.

Oh, that seems a lot of work. But I'll do it in the evening!

Not really. You should just select the Completely Custom set, and then paste the set definition the PTA suggests into the preset.

As the matter of fact, why don't you update that page "Play Chess Variants with Jocly" which was listing all available games until last year?

The problem is that it is a matter of taste what 'available game' means. The Jocly applet itself allows you to select any game that is implemented, through the 'other jocly games' link. But this applet is not able to show rule descriptions or credits, which are also available for most of these games in the Jocly source package.

Therefore Fergus created separate HTML pages for individual variants, which embed the Jocly applet preconfigured to run the corresponding variant, with a rule description. The overview page you refer to contains links to those individual game pages.

In general the reason for there being no link to a certain variant in this overview page is that there doesn't exist such a separate HTML page for that game yet. Someone would first have to create those pages.

Edit: Also, Hectochess doesn't have the 3d Queen, Marshall, and Cardinal for some reason...

Indeed, I noticed that too. I did upload a newer fairy-sprites file, and that made the Champion and Wizard appear.

[Edit] OK, that should be fixed now too. Hectochess was using the proper-*.js files for these 3d pieces, which differ from the original ones by a scale factor, to give them a more natural size. But these were not present on CVP.

[Edit2] I now moved a lot of the new 3d pieces to the CVP Jocly install as well. I had never payed much attention to the version here as far as updates go, because the CloudFlare caching made it pracically impossible to see any changes. But now that Fergus has exempted Jocly from this, it makes sense to bring the version here up to date as well. Makromachy already works. For Minjiku Shogi some of the promoted pieces seem to be still missing.

You must also put

set opaque (EA FA BA SM AR ea fa ba sm ar);

there to make the flying pieces block each other.

I beat you by 4 minutes! :-)

It is interesting how we both chose a different rectification of the board; mine spoils the coordinates, yours spoils the moves of the pieces. In your representation it would in principle be possible to use a whole-board image as background that has the original diamond-shaped cells.

I tried using the Atlantic SVG set through fen2.php, but this set is not suitable for use on a black-and-white board. (Alfaerie doesn't do so well either, on the dark squares...)

[Edit] Concerning Pawn: Ah yes, I had overlooked that detail in the description. Thanks!

No, you have to write something like

Model.Game.handLayout[1] = [0,2,4,6,8,10,12,14,30,46,62,...];

if you want the first 8 'hand squares' for white to be at the bottom, and the rest along the right edge.

I guess the drop model still needs some tweeking. The square painting on the hand ranks should be the same as that of the other hand squares. Now there seems to be no coloring at all, so that the rim texture shines through. I suppose the logical way to do this is that the square-painting array that has to be defined in the game's view file should include the extra ranks.

It is also not clear to me why the 'counter piece' in the lower-right corner is larger than the others.

[Edit] The array boardLayout defined in the view file is accessed in two places in grid-board-view.js, inside nested loops over rows and columns. The loop over rows was modified to skip the extra hand ranks. I suppose this was a bad idea; especially in the 'paintCells' function it should have run over all ranks, requiring the boardLayout to also specify how the cells in these extra hand ranks should be colored. There is a second routine 'paintInCoordinates' that also loops over all cells, which does more complex things and might need more subtle modification than just changing the loop limits. But it seems this function is not normally used.

The handLayout[-1] in the view file appears to have a 16 where there should be a 17, which causes misplacement of the 'counter piece' on 15 rather than 16.

I think that all that is needed is to make the 'row' loop run from 0 to NBROWS, and remove the -NBVHND from

this.cbView.boardLayout[NBROWS-NBVHND-row-1][col]

 And then putting the extra hand ranks in the boardLayout defined in the game's view file. I don't think there are any other games yet that use extra hand ranks. I implemented that feature with Wa Shogi in mind.

The paintCells function is not involved in drawing the grid.

I had already looked at the sources, by looking at the chu-seireigi-view.js of the compiled version. Since you build Jocly without uglification all used source files are in there unmodified.

Uncaught TypeError: this.cbView.boardLayout[((NBROWS - row) - 1)] is undefined

This sounds like an out-of-bounds access on boardLayout. Are you sure you defined that array with sufficiently many ranks? To further diagnose the problem you could add console.log(NBROWS-row-1); just before the access to boardLayout in paintCells; then you could see in the console  what the offending value is.

Strange. 13 should be a valid index for an array of length 19. That means the array should have some internal elements that are undefined. What happens if you print

console.log( this.cbView.boardLayout )?

Should I add : Should I add " ##############" before and after?

Indeed, you should, because you want the extra hand ranks to be colored black as well.

The Wikipedia has it that the player with the weakest player has the Jade General, and the strongest player the King. I am not sure if and how we should implement that in Jocly.