Winboard Forum

or consequent changes?

Hello,

1.

9250 <second: feature myname="Aristarch 4.50 (c) 2004 Stefan Zipproth"
9250 >second: accepted myname
9250 <second: feature variants="nocastle"
9250 >second: accepted variants

As the second engine Aristarch will never play normal chess as a winboard engine in two machine mode in wb 4.6.2. Winboard says: second engine does not play this. If Aristarch is the first engine, it works fine.


2.

A non coventional move input from a machine or you type in a move like f2f1Q, then winboard parse it as a correct move and send it to the (other) machine. But many engines, or some engines, I don't know, get tears in the eyes and explain such moves as illegal. The old winboard, I tested it with version 4.2.7, change such moves to f2f1q or n and so on and for all the universe is all right.



Harry

Harry wrote:9250 <second: feature myname="Aristarch 4.50 (c) 2004 Stefan Zipproth"
9250 >second: accepted myname
9250 <second: feature variants="nocastle"
9250 >second: accepted variants

As the second engine Aristarch will never play normal chess as a winboard engine in two machine mode in wb 4.6.2. Winboard says: second engine does not play this. If Aristarch is the first engine, it works fine.

Well, this is desired behavior, right? If Aristarch does not play normal Chess, it should not be used in a two-machines game of normal Chess. I suppose everything would work fine if you switched the variant to 'nocastle' before clicking Two Machines.

That it works when Aristarch is the first engine should be considered a bug. I don't want to let WinBoard exit immediately when the first engine does not play the current variant, though, but give the user the opportunity to switch variant through the menu, in stead. It really is a disastrous situation, though, because WinBoard uses the first engine in any mode, even Edit Position, to check move legality. But I am not sue how to solve that. I can gray out all menu items, but there is no mode I can switch WB to that would not need the engine.

A non coventional move input from a machine or you type in a move like f2f1Q, then winboard parse it as a correct move and send it to the (other) machine. But many engines, or some engines, I don't know, get tears in the eyes and explain such moves as illegal. The old winboard, I tested it with version 4.2.7, change such moves to f2f1q or n and so on and for all the universe is all right.

Hmm, I thought I fixed that before, so we might have a regression here. Or perhaps I only fixed it for when the opponent engine says such a thing. Users rarely type moves. I will check it.

[Edit] OK, it should be fixed now in the beta version. The error might have crept in with the new parser. I convert any alphabetic promo character to lower case now immediately in the parser, so this should not occur anymore. Thanks for reporting.

I think, it is difficult to change so much and be furthermore compatible to the old version. And no one can test all and all the old engines.

Yes, users rarely type moves. I found the upper case promotion letter problem in an two machine game. Amy 0.8.7b use such unusual notation. And then I am looking what happens, when Itype it.

Aristarch plays normal chess.
The interpretation of the variant-feature is strange, odd, curious (what is the right word?). In the old winboard protocol the new-command also tells an engine to set the variant to normal chess. So, if the engine lists some variants an entry 'normal' is o.k. but it is not needed. I think, perhaps it was a work around for machines, which use no variant-feature-command, but plays variants. For example Spike or machines with protocol 1. I don't know, but this is the reason, why Aristarch plays normal chess in the old winboard.

Thanks
Harry

Well, if Aristarch does play variant normal, it is definitely in error by not listing it in the variants feature. The specs require engines to list "normal" when you play it, and this is also a logical necessity, because there are engines that do not play variant normal, and there has to be a way for them to indicate that. Backward compatibility does not extend to bugs and shortcomings, so that engines that relied for their correct operation on such defects will find themselves in trouble when the defects are fixed.

There is an (undocumented) option -firstFeatures that should be able to provide a work-around, though. Try to install Aristarch with on the engine line the extra option

-firstFeatures 'variants="normal,nocastle"'

and see if that fixes the problem. (I hope I remembered correctly how to use this; I actually never used it myself.)