Codex is also very good at analyzing errors (just copy/paste the engine log). Meanwhile I have published version 1.2 that contains a lot of fixes, tweaks, supports dual engines and it will end a game if it detects draw-by-repetition (otherwise a match between two engines in which moves were repeated would always end with one of the engines losing on time).
You can select and configure an engine by right-clicking in the log.
I have still not written a single line of code. Can you test again with this version?
Regads,
GW
Last edited by gwiesenekker on Fri May 29, 2026 02:34, edited 1 time in total.
I have tested this version with the latest mobydam.exe, and mobydam requires 'hub' as the first argument to launch it in hub mode. 'We' have added that option to the engine-parameters dialog box, so before you open mobydam you first edit the engine-parameters and set 'launch-hub-argument' to 'hub' (which is the default).
I also noticed the following: GWD uses from-square x to-square x captured-square(s) as the notation for captures, but if you capture only one piece the captured-square is not necessary and mobydam expects from-square x to-square. 'We' have updated the move notation send to the hub to from-square x to-square if only one piece can be captured.
Does mobydam send 'info' messages while pondering? It stays very quiet after 'go ponder'.
28x19x23 also does not work. Perhaps Mobydam expects non-capture moves only as captures are non-reversible for draw-by-repetition detection (but regular man-moves are also non-reversible).
I found the answer by examing Mobydam's source code. 'We' will add 'send-starting-position' as an engine-parameter option. If 'false' the position will be sent after the last non-reversible move (which will be most moves except king moves).
gwiesenekker wrote: Fri May 29, 2026 02:32
I have tested this version with the latest mobydam.exe, and mobydam requires 'hub' as the first argument to launch it in hub mode. 'We' have added that option to the engine-parameters dialog box, so before you open mobydam you first edit the engine-parameters and set 'launch-hub-argument' to 'hub' (which is the default).
IIRC scan also needs the hub command line argument.
I also noticed the following: GWD uses from-square x to-square x captured-square(s) as the notation for captures, but if you capture only one piece the captured-square is not necessary and mobydam expects from-square x to-square. 'We' have updated the move notation send to the hub to from-square x to-square if only one piece can be captured.
Here is what the protocol doc says:
The move format is the same as standard notation for quiet moves, for example "32-28". For captures, all the captured pieces (but not the pivots) are included in any order like this: from x to x captured x captured ... without any spaces. For example "28x19x23".
This seems pretty clear, and there are no optional formats. IMO if we are going to design around the hub protocol then we should treat it as a standard and not gratuitously deviate from it. Of course there will be some engine specific commands for some settings that are unique to a particular engine. But I don't see any reason to deviate from the protocol for the pos command.
As it turns out I was put on the wrong foot here because Mobydam accepted the first couple of game moves when playing from the starting position until the first capture, so it looked like it did not accept the capture. As it turns out Mobydam expects king-moves but does not generate an error if the source-square is not a king.
All these behaviours are now behind four additional hub-parameter options that are not sent to the engine:
gui-hub-launch-argument: free text; default empty but can be set to hub, -h, --hub, whatever the engine expects.
gui-send-start-position: boolean; if true (default) the starting position and all game moves are sent (useful for time-management, GWD uses a Gaussian or Lorentzian distribution when playing a game with more time spent in middle-game positions); if false the position after the last non-reversible move is sent followed by all (reversible) reversible moves played for draw-by-repetition detection
gui-single-captures-include-capture-square: boolean; if true (default) from-square x to-square x capture-square is sent; if false (probably no longer needed) from-square x to-square is sent for single captures
gui-ponder-sends-info: boolean; if true (default) the engine sends info messages while pondering and stops with done move= and ready, this allows proper state-management of the engine by the GUI; if false the engine does not send info messages and also not done send move= and ready (that is how Mobydam seems to work for now). That is not ideal as you do not know for sure the state the engine is in (Is it pondering? Did it receive the stop command?)
GW
Last edited by gwiesenekker on Fri May 29, 2026 12:28, edited 1 time in total.
I have used (in linux) a shell script mobydam.sh as a wrapper to provide the options and "hub" argument to mobydam as a work around.
There is no response to "go ponder" because of the set-param of ponder to false. Even with ponder=true, I have interpreted the protocol as "go ponder" will only be sent by the GUI after the engine reports a "done" that includes a ponder move. Is that reasonable? GUI sending "go ponder" without a previous ponder move will mess things up.
I expected the moves in the "pos" command to be non-capture king moves only, for the purpose of draw detection, due to the wording in protocol.txt. I agree now that any moves in the standard notation should be accepted. Still, I like you adding 'send-starting-position' as an engine-parameter option.
Version 1.4 is published on github. You should be able to play a match between Kingsrow and Mobydam with this version. Note that if you want to use GWD as a hub engine you need an updated version (not published yet on github) available from my SFTP server: it fixes the 'info' message-storm that GWD sends if the position is bad and all moves seem to be losing. As GWDs neural network has not been trained on positions with less than 7 pieces and the neural network generalizes poorly towards those positions you must (down)load at least all 6-piece EGTBs (about 22GB, also available from my SFTP server) for realistic evaluations in the late middlegame.
I realized MCTS is a specific GWD option, so 'we' have added now a boolean 'gui-engine-supports-mcts' parameter. If true 'go mcts' is sent to the engine when the MCTS button is clicked.
While playing with version 1.4, pondering appears to have a problem. From protocol.txt: "go ponder" works like in UCI: the expected opponent move, chosen by the engine during the previous search, is already present in the position.
I don't see the expected opponent move included in the position.
And a minor issue: when starting a game, I'd like to see a "new-game" command.
'We' have added an evaluation-bar that shows the evaluation from engine 1's perspective controlled by two additional gui-only engine parameters: 'gui-score-perspective' (side-to-move, white or black), 'gui-evaluation-bar-score-max' and 'gui-evaluation-bar-depth-min'.
Good point, currently 'go ponder' behaves as 'go analyze'. Perhaps we can have a quick show of hands here: do all engines support 'go analyze', so when browsing a game the GUI continuously sends 'go analyze'? 'go ponder' should work as Harm/UCI mentions?
I have still written not a single line of code BTW.
gwiesenekker wrote: Fri May 29, 2026 16:40
Good point, currently 'go ponder' behaves as 'go analyze'. Perhaps we can have a quick show of hands here: do all engines support 'go analyze', so when browsing a game the GUI continuously sends 'go analyze'? 'go ponder' should work as Harm/UCI mentions?
Kingsrow supports both go analyze and go ponder, always using the last position that the UI sent with the pos command. I'm not sure if there was more to that question.
