Comments/Ratings for a Single Item

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.

Ah, sorry. I thought you wanted to allow both kinds of Pawns to promote to each other. But you want to exclude it. (Why would you want that, btw? It would be a nice tactical twist if it was allowed.)

I am afraid that BadZone cannot be used to veto promotions, because it does not get the promotion piece passed as a parameter. I wonder if it is worth it to implement some general solution for this problem, which can be summarized as that you want to allow the promoting pieces to refrain from promoting on some ranks, but you don't want to allow them to promote to each other. Adding their types to the possible promotion choices for that rank then would not work. It would be nice if a special symbol like 'self' could be added to the set of choices to indicate the type of the moving piece. I will think about it.

And you are right about the other thing: the AI of the Diagram appears to ignore the promotion restrictions.

Thanks, HG!

@HG,

On the previous rank the promoting pawn basically has a sergeant power (fWfA). This is to difficult to stop in my opinion.

I now implemented the 'self option' in the betza.txt include file:

Just remove the p and x from all the sets in the promotab, and replace it by the word self. (Always lower case, even in the sets of white pieces.) If this word is in the set the piece name of the moving piece will be added to the choices before further processing. This way you prevent there will be an x in the set when the mover is a p, or a p in the set when the mover is an x.

Perhaps you can test this; I did not test it myself, but it was a very simple change.