UCI has a lot of really useful setup commands. You can modify hash table size, internal state of the engine such as options to control whether the ability to resign is turned on, and things like that. It's actually not particularly tricky, the engine itself specifies what it can do and the UI or controller doesn't even need to understand it. And there is no baggage with it. You don't have to understand much of anything to make a UCI compatible engine. Very well thought out and flexible.
It's probably asking to much to get close to UCI's sophistication, but if you decide to upgrade GTP, I wish you would FIRST take a good hard look at UCI just to get ideas. It's a very succesful practical working protocol. - Don On Thu, 2007-03-08 at 21:38 +0100, Gunnar Farneback wrote: > Weston wrote: > > Although Gunnar specifies async_genmove to return zero or one > > responses, I believe that it may be more useful to allow it to return > > any number. This allows the possibility for the controller to update > > a "current best" display while it has still not accepted a single > > definitive response. From the controller's point of view, the command > > could still be in effect until a response to the abort_async_genmove > > has been received. (although perhaps end_async_genmove would be more > > appropriate name in this case.) I don't feel strongly either way on > > this, but I thought that I should mention the possibility. > > It's cleaner to have async_genmove return at most one move and let > updates of current best move, significant changes of a principal > variation, or other interesting information be asynchronous responses to > some other command enabling that information. > > > Does it also make sense to forbid commands that modify the engine's > > state? If the board state changes before async_genmove generates a > > response, to which board does the response apply? > > It should of course apply to the state when the async_genmove was > requested, but indeed it doesn't make sense to try to change the state > under the feet of the engine. Either it could be forbidden or the engine > could choose to block on state changing commands until the move > generation is ready. > > /Gunnar > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
