A small request

[defrag1971]

- 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?

No, it's not greyed out.
I added Stockfish as main engine ("Duck Chess" -fcp "Duck Chess.exe" -fd "\" /variant=duck), when I start the program in the Specify Engines startup dialog there are two fields, it shows Stockfish as a choice only in the first field.

- 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'.

Ok resizing I can see the Duck, thanks.

- 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.

Ok.
also, if a king moves in check, even if the Duck covers the check, still Winboard thinks it's illegal. In Duck chess there is no check move restriction.

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).

Here's the debug from a simple Sicilian defence opening, from what I understand of it Winboard sends the move (c7c5,e2b5) and the engine answers it's illegal.
But maybe the move should have been c7c5,c5e2 because it is where I placed the Duck (e2 square).

1393012 >first : time 300
1393012 >first : otim 300
book hit = (NULL)
1393028 >first : go
nps: w=-1, b=-1
1393028 <first : info string classical evaluation enabled
1393028 <first : 1 53 0 831 1 92333 0 e2e3,e3e2
1393043 <first : 2 92 2 1839 2 65678 0 d2d4,d4a3 a7a6,a6d2
1393059 <first : 3 146 4 2737 3 60822 0 d2d4,d4e3 a7a6,a6d2 e2e4,e4e2
1393075 <first : 4 176 5 3409 4 64320 0 d2d4,d4e3 a7a6,a6d2 e2e4,e4e2 a6a5,a5a3
1393124 <first : 5 153 9 5720 5 62173 0 d2d4,d4e3 d7d6,d6d2 e2e3,e3d7 a7a6,a6a3 g1f3,f3a7
1393250 <first : 6 123 19 9917 6 50340 0 d2d4,d4e3 d7d6,d6a3 c2c4,c4d7 e7e6,e6d2 e2e4,e4e2 a7a6,a6a3 b2b3,b3b2
1393829 <first : 7 125 76 26126 7 34062 0 e2e4,e4d6 g8f6,f6c3 d2d3,d3d6 e7e6,e6d4 f2f4,f4e2
1394829 <first : 8 76 176 56471 8 31976 0 e2e4,e4d6 e7e6,e6d3 b1c3,c3d6 a7a6,a6d3 g1f3,f3d6 b8c6,c6d3 g2g3,g3d6 g8f6,f6d3
1395895 <first : 9 323 278 100834 12 36271 0 e2e4,e4d6 b8c6,c6f3 e4e5,e5d6 c6e5,e5d3
1396129 <first : 10 238 301 112943 10 37522 0 e2e4,e4d6 b8c6,c6f3
1396145 <first : 10 238 301 113141 10 37476 0 e2e4,e4d6 b8c6,c6f3
1396145 <first : move e2e4,
1396145 <first : move e4d6
silence
1397039 >first : lift c7
1397039 <first : highlight 8/8/2Y5/2Y5/8/8/8/8
1397585 >first : put c5
1398101 >first : time 300
1398101 >first : otim 104
book hit = (NULL)
1398101 >first : usermove 1398101 >first : c7c5,e2b5
1398101 <first : Illegal move: c7c5,e2b5



I think the code to fix is this:

if((boards[moveNum][m[6]-ONE][m[5]-AAA] < BlackPawn) == (boards[moveNum][m[1]-ONE][m[0]-AAA] < BlackPawn)) // move is kludge to indicate castling
snprintf(buf, MSG_SIZ, "%c%d%c%d,%c%d%c%d\n", m[0], m[1] - '0', // convert to two moves
m[2], m[3] - '0',
m[5], m[6] - '0',
m[2] + (m[0] > m[5] ? 1 : -1), m[3] - '0');

Sometimes it kicks in above, instead of:

} else if(gameInfo.variant == VariantDuck)
snprintf(buf, MSG_SIZ, "%c%d%c%d,%c%d%c%d%s\n", m[0], m[1] - '0', // convert to two moves
m[2], m[3] - '0',
m[2], m[3] - '0',
m[5], m[6] - '0', c);

[F.Huber]

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.

A quite long week ...

[H.G.Muller]

I said "at least"!

After some setbacks the plumbing is finished for now, though. But when I am away from home for the holidays working on WinBoard is also not an option.

[H.G.Muller]

The version of WinBoard in http://hgm.nubati.net/Duck2.zip now should put WinBoard in Machine White/Black mode after setting up / pasting a position, when WinBoard is not in Game Viewer or ICS mode.

[F.Huber]

Well, it works only for pasting a position from the clipboard but NOT when loading a FEN/EPD file (which still ends in 'Edit Game' mode).

But no problem: in the meantime I've analyzed WinBoard with a debugger, and by patching 3 bytes now loading a position (FEN/EPD) from file or clipboard is now working excactly as loading a game (PGN) in your last 'new49x.zip':
it ends up in a state where none of the options in the 'Mode' menu is checked, i.e. not 'Machine White/Black' and not 'Edit Game' or 'Edit Position'!
So at least both functions (load game or position) are consistent, and the user MUST choose the machine's color before he can continue (so he can't enter a move by mistake).

[defrag1971]

It is possible to instruct Winboard to show the engine name as specified in the configuration?
If I clone an engine tweaking its behavior and want to test, in the PGN they appear with the same name (as taken from the engine itself).

edit: Ok I found it, option -fn (not in the guide though)

[H.G.Muller]

You can do that through the Load Engine menu by putting something in the Nickname field.

[H.G.Muller]

But no problem: in the meantime I've analyzed WinBoard with a debugger, and by patching 3 bytes now loading a position (FEN/EPD) from file or clipboard is now working excactly as loading a game (PGN) in your last 'new49x.zip':
it ends up in a state where none of the options in the 'Mode' menu is checked, i.e. not 'Machine White/Black' and not 'Edit Game' or 'Edit Position'!

But why would you want that? This seems to me the 'always wrong' option. After loading PGN it makes sense to go to a mode where you cannot accidentally erase it by playing a move, and where it auto-steps through the game. But when loading a FEN there is no game to auto-step through, or to erase.

[F.Huber]

But why would you want that? This seems to me the 'always wrong' option.

Yes, but since you refuse to implement the 'always right' option (i.e. setting it to 'user has the move' for all 4 cases of loading a game or position from a file or clipboard), this was the only possible method with a debugger/hexeditor. For changing it to 'Machine White/Black' I would need to find out which side has the turn, and it's impossible to insert the necessary code into an EXE file.

[H.G.Muller]

Even so, what do you gain by being in Load Game mode compared to being in Edit mode? In both cases you would still have to open the Mode menu and click Machine White/Black, or Analyze.

'Consistency' seems a non-sensical goal; loading a game is not the same as loading a position. So why would you even expect that it would bring you to the same state?

[F.Huber]

'Consistency' seems a non-sensical goal; loading a game is not the same as loading a position. So why would you even expect that it would bring you to the same state?

No, 'Consistency' makes very much sense. You forget that I'm using WinBoard as GUI for my emulation of old chess computers, and with them it's very complicated to correct a mistakenly made user move!
I just want to avoid that the user enters a move (after Load Game) or changes the position (after Load Position) BY MISTAKE, so forcing him to use the menu and choose what he really wants is definitely the best way.
And usually after loading a game or a position in most cases the engine should make the first move, so no matter in what state you are - you will almost always have to enter the menu to start the engine.

[H.G.Muller]

Seems to me you would have to be pretty much insane to play a move by accident after loading a position when it was not your intention to play a move. Why would you ever enter a move when it was not your intention to play against the computer from the loaded position? If your intention was to play with the other color, your attempts would fail even when you try to 'grab' a piece.

And even if you would, you could just reload the position. It is true I retired the menu items 'Reload Position' and 'Reload Game', but you could just hit 'Load Next Position' and then 'Load Previous Position' to achieve the same. (Or hit the Alt + Shift + PgUp/Down keys.) That only requires the engine to restart. Surely your emulator would be able to do that.

[F.Huber]

Seems to me you would have to be pretty much insane to play a move by accident after loading a position when it was not your intention to play a move.

Apparently you have no idea what insane ideas some computer users come up with.
Assume the user loads a position from a file (which puts WinBoard in 'Edit Game' mode, something that no normal user would expect in this situation). Now he makes a move, but the engine doesn't answer. Why? Well, because the engine has received a 'force' from WinBoard before,
and there's no 'go' after the user's move, because of the 'Edit Game' mode!
Now what will be the next step? An email or a forum posting like "Why the heck does the engine not move?"

Let me sum up the current behaviour of WinBoard:
1) Load Game (from file): nothing is checked in the 'Mode' menu
2) Load Game (from clipboard): nothing is checked in the 'Mode' menu
3) Load Position (from file): 'Edit Game' is checked
4) Load Position (from clipboard): 'Machine White/Black' is checked

4 similar (or at least related) actions returning 3 different states - that's what I would call 'insane'!
The only correct, logical and consistent method would be, if all 4 actions would put WinBoard into 'Machine White/Black' mode, so that the user could immediately continue with his own move OR go to the 'Mode' menu and start the engine (or of course select any other mode like 'Analysis' or 'Edit Game/Position'). If I load a game or a position, then I definitely expect to be in 'play mode' and have the turn, NOT to be in 'Edit' mode, point!
Because it's impossible to just patch the EXE of WinBoard so that it works that way, I've simply used the 2nd best method, i.e. nothing is checked after all 4 actions. That's in fact not really different to 'Machine White/Black' checked, because after loading a game (e.g. for using special opening lines in engine tournaments) or loading a position (for position tests or mate puzzles) in 99% of these situations the user wants the engine to make the first move, so he almost always has to open the 'Mode' menu and choose 'Machine White/Black'.

It's amazing to see the nonsense you keep repeating ("you could just do this or that ...") just to avoid having to admit that this illogical mode setting is just a bad design in Winboard.
I don't know any other programmer who is as resistant to improvements in his program as you are.
Thus any further discussion is useless (and my patched Winboard version is ok for me, at least much better than the original one) ...

[H.G.Muller]

That is of course because these are not really improvements at all. They merely seem 'solutions' to nonexisting problems, that you bring upon yourself by using a needlessly non-compliant engine.

And for your information: WinBoard is not 'my program'. It is a GNU open source project, to which I made some contributions such that it would better fit my needs, and shared those with the community. People that have other needs are free to do the same. You seem to believe that that my reason for existing is to service requests for patching WinBoard. Well, it is not. To me WinBoard is just a tool that I need to develop and run my engines. So unless there are bugs or missing features that make it unfit for my personal use, working on it has a very low priority. And when unavoidable, is an annoying distraction at best.