Comments/Ratings for a Single Item

You could just use O-O for everything along with the king's destination square, like O-O b1

You could.  But, at that point, I would ask what value the "O-O" is bringing.  Wouldn't the more standard "e1b1" also accomplish that?  Although, I guess this would address the issue with (e.g., Wildebeest Chess) where the King can move a single space and still castle.  Perhaps if either "O-O" or "O-O-O" is followed by the notation of a square, it would mean castling to that square (and there would be no difference between "O-O" and "O-O-O")

You could just use O-O for everything along with the king's destination square, like O-O b1. If you want to preserve O-O-O, it could be understood as referring to the left half of the board from White's perspective, while O-O refers to the right half.

I don't think the O-O, O-O-O thing scales very well. What about games with an odd number of files and the King starts in the middle?

I have somewhat of a dilemma concerning the move notation for castling in the Interactive Diagram. Normally King-side castling is O-O, Queen-side castling is O-O-O, both for white and black. This then corresponds to short and long castling, respectively.

But what if the Kings start closer to the a-file? Would it still make sense to keep calling the a-side the Queen side, and use O-O-O for that castling. I know that the official notation for Chess960 does this, but that is really another case, because the King there can start anywhere, but at least ends on the c-file, like in orthodox Q-side castling. So it is indeed like a long castling, only with messed-up initial position because of the shuffling.

But what if the King in a-side castling ended on the b-file. Does it still deserve to be written as O-O-O? I encountered this problem in Elven Chess, which is unusual in that it has rotation symmetry rather than reflection symmetry in the initial setup; usually variants that have that do not have castling, but Elven Chess does. The white King starts on the f-file, and moves 3 spaces to i1 on the 10-wide board. So it would be normal to call that O-O, and the castling to c1 O-O-O.

But now what for black? His King starts on e10, and castling would bring it to b10 or h10. I would be inclined to call the castling to b10 O-O now, not O-O-O.

Any ideas what we should elevate to standard here?

Thank you H.G., that's how it will be for sure. Sounds to me like from another star. It means to me that I will not be able to do it on my own.

In addition to defining normal chess, but without normal promotion (maxPromote=0), you would have to embed a JavaScript function WeirdPromotion that would promote every piece (except King) to the type that belongs to the destination square.

What can be done to play the game Avatar Chess online?

Ok, I'll try it

I thought the changes I made on August 1 fixed that? As long as the game you try to past is legal and unambiguous, of course.

Hello, HG

Have you made any progress with the saving and loading in the interactive diagrams?

While it is certainly possible to make illegal moves in the Diagram, this cannot be the full explanation. Because the Diagram would also see that move is ambiguous during generation of the notation, and then would disambiguate it. So when I move that Kangaroo to i10 in the position where the loading of the game stops, it adds the move Ghi10 to the game, rather than Gi10. It constructs the notation such that its parser can always read it back unambiguously. It will even allow different piece types to have the same piece ID, and will already add disambiguators if two pieces with the same ID can go to the same square. (This can be useful when you implement location-dependent moving by defining different types to be used in different locations for what is shown as the same piece.) A slight difference with standard notation in orthodox Chess is that it disambiguates based on pseudo-legality only, and won't rule out alternative moves just because they expose you to check. This because not all variants do have a checking rule.

With the G move it could mean that I have personally made an illegal move! Sorry for that

OK, I found (and corrected) two problems in the Diagram script. When I added the possibility to include comments (enclosed in braces) in a pasted game some time ago, I had broken the reading of the shuffle specifier at the start of the game (which is also in braces). That was not the only problem, however: when the Diagram of a shuffle game is first shown, it displays as the 'nominal position', without any shuffling. But the initial value of the random seed used for shuffling (123456789) does not correspond to 'no shuffling'. But it was saved with the game. And if the game then was pasted back it was taken seriously, and the corresponding shuffle was executed. For now I solved this by suppressing shuffling if the random seed is 123456789.

I think this should solve all problems in the Diagram script. (Be sure to flush your browser cash or you would keep using the old script!) But there still is a problem with the games you posted: if I paste the 'alert' game into the Diagram on your alert page, it complains that Gi10 is an illegal move. And as far as I can tell, it indeed is one: G means Kangaroo there, which is defined as HFD, and  it starts (unshuffled) at h12. So Gi10 is an N jump. Since there is another Kangaroo on the board, and the specified destination square is illegal for both, it has no idea which of the two should move there, and throws up an 'ambiguous illegal move' error.

And probably the same goes for the other two games!

OK, I see. When I only paste the first Pawn moves, it works. As soon as I include 4... Gi10 in the alert version it throws up a popup complaining about an illegal move. When I include the number between braces it ignores the pasting entirely.

I suspect that there is something wrong setting up the position, since these are shuffle games. I will have a look at this.

I have copied a non finished game from my each grand apothecary diagrams. I have put it in a notepad text file. I am trying to copy it back but it does not work with edge. Firefox does give me that error though. Look try it for yourself:

The alert game:

{123456789} 1. f7 i8 2. h6 h8 3. f6 g9 4. e7 Gi10 5. Nf5 Ni9 6. Gi6 Mi12 7. Ic6 Vk7 8. Ixi12 Gxi12 9. Jh4 Oj9 10. Gg6 Vk8 11. i6 Vk9 12. Oc6 d10 13. i7 Wk10 14. ixh8 Wxh8 15. Gj6 Oh9 16. Gj8 Vj9 17. Wk5 Oxc6 18. Xxc6 We6 19. Jxe6 Vxj8 20. Nh4 Ij9 21. Je4 Gi10 22. Bg6 Ik8 23. Wxi8 Gxi8 24. k7 Vl9 25. Jxi8 Fk9 26. Vj6 Fxg6 27. Uxg6 Ii10 28. Vj8 Vxj8 29. Jxi9 Nh11 30. Jxh11 Qxh11 31. kxj8 Ixf7 32. Uxf7 Yxf7 33. Ne5 Ye9 34. Jxa12 Jxa12 35. Fj7 Bxj5 36. Rlk3 g10 37. Rk8 Ff9 38. Fb6

The classic game:

{123456789} 1. f7 i8 2. h6 h8 3. f6 g9 4. e7 Ek10 5. Nf5 Ne10 6. i7 Yh9 7. ixh8 gxh8 8. Uxh8 Bg9 9. Ui9 Hh11 10. Ng7 Yi11 11. Hh4 Yg10 12. Uj8 Eh10 13. Ul9 Ei9 14. Uh5 Yc8 15. Ee4 Ya7 16. Fd5 f8 17. exf8 Bxf8 18. Fb7 Bd6 19. Le5 Bxe5 20. dxe5 Nd8 21. Fd5 Le10 22. Hj6 Lf10 23. Nh9 Eh10 24. Nxf10 exf10 25. Uxk11 Ii12 26. Xd7 Fi10 27. Uxi12 Jxi12 28. Xxd8 Fxj6 29. Xxj6 d9 30. Ni5 Uk10 31. Eeh4 Je11 32. Je4 Ng9 33. f8 Ni6 34. Exi6 Bxi6 35. j5 Bk8 36. l7 Ff9 37. Rab3 Yb9 38. Txk8

The modern game:

{123456789} 1. f7 i8 2. h6 h8 3. f6 g9 4. e7 Ci10 5. Nef5 Nh9 6. Je4 Sh11 7. Jf4 d9 8. i5 Nee9 9. Sh4 We10 10. g6 Si11 11. Wh5 Wd7 12. Jd5 Wc8 13. Je4 Wd7 14. Sg5 Wxe4 15. Dxe4 Nk9 16. Dxd9 Cd10 17. Da8 b9 18. Db6 Nc8 19. Dc7 Shf9 20. Dd5 Yb11 21. Si4 Sk8 22. Xi7 Sj7 23. Xxi8 Sxg5 24. Nxg5 Nxi8 25. h7 Nk9 26. b7 Nb10 27. We6 Sg10 28. Xc6 Yh9 29. Ya6 Yj8 30. Nh4 e10 31. Nhi6 Yh9 32. Fc7 Sh11 33. Ck5 b8 34. Fg8 Te11 35. Lh4 Ni7 36. Yh3 f9 37. Fi8 Xi9 38. Cxi7

I don't think this can be the problem. But you will have to be more specific about what exactly you do, and what exactly then doesn't work. When I use Edge with the example Diagram for Capablanca in the Interactive Diagrams article, play f4, f5, open the AI bar, copy the game displayed at the bottom of it, reload the page so that I get a fresh Diagram, and then paste the game back, it advances both f-Pawns. I can then play Nh3, and it replies with e5. That is all exactly as it should be.

It works a bit with Firefox, but the joker gives an ambiguous move error!

Well HG, for me it does not work. I use edge. Can this be the problem?

Yes it can, and you should be able to continue it in that case. Either by making a move, or pressing the Move button.

Can it be a non finished game?

There is no real save function. Under the buttons in the AI bar there is a text box where the game record will appear, and you can copy-paste that to a place where you want to store it. You can paste such a game back into that same text box to load it into the Diagram again.

I remember there being a way to save and load games for the interative diagram. I cannot find where. Any ideas of how to do it?

Refresh your browser cache (Shift + reload on FireFox), or you would still be using the old Diagram script.

The immobilizer works for me when moving pieces around, but not when playing against the AI.

Indeed, it would not make sense to use this in a FIDE context. But it might fit in with the Tenjiku-Shogi crowd. After all, getting paralyzed is not nearly as bad as getting burned.

Seems to work. What a mighty piece!

This is a test for how to implement immobilizers with the Interactive Diagram, through a user-supplied function BadZone(). The Queen here immobilizes all adjacent enemy pieces.

This was already possible before, by having the function BadZone() examine all board squares adjacent to the origin of the move, and vetoing the move (by returning non-zero) when an enemy immobilizer was found there. This was quite inefficient, though, as it would be done for every potential move of the immobilized piece.

I now changed the Diagram Script such that BadZone() can remember the result of any test it does in a variable 'frozen', set to -1 whenever move generation for a new piece starts. So that it can get the result of a previous test for the same piece from there, rather than redoing the test. And by setting frozen = 100 it can even abort generation of moves for the current piece altogether.

I see your point, HG. You are probably correct but I'll do it my way. It can't really hurt. Unless I blunder a bug anyway.

I understand that, but that is not a reason for allowing your opponent to promote, anymore than you would let him capture one of your Bishops with a Pawn (which would also give him a Bishop for a Pawn, if the Bishop was protected). In real games there never are any promotions 'early in the game'. At least not any where the promoted piece is allowed to survive. And there certainly will not be more than two. So if you want a Bishop to be available early in the game for the one-in-a-million case that someone would be allowed to promote and would want one, you might as well make it available in unlimited supply. How many games would have more than 2 promotions in total anyway? Usually the first promotion decides the game.

This game, like Gross chess has promotion limited by rank. Bishops are easier to promote earlier in the game.

I am not sure why you would even bother to limit the number of Bishop promotions to 2 (if the original Bishops are still present). Like anyone would ever want to promote to Bishop... In practice promotions would never occur when there still are enough super-pieces around to prevent them. So even with promotion to captured pieces only there would always be something much better than a Bishop available. It is quite inconceivable that the opponent would have blundered away so many pieces that he can no longer stop promotion, while you would not have lost a single piece better than a Bishop.

So it seems a totally useless rule. Even when you would grant an infinite supply of Bishops, no one would ever want to use one. Let alone 3.

Well I can manipulate the captured pieces array. I did that before! Thanks!

You cannot. The supply array is for indicating what piece types are in infinit supply. If a piece is not in there you can only promote to it when it was captured.

But how do I put 2 bishops in the supply array?

OK, Thanks

Sorry, I managed to produce a bug in this simple change after all, swapping the arguments of a GAME-code 'push' instruction. Now it should work, and I actually tested it on one of your presets.

BTW, the numbers you put in the supply array are meaningless. But they do not hurt.

No, it does not work with (P 10 p 10 X 10 x 10) nor with (P p X x)

Oh yes, I forgot to tell that. The rule that you cannot promote to pieces that are not captured and not in the supply array remains applicable. So it should allow 'promotion to self' if a pawn of that type was already captured, but this is probably not the way you tested it. So add p and x to the supply array.

It seems that staying a pawn does not work. Is that because the self pieces do not appear in the supply array?

@HG There is also a peculiar situation in the Grand Apothecary chess games given by the brouhaha squares. Technically pawns should not reach there and that is easily done by adjusting the promotab so that you are forced to promote before reaching the brouhaha squares. But I'm not sure how easy it is for the interactive diagram.

That is great. I'll be testing it soon!

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.

@HG,

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

Thanks, HG!

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.

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.

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.

Thanks for the clarifications, HG

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.

@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?

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

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.

@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.

@HG,

All my tests are working. Thanks!

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;

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

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

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!

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;

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.

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.

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

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

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

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;

?

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

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 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).

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.

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.

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

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.

@HG,

In these games:

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+1&settings=Applet

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+2&settings=Applet

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+3&settings=Applet

castling is supposed to work like described here:

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

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

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

but it does not. It just give fast castling with the rook. I see that this line:

set partners (b2 k2 b13 k13);

should contain the cannons initial position also. That is easy to solve. But I have no idea about the fast castling. May you help me with making the necessary modifications?

Well, actually it doesn't, because I messed up. One should not test pieceType (which will always be 14 at this point), but imi, to decide which moves to forbid. In addition, I tested for a full square, rather than an empty. The following routine should work: it first declares OK all non-imitator moves, all imitations of non-pawns, and all moves to occupied squares. At that point only non-capture pawn imitations are left, and advances of more than 1 rank can be flagged as illegal. finally it tests for e.p. depending on which pawn type is imitated.

    function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) {
      if(pieceType != 14) return 0;
      if((imi & 511) > 2) return 0;
      if(board[toRank][toFile] & 511) return 0;
      if(fromRank > toRank + 1 || fromRank < toRank - 1) return 1; 
      if(imi == 1) return (toFile != fromFile);
      return (toFile == fromFile);
    }

It works well, HG, Thank you and a happy new year.

No, ther can be only one function BadZone, which must detect all moves you want to forbid, and return true (non-zero) for those (and false or 0 for the others). So you have to put this in BadZone just before the final return statement (which would otherwise return 'false', because in e.p. capture you only advance one rank)

This should be in another function BadZone2 for example, isn't it?

Promotion is done based on the piece type, so if the Joker is not amongst the promotable pieces, it will not promote. Only moves are immitated.

Because you have two different kinds of Pawns the test for it becomes complicated. In any case the destination square must be empty. But then for normal Pawns diagonal moves must be excluded, and for Berolinas the straight moves. So omething like

if(board[toRank][toFile] & 511) {
  if(pieceType == 1) return (toFile != fromFile);
  if(pieceType == 2) return (toFile == fromFile);
}

This is done. It works correctly. What about enpassant and promotion?

OK, the problem obviously is that 'imi' is not defined. I am pretty sure I uploaded the version that updates 'imi' also on user moves yesterday, but it turns out the old version was still on the CVP website. So somehow th upload must have failed. I now uploaded it again, and this fixes the problem. You can remove the document... line from the BadZone function now.

I get these errors, after a few moves:

BadZone(3,3,1,0,undefined,3) imi =undefined BadZone(3,4,1,0,undefined,3) imi =undefined BadZone(3,5,1,0,undefined,3) imi =undefined BadZone(3,6,1,0,undefined,3) imi =undefined BadZone(3,4,1,0,undefined,3) imi =undefined BadZone(3,5,1,0,undefined,3) imi =undefined BadZone(3,6,1,0,undefined,3) imi =undefined BadZone(1,4,1,0,undefined,1) imi =undefined BadZone(1,5,1,0,undefined,1) imi =undefined BadZone(1,6,1,0,undefined,1) imi =undefined BadZone(4,4,1,0,undefined,4) imi =undefined BadZone(4,5,1,0,undefined,4) imi =undefined BadZone(4,6,1,0,undefined,4) imi =undefined BadZone(7,4,1,0,undefined,7) imi =undefined BadZone(7,5,1,0,undefined,7) imi =undefined BadZone(7,6,1,0,undefined,7) imi =undefined BadZone(8,4,1,0,undefined,8) imi =undefined BadZone(8,5,1,0,undefined,8) imi =undefined BadZone(8,6,1,0,undefined,8) imi =undefined BadZone(10,4,1,0,undefined,10) imi =undefined BadZone(10,5,1,0,undefined,10) imi =undefined BadZone(10,6,1,0,undefined,10) imi =undefined BadZone(5,5,1,0,undefined,5) imi =undefined BadZone(5,6,1,0,undefined,5) imi =undefined BadZone(6,5,1,0,undefined,6) imi =undefined BadZone(6,6,1,0,undefined,6) imi =undefined BadZone(3,3,0,0,undefined,3) imi =1073741825 BadZone(3,6,1,0,undefined,3) imi =1073741825 BadZone(5,9,1,1024,undefined,5) imi =1073741825 BadZone(5,8,1,1024,undefined,5) imi =1073741825 BadZone(5,7,1,1024,undefined,5) imi =1073741825 BadZone(5,8,1,1024,undefined,5) imi =1073741825 BadZone(5,7,1,1024,undefined,5) imi =1073741825 BadZone(6,8,1,1024,undefined,6) imi =1073741825 BadZone(6,7,1,1024,undefined,6) imi =1073741825 BadZone(1,9,1,1024,undefined,1) imi =1073741825 BadZone(1,8,1,1024,undefined,1) imi =1073741825 BadZone(1,7,1,1024,undefined,1) imi =1073741825 BadZone(3,9,1,1024,undefined,3) imi =1073741825 BadZone(3,8,1,1024,undefined,3) imi =1073741825 BadZone(3,7,1,1024,undefined,3) imi =1073741825 BadZone(4,9,1,1024,undefined,4) imi =1073741825 BadZone(4,8,1,1024,undefined,4) imi =1073741825 BadZone(4,7,1,1024,undefined,4) imi =1073741825 BadZone(7,9,1,1024,undefined,7) imi =1073741825 BadZone(7,8,1,1024,undefined,7) imi =1073741825 BadZone(7,7,1,1024,undefined,7) imi =1073741825 BadZone(8,9,1,1024,undefined,8) imi =1073741825 BadZone(8,8,1,1024,undefined,8) imi =1073741825 BadZone(8,7,1,1024,undefined,8) imi =1073741825 BadZone(10,9,1,1024,undefined,10) imi =1073741825 BadZone(10,8,1,1024,undefined,10) imi =1073741825 BadZone(10,7,1,1024,undefined,10) imi =1073741825 BadZone(5,7,1,0,undefined,5) imi =1073742849 BadZone(5,9,0,0,undefined,5) imi =1073742849 BadZone(4,3,1,0,undefined,4) imi =1073742849 BadZone(4,4,1,0,undefined,4) imi =1073742849 BadZone(4,5,1,0,undefined,4) imi =1073742849 BadZone(4,6,1,0,undefined,4) imi =1073742849 BadZone(4,4,1,0,undefined,4) imi =1073742849 BadZone(4,5,1,0,undefined,4) imi =1073742849 BadZone(4,6,1,0,undefined,4) imi =1073742849 BadZone(1,4,1,0,undefined,1) imi =1073742849 BadZone(1,5,1,0,undefined,1) imi =1073742849 BadZone(1,6,1,0,undefined,1) imi =1073742849 BadZone(7,4,1,0,undefined,7) imi =1073742849 BadZone(7,5,1,0,undefined,7) imi =1073742849 BadZone(7,6,1,0,undefined,7) imi =1073742849 BadZone(8,4,1,0,undefined,8) imi =1073742849 BadZone(8,5,1,0,undefined,8) imi =1073742849 BadZone(8,6,1,0,undefined,8) imi =1073742849 BadZone(10,4,1,0,undefined,10) imi =1073742849 BadZone(10,5,1,0,undefined,10) imi =1073742849 BadZone(10,6,1,0,undefined,10) imi =1073742849 BadZone(5,5,1,0,undefined,5) imi =1073742849 BadZone(5,6,1,0,undefined,5) imi =1073742849 BadZone(6,5,1,0,undefined,6) imi =1073742849 BadZone(6,6,1,0,undefined,6) imi =1073742849 BadZone(3,7,1,0,undefined,3) imi =1073742849 BadZone(4,3,0,0,undefined,4) imi =1073741825 BadZone(4,6,1,0,undefined,4) imi =1073741825 BadZone(6,9,1,1024,undefined,6) imi =1073741825 BadZone(6,8,1,1024,undefined,6) imi =1073741825 BadZone(6,7,1,1024,undefined,6) imi =1073741825 BadZone(6,8,1,1024,undefined,6) imi =1073741825 BadZone(6,7,1,1024,undefined,6) imi =1073741825 BadZone(5,6,1,1024,undefined,5) imi =1073741825 BadZone(4,6,1,1024,undefined,4) imi =1073741825 BadZone(1,9,1,1024,undefined,1) imi =1073741825 BadZone(1,8,1,1024,undefined,1) imi =1073741825 BadZone(1,7,1,1024,undefined,1) imi =1073741825 BadZone(3,9,1,1024,undefined,3) imi =1073741825 BadZone(3,8,1,1024,undefined,3) imi =1073741825 BadZone(3,7,1,1024,undefined,3) imi =1073741825 BadZone(4,9,1,1024,undefined,4) imi =1073741825 BadZone(4,8,1,1024,undefined,4) imi =1073741825 BadZone(4,7,1,1024,undefined,4) imi =1073741825 BadZone(5,9,1,1024,undefined,5) imi =1073741825 BadZone(5,8,1,1024,undefined,5) imi =1073741825 BadZone(7,9,1,1024,undefined,7) imi =1073741825 BadZone(7,8,1,1024,undefined,7) imi =1073741825 BadZone(7,7,1,1024,undefined,7) imi =1073741825 BadZone(8,9,1,1024,undefined,8) imi =1073741825 BadZone(8,8,1,1024,undefined,8) imi =1073741825 BadZone(8,7,1,1024,undefined,8) imi =1073741825 BadZone(10,9,1,1024,undefined,10) imi =1073741825 BadZone(10,8,1,1024,undefined,10) imi =1073741825 BadZone(10,7,1,1024,undefined,10) imi =1073741825 BadZone(6,7,1,0,undefined,6) imi =1073742849 BadZone(6,9,0,0,undefined,6) imi =1073742849 BadZone(4,2,8,0,undefined,4) imi =1073742849 BadZone(4,5,8,0,undefined,4) imi =1073742849 BadZone(3,3,8,0,undefined,3) imi =1073742849 BadZone(4,4,8,0,undefined,4) imi =1073742849 BadZone(4,5,8,0,undefined,4) imi =1073742849 BadZone(3,3,8,0,undefined,3) imi =1073742849 BadZone(4,4,8,0,undefined,4) imi =1073742849 BadZone(7,5,8,0,undefined,7) imi =1073742849 BadZone(7,4,8,0,undefined,7) imi =1073742849 BadZone(4,2,0,0,undefined,4) imi =1073741832 BadZone(4,5,8,0,undefined,4) imi =1073741832 BadZone(5,10,1,1024,undefined,5) imi =1073741832 BadZone(5,9,1,1024,undefined,5) imi =1073741832 BadZone(5,8,1,1024,undefined,5) imi =1073741832 BadZone(5,9,1,1024,undefined,5) imi =1073741832 BadZone(5,8,1,1024,undefined,5) imi =1073741832 BadZone(5,6,1,1024,undefined,5) imi =1073741832 BadZone(4,6,1,1024,undefined,4) imi =1073741832 BadZone(6,6,1,1024,undefined,6) imi =1073741832 BadZone(1,9,1,1024,undefined,1) imi =1073741832 BadZone(1,8,1,1024,undefined,1) imi =1073741832 BadZone(1,7,1,1024,undefined,1) imi =1073741832 BadZone(3,9,1,1024,undefined,3) imi =1073741832 BadZone(3,8,1,1024,undefined,3) imi =1073741832 BadZone(3,7,1,1024,undefined,3) imi =1073741832 BadZone(4,9,1,1024,undefined,4) imi =1073741832 BadZone(4,8,1,1024,undefined,4) imi =1073741832 BadZone(4,7,1,1024,undefined,4) imi =1073741832 BadZone(6,9,1,1024,undefined,6) imi =1073741832 BadZone(6,8,1,1024,undefined,6) imi =1073741832 BadZone(7,9,1,1024,undefined,7) imi =1073741832 BadZone(7,8,1,1024,undefined,7) imi =1073741832 BadZone(7,7,1,1024,undefined,7) imi =1073741832 BadZone(8,9,1,1024,undefined,8) imi =1073741832 BadZone(8,8,1,1024,undefined,8) imi =1073741832 BadZone(8,7,1,1024,undefined,8) imi =1073741832 BadZone(10,9,1,1024,undefined,10) imi =1073741832 BadZone(10,8,1,1024,undefined,10) imi =1073741832 BadZone(10,7,1,1024,undefined,10) imi =1073741832 BadZone(5,8,1,0,undefined,5) imi =1073742849 BadZone(5,10,0,0,undefined,5) imi =1073742849 BadZone(4,1,18,0,undefined,4) imi =1073742849 BadZone(3,3,18,0,undefined,3) imi =1073742849 BadZone(2,5,18,0,undefined,2) imi =1073742849 BadZone(1,7,18,0,undefined,1) imi =1073742849 BadZone(0,9,18,0,undefined,0) imi =1073742849 BadZone(3,3,18,0,undefined,3) imi =1073742849 BadZone(2,5,18,0,undefined,2) imi =1073742849 BadZone(1,7,18,0,undefined,1) imi =1073742849 BadZone(0,9,18,0,undefined,0) imi =1073742849 BadZone(4,1,0,0,undefined,4) imi =1073741842 BadZone(1,7,18,0,undefined,1) imi =1073741842 BadZone(6,10,1,1024,undefined,6) imi =1073741842 BadZone(6,9,1,1024,undefined,6) imi =1073741842 BadZone(6,8,1,1024,undefined,6) imi =1073741842 BadZone(6,9,1,1024,undefined,6) imi =1073741842 BadZone(6,8,1,1024,undefined,6) imi =1073741842 BadZone(5,6,1,1024,undefined,5) imi =1073741842 BadZone(4,6,1,1024,undefined,4) imi =1073741842 BadZone(6,6,1,1024,undefined,6) imi =1073741842 BadZone(1,9,1,1024,undefined,1) imi =1073741842 BadZone(1,8,1,1024,undefined,1) imi =1073741842 BadZone(3,9,1,1024,undefined,3) imi =1073741842 BadZone(3,8,1,1024,undefined,3) imi =1073741842 BadZone(3,7,1,1024,undefined,3) imi =1073741842 BadZone(4,9,1,1024,undefined,4) imi =1073741842 BadZone(4,8,1,1024,undefined,4) imi =1073741842 BadZone(4,7,1,1024,undefined,4) imi =1073741842 BadZone(7,9,1,1024,undefined,7) imi =1073741842 BadZone(7,8,1,1024,undefined,7) imi =1073741842 BadZone(7,7,1,1024,undefined,7) imi =1073741842 BadZone(8,9,1,1024,undefined,8) imi =1073741842 BadZone(8,8,1,1024,undefined,8) imi =1073741842 BadZone(8,7,1,1024,undefined,8) imi =1073741842 BadZone(10,9,1,1024,undefined,10) imi =1073741842 BadZone(10,8,1,1024,undefined,10) imi =1073741842 BadZone(10,7,1,1024,undefined,10) imi =1073741842 BadZone(6,8,1,0,undefined,6) imi =1073742849 BadZone(6,10,0,0,undefined,6) imi =1073742849 BadZone(4,0,14,0,undefined,4) imi =1073742849 BadZone(4,1,14,0,undefined,4) imi =1073742849 BadZone(4,2,14,0,undefined,4) imi =1073742849 BadZone(4,3,14,0,undefined,4) imi =1073742849 BadZone(4,4,14,0,undefined,4) imi =1073742849

OK, so the routine is in fact called. Try the following. Below the script add a place where we can print debug output:

<p id="debug"></p>

Then inside the BadZone routine add a line

document.getElementById("debug").innerHTML += 'BadZone(' + toFile + ',' + toRank + ',' + pieceType + ',' + color + ',' + fromFile + ',' + toFile + ') imi =' + imi + '<br>';

Then we can get an impression of what goes wrong.

Is there a mail of yours where I can send my password to you, so you can work on it? Then after you are done I just change the password.

When I had put return 1 all moves where indeed suppressed.

I can confirm that the BadZone function has no effect in the page at the link you gave. The weird thing is that when I ask the page source of that page, copy the Diagram in it to a local HTML page on my own computer, and open it in the browser, the distant moves do get suppressed. I have no idea why it doesn't work on your page. If I look in the browser console I do not get any error messages from the JavaScript on your page.

The problem is that I cannot experiment on your page; only you have access to it. This is why I copied to my own computer, but the copy shows no errors, so there is nothing to debug. Perhaps you can try the following: add as a first line in the BadZone routine the line

return 1;

This should suppress every move of every piece, and even prevent the highlighting of the piece itself. If that has no effect, I am pretty sure that the routine BadZone never gets called.

The longer moves are still shown. I'm not sure if the ai internally makes only 1 step moves. The enpassant and promotion rights are probably still there needing more BadZone functions, probably.

Also all these things should be done manually in the game courier generated script. Isn't that true?

OK, I found the problem. It turns out that the variable 'imi' was copied directly from the board, where it also contains color and highlighting information, besides the piece type. So these bits have to be stripped first by taking (imi & 511) to be left with the type. I suppose I should change the Diagram script to already do this by itself when storing imi, rather than when using it. For now you can fix it by using

  <script>
    function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) {
      if(pieceType != 14) return 0;
      if((imi & 511) > 2) return 0;
      return (fromRank > toRank + 1 || fromRank < toRank - 1);
    }
  </script>

This also fixes the problem that the highlighting function is also called to highlight the selected piece itself (so that fromRank equals toRank), and we don't want to suppress that. So I changed the test for suppressing only moves of more than 1 rank.

Note that it still wouldbe able to e.p. capture when imitating a pawn.

These are the articles in question:

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

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

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

Any of them would do.

Well, that looks OK. If you would post a link to the page where you have it, I could have a look at it, and maybe we could have some progress...

I have the following script, without any result:

function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) { if(pieceType != 14) return 0; if(imi != 1 && imi != 2) return 0; return (fromRank != (color ? toRank + 1 : toRank - 1)); }

No, it does not. It is not in the table. (In fact the Diagram uses piece type = 250 for holes internally.) The Diagram should be put on the HTML page that contains the Diagram. It should not matter where. There is no way to relate the script to a specific Diagram, however. So if there are more than a single Diagram on the same page, they will all use the BadZone function defined in the script.

I could not figure out where to put the bad zone script. It does not work yet it seems, even if with the proper modifications. Another thing that I am in doubt is if the hole piece count towards piece number. I assumed it does!

Wow H.G.,

Thanks!

I thought that was it!

Well, the idea was not to change any piece types, but detect whether the generated move was for an imitator imitating a pawn, and in that case forbid the move (by returning a non-zero value) when it advanced more than one rank. This was not so easy, though, because BadZone did not get the coordinates of the origin square passed to it, and it was not obvious what the imitator was imitating.

I did change the Diagram script now to make this easier: the variable 'imi' now contains the imitated piece at all times during the game, not just when the AI is thinking. And the square of origin are passed as extra parameters to BadZone. (Refresh the browser cache!) This should make the following script so what you want:

<script>
function BadZone(toFile, toRank, pieceType, color, fromFile, fromRank) {
  if(pieceType != NUMBER_OF_JOKER) return 0;
  if(imi != NUMBER_OF_PAWN) return 0;
  return (fromRank != (color ? toRank + 1 : toRank - 1));
}
</script>

(Replace the NUMBER_OF_... by the actual numbers your pieces have in your table.)

HG, I don't understand the bad zone script. How it would work. The way I see it the specific instructions to be added here would be something like: if lastMoved is pawn then imitate barren pawn. if lastMoved is berolina then imitate barren berolina.

The barren pieces pieces could be added in the diagram but not used in the initial setup.

But I don't think the interactive diagram supports lastMoved as the game courier supports it. It seems I'm screwed with this one!

The Diagram does not support 'partial imitators', which can only imitate a subset of the pieces, or of the moves of some of the pieces. I suppose it would be possible to exploit the possibility to veto unwanted moves through a user-supplied JavaScript function BadZone.

I had to do something similar to this to get it working in ChessV.  A basic imitator rule will, of course, imitate all moves.  It requires extra code to stop it from imitating this.  Also, the Joker imitating a pawn cannot capture en passant even if a pawn could do so.  Fortunately, this did not require extra code for me just because of the way en passant is implemented as a rule and not a movement capability.

The Diagram does not support 'partial imitators', which can only imitate a subset of the pieces, or of the moves of some of the pieces. I suppose it would be possible to exploit the possibility to veto unwanted moves through a user-supplied JavaScript function BadZone. Originally this feature was created for confining pieces to part of the board as  in Xiangqi. It could be used to veto moves for any reason, though. Problem in this case is that the routine should know which piece the imitator is imitating, because you don't want to veto distant forward moves when it is imitating a Rook. The Diagram keeps track of that in a variable that is accessible from the routine. But it is a different variable in case of a move in the game from when the AI is thinking.

Hello HG, While testing the interactive diagram on grand apothecary chess alert I have noticed that the joker imitating a berolina pawn has moved 5 spaces. This is probably because the berolina pawn is defined like this mfF*fceW and that means the joker inherited the ability to move as much as to the center of the board. But the rules of the games, as I had made them state : "A joker imitating a pawn has only the regular moves, no double step, no enpassant and no promotion even if that pawn has promoted the last move."

In the game courier I had created a special case for when the joker imitates a pawn to get the moves of a fictious barren pawn that does not promote, and gets no double steps or en passat. But I don't think that can be done here. Can it?

Here is the game that led to this situation:

{770295349} 1. f7 Xi8 2. e6 Wb10 3. d5 Wk10 4. Bd4 Ig9 5. g7 h9 6. f8 Ii7 7. Gi5 Ik9 8. f6 Uk8 9. Me4 Ig6 10. Mf4 Gd9 11. Of3 Id10 12. Wf5 Oj9 13. Wig5 Fb9 14. Xe7 Ji10

Grand Apothecary chess alert can be found here:

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