Comments/Ratings for a Single Item

Try clearing your browser cache (cached images and files, any browser) assigning KADGHmcavKmpafcavKcafcmpavK (the complete Lion Dog move) to the star piece in the XBetza sandbox, and making the following moves: b2-b4 c2-c4 d2-d4 f2-e3 e12-e4 e4xd4xc4xb4. You should see spurious highlights e3 and e1 (it only works if the first and second squares in a direction are occupied by enemy pieces). If you don't see spurious highlights after this, then it must be something on my end.

Maybe it only takes place when I clear my browser cache.

Edit: I tested this in Edge, and yes, it only works if you clear your browser cache.

This is really weird. I have tried Chrome too now, and also don't see anything strange there. When you try this with an open console (F12), do you get any error messages there while you enter the move?

I tried this in both Edge and Google Chrome, and it seems only the latter has the spurious highlighting. When executing the moves on Chrome with the compact description assigned, I also see a spurious highlight on e1 when entering the third leg of the move.

What I see is this (Fire Fox and Android browser):

• 1st click on e4: d4 and c4 -> blue star (= 2nd leg can follow), b4 = red dot (simple capture e4xb4)
• 2nd click on d4: e4 -> yellow dot (igui), d4 -> red dot (simple capture e4xd4), c4 -> blue star (3rd leg can follow), b4 -> red dot (e4xd4xb4 double capture)
• 3rd click on c4: c4 -> red dot (e4xd4xc4 double capture), b4 -> red dot (e4xd4xc4xb4 triple capture)
• 4th click on b4 -> move accepted, move indicated with greenish background on e4, b4 and reddish background on c4, d4.

This is exactly as it is supposed to be. Do you see anything different? If so, what?

I am sure I am not using the old script. Try doing the same thing in the sandbox that you did last time, but with the following moves instead: b2-b4 c2-c4 d2-d4 e12-e4 e4xd4xc4xb4. You should notice spurious highlights when asked to enter the third leg of the move. Note that the bug only works if both the first and second square in a given direction are occupied by enemy pieces.

Either I cannot reproduce it, or I don't understand what you mean. When I go to the Betza Sandbox, and assign the more compact description of the Lion Dog I gave below to the 'star piece', and play e12-e3 b2-b3 c2-c3 d2-d3 (all illegal, but just to set up a situation), I can then enter e3xd3xc3xb3, and I don't see any spurious highlighting or other irregular behavior. While there are still lot of pieces in range for the KADGH direct captures.

Are you sure you are not running a cached version of the old script?

The triple capture ability for Lion Dogs works perfectly, at least in regards to executing the moves. There seems to be a problem when highlighting destination for the third leg of a triple capture move. The possible destination squares (aside from the one travelled to via the second leg) generate in all directions where there is a piece on one such square in said direction.

Edit: Also, the moving piece isn't deselected if it can't move back to its starting square when the diagram generates the moves for the next leg. There also seems to be a problem with contageous promotions not taking effect if you make a three leg move to an empty square

I finally got to upgrading the Diagram so that it would be able to support (a limited form of) double locust capture. In particular, I considered it a blemish that it was not able to handle the Lion Dog that occurs in the large Shogi variants (which can make up to 3 radial King steps per turn, and thus capture up to 3 pieces in one move). The AI of the Diagram was already capable of supporting any number of locust captures, but up to now it was not possible for the user to enter a capture with more than one locust victim (in addition to the normal victim in the destination square).

This is now fixed, albeit in a clumsy way. The Diagram still does not support locust capture of any pair of pieces, but only those where these victims are on the same ray, on the first and second square. But that is exactly what the Lion Dog needs. (This limitation came about by the fact that it still uses only a single e.p. square, which then implies the second square.)

There was a lot involved in getting this to work. (It needed new code for generating the move notation, parsing such moves when you paste a game, communicating it to and from the AI, and of course for interpreting the clicks made when you enter a move.) I hope that I got everything right. I also made the Diagram smarter in understanding XBetza descriptors that have both destructive and non-destructive action at the square connecting the legs. (These need a different set of clicks to play: non-destructive intermediates, like the corners in a bent-leaper trajectory, never need to be clicked, while locust victims do.)

The Lion Dog can now be represented in XBetza notation as: KADGHcavKmcafcavKpafcafKcafmpafK . This is a bit cumbersome, but I saw no easy way to allow a 2-out-1-in move (using v in the 3rd leg) only when the first square gets captured or already was empty, and forbid it (using f)when it was an occupied square that was hopped over. So 3 types of three-leg moves need to be described. I guess to also describe null move an extra abK would be needed.

[Edit] I guess that the slightly more compact KADGHcavKmpafcavKcafcmpafK would also work. This only needs two descriptions of the 3-leg move. One for the 3-out move that captures the adjacent victim, and in addition optionally the one on the second square. And another that in any case captures two squares away, and then either continues either out or in. Possibly making a normal capture on its destination. The disadvantage of this is that for the 2-out-1-in move the victims are captured in reverse order (furthest first). Which could make a difference in the case of contageon, when both the captured pieces are contageous. (As they could be in Maka Dai Dai Shogi. Although this is of course a 'never happens' situation.)

An influence display like the one in the ShogiVars program would be a really nice feature to add, especially for the really big games.

I love the new behavior for parentheses. For complex pieces (e.g. Suzumu Shogi's new Fire Demon) it can be a real lifesaver.

I made some modificaions to the AI of the Interactive diagram. In particular, I simplified the Quiescence Search. This because it was prone to search explosion in variants with super-powerful pieces (such as hook movers and multi-capturers). The new QS only always searches capture of the last-moved piece when it is worth less than the attacker, or when it is unprotected. Other captures are only searched if there is enough remaining depth; new captures (i.e. those not possible 2 ply earlier) require a depth of 1/2 ply, other captures a full ply. This puts a limit to how long an exchange can continue.

This new QS is weaker then it was (but faster, and in complex situations far faster). To partly compensate that the default search depth is now 2.5 ply instead of 2 ply, and the depth can be adjusted in steps of 0.5 ply (from 2 to 4 ply).

I also slightly improved the positional bonuses for centralization; the bonus for that is now flatter in the horizontal directions, and pieces with a forward orthogonal slide but no distant other forward moves (such as Rooks and Lances) are exempt from the bonus. This avoids the annoying Rb1 after Nc3, then followed by Rc1 after Bd2, and prevents amassing all pieces on the central two files.

The diagram now has an experimental implementation of repetitions of modifier groups through parenthesizing those. The parentheses must be followed by a number to indicate the maximum number of repetitions. The minimum number of repetitions is zero, i.e. the parenthized group is optional. (Refresh browser cache!)

An example is the Cannon in the diagram below: it is defined as (paf)3R. This expands to RpafRpafpafRpafpafpafR, i.e. a move with 1 to 4 sliding legs, all in the same (orthogonal) direction, which all except the final one must end on an occupied square (p). That means it is a multi-hopper, which can hop over up to 3 pieces.

As other examples the diagram defines a Mao-rider and and a Quintessence. The implementation is done through expanding the text string before feeding it to the Betza parser. At most a single pair of parentheses can occur per atom, otherwise the result will be undefined.

I uploaded a new version of the betza.js script (so clear your browser cache!) with two minor fixes:

1) The width of the 'name' column in the piece table is now limited to 120 pixels. This to cure a problem in the Scalable diagram Editor, where due to some ridiculously long names of Alfaerie pieces the table became so wide that the vertical scroll of the table was no longer on screen, on my lapotp. And the page as a whole did not get a horizontal scroll in FireFox to get it in view. (Probably because the table is created by JavaScript after loading.) Which made it pretty much unusable. Now it just breaks long names over multiple lines.

2) It does not consider any of the diagrams on a page initially as the 'active' one. So that the first click on any diagram will activate it, and switch the square colors from the startShade to the darkShade.

I implemented some new parameters with the diagram for controlling its appearence:

• borders=0 can be used to suppress the black lines that separate the board squares. (Not recommended on uncheckered boards!)
• rimColor=#FFFFF can be used to specify a color for the rim around the board that holds the coordinates, where #FFFFFF (= white) is the default, but can be replaced by any valid HTML color spec.
• coordColor=#000000 can be used to specify the text color for the printed board coordinates, where #000000 (= black) is the default, but can be replaced by any valid HTML color spec.

I fixed a bug in the diagram w.r.t. the pasting of games; the SAN parser was not recognizing the ID for the last piece in the list (usually King). I also made he parser somewhat more tolerant towards games that were not produced by the diagram itself, but had a slightly different formatting. In particular, it now no longer insists that move numbers are followed by a space. (Carlos and Kevin had posted a few such games for Sac Chess that wrote the move directly behind the period of the move number.)

I also implemented a new parameter moveList=... for the diagram. If this is set to a game played earlier with a similarly configured diagram, it will act like that game was pasted into it from the start. (Must be a single line of text! Wrapping is OK, but there shouldn't be any explicit newlines in it.) This makes it possible to post diagrams dedicated to viewing a particular game. (A proposal by Fergus.)

I now removed the ability to always castle with a Rook (irrespecive of its location on the board). I originally added that to handle Omega Chess. But after the diagram supported jO this was no longer needed. So I changed the King's move to KisjO2 in the diagram I had posted for Omega Chess. I don't think there were any other diagrams that needed castling with a non-corner pieces, and were relying on this 'Rook exception'.

So you can change the Rook move back to R, now, without the diagram highlighting a spurious castling.

The way it works now is that the diagram locates the castling piece, and then, on the same rank, scans the board to the left and right until it reaches an edge or a hole. Then it scans back from there in the direction of the castling piece to find a non-empty square in the initial position ('farthest reachable piece').  This would be the castling partner for a plain O castling. If it should be the piece one square further inward, one should use jO.

The diagram work well. Thanks HG!

I'll check it soon!

I'll check it.

Are you sure you are using the latest script, and not some version cached by the browser? When I try it in the Play-Test Applet, with a King move KisjO2isO3 on a 10-wide board, with Rooks (with move mRcR) on b1/i1 and Cannons on a1/j1, it does allow me to do the O2 (but not the O3) castling with the Rook.

When using mRcR castling is possible only with the outer piece- the cannon. When using R is possible to castle with both pieces but there are still, in both cases three fields instead of two highlighted. There needs to be highlighted only the 2 squares near the piece to castle with.

It turned out the highlighting / move entry routine of the diagram (unlike the AI) was completely ignoring j prefixes on O atoms. So it was always castling with the outer-most piece of the initial setup. This should be fixed now, so please try it again.

When I had changed the R to mRcR I could only castle with the cannon 2,3,4 spaces (it is supposed to be only 3 or 4).