Comments by HGMuller

Well, it seems I remember things I did that I really did not do at all, but was just planning to do. Not even the new version of the PTA stores the morphs boards in GAME code. And the GAME-code include file does support morph board only form automatic type change, not the case where you have choice.

But fortunately what you want seems possible without using morph. I guess what you did was make the promotion zone the entire board to have the back rank in it, but that makes the white and black zone overlap, and this is what the GAME code cannot handle. But for what you want it is not needed to have overlapping zones, and each zone can only be reached by Pawns of the color that promote there. If that is the case the generated GAME code can handle it through its regular promotab. You just have to make that

set promotables (P p);
set promotab (
  (Q R B N)
  0
  0
  0
  0
  0
  0
  (q r b n)
);

That is how it would also look for orthodox Chess, except that the white and the black pieces are now swapped. For each piece in the 'promotables' it looks in the 'promotab' at the rank it moves to, and if that is not 0 it is considered a promotion rank, and contains the possible choices.

As to the game: I don't see why players would ever choose anything other than Queen. Despite the limited range it is still far stronger than any of the other pieces. It has 16 unblockable targets; the Rook and Bishop have only 12. The Knight potentially has 16, but never on 8x8.

Well, if you know what you are doing, and do it carefully, you can add new pieces to a preset. You would have to make a copy of the moves of the Sergeant:

1  1  1  1     3 // sergeant(5616)
1  1 -1  1     3
1  3  0  1     3
1  1  1  0     1
1  1 -1  0     1
0

and copy that to the end of the legdefs table, behind the King moves. Then you would have to change all the y steps there (the 4th number on each line) from 1 to -1, to make it move in the other direction. Finally you would have to calculate where this appended section starts, which is 8 lines of 5 numbers plus the terminating zero (i.e. 41) places behind the King (which starts at 5703, as the comment indicates). So it starts at 5744.

Finally you replace the 5616 in the line

def sg cond #0 5616 0;

by this 5744, to let the GAME code know where the moves of the black sergeant (sg) start. That should do it.

The version on hgm.nubati.net is the only one I updated. (Not entirely true; I updated the one on CVP for the new sprites. But it can take weeks before anyone will be able to enjoy updates on CVP, because they will all be redirected to CloudFlare, which caches the old files for an unpredictable amount of time.)

If you look at http://hgm.nubati.net/jocly/jocly-master/dist/browser/games/chessbase/tenjiku-chess-model.js you should see for GenerateMoves():

Model.Board.GenerateMoves=function(t){
 var e=this.cbGeneratePseudoLegalMoves(t),ok=0;
 this.mMoves=[];
 for(var r=!0,i=this.kings[this.mWho],a=e.length,n=0;n<a;n++){
  var s=e[n]
  if(this.kings[-this.mWho]==s.t){this.mMoves.push(s),this.mFinished=!0,this.mWinner=this.mWho;return;}else{
   if(ok)this.mMoves.push(s);else{
    var o=this.cbQuickApply(t,s);
    if(!(this.cbGetAttackers(t,this.kings[this.mWho],this.mWho,!0).length>0)){
     var h=this.cbGetAttackers(t,this.kings[-this.mWho],-this.mWho,!0).length>0;
     s.ck=h,this.mMoves.push(s),ok=1,s.f!=i&&(r=!1)
    }
    this.cbQuickUnapply(t,o)
   }
 }}
 if(0==this.mMoves.length){
  if(this.check===undefined)this.check=this.cbGetAttackers(t,this.kings[this.mWho],this.mWho,!0).length>0;
  this.mFinished=!0,this.mWinner=t.cbOnStaleMate?t.cbOnStaleMate*this.mWho:JocGame.DRAW,this.check&&(this.mWinner=-this.mWho);
 }else if(this.ending[this.mWho]){
  if(!r)for(var n=0;n<this.mMoves.length;n++)this.mMoves[n].ko=!1
 }else if(!this.ending[this.mWho]&&r&&!this.check) for(var n=0;n<this.mMoves.length;n++)this.mMoves[n].ko=!0
},

If not, you have an old version cached.

You can do that through the captureMatrix. Just fill the entire column for the contageous piece with its own ID, except in its own row. The capture matrix has basically  made the contageous and anti-trade parameters obsolete; it can do all that in a much more precise way.

[Edit] I suppose the question was for if you had various contageous types, so you would have multiple columns with automatic promotion to the captured type, and you would just leave the rows of the pieces that are immune to this blank; That could also be the pieces that are contageous. You can even make them immune to some, but not to others.

That is weird indeed. Do you have a link to the preset?

The ID now guestimates the values as N=4, B=4, R=5.6 and Q=6. It seems no one would ever choose Bishop or Knight. Conidering how much orthodox Chess players favor Bishops over Knights, 0.5 Pawn difference could already seem sufficient reason not to choose it. R and B have 16 move targets only in the central square, the Queen has it in a 5x5 central area.

Oh, and don't forget to add what happens with q on single-letter sliders to the list of "new/altered" modifiers.

Well, up to now it was an undocumented feature, and I am not sure if it is a desirable one. qR does the same as [W?DD], but the latter is a lot clearer. To understand qR you would have to know that q is overloaded, and doesn't mean 'circular' in this context, but something totally unrelated. Most people would not know that.

If I knew for which Diagram I implemented this, I would change it to the bracket notation there, and no longer support q in this meaning in the general script.

How would you do a piece that hides itself, though?

Pieces don't hide themselves; they just are transparent. Unfortunately transparency is currently not supported, other than making all sliders also hoppers, and then use the captureMatrix to forbid them to hop over anything except the transparent piece. It would of course be more convenient if there was a special symbol in the captureMatrix to tell that one type can slide through another. This might be implemented some day.

and not knowing anything @gbtami, I do not know whether he is Chinese himself.

I think he is Hungarian, the programmer of PyChess.

Well, unlike features such as contagion and ironness tranparency cannot be implemented as a filter on the generated moves, but would have to be implemented within the slider loop of move generator. In this respect it is similar to the already implemented ban on hopping. (As the final move does neither show what you hopped over, nor what empty squares you passed through.)

But wherever it is implemented, it has to test whether the slider loop should terminate or can continue after skipping the square, based on the piece type of the encountered piece. And in that case it might as well check the piece type of the moving piece as well, by looking in captureMatrix[attacker][victim] rather than in some newly created table transparency[victim]. So if I were to implement a parameter transparency=N, I would implement that by just filling the entire column of the capture matrix for piece number N with the code for transparency.

I have grown an aversion agains specifying pieces by number, though; it is a frequent source of bugs when you decide to add or remove a piece later. So it would be better to allow a (possibly comma-separated) list of piece IDs here. That is a bit harder to implement, because you can interpret it only after al pieces have been defined, but I already did something like that for the royal parameter.

The problem with an interface that shows the entire capture matrix at once is that for a large game it might not fit the screen. And usually capture matrices are quite sparsely populated. There are only a few special pieces, that either have their colun or their row set to something (possibly with some exceptions). But I am always open to good interface ideas.

There are several issues here. The 'range' indicator 4 means 0 to 4. So all the pincher captures become optional; it can use the 0 case. And I suppose you want it to be an automatic side effect. Even if you could force it to traverse the parenthesized part 4 times, (by just writing it in full 4 times), there is no guarantee it doesn't take the path 4 times over the same piece, or over two pieces each twice.

The problem is that what you are trying to describe is not really a move. It is a form of conditional burning. These can both be described in Betza notation. But the difference is that for a move you have to pick one of the possible realizations, while for burning every possible realization should be executed. And that nothing moves during such execution: you really describe the path of a 'flame', which evaporates after having done its damage.

What you would want is being able to define spellZone=dabuafcK.

Now that I think about it, this might not be so difficult to implement. I could treat the spellZone as an extra piece, letting the Betza parser create the move list as usual. Then every move of a burning piece should automatically be followed by all possible moves of an empty square from the destination of that piece. Tomorrow I will try if I can get something working along those lines; most code for it already exists, and should just be called for another purpose.

Leapers can leap over a hole; they never sense any othe square than thir destination. Lame leapers cannot.

Hoppers cannot hop over holes, which are treated as off-board squares. But you could define, say, [oR-fmR] to get a piece that can hop over a hole. Iron pieces are pieces, so hoppers can hop over them. Unless the captureMatrix would forbid it.

There is currently no restriction possible on U. Conceivable would be a range, or directional modifiers that would be interpreted according to the K or oblique system, depending on the destination.

The "Try it!" link should work now; I clipped off the 3 from the requested image. I guess this error crept in when I changed the checkmating page to using alfaeriePNG, which does not have a wildebeest3. I don't really know which set has, though, as the old alfaerie gifs don't seem to have it too.

This is fishy, as these extraneous images are defined with the extension .gif, and betzaNew.js is programmed to keep the existing extension, or use that of the regular pieces if no extension was specified. And this was working when I made the Diagram. SOmething is going wrong here, but I don't see immediately what. The code to create the image URL looks OK:

  var im = imag[n];
  if(im.indexOf('%') < 0) return graphDir + prefix + im; // from standard set
  var p = im.replace('%', prefix); // custom graphics; replace % by color prefix
  p = p.split('.'); if(p.length == 1) p[1] = graphSuffix;
  p = p[0] + (p[1] == '' ? '' : '.' + p[1]);
  if(p[0] == '*') p = graphDir + p.substring(1);
  return p;

After the split p[1] should have been 'gif', and p.length 2.

Well, if you play with black the Applet should demonstrate it to you. The key is that the Bison has (say) to be on c4 with its King on b3 to checkmate on a1, and to force the bare King to step to a1 it had to attack c1 on the move before. So it has to move from c1 to c4 in two moves. (Actually a retrograde capture plus a normal non-capture, but since it is symmetric and non-divergent there is no need to distinguish the move types.) It can do that via f2 or f3, which means it must have to be on one of these in the mated-in-1 positions.

It could be that the King was forced to a1 earlier without the Bison being on f2 or f3, e.g. namely when the Bison is on any other square it could reach from c1 (so a4, b4, d4 or e4). The Bison then has two moves to reach f2/f3, as the next move Ka1-b1 is forced without the Bison's help. (And you could also play Kb3-c2 to move the mate to the other edge, and make d3 the target where the Bison could checkmate, after coming from b6/c6.) If you look at what a Bison can do in 2 moves, it is a lot. From any of its move targets to any other. That is W, D, H, WX, F, D, A, N, FX, NX, DY moves, amongst others. For the close-by targets there are only very few that it cannot reach in two moves. It particular, from f3 it could go to a4 (via d6), b4 (via e6), d4 (via g6) and e4 (via h6), so on all these squares it has mate in 3.

If a piece can make these final steps to force mate on a bare King that is in a corner, it can usually force mate from any position, if the board is not too large. What is too large is determined by how strong the piece is, and a Bison is pretty strong. (But it cannot force a King to the edge all by itself, such as a Centaur can, so at some size it will lose its mating potential.) For a piece with only large leaps, the board must also not be too small.