icsDrone

[Michel]

While we are at it. I noticed on several occasions that the server multiplies the increment by 10. E.g. see the following line

Creating: Michel (1558) GnuCheese (1882) rated wild/4 2 120\012\015

The board however has the correct increment (12).

Perhaps the server computes in tenth's of a second.... This does not seem to be the case on FICS however.

[hgm]

I also can apparently kill the server reliably by issueing a simple "sought" command....

I cannot find anything suspicious in the code that handles 'sought'. It is a very simple code, just a loop over the seek-ad list calling a routine to print one seek ad. In addition, I don't seem to be able to trigger the crash: when I enter a 'sought' command, the ICS processes it without any problems.

Yet, it is clear the crashes always happen during a ' sought'. I have the ICS log all input, and when I find it has crashed, the last input it received is always a 'sought' command. (Well, 'always' here means 4 times.)

I have started up a version now that prints some output to the log during execution of a 'sought' command. Could you try if you can trigger the error in the same way as you triggered it before?

(I still haven't fixed the other two bugs you reported.)

[Michel]

Could you try if you can trigger the error in the same way as you triggered it before?

Ready to oblige!

It happens after a seek 1 0 mf. Even though the server rejects the command
(not understanding the mf suffix) apparently it still manages to corrupt the seek list, triggering a crash after sought.

[hgm]

OK, thanks, this is extremely helpful. Apparently the counter for seek ads is incremented even when the seek command is rejected. The ´sought´ command then crashes when it tries to print the non-initialized 5th ad:

p1: 'seek losers'
seek 0 type = 1
p1: 'stop_1135517749'
p1: 'set width 240'
p2: 'sought'
seek 0 type = 1
msgtext = 0 1802 GnuCheese 2 12 rated losers

p1: 'ping_1135517749'
p2: 'accept gnucheese'
p2: 'match gnucheese losers'
p2: 'help losers'
p1: 'start_1135517749'
p1: 'seek suicide'
seek 1 type = 1
p1: 'stop_1135517749'
p1: 'set width 240'
p1: 'ping_1135517749'
p2: 'match gnucheese suicide'
p2: 'help suicide'
p2: 'help wild'
p2: 'next'
p1: 'start_1135517749'
p1: 'seek w6'
seek 2 type = 1
p1: 'stop_1135517749'
p1: 'set width 240'
p1: 'ping_1135517749'
p1: 'start_1135517749'
p1: 'seek w5'
seek 3 type = 1
p1: 'stop_1135517749'
p1: 'set width 240'
p1: 'start_1135517749'
p1: 'seek w5 mf'
p1: 'stop_1135517749'
p1: 'set width 240'
p1: 'start_1135517749'
p1: 'sought'
seek 0 type = 1
msgtext = 0 1802 GnuCheese 2 12 rated losers

seek 1 type = 1
msgtext = 1 1802 GnuCheese 2 12 rated suicide

seek 2 type = 1
msgtext = 2 1802 GnuCheese 2 12 rated wild 6

seek 3 type = 1
msgtext = 3 1802 GnuCheese 2 12 rated wild 5

seek 4 type = 0

This should give me enough info to find the bug (especially since I now know how to trigger it)!

[hgm]

OK, it should be fixed now. I am ashamed to say this was actually a bug I introduced myself: the original seek command was not at all like the FICS seek, and accepted only 2 or 4 (for time-odds) integers as parameters, which would never refuse the command (and at worst ignore arguments, and replace the times for the user's defaults). So no category/board, color and rated choice, like in the match command. To cure that I used the parsing routine of the match command arguments for seek as well, but this parser could return with an error. In that case I aborted creating the seek ad, but I had not realized the 'valid flag' for it had already been set.

You were right about the time increment: the ICS keeps it in deci-seconds, so it has to be divided by 10 every time you print it (and multiplied by 100 every time it is used to update the clocks, which have msec precision). I remember having fixed this before in one other place. No idea why they do this; it seems completely pointless, as there is no way to enter fractional increment! When I grep on wIncrement all uses of it now seem to have a /10 or *100 with it, so this should really be the last problem of its kind.

The w3 and w4 setup problems were also my fault; at some point I had re-ordered the pieces, and A is now using the code that was formerly used by Q. The routine to generate random setups was not adapted for this.

All should be fixed in the version I have running now. Thanks for helping!

[Michel]

Some more issues. I am unsuccesfully trying to get a suicide game going.

First I post a seek add

seek 1 0 suicide

which is fine (veryfied with sought).

Replying with "play 0" (the seek #) yields

You accept the challenge of GnuCheese.
PROBLEM LOADING BOARD. Game Aborted.

On the other hand doing

match gnucheese 1 0 suicide

gives

No such category/board: suicide/0

[hgm]

That is indeed a bit inconsistent. Apparently I should copy some more code from the 'match' to the 'seek' command, so that it doesn't only see if the arguments can be parsed, but also whether they are valid.

Suicide / losers / giveaway is not implemented in the public ICS code. Originally only orthodox Chess and bughouse were. The ICS was even programmed to make an error exit when there was a game without 1+1 King.

The category/board arguments are interpreted by the ICS as a filename, and the file contains the initial position of that variant. I added the possibility to add rule modifiers in these files, so 'variants' could be more than just playing from a non-standard opening position. But I never got to adding code to implement forced capture (and a modifier code to switch it on). It should be easy enough to check if the mentioned file exists, though.

From looking at the code it seems this ICS does have the possibility to inform the user of placing and removing of all seek ads. On FICS this can only done with ivars (not implemented) and on ICC with datagrams (vry ICC specific), so I thought it would not be possible in the public code. So auto-refresh of Winboard's seek graph does not work on my ICS. I should adapt WinBoard to also understand the mehanism by which it could work there.

[Michel]

One more:

On variants where castling is not allowed (e.g. wild/2) the ICS still sends
boards with full castling rights. I checked and this does not seem to be the case on FICS.

This makes it more difficult from the engine's point of view since it now needs an explicit variant "nocastle", whereas otherwise variant "normal" would be sufficient.

[Michel]

I should adapt WinBoard to also understand the mehanism by which it could work there.

Isn't is a bit dangerous to implement yet another mechanism for this? Wouldn't it be better to implement FICS's system of ivars.

[stevenaaus]

( Well yous have convinced me to stick with FICS for Scid vs PC, and not worry about ICS. )