Crafty & draw offer on FICS

[jdart]

I was playing an account running Crafty 23.2 + Winboard 4.4.3 on FICS and in a tablebase draw position Crafty repeatedly offered a draw. But all I see in the xboard logs is this:

<ICS: \012\015<12> K------- -------- -k------ -Pb----- -------- -------- -------- -------- W -1 0 0 0 0 47 384 GeidiPrime ArasanX -1 15 0 1 3 33550 44570 119 B/d4-c5 (0:01.570) Bc5 1 1 0\012\015fics% \012\015GeidiPrime offers you a draw.\012\015fics% \012\015<12> -K------ -------- -k------ -Pb----- -------- -------- -------- -------- B -1 0 0 0 0 48 384 GeidiPrime ArasanX 1 15 0 1 3 33450 44570 119 K/a8-b8 (0:00.100) Kb8 1 1 62\012\015fics%
ics input 236, castling = 45 45 5440651 45 45 0

I never see a "draw" command from xboard. So Arasan ignored the request. A human might have accepted but Arasan doesn't parse text strings like "X offers you a draw", only Winboard/xboard commands.

From the source, it looks like Crafty sends "draw" only if the xboard variable is set to true.

So maybe this was set off? Would that even work playing on a chess server under Winboard? Or is this some other issue?

[bob]

I was playing an account running Crafty 23.2 + Winboard 4.4.3 on FICS and in a tablebase draw position Crafty repeatedly offered a draw. But all I see in the xboard logs is this:

<ICS: \012\015<12> K------- -------- -k------ -Pb----- -------- -------- -------- -------- W -1 0 0 0 0 47 384 GeidiPrime ArasanX -1 15 0 1 3 33550 44570 119 B/d4-c5 (0:01.570) Bc5 1 1 0\012\015fics% \012\015GeidiPrime offers you a draw.\012\015fics% \012\015<12> -K------ -------- -k------ -Pb----- -------- -------- -------- -------- B -1 0 0 0 0 48 384 GeidiPrime ArasanX 1 15 0 1 3 33450 44570 119 K/a8-b8 (0:00.100) Kb8 1 1 62\012\015fics%
ics input 236, castling = 45 45 5440651 45 45 0

I never see a "draw" command from xboard. So Arasan ignored the request. A human might have accepted but Arasan doesn't parse text strings like "X offers you a draw", only Winboard/xboard commands.

From the source, it looks like Crafty sends "draw" only if the xboard variable is set to true.

So maybe this was set off? Would that even work playing on a chess server under Winboard? Or is this some other issue?

Are you seeing a message like "Crafty offered a draw" when you are observing the game? If so, that means that Crafty is offering the draw correctly, and your xboard should be sending your program a simple "draw" by itself... The real question is does your GUI (I assume xboard?) know that _you_ are a computer so that it will send the "draw" offer command correctly?

Crafty can't directly send "draw" to your engine. All it can do is send "offer draw" to the server, which gets passed to your program/GUI. It is up to the GUI to parse that and do whatever is necessary to get the draw offer to your engine...

[jdart]

I am passing "-zp -ics" to xboard so it should know the player is a computer.

--Jon

[bob]

I am passing "-zp -ics" to xboard so it should know the player is a computer.

--Jon

Next question... what version of xboard??? I'm using 4.4.3... It seems pretty clear that if you are seeing the draw offer message, that my end is doing things correctly...

[hgm]

I think Bob is right: the excerpt of the debug file you show here is the raw traffic between ICS and xboard. XBoard is supposed to trigger on the substring "offers you a draw", and then send the WB draw command to the engine.

Newer versions of XBoard are supposed to delay relaying the draw offer to the engine until the opponent moves. Then they send it just before the move. This to prevent the opponent disrupting ponder of engines with a flakey ponder implementation by bombarding it with draw offers. That is beyond the part you show, after XBoard has parsed the move.

If it is not there, it should be considered an XBoard bug.

[jdart]

I have been using a snapshot of xboard - it is pretty recent (Jan. this year). Maybe I should upgrade.

I don't see the "draw" command issued to the engine. Arasan was pondering so it was the opponent's turn. But I only see "<account> offers you a draw" not the draw command itself.

--Jon

[bob]

I have been using a snapshot of xboard - it is pretty recent (Jan. this year). Maybe I should upgrade.

I don't see the "draw" command issued to the engine. Arasan was pondering so it was the opponent's turn. But I only see "<account> offers you a draw" not the draw command itself.

--Jon

I don't think it will arrive until just before the move itself arrives. That's the key. You will see the message, which comes from ICS to your GUI, and the GUI will display that in the text window where you see all the ICS chit-chat, but the GUI won't send the "draw" until it gets a move to send, according to HGM... that might be adding some confusion to what you are seeing...

[jdart]

I am pretty sure it didn't arrive because I have code to accept a draw if the tablebases say draw .. so it would have accepted.

Strangely, too, playing the actual "crafty" account on ICC (different server), draw offer worked:

<ICS: ArasanX(C) kibitzes: time=12.82 sec. score=+0.33 depth=16 nps=4.38M cpu:713.22% pv: f5 Qf6 Rdc5 Bd3 R2c3 Rd8 a4\015\012(kibitzed to 2 people)\015\012aics%
ics input 67, castling = 45 45 5440651 45 45 7
10265033 <first : # time check interval=227007 elapsed_time=156 target=99999
10265033 <first : # 15. move=d5-c5 score=44 terminate=0
10271988 <first : # time check interval=243279 elapsed_time=851 target=99999
10271988 <first : # 16. move=f2-g1 score=26 terminate=0
<ICS: aics%
ics input 67, castling = 45 45 5440651 45 45 7
<ICS: \015\012Your opponent offers you a draw.\015\012\007Use "draw" to accept. The offer is valid until you make a move.\015\012aics%
ics input 67, castling = 45 45 5440651 45 45 7
10280383 >first : draw
10280385 <first : # read 5 bytes
10280385 <first : # check_command: draw
10280385 <first : # in accept_draw
10280385 <first : # checking draw score ..
10280385 <first : # rating_diff = 172
10280385 <first : # draw_score = 24
10280385 <first : # last_score = -17
10280385 <first : # threshold = -11
10280385 <first : offer draw
>ICS: /
>ICS: draw\015\012

[hgm]

OK, is seems there is an XBoard bug here. In ZippyMatch() in zippy.c I find the code:

Code: Select all

    if (ics_type == ICS_ICC) { // [DM]
        if (looking_at(buf, i, "Your opponent offers you a draw")) {
            if (first.sendDrawOffers && first.initDone)
                SendToProgram("draw\n", &first);
            return TRUE;
        }
    } else {
        if (looking_at(buf, i, "offers you a draw")) {
            if (first.sendDrawOffers && first.initDone) {
                SendToProgram("draw\n", &first);
            }
            return TRUE;
        }
    }

Apparently a problem was noticed here in the past, and fixed by Daniel Mehrman. He fixed it only for ICC, though, which explains why it works on ICC, but not on FICS. FICS does not say "Your opponent", but uses the actual name of the opponent in the draw-offer message. But the pattern that XBoard tries to match does not not account for the name.

The pattern should really have been "* offers you a draw", so that the * meta-character would match the name. In that case it would also have matched "Your opponent" as a special case of a name, and there would have been no need to single out ICC for special treatment. Without the wildcard, the string would only be recognized if "offered" is really the first word to read in the input buffer, which at this point it isn't.

The part of the code that calls this is also a bit suspect:

Code: Select all

	    if (appData.zippyTalk || appData.zippyPlay) {
                /* [DM] Backup address for color zippy lines */
                backup = i;
#if ZIPPY
       #ifdef WIN32
               if (loggedOn == TRUE)
                       if (ZippyControl(buf, &backup) || ZippyConverse(buf, &backup) ||
                          (appData.zippyPlay && ZippyMatch(buf, &backup)));
       #else
                if (ZippyControl(buf, &i) ||
                    ZippyConverse(buf, &i) ||
                    (appData.zippyPlay && ZippyMatch(buf, &i))) {
		      loggedOn = TRUE;
                      if (!appData.colorize) continue;
		}
       #endif
#endif
	    } // [DM] 'else { ' deleted

This code occurs just before a block of pattern matches that colorizes the matched words before printing them in the console. Apparently Daniel changed behavior here (by deleting the else) so that such colorized printing even takes place in zippy mode. But, as this involves matching of the same patterns as were already matched (and eaten away) in ZippyMatch(), he has introduced a 'backup' variable to rewind the input pointer for the second (colorization) matching attempt.

The strange thing is that this change has been made dependent on being WinBoard or XBoard. I see no reason here why XBoard and WinBoard should behave differently here.

It also seems braces around the colorization block are in the wrong place, making that some patterns cn never be matched. This might be my doing, though.

I will try to sort out the entire mess...

[hgm]

OK, I got to the bottom of it. This is what happened:

Originally the pattern "offers you a draw" in the zippy code was sufficient, because when no pattern is matched at all, the input pointer will be advanced one character, and the matching process resumes. So in the end you would skip over the "Your opponent" or "GiediPrime", (because that matches no other pattern) and arrive at "offers". This was the situation in 4.2.7.

Now in Feb. 2004 there was a commit by Daniel , removing the 'else', which made the colorization patterns for which no matching attempt was made in zippy modes also tried (to make colorization also active in this mode). But draw offers are also colorized, and the colorization code matched for them by "* offers you a draw" (because the name of the offerer also has to be colorized). So the colorization recognized the offer before zippy did, and then ate it away. So ICS draw-offer recognition was broken.

Daniel must have discovered this quite quickly, as the next day there was a commit that fixes it for ICC, by having zippy match for "Your opponent offers ...". The problem on FICS remained, though, and was apparently never detected until now. The proper fix would have been to change the zippy pattern to "* offers you a draw", which would have worked on every ICS.

These commits were in the Savannah repository for the 4.2.pre8, which was then merged with my own 4.3.16 fork to create 4.4.0. A June 2004 commit of Daniel was improperly merged, causing a regression, with as result that the _WIN32_ dependent code kept using &i in stead of &backup as the input pointer, so that zippy matches would still escape colorization in XBoard, which Daniel had fixed in that commit by making the 'continue' conditional.

Of course when both the _WIN32_ part and the alternative use both &backup, the code of both parts has become the same, and the need for the conditonal becomes dubious. The only remaining effect of it seems that in WB you match only for the zippy patters when you are already logged in, while in XB you always try to match, and when you succeed even when you (think you) are not login, you conclude that you are logged in anyway. I don't see any need for this subtly different behavior of WB and XB...