Comments by HGMuller

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.

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 )?

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.

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.

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.

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.

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.

I suppose that would heve worked, if you did that as first thing in the Post-Move sections. But I have already changed the betza.txt to use different arrays for the capturer and the victim. So now you have to put in Pre-Game:

set protected (T t);
set restricted (EA T ea t);

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.

Apparently the jocly.game.js was still the original one from 2017. The addition of LetsTwist (to make the Mersenne Twister random generator available to the game-specific code) is the only modification I ever made in the Jocly core. I have now replaced that file with the one on my website; this should make it work.

I have made an attempt to support fast castling in the betza.txt GAME-code include file. I could not test it in the context of your preset, though, because there seems to be a mismatch between the labels used in the I.D. that youconverted, and the piece set you use in the preset. So it still crashes because of an unknown piece 'E'. I suppose you would have to use the custom set as the PTA suggests it to make it work.

Anyway, to try the fast castling you should replace the lines

2 99  1  0    88
   1  9  0    25
2 99 -1  0    88
   1 -9  0    25

at the end of the legdefs array by

1 -3  1  0 FastCastle
1 -3 -1  0 FastCastle

This uses the existing mechanism for invoking dedicated routines for generating piece moves. But the routine FastCastle, which is invoked by this, is already supplied in the betza.txt include file.

I still have to adapt the PTA to generate these lines automatically, when encountering a fast castling.

You also have to add a line to /play/jocly/dist/browser/jocly-allgames.js to make Jocly notice the files that you placed in /play/jocly/dist/browser/games/chessbase/ . I think Fergus exempted the Jocly files from CloudFlare caching, so you should see new games immediately after flushing your browser cache. To do that I sometimes have to access the modified .js files (including jocly-allgames.js) directly with the browser.

Unfortunately the wikipedia-fairy-sprites.png file on CVP is not entirely compatible with the one that is now in the source repository.

link?

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.

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.

You must only paste the name=value and piece lines, which normally are between HTML <div> and </div> tags. The script line is not part of the Diagram definition; it specifies to the browser what script to run to create an I.D. on  the page. Something the GAME code would never have to do.

I think it did, at least partly. But it is not obvious, because the I.D. does pseudo-legal highlighting, and the capture restriction on Terrors is a context-dependent rule that results in some pseudo-legal moves to be illegal. If I set up a position where the AI can gain a Queen by trading Terrors (TxT, QxT, BxQ), it does not capture.

The I.D. in the article had configured the rule the obsolete way, though, through a protected=32 parameter. This could not specify the 'asymmetric' version of the rule, which forbids Eagles to capture protected Terrors, but not Terrors to capture protected Eagles. I changed that now by using the captureMatrix for specifying the forbidden cases by marking those with a % sign.

The betza.txt include file currently also doesn't support asymmetric anti-trading; the I.D.'s anti-trading through the protected parameter is implemented there by initializing an array

set protected (...);

which lists the labels of all pieces mentioned in protected parameters. But it then bans all captures of the mentioned pieces by each other (when protected). So if both the Terror and Eagle go in there, T x protected E would also be forbidden. I suppose I could fix this by having the betza.txt include use two attays, 'protected' and 'restricted', and then ban only the captures of a piece mentioned in 'protected' by one mentioned in 'restricted'. When the PTA translates an I.D. that contains protected= parameters to GAME code, it could then define both arrays with the same pieces in them (where it now only defines 'protected' in the Pre-Game code).

More precise definition of what can capture what will have to wait for full implementation of the captureMatrix in the generated GAME code. But in most case (including Megalomachy) such a temporary fix would be sufficient.

[Edit] I now modified the betza.txt include file to support these changes. So in Pre-Game you would have to define an array 'opaque' with the flying pieces and those that can shoot them down, an array 'protected' with the Terror, and an array 'restricted' with Terror and Eagle.

Might it work to use the generated code for most of it and manually define the pieces that wouldn't work?

I suppose this would be an option; the 'Custom Pieces' section of the 'Wizard for GAME-code generation' article described how to add pieces that would need explicit programming. I think the Terror would not be problematic for the automatic conversion; it is the flying pieces that would need separate coding, in particular their jump-capturing moves. I suppose you could define thir moves in the I.D. as QK, RW and BF, and then replace the K, W or F moves by a routine for generating jump-captures in the described way.

But it might be simpler to clone the betza.txt file, and modify the move generator there with some dedicated code for this variant. And then use this modified version instead of the standard betza.txt in the preset. All that would have to be done is to insert some code at the point where it now is decided that an encountered piece can be hopped over by a test whether both pieces belong to the set {bat, eagle, raven, archer, spearman}, and abort the generation of that hopping move when they do.

Since this code would only be invoked when a hopper move hits a potential mount, it would not slow down the move generation very much, and I could even insert that in the standard include file. Then all what would have to be done is defining the pieces that cannot hop over each other in the Pre-Game code, like

set flying (...);

where the ... would be the list of labels of all the pieces (of either color) to which this applies.

Don't count on automatic conversion of the Interactive Diagram to GAME code, though. There are some aspects of this variant that are not supported yet by the betza.txt include file that powers such GAME code. In particular the captureMatrix, which is used to make the flying pieces block each other.

Sorry, I was out of town for a few days, and had no time to figure out the answer on this one.

The presets you compare with were not automated through the PTA, so there is no reason why these should behave the same.

Are you sure the game ends when the King moves out of check? Normally an illegal move should not terminate the game; it should just be refused (in this case with the message you quote), and then through using the browser 'back' button you should be able to retry another move. This is also what happens if you insist moving a piece to a non-highlighted destination.

If this is the case the only thing that isn't working exactly as it should is the highlighting: the King jumps get highlighted even if they are forbidden because of check. But there is no way to exploit this; in the end legality is enforced by refusing the move.

The way the PTA-generated GAME code enforces 'not out of check' rules is by having the potentially forbidden moves generate e.p. rights on the square of origin. Using such a move then would allow the opponent to capture the moved piece (i.e. the King) en passant, making the move illegal.

Unfortunately the 'accelerated check test' used for determining the legality of the moves to highlight (in order to prevent this from becoming excruciatingly slow for large games) doesn't detect this: it generates all opponent moves from the current position to mark squares that are under attack on the board. And then only rejects King moves that go to such an attacked square. And in this case the problem is not that the destination is attacked, but that the origin is attacked.

I suppose I could solve this in the accelerated check test by suppressing the virginity of a King that is in check during the generation of the highlights.

[Edit] I now changed the move generator to suppress initial moves of a piece that should not move out of check, when it is in check during the accelerated check test. Please test if this solves the problem.

It would probably have been clearer if I had used a hyphen or slash instead of an a. But it all started as aaK for the area move of Tenjiku Shogi, and caK for the Chu-Shogi Lion. But the hyphens seem to group the atoms in the wrong way, when you don't also use brackets around the individual moves.

In (not-yet-implemented) bracket notation the Betza Rhino would be [W(?fzK)], shorthand for [W?fzK?fzK?fzK?fzK?fzK?fzK?fzK...], a W leg followed by any number of alternating fl and fr K steps.

You should consider the a as a chaining symbol, separating the modifiers for the legs of a multi-leg move. So in afsafzafzW you see 3 a, which means the move has 4 legs. The modifiers for these legs are none, fs, fz and fz, respectively. So the first leg is a W move in all directions (no modifier). From there it continues forward-left or forward-right (because s = l or r), i.e. a diagonal step in the second leg. Then for the third leg it again deflects 45 degrees, but in the opposit direction as in the second leg, as this is what z means. Etc. So afsafzafzW is a shorthand for aflafraflWafraflafrW, two crooked trajectories that are each other's mirror image.

Haru's notation (afz)W is shorthand for WafzWafzafzWafzafzafzW..., a set of ever longer crooked trajectories. Every additional afz adds a new leg, which deflects in the opposite fl or fr (relative) direction as the previous leg did. (Which is the hallmark of a crooked move; if they would all deflect in the same direction, which you could do with fq, you would get a circular piece.)

The second leg in every sequence should really have been specified as fs, however, to indicate it can deflect in both directions, rather than only in one that is specified relative to the previous one. The first z or q occurring in such a sequence (i.e. before it is clear what 'opposit' or 'the same' direction means for the deflection, because there was no previous deflection) is always interpreted as s. You could see this as a special rule for expanding the parentheses into paths with different lengths.

I did know about Betza's t[FR] proposal for Griffon, but I had never seen this z(FW) notation. XBetza is only upward compatible with the Betza notation for simple ('single leg') moves, and has its own system for combining these to multi-leg moves, which is more general than any of the suggestions that Betza coined in various scattered places.

The z modifier applied to a slider atom is original Betza notation for a crooked version of the piece, and is still supported in XBetza. On a leaper, such as zW, it never had any meaning.

The role of parentheses has completely changed; in XBeza these indicate zero or more repetitions of the enclosed group. So z(FW) would mean zzFWzFWFWzFWFWFW..., which doesn't really mean anything.

Brackets originally were not used in XBetza, but legs of a move were 'chained' by using an a as separator between the modifiers of each leg. This does the job of unambiguously defining very complex moves, but often leads to a very obfuscated description unsuitable for human digestion. A much clearer notation is possible by using brackets (but in a way that somewhat is different from Betza's t[...] construct). The brackets still enclose a sequence of simple Betza moves, which are supposed to be played in that order. But there is no t prefix (which was redundant, because the brackets are never used for any other purpose than chaining the contained moves), and separates the enclosed moves by hyphens (if continuation is mandatory) or question marks (if the move could also end there). This notation is already supported in the Interactive Diagram for simple cases like the Griffon ([F?R]). Supporting it in its full glory is a desire for the future.

The meaning of z in a multi-leg move has also changed; it now means l or r, but the opposit of what the previous leg did. (So that it can be used to specify crooked paths, while q means l or r in the same direction, and can be used to define curved paths.)

afs(afzafq)W(afqafz)W

No, that is not it; there is no step on the main orthogonals. The repeating unit involves three steps, not two (afzafqaz), and the repeat of it would thus only visit one of ever three squares in the path. So that you would need three moves to cover the entire path. And the plain W would have to be mentioned separately:

Wafs(afzafqaz)Wafsafz(afqazafz)Wafsafzafq(azafzafq)W

I suppose a bracket notation for this could be a lot simpler

[W?fF(?fzW?fqF?fzF)]

The option to terminate the move at the question marks allows collapsing the three different 'phases' into one.

Type selectivity is provided by means of the captureMatrix, possibly in combination with the apostrophy in the XBetza to restrict it to a subset of the moves. I haven't encountered any case yet that could not be handled this way.

Wagon promotes to Rhino = W-then-B Spider. Chariot (R4) promotes to Griffon (on CVP still represented by a dragon) = Octopus = F-then-R.

This is as it should be.

That is how I represented the ferz-knight and wazir-knight in Jocly (e.g. in Scirocco): A Knight on a somewhat taller base (so it is not so easily confused with a normal Knight) in the shape of a cross, oriented along the F or W move.

Does Jocly currently support any variant that uses Berolina Pawns at all? The 3d realization was made mostly as a test case for the initial version of the Tube tool (it is a purely cylindrical design). In that sense the committing of it was a bit premature, like for the Flamingo.

The design you have here looks a lot like the Alfaerie design, which is a variation on the Alfaerie normal Pawn. But the Wikipedia set uses an entirely different Pawn design. If we want to add new Pawn types, I think we should use that as basis.

Spartan Chess is an implemented variant that uses a different Pawn type, for the Spartans. These 'Hoplits' are very close to a Berolina Pawn, but not exactly equal, because their initial double push can jump, and isn't subject to e.p. capture. They do have their own 3d image, (a Pawn modified to carry a lance), but also use the normal Pawn image in 2d. If we want to distinguish the Pawns in 2d it seems more urgent to do find a symbol for those. In the WinBoard implementation I use the Lance pictogram for those. We could also do that in Jocly (now that we added the Lance). But it would still not have its own picto-sprite in that case. (But who would want to use a Lance and a Hoplit in the same variant...)

I am not sure we should go for a double-head design in 2d if we did not also do that in 3d. An alternative would be to write a V on their breast, to symbolize their non-capturing move.

And what about the Asian Pawn, for the western skins of the Shogi variants? These now also use the normal Pawn symbol.

If the idea is to represent the move, the logical form in a set where the Amazon is a Staunton Knight with the head of a Staunton Queen mounted on top of it, would be a King's head on a Knight. The cross could be omitted for the non-royal case.

If the idea is to represent an actual centaur, rather than just an arbitrary man-horse chimera, the Staunton style seems to lead to something like this:

That is, omit all upper extremities, and only leave a stylized version of the lowest for support. The one in the middle already breaks Staunton style by abandoning cylindrical symmetry (ellipticity is used in the hind legs and torso, and excentricity in the horse body).

The tail is in fact already dubiously detailed; if the cut in the Bishop's head was deemed enough to represent tusks, the tail should probably be represented by an upward diagonal cut just above the legs...

Of course it would be quite possible to apply further symmetry breaking (rightmost image) to get still further away from Staunton abstraction and closer to realism: the hind legs and torso could be slanted backwards, the horse's body forwards. An indication for the horse's front leges could be added, dangling down like it is prancing.

I think the generally best idea for all situations is "if you cannot do it properly, better not do it at all".

The world will not become a better place by spreading around crappy solutions because these were the best one could think of.

Perhaps representing something that is recognizable as a centaur requires a level of detail that is incompatible with the level of abstraction (no arms, no legs...) of the Staunton design. In that case it would be a mistake to go for a realistic representation. Use something more abstract. Like bowling peg with a horse tail sticking out at 1/3 of the height.

Make sure to flush your browser cache. Otherwise it won't see the new images, because it uses the cached directory listing for seeing what pieces are there.

Well if you have a piece that does have a defined move, you could move any piece you want to get rid of in its path, (through an illegal move to an empty square, which is always accepted), capture it with that, and then move it back. I agree this is more cumbersome, but I don't know how often thise works.

I don't know what variant you are using this for, but when you want Alfaerie pieces, you could also use the Play-Test Applet, which uses these by default. There you can define the correct moves, and if you want whole-board images, you can just take screenshots of it.

There was an error in handling the dots in the alternative filename by the betza.js script, which I thought I had fixed some time ago: it choked on the dot in graphics.dir. Apparently I fixed that wrong, although I thought it did solve the problem we had at the time. Anyway, it should now work correctly. (After flushing the faulty version out of the browser cache).

Yesterday I forgot to push the patch of base-model.js that Scirocco needs to work; for evaluating the promotability it needs the total army strength. Rather than having it calculate that again, I now pass it from the standard chessbase Evaluate function, (which already calculated it, but then only passes the difference of the two armies in evalValues), as the 4th parameter to the dedicated evaluate().

Perhaps everything that Evaluate() puts so much effort in calculating (by looping over all pieces) should be put into a single object, rather than just variables private to Evaluate(), so that the dedicated evaluate() can use that directly by passing it this object. Rather than having to rely on the often useles combinations that are made of the results and passed as evalValues.

BTW, I was a bit shocked how weak the Jocly AI is. I tried a game of Scirocco against the Interactive Diagram, with Jocly on level Medium (~10 sec?), and the I.D. at 2.5 ply (~0.1sec), and even though the I.D. did some trades I considered bad (but were good according to the piece values it guestimated) it massacred Jocly (until it finally lost with a huge advantage by not knowing that repetition is forbidden). It appears that Jocly at this level still overlooks quite elementary tactics, such as the only protector of a piece being traded away so the piece hangs, or by relying on protection from a piece that is soft-pinned.

There is nothing wrong with the preset, but the medusa images in that directory are completely blank. Something must have gone wrong while rendering those at 50x50. I will check it out later tonight.

[Edit] Strange, there must be something wrong with the SVG. When I render it with fen2.php it produces an entirely transparent PNG. The SVG exists, but when I render it directly in the browser it renders it much larger than the other SVG. Nevertheless the medusa 50x50 PNG images were on my own PC, so I must have been able to render them. Perhaps directly from my winboard.nl website.

Anyway, I uploaded these images from my PC to the alfaeriePNG directory now. That should fix the problem. (After flushing the cache; I hope the CloudFlare cache won't play you tricks; I still get the blank image if I don't append ?nocache=true to the URL.)

Link?