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

[Ben Asselstine-2]

Update of bug #8847 (project xboard):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up 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


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Follow-up Comment #2, bug #8847 (project xboard):

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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Update of bug #8847 (project xboard):

                  Status:                 Invalid => Confirmed              
             Assigned to:                mehrmann => None                  


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g. muller]

Beware that I hardly ever use an ICS, and that I never used examine mode
before.
But I tried it for the occasion, and it seems the ICS has commands
"forward" and
"backward" that can be used to step through the game (possibly in steps of
multiple
moves). After each such command it sends a new board.

I would have expected that new board, if it has a sequence number equal to the
current board + 1, to be sent to the engine as a move, and if not, (because
I enter
"forward 999" or something like that) as a setboard. But perhaps if the
sequence
number is higher, XBoard would obtain a move list through a "moves" command,
and then load the move list to obtain the position. (I guess this is
preferable, as
it would make the engine aware of the game history, which can be important for
detecting rep-draws.)

So now on "backward", when the sequence number of the new board is lower,
both strategies should still work. (Which made me wonder what to fix.) If
XBoard
sends a setboard it should not matter if you moved forward or backward, and if
it requests a move list (or perhaps already is in posession of the move
list) it
can reload the game into the engine. There is no need to recognize the special
case of backing up a single move, and using "undo" on the engine. (Which many
engines do not implement anyway.)

It would be easy enough to put code in BackwardEvent() that detects if the
engine
is analyzing an ICS game, and send "undo" to it in that case.

Problem is that I don't seem to be able to even get into the situation
where this
issue would manifest itself. When I log onto FICS in zippy mode with Fruit,
start
examining a stored game, and try to switch on analysis mode, I get the error
message from WinBoard: "you are not observing a game". I tried to observe
a game that was in progress, start analysis mode, and then give the "examine"
command, but then it did not give me a game I could step through, and when I
typed "unobserve" to try to examine, the engine stopped analysing.

SO what combination of XBoard / ICS commands I have to give to test this???


_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[h.g. muller]

I found this code in parse_board12():

    /* [DM] If we found takebacks during icsEngineAnalyze try send to engine */
    if (!newGame && appData.icsEngineAnalyze && moveNum < forwardMostMove) {
        takeback = forwardMostMove - moveNum;
        for (i = 0; i < takeback; i++) {
             if (appData.debugMode) fprintf(debugFP, "take back move\n");
             SendToProgram("undo\n", &first);
        }
    }

This seems aimed at fixing the reported problem, so it seems Daniel
has been working on it already. I don't see any flaws in the code;
(well, perhaps if the number of undos was very large, it would make
more sense to start a new game and load it from the begining...),
so if the problem occurs despite of it, it must be because the ICS
does not send a board.
_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Tim Mann]

Sorry, I should have tested with 4.4.x, but I didn't have it handy.  I
only tested with 4.2.7.  Also, I didn't go into analysis mode, so there
was no good reason for the engine to be participating at all.  It was
just sitting there in force mode looking at the moves and complaining
if it thought they were illegal.

It sounds like things have progressed a lot and this bug doesn't exist
anymore.

On Tue, 20 Oct 2009 13:36:29 +0200, "h.g. muller" <h.g.muller@...> wrote:

> I found this code in parse_board12():
>
>      /* [DM] If we found takebacks during icsEngineAnalyze try send to
> engine */
>      if (!newGame && appData.icsEngineAnalyze && moveNum < forwardMostMove) {
>          takeback = forwardMostMove - moveNum;
>          for (i = 0; i < takeback; i++) {
>               if (appData.debugMode) fprintf(debugFP, "take back move\n");
>               SendToProgram("undo\n", &first);
>          }
>      }
>
> This seems aimed at fixing the reported problem, so it seems Daniel
> has been working on it already. I don't see any flaws in the code;
> (well, perhaps if the number of undos was very large, it would make
> more sense to start a new game and load it from the begining...),
> so if the problem occurs despite of it, it must be because the ICS
> does not send a board.

--
Tim Mann  tim@...  http://tim-mann.org/


_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Update of bug #8847 (project xboard):

                Severity:              3 - Normal => 2 - Minor              
             Open/Closed:                  Closed => Open                  

    _______________________________________________________

Follow-up 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)
    _______________________________________________________

Additional Item Attachment:

File name: xboard.debug                   Size:28 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Follow-up Comment #4, bug #8847 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Follow-up Comment #5, bug #8847 (project xboard):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Update of bug #8847 (project xboard):

                  Status:               Confirmed => Ready For Test        


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard

[Ben Asselstine-2]

Update of bug #8847 (project xboard):

                  Status:          Ready For Test => Fixed                  
             Open/Closed:                    Open => Closed                


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?8847>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-XBoard mailing list
Bug-XBoard@...
http://lists.gnu.org/mailman/listinfo/bug-xboard