- by default, ChessGUI will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games
(if UCI is involved, ChessGUI will automatically claim)
- to claim these 2 draws before they appear on the board, WB engines must use the sequence:
1) "offer draw"
2) drawing move
3) "1/2-1/2 { Engine ... claims draw by ... }"
P.S.: Perhaps you should all send me ChessGUI debugs of all 3-fold-rep/50-move-rule draws of this ChessGUI version for scrutiny.
(mgemuh[@]yahoo{.}com)
Hi Matthias,
should this mean I no longer get problems like the one I had with Crafty?
Cheers, Graham.
No. It appears crafty may never work with that GUI. I do not send "offer draw" when it is my intent to claim a draw. I will move the claim to be sent after I send my move, but I am not going to send "offer draw" except for those cases where I want to "offer a draw".
If it doesn't work with xboard/winboard/chessgui then that's just going to be the way it is. I'm not offering a draw, making the move, then claiming a draw. That makes absolutely no sense even in any alternate reality-universe I can imagine.
- by default, ChessGUI will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games
(if UCI is involved, ChessGUI will automatically claim)
- to claim these 2 draws before they appear on the board, WB engines must use the sequence:
1) "offer draw"
2) drawing move
3) "1/2-1/2 { Engine ... claims draw by ... }"
You do realize this solves nothing? You may or may not get all three with a single read() call. This is a basic precept of stream-oriented I/O. It is a stream of bytes, not messages. They can be broken up in many different ways depending on circumstances. They are guaranteed to arrive "in order" but nothing else.
Matthias.
P.S.: Perhaps you should all send me ChessGUI debugs of all 3-fold-rep/50-move-rule draws of this ChessGUI version for scrutiny.
(mgemuh[@]yahoo{.}com)
- by default, ChessGUI will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games
(if UCI is involved, ChessGUI will automatically claim)
- to claim these 2 draws before they appear on the board, WB engines must use the sequence:
1) "offer draw"
2) drawing move
3) "1/2-1/2 { Engine ... claims draw by ... }"
P.S.: Perhaps you should all send me ChessGUI debugs of all 3-fold-rep/50-move-rule draws of this ChessGUI version for scrutiny.
(mgemuh[@]yahoo{.}com)
Hi Matthias,
should this mean I no longer get problems like the one I had with Crafty?
Cheers, Graham.
No. It appears crafty may never work with that GUI. I do not send "offer draw" when it is my intent to claim a draw. I will move the claim to be sent after I send my move, but I am not going to send "offer draw" except for those cases where I want to "offer a draw".
If it doesn't work with xboard/winboard/chessgui then that's just going to be the way it is. I'm not offering a draw, making the move, then claiming a draw. That makes absolutely no sense even in any alternate reality-universe I can imagine.
Hi Bob,
I seem to recall that this problem also arose with other GUIs such as Fritz and Shredder, possibly Arena also.
- by default, ChessGUI will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games
(if UCI is involved, ChessGUI will automatically claim)
- to claim these 2 draws before they appear on the board, WB engines must use the sequence:
1) "offer draw"
2) drawing move
3) "1/2-1/2 { Engine ... claims draw by ... }"
You do realize this solves nothing? You may or may not get all three with a single read() call. This is a basic precept of stream-oriented I/O. It is a stream of bytes, not messages. They can be broken up in many different ways depending on circumstances. They are guaranteed to arrive "in order" but nothing else.
That is clear to me.
Apart from the order, I just want people to abstain from inserting lengthy commands inbetween. The way I recommend it, there is a chance that my ReadPipeContents() may grab everything at once, and if not, then in chunks. ChessGUI relies only on the order.
- by default, ChessGUI will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games
I must be missing something here - so if ChessGUI won't terminate the game after 3-fold-rep/50-move, how will the game come to an end ? You are relying on the engines themselves to mutually agree to end the game ?
At the moment I'm still using 0.149, which is running perfectly. I have no intention of running Crafty under it, it seems I'm safer to stick to 0.149 which was never really broken apart from the issues it and many other GUIs such as Arena also have with Crafty
should this mean I no longer get problems like the one I had with Crafty?
Cheers, Graham.
Hi Graham,
even after long discusions in the programming subforum, HGM, Bob and I did not arrive at an agreement.
Bob's proposal is OK for future engines and future GUIs, but not quite compatible with already existing GUIs and one hundred old weak (buggy) engines.
To stay in sync with HGM's Winboard/Xboard, I have implemented HGM's proposal (which is more compatible with old GUIs/Engines).
Bob detests HGM's approach because it is not intuitive.
Matthias Gemuh wrote:
To stay in sync with HGM's Winboard/Xboard, I have implemented HGM's proposal (which is more compatible with old GUIs/Engines).
Matthias.
I think it is important that you stay in synch with HGM's Winboard/Xboard. That is the native environment for WB engines, so I think your approach is 100% correct.
- by default, ChessGUI will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games
I must be missing something here - so if ChessGUI won't terminate the game after 3-fold-rep/50-move, how will the game come to an end ? You are relying on the engines themselves to mutually agree to end the game ?
At the moment I'm still using 0.149, which is running perfectly. I have no intention of running Crafty under it, it seems I'm safer to stick to 0.149 which was never really broken apart from the issues it and many other GUIs such as Arena also have with Crafty
Hi Ray,
ChessGUI 0.152 will no longer claim 3-fold-rep/50-move-rule for WB vs. WB games by default, but there is an option "GUI claims WB draws"
I recommend ChessGUI 0.152
