..., 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'.
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
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'.