> One thing Scid does slightly wrong is it's reliance on "position fen"
> ...
> Anyway, the correct way is to use the "position startpos moves" command.
I recommend to do this change, it's the correct behavior and Scidb is
working well with "position startpos ...".
But consider three points:
1.
Steven wrote:
>> If you have thoroughly tested your code and you believe that there are
>> no problems, send me a patch and i willingly commit it into scid.
>>
>
> Laugh. In case you havent noticed, your fork is not in great shape.
> Sorry for the bad news :)
>
My fork??
As far as i know
> I agree that using "startpos" is the correct way.
> However it's also the most complicated and I would not be surprised if
> it does cause unexpected bugs.
Yes, i've found some issues today, but they seem resolved.
Null move needs special case, and the "sc_game moves coord"
should not retu
Steven wrote:
> One thing Scid does slightly wrong is it's reliance on "position fen"
>
>
> "position fen $analysis(fen$n)"
>
> to do UCI engine analysis. Pascal wrote all the UCI code, but cut a few
> corners.
> The obvious problem is, the engine has no way to know if it's next move will
> i
One thing Scid does slightly wrong is it's reliance on "position fen"
"position fen $analysis(fen$n)"
to do UCI engine analysis. Pascal wrote all the UCI code, but cut a few corners.
The obvious problem is, the engine has no way to know if it's next move will
immediately lead
to a draw when
