I discovered and fixed a bug in the AI w.r.t. promotions that are restricted to captured pieces (*X in the promoChoice). This became apparent in betzaNew.js, which also uses the AI routines for performing user moves: the number of pieces in hand would change in an unpredictable way when holdingsType=0, which is supposed to mean they should not change at all in absence of promotions. (Values -1 and 1 would mean captured pieces should go into the holding, with or without color flip, respectively.)
Pieces for a *X promotion are taken from the hand, and are not allowed when the hand count for piece type X is not positive. In this case captured pieces usually go into the hand in their original color (holdingsType=1), so they become available as promotion choices. In some variants the hand initially contains some pieces, without being filled during the game (holdingsType=0), to limit the number of times you can introduce a piece that is not initially present on the board. (Such as gating in a new piece in Musketeer or Seirawan Chess.)
The AI was always updating the hand counts: captured pieces would go into the hand, and in case of promotions the chosen piece would be taken from the hand, and the original one would be put back, without taking the holdingsType into account (for efficiency). Color-flipping would be taken into account only on dropping the piece. (Which the AI never does, but which the user can do by dragging a piece from the table to the board.) I now (in betza.js and betaNew.js) suppress updating the hand count for captured pieces, and a promoting piece would not be added either. But a selected promotion would always be taken from the hand.
The mechanism of 'promotion from the hand' can sometimes be used to implement variants that allow some one-time event. If individual pieces can do something only once (but not necessarily on the first time they move), this can be implemented by 'hidden promotion': you define two types for that piece (possibly with the same image and ID), only differing through the fact that one of them can also make the one-time move, and the other not. And you let the first type morph to the second everywhere on the board, but exempt the regular moves from application of the morph by suffixing those in the XBetza descriptor with an apostrophe '. Only the one-time move then causes the piece to morph to the type that can no longer make it.
If different pieces of the same type would have to communicate to each other whether one of them has already used the one-time privilege, you can use a similar method, but with restricted promotion. In the morph of the piece that can you would refer to a set defined in the promotionChoice with a *X choice, and provide one X in hand initially.
An even more complex case occurred in Modern Chess: it is allowed there to swap one of your Bishops there with the piece left or right of it (to get the Bishops on different square shade), provided both pieces have not moved before. Swapping with an orthogonal friendly neighbor in XBetza would be udW, so that isudW as one of the Bishop moves gets us a long way in the right direction. XBetza has no way for limiting (friendly) capture to victims that have not moved, though.
This can be remedied by making the neighboring pieces morph into another (but identical) type as soon as they move, and then use the capture matrix to forbid the friendly capture of (and thus the swap with) the type it morphs to. Suppose, for simplifying the example, that the piece you can swap with is always a Knight. Then you would define two types that move and look as Knights, and define a morph for the first (initially present) type that changes it to the second Knight type everywhere on the board. Friendly capture of that 2nd type by a Bishop would then be for would then be banned with the aid of the captureMatrix. Then a Bishop can only swap with an original Knight; whenever a Knight would move and then return to its starting square it would have changed to the unswappable type.
That still leaves the problem of how to forbid the swap for the second Bishop when you did it with the first. This can be implemented by also defining two Bishop types. One starts on the board, and has the swap move. Of the other each player gets initially one in hand. For the initially-present type you would define a morph that specifies a promotion to a promotion set *B, i.e. a promotion to a piece that must come from the hand. To make sure that hand piece is only used up when you swap, you define the Bishop move as B'isudW, where the apostrophe exempts the preceding B move from being subject to the morph. So after a B move the Bishop remains of the initially present type, but as soon as one of the Bishops uses a swap move, it must morph, and thereby consume the hand piece needed to do that (which can simply have move B). From that moment on the swapping move becomes a dud on the Bishops that still have it.
Idea: this whole operation would be a lot simpler if there was a way to specify in the captureMatrix that a given capture can only be performed on pieces that have not moved yet. In a sense any piece type you specify already defines two types, the initial type and the one that has moved, and the Diagram changes one to the other automatically. Then nothing special would have to be done with the pieces that start next to the Bishop.
I discovered and fixed a bug in the AI w.r.t. promotions that are restricted to captured pieces (*X in the promoChoice). This became apparent in betzaNew.js, which also uses the AI routines for performing user moves: the number of pieces in hand would change in an unpredictable way when holdingsType=0, which is supposed to mean they should not change at all in absence of promotions. (Values -1 and 1 would mean captured pieces should go into the holding, with or without color flip, respectively.)
Pieces for a *X promotion are taken from the hand, and are not allowed when the hand count for piece type X is not positive. In this case captured pieces usually go into the hand in their original color (holdingsType=1), so they become available as promotion choices. In some variants the hand initially contains some pieces, without being filled during the game (holdingsType=0), to limit the number of times you can introduce a piece that is not initially present on the board. (Such as gating in a new piece in Musketeer or Seirawan Chess.)
The AI was always updating the hand counts: captured pieces would go into the hand, and in case of promotions the chosen piece would be taken from the hand, and the original one would be put back, without taking the holdingsType into account (for efficiency). Color-flipping would be taken into account only on dropping the piece. (Which the AI never does, but which the user can do by dragging a piece from the table to the board.) I now (in betza.js and betaNew.js) suppress updating the hand count for captured pieces, and a promoting piece would not be added either. But a selected promotion would always be taken from the hand.
The mechanism of 'promotion from the hand' can sometimes be used to implement variants that allow some one-time event. If individual pieces can do something only once (but not necessarily on the first time they move), this can be implemented by 'hidden promotion': you define two types for that piece (possibly with the same image and ID), only differing through the fact that one of them can also make the one-time move, and the other not. And you let the first type morph to the second everywhere on the board, but exempt the regular moves from application of the morph by suffixing those in the XBetza descriptor with an apostrophe '. Only the one-time move then causes the piece to morph to the type that can no longer make it.
If different pieces of the same type would have to communicate to each other whether one of them has already used the one-time privilege, you can use a similar method, but with restricted promotion. In the morph of the piece that can you would refer to a set defined in the promotionChoice with a *X choice, and provide one X in hand initially.
An even more complex case occurred in Modern Chess: it is allowed there to swap one of your Bishops there with the piece left or right of it (to get the Bishops on different square shade), provided both pieces have not moved before. Swapping with an orthogonal friendly neighbor in XBetza would be udW, so that isudW as one of the Bishop moves gets us a long way in the right direction. XBetza has no way for limiting (friendly) capture to victims that have not moved, though.
This can be remedied by making the neighboring pieces morph into another (but identical) type as soon as they move, and then use the capture matrix to forbid the friendly capture of (and thus the swap with) the type it morphs to. Suppose, for simplifying the example, that the piece you can swap with is always a Knight. Then you would define two types that move and look as Knights, and define a morph for the first (initially present) type that changes it to the second Knight type everywhere on the board. Friendly capture of that 2nd type by a Bishop would then be for would then be banned with the aid of the captureMatrix. Then a Bishop can only swap with an original Knight; whenever a Knight would move and then return to its starting square it would have changed to the unswappable type.
That still leaves the problem of how to forbid the swap for the second Bishop when you did it with the first. This can be implemented by also defining two Bishop types. One starts on the board, and has the swap move. Of the other each player gets initially one in hand. For the initially-present type you would define a morph that specifies a promotion to a promotion set *B, i.e. a promotion to a piece that must come from the hand. To make sure that hand piece is only used up when you swap, you define the Bishop move as B'isudW, where the apostrophe exempts the preceding B move from being subject to the morph. So after a B move the Bishop remains of the initially present type, but as soon as one of the Bishops uses a swap move, it must morph, and thereby consume the hand piece needed to do that (which can simply have move B). From that moment on the swapping move becomes a dud on the Bishops that still have it.
Idea: this whole operation would be a lot simpler if there was a way to specify in the captureMatrix that a given capture can only be performed on pieces that have not moved yet. In a sense any piece type you specify already defines two types, the initial type and the one that has moved, and the Diagram changes one to the other automatically. Then nothing special would have to be done with the pieces that start next to the Bishop.