A small request

[F.Huber]

To see what WinBoard sends you can start it with the 'Additional option' -debug, and look in the winboard.debug file it creates.

Aah, that's great, I've missed such a feature in WinBoard since a long time!

Well, your new version is indeed working quite well, I'm only still trying to find the best behaviour of my adapter when the user activates 'Edit mode.
Currently it simply ignores the 'force' command, and only after the user has made his first move in 'Edit' mode, it displays an error message
"ERROR: 'Edit' mode is not supported by this engine! Take back the move(s) and deactivate 'Edit' mode again!".
Better would be to display this message already directly after receiving the 'force' command, but such a 'force' is also sent in other situations (e.g. when starting a new game), so the message would pop up also in situations where it won't be sensible.
The best way would of course be, if the user couldn't even activate the 'Edit' mode at all for some engines, but this would require such an additional option "feature edit=0" - that's why I've suggested this idea.

And there's still an other problem that I have to solve, but this has nothing to do with WinBoard:
For my emulator the user can choose between WinBoard and Arena as GUI for MessChess, and unfortunately Arena handles this 'Edit' mode in a completely different way. If I switch on 'Edit' mode, Arena doesn't send anything to the engine, it even doesn't send any of the following user moves to the engine, until the user exits 'Edit' mode again and makes his first 'normal' move (or tells the engine to move) - only then Arena sends the 'force' and then all user moves at once.
That's in fact a very annoying behaviour, because so the user maybe enters many moves, and gets informed only at the end that the engine doesn't support this mode!
This is one of the reasons why I prefer WinBoard as GUI for my emulation program.

[H.G.Muller]

Well, the best behavior would be to not complain against 'force' until after you receive a second user move in force mode. Because only at that moment you get into a situation that the engine cannot handle. Up to that point you could still hope for a 'go' command to follow the move (as indeed it would when you switched to Machine White/Black out of turn). So the adapter backlogs the first move, sends the backlogged move to the engine on reception of 'go', and throws away the backlogged move after reception of 'undo' (making it ready to receive and backlog another move). In other words, do what CECP orders you to do when you can.

If you receive a move when you already had one backlogged you can complain through a 'tellusererror' popup that the engine cannot handle that. There is no need to request the user to take that second move back; the adapter itself can order the GUI to do that, through an 'Illegal move' command. So you just ignore that move, and make sure the GUI will have ignored it too (by taking it back). At some point the user will get tired of entering moves that will immediately be rejected, and switch to Machine White/Black to cause sending of a 'go', or will start a new game or a new engine.

Not sure what Arena would do when one of the moves it sends to the engine would get an 'Illegal move' response. I suppose it has no way to know which move was the one the engine complains against, unless it sends 'ping' between after every move to make sure the engine has accepted it silently. I guess that makes Arena non-compliant. I must admit, though, that WinBoard also floods an engine with moves in some situations. In particular when using a PGN game as opening line. This was a great annoyance in the WinBoard Alien Edition for variant 'alien', where the engine is supposed to reply to every move with a FEN for updating the board. (Which is needed in variants where moves can have unexpected side effects that WinBoard is unaware of.) It means the PGN gets parsed without the board being properly updated, which of course leads to spurious 'Impossible move' claims by WinBoard against what is in the PGN.

[F.Huber]

Well, the best behavior would be to not complain against 'force' until after you receive a second user move in force mode. Because only at that moment you get into a situation that the engine cannot handle. Up to that point you could still hope for a 'go' command to follow the move (as indeed it would when you switched to Machine White/Black out of turn). So the adapter backlogs the first move, sends the backlogged move to the engine on reception of 'go', and throws away the backlogged move after reception of 'undo' (making it ready to receive and backlog another move). In other words, do what CECP orders you to do when you can.

Yes, that would be possible too, but that's much more complicated to handle in the adapter!
And the earlier the user gets informed about this 'non-existant edit mode', the better. As I already said, immediately after the 'force' command would be the best solution, but that's not possible, because 'force' is also used in other situations.

I've also tried the method with sending "Illegal move" back to WinBoard (for each move while being in 'Edit' mode) until the user leaves the 'Edit' mode again, but this doesn't work, because WinBoard doesn't send any command to the adaptor when the user just switches to 'Machine White/Black' again, so the adapter can't know, if WinBoard is still in 'Edit' mode or not, and whether the next 'usermove' should be accepted or rejected again.

I must admit, though, that WinBoard also floods an engine with moves in some situations. In particular when using a PGN game as opening line.

Yes, that was one of the reasons why I've now implemented this new feature (allowing multiple moves) in my adapter.
But it works fine with WinBoard: when I load a PGN file, WinBoard sends a 'force' first, and then all moves in a row. At the end the user has just to activate 'Machine White/Black' again, depending on whether he wants to make the next move or the engine should move.
And if the engine doesn't support 'Edit' mode - well, the user get's the same error message from the adapter, and can simply undo all moves with [<<] or just start a new game.

[H.G.Muller]

Yes, that would be possible too, but that's much more complicated to handle in the adapter!
And the earlier the user gets informed about this 'non-existant edit mode', the better. As I already said, immediately after the 'force' command would be the best solution, but that's not possible, because 'force' is also used in other situations.

I've also tried the method with sending "Illegal move" back to WinBoard (for each move while being in 'Edit' mode) until the user leaves the 'Edit' mode again, but this doesn't work, because WinBoard doesn't send any command to the adaptor when the user just switches to 'Machine White/Black' again, so the adapter can't know, if WinBoard is still in 'Edit' mode or not, and whether the next 'usermove' should be accepted or rejected again.

There is no need for the adapter to know that. It only has to know what the engine can handle. If it receives a usermove that the engine could not handle (because it is a move for the side that the engine plays, and the engine cannot switch sides), it should reject it. If it gets a usermove that can be sent to the engine, but to which the engine would automatically reply, while the adapter is in force mode (so that a reply is unwanted), it should backlog the move and wait for 'go' to send it, or 'undo' to throw it away.

Sounds simple enough to me.

[F.Huber]

There is no need for the adapter to know that. It only has to know what the engine can handle. If it receives a usermove that the engine could not handle (because it is a move for the side that the engine plays, and the engine cannot switch sides), it should reject it. If it gets a usermove that can be sent to the engine, but to which the engine would automatically reply, while the adapter is in force mode (so that a reply is unwanted), it should backlog the move and wait for 'go' to send it, or 'undo' to throw it away.

Sounds simple enough to me.

Well, not really simple enough.

How should the adapter know what the engine can handle (before it has actually sent the move to the engine)?
This would mean the adapter had to keep track of the side who has the turn (i.e. if the move is a white or black move and if the engine has the white or black side), and this can change anytime in the game, if the user switches the sides.
That's what I meant with "that's much more complicated to handle in the adapter".

[H.G.Muller]

Well you know whether the engine is capable of accepting a sequence of moves to set up a position, right? How else would you decide whether the adapter should complain against being put in 'force' mode? And I though the main problem was that it is not possible for the engine to change sides.

The adapter doesn't have to keep track of who has the turn at all. It just should not accept two moves in a row. I think this would do it:

Code: Select all

Move backlog, usermove;
Boolean play = FALSE, thinking = FALSE;
while(1) {
  lastCommand = command;
  command = ReadFromGUI();
  switch(command) {
    case NEW:
      ResetEngine();
      backlog = usermove = 0;
      play = TRUE; break;
    case USERMOVE:
      if(backlog) SendToGUI('Illegal move');
      else if(!play) backlog = usermove;
      else thinking = TRUE;
      break;
    case FORCE:
      play = FALSE; break;
    case GO:
      if(backlog) {
        usermove = backlog; backlog = 0;
        thinking = TRUE;
      } else if(usermove) SendToGUI("tellusererror cannot change sides; please switch back to Edit Game");
      else thinking = TRUE;
      play = TRUE;
      break;
  }
  if(thinking) {
      if(!usermove) AskEngineToStart();
      else SendToEngine(usermove);
      move = ReadFromEngine();
      SendToGUI("move " + move);
      thinking = FALSE;
  }
}


[F.Huber]

I think this would do it:
...

Thanks, but my version of the adapter is already working!

It's just so, that we have different opinions about the best way to solve this problem:
I don't see why the user has to enter 2 moves in 'Edit' mode before he is informed, that the engine doesn't support this feature.
The best method would be to not even accept switching to 'Edit' mode for such engines, but that's not possible in WinBoard
and you just don't want to implement this (though it would certainly only need a few additional lines of code).
So I have to wait for at least one user move before sending this error message, but why should I wait for two moves and tell
WinBoard, that this 2nd move is "illegal" and should be taken back again? It's just unnecessarily cumbersome ...

And I have other things to consider as well:
First there's Arena that handles the 'Edit' mode in a different way (even with the WB protocol), then it should also work for GUIs with the UCI protocol, and finally the adapter must also work correctly when the user loads a PGN file.
My current adapter version now handles all these situations in a reasonable way, so I guess we can end this discussion now.

Thanks again for your small change of this 'Edit' mode in WinBoard,
Franz

[H.G.Muller]

Loading a PGN is not possible with such engines, right? So I don't see why that would be a problem for the adapter; it is just a can't do. A user that attempts it would lose nothing if he just had to press New Game.

For UCI you would have to test whether the list of moves presented by the position command is equal to the previous list plus the engine's reply plus one new move to figure out if the user has done something devious, and if not feed that final move to the engine.

[F.Huber]

Hi Harm,

may I request one more small change?

After manually entering moves in my adapter I've now also implemented setting up positions, but there's a small inconsistency in WinBoard:
If I load a game (either from a PGN file or from the clipboard), then WinBoard ends up in a state where none of the options in 'Mode' is checked.
That's absolutely ok, because so the user has to select any of these modes before he can continue.
But if I load a position (either from a EPD/FEN file or from the clipboard), then WinBoard is in 'Edit Game' mode at the end.

I think loading a position should work the same way as loading a game, i.e. not switch to 'Edit Game' mode at the end, but just end up in the same state as after loading a game (with no options checked in 'Mode'). So the user would be forced to select any mode before he can continue, because it's quite unusual that after loading a position the user would want to change this position by manually entering additional moves (and if he really wants this, then he just has to activate 'Edit Game' mode himself).

It would be nice if you could make this small change in WinBoard as well ...

Regards,
Franz

[H.G.Muller]

Well, after loading a game the Load Game mode is checked. But it is the file menu, not in the load menu. But Load Game is a mode like the others.

I don't see the logic of having WinBoard in Load Game mode when loading a position. Load Game exists for the autostepping through the game (controlled by the P/C button in the button bar). That would not work in Edit Game mode. But there is no reason it should work for loading a position, as there is no game then.

It is not obvious what mode the user most-likely wants to switch to. Probably Analysis mode. But that would immediately cause heavy engine activity (these NN engines often take a long time to start up, and the engine-loading cannot be interrupted). So in cases where you did not intend to analyze, this could be extremely annoying. If the user wants to play from that position, there is no way to know whether he would want to play white or black. Setting it so that the user is on move playing against an engine would not cause immediate engine activity, so that would be a possibility. I guess it switches to Edit Game mode because before the latest patch it could not switch to a Machine White/Black mode to make the engine play for the color that was not on move. So if you wanted the engine to play that color, you had to enter your own move in Edit Game mode to switch the turn to the engine, and only then hit Machine White/Black to send 'go' to the engine. Now that it can it seems indeed more logical to switch to the 'playother' mode.

Not sure if it is a tiny change, though.

[F.Huber]

Ok, I didn't think of this Load Game mode in the File menu, I just saw that nothing is checked in the Mode menu, so I thought this would also be perfect for loading a position.

If there's no similar mode for loading a position, then the best option would indeed be the method you've mentioned ("Setting it so that the user is on move playing against an engine ...").
This should of course be the same for loading a game and for loading a position (either by file or by clipboard), and it should always set the user on move (e.g. if the first move after a loaded game or position is black, then 'Machine White' should be checked).
This would even be better than your last patch, because the user could immediately make his own move (if he wants) without having to set 'Machine White/Black' first (that's the same way WinBoard works when you just load an engine: it always asumes that the user wants to make the first move, so 'Machine Black' is activated by default).

So if you could make it this way, that would really be great!

[F.Huber]

So if you could make it this way, that would really be great!

Well, after almost 2 weeks I guess I don't need to wait any longer for this small (but useful) change ...

[H.G.Muller]

Well, at the moment I have more urgent things to do (plumbing, mostly) than working on WinBoard. This will remain so for at least another week.

[F.Huber]

Is the source code of 'new49x.zip' available, so that I could try to implement my suggested idea myself?

[H.G.Muller]

Normally that would be in the v4.9.x branch of my on-line repository. But I see that some forking has been taking place, and the patch for allowing out-of-turn swicthing to Machine mode was made in another version than where I implemented Duch Chess. And only the latter found its way to the repository.

I will try to merge the two branches, and upload the result.

[Edit] The v4.9.x branch should now be up to date.

[F.Huber]

[Edit] The v4.9.x branch should now be up to date.

Thanks - unfortunately I've no success in compiling it.

I've tried it with 3 different MinGW versions that I use for my CB-Emu (MAME) program, but I guess there's still something else needed for compiling a Windows version - too much trouble for just trying to change 2 or 3 lines of code.

[defrag1971]

[Edit] The v4.9.x branch should now be up to date.

Thanks - unfortunately I've no success in compiling it.

I've tried it with 3 different MinGW versions that I use for my CB-Emu (MAME) program, but I guess there's still something else needed for compiling a Windows version - too much trouble for just trying to change 2 or 3 lines of code.

How do you download the source code?

[H.G.Muller]

Click the 'snapshot' link of the latest commit.

[defrag1971]

[Edit] The v4.9.x branch should now be up to date.

Thanks - unfortunately I've no success in compiling it.

I've tried it with 3 different MinGW versions that I use for my CB-Emu (MAME) program, but I guess there's still something else needed for compiling a Windows version - too much trouble for just trying to change 2 or 3 lines of code.

I got to compile it with Visual Studio 2013, tested Duck Chess and found these bugs:

- At the Startup dialog I cannot specify the second edited engine
- The Duck shows as a black square
- In edit mode I can place the Duck one the same square of the moved piece, but it's not actually allowed (i.e. movelist 1. e4,e4 e5,e5 2. Nf3,f3 )
- Two engine match ends in "False illegal-Move claim 0-1" after just one move (playing with fairy stockfish-duck branch), i.e. 1. Nf3,d6 {+0.52/16} e5,d3 {+0.06/15}
- Human playing as White 1. c4,c6 e5,c3 {-0.23/15} 2. Nf3,e4 Nc6,d3 {-0.16/14} 3. Nc3,e7 f5,d3 {-0.14/11} 4. g3,g2 {rejected by first chess program}, Playing as Black I got this error on the first move with any move

[H.G.Muller]

- At the Startup dialog I cannot specify the second edited engine

I don't understand what this means. What is an 'edited engine'? And which engine would this be? What exactly means 'cannot'? Is the combobox greyed out?

- The Duck shows as a black square

Duck images are only provided for board sizes Petite, Middling and Bulky. (Like most fairy pieces.) In other sizes is shows up as a black square, because internally the Duck is implemented as 'inaccessible square'.

- In edit mode I can place the Duck one the same square of the moved piece, but it's not actually allowed (i.e. movelist 1. e4,e4 e5,e5 2. Nf3,f3 )

Indeed, there is no legality testing on the Duck move yet.

- Two engine match ends in "False illegal-Move claim 0-1" after just one move (playing with fairy stockfish-duck branch), i.e. 1. Nf3,d6 {+0.52/16} e5,d3 {+0.06/15}

Sounds like a Stockfish problem, as 1... e5,d3 does not seem illegal to me. So any claim to that effect has been correctly judged as 'false'.

- Human playing as White 1. c4,c6 e5,c3 {-0.23/15} 2. Nf3,e4 Nc6,d3 {-0.16/14} 3. Nc3,e7 f5,d3 {-0.14/11} 4. g3,g2 {rejected by first chess program}, Playing as Black I got this error on the first move with any move

Again, it doesn't look to me like g3,g2 is illegal. So if the engine rejects it, it would be an engine bug. Provided the engine got sent the correct move. Which can only be checked in the winboard.debug file (but for which there is little reason to doubt it).