Comments/Ratings for a Single Item

I am not sure why you refer to 'fast castling'. Is that the type of castling proposed by Kevin Pacey in his wide-board variants? Neither the Diagram nor the GAME-code produced by it do support such castling.

The Cannon would have to be in the partners set to allow castling with it. How far the King moves on castling is defined in the moves of the King; castlings are defined in the legdefs table as two-leg moves, the first leg being the slide that has to be used to find the partner, and the second leg (only attempted when a partner could be reached) indicates the leap the King should make. Your presets appear to define both 2-step and 3-step castlings for the King.

A problem is that the castling moves you define on the King are not critical w.r.t. the partner they use; any piece in the partner set would do. So it would not be possibe to only allow 2-step castling with a Rook, but not with a Cannon.

Well if I move my king on top of the rook is castles (3 squares king move). What is w.r.t?

With respect to

In the first preset, when I select the King (after clearing away pieces between King and Rook) it highlights all squares between King and Rook. If I then click the second of that, it does a 2-step castling. I have little doubt that on clicking the 3rd it would do a 3-step castling. If I click on the Rook (which is also highlighted) it does a 4-step castling.

Ok, this means I have to do a separate castling subrountine but that is very difficult, so if you have any advice, I'd gladly take it.

I guess you could use the applet-generated code like 2-, 3- or 4-step castling is always possible, with both Rook and Cannon (adding the latter to the 'partners' array). Like it already seems to be. And then supply a function 'BadZone' in GAME code to suppress the two cases you do not want (2-step for Cannon and 4-step for Rook). You would have to set a variable 'zonal' to true in the Pre-Game code to cause this BadZone function to be called.

The function BadZone will get called with 5 parameters: origin, destination, locust square, drop square, and piece to drop on the latter. For castling the castling partner will be on the locust square. I don't think your variants have locust capture other than e.p., so when the locust square is in the 'partners' array you can be sure it is a castling, and there is no need to test whether it was actually a King that was moved.

I would do it as follows:

set rooks (b2 k2 b13 k13);
set badCannon (e2 i2 e13 i13);
def BadZone match #locust #partners and cond match #locust #rooks match #dest rooks match #dest #badCannon =O =dest =locust =D =P;
set zonal true;

This would declare the move invalid when the locust victim is one of the castling partners (match #locust #partners), AND, depending on whether it is one of the Rooks (match #locust #rooks) whether the destination square (of the King) is on the Rook (match #dest #rooks) or whether the destination square is two steps away from the King (match #dest #badCannon).

With the following code:

set partners (b2 k2 b13 k13 a2 l2 a13 l13); // 'rook' locations for castling set badCannon (e2 i2 e13 i13); def BadZone match #locust #partners and cond match #locust #rooks match #dest rooks match #dest #badCannon =O =dest =locust =D =P; set zonal true;

I'm getting this error:

213 if #zonal 214 verify not fn BadZone #orisqr #destsqr #locustsqr #dropsqr #unload 215 endif

at line 214

I see no definition for 'rooks' in the code you posted. It could be that it doesn't like that. Another problem could be the case where 'locust' is 'undefined' (as it might be for most moves). I don'tknow how the match operator handles that. If there still is an error after defining rooks, try to insert an extra

#locust and

Directly after

def BadZone

This might make the code more efficient anyway, because it would never get to the match parts (which might be expensive) for moves other than castling or e.p..

You mean like this:

set partners (b2 k2 b13 k13 a2 l2 a13 l13); // 'rook' locations for castling

set rooks (b2 k2 b13 k13);

set badCannon (e2 i2 e13 i13);

def BadZone #locust and match #locust #partners and cond match #locust #rooks match #dest rooks match #dest #badCannon =O =dest =locust =D =P;

set zonal true;

?

Yes, isn't that what I wrote in the first place?

Oh, this is not what I meant. I have edited my previous comment.

The thing is that I'm getting the same error!

Well, GAME-code doesn't excell in clarity of error messages. So we have to figure out what the problem is by trial and error. For this purpose we will start with a very simple definition of BadZone, and gradually increase its complexity to see how far we get. Start with:

def BadZone false =O =dest =locust =D =P;

This should allow everything, including 2-, 3- and 4-step castling with both Cannon and Rook. Then try:

def BadZone #locust =O =dest =locust =D =P;

This should not allow any castling or e.p. capture. Then:

def BadZone #locust and match #locust #partners =O =dest =locust =D =P;

This should now also allow e.p. capture, but all castlings would still be forbidden. Then:

def BadZone #locust and match #locust #partners and match #dest #badCannons =O =dest =locust =D =P;

This should allow everything except 2-step castlings.

None of them gave an error, but with the last one when I tried to castle 3 squares with the rook, the king was in it's proper place but instead of the rook, the cannon was moved by the king and the rook got totally deleted.

That is not as it is supposed to be. But since this is one of the moves that we want to outlaw, we don't have to worry about that now. Your test results suggest that the error was caused by #locust being undefined for non-castling, non-e.p. moves, and that the match operator doesn't like having an undefined first operand. Starting the BadZone definition with #locust and intercepts that case before it gets fed to the match operator.

This is the definition that should exactly do what you want, then:

def BadZone #locust and match #locust #partners and cond match #locust #rooks match #dest #rooks match #dest #badCannon =O =dest =locust =D =P;

There is no error now but the short 3 squares castle with the rook still deletes the rook while jumping the cannon over the king!

OK, I see what the problem is. The way the Play-Test Applet generated GAME-code for the King's castling moves that you specified, will lead to the 3-step moves of the King appearing twice in the legdefs array. Once for the Rook, and once for the Cannon castling. The code in the included betza.txt does not need that (because each specified castling step would automatically work with any partner spesified in the 'partners' array), and is in fact not resitant to that. When it gets the first match with the input move (which it supposes to be the only match), it already executes the 'locust capture', in this case the removal of the Rook. When it tries the same King step again, and thus again gets a match with the input move, the Rook is gone, and the Cannon is the closest piece. (And then also removed, and remembered as piece to drop next to the King.)

Easiest way to fix this is to clip the duplicat definition of the 3-step castlings (which luckily happen to be the last two moves of the King) off the move list, by changing a 2 in a 0 (at the start of the commented line). Like

1  1  0  1     3 // king(95)
1  1  1  1     3
1  1  1  0     3
1  1  1 -1     3
1  1  0 -1     3
1  1 -1 -1     3
1  1 -1  0     3
1  1 -1  1     3
2 99  1  0    72
   1  3  0     9
2 99 -1  0    72
   1 -3  0     9
2 99  1  0    72
   1  4  0     9
2 99 -1  0    72
   1 -4  0     9
2 99  1  0   33554504
   1  2  0     9
2 99 -1  0   33554504
   1 -2  0     9
0 99  1  0   33554504 // here a 0 for the number of legs indicates no more moves follow
   1  3  0     9
2 99 -1  0   33554504
   1 -3  0     9
0

It seems we are almost there. The 4 squares to the left castling with the rook should also be suppresed.

Oh sorry, my bad. I mistakenly thought that the 4-step castlings always ended on the Rooks. But this is only true on the king-side. That means we have to define another set 'badRook' to specify where Rook castlings cannot go, different from the set that specifies where the Rooks are. (And use that in BadZone when we see the locust square is at a Rook.)

set badRook (c2 k2 c13 k13);
def BadZone #locust and match #locust #partners and cond match #locust #rooks match #dest #badRook match #dest #badCannon =O =dest =locust =D =P;

@HG,

All my tests are working. Thanks!

@HG,

It is really annoying that the imitators are traded for nothing. Maybe you can do something about this when you find the time, like when the move button is triggered the value of the imitator is updated with the average of the values of foe pieces.

Are you sure this is the problem? Because what you describe is what I already do. (That is, I set it to the weighted average of the value of all pieces, where the weight is equal to the value. This because I assume that stronger pieces will be moved more often than weak pieces. And I subtract 30% of the variation in this, because I assume the opponent will adapt his move choice to make the imitator less useful, if he can, by moving more weak pieces than he otherwise would.) When you click the 'move' header in the piece table to see the values, you will see that the imitator does have a finite weight.

The procedure could be a bit improved. (E.g. I now take the average of all pieces, while it should really just be opponent pieces. But if that would be very different the game is decided anyway. And it does not take account of an imitator's fixed moves, if it had any (e.g. if you define WfI).) But whatever flaws it has now, it should never lead to thinking the imitator is worthless.

Perhaps the problem is simply that the AI doesn't search deep enough to see that an Imitator can be easily trapped.

It is just that I remember an older discussion. Thanks for clarifications!

@HG

In all my 3 Grand Apothecary games pawns do not promote, except to other pawns. I have identified the error coming from the supply vector. It is defined like this:

set supply (P p X x); // in infinite supply

But not the other pieces that are there initially. How do I fix this as the interactive diagram works well.

And by the way, also the regular pawn is able to promote to berolina and the berolina to regular pawn. Is that fixable?

The preset will allow promotion to all captured pieces, or to a piece that is in the 'supply' set. So you should put all pieces you can promote to even when they are not yet captured in that set. The GAME-code generated by the diagram also contains an array ('promotab') that per board rank lists which pieces you could promote to on that rank. If both the normal pawn and the Berolina are in the set of allowed choices (and either have been captured or are mentioned in 'supply'), you will be allowed to select those.

A problem might be that if you allow both Pawn and Berolina as promotion choice, you don't only allow Berolina to promote to Pawn and vice versa, but you also allow Berolina and Pawn to stay themselves. Since the choice would make no sense on the last rank, where neither of these would have any moves, I suppose this is not a problem, but rather exactly what you want.

Thanks for the clarifications, HG

I think I have found a bug in the diagram below:

https://www.chessvariants.com/rules/grand-apothecary-chess-alert

The AI, while playing black, promotes to rook at rank 4 (1 being the brouhaha rank). It supposed to de able to promote to rook since the 3 rank downwards. The weird thing is that I checked it manually with the diagram and it worked fine. The trouble is only when the move button is pressed.

A problem might be that if you allow both Pawn and Berolina as promotion choice, you don't only allow Berolina to promote to Pawn and vice versa, but you also allow Berolina and Pawn to stay themselves. Since the choice would make no sense on the last rank, where neither of these would have any moves, I suppose this is not a problem, but rather exactly what you want.

I don't see the way to ban promotion of regular pawns to berolina pawns and vice versa.