I haven't seen a lot of response to this, so I'll post my two cents. What follows is specific reactions to the various proposed commands. If you didn't read the original post, I recommend doing that first (it's copied below my response)

I find it really hard to believe that there isn't already a rules command in GTP. Is it possible that one exists but doesn't work well? If there is no such command, I'd think it really should be in there.

captured_by_black and captured_by_white could in theory become a single command (accepting a color argument).

is_legal seems useful for regression testing, at the very least for super ko and suicide. It might be interesting to try and consider shades of gray with this command. Filling your own eye is probably frowned upon even though it's legal...

adjust_status seems interesting but may be a little too close to implementation dependent details?

thinking seems interesting, but I wonder how compatible it is with the way most engines implement GTP. I'd be in favor of this command but it might not work in many cases. At the very least, this can only be done when command ids are used.

I personally don't see much value in standardizing last_move, next_move_nr, and a few others. It seems like a test once, never use again type of a thing. I don't really even see it as being that useful for regression testing.

Mark Boon wrote:

I'm currently looking to see what it would take to replace my GoEngine interface by an interface that would fit GTP. Since they basically fill the same role, except that GoEngine was only meant for Java, there must be similarities. There are of course, but there are also some differences. These probably fall in one of three categories:

1. Commands my GoEngine has but GTP doesn't and that are not strictly

necessary. 2) Commands my GoEngine has but GTP doesn't where maybe GTP could/should be extended. 3) Commands GTP has but my GoEngine doesn't, which are not striclty necessary to support.

At the moment only category 2 is of interest now, the other two categories I could deal with myself. I'll list them below. Most of them are related to the state of the game. Although the GTP definition explicitly states a certain amount of state is expected to be kept by the engine (like the number of stones captured, history etc.), it doesnt provide commands to query this state. Although it is not strictly necessary to provide means to extract this information, it can be very convenient. After all, for an engine to work meaningfully, it needs to implement a minimal administration of the game and knowledge about legal moves. By exposing this knowledge, a front-end could trust the engine to provide this information correctly, thereby reducing the complexity of the front-end.

# set_rules arguments rules (string) effects the engine will return moves and score according to these rules. output none fails when rules are not supported by the engine comments The engine needs to know by which rules the game is played, it seems strange this command is missing.

# captured_by_black arguments none effects none output number of stones captured by the black player (int) fails never

# captured_by_white arguments none effects none output number of stones captured by the white player (int) fails never

# is_legal arguments vertex color effects none output whether a move played by color would be a legal move (boolean) fails never

# next_move_nr arguments none effects none output number of the next move to be played (int) fails never

# color_to_move arguments none effects none output color of the next move to be played (b|w) fails never

# last_move arguments none effects none output vertex color (b|w) of the move that was last played fails never

# last_move arguments none effects none output vertex color (b|w) of the move that was last played fails never

# last_move arguments none effects none output vertex color (b|w) of the move that was last played fails never

# nr_passes arguments none effects none output number of consecutive passes played (int) fails never

# adjust_status arguments vertex* status (alive,seki or dead) effects the next call to final_score will return the score with the status adjusted at the list of points passed output none fails never

# thinking arguments none effects none output whether the engine is currently thinking about its next move(boolean) fails never comment this can be very useful to prevent undesirable re-entry of the engine

I would be interested to hear opinion against or in favour of these.

Mark