bugXBoard - Bugs: bug #8847, Moving backward while examining on...

 
 

bug #8847: Moving backward while examining on FICS not reported to engine

Submitted by:  None
Submitted on:  Sun 09 May 2004 10:57:46 AM UTC  
 
Category: NoneSeverity: 2 - Minor
Item Group: NoneStatus: Fixed
Assigned to: NoneOpen/Closed: Closed
Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 23 Oct 2009 08:01:19 AM UTC, comment #5:

This should be fixed now, in the latest git version. At the point where a new board of an already active game is received, when in zippy mode with an initialized engine, as many undos as needed are sent to the engine when the board number falls within existing move history. When not, a move list is requested, and I added a call to InitChessProgram() to make sure the program will be ready to process that list in FeedMovesToProgram() (which will be called after the entire move list has arrived).

I guess that only leaves problems when you play with -getMoveList false. But I am not sure that is a sensible setting in zippy mode. So for now I wanted to leave that.

Behavior with -getMoveList true should now be OK, and is ready for testing.

H.G. Muller

Anonymous
Thu 22 Oct 2009 06:50:25 AM UTC, comment #4:

OK, I see. In my mind I was mixing up "Analyzing" and "Examining". Daniel had already added code to solve this problem, (sending the appropriate number of undos when a board with a lower number of the same game is received), but it was only activated when the engine was analyzing. And AFAICS that can only be the case when observing, not when examining. And when observing I don't think you would ever get out-of-sequence boards.

I now made that code active depending on (zippy mode && (observing || examining) && init done). I think this catches all the cases we want this to happen.

(Come to think of it, I guess I must test for the engine to understand the variant of the game we are currently observing, as I suppress sending the moves to keep the engine in sync in that case too: it was very annoying when you were in an on-line engine tournament waiting for your next game, not being able to observe, say, a crazyhouse game without being swamped by illegal-move messages from the engine.)

H.G. Muller

Anonymous
Wed 21 Oct 2009 07:38:22 AM UTC, comment #3:

I just tried with the latest git version of xboard, and this behavior is still the same. Looking at the xboard.debug file, a board image that comes back from "forward" causes us to send the move to the engine, but one that comes from "backward" doesn't cause us to send anything, so a subsequent "forward" causes the engine to say "illegal move."

To clarify, this is just examining with -zp turned on and the Mode menu on the default "ICS Client" mode, not Analysis Mode.

I'll attach the xboard.debug file.

Of course, this issue is by no means important, but looking at it was a way for me to dip a toe back in the water of helping with the project.

(file #18912)

Tim Mann <mann>
Project Administrator
Tue 20 Oct 2009 05:37:52 AM UTC, comment #2:

The bug submitter must have been examining a game on FICS while in zippy mode (-zp). Zippy mode is the only case where xboard is connected to both an ICS and an engine at the same time. (Or at least it was in 4.2.7... have we added anything in 4.4.x that changes that?)

Testing the user's scenario on 4.2.7, it's true: if you connect to FICS in zippy mode, examine an existing game, and hit the [>] button on xboard, it sends "forward" to the ICS and the move that ICS sends back gets sent to the engine. And if you hit the [<] button, it sends "backward" to the ICS, but it does not send "undo" (or anything else) to the engine, so the engine gets out of sync with the board position being examined. This is bad because if you then hit [>] again to go forward, the engine rejects the move sent back from ICS as illegal and causes xboard to display an error message.

It's not clear what the right fix is for this. AFAICS, there is no reason the engine should participate in examine mode, so ideally we would detect you've gone into that mode and not send it anything. I don't remember enough about the ICS protocol to know if it's easy to detect that.

In the short term, the workaround is to log in separately (not in zippy mode) if you want to examine games.

Tim Mann <mann>
Project Administrator
Tue 20 Oct 2009 01:24:40 AM UTC, comment #1:

FICS doesn't have an undo command according to their help files and it seems that you shouldn't be able to take a move back by just clicking on the back button...

In case you mean something else, please let us know. For the moment I'll flag this as invalid and close the report.

ARUN

Arun Persaud <apersaud>
Project Administrator
Sun 09 May 2004 10:57:46 AM UTC, original submission:

When examining an existing game on FICS and going
forward one move, Xboard sends "usermove e4" to the
engine (since I used "feature usermove=1"). Fine.

However, when I back up one move, the engine gets
nothing, and thus goes out of sync. I'd expect an
"undo" in this case.

Thanks for your attention, and THANKS for Xboard!

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #18912:  xboard.debug added by mann (28KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 31 Oct 2009 03:10:08 AM UTCapersaudStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Fri 23 Oct 2009 03:42:23 PM UTCapersaudStatusConfirmed=>Ready For Test
    Wed 21 Oct 2009 07:38:22 AM UTCmannSeverity3 - Normal=>2 - Minor
      Open/ClosedClosed=>Open
      Attached File-=>Added xboard.debug, #18912
    Tue 20 Oct 2009 05:38:11 AM UTCmannAssigned tomehrmann=>None
      StatusInvalid=>Confirmed
    Tue 20 Oct 2009 01:24:40 AM UTCapersaudOpen/ClosedOpen=>Closed
    Tue 20 Oct 2009 01:24:39 AM UTCapersaudStatusNone=>Invalid
    Mon 12 Jul 2004 03:20:24 AM UTCmehrmannAssigned toNone=>mehrmann

    Back to the top


    Powered by Savane 3.1-cleanup1