improved FRC version of WinBoard_F

[hgm]

I just fixed an alpha version of WinBoard_F (4.3.13f) that should be fully FRC compatible. The previous versions had some problems when playing on ICS, in particular when resuming an adjourned game. I had never tested them for ICS play, so they only worked for engine-engine games.

The current version ( http://home.hccnet.nl/h.g.muller/alpha.tst , rename to winboard.exe) is extensively tested on ICC, and seems to correctly handle castling rights when playing, and when restoring an adjourned game.

It was a rather messy operation, as WinBoard uses entirely different mechansims (and thus code) for keeping track of a position in local play and in ICS play. Plus that ICC in general does not send correct castling rights in FRC (which was no problem in old WinBoard, as it neglects castling rights completely anyway, but became a ig problem in WinBoard_F).

I would be very grateful if people could try out the alpha.tst in normal Chess and FRC, on local engine-engine and ICS play (playing, resuming, observing other games) to see if everything works, and if I haven't broken anything.

[Charles B.]

Not related to your FRC posting but I would like to bring it to your attention.

Maybe not a major thing but when I have the Windows (chessboard, engine output and Move History) set up in Winboard_X where I want them and close the program, whenever I restart the program Winboard_X remembers where the windows were positioned when it was closed.

With Winboard_F whenever I open the program I have to move the Windows where I want them because the program doesn't remember where they were from when the program was closed.

I have only used Winboard_F for standard chess and not the variants so maybe this is something that cannot be fixed and possibly I am the only one with this Winboard_F problem.

[hgm]

Very strange. Because for me WinBoard_F behaves exactly like WinBoard_x in this respect: it remembers the window positions. Under win2k, winXP and Vista alike.

The window coordinates are saved in the winboard.ini file. It might be that your WinBoard_F has gotten in a state where it does not automatically save its settings in the .ini file on exiting. I know there is an option to suppress this saving (used by PSWBTM to make sure all games of a tourney are played with the same setting), but never used it myself. If that option is specified in the winboard.ini, rather than on the command line, you would then not get rid of it, even if it would otherwise not be saved in the .ini along with other options.

Could also be that your winboard.ini got locked by the OS and cannot be written anymore.

[adams161]

hi,

does it still use that funny notation like d1g1 for a king side castle or is giving o-o and o-o-o? there was supposedly a winboard argument to ask for o-o and o-o-o but it defaulted to true ( i.e. it should be on without the argument ) and i noticed in home play it did give o-o but in ics play it seemed to give 8 different moves to express the move ( 4 for white and 4 for black ) plus you had to write a bunch of code to figure out if something like d1g1 was meant to indicate castle or if it was really the move d1 to g1. It was a confusing mess and i still havent gotten it debugged entirely.

Mike

[Charles B.]

Very strange. Because for me WinBoard_F behaves exactly like WinBoard_x in this respect: it remembers the window positions. Under win2k, winXP and Vista alike.

I suspected since I had not read of anyone else having the problem that it was only me that was experiencing it. As I wrote previous, it isn't a major thing other than having to reposition the windows everytime the program is opened. I am not using any tournament managers and the winboard.ini isn't set to read only. A few weeks ago I did look for the settings in the winboard.ini files so that I could compare Winboard_X's with Winboard_F's but maybe due to my being dense I could not locate the settings in either versions ini file.

I am currently using Windows ME but even with that operating system Winboard_X functions o.k.


Here is a screenshot of your current version Winboard_F 4.3f.13 with the windows positioned correctly.

http://i278.photobucket.com/albums/kk11 ... /wbf01.jpg


Close the program and restart it later and the windows look like this

http://i278.photobucket.com/albums/kk11 ... /wbf02.jpg


Since in the later operating systems you mentioned Winboard_F remembers the window's positions, there is no need for you to fix what is not broken in them. I will be moving to XP sometime in the future.

I only mentioned it thinking that there might be an easy fix.

[pedrox]

hi,

does it still use that funny notation like d1g1 for a king side castle or is giving o-o and o-o-o? there was supposedly a winboard argument to ask for o-o and o-o-o but it defaulted to true ( i.e. it should be on without the argument ) and i noticed in home play it did give o-o but in ics play it seemed to give 8 different moves to express the move ( 4 for white and 4 for black ) plus you had to write a bunch of code to figure out if something like d1g1 was meant to indicate castle or if it was really the move d1 to g1. It was a confusing mess and i still havent gotten it debugged entirely.

Mike

Thx HGM,

Just a comment, so that an engine winboard can play in winboard_f FRC should support castling format HAha instead of KQkq. So perhaps you (another engines winboard) should make a small change in the funtion setboard to correct castling rights.

DanaSah ---> in arena o chessgui

Code: Select all

		if ((strcmp (gui,"arena") == 0) || (strcmp (gui,"chessgui") == 0)) {
			enroque = 0;
			c = string[i++];
			while (c == 'K' || c == 'Q' || c == 'k' || c == 'q') {
				if (c == 'K') {
					enroque = enroque + 1;
				}
				if (c == 'Q') {
					enroque = enroque + 2;
				}
				if (c == 'k') {
					enroque = enroque + 4;
				}
				if (c == 'q') {
					enroque = enroque + 8;
				}
				c = string[i++];
			}		
		}

DanaSah--> in Winboard_f

Code: Select all

		if (strcmp (gui,"winboard") == 0) {
						enroque = 0;
			c = string[i++];
			while (&#40;c >= 'A' && c <= 'H') || &#40;c >= 'a' && c <= 'h')) &#123;
				if &#40;c >= 'A' && c <= 'H') &#123;
					r = 65 + COLUMNA&#40;rb&#41;;
					if &#40;c > r&#41; &#123;
						enroque = enroque + 1;
						tb1 = c - 'A' + 56;
					&#125;
					if &#40;c < r&#41; &#123;
						enroque = enroque + 2;
						tb2 = c - 'A' + 56;
					&#125;
				&#125;
				if &#40;c >= 'a' && c <= 'h') &#123;
					r = 97 + COLUMNA&#40;rn&#41;; 
					if &#40;c > r&#41; &#123;
						enroque = enroque + 4;
						tn1 = c - 'a';
					&#125;
					if &#40;c < r&#41; &#123;
						enroque = enroque + 8;
						tn2 = c - 'a';
					&#125;
				&#125;
				c = string&#91;i++&#93;;		
			&#125;
		&#125;

Best,

Pedro

[hgm]

does it still use that funny notation like d1g1 for a king side castle or is giving o-o and o-o-o?

WB protocol prescribes all castlings in FRC to be communicated as O-O or O-O-O, and as e1g1, e8g8, e1c1 or e8c8 in other variants. For variant wildcastle even d1f1 etc. is allowed (provided the King started on d1). There is an option that forse the move to be sent to the engine in SAN, and in SAN all castlings are O-O or O-O-O in any variant. (Although it is not clear to me which means which in wildcastle.)

In WinBoard_F I will reat CRC similar to FRC, when I get to implement variant caparandom, but non-shuffled variants on 10x8 (i.e. with K on central files and R in corners) will use long algebraic (e.g. f1i1).

Internally WB uses the K captures own R encoding in FRC, but it should always be converted to O-O or O-O-O on sending the move to engine or ICS. I inherited this from the code of Tord and Fabien in WinBoard_x, and saw no reason to change it. Although I had to change their code quite a lot to make it pay attention to castling rights.

[hgm]

A few weeks ago I did look for the settings in the winboard.ini files so that I could compare Winboard_X's with Winboard_F's but maybe due to my being dense I could not locate the settings in either versions ini file.

This is the section of my winboard.ini that describes the window coordinates:

Code: Select all

/x=50
/y=41
/icsX=33
/icsY=468
/icsW=594
/icsH=260
/analysisX=-2147483648
/analysisY=-2147483648
/analysisW=-2147483648
/analysisH=-2147483648
/commentX=451
/commentY=548
/commentW=461
/commentH=193
/tagsX=145
/tagsY=581
/tagsW=259
/tagsH=162
/gameListX=90
/gameListY=233
/gameListW=397
/gameListH=276
/saveSettingsOnExit=true

Note that if you set the last option to false, it protects itself for ever...

[hgm]

Just a comment, so that an engine winboard can play in winboard_f FRC should support castling format HAha instead of KQkq. So perhaps you (another engines winboard) should make a small change in the funtion setboard to correct castling rights.

Note that you should understand BOTH the KQkq and AHah notations in the FEN reader of an engine that should play normal Chess as well as FRC under WinBoard .

Note that you have to understand BOTH the KQkq and AHah notations in the FEN reader of an engine that plays FRC under non-broken Arena or ChessGUI versions and supports setting up an arbitrary FRC position (rather than only opening positions).

Many FRC positions cannot be described unambiguously without the AHah notation. Current Arena 'solves' this by replacing FRC positions it cannot send by other positions that it can send. (Just like WB protocol 1 cannot send positions where K and R are in the initial position without castling rights in normal Chess.) Don't know about ChessGUI. No matter what FEN standard you use, you always have to understand the AHah notation in FENs, or your engine will not have full 'edit position' functionality. Of course, running under Arena, you might not care, as Arena does not support a full 'edit position' for FRC anyway (currently).

[Matthias Gemuh]

Note that you have to understand BOTH the KQkq and AHah notations in the FEN reader of an engine that plays FRC under non-broken Arena or ChessGUI versions and supports setting up an arbitrary FRC position (rather than only opening positions).

Many FRC positions cannot be described unambiguously without the AHah notation.

KQkq FRC engines must know that in ambiguous situations, castling is in HAha-style under ChessGUI.

All FRC engines (HAha and KQkq) run fine in ChessGUI.

Matthias.