Ratings & Comments

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.

An army with your pieces. What'd you call this army? Greenwade Gravels?

By the way, Chinoise Rose in problemist language is called Rao.

I gave it a try here. I think It looks better this way.
@Adam: apart from the adjustments linked to the changes, what do you think?

I still have Astra (Rosetta) on your queue, but also I’ve recently created Astromech (even squares diagonally or odd ones orthogonally, AA[W?DD]). Try to guess who is Astromech)

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.

The issues that the Tinkercad website is having recently may lead me to take a break after this weekend. Since the problem mainly affects new uploads, I may continue for a short while, but otherwise I'll just wait for the problem to be fixed.

I had already planned on only going to #366 (I'm running out of possible pieces to post), posting only occasionally afterward for extensions of sets, missed rotary counterparts, special requests, new discoveries, and so forth. I also had planned, if I hadn't done this already by then, to take the time to create an index of sorts that I could post as an article.

It's good to know that you can use the bottom squares for that. Does it mean that we have to specify something like Model.Game.handLayout[1][{2:18,4:17}]; // eg : square 2, hand 18 for the white for each piecetype?

Thanks for the catch. I only just recently realized my error there. I'll go fix that, both here and in my games where it appears, today and tomorrow.

Note that it is possible to control the way the captured pieces are placed next to the board by defining arrays Model.Game.handLayout[color][handIndex]. This array should contain the square numbers where you want the first captured piece of the given color (1 or -1) and hand value to be placed. (A second piece will be placed at sqr+color, and after that counters will appear between the two shown pieces.)

Currently the default assignment is used, which places the white pieces on the first 'file' on the right of the board, the hand number equal to the rank number (which starts at 0). By defining a handLayout you could also use the ranks under or above the board to place pieces, thus requiring fewer extra ranks.

E.g. with a single extra rank (instead of the 4 you have now) you could place 6 white pieces below the board, and 14 white pieces to the right of the board.

Powerchess V.3 (also with random)

Thanks.

Can you also do the same for normal Seireigi? It has the same problem with its 3d Kanji pieces.

Talking about background it doesn't seem to work on my device even though it used to work. Interactive Diagrams that use backgrounds like Eurasian Chess, Chak, VaoQi don't seem to have backgrounds on my device.

Demiurge Turtle is mScK4 since it's based on Mock Turtle from Jupiter.

Done!

This is an excellent concept. There's just one tweak I'd like to see. Pawns on the a-file cannot move any further to the left, so that could be a problem. One way to remedy that might be to divide the board vertically down the middle, giving pawns on files A-D a move to the RIGHT, and on files E-H to the LEFT, as you have currently done for all pawns.

280. Yak. No, this isn't another Tifinagh piece*; this is named for the animal.

It simply occurred to me recently that particularly large boards could use a piece that's the equivalent of a Buffalo (NCZ), extending one space further. I considered naming it for a pouncing predator, but besides most such creatures being already taken, it didn't seem to fit the established pattern. This piece combines the leaps of the Knight (horse), Camel, Zebra, Giraffe, and Antelope, and also includes many compound ungulates (Gnu, Bison, Okapi, Buffalo, and so forth), so an ungulate seemed fitting. After a little bit of research, the animal that stood out was the Yak. (NCZFXNY)

I deliberately excluded the (4,2) leap of the Hare/Stag/Lancer since it's just an extension of the Knight move; pieces that add the DY or N2 can be considered separately. As it is already, it can be a formidable and versatile piece.

*The two forms of the letter yak are ⴽ and (in Tuareg) ⴾ, neither of which (in my opinion) make particularly good chess pieces -- at least, not without some sort of mirror image.

Ishskwaday II by Stuart Spence, AKA Zulban

How about switching Diamonds & Onyxes? or Onyxes with Lame Ducks?

I filled in the board size metadata as 8x8, but perhaps it would be better as 8x15 (still with 64 cells)?

For some reason, the 3d graphics for Seireigi and Chu Seireigi are only showing as blank Shogi pieces, and in the case of certain Chu Seireigi pieces, not showing at all. Any help would be greatly appreciated.

Also, I noticed a bug in the Hectochess file, where, when castling, the Champion starting square is not checked to see if a piece is there or not.