icsDrone

[hgm]

OK, I repeated the event, because the original log had already been overwritten. What I did now as:

1) Start icsDrone with the command

./icsdrone -icsHost localhost -icsPort 5000 -handle FairyMax -password XXX -daemonize on -program fairymax

2) I challenged FairyMax for a 1 0 unrated game, which it accepted. Fairymax was assigned white by the ICS, and started with 1.d4. I replied 1... Nf6.

3) After that FairyMax seemed to hang. I waited until it had 2 sec on the clock, and then aborted the game by disconnecting myself (so FairyMax stayed logged on).

4) I connected again. FairyMax immediately challenged me to resume the adjourned game. I accepted. The position after the first 2 ply was presented to me, and FairyMax clock started running at 1:00 (an ICS bug?).

5) Again, it did not move. So I disconnected again when time its had nearly run out.

6) I connected again. FairyMax immediately challenged me, but this time I declined.

7) Then I tried to resume the game from my end, and typed "match FairyMax" to do so. Then I got the reply

FairyMax tells you: Sorry I only play regular chess.

After this, I uploaded the file FairyMax.log in the icsDrone directory to http://hgm.nubati.net/FairyMax.log .

[Michel]

Thanks!

However I assume our messages crossed each other...

Can you comment on the reason why a resumed blitz game would become a "non-standard" one?

[hgm]

Ah yes, indeed they crossed.

I agree that non-standard looks indeed bizarre here. This might very well be an ICS bug. OTOH, XBoard seems to have no trouble with it. I thought that 'non-standard' is ICS speak for normal Chess starting from a position different from the standard opening position (like against KBNK bots and such), so there is no reason for a regular Chess bot to refuse such a game. But this could very well be fixed in the ICS.

The other problem (why it does not move, except for the first move with white) is more serious, though:
icsDrone sends the move in non-compliant notation (SAN) to the engine!

[Michel]

so there is no reason for a regular Chess bot to refuse such a game. But this could very well be fixed in the ICS.

I agree. Provided that other variants do not become "non-standard" as well...

The other problem (why it does not move, except for the first move with white) is more serious, though:
icsDrone sends the move in non-compliant notation (SAN) to the engine!

Ah yes. This is because icsdrone has no built in chess knowledge. On FICS one can get the movelist in LAN format (moves l) but this seems not to be the case on other ICS's.

I guess the correct way of handling this is, if the server does not support moves l, is to
not ask for the movelist (at the risk of missing a 3-fold repetitions and such).

On the other hand the engines I have experience with have no problem handling SAN move input.

EDIT: Ok I see the problem is not only with an adjourned game. This is indeed
a bug as it is possible to get the LAN move from the board string.

[hgm]

I will definitely scrutinize the ICS code to see where this 'non-standard' is coming from. It seems weird.

Not being able to interpret the SAN of a move list indeed seems a serious problem, for resuming games. But adjourned games are only a 'second-order problem'; it would be good if it could at least play an uninterrupted game. I can always put it on the ICS with 'noescape' (at least I hope the public ICS code supports that...).

Beware that the long-algebraic move in a style-12 board never contains a promotion suffix. Only the SAN does!

[Michel]

I will have a shot tonight at disabling the movelist.

Beware that the long-algebraic move in a style-12 board never contains a promotion suffix. Only the SAN does!

Hmm I have to take your word for it. On FICS I have never seen any problems with promotions. Perhaps FICS does add a promotion suffix in the LAN case?

[Michel]

On FICS the LAN moves contain a promotion suffix. See below. I do not know on ICC
unfortunately. Still I am quite suprised by your assertion.

\012\015<12> rnbq--Br pppkb-pp -------- ---p---- ---p---- -------- PPP--PPP RNBQKBNR B -1 1 1 0 0 0 9 IOEO tester -1 2 12 40 35 166188 117455 6 P/f7-g8=B (0:00.164) fxg8=B 0 1 0

[hgm]

Ah yes, you are right. On freechess.org they both seem to have promo suffix. Not sure if it was on ICC or on the public FICS code then. If only the latter would have this problem I should of course fix it.

[Michel]

No you are right. On ICC there is no promotion suffix in the LAN move. How ugly.

It is not a big problem. I was not aware of it.

<12> ------Q- -------- -------- --pK---B --P----P ---k---- -------- -------- B -1 0 0 0 0 0 435 GnuCheese MFnagamine -1 1 0 14 1 22 8 58 P/g7-g8 (0:00) g8=Q 0

[hgm]

Indeed, it is easy to work around it. But it took me a fair amount of time to figure out what the problem was (after I switched to using the LAN move in XBoard), or in fact that there was a problem. (Under-promotions are rare, and a missing promotion suffix in XBoard defaults to Queen...) And this was quite unexpected.

BTW, in case icsDrome also handles crazyhouse: in LAN the from-square of drop moves is @@, so the LAN move is not compliant with WB protocol for drops.