Winboard Forum

Hi Harm,

I'm using your last WinBoard-AA.zip for my CB-Emu program, because it's in fact the perfect GUI for this emulation of old chess computers.

I would only have a request for a small change about the features 'Mode > Edit Game' and 'File > Load Game':

This option 'Edit Game' can be switched ON, but unfortunately not OFF!
The problem is, that many old chess computers don't support such a 'MultiMove' mode, and the emulator shows a popup message in this case,
but currently there's no way to switch off this 'Edit' mode again in WinBoard - maybe you could change this option 'Edit Game', so that it can be toggled (i.e. switched on AND off) by the user?

And there'S a similar issue when loading a (PGN) game: after the game has been loaded, you can't just enter your own move (if you want to continue the game) - you first have to use 'Mode > Edit Game' (or tell the engine to make the first move).
It would be more comfortable, if you could immediately enter your own move without having to activate 'Edit Game' before - I guess this would need only a very small change in WinBoard.

Regards,
Franz

I don't get this. WinBoard will always be in some mode, by definition. When you select the mode you want it to be in, it automatically leaves the mode it was in before. So Edit Game mode is switched off by selecting any of the other modes in the Mode menu (or Loading a Game). 'Load Game' actually also is a mode; you will notice a checkmark in front of the menu item in the File menu when WinBoard is in that mode after loading a PGN game. It just happens to be in another main menu. It is the mode in which auto-stepping through the game works (and can be controlled by the C/P button in the button bar).

What would you expect WinBoard to do when you 'switch off' Edit Game mode? Ignore all attempts to select or grab a piece? But that is what it does in Load Game mode, and you explicitly ask to make it never go into that mode.

It would indeed be a tiny change to switch automatically to Edit Game mode immediately, after loading a game. But I am not sure if that is what the majority of the users would want. I suppose the reason to have a separate Load Game mode at all is to protect the integrity of the game that was loaded, preventing accidental changes. Switching to Edit Game mode for instance would reset the PGN tags for players, date and event, because after editing it is no longer that game. You would no longer have a chance to see the original tags.

I am also not sure what problem exactly you want to solve. It is true that WinBoard makes the first engine follow the currently displayed position when you navigate through the game, through moves or 'undo' commands. I guess this is for historic reasons: originally WinBoard did not know the rules of Chess, (which for many variants would still be the case, now we have 'engine-defined' variants), so any move the user tried to enter had to be vetted by the engine (and rejected through an Illegal move response if not OK). This is apparently what CB-Emu does not like?

I don't know this CB-Emu. Is it a ChessBase program? If so, it seems unlikely that it is implemented as a WinBoard engine. And UCI engines would only be made aware of the position the GUI is in when they are actually set thinking. In whch case they always must be fed the entire sequence of moves from the start position to the current. So it would never know which position is in the display of the GUI while you were editing, and it would be completely useless in vetting the entered moves. (Which for orthodox Chess is fortunately not needed anymore, now that the rules of Chess are programmed into WinBoard.)

Well, if you don't know CB-Emu, I think I should first explain it a bit:
CB-Emu is a program that emulates around 400 old chess computers (Fidelity, Mephisto, Novag, Saitek, Tasc etc.).
Since some of these old chess computer are rather complicated to operate (if you don't know them), I've included
a special version (called 'MessChess') in CB-Emu that allows to use these emulated engines e.g. with WinBoard.
For this purpose MessChess uses a plugin that acts as interface between WinBoard and the emulated chess computer.
If you start MessChess and select any of these old engines, then it automatically starts WinBoard together with the
emulated engine, and for WinBoard it looks as if the engine would be a usual WB-engine.
If you would like to try this MessChess - the link is on my website: https://fhub.jimdofree.com/ (the program is CB-Emu_Pro)
CB-Emu is the main program and the included MessChess is the sub-version that uses WinBoard as GUI.

Now about about the problem with this 'Edit Game' mode in WinBoard:
Let's assume WinBoard has been started by MessChess and has loaded the specified engine.
Now I would like to enter the first few moves manually (for both sides, i.e. without the chess engine responding), so I use
'Edit Game' and WinBoard sends a 'force' command to the engine (resp. to the plugin in MessChess) - so far all is ok.
The problem is, that not all of these old chess computers have such an 'Edit' mode that allows to enter a sequence
of moves. When the plugin receives this 'force' command from WinBoard, it checks if the chess engine supports this mode,
and if not then I get a popup message "MultiMove not supported!" from the plugin.

What should I do now? I can't abort this (non-supported) 'Edit' mode, because WinBoard doesn't allow me to uncheck 'Edit Game'
again, and if I would just make my first (white) move, the engine will respond with it's first (black) countermove.
But Winboard doesn't expect any countermove in the 'Edit' mode, so there's now a situation where WinBoard and the emulated engine
are not synchronized anymore, and there's no way to continue anyhow.

That's the reason why I would like being able to deactivate (i.e. switch off) this 'Edit Game' mode again in WinBoard!
And what should Winboard do after switching off the 'Edit' mode?
Well, it should just go back to it's previous mode (or state) before I've switched on 'Edit Game' - that's just the mode that is active
immediately after starting WinBoard (with a loaded engine) or whenever it's the users turn to move during a usual chess game.
In this mode (which I would simply call 'Playing' mode) only one of the options 'Machine White' or 'Machine Black' (but nothing else)
is checked, and I can either enter my own move or tell the engine to make a move by using 'Machine White (or Black)'.
I'm sure you know the Arena GUI, and there you can just click the 'Edit' button to switch on 'Edit' mode, and clicking again on this
'Edit' button switches off this mode again.
I would say it is the usual behaviour of any option which can be switched on, that it also can be switched off again by clicking on
this option (or button) a 2nd time - not only in chess GUIs, but in almost every Windows program I know.

The other problem (after loading a PGN game) is not really a serious problem but rather an inconvenience:
after the game is loaded, I would prefer WinBoard to be in the same 'playing' mode as I've described above, so that I could
immediately enter my own move (e.g. to continue a not-finished game) without having to explicitely switch to 'Edit' mode first.
I just think that these 2 extra clicks 'Mode > Edit Game' should not be necessary to continue the game - WinBoard should be
in the same state/mode as if the game has just been 'played' instead of having been loaded from a PGN file.

When you first start WinBoard with an engine it will be in Machine Black mode. You get there by pressing New Game (if there is an engine). Without engine WinBoard will start in Edit Game mode, and all other modes except Edit Position and Load Game will be disabled.

One would expect the same to happen by selecting Machine Black from the mode menu when you still happen to be in the initial position. WinBoard does not allow this, however, because it is not black's turn to move. This is probably a legacy from the time the Machine White/Black menus were simply sending a 'go' command to the engine; of course the GUI could remember that the engine should play black but has not yet received a command that would make it play black, and just send that command when black's turn comes up. But since New Game already seems to do the same thing no one really bothered to extend the Machine Black command that way.

I think the whole problem is 'self inflicted'. You seem to associate the 'force' command with multi-move loading. That is wrong. It is perfectly possible that a single mode follows. I think WinBoard even uses the sequence "new, force, usermove, go" as standard idiom for making an engine play black. In principle an engine is supposed to be set for playing black after 'new', but this would also work for engines that are buggy in this respect.

So you have no right to complain before you receive the second move. As I assume the machines you are emulated can play with black, and would accept the white starting move in that case. You only have a right to complain if you receive a second move instead of a 'go' command. Then you can refuse that move with an 'Illegal move' command to make the GUI take it back, (with as reason "it is my turn!"), and use 'telluser' to inform him that he cannot enter multiple moves, and that his only option now is to start a new game, or select Machine Black to emit the 'go' command that you would have liked to see in the first place.

As to the Load Game issue; I still think that you use this for a very atypical application, and want to wreck WinBoard for people that use Load Game for other purposes. Most games that are loaded will end in checkmate. There would not be any continuation play. People load it for analysis, stepping through it to read the comments, or whatever. You basically want to abolish Load Game mode, because when you leave it, there is no way to get back to it.

Well, let's shorten the discussion to the really important points.

H.G.Muller wrote:When you first start WinBoard with an engine it will be in Machine Black mode. You get there by pressing New Game (if there is an engine).

Yes, WinBoard is in this 'Machine Black mode' at the beginning and during the whole game whenever it's the user's turn to move (or in 'Machine White mode', if the user has changed the side anytime).
If the user activates the option 'Mode > Edit Game'. then WinBoards switches to the 'Edit mode'.

Now could you please answer the following question:
What's the problem to allow the user to immedaitely undo this action again, i.e. to uncheck 'Edit Game' again?
WinBoard could just go back to the previous mode (i.e. either 'Machine Black' or 'Machine White'), and the user can continue as if he never had activated this 'Edit Game'.
I'm sure this would just be a very simple and small change in the code, to allow toggling this 'Edit Game' option (instead of only being able to switch it on), and this would in fact solve the problem that I have in CB-Emu with some engines that don't support such an 'Edit' mode.

Before I answer that question, let me reprocicate with another question:

What is the problem with simply clicking Machine White or Machine Black to leave Edit Game mode? Both of these would switch Edit Game mode off. So the feature you request already exists. Twice! (If you don't count Analyse, or Edit Position, which would also leave Edit Game mode, but probably not to a mode that CB-Emu supports.) Why should there be yet a third menu item that would bring you from Edit Game to Machine White/Black?

I guess the answer to your question primarily is that I don't like duplicat menu items. I'd rather remove those than creating new ones. Especially if it would be unclear what it does (i.e. what mode it would switch to).

Another reason is that it seems you want me to cater to buggy programs. You have an engine that does wrong things, and now you want me to modify the GUI to elevate this wrong behavior to a standard. As a matter of principle I am gainst such erosion of standards.

H.G.Muller wrote:What is the problem with simply clicking Machine White or Machine Black to leave Edit Game mode? Both of these would switch Edit Game mode off. So the feature you request already exists. Twice!

No, the feature does NOT exist!
I'm talking about a situation where it is my turn to move. If I enter the 'Edit' mode and would leave it with 'Machine White (or Black)', then the engine makes the next move, so this has the effect of swichting the sides - that's not what I want.

Why should there be yet a third menu item that would bring you from Edit Game to Machine White/Black?

Hmm? Where did I ever talk about a third menu item???
You could just click on the (checked) 'Edit Game' to uncheck it again!

Another reason is that it seems you want me to cater to buggy programs. You have an engine that does wrong things, and now you want me to modify the GUI to elevate this wrong behavior to a standard. As a matter of principle I am gainst such erosion of standards.

Sorry, but that's nonsense. These 25-35 year old chess computers (or programs), which are emulated in CB-Emu, are not buggy at all -
they just don't have all features of modern PC chess programs, and of course they didn't 'know' anything about WB or UCI protocols.

But I see, you just don't (or don't want to) understand what I mean (and which small change I want), so I'll stop this discussion here now ...

F.Huber wrote:

H.G.Muller wrote:What is the problem with simply clicking Machine White or Machine Black to leave Edit Game mode? Both of these would switch Edit Game mode off. So the feature you request already exists. Twice!

No, the feature does NOT exist!
I'm talking about a situation where it is my turn to move. If I enter the 'Edit' mode and would leave it with 'Machine White (or Black)', then the engine makes the next move, so this has the effect of swichting the sides - that's not what I want.

Well, but it was what you asked for: a menu item that would leave Edit Game mode without specifying to which of Machine White or Machine Black it should go. So naturally it would have gone to the mode where the engine now does the move. Because apparently you do not want to make a move yourself, as you could have done that in Edit Game mode without any need to operate a menu.

Whether switching to Machine White or Machine Black would change sides depends entirely on which color has the move, BTW. If you switch sides it is because you asked the engine to play for the side that you don't want it to play. That is a user error, not something that requires a fix in WinBoard.

Now you are probably going to argue that WinBoard refuses the 'Machine White/Black' command for the side that is not on move. In that case you would have a point which could be fixed (as I already mentioned before). But it requires something entirely different from what you asked for. And the fix would be that WinBoard just makes a mental note that it should send a 'go' command to the engine after sending it the next move the user is going to make.

But I hope you will agree that when you don't want the engine to play for the side that is currently on move, it is unavoidable that you should enter a move. And Edit Game mode perfectly allows you to do that. That move would then be sent to the engine. And after it it is the engine's turn again (without switching!), and WinBoard in its current state would allow you to set the engine playing for that side, and send a 'go' command as a result of you operating the Machine White/Black menu. So, lo and behold, exactly the same commands are sent to the engine by first making a move and then pressing Machine White/Black (whichever is accepted at the time) as what would have happened in the hypothetical fix that would you to press Machine White/Black 'out of turn', and play your move then: It would receive "usermove, go". The engine would not know what mode WinBoard was in when the move was entered.

It eludes me what is so much worse about first pressing a menu and then making a move compared to first making the move and then pressing the menu...

Sorry, but that's nonsense. These 25-35 year old chess computers (or programs), which are emulated in CB-Emu, are not buggy at all -
they just don't have all features of modern PC chess programs, and of course they didn't 'know' anything about WB or UCI protocols.

No, it is not nonsense. Because 25-35 years ago these old chess computers were not making use of an adapter / emulator to communicate with a GUI; that adapter / emulator is a recent piece of software. And it is this program that is buggy. By not accepting the sequence of commands that GUIs have used for 35 years to do the tasks they were designed to perform. Or at least by throwing up spurious error popups that confuse the user.

But I see, you just don't (or don't want to) understand what I mean (and which small change I want), so I'll stop this discussion here now ...

Well, as I explained it is you who doesn't seem to understand what you mean. As far as I am concerned this is still a simple matter of user error. Namely that you want to leave Edit Game mode while in fact what you want to do would only happen when you stay in it. (And don't give me any bullshit that 35-year old computers would not allow that, because the engine can never know which mode WinBoard is in, it can only see whether it receives moves at the proper moment.) Proper use of a GUI when the side that you want to play for is on move, is entering a move. The only reason to turn to the menu before having entered that move is that the move would trigger an unwanted automatic immediate response (e.g. set the engine thinking). But that is not the case here; the engine would not automatically start thinking, and even if it did this would not be unwanted. But the latter problem can be solved after having entered the move (by switching to the appropriate Machine mode).

In the meantime I've discovered an other possible solution that would solve my problem in an even better way.

Reading through the WB protocol commands I saw, that there's a possibility to avoid activating the 'Analysis Mode' in WinBoard:
If the engine sends a "feature analyze=0" at startup, then WinBoard refuses to switch to 'Analysis Mode' and pops up an error message "EngineXY does not support analysis".

A similar reaction for 'Edit Game' would perfectly solve my problem for engines that don't support this mode.
Unfortunately there's no such command like "feature edit=0" in the WB protocol, but I guess it won't be much work to implement this in WinBoard,
and (although not being WB standard) it would not cause any other problems, because no other engine will ever send such a command.

So my last question: would it be possible to implement such a "feature edit=0" in WinBoard (default should be edit=1), with the result, that trying to activate 'Edit Game' just returns a popup message "EngineXY does not support editing" but does NOT switch to 'Edit' mode?

You still haven't explained why pressing New Game to get out of Edit Game mode doesn't do exactly what you want. As far as I gathered the 'problem' you imagine occurs when you load an engine, and instead of starting to play by making a white move or pressing Machine White to set the engine thinking, you select Edit Game from the menu because you want to feed an opening line to the engine before starting to play. But alas, the 35-year old engine does not allow that. So you get an error popup.

Well, now you know you cannot do that. So you should either load another engine that can do it, or accept the fact of life that you can only play with white or black against this engine from the FIDE start position. If you want to play with white: just press Machine White. This will leave Edit Game mode, and make the engine do a move for white. If you want to play black: just press New Game to leave Edit Game mode and get to Machine Black mode automatically after you entered your move.

Now what is the problem? I don't see any...

Well, if it would be only at the start of a game, you are right - here I could just start a new game.
But I was also thinking about anytime in the middle of an already played game.
Imagine that anyone just want to enter a few moves by himself in the middle of a game, and after using 'Edit Game' he gets this error message.
Now using 'New Game' is no option, because then the already played game is lost.

But then it entirely depends on the engine whether this situation is recoverable or not. Because the engine already has received the 'force' command to instruct it to not respond automatically on the current move. If it reacts to that command by shutting off and requiring a reset (through a 'new' command) there is nothing that can be done. Because there is no way to reload the moves that were already played can be loaded into the engine.

This all crucially depends on the properties of the adapter. And it seems the behavior of that adapter is completely wrong. Why don't you simply fix the adapter, rather than trying to get complex work-arounds in WinBoard? After receiving the 'force' command is should just warn you that it accepts single moves only, and that you have the choice between setting the engine to think immediately (if it supports that; I can imagine it would not support switching sides either), or play a move and resume the game after it. Any subsequent moves after the first it should reject; after having received the move it should wait for 'either 'new' or 'go'.

H.G.Muller wrote:Why don't you simply fix the adapter, rather than trying to get complex work-arounds in WinBoard? After receiving the 'force' command is should just warn you that it accepts single moves only, ...

Well, you can be sure that I've already tried many different methods to solve the problem in the adapter, but nothing works.
If the adapter receives the 'force', it's already too late, because then WinBoard is already in the 'Edit' mode.
And there are only 2 ways to get out of this 'Edit' mode again:
1) either the user enters a move and uses 'Machine White/Black' after it
2) or the user clicks on 'Machine White/Black' immediately.

For point 1) the adapter could of course avoid sending this move to the engine, but WinBoard is still waiting for a move from the engine (before it leaves the 'Edit' mode again), so where should this countermove come from???
If the adapter would send the user move to the engine, then the engine would respond, but there's no way to take back these 2 moves again, because the engines I'm talking about usually also don't support taking back moves.
And if the adapter would not send the user move, but tell the engine to switch the sides, then the returned engine move would be for the wrong side and WinBoard would not accept this move (apart from what you already assumed, that those old engines also often don't support switching the sides).

And for point 2) it's almost the same, also here WinBoard waits for a move from the engine, so no matter whatever I do in the adapter - the only way is to tell the engine that it should move, and with this the user and the engine have in fact switched the sides, nothing I would want. And also here taking back this engine move again is just not possible for some engines.

So this problem can definitely not be solved in the adaptor!
But I see, you are just not interested to make one of these small changes in WinBoard (either being able to toggle the option 'Edit Game',
or to add such a feature edit=0), and I guess I'll have to accept this, so I give up now ...

F.Huber wrote:

H.G.Muller wrote:Why don't you simply fix the adapter, rather than trying to get complex work-arounds in WinBoard? After receiving the 'force' command is should just warn you that it accepts single moves only, ...

Well, you can be sure that I've already tried many different methods to solve the problem in the adapter, but nothing works.
If the adapter receives the 'force', it's already too late, because then WinBoard is already in the 'Edit' mode.

But it is not too late at all; the adapter could simply ignore the 'force' command. This is the point where your mind block is: that the world ends when the adapter receives a force command. While it is a command it can perfectly obey: it just is an advance notice that it should not automatically set the engine thinking after receiving the next move, but wait for a 'go' command. When it is mediating for an engine that always automatically responds to a move, that means it should just withhold the next move from the engine until it receives that 'go' command, and consider the move it will send the translation of the received 'usermove' + 'go'. At that point the adapter would be in the playing state it had before the 'foce' command was received.

Trying to switch out of Edit Game mode (as you originally requested) is in any case useless, because, like you say, the adapter has already received 'force' at that point, and would not be informed what mode WinBoard is in anyway. All the adapter has to go on are the 'usermove', 'force' and 'go' commands it receives. And the compliant way for getting back to the desired adapter state after 'force' is 'usermove' + 'go'. And that is exactly what WinBoard sends when you would play the move (in Edit Game mode!) and hit Machine White/Black).

So there should not be any problem, and if there is one, it is only because the adaptor reacts non-compliantly to the 'force' + 'usermove' + 'go' sequence. And that would be the adapter's fault. An inexcusable fault, because it prevents it from doing something that was perfectly possible even with the 35-year-old engine. Only when it does receive a second 'usermove' instead of the 'go' it would be asked to do something that the engine does not support, and thus have no choice to complain. The compliant CECP command for such a complaint would be 'Illegal move'. The GUI will then take back that second move that the user entered, and the user can hit Machine White/Black after all.

Well, do you really not understand my last posting where I've explained in detail the 2 possibilties after switching WinBoard into 'Edit' mode, or do you simply not read my answers and repeat your non-working suggestions again and again like a parrot?

Ok, I'll try it a last time with a concrete example:
The user (White) is playing a game against such an old engine (Black) that does NOT support 'Edit mode', 'Change Sides' and 'Take Back Move'!
The user starts with 1.e2e4 and the engine responds with 1...c7c5, so White (the user) has the next move.
That's now the situation where the user wants to enter a few moves manually to force a special variant of the Sizilian opening.
Thus he clicks on 'Edit Game' in WinBoard, and WinBoard switches to 'Edit' mode and immediately sends the command 'force' to the adapter.
The adapter receives this 'force' command and simply informs the user with an error message, that the "Engine does not support editing", but it does NOT send anything to the engine at this moment!

Now the user has the choice between 2 possible actions:
1) he can immediately use 'Machine White' (because it's white's turn): now WinBoard sends a 'go' to the adapter and waits for a white move from the engine, and WinBoard does NOT leave the 'Edit' mode until it has received such a white move!
What should the adapter do in this situation?
If it just sends this 'go' to the engine (i.e., it tells the engine to make the next move), the engine would respond with an error (meaning "Sorry, it's not my turn!"), because the engine has Black but it is asked to make a move for White (you remember, the engine does not allow to switch sides!). OTOH if the adapter does NOT tell the engine to make a move, then WHICH (white) move should the adapter send back to WinBoard??? The adapter simply HAS NO move to send back!!!
But WinBoard is in 'Edit' mode and IS WAITING for a white move from the engine (resp. from the adaptor), so it is waiting forever and there's no way to get back to the situation after 1.e2e4 c7c5 and without an activated 'Edit Game'!

Or:
2) the user could FIRST enter an own move (e.g. 2.g1f3), and THEN click 'Machine Black': in this case WinBoard sends 'usermove g1f3' and then 'go'!
Ok, now the adapter can act in 2 ways:
a) if (as you suggest again and again) it does NOT send this 'usermove g1f3' to the engine, it MUST send at least the 'go' to the engine, because else it won't have any move to send back to WinBoard (but WinBoard is waiting for a move!).
But that's the same situation as described above in point 1) - the engine is asked for the next move directly after it has made it's last move (2...c7c5), because the user's move (3.g1f3) has NOT been sent to the engine, so again the engine returns the same error ("it's not my turn!").
b) but if the adapter WOULD send 'usermove g1f3', then "GAME OVER": no matter what the adapter (or WinBoard) would do afterwards - the engine excutes the move g1f3 and calculates and returns it's countermove, and there's NO WAY to get back to the old position (or situation) again, because the engine has no 'Take Back Move' feature!

Have you got it now? If not, then ..... (I prefer to keep this to myself, because I'm a nice person )

F.Huber wrote:For point 1) the adapter could of course avoid sending this move to the engine, but WinBoard is still waiting for a move from the engine (before it leaves the 'Edit' mode again), so where should this countermove come from???
If the adapter would send the user move to the engine, then the engine would respond, but there's no way to take back these 2 moves again, because the engines I'm talking about usually also don't support taking back moves.
And if the adapter would not send the user move, but tell the engine to switch the sides, then the returned engine move would be for the wrong side and WinBoard would not accept this move (apart from what you already assumed, that those old engines also often don't support switching the sides).

Well, you have got a point there, because I generally stop reading when I reach the point where an argument goes off into La La land.

The quoted text above is just pure nonsense. WinBoard is not waiting for any move from the engine in Edit Game mode. That is the whole point of Edit Game mode; the engine is supposed to be silent, as instructed by the 'force' command. So WinBoard is waiting for the user to either enter another move (which in this case would not be acceptable), or for the user to use the menu, e.g. to switch to Machine White/Black. That would result in sending 'go' to the adapter, and only after that WinBoard would expect a 'countermove'.

So the adapter should just backlog the received move, wait for 'go', and then send the backlogged move to the engine. In the mean time the adapter could even accept an 'undo' command to take back that move, as the engine is blissfully unaware what goes on between GUI and adapter. Of course you could also relay the received move to the engine immediately, and backlog the move it receives in replay until it receives 'go'. But then it would cheat with the clocks (as these are stopped during Edit Game mode).

I have no idea why you would ever want to take any moves back. Seems to me they are just regular moves of the game you are playing, which now has advanced two halfmoves.

This is all moot, because switching sides is not what you wanted anyway. So asking WinBoard to switch side was a user error.

Ok, I'll try it a last time with a concrete example:
The user (White) is playing a game against such an old engine (Black) that does NOT support 'Edit mode', 'Change Sides' and 'Take Back Move'!
The user starts with 1.e2e4 and the engine responds with 1...c7c5, so White (the user) has the next move.
That's now the situation where the user wants to enter a few moves manually to force a special variant of the Sizilian opening.
Thus he clicks on 'Edit Game' in WinBoard, and WinBoard switches to 'Edit' mode and immediately sends the command 'force' to the adapter.
The adapter receives this 'force' command and simply informs the user with an error message, that the "Engine does not support editing", but it does NOT send anything to the engine at this moment!

Now the user has the choice between 2 possible actions:
1) he can immediately use 'Machine White' (because it's white's turn): now WinBoard sends a 'go' to the adapter and waits for a white move from the engine, and WinBoard does NOT leave the 'Edit' mode until it has received such a white move!
What should the adapter do in this situation?

Well, this obviously is the wrong thing to do. You asked WinBoard to change side. The engine cannot do that, so the adapter has no choice but requesting a popup through a tellusererror command to inform the user that the engine doesn't support changing sides, and kindly request him to switch back to Edit Game mode. After which the adapter will receive another 'force' to neutralize the 'go' it could not handle.

2) the user could FIRST enter an own move (e.g. 2.g1f3), and THEN click 'Machine Back': in this case WinBoard sends 'usermove g1f3' and then 'go'!
Ok, now the adapter can act in 2 ways:
a) if (as you suggest again and again) it does NOT send this 'usermove g1f3' to the engine, it MUST send at least the 'go' to the engine, because else it won't have any move to send back to WinBoard (but WinBoard is waiting for a move!).
But that's the same situation as described above in point 1) - the engine is asked for the next move directly after it has made it's last move (2...c7c5), because the user's move (3.g1f3) has NOT been sent to the engine, so again the engine returns the same error ("it's not my turn!").
b) but if the adapter WOULD send 'usermove g1f3', then "GAME OVER": no matter what the adapter (or WinBoard) would do afterwards - the engine excutes the move g1f3 and calculates and returns it's countermove, and there's NO WAY to get back to the old position (or situation) again, because the engine has no 'Take Back Move' feature!

Not GAME OVER, but GAME CONTINUES. Why would you want to take those moves back? Because you don't like how the engine replied to g1f3? Well, tough luck, you have no influence over what the engine prefers to play, it can reply as it pleases. That is how Chess is played. So you did not like g1f3? But that was your move, so why did you play it if you did not like it? In an OTB game FIDE rules would also not allow you to take back a move after the opponent replied to it. When playing Chess one should always enter the moves one actually wants to play. Especially when you are playing against an opponent that doesn't allow takebacks.

You could of course let the adapter pop up a warning message through a telluser command before every move (i.e. directly after it sent its own to the GUI): "Please enter the move you want to play, and not another one, because we won't allow you to take it back"...

H.G.Muller wrote:The quoted text above is just pure nonsense. WinBoard is not waiting for any move from the engine in Edit Game mode. That is the whole point of Edit Game mode; the engine is supposed to be silent, as instructed by the 'force' command. So WinBoard is waiting for the user to either enter another move (which in this case would not be acceptable), or for the user to use the menu, e.g. to switch to Machine White/Black. That would result in sending 'go' to the adapter, and only after that WinBoard would expect a 'countermove'.

Well, the quoted text is NOT nonsense at all - when I said, that WinBoard is waiting for an engine move, then of course I meant, that's it's waiting for an engine move after the user exits the 'Edit' mode by pressing 'Machine White/Black' (I thought that would be clear, so I didn't explicitely mention it, and it's not so easy for me to write so much in English).

Not GAME OVER, but GAME CONTINUES. Why would you want to take those moves back? Because you don't like how the engine replied to g1f3?

No, it's simply because you don't understand what I really want!

We are just talking about 2 different things:
You say, that I should make the move g1f3, then use 'Machine Black' and accept the engine's countermove, and then continue a 'normal' game!
But I want something else - if the adapter informs me, that the engine doesn't support 'Edit' mode, then I would just like to undo this 'switching to edit mode' again, i.e. return to the exact state before I've clicked 'Edit Game' in WinBoard AND without making any move at all (like g1f3) in the meantime!
And this is NOT possible in WinBoard, because if I click 'Machine White/Black' again to leave the 'Edit' mode (no matter if immediately or if I enter one or more moves before), WinBoard waits for a (white or black) engine move, and there's definitely no way to abort this 'waiting' (and return to the state where I can enter a move again) as long as the adapter doesn't send any such move to WinBoard.

So in short words: what I want is to simply switch OFF the 'Edit' mode again, when I realize that the engine doesn't support it, and WITHOUT any additional steps (like making 'dummy' moves that should be ignored by the adaptor and/or switching sides with 'Machine White/Black')!
And since such a 'toggling' of the 'Edit Game' mode does not exist (and you are not willing to change this), the easiest way would be to simply implement my idea about a "feature edit=0", but it seems you also don't consider this small change.

You are still talking nonsense: there are no 'dummy' moves, and the adapter should not ignore any move. The only move is the next move in the game, and it should not be ignored by the adapter, or the game would never resume.

But what you basically want is that the Machine White/Black menus should also work for the side that is currently not on move. For no good reason at all, because for the purpose of playing a chess game (for which WinBoard is designed) there is no need to do that. Modes in WinBoard are provided as tools for enabling you to do what is needed, not to fool around with and see how many you can visit and still get back in exactly the same state.

There even is a command in the CECP definition that was designed for switching an engine to playing for the side that is not on move: 'playother'. It was never implemented in WinBoard. Chicken and egg problem: no engine supports that command, so why should the GUI, and vice versa. And it should not really be needed, because the GUI should be perfectly able to backlog the 'go' command until after the next move. (This is in fact exactly what it does when the engine uses the GUI book; it backlogs the 'go' until you get out of book.)

But implementing 'playother' in WinBoard is a tiny change; in the place where it now rejects the attempt to use the menu with the message "it is white/black's turn", it should just test whether the engine supports 'playother', and if so, send that to the engine instead of rejecting the switch. That is a safe change, unlike backlogging the 'go', which interacts with the (very messy) book probing code.

So the adapter should send 'feature playother=1' at startup, and then it will receive the combination 'force' + 'playother' to get into the same state as before, with WinBoard in the same mode as before. Without the need to wreck anything for other users.

I still think this is a completely useless demand, but at least it would solve the silly situation that CECP defines commands that even WinBoard does not implement. I can do it tomorrow.

[Edit] Well, I think it already works. Version uploaded to http://hgm.nubati.net/new49x.zip .

Turned out 'playother' was already partially implemented, but only used in zippy mode. But I realized that I could not just send 'playother' without informing the book-probing code that the engine state had changed, and in the end it turned out to be easier just to mimic (after an out-of-turn Machine White/Black) the situation that arises after playing a book move on behalf of an engine (where the engine is supposed to play, but in fact is in force mode to feed it the book moves the GUI selects for it). Then I only had to set the bookSuspend flag for the engine to send it a 'go' when its turn again comes up (and it doesn't want to play a book move).

Let me know if you have any problems with it.

Ok, i've just downloaded your new version, and at first glance it seems to work!

I've not yet tested what WinBoard actually sends to the engine after switching back to the previous state by setting the engine to the 'other' side (for this I would need to add some code to my adapter to show all commands sent by WinBoard), but it does indeed reset WinBoard to the state before clicking 'Edit Game', and that's exactly what I wanted - thanks for this change!

I don't know if this is intended, but I saw that it works independently of the 'playother' setting, i.e. it doesn't matter if the adapter sends "feature playother=0" or "feature playother=1" - I can set the engine's color to the other side in both cases!?

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

But when you switch back to playing mode it sends nothing. The only thing it does (apart from modifying WinBoard's mode) is setting an internal flag 'bookSuspend', which already existed, and indicates that an engine that formally should be in a playing state has actually been switched to force mode, to give WinBoard an opportunity to feed it a book move after sending it the opponent's move, instead of allowing it to automatically making a reply itself. If this flag is set, and the engine's turn comes up without a book move being available, WinBoard will send a 'go' to make the engine do what it formally should have done automatically (namely think about its own move).

Since the book will be switched off for this type of engine, there will never be a book move, so that the 'go' will automatically be generated if the user's move makes it the engine's turn.

This solution was preferable over using 'playother', because it also works for engines that do not support the latter. And sending 'playother' without checking whether the engine was in bookSuspend would wreck the book code, as an engine that was already playing automatically would still receive an extra 'go', which it would likely interpret only after giving his own move, to switch to playing for the other color.