pedrox wrote:I think DanaSah is one of the few winboard engines that have updated for this.
By coincidence it is supported in the Baron 3.x as well, because the winboard parser shares its FEN parser with the UCI part.
The Baron 2.x is a closed project. This release was made on special request, and I fixed a few easy bugs while doing the release work. But that's it.
Changing the parser to understand the UCI-FEN would not have been a quick job (and strictly it is not a bug in the Baron but in the protocol extension and alternative GUIs are available) so you'll have to wait to use it with winboard-F until it is fixed in there.
Richard.
pijl wrote:
Please use a GUI that sends standard FENs in the winboard protocol instead of the UCI variant of it.
Richard.
Note that there are two FEN standards for FRC, X-FEN and Shredder FEN, and that Baron understands neither. What Richard really means here, is that you should use a GUI that sends FENs for standard Chess in FRC, rather than FRC standard FENs.
WinBoard protocol does not specify which type of FEN the engine will receive, other than that it will be a FEN for the variant that you are actualy playing. In FRC this means that the engine has to understand the meaning of A-H and a-h in the castling fiels, as all FEN standards in FRC use these.
pijl wrote:
Please use a GUI that sends standard FENs in the winboard protocol instead of the UCI variant of it.
Richard.
Note that there are two FEN standards for FRC, X-FEN and Shredder FEN, and that Baron understands neither. What Richard really means here, is that you should use a GUI that sends FENs for standard Chess in FRC, rather than FRC standard FENs.
WinBoard protocol does not specify which type of FEN the engine will receive, other than that it will be a FEN for the variant that you are actualy playing.
Can you point out where (in the original version 2 specification by Tim Mann) it is specified?
I could only find this: setboard FEN
The setboard command is the new way to set up positions, beginning in protocol version 2. It is not used unless it has been selected with the feature command. Here FEN is a position in Forsythe-Edwards Notation, as defined in the PGN standard.
Illegal positions: Note that either setboard or edit can be used to send an illegal position to the engine. The user can create any position with xboard's Edit Position command (even, say, an empty board, or a board with 64 white kings and no black ones). If your engine receives a position that it considers illegal, I suggest that you send the response "tellusererror Illegal position", and then respond to any attempted move with "Illegal move" until the next new, edit, or setboard command.
Seems to me that the FRC Baron 2.23 complies fully with this.
Of course, you can extend the protocol by giving the engine the option a method to tell the GUI that the extension is supported. The feature command is intended for that.
Btw: What have you done to 'fix' the edit command? Surely you cannot specify all legal positions for standard chess with this command as it is not aware of castling rights and en-passant. In fact, as fischerandom was already specified in version 1 of the winboard protocol, it is even legal to use 'edit' for fischerandom engines.
Well, that is exactly what I said, not? You meant that the FEN should be a standard FEN for normal Chess, as described in the PGN standard (for normal Chess).
The final remark of my previous post refers to the clarified specs as they are posted on the WinBoard forum, not to those on Tim Mann's site. His original protocol-2 specs are not clear and complete w.r.t. FRC, presumably because at the time they were written, WinBoard did not support FRC. So the issue was not given due consideration, and some important issues were not recognized or addressed. Merely adding the command variant fischerandom to an existing protocol spec does not turn it into a protocol that can handle FRC, as was apparently thought. Protocol v3 was more explicit in that respect; it mandatory prescribed Shredder FEN for use in the setboard command of FRC. But it never got off the ground.
I would think it rather obvious that if you want to have an engine that plays a variant, you should support FENs that are suitable for that variant, even if that is not stated explicitly in the protocol. So that the scope of the remark you quote, because it refers to a standard that only applies in normal Chess, is indeed limited to normal Chess, and has no bearing on any other variant that is not sufficiently compatible with normal Chess. I wonder how many people would write a Xiangqi engine, and then reject any Xiangqi FEN on the basis that it has a 9x10 board, and the FEN standard referred to prescribes 8x8 boards...
But apparently not. To my surprise there are not only people that feel comfortable with equiping their engine with a setboard command that is inadequate for the variant that the engine is supposed to play, they are even prepared to obstinately fight for it to maintain their engine in such a crippled state. I had expected people to prefer a correctly working engine, so I expected most WB engines that played FRC to already understand one FRC FEN or another, as it would never occur to me to not support that in my own engine. But this was obviously a miscalculation.
But, like I wrote above, it will be fixed in future WinBoard versions, which willl have a command-line option allowing the user to specify the FEN castling field. A new feature command would not be useful, as no existing engine would send it. So the strategy of mimicking old behavior unless WB recieves a feature command would only serve to break all old engines, and the old behavior of WB was to not send a setboard at all... But an option to have the user overrule the castling field will enable them to run even the most defective engines with inital positions, without infringing on the right of authors to keep their engines in a state that makes them forfeit in other positions.
As to the edit command: The v2 protocol specified that castling rights should be assumed for all corner Rooks and e-file Kings, and no e.p. rights. I clarified the consequences implied by this and the absence of commands to alter castling rights, e.p. status and side to move (the latter since the deprecation of the black command): Positions that do not satisfy the default assumptions, should be entered as another position, followed by one or more moves to create the desired position with the desired rights. For black-to-move positions this kludge is already described in the v2 protocol specs, and consists of making the a2-a3 move to give black the move. In the same spirit, positions with e.p. rights should be entered with the opposite side to move, and the Pawn to be e.p.-captured still on 2nd/7th rank, after which the move of that Pawn to 4th/5th rank should be forced into the engine. I did not implement these kludges in WB yet, though: it did not seem to have a very high priority compared to other things.
Protocol v3 specified that the edit command cannot be used in FRC, but I think this is unnecessary restrictive. So I extended the specs by how engines should react when they do want to use the edit command in FRC (which they can indicate through feature setboard=0, as usual), in the same spirit as for normal Chess: they should assume all Rooks and Kings that conceivably could have castling rights to indeed have these rights. Other positions would have to be entered through a kludge. Which I did not implement in WB yet, but again, the urgency seemed low, as there likely exists no WB FRC engine that does not support setboard, and for initial positions the kludge is never needed, as the default assumptions are satisfied for such positions.
