fast damexchange games

[MichelG]

I have tried playing games with damexchange with a thinking time below 1 minute, but i suspect none of the current programs can do that.

Technically, in the GAMEREQ message damexchange has a 3 character field for playing time in minutes. I think most programs interpret that to be an integer value between 1 and 999.

What i propose is to interpret the field as a floating point number, such that "0.5" would indicate a thinking time of 30 seconds and ".05" a thinking time of 3 seconds per game. With something similar in the time field of the MOVE message.

Note that at such high speeds, the program should not include the time to communicate and do user interface stuff into the thinking time.

How would you fellow programmers feel about this? Are there already programs that would support this?

[BertTuyt]

Michel, changing the definition for the 3 character field could create backwards compatibility issues.

Another possibility (but depends on how the DXP Programs have so far implemented DXP...), is to sent a gamereq with 02 in the version field.
Normally this should be 01, and was meant for future updates.
I can imagine that most programs don't look at this filed code, but im not sure.
If not used, than the receiving program could sent an acknowledge code of 4 (which is also not implemented), which indicates that the version 2 protocol is recognized, and the caller could sent a different string with new options....

But this also might not work in the end...

Bert

[MichelG]

Michel, changing the definition for the 3 character field could create backwards compatibility issues.

Another possibility (but depends on how the DXP Programs have so far implemented DXP...), is to sent a gamereq with 02 in the version field.
Normally this should be 01, and was meant for future updates.
I can imagine that most programs don't look at this filed code, but im not sure.
If not used, than the receiving program could sent an acknowledge code of 4 (which is also not implemented), which indicates that the version 2 protocol is recognized, and the caller could sent a different string with new options....

But this also might not work in the end...

Bert

Technically using a dot (.) does not break the standard and could be implemented in existing programs without changing the protocol. (Nowhere it says time should be an integer).

In any case both options are possible and in both cases it requires support in the programs.

But there is only any use if multiple programs want to support fast damexchange games.

[Walter Thoen]

I am currently working on connecting a HTML5 GUI to an engine using DamExchange as the protocol.

My vote would therefore go to a new version 02 in which also Fisher time control options would be included. I would propose to represent time in three parts: Minutes (3 bytes as version 01), Seconds (2 bytes, valid range 00 to 59), Fisher Seconds (2 bytes, valid range 00 to 99). Fisher time controls are very popular damserver.kndb.nl and it would be nice to play against an engine with Fisher time as well.

If there ever comes a version 02 of the DamExchange Protocol, then I wonder if some other features can be improved as well. For instance, ending games is not very well handled in version 01 in my opinion. I think that it would be useful for instance when during engine - engine matches a game can be ended if an engine claims a win or draw based on egdb data (and the other engine acknowledges). This could save many unnecessary moves and avoid many unknown results if the maximum number of moves is hit.

Regards,
Walter