Adriaan wrote:
Some comments on the 2nd gtp V2 draft:
Thanks. I'll just add a few random responses at this time. Well, maybe it turned out to be more than a few. :-)
[design,nitpicking] 2.8 Timing since, we have the possibility of "line numbers", I see no reason for the responses beiing sent back in the same order as the requests were received.
Yes, this is somewhat redundant but I think it will make life simpler on the controller side to have that guarantee.
3.2.1 move maybe "Resign" should be added as a valid move.
Pass and resign are troublesome. I decided to include pass in the vertex entity but sometimes it doesn't make any sense like in a list of handicap stones. Resign on the other hand only really makes sense as a response from genmove, so I added that explicitly as a possibility for that command.
(in a subsequent section "Pass" was omitted)
Where? This is important to get consistent.
4.1.2 is too big, IMO.
Agreed. Most of it should be moved to section 8. (I wrote this before I decided to have a comment section.)
I think the PL[] and MN[] are (invisible) aspects of the board state. PL should be made explicit, MN is less important.)
It's perfectly reasonable both to include or not include player to move as a board state. I have rather negative experiences from other protocols of having it as a board state, which is why I decided to explicitly include color in the play and genmove commands. This is a definitive decision for GTP version 2.
Also, for setting up positions, there could be added a provision for one or more "forbidden" ko-locations to be kept in the board state.
Absolutely not. The only sane way to communicate ko information is by playing through the game so far. If superko is used it's also the only way.
I noticed the rulesystem-section has been removed. I rather liked this independent setting of tt-like rule elements. It looked clear and more workeable than a "package deal" Japanese/Chinese/Goe/Ing/Igs kind of approach (which involves more semantics).
Yes, having separate rule elements is definitely the way to go.
The timing commands should be moved to the tournament subset.
Uh, that's where they are.
IMO, The regression subset is not needed (for general use) and should be consired an extension.
You're underestimating the value of using GTP for regressions and the potential for sharing well defined test suites between programmers. I would have excluded this except for the fact that I consider it extremely important.
Strictly speaking, loadsgf is not needed in the core set, but can be allowed there, because it is general enough. Every implementation will need some kind of file loading, eventually.
loadsgf is not in the core set for two reasons:
1. GTP and SGF don't really fit very well. SGF has a complexity and power of expression which isn't met by GTP. Maybe it will be in some future GTP version, but clearly not now.
2. loadsgf requires the controller and the engine to have a common filesystem. This is a reasonable assumption in regression settings but not in general. (Inline SGF is out of the question.)
I don't see much need for renaming the V.1 "help" command into the ugly "list_commands". Semantics seem to have been tightened, but not changed.
A matter of taste apparently. I think "help" is more ugly.
To me, place_free_handicap <--> set_free_handicap is confusing. My proposal: rename place_free_handicap into gen_free_handicap, which seems more in line with genmove, too.
I considered that alternative but I don't really like the "gen" abbreviation. Does anyone else have an opinion on the naming of these commands, or maybe a better proposal?
6.3.3 play/genmove "pass" and "resign" should both be valid moves for both the "play" and "genmove" commands
Pass is already valid. (See definitions of vertex and move entities.) Resign is an explicit possibility for genmove but would it really make sense for play?
To facilitate automated playing, a command to report dead stones could be added. eg: "list_dead_stones B"
This can be done with the not yet documented "final_status_list" command.
loadsgf introduces a lot of implied semantics. The boardstate is changed heavily by sgfload.
Absolutely.
SGF will change the MN-, PL- , KOlocation state in the engine, which were designed to be hidden in this GTP-draft.
What is the problem with these? If the engine wants to use move number for some purpose it may change that state however it likes. I don't see why the controller or the protocol should care.
Player to move is a non-issue by design.
"KOlocation" is implied by the "move history" board state. (There is, by the way, no standard SGF property to manipulate ko state besides move history.)
8.2.11 [error] GMP uses a one-dimensional vertex coding scheme. 1 bit color + 9bits lineair addres, IIRC.
Yes, but it also associates this linear address with 2D coordinates which are elsewhere used to define the fixed handicap placement.
[politics] Why mention IGS and not NNGS, KGS ?
Whatever you think about the evolution of go servers it's undeniable that IGS was first and I think it's safe to say that other servers have followed its lead with respect to choice of coordinate convention. A wise decision, of course.
Actually I'd like to know which servers do use this convention and whether there are some which don't. I only regularly use NNGS, so my knowledge is rather limited here.
Similarly I later have the comment "This fixed handicap placement is compatible with the Go Modem Protocol and many go servers." This is intentionally vague because I don't really know about IGS or other servers than NNGS. Furthermore NNGS is only almost compatible. It deviates, probably due to some obscure bug, for 2 and 3 handicap stones on an 8x8 board. Any information about how other servers do would be most welcome.
8.3.2 IMO these are extensions, since it is unlikely that others (than gnugo) will ever use them.
Not so. There already are other people using them.
/Gunnar