bugXBoard - Bugs: bug #27153, Pre-move does not work on xboard...

 
 

bug #27153: Pre-move does not work on xboard 4.4beta1

Submitter:  None
Submitted:  Sat 01 Aug 2009 06:27:58 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

Sun 25 Oct 2009 01:34:25 AM UTC, comment #16: 

OK, finally got some time to test, built xboard-4.4.1.20091019, and indeed it seems the issue is now fixed.

As a side note, there seem to be some lingering debug messages in that version (backend.c at line 3429) as xboard outputs the following lines at each move:
old: 8x8   new: 8x8 weird=0 variant=0
old: 8x8   new: 8x8 weird=0 variant=0

Anonymous
Mon 19 Oct 2009 01:48:20 AM UTC, comment #15: 

you want to try the latest git version not the one that's one the ftp server.

Arun Persaud <apersaud>
Group administrator
Mon 19 Oct 2009 12:08:49 AM UTC, comment #14: 

Not sure if the fix of HGM is included in 4.4.1pre but FYI I compiled it today and pre-move still not working.

Anonymous
Sun 11 Oct 2009 06:01:46 AM UTC, comment #13: 

seems to have fixed it. Closing the report

Arun Persaud <apersaud>
Group administrator
Fri 09 Oct 2009 06:04:47 AM UTC, comment #12: 

uploaded the changes from HGM. Please test.

Arun Persaud <apersaud>
Group administrator
Thu 08 Oct 2009 04:50:00 PM UTC, comment #11: 

Indeed, we got it now. If someone had told me that the problem was that recptures could not be entereds premoves, I would have fixed it in a few minutes. It was just that no one mentioned that. In click-click mode premove recaptures are not possible, as clicking a new own piece selects it as new FROM square rather than as a TO square. So I assumed that it was intended behavior that recaptures could not be premoves, and that everyone knew this. I never realized that the ambiguity new-mover / recapture does not occur for drag-drop moves, and that 'capture-own' premoves are actualy supposed to work there. My mistake.

As the comment in the source shows I misjudged the function of the offending code (which I moved from winboard.c to backend.c). I thought it was for filtering out illegal premoves, but in fact it serves to give precedence for selection of a new piece in click-click mode over entering a capture-own move.

Simply deleting the offending code in backend.c is no option, as this would break WinBoard. I will rewrite the mouse handlers of both to be compatible with a renewed backend. The XBoard mouse andler will then also contain the promotion-popup fix and selecting promotion pieces from the holdings in -variant super and great (which WinBoard already has).

H.G. Muller

Anonymous
Thu 08 Oct 2009 03:55:46 PM UTC, comment #10: 

Also note, that these kind of premoves (to a piece of your own
colour) can only be made by dragging the piece, not if you just click the from and to squares.
This was the same in xboard 4.2.7.

Anonymous
Wed 07 Oct 2009 06:56:23 PM UTC, comment #9: 

The following piece of code (in UserMoveTest() in backend.c)
filters out perfectly good premoves - the ones that put a piece
on a piece of the same color. Removing those lines gives
premove handling like in xboard 4.2.7:


    /* note: this code seems to exist for filtering out some obviously illegal premoves */

    if (    gameMode != EditPosition &&
            (WhitePawn <= pdown && pdown < BlackPawn &&
             WhitePawn <= pup && pup < BlackPawn  ||
             BlackPawn <= pdown && pdown < EmptySquare &&
             BlackPawn <= pup && pup < EmptySquare
            ) && !((gameInfo.variant == VariantFischeRandom || gameInfo.variant == VariantCapaRandom) &&
                    (pup == WhiteRook && pdown == WhiteKing && fromY == 0 && toY == 0||
                     pup == BlackRook && pdown == BlackKing && fromY == BOARD_HEIGHT-1 && toY == BOARD_HEIGHT-1  )
        )           )
         return ImpossibleMove;

Anonymous
Tue 06 Oct 2009 09:53:28 PM UTC, comment #8: 

Premoving does not work when you try to move a piece onto
one of your own  pieces (which you expect to be captured by
your opponent).

Anonymous
Sat 03 Oct 2009 02:39:53 AM UTC, comment #7: 

still working on this one. Other people reported this too, but we (HGM and Arun) are not able to reproduce this, so it's hard to track down.

Arun Persaud <apersaud>
Group administrator
Mon 07 Sep 2009 04:37:48 AM UTC, comment #6: 

After seeing in Git that H.G. Muller made pre-move fixes for Winboard I downloaded and compiled the final 4.4.0 tonight, unfortunately problem remains for xboard.

Anonymous
Thu 20 Aug 2009 08:27:15 PM UTC, comment #5: 

When the problem occurs I cannot even select a pre-move, if I try to drag a piece it does not even get highlighted at all.
And yes, I did all the steps from autogen to final binary.

Actually I did upgrade my system to Jaunty (Ubuntu 9.04, gcc 4.3.3) today and rebuilt xboard from scratch. I still see the same problem, a little less often but it still occurs. It is strange, at a given move, the pre-move would work for one piece move and not for another. For example, there was a position where I could input a pawn-take-pawn premove but not a Bishop take-pawn (and of course both are valid moves).

At some point I thought it might be because I use the mouse of my Wacom tablet but again, I have older version of xboard that work just fine on the same system so it is more likely a regression.

Anonymous
Fri 07 Aug 2009 05:24:04 PM UTC, comment #4: 

I tried it yesterday and pre-move seemed to work fine for me, but I only tested it a few times, so I'll do some more testing in the next few days, since you mention that it stopped working for you.

When it stops working for you what's the problem? Does the selection of the squares stop working or does it just not do the move, but the squares show up as selected for pre-move, etc?

Could you also confirm that you use these commands to build

./autogen.sh
./configure
make

or if not which commands you are using.

Arun

Arun Persaud <apersaud>
Group administrator
Fri 07 Aug 2009 05:10:39 PM UTC, comment #3: 

Recompiled today with the following GCC:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)


There is definitely a problem with pre-move for me. Behaves very erratically. May work a couple of times at the beginning of a game and then stops working. Also, it does not seem to work at all unless I specify the -premove option on the command line (true of false by the way).
This is all using the 4.4beta1 sources from ftp://alpha.gnu.org/gnu/xboard/.

Anonymous
Thu 06 Aug 2009 08:53:40 PM UTC, comment #2: 

To answer the question, I am using Ubuntu Hardy (8.04).

I tried both with the flag set or unset in the Option menu. It looked like a GUI problem because even the squares highlight that I usually see (when a pre-move has been entered but not yet played) is not showing.

If it works for you then it may be a problem on my end. I will rebuild everything, retest, and let you know.

Anonymous
Sat 01 Aug 2009 08:24:06 PM UTC, comment #1: 

Hi, what operating system, etc are you using. I've been testing the new version also on FICS and have no problems with pre-move.

Is premove enabled in the Option menu?

ARUN

Arun Persaud <apersaud>
Group administrator
Sat 01 Aug 2009 06:27:58 PM UTC, original submission:  

FYI, just compiled today and tried it on FICS, pre-move enabled at start but nor working.

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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-11 apersaud StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2009-10-09 apersaud StatusNeed Info Ready For Test
    2009-08-01 apersaud StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code