bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Problems with import of oldfibs files


From: Joern Thyssen
Subject: Re: [Bug-gnubg] Problems with import of oldfibs files
Date: Thu, 30 Oct 2003 07:54:58 +0000
User-agent: Mutt/1.4.1i

On Thu, Oct 30, 2003 at 12:53:12AM +0100, Jim Segrave wrote
> 
> While looking into the many reaons gnubg won't import a user's fibs
> log, I found the following:
> 
> gnubg expects a game to start with a score line:
> 
> score %d-%d in a %d ...
> 
> I don't know if this is a valid prerequisite.
> 
> A worse problem is that import.c calls CanonicalMoveOrder() to process
> the listed moves. This works well for player 1, whose moves are from
> high numbers to low, it doesn't work for player 0, whose moves are
> from low numbers to high. 

Yes, but did you note the code just above:

            /* if the moves are ascending invert it.
               In theory this is only necessary when iPlayer == fInvert,
               but some programs may write incompatible files.
               Joseph's fibs2html is one such program. */
            
            if ( c && isAscending( pmr->n.anMove ) ) {
              /* ascending moves: invert */
              for ( i = 0; i < ( c << 1); ++i ) 
                if ( pmr->n.anMove[ i ] > -1 &&  pmr->n.anMove[ i ] < 24 )
                  /* invert numbers (other than bar=24 and off=-1) */
                  pmr->n.anMove[ i ] = 23 - pmr->n.anMove[ i ];
            }


> A specific case is a valid move:
> 
> 19/18 18/off, which became anMovep[] = { 17, -1, 18, 17, -1, -1, -1, -1}
> 
> which was not a legal move, as the 18 point was
> empty. CanonicalMoveOrder needs to be given a direction flag to allow
> it to sort the moves into the correct order.

No, the code above should take care of it.

Maybe there is a bug in isAscending.

Jørn

Attachment: pgpH_hnRjbf6T.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]