I just wanted to point out that a variant having both mandatory capture and the checking rule does exist.

Indeed it does.  So this is another use for IllegalUnlessOnly (I'd like to think of a better name for that. IllegalUnlessExclusive maybe?)

For positional evaluation in this game, is everything basically negative?  My frist thought was to make the material values of the pieces negative.  But it's also bad to have one's pieces in the center, so the PSTs are basically negative also.  And maybe everything ... having your rook on an open file is bad.  A knight outpost is bad.  Is "good" pawn structure also bad?  On that, I'm not sure.

And if everything is reversed, maybe just invert the eval after everything? (assuming it's not a mate score, -INFINITY is still -INFINITY).  Just thinking out loud.  And I don't currently have a "hook" in place for adjusting the whole eval after calculation but I could easily add one.  The whole "losing genre" jenre is one I would like to support...

That's perfect! Now that that's done, I can test a double-burning Suzumu Fire Demon.

Also, for some reason the Comments section is excessively narrow when viewed from the interactive diagram page.

Now that triple captures other than those of the Lion Dog are supported by the interactive diagram, I am currently testing a new version of Suzumu Shogi, with burning pieces (Fire Demons and Heavenly Tetrarches) that can burn (or capture without moving as in igui) up to two adjacent pieces at once.

I have never built an engine for such variants, and hardly ever played them myself. But strategy is much more subtle than you might think. From other engines (like Sjeng) I know that piece values are different from Chess, but positive. E.g. a Queen is worth about 6 Pawns. To win you must get a controlling advantage, so that you can force the opponent to take your weak pieces, which otherwise are difficult to get rid of. E.g. when white has all pieces in the FIDE start position, and black only his King and Pawns, white very easily wins.

It’s not ready, it’s list, as notation, and for likers. This notation is used in my games. Symbols above/under pieces are existing when this piece is made later.

No, my Fluidity have many difference from it [Jumping Chess].

It’s not like diffs between Carrera’s and Capablanca’s setups of Archbishop and Chancellor, it’s like diffs between Capablanca’s and Seirawan’s chess.

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.

So it’s notation not for single variant, but for more — for game.

But I don’t know now how to enable letters with symbols or small letters.

No, my Fluidity have many difference from it [Jumping Chess].

It’s not like diffs between Carrera’s and Capablanca’s setups of Archbishop and Chancellor, it’s like diffs between Capablanca’s and Seirawan’s chess.

I understand it is different.  Jumping Chess is a good, playable game.  This one is not.

Daniel Zacharias wrote on 2022-11-16 UTC

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.

Should be fixed now. Turned out e.p. squares were never cleared until another double push was made. Apparently g8-g6 had been the latest double-push, so when a Pawn then captured to g7... Amazing that no one ran into this problem before.

I still had to write a BadZone function for this one, despite my efforts with the captureMatrix parameter. Because the ban on capturing Kings with the capture move for divergent pieces is dependent on the move, not just on the piece type. XBetza can indicate a move can only capture royalty (k modifier), but not that a move can capture anything but royalty. I suppose I could make an XBetza extension for that, by adopting the convention that the combination kc means non-royal capture. This would otherwise be a useless combination, as c already includes capture of royals. So k becomes a kind of toggle modifier, which negates the possibility to capture royalty from what it would have been without its presence.

[Edit] This is achieved now, and the Diagram now is working without any custom scripting.

Thank you for making the diagram so we can test. Unless I'm missing something, it looks like white wins in 3 moves.

One other question: how will the new move generation affect the pieceZone and piecePromotion functions (and other functions that use parameters representing move coordinates)? The new code does not appear to use the old variables that keep track of a move's coordinates. Instead a clicks array is used to store the coordinates for every clicked square in one variable. For obvious reasons, the old parameter list for pieceZone and piecePromotion wouldn't really work all that well.

Also, you should consider adding a section about the user-defined functions so people don't have to read the comments to figure out what they do.

Same here. I tried to get this working in the spring. One of the guys (moderators) even tried to fix it manually for me. It just doesn't work. And it'd be very helpful if it did cause I would get notified when my opponents move.

By the way, I believe I did get the verification emails, they just didn't work.

I guess I forgot to have the callbacks for the Shogi promotion (on the yes/no message) call the new handler for finishing the move.

Should be fixed now.

As to documenting the WeirdPromotion / BadZone scripting stuff. So far I have refrained from doing that, because writing their own JavaScript would be beyond the capability of most prospective users (present company excluded), and dwelling too much on it in the description of the Diagram is more likely to discourage people from using the latter than to help them.

But there are other reasons as well: this part of the Diagram is pretty much experimental and still in development; I already changed the parameters used in the function calls several times, and even the current argument list of WeirdPromotion is not well suited for the new move-entry system, as it only a single e.p. square. I now also regret that WeirdPromotion and BadZone are separate functions. It would have been quite possible to have their tasks shared by a single function, which, when called with the full description of the move, would return whether the move should be rejected, result in game termination, change the piece type in a mandatory way, or offer promotion choice. And in the latter case it would be desirable if it could actually specify what can be chosen. E.g. by returning a string in the format used for promoChoice, overruling the latter.

And I actually consider it an embarassment that such scripting is needed at all. Ideally it should be possible to specify the rules solely through Diagram parameters. The newly introduced parameters morph and captureMatrix make a great step in that direction; these are very powerful features, which could satisfy the requirements for the large majority of Diagrams for which I originally had to write WeirdPromotion aor BadZone functions.

I have implemented k now such that in combination with c it disables capture of royals. (A combination that before was not different from plain c.)

Actually this means that k now can do what the t modifier (for 'tame') does in XBoard. Without using an extra letter!

In the process of testing it I found out there was a horrible e.p. bug in the AI of the Interactive Diagram: it was always considering the destination of any normal moves an e.p. square. But since usually pieces that can e.p.-capture also would have normal capture to the same square, it would not have any effect other than that the capture would be generated twice. With the new move entry routine this would require an extra click on the destination, though, to resolve the 'ambiguity'.

I am surprised that this article was published. The English is rather poor, and I can hardly understand what the rules are. The layout is awful; there is an enormous disparity in the size of the various graphics. The Berolina Pawn is presented like it is a new invention for this game.

It seems the Shielders can push away pieces, but it remains unclear where these pieces then end up. This Diagram assumes you can push one piece, and it goes one square backward.

Diagram parameters would be ideal, but there's one little problem. When rule enforcement require complex decision making (such as in Suzumu Shogi's current version, which forbids burning pieces from burning each other) the diagram parameters would be less than ideal. So there would likely still be a need for such functions even if the parameters eliminate the majority of cases where they would be needed.

I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.

But I suppose it is better to stick to perfecting the new move generation system for now and focus on the functions later in development.

Some words have been corrected

• (e.g. Surrender -> Resignation)

And some pieces have been renamed to make them easier to read

• (e.g. 雲 ⇒ 云)

I'm not sure how you intend to merge move rejection, game termination, mandatory promotion, and offering promotion choice, into a single function, unless JS allows you to return a value that could be one of many different types.

This is exactly what JavaScript allows. It is a 'typeless language', where any variable can hold, or any function can return any type of data structure. Move rejection and game termination go through numeric codes (BadZone does that now, 1 for rejection, 0 for allowed, -1 and -2 for termination), forced promotion or a choice request as well (by WeirdPromotion, returning the piece-type number or 1000). It would be easy enough to rearrange the numeric codes such that they do not collide. It is just that when you request promotion choice, it uses the same procedure as when you enter the zone, controlled by promoChoice or promoOffset. Here it would increase flexibility if I allowed returning a character string or (more efficiently, but perhaps less user-friendly) the array that such a string would parse to when given as promoChoice. (Such an array would be indexed by piece type, and contain a non-zero value for each piece type that in principle can be chosen. Where 2 means 'if available in the holdings', and 3 means 'not on last rank'.

I understand that it will never be possible to handle everything by parameters. But the main point is that I don't want to realease on afficial specification for something I would have to change later. That would load the whole project with an obligation to remain backward compatibility for the legacy features. Now in this case it would probably not be so hard to maintain such compatibility: I could switch to a usiversal Custom() function that takes care of everything, only invoked when no parameters (such as morph or captureMatrix) are specified that require use of the standard function, and the user specified a legacy BadZone() or WeirdPromotion(). This Custom() function would then call the latter two, and integrate their return values into the new format. This Custom() could just get the complete move description used by the AI passed as an array.

I removed the Unique Pieces tag, because there is nothing stopping other games from using the same pieces, and then they wouldn't be unique any longer. Tags should be used for non-relational properties, not for relational or comparative properties like unique or best.