Send GTP play command according to the tree order

[ymgaq]

Hi, I'm a developer of a Go engine (AQ).
Thank you for developing your wonderful GUI program.

In GTP communication, Sabaki seems to send play B or play W command in the order from the upper left to the lower right. I think there are some special reasons for the style, but this may cause problems for Go engines if they are attached in the middle of the game.

1. The engine can not know Ko that occurred just before. Therefore, it may return illegal move (i.e., capture the Ko stone immediately).
2. Most of recent engines use neural networks, and the information of the last or before moves is really important.

Then, ｍy pull request is to modify the play commands when the board is not synced so that they are sent from the root node to the last one according to the game tree. (i.e. 1st move -> 2nd move -> ... -> last move.)

I am not so familiar with the function of Sabaki, so I'm not sure it covers all cases. In the test with my engine, it was able to recognize the board correctly with and without handicap games.

Perhaps I think there should be a smarter implementation.
In any case, I hope that Sabaki will be a more powerful tool in combination with various Go engines.

Thank you!

[yishn]

Thank you for your pull request!

As I wrote the engine sync code I suspected that my implementation may cause some problems even if the GTP specification doesn't specifically forbid placing stones non-consecutively. Eventually, I chose this way because of limitations in the GTP specification:

• SGF allows free stone removing/overwriting

  Someone can use AE to remove stones from the board or use AB and AW to overwrite the color of previous stones. AFAIK this can't be emulated on the GTP engine.

• An SGF game tree may contain nodes with illegal board positions

  Some engines can't process illegal board positions.

• SGF doesn't care for ko or suicide

  In some GTP engines you can't place stones if it results in a suicide or violates a ko rule, so replaying those games won't be possible for the engine.

[ymgaq]

OK, I understand why you implemented it that way. Thank you for detailed explanation.
It seems to be difficult to cover all cases of SGF games.

Then, I will manage this branch just in my fork.

[killerducky]

I wrote on L19 but I think you didn't see it:

I see your point out that in general SGF files can do almost anything. But in trying to handle all SGF file types, Sabaki doesn't support LeelaZero (or AQ and others like it). I propose you parse the SGF and determine if it is a normal game with simple moves (no position setup, removing/overwriting etc). In that case play back the moves to the engine as normal. At least this will allow it to work with LeelaZero.

[yishn]

@killerducky I did see it ;) I'm just a little busy at the moment. I will experiment with the idea in the winter holidays and see if it's okay performance-wise. I just didn't want to add anything in the thread on L19, because it was about Leela integration, not about Sabaki in general.