Comments by HGMuller
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.
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(
)?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.
We could also ask the more general question of not keeping anything other than chess variants. Something to think about.
Indeed, that occurred to me too. We could easily delete all lines in the jocly-allgames.js file that do not refer to chess variants.
OTOH, the preferred access to the variants on this website appears to be through the Jocly overview page, not through the 'other Jocly games' link that the applet always shows. It is a bit silly when you first have to select a variant you don't want to play, and then switch. And the switch works in the applet, but not for the rule description page we embedded the applet in.
But the overview page also needs refactoring; listing the available variants by date is not helpful at all to the unwary visitor of this website. I am not sure what the best presentation is, though. I suppose alphabetically, even though this competes with what you could do (with some more knowledge and effort) in the site's alphabetical index.
I am also thinking of 'modernizing' the install here. By replacing jocly.game.js the Jocly core is already fully compatible with the recent source code. The only variant in the CVP install that has not been back-ported to source yet is Tenjiku Shogi. Since all game-specific model and view files include a version of the chessbase model and view, there is no harm in different variants needing different versions of these.
So we could replace all model and view files in the chessbase folder by those from the most-recent compile, and the images and supporting info file these use in the chessbase/res sub-tree as well. I think Tenjiku Shogi exclusively uses sprites, mesh files and diffusemaps from the shogi2 subdirectory, which does not exist in the source tree. Only jocly-allgames.js must be made to always have the extra line defining Tenjiku Shogi, compared to the version created by building Jocly from source.
You must not write anything on the row behind the =. Probably /..$= would already do. On encountering the = filling of the matrix skips to the friendly captures/hops, and at the same time copies what you already have defined in the row (so ..$ here) to the corresponding friendly interactions. What you continue after that will start to overwrite the copied friendly interactions.
I suppose I implemented the idea I described earlier in this thread, to give U moves a penalty in the positional range. I don't remember when I did that. (Or in fact that I did it at all.)
BTW: K-side castling is done with the pocketed Knight, instead of the Rook! Better move the pocket squares to 2nd rank.
This would only be possible with significant additional GAME-code programming. For one, you would have to program enforcement of the 'prelude', as the HandleMove routines in the Post-Move sections only handle normal board moves. So the code should first test the move number, and do something else for the first few moves.
Apart from that you would also have to add code after the call to HandleMove, in order to automatically step the piece on board that is gated.
I am not sure it would ever make sense to add code in the Pre-Move section, when you automate through the PTA. Because Game Courier is configured to "not add moves" in that case, you should be in the same state at the start of the Post-Move section as you are in Pre-Move.
I have just read that thismove does not work in premove
All the more reason to not do anything there.
I don't think you get this criticism because you chose an uncommon name. It is mostly because it is such an awful name, which looks very un-English in multiple ways. I don't think you would have gotten many complaints if you had called it a Falaffel.
I have seen the WD being called Wazaba, never Wazbaba.
Is it possible to make an Interactive Diagram use a hexagonal board?
The current standard scripts do not support that. The I.D. represents the board through a HTML table, and in theory it should be possible to create a table with a masonry-like tiling, shifting each subsequent rank by half a cell. This could be done by giving the first cell on each rank colspan 1, 2, 3, 4, ..., and all other cells colspan="2".
I have tried this, though, and it works to some extent. But for reasons that I do not grasp yet it also changes the height of the ranks in a way that I could not control.
Once the pieces are displayed on the hexagonal grid defined by the table, suppressing cell borders and coloring would allow display of a custom hexagonal board image as background.
But some hints to where I put my code and what that code should be are very welcomed.
I think the variable 'mln' gives you the current move number in the Post-Move sections. What you want is special treatment for the first few ('prelude') moves, and then the normal procedure possibly followed by gating when this would be required. So something like:
if == mln 0: ... // do what has to be done for the first prelude turn elsif == mln 2: ... // do what has to be done for the third prelude turn else: gosub HandleMove true; set waiting where #ori 0 -1; // square behind moved piece if not flag #ori and == 1 rank #ori != @ space #waiting: // virgin first-rank piece with something behind it add space #waiting #ori; // gate the piece empty #waiting; endif; endif;
You stil would have to suppress normal moves for the pieces waiting to be gated. I suppose the easiest way to do this define an alternative version of those that looks the same but does not have any moves, and put those on 0th rank. When its turn comes to be gated you then put the version with moves on the board.
It does not. I have made that mistake too and had to correct it. To use
$mln
to get the move number, you need to get$mline[$mln]->movenum
.
This is somewhat important, because the first things that the HandleMove routine does in the betza.txt include after the move is parsed is:
set all == mln $maxmln; // indicates last move
Note there is no $ there, so we might be talking about different things, and this one might be a legacy variable. The purpose here is to determine whether the subsequent move generation needs to generate all pseudo-legal moves, and compare the input move against those for testing its legality. Or whether it can simply assume the move is legal, because it is not the final move of the stored game, and thus must already have passed the legality test on the turn where it was entered. If the latter is the case only the moves with implied side effects are generated, (e.g. e.p. capture or castling), for the purpose of reconstructing the side effect, and apply it to the board together with the entered move.
I cannot image how this would work if mln was not the current move number.
Using grid would probably help you avoid this problem too. With grid, you should be able to make one column or row diagonal, though I have not yet tried using grid with hexagonal boards. My CSS code for hexagonal boards uses absolute positioning, as grid was not yet part of CSS when I wrote the code. Anyway, absolute positioning is another alternative to using tables.
I am not familiar with this technique, but a problem could be that it is not just about positioning the images, but also about translating mouse clicks to cell coordinates. (Which must also work for empty cells, for entering non-captures.) In the table version I have attached event handlers to the cells for this.
I am not aware of any such sources.
I don't think there was any suggestion that the idea is no good, or the implementation was flawed. Just that the presentated explanation of it is very cumbersome.
I agree with Bn Em that it would be much better explained by not presenting this as pieces that change, but just stating that the orthodox pieces get some extra moves on some of the squares. And then show a table that mentions the extra moves for each piece, and on which squares it would get those.
OK, so the betza.txt code, which thus aims to test for whether the move is the one that was just entered, would work fine even in the presence of comments?
And the code to test for whether we are in prelude should look like
if == 0 $mline[$mln]->movenum:
?
rfNX rfCX rfFXX rfNXX ...
Is there a way to enter XBetza on this?
Not on this page. But you could use the configurable applet page that the Piececlopedia links to, and write the Betza move you want in the URL.
I wanted to try out the Blue Gecko (frB4lbW2flFbrFfW) but I can't limit the B move to 4 on this diagram.
I guess I should extend the move-definition aid to 11x11 one of these days. But in case of the Blue Gecko, why bother? The 4th step of the B move will hardly ever be needed. And even when you leave out the frB move altogether, it can already force checkmate. You could also use B3 plus a direct AY leap, which shows that adding the AY leap does not shorten the mate (on 8x8, at least).
It would be an interesting challenge for someone to make an Interactive Diagram for this variant.
It is not the pushing that makes that difficult, but the rule that Pawns have a double-step from the first rank. (That they regain the possibility when returning to 2nd rank can be indicated by making it an ii move.) I suppose it could be done through a morph for the Pawn that forbids access to the enemy half, but then exempt the fmW and fceF moves from that, so that only the fmnD move suffers.
The pushing is not too complex: hop on a piece (d), land on the empty square immediately after (af or yaf), and then step backward for friendly capture with unload (i.e. swap, abud). The bounce rule is implemented (on diagonal moves only) by landing off-board after the hop, returning backward for a second hop, this time hopping off sideways, and swap from there (pyafoabpasabudB).
25 comments displayed
Permalink to the exact comments currently displayed.
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.