Comments/Ratings for a Single Item

Since you already appear to have an Interactive Diagram for Bigorra, why don't you simply paste that into the Play-Test Applet, and paste the GAME code it provides on pressing the 'GAME code' button into the preset?

I had never tried that. I am not sure what I have to paste exactly. I took the lines between

The result is a big progress. However, some pieces are missing and some are the wrong ones.

And when played, all piece graphics are very small, same size than for the ID, except that here the board is bigger.

That's correct, you have to paste the part between the HTML tags (the parameter=value lines and piece definitions). This should make the diagram appear on the Play-Test Applet's board. (In this case a bit squeezed, because your board is too wide for the page layout, but still bearable.)

The choice of piece images is controlled by the lines below the green header "Additional Pre-Game code (only needed with non-standard piece set)":

set mypieces assoc
  P "wquickpawn.png" p "bquickpawn.png"
  S "wsergeant.png" s "bsergeant.png"
  ...
  Q "wqueen.png" q "bqueen.png"
  AZ "wamazon.png" az "bamazon.png"
  DW "wdragon.png" dw "bdragon.png"
  K "wking.png" k "bking.png";
setsystem dir "/graphics.dir/alfaeriePNG35/";
setsystem pieces #mypieces;

The forelast line defines the directory from which they have to be taken; it uses the 35x35 alfaerie PNG set, because that is what the Diagram that you pasted used. (It just copied the directory name from the graphicsDir parameter of the ID.) If you want the 50x50 pieces you can just delete the 35 suffix.

The sergeant apparently occurs twice in the list; not sure GAME code would like that, so you might have to delete one of the lines.

BTW, this code for defining the piece set is really independent from the other provided code; it should work in combination with other GAME code for automating the preset as well.

I am not sure about the "missing and wrong ones". Beware that GAME code is only executed once you start using the preset for playing. So any method of defining piece images through GAME code will have the problem that the initial image one gets when loading (and editing) the preset will still use standard images and piece labels, and only when you press 'play' the Pre-Game code is executed, and you will get to see the pieces you asked for.

I'm far from an expert. line 193 is in a loop, and you are getting an array back of enimies that is from piece.

Line 193 is using fn #piece.

This means you need a function def for every piece.

def bi merge checkaleap #0 #1 1 2 checkaleap #0 #1 1 4;

HG, this function you put in the Play-Test Applet is just wonderful. Really it is perfect for people like me who are at pain coding for a GC.

Thank you also for the comments. I found some mistakes, for instance I had two pieces named H, which was not an issue for the ID but is one for the GC.

I fixed the icons' size, and other easy fixes. The remaining issue is with the promotions. I have a lot of pieces that may promote. Apparently, nothing is transferred for promotions. Only the Pawn promotes, and it does for Q/B/R/N as in chess, whereas it should promote only to Q in Bigorra. The other pieces cannot promote. Do you know how to fix that?

Thank you again

..., for instance I had two pieces named H, which was not an issue for the ID but is one for the GC.

It would have been an issue to the ID if you wanted one of the two as a possible promotion choice, but not the other, because the promoChoice has to be indicated by piece label.

As to the promotions: the ID should have contained a line promoChoice=Q if pawns (or in fact the first maxPromote pieces in your list) should always promote to Q. Your ID did not have that, so the choice defaulted to QRBN. (This is actually an inconvenient default, and one day I will change it to an empty string, which already means "every piece except the promoting ones and the royals". But that would also not have given you what you want.) Thus the ID and the preset now suffer from the same problem.

For the preset you can fix this by editing the Pre-Game code: it contains something like

set promotables (P p); // pieces that can promote
set supply (N n B b R r Q q); // in infinite supply
set promotab (         // allowed choices per rank
  (n b r q)
  0
  0
  0
  0
  0
  0
  (N B R Q)
);

and you would just have to change the set of choces to (q) and (Q). This allows you to specify different choices on different ranks, and also to restrict choices to pieces that have been captured, by removing those types from the 'supply'. (This would happen automatically when you had prefixed the corresponding choices with * in the promoChoice of the ID.)

This doesn't allow you to diversify the choice based on the promotiong piece type, though. In the ID on the Bigorra page, this is taken care of by a custom JavaScript function embedded in the page, and this cannot be transferred to the Play-Test Applet (which would not know how to convert JavaScript to GAME code anyway). The latest version of the ID makes it possible to define promotions for each piece type separately without any custom JavaScript, through a morph parameter specified directly after the piece definition. E.g. morph=R would automatically promote the piece to Rook (supposing that is what R meant) when it reaches last rank.

Unfortnately the Play-Test Applet does not work with this latest version of the ID, and would also not contain the code needed to convert the specified morphing to GAME code. A problem here is that editing pages on this website does not work properly, and any attempt to edit the Play-Test Applet results in its destruction: hundreds of spurious changes, and incorrect operation of the result.

At the moment the best solution is probably to append a bit of hand-written GAME code to the Post-Move sections that take care of promoting the pieces that reach last rank in the desired way. Basically doing for the preset exactly what the custom JavaScript routine on the Bigorra page did for the ID. This would look like (for the white Post-Move code):

if == 15 rank #desti:
  switch #mover:
    case XX:
      add YY #desti;
      break;
    case ZZ:
    ...
    default:
  endswitch;
endif;

if you wanted piece type XX to promote to YY, etc., and for the black Post-Move code something similar (except that all the piece labels should be lower-case, and it would happen on rank 0 rather than rank 15). This is probably exactly the same as what you would have to do when automating the preset by any other GAME code.

I will probably create a new Play-Test Applet that will have some interface for specifying the morphing for each piece (e.g. by dragging the pieces you want it to morph to to the squares where this should happen, and then select a piece that should morph that way), and then pass this information to the GAME code as a (potentially huge) table, which for each combination of piece type and destination square tells what the piece should promote to. (Which would go into the Pre-Game section, while the standard routine for move handling in the betza.txt include file would then draw on the data in that table for adjusting the piece type each move.)

To make this manageable for variants as large as Bigorra I suppose some form for compressing the table would be very desirable, making use of the fact that most pieces would never morph at all, other pieces would not morph on most of the board, and when they morph somewhere they would usually morph the same way on the entire rank. Possible something similar to the promotion-choice table, which for each piece type would either contain a 0 (if the piece never morphs) or an array of ranks, in which it then would write a 0 if the piece never morphs on that rank, or an array with promotion pieces for each square on the rank.

Hmmm, this sounds doable. Perhaps I should already put the code for interpreting such a compressed table in the betza.txt include file, then it would be possible to supply a morph table 'by hand'.

Mind that I'm paying close attention to this discussion; I just had a request for a GC of Vanguard Chess. :)

Hi. This Game Courier for Bigorra is ready. Please make this page public. Big thanks again to H.G. for his precious help.

The author, Jean-Louis Cazaux, has updated this page.

@HG: I have a problem that I can't solve. In many of my variants I have a rule of King's leap to a 2nd square replacing castling. As for regular castling, the King may not leap when it is under check. It works fine for Metamachy, Zanzibar, Maasai, Terachess II, etc. But in Bigorra, the GC would let a CHECKED King leap to a 2nd-square! Actually, it marks the destination square as a possible move, but if the player does it (so, violating the real rule), the game ends with an error message saying the King has moved out of chess.

Why the Bigorra GC is behaving like that whereas Metamachy or Terachess II for example don't have this behaviour, I don't know. I would like to fix that bug in Bigorra GC but I don't know what to do.

I ask you because that GC had been made with the PTA from the ID. Could you please have a look on that GC?

https://www.chessvariants.com/play/pbm/play.php?game=Bigorra&settings=Default-PTA

Thank you very much

I repost this message which was probably missed:

@ HG Muller: I have a problem that I can't solve. In many of my variants I have a rule of King's leap to a 2nd square replacing castling. As for regular castling, the King may not leap when it is under check. It works fine for Metamachy, Zanzibar, Maasai, Terachess II, etc. But in Bigorra, the GC would let a CHECKED King leap to a 2nd-square! Actually, it marks the destination square as a possible move, but if the player does it (so, violating the real rule), the game ends with an error message saying the King has moved out of chess.

Why the Bigorra GC is behaving like that whereas Metamachy or Terachess II for example don't have this behaviour, I don't know. I would like to fix that bug in Bigorra GC but I don't know what to do.

I ask you because that GC had been made with the PTA from the ID. Could you please have a look on that GC?

https://www.chessvariants.com/play/pbm/play.php?game=Bigorra&settings=Default-PTA

Thank you very much

If I remember correctly, the PTA does that for all special King moves, such as castling.

Sorry, I was out of town for a few days, and had no time to figure out the answer on this one.

The presets you compare with were not automated through the PTA, so there is no reason why these should behave the same.

Are you sure the game ends when the King moves out of check? Normally an illegal move should not terminate the game; it should just be refused (in this case with the message you quote), and then through using the browser 'back' button you should be able to retry another move. This is also what happens if you insist moving a piece to a non-highlighted destination.

If this is the case the only thing that isn't working exactly as it should is the highlighting: the King jumps get highlighted even if they are forbidden because of check. But there is no way to exploit this; in the end legality is enforced by refusing the move.

The way the PTA-generated GAME code enforces 'not out of check' rules is by having the potentially forbidden moves generate e.p. rights on the square of origin. Using such a move then would allow the opponent to capture the moved piece (i.e. the King) en passant, making the move illegal.

Unfortunately the 'accelerated check test' used for determining the legality of the moves to highlight (in order to prevent this from becoming excruciatingly slow for large games) doesn't detect this: it generates all opponent moves from the current position to mark squares that are under attack on the board. And then only rejects King moves that go to such an attacked square. And in this case the problem is not that the destination is attacked, but that the origin is attacked.

I suppose I could solve this in the accelerated check test by suppressing the virginity of a King that is in check during the generation of the highlights.

[Edit] I now changed the move generator to suppress initial moves of a piece that should not move out of check, when it is in check during the accelerated check test. Please test if this solves the problem.

@ HG: thank you for your answer. Indeed, all my other games with King's jump were done without using the PTA, so I cannot make a direct comparison. I think you are right on this.

I have tested. Apparently I get the same. The square of King's jump is highlighted even though the K is in check. But if I do that move, I get a long message with the moves, the code and starting by:

GameEnd That moves through or out of check

Use your browser's BACK button to go back to the previous page, then reload if necessary.

For general reference, here is the complete list of moves:

If I go back with my browser, I get the message "Ce document a expiré" that you understand probably. But even though this is discouraging to continue, there is also a button "retry" and if I retry I finally get the game just before the King's jump. Indeed, it is then possible to continue to play.

So I think that as you mean, the problem is disturbing but rather cosmetic. If they know what is happening, the players can continue to play, which is the major point.

Thanks again.

I discovered a bug in the GAME code I added in my attempt to fix the problem. (writing 'task' instead of '#task'). I think it should be solved now.

@ HG: Yes, it seems that the problem is 100% solved. Thank you very much.