Author: Reinhard Scharnagl
Date: 00:42:05 07/27/05
Go up one level in this thread
On July 27, 2005 at 02:30:34, Alessandro Scotti wrote: >On July 27, 2005 at 01:05:33, Reinhard Scharnagl wrote: > >>SMIRF though using TMCI is showing by doing that it is possible to support a lot >>of variants WITHOUT SWITCHING the engine's mode simply by communicating with >>compatible FEN strings and encoded moves. This idea also could have been >>applicated to a UCI protocol extension. But actually that switches an engine >>into an FRC mode forcing the engine to different encoding of moves and FEN >>strings, e.g. generating different FENs for identic positions (where castling >>rights are based on traditional K+R placements only). Hi Allessandro, >I would not say that engine is "switched into FRC mode". Communication protocol >and engine interface should be completely separated, although they usually >aren't for practical reasons. Also, why not telling the engine it's going to >play FRC? Having more information at hand is rarely going to hurt, and you can >always throw it away. the problem is not the switching itself. But it is used to 'prove' Chess960 to be an incompatible variant. All information needed is already included in to be communicated FEN strings. And if you like to switch (for which obscure purpose ever) there is no need to change the enconding of transferred moves. My proposal (and the way Smirf works) is to encode castlings as kings moves when having at least two elementary steps and as move to the involve rook otherwise. This constitutes a compatible way along traditional chess, avoids misunderstandings looking at King's single step moves, and it establishes clear gestures to be made at a GUI to enter any castling move. And of course it is counter productive to change the way of producing a FEN string. Shredders approach now would produce different FEN strings in positions, where existing castling rights are related to traditional K+R placements. This does not make any sense at all. But as a rule to avoid switching FORCES COMPATIBILITY instead of such nonsense. >A protocol adaptor, which you would have to write for TMCI anyway, can easily >translate FEN and adjust castling moves before passing them to the engine if >needed. Because TMCI is rather modern this would not work in both directions. And as long as extended UCI will mutually make Chess960 an incompatible variant, there is no way to give me any motivation for to do this. >P.S. I really like SMIRF and your ideas on chess programming, so I hope >development may restart soon! I just have published the status quo to enable chess programmers to watch a working compatible Chess960 concept beside of protocol questions. But when the situation is not changing (e.g. by the Chess960 WNCA to publish quality concepts for Chess960 representations in FEN, PGN and GUI gestures) I will work on other ideas like Go programming etc.. Reinhard.
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.