Comments by HGMuller

To make life easier for those who want to extend the Interactive Diagram with custom JavaSCript, I added a second argument to xxxTinker(): this gets passed the distance to last rank, corrected for piece color. Almost every WeirdPromotion() function I have ever written required calculation of that.

I added functions in the standard script to aid with other tasks: AddVictim(move, x, y) adds a locust square (x, y) to the specified move. And VetChoice(promoPiece, d) tests whether chess-like promotion to promoPiece would be allowed (as per promoZone and promoChoice) when you are d steps removed from last rank. You might want to fake a d within the zone in cases where the user script requests a promotion outside the zone.

The moving piece will always be stored in move[-6]. As an example, when you want to allow piece type 2 to promote when it arrives on last rank from the fore-last one, but not from a larger distance, you could use

function xxxTinker(m, d) {
  if(d != 0) return 0;             // not to last rank
  if((m[-6] & 511) != 2) return 0; // not piece type 2
  if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
  if(!m[-1]) return 4;             // choice not yet made, request one
  return VetChoice(m[-1], 0);      // return whether choice is forbidden (1) or not (0)
}

If under the same conditions a shogi-like promotion to piece type 12 (different from what promoOffset would specify) should take place, things are simpler:

function xxxTinker(m, d) {
  if(d != 0) return 0;             // not to last rank
  if((m[-6] & 511) != 2) return 0; // not piece type 2
  if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
  m[-1] = 12 | m[-6] & 1024;       // specify promoted type (adding color)
  return 3;                        // request choice between this and deferral
}

Scripts like this are only needed to make the promotion dependent on the move; if it is just dependent on the square you move to, or what you capture there, the standard parameters morph and captureMatrix take care of the promotion for you. The way I have implemented it now these would have precedence over the user-supplied scripts. That is, when these specify a promotion, ban or game termination, this will be applied without question, and the xxxTinker() script will only be invoked when they don't specify anything special. So the script only has to handle the non-standard cases.

Although the script could now add as many locust victims to a move as it wants, and wherever it wants those, the trick to request burning or atomic capture through promotion code 512 will still work, and the standard script will add the locust squares in that case.

Link?

I think I will implement the following interface for extending the Interactive Diagram with user-supplied scripts:

The user can supply a JavaScript function xxxTinker(m), where xxx is the satellite name for the Diagram (default value: 'piece'), and m is an array describing the move. This array will contain the board coordinates (which always start counting at 0) for the squares involved in the move, the rank number following the file number of each square. The first square (in m[0] and m[1]) will be the origin, the second (m[2] and m[3]) the destination, and after that will come the locust squares in the reverse order as the XBetza description visited them. The element m[-2] will specify how many squares will be altered by the move. (So if there are no locust squares this will be 2: the origin and destination.) After the locust squares can come squares where e.p. rights are generated; these are not counted in m[-2]. It is not specified how many there are of those, and most moves do not have them.

The element m[-1] contains the promotion piece for the move (i.e. the piece that will appear on the destination square), but it might or might not be initialized.

This xxxTinker() funtion can then modify the m array in any way it wants. Likely modifications are altering or supplying a promotion piece in m[-1], or adding locust squares by writing those in the appropriate m[] elements, and increasing m[-2] correspondingly. When it is done tailoring the move, it should return a value to indicate to the standard script what it should do with that move. Possible return valueas ar:

-2 Terminates game immediately, as a win for the player that can do the move (as if the move captured a King).
-1 Terminates the game as a win if the player making it survives the reply of his opponent (as with Shatranj baring).
 0 Take the move as we now prepared it (which could be unaltered).
 1 Discard the move; it is forbidden (e.g. due to zonal confinement, or improper promotion piece).
 2 Suppress deferral of normal Shogi promotion (as per maxPromote and promoOffset).
 3 Take the promotion we specified in m[-1], but also add a move that defers.
 4 Perform a Chess-like promotion. Moves with every possible promotion type will be subjected to xxxTinker(), and can be
   rejected or accepted by it in the normal way (returning 1 or 0).

The value 4 should only be returned when the value of m[-1] was undefined (if(!m[-1])...), to make a move that otherwise would not promote at all offer a Chess-like promotion choice. If m[-1] does have a value > 0 the promotion choice has already been made, and we must only reject or accept it.

I added mention of the pO notation for fast castling to the XBetza section, and dressed up the article with two Interactive Diagrams for exemplifying flexible and fast castling.

I also added mention of the K~b1 notation for unambiguously specifying flexible castlings.

The article is a bit vague about the castling and promotion rules. The choices you made in the FSF settings (O3 castling and no promotion to Prince) seem the logical ones, though.

Anyway, I put in some section headings, and added an Interactive Diagram in the Setup section, playing by these rules.

And you are right: this 'promotion to King' business seems a bit nonsensical: you simply win by reaching the last rank with a Prince, so there is no need to change it for another piece. There is a question, though, whether it is allowed to promote it on a square attacked by the opponent. In the Diagram I programmed it as an immediate win, because the rules explicitly say that you can expose a Prince to capture. But if you would really promote it, it would no longer be a Prince, and you would have exposed the resulting King to capture. So this 'promotion to King' could be just be a roundabout way of saying that this is a delayed winning condition, where you have to survive the opponent's 'after-move' in order to win (like in King of the Hill). But this interpretation is subverted by the mention of the first variant, which uses the resulting King as extinction royalty, so that it could be exposed to capture.

... though I still don't fully trust computer analysis to give reliable piece values for a given board size (e.g. may well depend at least to some extent on what else is on the board, and where exactly it's placed, in the setup used by a given computer study).

This is why serious computer studies always use a number of different mixes of opponent pieces, and average over many shuffles of those as initial setup. E.g. if you want to compare the value of Queen, Archbishop and Chancellor, you don't just play these against each other (e.g. in a FIDE setup whetre one player starts with A or C instead of a Q), but also against, say, R+B, R+N, R+N+P, 2B+N, B+2N (deleting these for the player that has Q, C or A, and deleting Q of the other player), to see which of the super-pieces does better, and by how much.

To test an Alibaba (which I apparently did once), you would replace 2N, N+B, 2B or R for two Alibabas (and give the opponent Pawn odds to get closer to equality), and just a single N or B for one Alibaba.

How does your estimate take account of the severe color binding of the Alibaba? Because of that it seems a very weak piece to me. It can for instance not act against half the Pawns.

Ancient Shatranj theory indeed values different Pawns differently. In Shatranj an Alfil is considered slightly better than an average Pawn. But you should keep in mind that a FIDE Pawn is worth significantly more than a Shatranj Pawn, because it has a game-deciding promotion, while in Shatranj an extra Ferz is often not helpful at all. And I suspect a lot of the value of the Alfil is that, even if tactically worthless, it acts as insurance against loss by baring when only weak pieces are left.

Bah, I was (sadly) fearing to get such an answer. I take your last sentence straight in my face, thank you. Are you especially angry today?

Not angry at all. But if you suspected this answer could come, there must be some truth in it, right? And don't get me wrong, Shako and Pemba are great games. I count them in the top 10%-tier of all chess variants, because of the good spectrum of piece values and interesting pieces. But that doesn't mean one should make infinite numbers of variations on them, using the same set of pieces over and over again, with minimal variation. Especially since there are already many other variants that use Elephant, Cannon and Vao. At some point that gets boring, and a clone of a great original is still just a clone.

Thanks for the info. I added the link in the notes section.

For my taste the pieces in Officer Spiel are way too strong, while those in Constable Spiel (although I like that more) are a bit on the weak side. If you would replace the Elephants by a Crowned Rook and a Crowned Bishop you would have an interpolation of the two that has pretty much an ideal piece mix; it would add one rook-class piece, and one halfway Rook and Queen, next to three pairs of light pieces (of which the War Machine has mating power).

I suggest to replace the Elephant, because it seems the 'most redundant piece': its footprint is a subset of that of the Bishop, and although it can jump, you already have the WA that has that move. And you already have the WD, which is also color bound.

P.S. The Diagram now also supports 'fast castling'. (Flush browser cache!) The XBetza notation ispOn. It seemed fitting to use the p modifier to distinguish it from normal castling, as it is a castling that can hop over other pieces. For now the n is ignored; perhaps this can be interpreted as the maximum range over which the King is allowed to jump.

Ah, thanks for reporting this. The Interactive Diagram for Elven Chess was one of the first I ever posted, and it was still using off-side piece images, even though the corresponding images have long since all been uploaded to this site. I would never notice such things myself, because my browser settings have this madness of http blocking disabled; I consider it a browser bug that this exists in the first place.

Anyway, I have now made the Diagram use the on-site images, and also tweeked its appearance a bit.

I am getting less and less happy with the WeirdPromotion() and BadZone() extension system for the Interactive Diagram. It is inconvenient that these are two different functions, and a shortcoming of WeirdPromotion() is its limited power for adding side effects to the move, and that it gets passed only a single locust square (while the NewClick entry system allows arbitrary many locust victims). This has been somewhat ameliorated by the kamikaze and burn/atomic pseudo-promotion codes, but there still remain lots of things that cannot be done.

It would be much better to have a single user-supplied function AlterMove(move), which gets the internal move representation passed as the single argument. This move representation is an array, which contains the coordinates of all involved squares (origin, destination, all locust squares, all squares where e.p. rights are generated, the promotion piece...). And what is even better: AlterMove() could make changes in that, (like adding locust squares), which would affect the original. As, unlike scalar objects, when an array gets passed to a function it will be the real thing, not a copy. So it could directly alter the promotion choice in the move, rather than returning it as a result, and leaving it for the standard code to incorporate it in the move.

The return value then could be reserved for signalling only. Like indicating that the move or promotion choice is forbidden, so that the move should be deleted from the move list. Or that the move is winning (e.g. by reaching a goal square). Or that a move thought to be a non-promotion should unexpectedly offer promotion choice (making the standard script duplicate the move, this time with other promotion choices, subjecting these again to AlterMove() to test whether these are allowed, and add those to the  move list when they are).

This would for instance also allow implementation of pieces like the Ultima Coordinator, which might need locust captures on distant squares at the intersection of its coordinate lines and those of the King. By switching the Diagram's tracking function on, the location of the King would be easily available, and the AlterMove() routine would just have to combine these with the coordinates of the destination on a Coordinator move, test whether there is an enemy there, and if there is, add it as a locust square to the move.

For backward compatibility the standard script could contain a default function for AlterMove(), which it invokes if the user has supplied a WeirdPromotion() or BadZone(), to call the latter two for the move in question, and translate the return values to the actions these request. (Like altering the promotion piece, or return the 'forbidden' code.) This seems a simpler and more powerful system. Perhaps some standard routines could be offered to simplify writing AlterMove(), like AddLocustSquare(move, x, y).

I am also wondering if I should devote some attention to configurable use of the trackPieces functionality in such a standard version of AlterMove(). Passive effects on adjacent pieces are not that uncommon in variants, especially immobilization. So where trackPieces=N now just serves to switch on the tracking for non-zero N, I could have N indicate a piece type for which the adjacent squares should automatically be marked in a neighbors[] array indexed by square number. And supply a new Diagram parameter neighbors, which could be given the values immobilize, pacify or burn, which then would activate to either forbid all moves with a piece standing on a marked square, forbid all its captures, or make moves to a marked square kamikaze moves, respectively. Then these rules could be implemented purely by configuration, without writing any script.

Short follow-up on posting diagrams: You must only write the board part of the FEN between the tages; the other stuff contained in a FEN would not be expressed in the image anyway. When I place your FEN between the tags I get this:

These are not the pieces you want; apparently the standard meaning for C is Cannon, for S Squirrel, and for J it is Camel. But that doesn't have to discourage you: you can either try an alternative likely letter (like M for Marshall), or replace the letter by the full name of the Alfaerie image in braces ({berolinapawn} and {fool}:

[ fen]3{FOOL}3k1w/10/10/8p1/2P5Pp/1{SERGEANT}7P/5{sergeant}4/10/4m4{fool}/7BK1[ /fen] gives

This Diagram lets the Queen burn both actively and passively. It uses trackPieces=1 to track the Queen, so WeirdPromotion() can efficiently get her location, and mark the adjacent squares as the burn zone, to destroy all pieces that land there.

(Refresh the browser cache, as there was a bug in the standard script w.r.t. kamikaze moves: these did set the 'non-virgin' flag on the resulting empty square, so the Diagram would treat it as an invisible white piece rather than an empty square. For now I solved that by making all pieces resulting from promotion virgin. Which is of course incorrect, but much less harmful.)

Indeed, a user promotion choice does overrule everything else. If a fixed promotion is required for pieces that would offer choice, the promotion query should be suppressed. Not only because it would prevail, but because it makes no sense at all to let the user choose and then do something else.

The mechanism the Diagram uses for this is to call WeirdPromotion() with the promo parameter set to 1021 (which is not a valid piece type), to inquire whether there is promotion choice. When this call returns 1001 the query will be suppressed, when it returns 1000 a query is forced, and in any other case it decides itself (based on maxPromote, promoZone and promoChoice).

In the AI it works slightly different; there (for a piece that could normally promote) WeirdPromotion() is called with promo equal to the promoted piece (as per promoOffset), and to suppress the promotion this would have to return 1022. It is the deferral (promo=0) that must be turned into a kamikaze move by returning 251, so that moves that would not naturally promote also get burned.

So when a passive burn is detected, WeirdPromotion() should return 1001 if promo == 1021, 251 if promo == 0 and 1022 otherwise.

Indeed, when WeirdPromotion() is used to pieces that would also promote otherwise it involves more than just returning the desired promotion piece. The Diagram makes a special call to it (recognizable by promo = 1021) to inquire whether there might be promotion choice, and in the passive burning case this should be used to suppress the choice that maxPromote and promoZone would suggest. I don't think the current version does this entirely correct for Shogi promotions, though. I will have a look at it tomorrow.

The Diagram I posted only does active burning. Sorry I was unclear about that.

Adam implemented the burning by embedding a custom script for WeirdPromotion. Where he first tests whether a piece lands next to a burner (and in that case returns 251 as promotion code to make it a kamikaze move), and otherwise returns 512 when the moved piece is a burner.

I only used the captureMatrix parameter in my Diagram. There is no formalized way yet to specify passive burning by Diagram parameters; you would have to supply a JavaScript extension.

Respect the power of three Wazirs - they can checkmate a lone King in 47 moves.

True. But not very relevant. Three Ferzes do it faster when not all on the same color. (Addmitted, this rules out 1/4 of the cases.) But in Shatranj stalemate is a win, and even two Ferzes or Wazirs can force that on a bare King. And the worst case for the Ferzes is two moves faster than for the Wazirs, even when they are on the same color.

Unfortunatey a general t modifier is a bit hard to implement. Which is a pity, as with the unload modifier it would make it possible to describe magnetic pieces and catapult pieces.

So for now I added capture of pieces adjacent to the destination as a standard feature, controllable through the capture matrix and from WeirdPromotion(), as internally it uses the promotion element of the move array to trigger it. An @ in the captureMatrix orders promotion to piece number 512 for that particular combination of attacker and victim (wher the latter can also be an empty square). Now this is an invalid piece number, and used as a kludge to indicate 'burning'. How exactly this burning works depends on a new parameter atomicCapture=N. For N=0 it does Tenjiku-type burning: only enemies get burned, and the capturer survives. For larger N is gives you explosion like in Atomic Chess: all adjacent pieces are destroyed, friend and foe alike, but the first N piece types from the table survive, while the capturer always selfdestructs.

Now this works the same when you return 512 from WeirdPromotion(). But you have additional control there. By returning 512+C (0 < C < 256) you also trigger the burning. But in that case it burns only the squares selected through the bits of C, where 1 = N, 2 = NE, 4 = E, 8 = SE, etc. So WeirdPromotion() could do additional testing on the board to decide whether an adjacent piece should be burned or not. This could for instance be used to implement Ultima Pincher Pawns, by checking whether there is a friendly piece behind the adjacent one.

All this only works with newClick=1, which unfortunately means that the move diagrams (using the old highlight code) would not show the burning. It is not easy to cure that, as the move generator doesn't know about it (as far as that it is just a promotion), and no clicks on the burn victims are required . (During hovering over the move diagram the highlighting is as if the hovered square had received the second click, and it shows where the third can go.)

BTW, I now added a link to the Extended Betza article.