bugXBoard - Bugs: bug #27772, Board and holdings out of sync

 
 

bug #27772: Board and holdings out of sync

Submitter:  None
Submitted:  Wed 21 Oct 2009 08:17:48 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 27 Oct 2009 12:31:21 PM UTC, comment #23: 

All points mentioned in this thread (sync/bell/prompt) tested ok with git affb2d78e0cfaa22e62573dd4e65d2bb3062471c.
Thanks to H.G. Muller for his effort.

Anonymous
Mon 26 Oct 2009 09:35:50 AM UTC, comment #22: 

It seems the prompts fail to be filtered, because during game play, the prompt following a board for the opponent's move is separated from the latter by an empty line. (Actually by \n\r\n\r\r, but XBoard fiters out any '\r' in the low-level input routine.)

I put in some code after board reading, to eat away any empty lines before trying to eat the prompt, and then the effect disappears even with timeseal.

while(looking_at(buf, &i, "\n")); // [HGM] skip empty lines
if (looking_at(buf, &i, "*% ")) {
    savingComment = FALSE;
}

Anonymous
Mon 26 Oct 2009 09:11:50 AM UTC, comment #21: 

I tried different settings and noticed that the promps get filtered when I don't use timeseal.

I have 2 different timeseal versions and both produce the prompts.

Anonymous
Mon 26 Oct 2009 06:25:17 AM UTC, comment #20: 

hmm, I don't see those prompts over here when I play on FICS...

Arun Persaud <apersaud>
Group administrator
Sat 24 Oct 2009 09:41:22 PM UTC, comment #19: 

I think those are exactly the prompts that are filtered here. Strange that this does not work for XBoard: the filtering takes place in the back-end. In WinBoard you don't get such prompts, and the console stays nicely empty.

H.G. Muller

Anonymous
Sat 24 Oct 2009 08:19:24 PM UTC, comment #18: 

That prompt suppressing reminds me of all those "fics%" lines filling up the xterm-console while playing (each opponent's move adds one). Might be further filter candidates.

Anonymous
Sat 24 Oct 2009 06:01:23 PM UTC, comment #17: 

I guess I found a front-end-independent fix:

In stead of RingBell() or my new routine Bell(), simply call:

SendToPlayer("\007", 1);

This sends a bell to the console, which both in WinBoard and XBoard produces the required sound! :-D

H.G. Muller

Anonymous
Sat 24 Oct 2009 04:33:51 PM UTC, comment #16: 

Yeah, that was the nasty part. RingBell() strangely enough is the move sound in WinBoard, and there is no way to call the sound produced by the bell charactr from the back-end. Only the front-end routine that sends text to the console produces it, by calling the low-leve sound driver directly.

So I had to add Bell() to make a consistent sound in WinBoard. I have not tried to make it work in XBoard yet; obviously I would have to add a Bell() routine there too, but what exactly it should do...?

H.G. Muller

Anonymous
Sat 24 Oct 2009 03:56:05 PM UTC, comment #15: 

Bell() -> RingBell()

Works now.


Anonymous
Sat 24 Oct 2009 03:17:14 PM UTC, comment #14: 

Well, it seems that for me, the bell character is almost always prefixed to the prompt. I captured it from the winboard.debug file, but that should not really matter. It might be that there is a kind of race condition in the server, where two message of different rigin are sent to the same user, and get interleaved in an unpredictable way.

But I guess it does not really matter. The code suppresses the prompt after board and holdings (together with board or holdings itself), and then switches on the displaying in the console. So if the bell arrives after the '%' of the prompt it should be sounded. Only when it would arrive before the '%' it would be considered part of the prompt, and be suppressed (and then also not sounded). So the patch I have now,

    /* Suppress following prompt */
    if (looking_at(buf, &i, "*% ")) {
if(strchr(star_match[0], 7)) Bell(); // FICS fuses bell for next board with prompt in zh captures
savingComment = FALSE;
    }

should solve the only case that would lose the bell, and thus solve the problem. I have been watching quite a number of crazyhouse games now, and I neer noticed the bell not sounding.

H.G. Muller

Anonymous
Sat 24 Oct 2009 03:03:04 PM UTC, comment #13: 

I used "telnet freechess.org|tee log.txt" to capture the strings (manually setting style 12). I don't know, if that's a proper way.
The whole beep-thing was more to make sure, that a character isn't overwritten by accident, so that "bell 0" would be safe too. I prefer "bell 1", because that's the perfect lag indicator, when making a move.



Anonymous
Sat 24 Oct 2009 12:10:52 PM UTC, comment #12: 

Note that the 12 15 and 07 actually stand for lf, cr and bell; the software of this board seems to replace the backslash+0 by a space.

Anonymous
Sat 24 Oct 2009 12:06:19 PM UTC, comment #11: 

Strange! For me the Bell got prefixed to the prompt following the holdings:

<ICS: \012\015<b1> game 238 white [P] black [N] <- WP\012\015\007fics% \012\015<12> rn--kb-r ...

I put in a patch that looks at the matched part when recognizing the prompts after holdings with looking_at(buf, &i, "*% "), to see if it contained a bell character, and if so, sound it. (Already a nuisance, as there was no call available to sound the bell from the backend. Which means that adding the call likely breaks XBoard.) This works for me. But it would not work if the bell appeared after the %, as you show.

H.G. Muller

Anonymous
Sat 24 Oct 2009 11:50:55 AM UTC, comment #10: 

Ok, forget about the bell. I saw in the source, that the next prompt after holding gets intentionally suppressed. So there might be a good reason for this. Wouldn't be worth breaking something. So this item can be closed.


Anonymous
Sat 24 Oct 2009 10:48:36 AM UTC, comment #9: 

Sure it can be worked around, but it's normally a good thing to have a closer look to strange behaviour. There could be more serious things behind it.

As I see the bell is always sent on a seperate new line just before the board:

^Mfics%
^M<b1> game 260 white [BBRQ] black [PN] <- WB
^Mfics% ^G
^M<12> ---rr--- -pp---pk p-n--pp- ---pb--N ---P---- --P---P- PP---PPP RNB-Q-K- B -1 0 0 0 0 0 260 Horkko tiberiansun 0 1 0 51 27 21 11 26 N/f4-h5 (0:01) Nxh5 0 1 183

Seems the holding string before a capture kills the next line. Good thing FICS even sends "^Mfics%" with "bell 0", otherwise the <12> line might have been removed.

So it should be safe to keep that (at least with FICS).

Anonymous
Sat 24 Oct 2009 10:03:48 AM UTC, comment #8: 

I guess the problems are indeed related: WinBoard only sounds bells that are printed to the console. Normally the bells are appended to the prompt, or on an empty line. But I guess when something is captured in crazyhouse, FICS sends the holdings update before the board, and the bell gets appended to that. (Not sure; there are virtually no crazyhouse games played on FICS at the times I can do testing.) Now the holdings update line is not printed to the console, so the bell gets suppressed.

Should we also sound bells that are not printed to the console?

If you want to hear a sound on every move, the moveSound is meant for that.

H.G. Muller

Anonymous
Sat 24 Oct 2009 07:37:45 AM UTC, comment #7: 

The synchronization seems to work with xboard-4.4.1.20091022.
The servers bell code still gets lost in crazyhouse capture moves.

Anonymous
Fri 23 Oct 2009 10:25:28 AM UTC, comment #6: 

Ah, good observation. I guess this tells us how they implemented it on the server; when a piece is captured they first send a holdings update to the game that receives it, and after it print the board to the game making the capture, both in bughouse and crazyhouse. Except that in crazyhouse this is the same game.

They should have sent the holdings update after sending the board, or suppress it altogether in crazyhouse.

As it now seems to work with the flag, I will keep it that way for now, and just keep in mind that there is a better solution for when we are going to do some code refactoring.

There still will be a problem for the part of the game you have not been observing. The holdings will be empty for that part, as move lists do not contain holding updates. In crazyhouse the updates are implied by the moves, of course. So in principle I could alter the flow of information during ICS play, and derive holdings (and castling rights in FRC, and info on which pieces are really promoted Pawns) from the previous position (if known) and move, rather than from the board sent by the ICS. But that would still not work in bughouse, so I am not going to bother with that now, and leave it for a later version.

H.G. Muller

Anonymous
Fri 23 Oct 2009 09:19:02 AM UTC, comment #5: 

Remark: Looks like the holdings sent before a capture always have that format:

<b1> game 174 white [PPR] black [NNB] <- WR

And afterward the board was sent that:

<b1> game 174 white [PPR] black [NNB]

That might be useful to differentiate the two, without using additional flags.

Anonymous
Thu 22 Oct 2009 03:03:05 PM UTC, comment #4: 

It seems FICS sends holdings both before and after the board. Those before the board were then overwriting the holdings of the previous board, of course. I now tried to fix this by hiding a flag in each board that remembers if the holdings were already set from the ICS, and then suppress any duplicate holdings that really belong to the next board that is yet to come. (We do not know the move number of this board before it really arrives; thre is no move number in a holdings line... :-( )This seems to work.

In bughouse I still allow overwrite, as I suppose multiple holdings updates can be made there between boards. I have not tested this.

(Not in git yet.)

H.G. Muller

Anonymous
Thu 22 Oct 2009 12:46:28 PM UTC, comment #3: 

I don't know, if this effect is somehow connected:
I have "Move sound" off and "set bell 1" on FICS. Capture moves while observing crazyhouse often don't produce the beep.
All other move types (and all moves in the other variants) produce the beep.

Anonymous
Thu 22 Oct 2009 08:44:11 AM UTC, comment #2: 

It has improved, but sometimes it's still off 1 move. Stepping through afterwards shows a piece appear in the holding that is captured one move later.

Anonymous
Thu 22 Oct 2009 06:03:01 AM UTC, comment #1: 

uploaded patch by HGM in git, please test.

Arun Persaud <apersaud>
Group administrator
Wed 21 Oct 2009 08:17:48 PM UTC, original submission:  

XBoard in ICS mode (FICS):
Observe a crazyhouse game and pause the game for a while. The board position freezes, but the holdings still are updated when moves are made. When the game is over, step through the game. Capture moves on the board and holding updates are out of sync.
Even without pausing this happens sometimes.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by apersaud (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-27 apersaud Open/ClosedOpen Closed
        StatusReady For Test Fixed
    2009-10-22 apersaud StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code