You are on the backup site for Chessvariants.com. Any posts, moves, or other changes you make here will not be permanent, because the pages and database from the main site will be backed up here every midnight EST. Additionally, things may not be working right, because this site is also a testbed for newer system software. So, if you are not here to test, develop, or merely read this site, you may want to change .org to .com in the navigation bar and go to the main site.



The Chess Variant Pages




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Latest Ratings and Comments

Later Reverse Order EarlierEarliest
Game Courier User's Guide. How to play games with the CV Play-by-Mail system.[All Comments] [Add Comment or Rating]
Jean-Louis Cazaux wrote on 2022-06-27 UTC

I don't know if it is me, or if it happens to others too, but I confess: I don't catch nothing at all in the explanations of Time Controls. It is not a problem of English, I'm used to read complex scientific stuff in English. Maybe it is because I never played chess in official competitions and I'm lacking some notions.

I wanted to put a time limit because I've been frustrated in some recent games to see opponents stopping to play after being in a difficult situation. Doing so, they never loose. An unfair behaviour certainly, I wanted to avoid this.

So I set a time limit but frankly I don't understand at all what I have selected and the effect it may have. I just guess there is a limit somehow.


Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
Aurelian Florea wrote on 2022-06-27 UTC

@HG,

All my tests are working. Thanks!


H. G. Muller wrote on 2022-06-27 UTC

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;

Aurelian Florea wrote on 2022-06-27 UTC

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


H. G. Muller wrote on 2022-06-27 UTC

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


Aurelian Florea wrote on 2022-06-27 UTC

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!


H. G. Muller wrote on 2022-06-27 UTC

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;

Aurelian Florea wrote on 2022-06-27 UTC

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.


H. G. Muller wrote on 2022-06-26 UTC

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.


Game Courier Ratings. Calculates ratings for players from Game Courier logs. Experimental.[All Comments] [Add Comment or Rating]
Kevin Pacey wrote on 2022-06-26 UTC

@ Fergus:

I'm wondering if there is a bug in the way GC does the total rated games for individual players. For example, I just finished a drawn publicly viewable Fischerrandom game with Play Tester, yet for both his public and rated games for Fischerrandom it shows he still has perfect scores.

Also, I once tallied up my rated games for (orthodox) chess, and I was not credited for one of my drawn games, but seemed to have received a loss instead.

Kevin


Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
Aurelian Florea wrote on 2022-06-26 UTC

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


Aurelian Florea wrote on 2022-06-26 UTC

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


H. G. Muller wrote on 2022-06-26 UTC

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


Aurelian Florea wrote on 2022-06-26 UTC

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;

?


H. G. Muller wrote on 2022-06-26 UTC

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


Aurelian Florea wrote on 2022-06-26 UTC

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


Pandemonium (Surajang修羅場). Capablanca chess + Crazyhouse.[All Comments] [Add Comment or Rating]
Daphne Snowmoon wrote on 2022-06-25 UTC

The setup has changed a lot !


Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2022-06-25 UTC

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


Aurelian Florea wrote on 2022-06-25 UTC

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.


H. G. Muller wrote on 2022-06-25 UTC

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.


Aurelian Florea wrote on 2022-06-25 UTC

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


H. G. Muller wrote on 2022-06-25 UTC

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.


Aurelian Florea wrote on 2022-06-24 UTC

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


The nightrider in Grand Apothecary Chess Alert, Classic and Modern[Subject Thread] [Add Response]
Aurelian Florea wrote on 2022-06-22 UTC

@Jean-Louis

I have not designed these games for the nightriders but they seem to work ok probably because of the high board density.


Aurelian Florea wrote on 2022-06-22 UTC

Thanks for the reply Jean-Louis!


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.