[Top][All Lists]
[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
pgpH_hnRjbf6T.pgp
Description: PGP signature